承認ワークフロー（BPM・承認ルール・通知）

Fusion の承認は、業務ごとの 承認タスク に ルールセット → ルール（条件＋承認者の決め方） を持たせる共通の仕組みで動きます。AP 請求書・GL 仕訳・購買・経費・受注は、承認を始める操作や設定の入口が違っても、考え方は同じです
承認者は リスト・ビルダー（Supervisory・Job Level・Position・Approval Group・Resource）で決めます。上司階層・ジョブ・レベル・職位は人事（HCM）のデータに依存するので、ルールを書く前にそのデータを整えます
BPM Worklist でのルール編集は、Save しただけでは有効になりません。Commit Task で有効にします。1 つのルールセットの中では、1 件の取引が成立させるルールが 1 つだけになるように、条件を重ならせず漏れなく作ります
日本の稟議・職務権限規程は、「対象＋条件（金額・費目）＋承認者（役職）＋経路（直列・並列・回覧）」の表に起こしてからルールに写します。専決は金額帯ごとのルール、代決は委任、合議は並列と承認グループ、回覧は FYI 通知で表します
通知（メール・ワークリスト）は承認を動かす手段であり、承認が止まる原因にもなります。テスト環境では通知の宛先を集約し、本番へ移した後は承認の設定と通知を必ず画面で確認します

BPM Worklist の操作とリスト・ビルダーの項目は、公式ガイド Implementing Expenses（26B）の How You Define Approval Rules で確認した内容を基準にしています。AP・GL・調達・受注も共通の仕組みを使いますが、タスク名・画面名・選べる項目はモジュールとリリースで異なるため、設定のときは各モジュールの公式ガイドで確認してください
委任・差戻しなどのタスク操作や投票は、Oracle BPM の汎用ガイド（12.2.1.4）の説明です。Fusion の標準タスクで使えるかは、タスクの構成と権限によります
調達の承認（AMS）の設定画面名、モバイルでの承認、財務（AP・GL・経費）の承認画面の Redwood 対応は、公式で確認できた範囲だけを書いています。未確認の項目には「要確認」と書いています

全体像

承認は、取引の提出をきっかけに「誰が承認するか」をルールで決め、その人に通知して応答を待ち、結果を業務側に返す仕組みです。業務ごとに別の機能があるわけではなく、Oracle BPM 上の 承認タスク として、共通の部品で動きます。経費の公式ガイドは、承認ルールを Approval Management Extensions（AMX）で作ると説明しています。調達のガイドは、Oracle Approval Management Service（AMS）という名前でまとめています。

承認の部品

用語	意味	例
承認タスク（Task）	承認 1 種類に対応する BPM のタスク	経費精算書の承認は `FinExmWorkflowExpenseApproval`
ステージ（Stage）	承認の段階。ルールセットはステージに対して直列または並列に動く	Expense Report Approval Stage
ルールセット（Rule set）	1 つ以上のルールの集まり。参加者のリストを 1 つ作る	金額による承認、経理の合議
ルール（Rule）	条件（IF）と、承認者の決め方（THEN）の組	精算書の合計が 1000 を超えたら上司 1 段
条件（Condition）	取引の属性による絞り込み。1 つのルールに複数付けられる	`ExpenseReport.expenseReportTotal`
参加者（Participant）	ルールセットが決めた承認者のリスト	部長、経理部の承認グループ
リスト・ビルダー（List builder）	参加者のリストの作り方	Supervisory、Job Level など
応答タイプ（Response type）	応答を求める（Required）か、知らせるだけ（FYI）か	決裁は Required、回覧は FYI

処理の流れ

提出（起票者）
  → 承認タスクが始まり、ルールセットが条件を評価する
  → ルールに従って参加者（承認者）のリストを作る
  → 参加者へ通知する（メール・ワークリスト）
  → 承認者が応答する（直列なら順番に、並列なら同時に）
  → 結果が業務側に返り、取引のステータスが変わる
参加者を決められない場合：失敗通知（インシデント ID つき）が届き、承認は止まる

承認を「始める」操作は業務ごとに違います。AP 請求書は Initiate、GL 仕訳は Request Approval、購買依頼や PO は提出、受注は Submit です。始めたあとの流れは共通です
承認の有効化と、承認ルールの設定は別々です。AP・GL・受注のように、業務側のオプションで「承認を使う」と決めてから、ルールで「誰が承認するか」を決める業務があります

どこで何を設定するか

