受注入力・受注インポート

この章の結論

• 受注の入口は「Order Management 作業領域での入力」「FBDI・REST によるインポート」「B2B メッセージング」の 3 つです。外部から来た受注はソース・オーダーとして取り込まれ、OM の共通形式の販売オーダーに変換されます。
• 受注は下書き（Draft）で作成し、**提出（Submit）**した時点で検証・与信チェック・承認・オーケストレーションの割当が動きます。
• 大量の取込は FBDI（SourceSalesOrderImportTemplate.xlsm → Load Interface File for Import → Import Sales Orders）、1 件ずつのリアルタイム連携は REST（salesOrdersForOrderHub、1 ペイロード 1 受注）を使います。
• 提出後の変更は処理制約（Processing Constraints）で制御され、変更内容に応じてオーケストレーション・プロセスが補償処理（やり直し・取消）を行います。
• 与信チェックは Receivables が行い、失敗時の動き（受注全体を下書きに戻すか、失敗明細だけ保留にするか）をパラメータで選びます。

全体像

受注が OM に入るまでの流れは次のとおりです。

1. 入力・受信：受注入力担当（Order Entry Specialist）が Order Management 作業領域で Create Order を使って入力するか、EC・EDI・コールセンターなどの受注システムから受注を受け取ります。
2. ソース・オーダーの変換：外部から来た受注（ソース・オーダー）は、ビジネスルールや拡張で属性を補完・変換されて販売オーダーになります。
3. 提出：検証（品目・顧客・必須項目・処理制約）、与信チェック、承認を経て、明細が下書きから提出済みになります。
4. オーケストレーションの割当：割当ルールで明細ごとにオーケストレーション・プロセスが決まり、フルフィルメントが始まります（オーケストレーション）。

公式ドキュメントでは、受注作業のロールとして Order Entry Specialist（受注入力）、Order Manager（受注管理者）、Order Administrator（受注の設定管理）、Error Recovery（エラー回復）が使われています。

受注の構造

階層	テーブル	主な属性	役割
ヘッダー	DOO_HEADERS_ALL	BU、顧客（Buying Party）、請求先・出荷先、受注タイプ、通貨、支払条件	受注全体の情報
受注明細	DOO_LINES_ALL	品目、数量、単位、明細タイプ	顧客が注文した内容
フルフィルメント明細	DOO_FULFILL_LINES_ALL	倉庫、予定日、ステータス、出荷・請求の状況	オーケストレーションが処理する単位

• 受注明細とフルフィルメント明細は通常 1 対 1 ですが、部分出荷などで明細が分割されるとフルフィルメント明細が増えます。
• 構成品目（モデルとオプション）は親子の明細になり、子明細は親の構成から作られます。
• 料金と税は DOO_ORDER_CHARGES → DOO_ORDER_CHARGE_COMPONENTS → DOO_ORDER_TAX_DETAILS に保持されます。

用語の注意

26C の公式ドキュメントでは、フルフィルメント明細を「order line」と表記している箇所があります（例：トピック名は Add Status Conditions to Order Lines、URL は add-status-conditions-to-fulfillment-lines）。設定画面や旧版の資料では fulfillment line の名称も残っているため、同じものを指していると理解して読み進めます。

画面での受注入力

Order Management 作業領域での基本的な入力の流れです。

1. Create Order で受注を作成し、BU と顧客を指定します。顧客の請求先・出荷先・連絡先・支払条件は TCA のパーティ情報から既定値が入ります。
2. 受注全体の価格設定（価格戦略・価格セグメント）が Pricing で決まります。価格戦略は顧客の属性で決まります（価格設定）。
3. 明細に品目と数量を入力して Apply すると、品目情報は Product Management から取得され、明細ごとに価格が計算されます。
4. 必要に応じて下書きとして保存し、準備ができたら Submit します。

関連する主な設定です。

