ナビゲーションに戻る

プロセス定義の設定コンポーネントの定義

ビジネス アナリストは、プロセス定義の設定ページを使用して、承認定義プロセスを定義します。プロセスは、ステージ、パスおよびステップから構成されます。承認パスに設定する承認ステップは、トランザクションに必要な承認レベルを表します。

このセクションでは、プロセス定義の設定コンポーネントの定義方法について説明します。

ページ名

定義名

用途

プロセス定義の設定ページ

EOAW_PRCS_MAIN

承認プロセスのステージを定義します。

条件定義ページ

EOAW_CRITERIA

ワークフロー承認の条件を定義します。

通知ページ

EOAW_NOTIFY_DEF

通知オプションを定義します。

タイムアウト オプション ページ

EOAW_TIMEOUTDEF

グローバル タイムアウトおよびエスカレーション設定を定義します。

承認パス定義ページ

EOAW_PATH_SEC

ワークフロー承認パスを設定します。

承認ステップ定義ページ

EOAF_STEP_SEC

ワークフロー承認のステップを定義します。

プロセス定義の設定ページ (EOAW_PRCS_MAIN) を使用して、承認プロセス ステージを定義します。

画像: プロセス定義の設定ページ

次の例では、プロセス定義の設定ページのフィールドおよびコントロールを説明します。このページのフィールドおよびコントロールの定義は後で説明します。

プロセス定義の設定ページ

ビジネス アナリストは、このページを使用して承認定義プロセスを設定します。プロセスは、ステージ、パスおよびステップから構成されます。承認パスに設定する承認ステップは、トランザクションに必要な承認レベルを表します。

次のような承認プロセスを構築できます。

  • 組織または階層型の承認範囲内にある承認プロセス。

  • 複数のトランザクション エントリが同時に処理できるようにするために、並列処理を使用するプロセス。

  • 1 つの処理の完了後に次の処理を開始できるようにするために、一連の処理を要求するステージ承認を使用するプロセス。

通常の承認プロセスには、次のような要素が含まれます。

  • 金額ベースの承認条件。

  • 各ステップに 2 人の承認者。あるステップで両方の承認者が承認しなければ、リクエストが次のステップに進みません。

フィールドまたはコントロール

定義

プロセス ID

トランザクション登録ページで作成したプロセス ID。

承認トランザクション レジストリについて」を参照してください。

定義 ID

自分にとって意味のある ID コードを入力してください。この ID は、承認のモニター ページの検索フィールドとして使用されます。

注: 以前のリリースからアップグレードする場合は、[セットID] フィールドが [定義 ID] に使用されます。

有効日

この承認プロセスが有効になり、システムで利用可能になる日付を示します。この値は、特定の承認プロセス ID および定義 ID の承認プロセスに適用され、有効日の付けられたエンティティに関連する PeopleSoft の機能が含まれます。たとえば、承認プロセス ID、定義 ID および有効日が指定された複数の承認プロセスが有効の場合、最新の有効日を持つ行が使用されます。

説明

承認プロセスの説明を入力します。

コピー承認処理

このリンクをクリックして、承認プロセスをコピーします。

承認プロセス表示

このリンクをクリックしてグラフィック ツールにアクセスし、承認プロセスのそれぞれのステージ、パスおよびステップを参照できます。

注: この機能には、SVG ビューアが必要です。

注: 承認プロセス ビルダー ページでグラフィック ツールを表示したときに、変更を加えようとすると、標準の承認プロセス定義ページに自動的に戻ります。

承認プロセスのプレビュー

このリンクをクリックして、実行時にワークフロー インスタンスがどのように表示されるかを確認できます。

定義オプション

このページのこのセクションは、承認プロセスのオプションを定義するために使用します。

フィールドまたはコントロール

定義

定義条件