入口	設定すること	例	備考
業務側のオプション	承認を使うか、いつ回すか	AP：Manage Invoice Options の Enable invoice approval。GL：元帳オプションの Enable journal approval と仕訳ソース。受注：パラメータ Start Approval Process for Sales Orders	承認ルールそのものではない。画面は業務ごとに別
BPM Worklist のタスク構成	ルールセット、ルール、リスト・ビルダー	GL：Setup and Maintenance の Manage Task Configurations for Financials から開く。経費：`FinExmWorkflowExpenseApproval` を編集	Save のあと Commit Task で有効になる
スプレッドシート	ルールの作成・変更	AP：Create／Manage／Modify Workflow Rules Using a Spreadsheet	ADFdi を使う（ADFdi）。使える業務は限られる（要確認）
調達の承認管理	割当とルーティング、期限・有効期限のポリシー	Implementing Procurement の Approval Management for Procurement の章	画面と用語は調達のガイドに従う

業務ごとの違い

承認の仕組みは共通でも、承認を始める操作、ルールの置き場所、既定のルールは業務ごとに違います。設定のポイントは「設定・実装の手順」の業務別の節にまとめています。

業務	承認が始まるきっかけ	ルールの置き場所	既定の承認者
AP 請求書	Initiate、または Initiate Invoice Approval Workflow の定期実行	Manage Invoice Options で有効化。ルールはスプレッドシートか BPM のタスク構成	1000 以上は依頼者の直属上司、1000 未満は自動承認
GL 仕訳	Request Approval。転記や AutoPost でも、承認が必要なら先に承認へ回る	元帳オプションと仕訳ソースで有効化。ルールは BPM Worklist	提出者の上司 1 名
調達（購買依頼・PO など）	購買依頼・PO の提出。自動作成した PO は、契約の設定で自動提出もできる	Approval Management for Procurement（AMS）	ルール次第。監督階層、職位・ジョブ・レベルの階層、承認者リスト（既定は要確認）
経費	経費精算書の提出	AMX の承認ルール（`FinExmWorkflowExpenseApproval`）。監査ルールは別	事前定義のルールセットが 9 つある（名称は公式ガイドに記載なし）
受注	受注の提出。Start Approval Process for Sales Orders が Yes なら、ルールがなくても承認処理を経由する	承認ルールと承認タスク（Set Up Approval Rules／Tasks for Sales Orders）	ルール次第（既定は要確認）

BPM Worklist（ワークリスト）

BPM Worklist は、承認者がタスクを受け取る画面であり、管理者が承認ルールを編集する画面でもあります。

承認者：承認依頼は、メール通知、ホームページの通知、ワークリスト（Worklist）に届きます。承認者はそこから承認・却下などで応答します。AP 請求書は、メール通知・ワークリスト・請求書画面のどれからでも応答できます
タスク操作：BPM の汎用ガイドが挙げるタスク操作は、承認・却下のほかに、委任（Delegate）、再割当（Reassign）、情報の依頼（Request for Information）、差戻し（Pushback）、エスカレーション（Escalate）、取下げ（Withdraw）、アドホックな参加者の追加（Adhoc Insertions）です。Fusion の各業務でどれが使えるかは、タスクの構成と権限で決まるため、導入前に画面で確認します（要確認）
起票者：進行中の承認を取り下げられます。AP 請求書は Withdraw で Initiated から Withdrawn に、GL 仕訳は Withdraw Approval で Incomplete に戻ります
管理者：BPM Worklist の管理画面（Administration）で、承認タスクのルールを編集します。手順は「設定・実装の手順」を参照してください

Redwood の承認画面と通知

Redwood は、ページの見た目と操作を新しい UX に置き換える取り組みです（Redwood UX と AI・自動化機能）。確認できた範囲では、承認の通知や承認の画面を Redwood スタイルにする機能が、分野ごとに順に提供されています。承認ルールの構成方法が変わるとは、確認した資料では説明されていません。

