受注管理（Order Management）の全体像と試験範囲

Order Management（受注管理。以下 OM）は、受注を取り込み、オーケストレーション・プロセスで引当・出荷・請求を各システムに依頼して進捗を管理する「司令塔」です。価格は Pricing、引当は Global Order Promising（GOP）、出荷は Inventory Management、請求は Receivables が実処理を担います。
受注は ヘッダー → 受注明細 → フルフィルメント明細 の 3 層です。オーケストレーションはフルフィルメント明細の単位で動きます（DOO_HEADERS_ALL / DOO_LINES_ALL / DOO_FULFILL_LINES_ALL）。
設定は「組織・品目・顧客 → GOP → OM パラメータ → 価格 → ステータス・制約 → オーケストレーション・プロセス」の順で、オーケストレーション・プロセスが最後です。事前定義プロセスは変更せずコピーして使います。
移行・連携は FBDI（SourceSalesOrderImportTemplate.xlsm ＋ Import Sales Orders）か REST（salesOrdersForOrderHub）。請求は Import AutoInvoice で AR に渡ります。
試験 1Z0-1077-26 は OM 本体に加え、Configure-to-Order・Configurator・レポート・Redwood・AI まで範囲が広い点に注意します。

モジュールの役割と位置づけ

OM は O2C（Order to Cash：受注から入金まで） の前半を担います。公式ドキュメントは受注のライフサイクルを「取込（capture）→ 約束（promise）→ フルフィルメント（fulfillment）→ 売掛（receivables）」と説明しています。

OM の特徴は、自分では在庫も請求書も持たないことです。受注明細ごとに割り当てたオーケストレーション・プロセスが、スケジュール・引当・出荷・請求などのタスクを順に各アプリケーションへ依頼し、応答を待って次のステップへ進めます。EC サイト・EDI・コールセンターなど複数の受注システムからの受注（ソース・オーダー）を共通の形式の受注（販売オーダー）にそろえ、複数のフルフィルメント・システムへ振り分ける「オーダー・ハブ」としても使えます。

機能	実処理を担うアプリケーション	OM との関係
受注入力・変更・保留・返品	Order Management 作業領域	OM 本体
価格計算	Pricing（Pricing Administration 作業領域で設定）	受注ヘッダー・明細の価格を計算
供給の可用性チェック・出荷元の選定	Global Order Promising（GOP）	Create Scheduling タスクから呼ばれる
引当（予約）・出荷	Inventory Management	Create Inventory Reservation / Create Shipping
与信チェック	Receivables（Credit Management 機能）	受注の提出時などに呼ばれる
請求・入金	Receivables	Create Billing Lines → AutoInvoice
品目情報	Product Management	品目属性を受注で参照

使用する組織

OM の組織設計は「どの BU が売るか」「どの倉庫から出すか」「どの組織の品目属性で判定するか」の 3 点で考えます。

組織	OM での使われ方	設定の考え方
ビジネス・ユニット（BU、受注ヘッダー）	受注ヘッダーの Business Unit。OM 作業領域には、ユーザーがアクセスできる BU の受注だけが表示される	受注を受け付ける BU ごとに作成し、ユーザーにデータアクセスを付与
販売利益センター BU（任意）	明細ごとの BU（Selling Profit Center）。税・原価・AR・Supply Chain Financial Orchestration に渡る	機能のオプトイン＋パラメータ Business Unit for Selling Profit Center
在庫組織（倉庫）	明細の出荷元（Warehouse）。GOP が選定し Inventory Management が出荷	フルフィルメントで使う倉庫はすべて在庫組織として設定
品目検証組織	受注で検索・入力できる品目と、OM が読む品目属性の組織	パラメータ Item Validation Organization を BU ごとに設定
参照データ・セット	顧客アカウント・サイトや保留、オーケストレーション・プロセスをセット単位で共有	各 BU に既定セットを割り当てる

組織間の関係は次のとおりです。