クリックすると、条件定義ページにアクセスし、このプロセスでのユーザーとフィールドの条件、および金額とアプリケーション クラスの条件を定義できます。このページは、パスおよびステップに使用する各条件定義ページと同様に機能しますが、この条件は、承認の処理に使用する定義 ID がどれかを識別するために使用されます。

条件定義ページ」を参照してください。

警告条件

クリックすると、条件定義ページにアクセスし、このプロセスでのユーザーとフィールドの条件、および金額とアプリケーション クラスの条件を定義できます。この条件はアプリケーションにより評価して、承認するトランザクションの条件を強調表示できます。たとえば、ワンタイム出荷先住所は、このリクエストのみに使用されます。

警告条件は、承認の転送方法を判断するためには使用されません。これは、メッセージ (警告) を承認プロセスの一部として表示するかどうかをアプリケーションが判断するために使用されます。

定義の通知

クリックすると、承認フレームワークの通知ページにアクセスし、トランザクションの設定コンポーネントで定義した 1 つ以上のプロセス定義通知オプションをオーバーライドする通知オプションを定義できます。

トランザクションの設定ページ」を参照してください。

タイムアウト オプション

クリックすると、承認フレームワークのタイムアウト オプションページにアクセスし、承認定義レベルでグローバル タイムアウトおよびエスカレーション設定を設定できます。パス レベルと承認定義レベルとでタイムアウト設定が異なる場合、パス レベルの設定が優先されます。エスカレーションがカレンダーに基づくようにする場合、カレンダー ID を指定できます。固有のカレンダーに基づいてタイムアウト オプションを設定するには、「エスカレーション カレンダー設定ページ」を参照してください。

管理者ロール (管理ロール)

ワークフローで使用される PeopleSoft ロールを選択して、承認処理でエラーがあった場合に、トランザクションをそのロールに該当する全ユーザーに送信します。

注: エラーの条件は承認者がいないか、または十分な承認者がいないかのどちらかです。

ユーザー リスト定義ページ」を参照してください。

ステータス

この承認プロセスの現在のステータスを選択します。選択肢は以下のとおりです。

[アクティブ]: 承認プロセスが使用できることを示します。

[非アクティブ]: 承認プロセスが使用できないことを示します。

特定の条件で開始されたトランザクションは、ステータスが [非アクティブ] の場合でもその定義を使用して続けられます。

優先順位

定義の優先順位を入力します。優先順位は 1 が最高です。呼出元のアプリケーションが承認フレームワークに明示的に定義を渡さない場合、承認フレームワークでは、使用する定義を判断するために、定義レベルの条件が使用されます。複数の定義から true の条件が返された場合、優先順位が最も高い定義が使用されます。

注: 複数の定義 ID に同じ優先順位が設定されていると、複数の定義 ID が該当した場合に処理が一致しなくなることがあります。

デフォルト プロセス定義

選択すると、入力された条件に一致する定義 ID が他にない場合は、このプロセス定義をデフォルトとして使用します。

行の完了時に次の処理を実行

オンにすると、トランザクション内の他の行が完了するのを待たずに、各行が承認プロセスの次のステップに進むことができます。この設定は、プロセスの最後に行レベルのステージを持つ承認プロセスに適用されます。

このチェック ボックスをオンにすると、トランザクションにまだ承認プロセスが完了していない一部の行があっても、トランザクションの承認済の行は次の承認ステップに進みます。各行が承認プロセスを完了したときに、ヘッダー ステータスおよび行ステータスは即時に更新されます。これにより、トランザクションの全行がワークフロー承認を完了するのを待機する必要なく、個々の行を次のステップに進めることができます。