機能	分野	リリース	確認できた内容
Redwood: Use and Configure Redwood-Style Requisition Approval FYI Notifications	購買依頼（Self Service Procurement）	25B	Approved、Rejected、Returned by Buyer、Withdrawn、Reassigned、Canceled の 6 種類の FYI 通知を、メールとワークリストで Redwood スタイルにする。Procurement オファリングの Opt In UI で有効にする
Redwood: Use Redwood-Style Approval and Review Notifications	製品ライフサイクル管理（PLM）	25A	機能名のみ確認
Redwood: Use Redwood Template for ERES Approval Notifications and Approve Using Deferred Mode	在庫管理（Inventory）	25C	機能名のみ確認
Redwood: Approve Physical Inventory Adjustments Using a Redwood Page	在庫管理（Inventory）	25A	Redwood ページで承認する機能（機能名のみ確認）
Approve Count Sequences Using a Redwood Page	在庫管理（Inventory）	24C	Redwood ページで承認する機能（機能名のみ確認）
Redwood: Compare and Approve Policy Values Using a New User Experience	需要管理（Demand Management）	26A	比較して承認する新しい画面（機能名のみ確認）
Redwood: Use Approvals for Receipts	受入（ホワイトペーパー）	－	タイトルのみ確認

導入のときは、次の点を確認します。

有効化の方法：購買依頼の FYI 通知は、Procurement オファリングの Opt In UI で有効にします。機能ごとに、オプトインか既定で有効か、期限があるかが違います。Readiness の What’s New と Opt In Expiration で確認します
通知のカスタマイズ：購買依頼の FYI 通知は、Analytics Publisher のテンプレートで変えます。従来の通知テンプレートを自社用に変えている場合、Redwood スタイルに切り替えたときの扱いは確認できていません（要確認）
権限：購買依頼の FYI 通知を使う利用者は、Manage Requisition（POR_MANAGE_REQUISITION_PRIV_OBI）を含むジョブロールが必要です。通知テンプレートを編集する管理者は、BI Author Role を含むジョブロールが必要です
予算管理との関係：Budgetary Control を有効にしていると、承認された購買依頼でも資金がなければ拒否（Rejected）の状態になります。Rejected の FYI 通知は、拒否された依頼の作成者（Preparer）に送られます
財務の承認：AP・GL・経費の承認通知や承認画面が Redwood スタイルになっているかは、確認できていません（要確認）。四半期ごとの What’s New で、承認と通知の項目を検索します

設定・実装の手順

承認は、次の順に導入します。

稟議・職務権限規程を、ルールの表に起こします
HCM のデータ（上司・ジョブ・職位）と承認グループを整えます
業務側のオプションで、承認を有効にします
BPM Worklist などでルールを作り、Commit Task で有効にします
通知を設定し、テスト環境で承認と通知を確認します
本番へ移した後に、承認ルールと通知を画面で確認します

規程を表に起こす（稟議・職務権限規程との対応づけ）

日本の稟議は、「起案、関係部署の合議、決裁権限者の決裁、回覧と保管」という流れで進みます。職務権限規程は、何を、いくらまで、誰が決裁できるかを表にしたものです。Fusion の承認は、この規程を「条件」と「承認者の決め方」に分解して写します。そのまま置ける要素と、運用で補う要素があります。

規程の要素	Fusion での表し方	設計上の注意
金額別の決裁基準（例：100 万円以上は部長決裁）	金額の条件＋ Job Level または Position	金額帯は重ならず、漏れなく作る。税込・税抜、通貨の基準は、ルールで使う属性と規程を合わせる
直属の上長による承認	Supervisory（Number of Levels）	HCM の上司階層が最新であること
役職・職位で決まる決裁権限	Position（職位階層）または Job Level	職位階層は Global HR で先に定義する。役職とジョブ・レベルの対応表を作る
専決（規程で下位者に決裁を委ねる）	金額帯ごとにルールを分け、最終承認者を下位の役職にする（Number of Levels、Top Participant）	専決の上限額を規程と一致させる
代決（不在時の代理決裁）	委任（Delegate）、再割当（Reassign）	代決の範囲と記録は運用規程で定める。Position のリスト・ビルダーでは使えない操作がある（要確認）
合議（関係部署の合意）	並列のルールセット＋ Approval Group（Required）	全員の同意が必要かを決める。「N 人中 M 人」の投票が標準で使えるかは要確認
回覧・報告	FYI 通知	応答は不要。確認した記録が必要なら承認にする
経理・予算部署の審査	Approval Group を直列で追加	上長の前に審査するか後にするかを決める
起案者と決裁者の分離	Skip creator for Approval List（GL の例）、職務分掌（SoD）	起案者が承認者の階層に入らないようにする（セキュリティ設計）
稟議番号	DFF に社内稟議番号を持たせる	稟議書の本体が別システムなら、番号で紐付ける（フレックスフィールドと値セット）

