オーケストレーション（プロセス定義・フルフィルメント）

この章の結論

• オーケストレーション・プロセスは、受注明細のフルフィルメントを自動化する「ステップの並び」です。各ステップはサービス（Create Scheduling、Create Shipping など）を呼び、フルフィルメント・システムに仕事を依頼します。
• 事前定義プロセスは 4 つ（ShipOrderGenericProcess、ReturnOrderGenericProcess、OrderFulfillmentGenericProcess、DOO_ScheduleShipInvoice）。直接変更せず、コピーして修正します。
• 設定順は「タスクタイプ → プロセス → 変更のビジネスルール → 計画 → ジェパディ → ステータス → デプロイ」。デプロイ後に割当ルールで明細にプロセスを割り当てます。
• 処理中の受注にはプロセスの変更が効きません。新しい処理を適用するには、受注を取り消して再インポートします。
• ドロップシップとバック・ツー・バックは OrderFulfillmentGenericProcess の分岐で処理し、Procurement・Supply Chain Orchestration・Financial Orchestration と連携します。

全体像

オーケストレーションは次の要素で構成されます。

要素	内容	設定タスク
オーケストレーション・プロセス	ステップの並び。ステップ番号順（例：100 → 600）に実行	Manage Orchestration Process Definitions
ステップ	1 つのサービスを呼ぶ処理単位。依存関係（分岐）、計画（リードタイム）、変更時の動作を持つ	同上
タスクタイプ／サービス	Schedule、Reservation、Shipment、Invoice などの仕事の種類と、それを実行するサービス	Manage Task Types
タスク・サービス	フルフィルメント・システムからの応答や更新を解釈する	—
割当ルール	どの明細にどのプロセスを使うか	Manage Orchestration Process Assignment Rules
ステータス	タスク・明細・プロセスのステータスと条件	Manage Status Values、Manage Task Status Conditions

事前定義の ShipOrderGenericProcess のステップは次のとおりです。

ステップ	サービス	内容
100 Schedule	Create Scheduling	納期を満たすスケジュールを GOP で作成
200 Create Reservation	Create Inventory Reservation	在庫を引当（予約）
300 Create Shipment Request	Create Shipping	出荷依頼を作成
400 Wait for Shipment Advice	Wait for Shipment	出荷確認を待つ
500 Create Invoice	Create Billing Lines	AR 向けの請求明細を作成
600 Wait for Invoice	Wait for Billing	AR での請求完了を待つ

事前定義プロセス

プロセス	含まれる主な処理	用途
ShipOrderGenericProcess	スケジュール、引当、出荷、請求	在庫からの通常出荷
ReturnOrderGenericProcess	返品受入、請求（クレジットメモ）	返品
OrderFulfillmentGenericProcess	条件付きスケジュール、供給の要求、一時停止、バック・ツー・バック／ドロップシップ／倉庫出荷の分岐、請求	ドロップシップ・バック・ツー・バックを含む受注
DOO_ScheduleShipInvoice	スケジュール、出荷、請求	大量の受注の処理

設定・実装の手順

公式ガイドの順序で設定します。ナビゲーションは「Setup and Maintenance > Order Management オファリング > 機能領域 Orders」です。

1. タスクタイプ（Manage Task Types）：独自の業務ステップが必要なら独自タスクタイプを作ります。各タスクタイプはフルフィルメント・システムと通信するサービスを参照します。
2. プロセスの作成（Manage Orchestration Process Definitions）：事前定義プロセスをコピーして修正します。コピー前にコピー元を検証し、エラーを解消しておきます。
3. 変更受注のビジネスルール：変更が起きたときに各ステップで何をするかを決めます（後述の変更管理）。
4. スケジュールと計画（26D 以降は計画機能が利用不可。上記の注意を参照）：ステップごとの既定リードタイム、条件付きのリードタイム（ビジネスルール）、計画時に期待するステータスなどを設定します。
5. ジェパディ（計画機能に依存するため、26D 以降の扱いは公式で確認）：ジェパディ閾値とジェパディ優先度で、遅延リスクを低・中・高で評価します（Manage Jeopardy Thresholds、Manage Jeopardy Priorities）。
6. ステータス：Manage Status Values でオーケストレーション・プロセス・クラスを選び、そのクラスのステータスをタスクに追加します。フルフィルメント・システムごとにステータス値が違う場合（例：SCHEDULED と FULFILLMENT_SCHEDULED）は両方を登録します。
7. リリース・デプロイ：プロセスをリリースしてデプロイし、OM 全体で使えるようにします。
8. 割当ルール（Manage Orchestration Process Assignment Rules）：受注タイプや品目などの条件で、明細に割り当てるプロセスを決めます。

計画と再計画

26D 以降は利用できなくなります（計画機能の削除）