受注ヘッダーの BU が「売り手」です。顧客の請求先・出荷先サイトは参照データ・セット経由で BU から使えるものに限られます。
明細の倉庫（在庫組織）は GOP のソーシングルールで決まり、出荷は Inventory Management が行います。
請求は Receivables の AutoInvoice で作られます。Import AutoInvoice は BU をパラメータに持って実行されます。
販売利益センター BU を使うと、明細の BU を受注ヘッダーの BU と同じにするか、出荷する在庫組織が参照する BU にするかを選べます（パラメータの値は Order Management / Shipping Organization）。主な用途は、州ごとの税登録など複数の利益センターを 1 受注で扱うケースです。

主要な業務プロセス

標準的な「在庫から出荷する受注」（事前定義プロセス ShipOrderGenericProcess）の流れです。

受注入力：受注入力担当（Order Entry Specialist）が Order Management 作業領域の Create Order で入力するか、外部システムから受注をインポートします。顧客情報は TCA（Trading Community Architecture）のパーティ、品目情報は Product Management から取得します。
価格計算：Pricing が価格戦略・価格セグメントを決め、明細ごとに価格を計算します（価格設定）。
提出（Submit）：検証が通ると下書き（Draft）の明細が提出済みになります。設定により与信チェック（Receivables）と承認が動きます。
オーケストレーション・プロセスの割当：割当ルールが明細ごとにプロセスを決めます（オーケストレーション）。
スケジュール（Create Scheduling）：GOP が出荷元と出荷予定日を決めます。
引当（Create Inventory Reservation）：在庫を予約し、他の受注に使われないようにします。
出荷（Create Shipping → Wait for Shipment）：Inventory Management がピッキング・出荷確認を行い、OM は出荷確認を待ちます（引当・出荷・返品）。
請求（Create Billing Lines → Wait for Billing）：Receivables が Import AutoInvoice で請求書を作り、Notify Feeder System of Receivables Transactions で結果を OM に返します。明細は Awaiting Billing → Billed → Closed と進みます。
入金・会計：入金消込は Receivables、売上・売掛金の仕訳は Receivables、売上原価は原価管理が補助元帳会計（SLA）で作成します。OM 自体は会計仕訳を作りません。

このほか、ドロップシップ（仕入先から顧客へ直送）、バック・ツー・バック（受注ごとに供給を手配して引き当てる）、移動オーダー、返品などの流れがあります。

マスタデータ

マスタ	内容	作成場所・UI	移行手段
顧客	パーティ、顧客アカウント、請求先・出荷先サイト、連絡先	Receivables の顧客管理（TCA）	FBDI・REST（顧客マスタ）
品目	販売・受注の属性（Customer Ordered、Customer Orders Enabled、Reservable、Invoice Enabled など）	Product Management（Manage Items）	FBDI（品目インポート）・REST
単位（UOM）	受注数量の単位	Manage Units of Measure	手入力・FSM 移行
価格表・割引リスト・価格戦略	品目の価格と割引、顧客ごとの適用ルール	Pricing Administration 作業領域	公式の Pricing ドキュメントで確認
出荷方法	運送業者・輸送モード・サービスレベルの組合せ	Manage Carriers（Setup and Maintenance）	手入力・インポート（Import Shipping Method）
支払条件	請求の支払期日	Receivables の設定	手入力・FSM 移行
GOP のルール	ATP ルール、ソーシングルール、割当セット	Manage ATP Rules / Manage Sourcing Rules	手入力（設定データ）
オーケストレーション・プロセス	プロセス定義、割当ルール、ステータス	Manage Orchestration Process Definitions など	設定データの移行（FSM）
処理制約	変更・取消を禁止する条件	Manage Processing Constraints	設定データの移行（FSM）

**作成順序（依存関係）**は公式のロードマップに沿って次の順にします。