規程は、対象・条件・承認者・経路・根拠を 1 行 1 ルールで書いた設計シートにします。購買依頼を例にした設計シートは「コード例」にあります。

規程と HCM のデータのずれも、先に洗い出します。

規程の役職名（部長・本部長）と、HCM のジョブ、ジョブ・レベル、職位の対応表を作ります
兼務、出向、組織長の欠員、事務取扱の扱いを決めます。上司階層をどう持つかに影響します
上司が退職・異動したときの更新手順と責任者を決めます
HCM を導入しない ERP のみの導入でも、人レコードと上司の情報が必要です。上司の登録方法は要確認です。人レコードの考え方はセキュリティの基本の「ERP のみ導入時のユーザー管理の考え方」を参照してください

BPM Worklist でルールを編集する

承認ルールは、BPM Worklist の管理画面で編集します。経費承認の公式ガイドの手順は次のとおりです。

BPM Worklist の管理者としてサインインします。公式ガイドの例は財務アプリケーション管理者です
BPM Worklist の Administration を開き、Task Configuration タブ > Data Driven タブの順に選んで、Data driven configuration ページを表示します
Tasks to be configured ペインで、対象のタスクを選びます。経費精算書なら FinExmWorkflowExpenseApproval です
Edit アイコンを押し、ルールセットのルールを追加・変更・削除します
THEN 領域でリスト・ビルダーを選び、Create Action を押します。Add Variable ダイアログでパラメータを入力します
Save アイコンで保存します。この時点では有効になりません
Commit Task アイコンで有効にします。変更を取り消すときは Reset アイコンを使います
ルールセットを無効にしたいときは、Ignore this participant を選びます

GL では、Setup and Maintenance で Financials オファリング > Application Extensions 機能領域 > Manage Task Configurations for Financials タスクから開きます。他の業務のタスク名は、各モジュールのガイドで確認してください。タブやアイコンの名前は、リリースで変わることがあります。

条件（IF）

条件は、取引の属性で作ります。1 つのルールに複数の条件を付けられますが、入れ子の条件（ネスト）は使えません
経費では、Condition Browser に ExpenseReport（精算書の合計・提出日・組織など）、ExpenseItem（領収書金額・費用タイプ・方針違反や領収書なしのフラグなど）、CostCenterTotal（原価センターごとの合計）、ProjectTotal（プロジェクトごとの合計）のビュー・オブジェクトが並びます
GL では、バッチ内で最大の仕訳明細金額、最大の仕訳金額、決算ステージ、元帳・バッチ・ヘッダー・明細の属性（カテゴリ、ソース、勘定、DFF など）を使えます（仕訳）
調達では、文書の属性（金額・カテゴリ・契約条項の有無など）を使います（購買）

承認者の決め方（THEN）：リスト・ビルダー

経費承認の公式ガイドで確認できたリスト・ビルダーは次の 5 種類です。

リスト・ビルダー	承認者の決まり方	主なパラメータ	使いどころ
Supervisory	HCM の主たる上司階層を、提出者（または指定の承認者）から上へたどる	Number of Levels、Starting Participant、Top Participant、Auto Action Enabled、Auto Action	課長、その上の部長のように、直属上司を N 段ぶん
Job Level	上司階層をたどり、必要なジョブ・レベルの承認者が見つかるまで上がる	Number of Levels、Relative to、Include all managers at last level、Utilized Participants など	金額が大きいほど上位のジョブ・レベルまで
Position	職位階層を、承認者の職位から上へたどる	Number of Levels、Relative to、Starting Participant、Top Participant など	役職（職位）で決裁権限が決まる規程
Approval Group	BPM Worklist で作った承認者のグループ	承認グループ名	経理・法務・購買などの合議や確認
Resource	ユーザー名、グループ、アプリケーション・ロールの一覧（固定値または関数で指定）	Participants	特定の個人やロールを固定したいとき

BPM の汎用ガイドには、Names and Expressions、Management Chain、Rule-based というリスト・ビルダーも載っています。Fusion の標準タスクのルール画面で選べるかは、モジュールのガイドで確認してください（経費では上の 5 種類を確認しています）
Supervisory と Job Level は、HCM の上司階層が前提です。上司がいない、ジョブ・レベルに届かないなどで承認者を決められないと、失敗通知が届きます
Position を使うには、先に Global Human Resources で職位階層を定義します。BPM の汎用ガイドでは、Position のリスト・ビルダーは Reassign・Delegate・Escalate・Adhoc Insertions を許可しません（Fusion での扱いは要確認）