このチェック ボックスをオフにすると、トランザクションの任意の行が次の承認ステップに進むためには、トランザクション内の全ての行が承認プロセスを完了する必要があります。たとえば、ある調達依頼の行は、調達依頼の全ての行が承認プロセスを完了するまでは、発注をソーシングできません。ヘッダー ステータスおよび行ステータスは、このトランザクションの最後の行が承認プロセスを完了するまでは、保留ステータスのままになります。最後の行に対して承認アクションが実行されると、ヘッダー·ステータスと各行ステータスは更新されます。承認アクションは、却下または承認である可能性があります。たとえば、トランザクションに 2 つの行があり、ある行が承認され、もう 1 つの行は却下された場合、承認プロセスは完了し、承認された行は次のステップに進むことができます。

ユーザー自動承認

オンにすると、該当する承認プロセスで承認者が実行したアクションが記録されます。この承認プロセスが次に承認者に提示された場合、承認者が前回選択したアクションが自動的に適用されます。承認プロセスでのステップの自動適用は、[ユーザー自動承認] チェック ボックスをオフにするまで変更されません。

この設定は、承認者がこのプロセスで以前に承認した特定の行またはヘッダーにのみ適用されます。ヘッダー承認とは、全ての行における行レベルの承認を意味します。

依頼者へ転送

このチェック ボックスをオンにすると、この承認は依頼者に転送されます。このチェック ボックスがオンになっており、依頼者が承認者でもある場合、依頼者は、最小承認が既に満たされている場合を除き、手動でトランザクションを承認する必要があります。

このチェック ボックスがオフになっており、依頼者が承認者でもある場合、システムによって自己承認がアクティブかどうかがチェックされます。自己承認がアクティブでない場合、条件がチェックされます。

承認機能について」を参照してください。

依頼者を含む

オンにすると、依頼者が作成者と同じでないときに、ユーザーは依頼者を挿入できます。

ステージ

このページのこのセクションは、ステージを定義するために使用します。並行する複数のパスを含めることができますが、ヘッダーまたは行レコードのレベルが同じである必要がある承認プロセスです。ステージは 1 つずつ順番に実行され、前のステージが完了しないと次のステージは開始されません。

フィールドまたはコントロール

定義

ステージ番号

このステージの連番を示す番号を入力します。

説明

ステージの説明を入力します。

レベル

[行] または [ヘッダー] のいずれかを選択します。

ステージは 1 つずつ順番に実行され、前のステージが完了しないと次のステージは開始されません。ステージは、ヘッダーまたは行のどちらのレベルでもかまいません。行レベルでのステージでは、承認者が単一のトランザクションで個々の行アイテムを別々に承認できます。承認フレームワークでは、各ヘッダーと各行は、個別の要素として認識されます。行とはヘッダーの子に当たります。ヘッダー ステージは固有のヘッダーについて処理を行いますが、行ステージは各行について処理を実行します。ステージは 1 つまたは複数のパスから構成されます。

パス

このページのこのセクションは、ステージのパスを定義するために使用します。[詳細] リンクと [条件] リンクは、各パスに情報を追加するために使用します。

条件定義ページ」、「承認パス定義ページ」を参照してください。

ステップ

このページのこのセクションは、パスのステップを定義するために使用します。[詳細] リンクと [条件] リンクは、各ステップに情報を追加するために使用します。

条件定義ページ」、「承認ステップ定義ページ」を参照してください。

条件定義ページ (EOAW_CRITERIA) を使用して、ワークフロー承認の条件を定義します。

画像: 条件定義ページ

次の例では、条件定義ページのフィールドおよびコントロールを説明します。このページのフィールドおよびコントロールの定義は後で説明します。

条件定義ページ

このページは、承認プロセスに適用するさまざまなタイプの条件を定義するために使用します。1 つの論理演算子を持つ 1 つのフィールドと、承認を処理するためにトランザクション データを読み込むアプリケーション クラスからなる 1 つの定義値によって構成される定義を作成できます。

フィールドまたはコントロール

定義

条件タイプ