25D の What’s New（Replaced and Removed Features）によると、26D の更新から、オーケストレーション・プロセスの計画機能は使えなくなります。定義画面の Planning セクション（Planning Default Branch、Fulfillment Completion Step、Default Lead Time、Lead-Time UOM、Lead-Time Expression、Next Expected Task Status）は利用不可になり、パラメータ Enable Orchestration Process Planning and Calculate Jeopardy は No にする必要があり、スケジュール済プロセス Plan Orchestration Processes も使えません。代替機能は「なし」とされています。この節とジェパディの記述（手順 4・5）は 26C までの機能として読み、26D 以降の扱い（ジェパディ関連の設定を含む）は最新の Readiness と公式ガイドで確認してください。

パラメータ Enable Orchestration Process Planning and Calculate Jeopardy を有効にすると、OM はプロセスを計画し（各ステップの完了予定日）、ジェパディを計算します。再計画のタイミングは次から選びます。

• 変更時：受注が変更されたときに再計画
• ステップ完了後：各ステップの完了直後に再計画
• イベント時：受注システムからの更新などのイベントで再計画。定期的にはスケジュール済プロセス Plan Orchestration Processes で更新（26D 以降は利用不可）

Replan Instantly（即時再計画）は性能に影響するため、優先度の高い受注やジェパディ閾値が 1 日未満の受注に限って使います。

一時停止（Pause）と保留

• 一時停止：プロセスに一時停止のステップを入れ、時間の経過・イベント・依存関係の解消まで待たせます（公式トピック：Pause Orchestration Processes for Time / for Events / for Dependencies）。待機中のタスクはスケジュール済プロセス Release Pause Tasks で解除できます。
• 保留：保留をかけるとプロセスの進行が止まります。保留の適用・解除は作業領域、REST、拡張から行えます（受注入力）。

変更管理（Change Orders）

受注の変更は、オーケストレーション・プロセスが自動で吸収するように設計します。

1. 変更とみなす属性を決めます（Manage Order Attributes That Identify Change）。
2. 変更が来たら、プロセスは補償パターン（compensation pattern）に従って、完了済みのステップを取り消す・やり直す・何もしない、を判断します。公式の例では、出荷前に数量が変わると、フルフィルメントをロールバックして再スケジュールし、新しい出荷依頼を送ります。
3. 変更のコスト（Measure the Cost of Change）を設定すると、変更の影響度を評価できます。
4. 変更を外部システムに知らせる場合は、ビジネスイベントのトリガー・ポイント（Manage Business Event Trigger Points）を設定します。

処理制約（Manage Processing Constraints）は、そもそも変更を受け付けるかどうかを決めます。たとえば、請求に連携済みの明細の数量は変更できません。制約エンティティは Order Header（提出前）、Order Line（提出前）、Order Fulfillment Line（提出後）で、変更後は Generate Constraint Packages で反映します。

よくあるミス

• 事前定義プロセスの直接変更：公式ガイドは事前定義プロセスを変更しないよう求めています。必ずコピーしてから修正します。
• 処理中の受注への適用：プロセスを修正しても、処理中の受注には効きません。受注を取り消し、プロセスを修正して再インポートする必要があります。
• 移行時のプロセス名変更：開発環境から本番環境へ移すときに名前を変えると、参照の更新に失敗することがあります。
• コピー元の検証漏れ：コピー元に検証エラーが残っていると、コピーがリリースされず New のままになることがあります。

外部フルフィルメント・システムとの連携

OM は、明細を複数のフルフィルメント・システム（外部の倉庫システムや別の ERP など）に振り分け、各システムの応答をまとめて受注システムに返せます。

1. Manage Upstream and Fulfillment Source Systems：受注システムとフルフィルメント・システムを登録します。
2. Manage External Interface Web Service Details：フルフィルメント・システムの URL・資格情報・証明書を登録します（コネクタ）。
3. Manage External Interface Routing Rules：どの品目・条件の依頼をどのシステムに送るかのルーティング・ルールを設定します。
4. フルフィルメント・システムは、タスク・サービスを通じて応答（出荷完了など）を OM に返します。

下流に独自の項目を渡したい場合は、拡張フレックスフィールドをサービス・マッピングに追加し、値の加工が必要なら統合アルゴリズム（Integration Algorithm）で処理します。たとえば、出荷料金を AR で通常明細として課税するには、Integration Algorithm for Sales Order Charges で LineType を LINE にし、サービス・マッピング FulfillmentIntegration に属性を追加します（機能 Enable Custom Payloads for Downstream Integration も有効化）。サービス・マッピングの編集にはサンドボックスが必要です。

ドロップシップとバック・ツー・バック

ドロップシップ（Drop Ship）

仕入先が顧客に直送する流れです。