リスト・ビルダーのパラメータ

パラメータ	意味
Number of Levels	段数の指定。正の数で入れる（1 なら 1 段）。Job Level では At least／At most で下限・上限を指定する（BPM の汎用ガイド）
Relative to	Number of Levels の基準。Starting Point、Creator、Absolute から選ぶ。公式ガイドの例は At most 2 relative to Starting Point。詳しい意味は画面とガイドで確認する（要確認）
Starting Participant	リストの先頭にする参加者
Top Participant	リストの最後にする参加者。それより上へは上がらない
Include all managers at last level	最後に求めたジョブ・レベルと同じなら、次の上司も含める
Utilized Participants	使う参加者。Everyone、First and Last Manager、Last Manager から選ぶ
Auto Action Enabled／Auto Action	自動で応答する設定。経費の承認では Auto Action に Approve を使う

Starting Participant と Top Participant には、式を入れます。公式ガイドの式の例は「コード例」に載せています。

応答タイプとルーティング

Required：承認者が応答する必要があります。FYI：知らせるだけで、応答は不要です
直列（Serial）は参加者へ順番に通知し、並列（Parallel）は同時に通知します。ルールセットも、ステージに対して直列または並列に動かせます。BPM の汎用ガイドは、単一（Single）・並列・直列・FYI のパターンを挙げています
投票（Voting）は、汎用ガイドでは繰り返しステージの設定として説明されています。Fusion の標準タスクのルール画面で選べるかは確認できていません（要確認）

評価の規則と制約

1 つのルールセットで、1 件の取引が成立させられるルールは 1 つです。1 つも成立しない場合、承認はエラーになり、インシデントが記録されます（経費の公式ガイド）
条件が重なるときは、最も細かい粒度でルールを定義し、優先度（Priority）で整理します。BPM の汎用ガイドでは、複数のルールが成立すると優先度が最も高いものが選ばれ、優先度が同じなら選ばれる順が不定です
入れ子の条件は使えません
条件に漏れのあるルールセット（ルールが 0 件、どの条件にも当てはまらない）は、実行時エラーの原因になります（BPM の汎用ガイドの警告）
承認者を決められない場合は、ユーザーに失敗通知が届きます。インシデントの確認と承認の再開は、公式ガイドでは Enterprise Manager の Support Workbench と説明されています。SaaS でお客様が直接操作できるかは要確認なので、インシデント ID を控えてサービス・リクエスト（SR）に添えるのが確実です

承認グループを作る

承認グループ（Approval Group）は、承認者の集まりに名前を付けたものです。ルールからは Approval Group のリスト・ビルダーで名前を指定します。

作成：BPM Worklist で作ります。経費の公式ガイドは、静的な承認グループを BPM Worklist で作り、Approval Group のリスト・ビルダーで使うと説明しています。ルールで選ぶ前に、グループが存在している必要があります
静的と動的：静的グループは決まった承認者の一覧です。動的グループは実行時に承認者を作り、BPM の汎用ガイドでは開発者が用意した実装の登録が必要とされています。SaaS でお客様が使えるかは要確認で、通常は静的グループを使います
空のグループ：BPM の汎用ガイドに、メンバーが 0 人のグループを許すかを決める Allow Empty Groups のパラメータがあります。異動や退職でメンバーが空になると承認が止まるので、許すかどうかを設計で決めます
メンバーの指定方法：公式の資料では詳細を確認できていません。BPM Worklist の画面で確認してください（要確認）

使いどころは、専門部署による確認です。

経理の審査（予算・勘定科目の確認）
法務の確認（標準外の契約条項）
購買部門の確認（調達方針との適合）
情報システム部の確認（IT 機器・ソフトウェアの購入）

個人ではなく役割で持てば、人事異動に強くなります。グループの名前は「業務＋目的＋部署」のように決め、メンバーを更新する責任者と手順も決めておきます。

通知を設計する

種類：応答を求める Required の通知と、知らせるだけの FYI の通知があります
届き方：メールとワークリストが基本です。BPM の汎用ガイドは、AMX がメールとインスタント・メッセージ（IM）の通知に対応すると書いています。Fusion の各業務で IM が使えるかは要確認です
モバイル：モバイルでの承認の可否と対象は、リリースやアプリで異なります。公式で確認できていないため、この章では扱いません（要確認）
失敗通知：承認者を決められないと、ユーザーに失敗通知（インシデント ID つき）が届きます