次のオプションの中から 1 つを選択します。

  • [常に真] を使用すると、この承認プロセスがトリガされます。条件は不要です。評価の結果が真となるパスのみを通ります。

  • [アプリケーション クラス] では、ワークフロー承認タスクが真と評価されるかどうかを判断するために、システムで使用される特定のアプリケーション クラスを定義する必要があります。

    注: ユーザー入力条件に必要な詳細レベルが含まれていない場合、条件タイプとして [アプリケーション クラス] を使用します。

  • [ユーザー入力] では、全てのレコードとフィールドの組合せを入力する必要があります。これは、値または金額のどちらかに基づき、評価結果が真となるワークフローをトリガします。

アプリケーション クラスの条件 (セクション)

このセクションでは、承認プロセスを定義するための条件として、アプリケーション パッケージを割り当てます。クラスを定義する際に、この条件は承認プロセス用に入力した他の条件と共に使用されます。

画像: [アプリケーション クラス] 条件タイプが表示されている条件定義ページ

次の例では、[アプリケーション クラス] 条件タイプを示す条件定義ページのフィールドおよびコントロールを説明します。このページのフィールドおよびコントロールの定義は後で説明します。

[アプリケーション クラス] 条件タイプが表示されている条件定義ページ

フィールドまたはコントロール

定義

ルート パッケージ ID

基本のアプリケーション パッケージを選択します。ここで選択した項目は、他のパッケージや子のアプリケーション クラスの親となります。

アプリケーション クラス パス

ルート パッケージ内で特定のクラスを記述するパスを選択します。

アプリケーション クラス: 例

次の例は、EOAW_CRITERIA:CriteriaBase を拡張し、Check メソッドを実装する承認条件として記述されたアプリケーション クラスを示しています。この例は、EOAW_CRITERIA:EXAMPLES にもあります。

import EOAW_CRITERIA:DEFINITION:*;

class CriteriaClassExample extends EOAW_CRITERIA:DEFINITION:CriteriaBase
  1- method CriteriaClassExample(&rec_ As Record);
  2- method Check(&recBind As Record) Returns boolean;
  3- method CheckwithComments(&recBind As Record) Returns array of string;
private
   instance Record &rec;
   method CheckSQL(&recBind As Record) Returns boolean;
end-class;

method CriteriaClassExample
   /+ &rec_ as Record +/
   %Super = create EOAW_CRITERIA:DEFINITION:CriteriaBase(&rec_.EOAWCRTA_ID.Value);
   &rec = &rec_;
end-method;

method Check
   /+ &recBind as Record +/
   /+ Returns Boolean +/
   /+ Extends/implements EOAW_CRITERIA:DEFINITION:CriteriaBase.Check +/
   Local boolean &queryStatus;
   rem %This.CheckQuery(&recBind);
   Local boolean &sqlStatus = %This.CheckSQL(&recBind);
   
   Return &sqlStatus;
   
end-method;

method CheckwithComments
   /+ &recBind as Record +/
   /+ Returns Array of String +/
   /+ Extends/implements EOAW_CRITERIA:DEFINITION:CriteriaBase.CheckwithComments +/
   Local array of string &aryComments = CreateArrayRept(" ", 0);
   
   Return &aryComments;
   
end-method;

method CheckSQL
   /+ &recBind as Record +/
   /+ Returns Boolean +/
   Local string &sqlDef, &SQLText;
   Local integer &i;
   Local Rowset &rsResults;
   
   &SQLText = "SELECT 'X' FROM PS_INSTALLATION";
   Local string &output;
   REM ***** Specify a query that uses some or all of the transaction keys as input;
   SQLExec(&SQLText, &output);
   If All(&output) Then
      Return True
   Else
      Return False
   End-If;
end-method;