エンタープライズ構造（法的エンティティ・BU・元帳）、在庫組織、単位
品目・カタログ、顧客
GOP のデータ収集（Collect Planning Data）と ATP ルール・ソーシングルール
OM のパラメータ（Manage Order Management Parameters）とプロファイル（Manage Order Profiles）
価格設定（Pricing）
ステータス、処理制約、変更管理、ジェパディ、タスクタイプ、拡張フレックスフィールド
オーケストレーション・プロセスの定義 → リリース・デプロイ → 割当ルール（最後）

品目を作成・変更したら、GOP 用のデータ収集をやり直す必要があります。収集しないと品目や倉庫を受注で選べません。

他モジュールとの連携

タイミング	連携先	流れるデータ	仕組み
提出時	Receivables（与信）	与信チェック依頼と承認番号	Receivables の与信チェック・サービス
スケジュール	GOP	出荷元・出荷予定日	Create Scheduling、収集済みの計画データ
引当	Inventory Management	引当（予約）	Create Inventory Reservation（`INV_RESERVATIONS`）
出荷	Inventory Management	出荷依頼・出荷確認	Create Shipping → Wait for Shipment
請求	Receivables	請求明細・請求書番号	Create Billing Lines → Import AutoInvoice → Notify Feeder System of Receivables Transactions
直送・取寄せ	Procurement、Supply Chain Orchestration	購買依頼・購買オーダー・ASN	ドロップシップ、バック・ツー・バック

主な連携の補足です。

請求（AR）：受注明細は取引タイプ Invoice、返品明細は Credit Memo として渡ります（返品は Credit Memo 固定）。AR の請求明細の INTERFACE_LINE_ATTRIBUTE5 にフルフィルメント明細 ID が入るため、SQL で受注と請求書を結び付けられます。明細が Awaiting Billing のまま止まったら、Notify Feeder System of Receivables Transactions を再実行します。
原価（売上原価）：出荷の在庫取引は原価管理で原価計算され、売上原価の仕訳になります。販売利益センター BU は原価管理にも渡ります。詳細は粗利分析と原価の会計連携を参照してください。
調達（ドロップシップ）：GOP がソーシングルールで仕入先を選び、Procurement が購買依頼・購買オーダーを作ります。仕入先が出荷して ASN を登録すると、受入で論理的な受入が作られ、Financial Orchestration・原価管理を経て AR が顧客に請求します。
調達・製造（バック・ツー・バック）：受注ごとに購買・製造・移動で供給を作り、その供給を受注に引き当てたまま出荷します。
税：受注の税は Oracle Fusion Tax で計算されます。税率・税ルールは税側で設定します。

標準機能とアドオン

標準でできることの範囲は広く、まず標準機能の組合せで要件を満たせないかを確認します（Fit to Standard）。

要件の例	まず検討する標準機能	それでも足りない場合
項目の既定値・入力チェック	パラメータ、プロファイル、処理制約、ビジネスルール	Order Management Extensions（Groovy）
独自の業務ステップを追加	独自タスクタイプ、一時停止（Pause）ステップ	外部システム連携（コネクタ・OIC）
下流システムへ独自項目を渡す	拡張フレックスフィールド、サービス・マッピング	統合アルゴリズム（Integration Algorithm）
受注の変更を外部へ通知	ビジネスイベント（Manage Business Event Trigger Points）	OIC で受信・加工
帳票・一覧	標準レポート、OTBI	BI Publisher（データソース ApplicationDB_FSCM）
EDI 受注	B2B メッセージング（Collaboration Messaging）	OIC・FBDI・REST で取込

ベストプラクティス