通知の文面を変える方法は、業務ごとに違います。確認できた例は、25B の Redwood スタイルの購買依頼承認 FYI 通知です。メールとワークリストの通知の内容を、Oracle Analytics Publisher のテンプレートで変えます。

Analytics Publisher の Catalog タブで、Shared Folders > Procurement > Self Service Procurement のテンプレートを探します（Requisition Approval Status FYI Notification Report など）
More > Customize を選びます。Shared Folders > Custom > Procurement > Self Service Procurement にコピーが作られます
コピーを開いて編集し、インスタンスのロケールを選んでアップロードします

テンプレートのデータモデルは Requisition Approval E-Mail Data Model です。編集する管理者には、BI Author Role（BIAuthor）を含むジョブロールが必要です。他の業務の通知の変更方法は、各モジュールのガイドで確認してください。

テスト環境では、通知の宛先に注意します。

本番からテストへのリフレッシュで、本番の取引先・従業員のメールアドレスがテストに入ります。ワークフロー通知は、BPM Worklist の Test Notification Email Address に集約するか、BPM のワークフロー管理者が通知を停止します
ホームページの通知（承認依頼を含む）はリフレッシュでコピーされません。承認のテストは、新しく起票した取引で行います
詳細は環境管理・四半期アップデート・テストを参照してください

AP 請求書の承認

有効化：請求書オプション（Manage Invoice Options）で Enable invoice approval を有効にします。Require validation before approval、Accounting preference、Allow force approval もここで決めます
既定のルール：1000 以上は依頼者の直属上司、1000 未満は自動承認です。承認しない範囲を「自動承認」のルールとして表している点は、自社のルールを作るときの手本になります
開始：請求書ごとの Initiate、または Initiate Invoice Approval Workflow の定期実行です。取込分は後者でまとめて開始します
操作：Withdraw、Hold、Force Approve、Resubmit があります。Force Approve には、Force Approve Payables Invoice 権限と Allow force approval の両方が必要です。詳細は請求書を参照してください
稟議との接点：請求書ヘッダーに「社内稟議番号」を DFF で持たせる例はフレックスフィールドと値セットにあります

GL 仕訳の承認

有効化は 2 か所です。元帳オプション（Enable journal approval）と仕訳ソースの両方で有効にします。サブレジャーの仕訳ソースでは有効にしません。承認待ちで滞留するためで、承認はサブレジャー側で行います
条件：バッチ内で最大の仕訳明細金額、最大の仕訳金額、決算ステージ、元帳・バッチ・ヘッダー・明細の属性を使えます。承認はバッチ全体に適用されます
運用：提出者本人の承認を防ぐには、Skip creator for Approval List を選びます。提出者は Withdraw Approval で取り下げられ、仕訳は Incomplete に戻ります。承認済みで未転記の仕訳を修正すると、再承認が必要です
対象外：配賦仕訳と定期仕訳は承認に回りません。統制が必要なら、ルールの変更権限とレビュー手順で担保します。詳細は仕訳を参照してください

調達の承認（購買依頼・PO・仕入先）

対象：Implementing Procurement の Approval Management for Procurement の章は、ソーシング、購買依頼と購買文書、仕入先、外部購入価格の承認を扱います
設定項目：割当とルーティング、期限と有効期限のポリシー、電子署名、トランザクション・コンソール、監視とトラブルシューティング、ワークフロー通知（E メール通知の構成を含む）が章にまとまっています
購買依頼 BU のオプション：Reapproval required for changes made during an active approval process、Approval required for buyer modified lines、Enable approval override（Overriding Approver）が承認の動作に関わります
自動作成した PO：契約の Automatically submit for approval で承認に自動提出できます。承認を省略（バイパス）する設定もあります。PO インポートの Approval Action は、Do Not Approve、Submit for Approval、Bypass Approval から選びます
変更：承認済みの文書は変更オーダーで変更します。処理が終わるまでは、承認済みの現行版が有効です
確認：承認が止まっているときは、トランザクション・コンソールで状況を見ます。構成パッケージで承認の設定を移送した後は、承認ルールを画面で確認します。詳細は購買、セルフサービス調達、調達の共通設定を参照してください

経費の承認