1. OM がプロセスを割り当て、スケジュールのタスクで GOP に依頼します。GOP はソーシングルール・仕入先カレンダー・能力から仕入先と仕入先サイトを選びます。
2. 購買依頼組織を Supply Chain Financial Orchestration から取得し、Procurement に購買依頼を送ります。パラメータ Preparer for Procurement の設定が必要です。
3. Procurement が購買依頼・購買オーダーを作成します。明細は Requisition Created → Awaiting Shipping と進みます。
4. 仕入先が顧客に出荷し、Supplier Portal で ASN を登録します。受入では論理的な受入が作られます。
5. Financial Orchestration がドロップシップの財務フローを実行し、原価管理が受入会計と原価計算を行います。
6. OM は ASN を出荷確認として扱い、AR で顧客に請求します。

バック・ツー・バック（Back-to-Back）

受注ごとに供給（購買・製造・移動）を手配し、その供給を出荷まで受注に引き当てておく流れです。GOP が受注に対して供給を予約し、Supply Chain Orchestration が供給オーダーを作成します。製造（make）の場合は、GOP 用に作業定義を収集しておかないと供給オーダーが作られません。

移動オーダー

同じ組織内の拠点間で品目を移す取引です。移動オーダーは Supply Chain Orchestration で作成され、OM にインポートされて処理されます。

コード例

オーケストレーションが止まっている明細を探す SQL の例です（公式ドキュメントの照会例をもとに、待機中の有効なタスクがない提出済み明細を抽出）。

NOT_STARTED のまま進まないフルフィルメント明細を探す

SELECT h.source_order_number,
       l.display_line_number,
       f.fulfill_line_number,
       f.status_code,
       f.last_update_date
FROM   doo_headers_all       h
JOIN   doo_lines_all         l ON l.header_id = h.header_id
JOIN   doo_fulfill_lines_all f ON f.line_id   = l.line_id
WHERE  h.submitted_flag = 'Y'
AND    f.open_flag      = 'Y'
AND    f.status_code    = 'NOT_STARTED'
AND    f.creation_date >= :P_FROM_DATE
AND    NOT EXISTS (
         SELECT 1
         FROM   doo_wait_task_details    w
         JOIN   doo_orchestration_groups g ON g.group_id = w.group_id
         WHERE  w.status_code = 'Active'
         AND    g.status      = 'ACTIVE'
         AND    g.transaction_entity_name = 'DOO_ORDER_FLINES_V'
         AND    g.transaction_entity_id   = f.fulfill_line_id)
ORDER  BY h.source_order_number

抽出した受注は、作業領域のエラー回復の操作（公式トピック：Recover Sales Orders That Are Locked or Not Started）で対処します。運用では、この SQL を BI Publisher のレポートにして日次で確認すると、止まった受注の早期発見に役立ちます。

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

• ステップは少なく：大量処理には DOO_ScheduleShipInvoice のような簡潔なプロセスを使います。
• ステータス値を外部システムに合わせる：フルフィルメント・システムが返すステータスをすべて登録しておかないと、応答を正しく解釈できません。
• ジェパディは計画とセット：ジェパディを使うには、ステップのリードタイムと計画の有効化が前提です。
• テストは変更系を重視：出荷前・出荷後・請求後の数量変更や取消で、補償パターンと処理制約が期待どおり動くかを確認します。

試験対策ポイント

• 対応する試験：受注 模擬テスト の「高度なサプライチェーン・フルフィルメント手法の実装（Implementing Advanced Supply Chain and Fulfillment Techniques）」
• 事前定義プロセス 4 種の用途と、ShipOrderGenericProcess のステップとサービス
• 「コピーして修正」「処理中の受注には効かない」「移行時に名前を変えない」
• 設定順序（タスクタイプが最初、デプロイが最後、割当ルールはデプロイ後）
• 処理制約の制約エンティティと Generate Constraint Packages
• ドロップシップの登場人物（GOP、Supply Chain Financial Orchestration、Procurement、Supplier Portal、受入、AR）とステータス
• Replan Instantly の使いどころ（26C まで。26D 以降は計画機能自体が利用不可）

公式ドキュメント

• Oracle Fusion Cloud Order Management 25D What’s New（Replaced and Removed Features）
• Overview of Orchestration Processes
• Guidelines for Setting Up Orchestration Processes
• Roadmap to Set Up Order-to-Cash
• How Drop Ship Works in Order Management
• Use Order Management to Fulfill Different Types of Sales Orders
• Integrate Order Management with Oracle Receivables

関連ページ

• 受注管理（Order Management）の全体像と試験範囲
• 受注入力・受注インポート
• 引当（GOP）・出荷・返品
• 購買（購買オーダー・承認・変更）
• O2C：受注から出荷・請求・入金まで
• ビジネスイベントとアウトバウンド連携のパターン