事前定義プロセスはコピーして使う：ShipOrderGenericProcess などを直接変更しません。コピー元を検証してエラーを解消してからコピーします（エラーが残っていると、コピーがリリースされずステータスが New のままになることがあります）。
移行時にプロセス名を変えない：開発環境から本番環境へ移すとき、名前を変えると参照の更新に失敗することがあります。
処理中の受注にはプロセス変更が効かない：新しい処理をインポート済みの受注に適用するには、受注を取り消し、プロセスを修正（または新規作成）して、再インポートします。テスト計画に織り込みます。
大量取込は FBDI：REST（salesOrdersForOrderHub）は同期処理で、1 ペイロードに 1 受注が原則です。複数受注をまとめると約 5 分でタイムアウトする恐れがあります。
インターフェース表を掃除する：取込が成功してから数日おいて Delete Orders from Interface Tables を実行します。
並列数は既定から：Number of Processes for Order Import は既定 4、推奨上限 60 です。性能問題があるときだけ変更します。
E2E でテストする：OM 単体ではなく、出荷・AR 請求・原価計算・GL 転送まで通したテストシナリオを作ります（O2C の E2E）。

日本での導入の考慮点

日本固有の要件の多くは OM ではなく、税（Fusion Tax）と Receivables で対応範囲を確認します。機能の有無や対応範囲は、日本向けローカライゼーションの公式ドキュメントで必ず確認してください。

消費税：受注の税は Fusion Tax で計算されます。受注時の税額と請求書の税額をそろえるための公式トピック（Make Sales Order Tax and Invoice Tax the Same）があるため、両者に差が出ることを前提に設計・テストします。
適格請求書（インボイス制度）：請求書は Receivables が作成します。記載事項や税額の端数処理は税と AR の請求で検討します。
締め請求：OM は明細単位で請求明細を AR に渡します。月次の締め請求書は AR 側の機能で設計します。
売上計上のタイミング：出荷基準か着荷・検収基準かで、AR・収益管理の設定が変わります。公式には実際の配送日を契約・請求に使う設定（Use Actual Delivery Dates for Contracts and Invoices）や、収益認識日の扱い（Recognize Revenue on Different Dates）のトピックがあります。

実装リファレンス

主要テーブル

テーブル	内容	主な結合キー
`DOO_HEADERS_ALL`	受注ヘッダー	`HEADER_ID`、`SOURCE_ORDER_NUMBER`、`SUBMITTED_FLAG`
`DOO_LINES_ALL`	受注明細	`LINE_ID`、`HEADER_ID`
`DOO_FULFILL_LINES_ALL`	フルフィルメント明細（ステータス・倉庫・出荷）	`FULFILL_LINE_ID`、`LINE_ID`、`STATUS_CODE`
`DOO_ORDER_CHARGES` 系	価格・料金とその内訳、税明細	`PARENT_ENTITY_ID` = `FULFILL_LINE_ID`
`DOO_ORCHESTRATION_GROUPS` / `DOO_WAIT_TASK_DETAILS`	オーケストレーションの実行・待機タスク	`GROUP_ID`
`DOO_ORDER_HEADERS_ALL_INT` / `DOO_ORDER_LINES_ALL_INT`	受注インポートのインターフェース表	ソース・システムとソース取引 ID

料金・税の内訳は DOO_ORDER_CHARGES → DOO_ORDER_CHARGE_COMPONENTS → DOO_ORDER_TAX_DETAILS の順に結合します。引当は INV_RESERVATIONS（SOURCE_FULFILLMENT_LINE_ID、受注は DEMAND_SOURCE_TYPE_ID = 2）です。

SELECT h.source_order_number,
       l.display_line_number,
       f.fulfill_line_number,
       f.status_code,
       f.open_flag,
       trx.trx_number        AS ar_invoice_number
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
LEFT JOIN ra_customer_trx_lines_all trl
       ON trl.interface_line_attribute5 = TO_CHAR(f.fulfill_line_id)
LEFT JOIN ra_customer_trx_all       trx
       ON trx.customer_trx_id = trl.customer_trx_id
WHERE  h.submitted_flag      = 'Y'
AND    h.source_order_number = :P_ORDER_NUMBER
ORDER  BY l.display_line_number, f.fulfill_line_number

実務では、明細が分割（部分出荷）されるとフルフィルメント明細が増える点、1 明細に AR の請求明細が複数できる場合がある点に注意します。BI Publisher のデータソースは ApplicationDB_FSCM を使います（BIP の SQL 実践）。