この例は次のとおりです。

  1. CriteriaClassExample はクラス名です。全てのレベルと照合されます。この入力は、EOAWCRTA_ID フィールドを格納したレコードです。このメソッドには、このパラメータがある必要があります。

  2. Check メソッドは、これを実行する主なメソッドです。条件が真または偽のどちらであるかを検証します。追加する任意の要素を呼び出すことができます。この場合、CheckSQL という名前のプライベート メソッドを呼び出しています。&recBind パラメータは、トランザクションのクロス リファレンス レコードです。このクロス リファレンス レコードは、承認ワークフロー エンジンをトランザクションに関連付けます。トランザクション キーは、クロス リファレンス レコード上のフィールドです。RECNAME という名前のフィールドもあり、これにより、トランザクション レコードを再構築できます。

  3. CheckwithComments メソッドは、Check メソッドとほぼ同じです。これらの違いは、このメソッドは、真である条件の条件ページからの内容を返す点です。これは、承認プロセス定義ページの [警告条件] の領域で役立ちます。アプリケーションが単純な通知 (メッセージ) を表示する場合、CheckwithComments メソッドを使用して実現できます。この例として、eProcurement-調達管理のワンタイム住所チェックがあります。

次の例に、Self Criteria からの呼出しの作成方法を示します。

If (All(&c) And
            &c.Check(%This.path.thread.rec)) Then
         &self_ok = %This.utils.SELF_OK;
      End-If;

これは、Criteria オブジェクトのコンストラクタです。

&SelfAppCriteria = &fact.GetCriteria(&rec.EOAWSELF_CRTA_ID.Value);

ユーザー入力条件 (セクション)

このセクションを使用して、承認の追加条件を定義します。

画像: [ユーザー入力] 条件タイプが表示されている条件定義ページ

次の例では、[ユーザー入力] 条件タイプを示す条件定義ページのフィールドおよびコントロールを説明します。このページのフィールドおよびコントロールの定義は後で説明します。

[ユーザー入力] 条件タイプが表示されている条件定義ページ

フィールドまたはコントロール

定義

説明

警告の目的を入力します。

たとえば、ワンタイム出荷先住所を使用している場合、ワンタイム出荷先住所が、その調達依頼に添付されることを示す説明を作成します。

全ての条件必須

選択すると、ワークフローがトリガされて評価が真となるために、条件定義ページで定義した全ての条件を満たす必要があることを示します。

フィールド条件 (セクション)

このセクションを使用して、承認プロセスで使用するファイルに含まれる、データ範囲またはデータ タイプを管理またはフィルタするためのレコードおよびフィールドを選択します。このセクションに行を追加し、承認条件を構築するときは、それらの行は、承認フレームワークによって長い SQL 文に変換され、各行は OR 演算子で接続されます。たとえば、上のスクリーンショットで指定されている条件に対して生成される SQL の where 句は、次のようになります。

"where HRS_JOB_OPENING_ID > '10000' OR HRS_JOB_OPENING_ID < '9900'"

重要 Not Equal To 条件演算子が行内に使用されている場合、後続の行は、OR 演算子でなく AND 演算子で接続されます。次の例は、Not Equal To 演算子を含むフィールド条件に対して構築された SQL を示しています。

"where HRS_JOB_OPENING_ID <> '10500' AND HRS_JOB_OPENING_ID > '10000' AND HRS_JOB_OPENING_ID < '11000'"

承認フレームワークでは、SQL 内で指定した条件値をカッコで囲むことはサポートされていません

フィールドまたはコントロール

定義

レコード名

承認条件の定義に使用するレコードを選択します。

たとえば、ワンタイム住所を示す場合、PO_ADDR_REQ_VW をレコードとして特定します。

フィールド名

承認条件の定義に使用するフィールドを選択します。以下のフィールド条件グリッドで指定する値は、承認条件の決定に使用されます。

条件演算子

承認条件を構築する演算子を選択します。

