1. オーダー管理の実装
  2. Order Managementへのオーダーのインポートの概要
機械翻訳について

Order Managementへのオーダーのインポートの概要

オーダー・インポート・テンプレートまたはREST APIを使用して、ソース・システムからOracle Order Managementにオーダーをインポートします。

オーダー・インポート・テンプレート、webサービスまたはREST APIを使用して、ソース・システムからOrder Managementにオーダーをインポートします。

オーダー・インポート・テンプレートを使用すると、エラーを減らし、インポートを簡略化できます。 このテンプレートには、Oracleデータベースに必要な構造が含まれています。 データベース表ごとにタブが含まれ、タブは特定の順序で表示されます。 各タブの列はOracleが必要とする表の列を表し、テンプレートはOracleが各データベース列に必要なデータ型を指定します。

必要なもの 入手できる場所
オーダー・インポート・テンプレートの使用方法について学習します。 ソース・データをCSVファイルに変換
オーダー・インポート・テンプレートのコピー、およびテンプレートが参照する表の詳細。 「SCMのファイル・ベース・データ・インポート(FBDI)」に移動します。 オーダー管理の章で、「販売オーダーのインポート」をクリックします。
テンプレートの例。 「Order Managementの技術リファレンス(ドキュメントID 2051639.1)」に移動し、ペイロードおよびファイルの添付をダウンロードします。
salesOrdersForOrderHub REST APIの詳細。

詳細および例については、「Oracle Supply Chain Management CloudのREST API」に移動し、「Order Management(オーダー管理)」を展開し、「オーダー・ハブの販売オーダー」をクリックします。
より技術的な詳細。 マスター・ノートFBDIを使用したデータのインポート(ドキュメントID 2665940.1)

インポート・テクノロジの比較

実行内容 オーダー管理の作業領域 ファイル・ベース・データ・インポート REST API ADFデスクトップ統合(ADFDI)
販売オーダーおよびオーダー明細のクローズ中に、オーダー・ヘッダーの拡張可能フレックスフィールドを更新します。 いいえ いいえ いいえ いいえ
オーダー明細のリクエスト日属性を更新します。 はい はい はい いいえ
オーダー・ヘッダーのオーダー・タイプ属性を更新します。 はい はい はい いいえ

取消またはクローズされていないオーダーのヘッダーを更新します。

 はい いいえ はい いいえ
オーダー・ヘッダーのプライマリ営業担当を更新します。 はい はい。ただし、オーダーを送信していない場合のみです。 はい いいえ
オーダー明細の価格設定を更新します。* はい はい はい いいえ
請求待ちステータスの販売オーダーを更新します。 いいえ いいえ いいえ いいえ

*価格設定を更新できるのは、価格設定が確定されていない場合のみです。 詳細は、「販売オーダーの価格を確定」を参照してください。

大量のソース・オーダーのインポート

多数のソース・オーダーをインポートするには、REST APIのかわりにファイルベース・データ・インポート(FBDI)を使用することをお薦めします。 FBDIは回復力が高く、ソース・システムからソース・オーダーを再送せずに失敗したインポートを再試行する方が簡単です。

1つの例について考えてみます:

  • 毎日約4,000件のオーダーを処理します。

  • 各ソース・オーダーの平均オーダー明細数は約50です。

  • 毎日約20万件のオーダー・ラインを処理します。

  • 午前8時から午後8時まで、1時間当たり約330のソース・オーダーをインポートするとします。

  • 現在、4つのソース・システムからインポートする必要があり、8つまで拡張する予定で、全体的な処理が1日に2倍になる可能性があります。

  • 販売オーダーをインポートした翌日に出荷する必要があります。

  • オーケストレーション・プロセスには、スケジュール、予約、出荷、請求などの一般的な履行タスクが含まれます。

FBDIはこの種のボリュームを処理するための最良の技術です。

REST APIを使用してソース・オーダーをインポートする必要がある場合は、各ペイロード・リクエストにソース・オーダーを1つのみ含めます。

REST APIでは同期操作のみがサポートされているため、各ペイロードに複数のソース順序を含めて、リクエストが約5分を超えて実行された場合、リカバリできないタイムアウト・エラーが発生する可能性があります。

属性名と値の相違点

インポート・テクノロジでは、一部の属性の名前と値が若干異なります。 オーダー管理では、これらの命名規則の違いに関係なく、同じ方法で属性を処理します。

属性名

フォーマット

オーダー・インポート・テンプレート

REST API

属性名の大文字。

ヘッドライン(支払方法コードなど)。