設定	場所	内容
Item Validation Organization	Manage Order Management Parameters	受注で検索・入力できる品目と、OM が読む品目属性の組織（BU ごと）
Cascade Order Header Values to Order Lines	Manage Order Management Parameters	ヘッダーの値を明細に反映するかどうか
表示通貨・換算レートタイプ	Manage Order Profiles	Display Currency、Currency Conversion Type など
受注番号の採番	Set Up Sequences for Sales Order Numbers（公式トピック）	受注番号の文書順序

品目は、品目検証組織で Customer Ordered と Customer Orders Enabled が両方 Yes でないと受注に使えません。画面ではエラーで提出できず、インポートでは受注が Draft のまま取り込まれます。

受注インポート

取込手段の選び方

手段	向いている用途	注意点
FBDI（Order Import Template）	移行、大量の定期取込	失敗した取込を、ソース・オーダーを再送せずにやり直しやすい
REST salesOrdersForOrderHub	1 件ずつのリアルタイム連携、照会・変更	同期処理。1 ペイロード 1 受注が原則で、複数をまとめると約 5 分でタイムアウトの恐れ
REST Sales Orders for Order Hub Requests	REST で大量に取り込みたい場合	インターフェース表にステージングし、ジョブで取り込む
B2B メッセージング	取引先からの EDI 受注	Collaboration Messaging の設定が必要

FBDI と REST では属性名の書き方が異なります。テンプレートは見出し名（Payment Method Code）と Y/N、REST はキャメルケース（PaymentMethodCode）と true/false を使います。外部システムを使う場合は、事前に Manage Upstream and Fulfillment Source Systems でソース・システムを登録し、品目・顧客・単位などのコードの相互参照（クロスリファレンス）を設定します。

FBDI の手順

1. File-Based Data Import for SCM の Order Management > Import Sales Orders から SourceSalesOrderImportTemplate.xlsm を入手します。
2. 各タブ（DOO_ORDER_HEADERS_ALL_INT、DOO_ORDER_LINES_ALL_INT など）のサンプル行を削除してデータを貼り付け、Generate CSV File で ZIP を作成します。
3. スケジュール済プロセス Load Interface File for Import を、Import Process = Import Sales Orders、Data File = ZIP ファイルで実行します。
4. Import Sales Orders を実行します。主なパラメータは Batch Name、Delete Processed Orders、絞込み条件（Source System、Source Order Number、Customer Name など。指定は 1 つだけにする）、Order Interface Status（All statuses / Error / No status）です。
5. エラーは Order Management 作業領域の Manage Order Orchestration Messages で確認し、テンプレートを修正して再実行します。
6. 取込が安定したら Delete Orders from Interface Tables でインターフェース表を削除します。

Load Interface File for Import の同時実行数はパラメータ Number of Processes for Order Import（既定 4、推奨上限 60）で決まります。

ソース・オーダーの変換

ソース・オーダーの値の補完や変換は、変換前・変換後に属性値を設定するビジネスルール（公式トピック：Set Attribute Values Before You Convert Source Orders / Set Attribute Values After You Convert Source Orders）と、Order Management Extensions（Groovy）で行います。新規の実装では、公式ドキュメントが案内する Order Management Extensions を基本に検討します。試験範囲には製品変換ルール（product transformation rules）も含まれるため、旧来の変換ルールの考え方も公式ドキュメントで確認しておきます。

受注の変更・取消・保留

変更（リビジョン）と処理制約

• 提出済みの受注は、Order Management 作業領域で改訂（リビジョン）を作成して変更し、再提出します。外部システムからの変更は、REST やインポートでソース取引のリビジョン番号（SourceTransactionRevisionNumber）を上げて送ります。
• 変更できるかどうかは処理制約で決まります。たとえば、請求に連携済みの明細の数量は変更できません。事前定義の制約には Ordered Date Update（受注日の更新禁止）、Order Line Deletion（明細の削除禁止）、Payment Terms Are Missing（支払条件なしの提出禁止）などがあります。
• 処理制約の対象（制約エンティティ）は、提出前のヘッダーが Order Header、提出前の明細が Order Line、提出後の明細が Order Fulfillment Line です。変更後は Generate Constraint Packages で反映します。
• 変更を受けたオーケストレーション・プロセスは、どの属性の変更を「変更受注」とみなすか（Manage Order Attributes That Identify Change）と補償パターンの設定に従って、ステップのやり直しや取消を行います（オーケストレーション）。