以下の演算子が使用できます。

  • [範囲]: 指定したフィールドに、[値] フィールドを使用して特定される範囲内の値があります。

  • [=]: 指定したフィールドに、[値] フィールドに入力された値と同じ値があります。

  • [>]: 指定したフィールドに、[値] フィールドに入力された値を超える値があります。

    注: [>=] 演算子 (通常 >= 記号で示される) はサポートされていません。

  • [空欄]: 指定したフィールドに値がありません。選択した場合、[値] フィールドは表示されません。

  • [NOT BLANK]: 指定したフィールドに値があります。選択した場合、[値] フィールドは表示されません。

  • [<]: 指定したフィールドに、[値] フィールドに入力された値未満の値があります。

    注: [<=] 演算子 (通常 <= 記号で示される) はサポートされていません。

  • [<>]: 指定したフィールドに、[値] フィールドに入力された値を超える値またはその値未満の値があります。

2 つの [値] フィールドを使用して、演算子条件が評価する範囲を定義します。2 番目の値は、選択した条件演算子が [範囲] の場合にのみ使用されます。

金額条件 (セクション)

このセクションを使用して、調達依頼金額値または金額に基づいた承認条件を確立します。定義した値を使用して、調達依頼を承認するための転送経路が決まります。システムが承認プロセスまたはプロセス内のステップやパスの条件を評価するときは、このセクションで定義した金額が使用されます。

画像: 金額に対して [ユーザー入力] 条件タイプが表示されている条件定義ページ

次の例では、金額に対して [ユーザー入力] 条件タイプを示す条件定義ページのフィールドおよびコントロールを説明します。このページのフィールドおよびコントロールの定義は後で説明します。

金額に対して [ユーザー入力] 条件タイプが表示されている条件定義ページ

このセクションのフィールドの値は、[演算子] フィールドと共に使用され、ステップを実行するかどうかが決まります。

フィールドまたはコントロール

定義

金額レコード

ステップのトリガに必要な最小金額の比較時に使用する、元のトランザクション内の金額が格納されているレコード名を選択します。

金額フィールド

ステップのトリガに必要な最小金額と調達依頼を比較するときに使用する金額レコード内のフィールドを選択します。システムでは、[金額] フィールドを評価するために選択する値が使用されます。

通貨フィールド

[通貨コード] フィールドで選択する通貨コードに対応する通貨フィールドを選択します。

演算子

[金額] フィールドの値の処理方法を指定する演算子を選択します。値には [範囲][>] および [<] などがあります。

金額

[金額] フィールドは、金額範囲を定義するために [演算子] フィールドと一緒に使用します。

最初のフィールドでは、トランザクションでのステップのトリガに必要な最小金額を入力します。[金額レコード] フィールドおよび [金額フィールド] フィールドで定義された条件を満たすトランザクション内の全ての行が特定されます。これらの行の金額は、指定された [金額レコード] および [金額フィールド] に基づいて合計額が算出されます。調達依頼合計額が、この最小金額を超えている場合、条件を満たしています。金額が指定されていない場合、0 が最小金額と見なされます。

注: [演算子][範囲] の値を指定して選択した場合、2 番目の [金額] フィールドがアクティブになります。

通貨コード

承認で使用する通貨単位を選択します。

レート タイプ

現在のレートや財務レートなど、通貨の値の換算方法を選択します。

承認パス定義ページ (EOAW_PATH_SEC) を使用して、ワークフロー承認パスを設定します。

画像: 承認パス定義ページ

次の例では、承認パス定義ページのフィールドおよびコントロールを説明します。このページのフィールドおよびコントロールの定義は後で説明します。

承認パス定義ページ

このページを使用して、承認パスの処理方法を決定する追加のパラメータを設定します。エスカレーション機能を使用して、承認者が承認待ちリクエストの承認または却下に時間をかけすぎている場合の時間的な要素を定義します。

フィールドまたはコントロール

定義

条件

クリックすると、条件定義ページにアクセスし、ユーザーとフィールドの条件、および金額とアプリケーション クラスの条件を定義できます。

承認パス

作成または更新するパス名が表示されます。パスは通常、単一の所属関係階層 (またはその他) から、リクエストの承認の順序を決定します。

ステップ ソース