受注インポートと API

手段	名前	用途
FBDI	テンプレート `SourceSalesOrderImportTemplate.xlsm` → Load Interface File for Import（Import Process に Import Sales Orders）→ Import Sales Orders	移行・大量取込
REST	`salesOrdersForOrderHub`（Sales Orders for Order Hub）	受注の作成・照会・変更（同期、1 受注ずつ）
REST	Sales Orders for Order Hub Requests	大量の受注をインターフェース表にステージングしてジョブで取込
REST	`salesOrderActionRequests`	保留の一括適用・解除など複数受注への一括アクション

主要な ESS ジョブ（スケジュール済プロセス）

ジョブ名	用途
Load Interface File for Import / Import Sales Orders	受注インポート
Delete Orders from Interface Tables	インターフェース表の削除
Plan Orchestration Processes	オーケストレーション計画（予定日・ジェパディ）の更新（25D の What’s New では 26D 以降は利用不可）
Release Pause Tasks	一時停止タスクの解除
Generate Constraint Packages	処理制約の変更を反映
Publish Extensible Flexfield Attributes	拡張フレックスフィールドの公開
Update or Close Sales Orders	参照先がクローズされたのに開いたままの受注・明細の修正
Import AutoInvoice / Notify Feeder System of Receivables Transactions	AR での請求書作成と OM への結果通知
Collect Planning Data	GOP 用の計画データ収集

主要な設定タスク

Manage Order Management Parameters、Manage Order Profiles、Manage Orchestration Process Definitions、Manage Orchestration Process Assignment Rules、Manage Status Values、Manage Processing Constraints、Manage Jeopardy Thresholds、Manage Task Types、Manage Order Extensible Flexfields、Manage Business Event Trigger Points、Manage External Interface Routing Rules。いずれも Setup and Maintenance の Order Management オファリング（機能領域 Orders）にあります。

試験対策ポイント

対応する試験は受注模擬テスト（1Z0-1077-26：Oracle Order Management Cloud Order to Cash 2026 Implementation Professional）です。出題範囲の大項目と、このサイトの対応ページは次のとおりです。

出題範囲（Exam Topics の大項目）	主な内容	対応ページ
Implementing Order Management and Fulfillment Cloud	受注設定、保留、出荷許容範囲、サービス・マッピング、受注インポート、価格設定	本ページ、受注入力、価格設定
Implementing Advanced Supply Chain and Fulfillment Techniques	オーケストレーション、処理制約、ジェパディ、ドロップシップ、バック・ツー・バック	オーケストレーション
Implementing Configure-to-Order	ATO・PTO、GOP、ソーシング・ATP ルール、受注での構成品目	引当・出荷・返品、受注入力
Implementing Configurator Modeling	構成モデルのライフサイクル、構造、ルール、UI	引当・出荷・返品（「Configure-to-Order と Configurator モデル」の節）
Leveraging Reports and Analytics in Order Management	レポート、インフォレット、ダッシュボード	レポーティングの全体像
Enabling Redwood Capabilities / Leveraging AI/ML/Mobile and Automation Features	Redwood ページ、AI エージェント	Redwood と AI

覚えておきたい判断ポイントです。

受注の 3 層（ヘッダー・明細・フルフィルメント明細）と、オーケストレーションがフルフィルメント明細単位であること
事前定義プロセス 4 種：ShipOrderGenericProcess（出荷）、ReturnOrderGenericProcess（返品）、OrderFulfillmentGenericProcess（ドロップシップ・バック・ツー・バックの分岐）、DOO_ScheduleShipInvoice（大量処理向け）
品目検証組織と、品目の Customer Ordered / Customer Orders Enabled
与信チェックの 2 つのパラメータ（Activate Credit Check on Order Submit、Credit Check Failure at Order Submit）
請求連携のジョブ（Import AutoInvoice、Notify Feeder System of Receivables Transactions）と、返品は Credit Memo