取消と保留

• 受注・明細の取消は作業領域の操作か REST で行います。処理制約で取消を禁止している場合は取り消せません。
• 保留（Hold）は保留コードで管理し、保留をかけるとオーケストレーション・プロセスの進行が止まります。与信チェックの失敗でも明細に保留がかかります。
• 大量の受注への保留の適用・解除は REST の salesOrderActionRequests でまとめて実行できます（ActionCode = ORA_FOM_APPLY_ORDER_HOLD など）。

与信チェックと承認

与信チェック

与信チェックは Receivables の Credit Management 機能が行います。OM はチェックを依頼し、Receivables は「与信限度額 − 未決済残高 − 未消化の与信承認額」で利用可能額を計算して、承認番号・有効期限・承認額を返します。与信枠は単一通貨・顧客アカウント単位です。

パラメータ	値	動作
Activate Credit Check on Order Submit	Yes / No	提出時に与信チェックを行うか
Credit Check Failure at Order Submit	Save Order in Draft Status	受注全体が Credit Review Pending となり、何もフルフィルメントに送られない
同上	Submit the Order with Hold on Lines That Failed Credit Check	受注は Processing。失敗した明細だけ与信の保留がかかり、他の明細は出荷へ進む

与信チェックは提出時のほか、承認の直前、請求先顧客などの支払に関わる変更時にも再実行されます。Receivables は与信依頼ごとにケースフォルダ（case folder）を作り、与信担当者が Credit Reviews ページで承認・却下します。承認されると保留が解除されてフルフィルメントに進み、却下されると受注は下書きに戻り、受注入力担当が修正して再提出します。

承認

承認ルーティングはパラメータ Start Approval Process for Sales Orders で制御します。Yes にすると承認ルールがなくても承認処理を経由し（受注は一時的に Approval Pending）、No にすると承認ルールが有効でも承認ルーティングを行いません。承認ルールとタスクの設定は公式トピック Set Up Approval Rules for Sales Orders / Set Up Approval Tasks for Sales Orders を参照します（承認ワークフロー）。

コード例

salesOrdersForOrderHub に受注を 1 件登録する最小例です。公式のユースケースの構造に合わせ、値はすべて架空です。

受注を 1 件作成して提出する（REST）

export FA_URL="https://<your-pod>.fa.<region>.oraclecloud.com"
curl -s -u "$FA_USER:$FA_PASS" \
  -X POST "$FA_URL/fscmRestApi/resources/11.13.18.05/salesOrdersForOrderHub" \
  -H "Content-Type: application/json" \
  -H "REST-Framework-Version: 4" \
  -d @order.json

order.json（例：サンプル商事の受注）

{
  "SourceTransactionNumber": "EC-20261015-0001",
  "SourceTransactionSystem": "ECSHOP",
  "SourceTransactionId": "EC-20261015-0001",
  "SourceTransactionRevisionNumber": 1,
  "BusinessUnitName": "JP01 営業単位",
  "BuyingPartyName": "サンプル商事株式会社",
  "TransactionType": "Standard Orders",
  "TransactionalCurrencyName": "Japanese Yen",
  "RequestedShipDate": "2026-10-20T09:00:00+09:00",
  "RequestedFulfillmentOrganizationName": "東京倉庫",
  "FreezePriceFlag": false,
  "FreezeShippingChargeFlag": false,
  "FreezeTaxFlag": false,
  "SubmittedFlag": true,
  "lines": [
    {
      "SourceTransactionLineId": "1",
      "SourceTransactionLineNumber": "1",
      "SourceTransactionScheduleId": "1",
      "SourceScheduleNumber": "1",
      "TransactionCategoryCode": "ORDER",
      "TransactionLineType": "Buy",
      "ProductNumber": "ITEM-1001",
      "OrderedQuantity": 5,
      "OrderedUOM": "Each"
    }
  ]
}