[静的]: 承認プロセスの実行時に、個々のユーザー定義のステップを使用する場合に選択します。

[動的]: 動的パス定義にはステップが 1 つだけ含まれます。開始時には、単一のステップ定義によって必要な数のインスタンスを順番に生成できます。

ソースに [動的] を使用した場合、ステップ定義にユーザー リストを使用してパス内のステップが初期化されます。ステップのユーザー リストから承認者が戻されなくなるまで、単一のステップ定義が繰り返し実行されます。これらのインスタンスは全て順番にキューに入れられます。

ユーザー リスト定義ページ」を参照してください。

承認者がいない場合管理者に通知 (承認者がいない場合管理者に通知)

選択すると、パスの承認者がいない場合に管理者へ通知が送られます。このオプションは、選択したステップ ソースが [動的] の場合にのみ使用できます。

注: これは、静的パスのデフォルトの処理です。

前の承認依頼ステップを省略

選択すると、このパスの承認者の 1 人が依頼者でもある場合、その承認者のステップより前にあるこのパスのステップを全て省略します。

権限をチェック

このオプションは、選択したステップ ソースが [動的] の場合にのみ使用できます。

オンにすると、既存の条件を省略し、承認者の許可コンポーネントおよび条件定義を使用します。

[権限をチェック] をオンにすると、動的パスの終了ポイントが強制されます。

権限のないユーザーをスキップ

このオプションは、選択したステップ ソースが [動的] の場合にのみ使用できます。

オンにすると、そのトランザクションを承認する資格がない承認者が省略され、承認者がトランザクションを承認する資格があるときに終了します。

たとえば、最初の承認者が 500 未満のトランザクションを承認でき、2 番目の承認者が 5000 未満のトランザクションを承認でき、そのトランザクションが 675 の承認を受けるものだった場合、最初の承認者は省略され、トランザクションは直接 2 番目の承認者に渡ります。2 番目の承認者は適格であるため、これ以上の承認は必要ありません。

タイムアウト オプション

フィールドまたはコントロール

定義

エスカレーション オプション

[事前承認]: 現在の承認者を省略します。[事前承認] では、最後のステージの最後のステップである場合は、ステップは前進しません。

[関係者通知]: 電子メールまたはトランザクション レジストリで定義された通知方法を使用して、関係者に通知します。

[割当変更]: ユーザー ID またはユーザー リストを再割当てします。

注: [事前承認] を選択し、[ユーザー リスト] を定義した場合、通知はユーザー リスト メンバーに送信されます。

時間

エスカレーションが実行されるまでに、トランザクションを 1 つのワークフロー ステップに保持できる時間数を入力します。このフィールドと [日] フィールドの合計により、承認リクエストに対して承認者がアクションを実行するまでの合計時間が決まります。

エスカレーションが実行されるまでに、トランザクションが 1 つのワークフロー ステップで保持できる日数を入力します。これは、トランザクションの承認または却下など、承認者が処理を行わねばならない期限です。

割当変更先

オプションで [割当変更] を選択した場合、ユーザー名または特定のユーザー リストを入力できます。

注: ユーザー リストは、現在のユーザーと一致しないユーザー リストの最初のユーザーを割り当てます。

ユーザー リスト

ワークフローの転送先のユーザー リストを選択します。

代理者の使用

このチェック ボックスをオンにすると、エスカレーションは、現在の承認者 (代理者) の視点から転送される必要があることを示します。このチェック ボックスをオフにすると、エスカレーションは、元の承認者 (委任者) の視点から転送されます。

承認ステップ定義ページ (EOAF_STEP_SEC) を使用して、ワークフロー承認のステップを定義します。

画像: 承認ステップ定義ページ

次の例では、承認ステップ定義ページのフィールドおよびコントロールを説明します。このページのフィールドおよびコントロールの定義は後で説明します。

承認ステップ定義ページ

このページを使用して、ステップ定義の追加パラメータを設定します。