PaymentMethodCodeなどのキャメル・ケース。

ブール値を含む属性の名前。

価格設定の凍結などは示されません。

通常、テキストFlag (FreezePriceFlagなど)が含まれます。

識別子を含む属性の名前。

通常は、ソース・トランザクション識別子などの識別子という語が含まれます。

通常、SourceTransactionIdなどのテキストIDが含まれます。

ブール値

テクノロジ

True

False

オーダー・インポート・テンプレート

Y

N

REST API

true

false

インポート動作の変更の準備

更新27B以降、「大量の販売オーダーのインポートおよび履行」オプトイン機能は、デフォルトで有効として事前定義されています。 「販売オーダーのインポート」スケジュール済プロセスでは、SalesOrderForOrderHub REST APIのような動作が使用されます。 これらのガイドラインを使用して、準備に役立ててください。

顧客の作成
古い 新規 推奨
CreateCustomerInformationFlag属性をtrueに設定すると、インポートによってパーティ、サイト、担当者、アカウント、サイト使用およびアカウント・ロール・データを作成できます。 CreateCustomerInformationFlag属性は設定できません。 オーダーをインポートする前に顧客マスターに顧客が存在しない場合は、そのオーダーをインポートできなくなります。 販売オーダーの顧客REST APIを使用して、販売先、出荷先および請求先データを作成し、そのデータを使用して販売オーダーを作成します。
変換ルールのかわりに拡張機能を使用
古い 新規 推奨
プリトランスフォーメーション、トランスフォーメーションおよびポストトランスフォーメーション・ルールを使用できます。 27Bの更新からは、変換ルールを使用できなくなります。

かわりに、オーダー管理拡張を使用します。

拡張機能のオブジェクトを使用したデータの読取り

古い 新規 推奨

「送信要求の開始時」拡張は、オーダーの送信後に実行されるため、次のようになります。

  • 販売オーダー・データはすでにデータベースに存在し、パブリック・ビュー・オブジェクト(PVO)を使用してオーダーを問い合せることができます。
  • コミットが完了したため、オーダー番号を使用できます。

送信要求の開始時にオーダーを発行する前に実行するため:

  • PVOを使用してデータを問い合せることはできません。
  • オーダー番号は使用できません。 デフォルト値の-1 (負の1)が含まれます。

拡張で使用可能な拡張オブジェクトを使用して、現在の販売オーダーのデータを読み取ります。

PVOを使用して、改訂での作業時の処理オーダーや返品時の元のオーダーなど、関連オーダーのオーダー・データのみを問い合せます。

オーダー明細の分割

古い 新規 推奨

RESTペイロードのSourceLineId属性を使用して、オーダーを改訂できます。 改訂の全体的な明細数量を変更し、Order Managementで分割明細間の数量を正確に調整しました。

たとえば:

  • 明細xの数量15を、明細yの数量7、明細zの数量8に分割します。
  • 当初オーダーの数量15から改訂された、明細xに数量10の改訂を送信します。 これで、明細yに7、明細zに3という新しい分割数量が設定されました。

SourceLineIdを使用してオーダーを改訂すると、Order Managementでは、その更新が元の履行明細の最初の履行明細にのみ適用されます。 新規または後続の分割明細は更新されず、意図しない誤ったオーダー変更につながる可能性があります。

例:

  • ラインxの当初数量15をyの7、zの8に分割します。
  • 改訂を発行して、xの数量を15から10に減らします。
  • 改訂後、分割明細は10と8になります。 Order Managementでは明細yのみが7から10に更新され、明細zは変更されません。
  • その結果、合計数量が10に減らされるのではなく、誤って15から18に増加します。

改訂中に分割した後に履行明細を更新する場合は、FulfillLineIdを使用します。

このシナリオではSourceLineIdを使用しないでください。

大/小文字の区別を考慮

古い 新規 推奨
参照の値をそのIDに変換する際、インポートでは大文字と小文字が区別されませんでした。 「販売オーダーのインポート」スケジュール済プロセスでは、大/小文字が区別されます。 インポート・ペイロードで大文字と小文字が正しいことを確認してください。

出荷先および請求先属性のデフォルト値の設定

古い 新規 推奨
オーダー・インポートで、出荷先および請求先属性のデフォルト値を設定できませんでした。 これらの属性に値を含めない場合、インポートによって顧客のパーティ・データからデフォルトの住所およびその他の属性が移入されます。 インポート後にこれらの値を手動で設定していた場合は、これを行う必要はなくなります。

関連トピック