• SourceTransactionSystem には事前に登録したソース・システムのコードを指定します。
• SubmittedFlag を false にすると下書きとして作成されます。
• FreezePriceFlag を true にすると、送った価格を OM で再計算せずに使います（価格設定）。

実務での拡張ポイントです。

• リトライ：同期処理のため、タイムアウト時は同じ SourceTransactionId で受注の有無を照会してから再送します（二重登録の防止）。
• 変更：同じソース取引のリビジョン番号を上げて送ります。分割後の明細を更新するときは SourceLineId ではなく FulfillLineId を使います。
• 大量件数：1 回に複数受注をまとめず、FBDI か Sales Orders for Order Hub Requests に切り替えます。
• 拡張フレックスフィールド：ヘッダーの EFF は additionalInformation に Category（例：DOO_HEADERS_ADD_INFO）を指定して送ります。構造は describe で確認します。

インポートした受注の提出状況を確認する（BIP の例）

SELECT h.source_order_number,
       h.submitted_flag,
       COUNT(f.fulfill_line_id)                               AS fulfill_lines,
       SUM(CASE WHEN f.open_flag = 'Y' THEN 1 ELSE 0 END)     AS open_lines
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.source_order_number = :P_ORDER_NUMBER
GROUP  BY h.source_order_number, h.submitted_flag

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

よくあるミス

• 品目検証組織の未設定：BU ごとに Item Validation Organization を設定しないと、その BU の受注で品目を検索できません。
• 顧客の自動作成に頼る：受注インポートでの顧客情報の自動作成（CreateCustomerInformationFlag）はサポートされなくなっています。顧客は先に作成しておきます。
• REST で大量投入：1 ペイロードに多数の受注を入れるとタイムアウトします。
• インポート条件の重複指定：Import Sales Orders の絞込み条件（Source System と Customer Name など）を複数指定すると条件が衝突します。1 つだけ指定します。
• コード値の不一致：受注システムと Fusion で単位や通貨の表記が違う（例：Ea と Each）場合は、相互参照を設定しないと取り込めません。

• ソース・システムごとに受注番号を保持したい場合は、公式トピック Keep Your Order Number When You Import を確認します。
• 外部システムからの変更・取消のテストケースを必ず作ります。処理制約で拒否された場合のエラー応答と再送の手順を決めておきます。
• 与信・承認・保留はいずれも「明細が止まる」原因になります。ステータス（Credit Review Pending、Approval Pending、保留中）ごとに、誰がどの画面で解除するかを運用手順に書きます。

試験対策ポイント

• 対応する試験：受注 模擬テスト の「受注管理とフルフィルメントの実装（Implementing Order Management and Fulfillment Cloud）」と「AI/ML・モバイル・自動化機能の活用」
• 受注インポートのジョブの順序（Load Interface File for Import → Import Sales Orders → Delete Orders from Interface Tables）と、エラーの確認場所（Manage Order Orchestration Messages）
• REST salesOrdersForOrderHub は同期・1 受注ずつ、大量は FBDI または Hub Requests
• 与信チェックの 2 つのパラメータと、失敗時のステータス（Credit Review Pending / Processing ＋保留）
• 承認のパラメータ Start Approval Process for Sales Orders の Yes / No の違い
• 品目の Customer Ordered / Customer Orders Enabled と品目検証組織
• 処理制約の制約エンティティ（Order Header / Order Line / Order Fulfillment Line）

公式ドキュメント

• Overview of Importing Orders Into Order Management
• Import Orders Into Order Management
• Use REST API to Import Large Volumes of Sales Orders
• Create Sales Order With Extensible Flexfield（REST API for Oracle Fusion Cloud SCM）
• Apply Hold on Large Volume of Sales Orders（REST API）
• Overview of Setting Up Credit Check
• Manage Order Management Parameters

関連ページ

• 受注管理（Order Management）の全体像と試験範囲
• オーケストレーション（プロセス定義・フルフィルメント）
• O2C：受注から出荷・請求・入金まで
• 顧客マスタと共通設定
• REST API 応用（子リソース・作成更新・フレームワークバージョン・エラー）
• FBDI の仕組みと手順