フィールドまたはコントロール

定義

条件

クリックすると、条件定義ページにアクセスし、フィールドの条件、および金額とアプリケーション クラスの条件を定義できます。

自己承認条件

クリックすると、条件定義ページにアクセスし、ユーザーにフィールド条件や金額、アプリケーション クラス条件などの自己承認条件を設定できます。

連番

承認が転送される順番が表示されます。各ステップは通常、承認者への転送を示します。ただし、ステップ内で複数の承認者またはレビュー担当者に転送することも可能です。

承認者リスト

ユーザー リストに基づいて、このステップで使用する承認者のタイプを選択します。

承認者ロール名

ユーザー リストの他に、追加の承認チェックのためのロールを追加できます。ユーザーが持つ権限を指定するロールを選択します。承認フレームワークによって、このロールのためのユーザー リストで返された承認者にフィルタが適用されます。また、承認者がアクションを実行する際に、このロールが強制的に適用されます。承認者がこのロールの適用外になっているなど、ロールの割当てが変更されている場合、この承認者は調達依頼の承認アクションから除外されます。

全ての承認者必須

このステップでのトランザクションに、このステップで全ての承認者による承認が必要な場合に選択します。このステップでのトランザクションの承認には、全ての承認者または一部の承認者を選択できます。

一部の承認者

トランザクションの承認に全ての承認者が必要ない場合に選択します。このオプションを選択する場合は、[必要承認者数] フィールドに必要な承認者の人数を入力します。

注: 人数が満たされた後に、承認は次のステップに進みます。

必要承認者数

このステップで調達依頼を承認する承認者の最小人数を入力します。承認プロセスの開始時にこの人数が満たされない場合は、承認の [管理者ロール名] に通知されます。

自己承認

依頼者が自分の調達依頼を承認可能にする場合に選択します。依頼者がステップの承認者として表示される場合にのみ、この設定が適用されます。[自己承認条件] リンクを使用して、依頼者の承認権限を制約する条件を確立できます。関連する条件が真となった場合、自己承認は許可されます。たとえば、依頼者に金額の上限を設定し、トランザクションがその金額を超過した場合に、その依頼者を承認者として使用不可にできます。

自己承認をオンにし、条件を満たさなかった場合、承認フレームワークは、パス内のこのステップの後に、1 つ以上のステップがあることを要求します。これは、アドホック ステップには適用されません。チェック ボックスの選択を解除すると、自己承認が許可されないことを示します。

注: 条件が満たされず、この後にステップがない場合、システムにより追加のステップが 1 つ挿入されます。その場合、この選択内容が管理者に転送されます。

依頼者へ転送

このチェック ボックスをオンにすると、この承認は依頼者に転送されます。このチェック ボックスをオンにすると、依頼者は常に手動でトランザクションを承認する必要があります。

[依頼者へ転送] は、自己承認フラグと連動して動作します。

承認機能について」を参照してください。

社外承認者

オンにすると、外部承認者が電子メール情報を提供することを示します。この機能は、従業員ポータルに属していないユーザーに通知するために使用します。

注: 外部承認者の通知情報は、トランザクションの設定ページで設定される必要があります。

トランザクションの設定ページ」を参照してください。

依頼者のフィルタ

このチェック ボックスは、[依頼者へ転送] が選択されていないときに表示されます。このチェック ボックスをオンにすると、依頼者のユーザー ID は、発生時に毎回結果セットからフィルタされます。

レビュー担当者リスト

このステップで使用するレビュー担当者のタイプを選択します。特定の職種のロールにユーザーをマッピングするユーザー リストを使用します。このリストとリスト内のユーザーに基づいて、自動ビジネス プロセスが実行されます。このリストでは、承認および評価ステップで使用可能なユーザー ソースが定義されています。

承認機能について」を参照してください。

『PeopleTools: Workflow Technology』の製品ドキュメントを参照してください。