ルール：経費精算書の承認ルールは AMX で作ります。タスクは FinExmWorkflowExpenseApproval で、事前定義のルールセットが 9 つあります
承認と監査は別です：監査対象の精算書は経費監査担当が確認します。監査ルールを 1 つも選ばないと、すべての精算書が自動承認されます
仮払金：上長、経費監査担当の順に承認します。代理入力（Delegations）向けの承認ルールも設定できます
詳細は経費を参照してください

受注の承認

承認ルーティングはパラメータ Start Approval Process for Sales Orders で制御します。Yes にすると、承認ルールがなくても承認処理を経由します（受注は一時的に Approval Pending）。No にすると、承認ルールが有効でも承認ルーティングを行いません
与信チェックの承認は別の仕組みです。Receivables が与信依頼ごとにケースフォルダを作り、与信担当者が Credit Reviews ページで承認・却下します
詳細は受注入力・受注インポートを参照してください

プロジェクトや資産など、ほかの業務の承認はこの章では扱いません。考え方は同じですが、タスク名と画面は各ガイドで確認してください。

コード例

承認ルールの設計シート

購買依頼を例にした設計シートです。サンプル商事株式会社の JP01 営業単位を想定した架空の規程で、実在の規程や標準の既定値ではありません。購買依頼のルールで使える条件と画面は、調達のガイドで確認してください。

ルールセット,ルール,条件,承認者の決め方,応答,規程の根拠
金額による承認,R1,金額が 50 万円未満,Supervisory（Number of Levels = 1）で依頼者の上長,Required,別表 1：課長専決
金額による承認,R2,50 万円以上 500 万円未満,Job Level（部長級）まで上がる,Required,別表 1：部長決裁
金額による承認,R3,500 万円以上,Position（本部長）まで上がる,Required,別表 1：本部長決裁
経理の合議,R4,金額が 500 万円以上,Approval Group「経理部 合議」,Required（並列）,別表 2：合議
IT 機器の確認,R5,カテゴリが IT 機器,Approval Group「情報システム部 確認」,Required,別表 2：合議
購買部への回覧,R6,すべて,Approval Group「購買部 回覧」,FYI,運用規程：回覧

「金額による承認」の R1〜R3 は、金額帯が重ならず漏れません。境界は「以上」と「未満」で決め、50 万円ちょうどは R2、500 万円ちょうどは R3 です
経理の合議、IT 機器の確認、回覧は、金額による承認とは別の観点で成立するので、別のルールセットに置きます。同じルールセットに入れると、1 件の取引が複数のルールを成立させるためです
承認の経路（直列か並列か）はルールセットごとに決めます。この例では、経理の合議だけ並列にします

Starting Participant／Top Participant の式

公式ガイドの経費承認の例です。

Supervisory の開始    HierarchyBuilder.getManager("supervisory",Task.creator,-1,"","")
Supervisory の最上位  HierarchyBuilder.getPrincipal("<>",-1,"","")
Job Level の開始      HierarchyBuilder.getManager("joblevel",task.creator,-1,"","")

<> は公式ガイドの記載のままです。最上位にしたいユーザーを指定する位置と考えられますが、入力の仕方は画面で確認してください（要確認）。公式ガイドの Position の最上位の例は、かっこが 1 つ足りず、そのままでは使えません。

承認テストのシナリオ表

境界値、階層の端、経路、取下げと再提出、通知を、表にして確認します。上の設計シートに対応した例です。

No,観点,操作,期待する結果
1,境界値,"金額 499999 円の購買依頼を提出",設計シートの R1 の承認者（依頼者の上長）だけに通知が届く
2,境界値,"金額 500000 円の購買依頼を提出",R2 の承認者に通知が届く（R1 の承認者だけでは完了しない）
3,境界値,"金額 5000000 円の購買依頼を提出",R3 の承認者と、経理部 合議のメンバーに通知が届く
4,階層の端,"最上位の役職の人が提出",設計で決めた動作になる（承認者が決まる、または失敗通知が届く）
5,階層の端,"上司が未登録の人が提出",失敗通知が届き、インシデント ID を確認できる
6,経路,"経理部 合議のメンバーが先に承認",金額による承認が残っていれば完了しない（設計どおりか確認する）
7,取下げ,"承認中に提出者が取り下げる",承認依頼が取り消される
8,再承認,"承認中に承認者が内容を修正",再承認が必要かを、購買依頼 BU のオプションの設定と照合する
9,通知,"テスト環境で提出",通知が集約先のアドレスに届く（本番の承認者には届かない）

落とし穴とベストプラクティス

ルールを Save しただけで Commit Task を忘れ、変更が反映されない
金額帯が重なる、または漏れる。1 件が複数のルールを成立させるか、どれも成立せずエラーになる
Position のリスト・ビルダーを使うのに、Global HR に職位階層がない
承認グループを作る前に、ルールで指定しようとする
上司が未登録、退職者が承認者のまま。承認者を決められず、失敗通知が届く
GL で、サブレジャーの仕訳ソースの承認を有効にして、仕訳が承認待ちで滞留する
AP で、承認を有効にしたのに Initiate Invoice Approval Workflow をスケジュールしない
受注で、Start Approval Process for Sales Orders の Yes と No を取り違える
テスト環境で通知を集約せず、本番の承認者にメールが届く
本番へ移した後に、承認ルールと通知を確認しない。承認依頼の通知はリフレッシュでコピーされない
個人名で承認者を固定し、人事異動で承認が止まる

設計の原則

規程を先に表にします。設計シートのように、対象・条件・承認者・経路・根拠を 1 行 1 ルールで書きます
ルールセットは目的で分けます。金額、専門部署の確認、回覧を別のルールセットにし、1 つのルールセットの中のルールは、互いに排他的にします
金額帯は漏れなく作ります。境界値を「以上」「未満」で決め、承認しない範囲も、AP の既定ルールのように「自動承認」のルールで表します
承認者を個人名で固定しません。上司階層、職位、承認グループで指定し、人事異動でルールを書き換えなくて済むようにします
HCM のデータを先に整えます。上司、ジョブ・レベル、職位階層が正しくないと、承認者を決められません
承認グループを先に作り、責任者を決めます。メンバーを更新する担当と手順も決めます
起票者本人が承認者にならないようにします。Skip creator for Approval List などの設定と、職務分掌（SoD）の設計を組み合わせます
ルールの変更権限を統制します。ルールを変えられる人は、決裁権限を変えられます。変更は非本番で作って確認し、移送後は本番で画面を確認します。承認ルールを構成パッケージで移送できるか、手作業で再設定するかは、タスクごとに異なります（要確認）
期限と無応答の扱いを決めます。調達は「期限と有効期限のポリシー」を設定できます。他の業務で設定できるかは要確認です

止まったときの確認先

症状	確認すること	確認先
承認依頼のメールが届かない	承認者のメールアドレス。テスト環境で宛先が集約されていないか。BPM のワークフロー管理者が通知を停止していないか	承認者の人レコード、BPM Worklist（Test Notification Email Address）
承認が始まらない	AP は Initiate を実行したか、Initiate Invoice Approval Workflow をスケジュールしたか。GL はサブレジャーのソースで承認を有効にしていないか	業務側のオプション、スケジュール済プロセス
失敗通知が届く	上司階層、ジョブ・レベル、職位階層、承認グループが揃っているか	HCM のデータ、承認グループ、ルール
承認者が不在・退職	委任や再割当で別の人に回せるか。ルールの承認者が個人名で固定されていないか	ワークリスト、ルール
購買の承認が止まる	承認の状況（トランザクション・コンソールで確認）。期限と有効期限のポリシー	調達（Transaction Console）

試験対策ポイント

対応分野：GL 模擬テスト（仕訳承認）、AP 模擬テスト（請求書承認・経費の監査）、調達模擬テスト（承認の提出・PO のインポート）、OM 模擬テスト（受注の承認）
共通の用語：BPM Worklist、ルールセットとルール、リスト・ビルダー（Supervisory・Job Level・Position・Approval Group・Resource）、Required と FYI、Save と Commit Task
GL：元帳オプションと仕訳ソースの両方で有効化、サブレジャーのソースでは有効にしない、承認はバッチ全体、配賦仕訳は承認に回らない、Job Level は上司階層をたどって必要なジョブ・レベルで止まる
AP：Force Approve には権限（Force Approve Payables Invoice）と Allow force approval の両方が必要、Initiate と Initiate Invoice Approval Workflow、Resubmit。経費は監査ルールが 0 件なら全件自動承認
調達：契約の Automatically submit for approval、PO インポートの Approval Action（Do Not Approve・Submit for Approval・Bypass Approval）、変更オーダー中も承認済みの現行版が有効
OM：Start Approval Process for Sales Orders の Yes と No の違い