オーダー明細の納期出荷および到着日の設定

約束出荷日および約束到着日は、品目を顧客に出荷することに同意した日付を追跡します。これらの日付はオーダー管理作業領域では設定できませんが、他のテクノロジを使用して設定できます。

これらの日付は、履行を追跡またはレポートするためにのみ使用します。次の属性を使用して、品目が実際に出荷されて到着した時期を決定します:

実績出荷日
実際の配送日(出荷)
実績搬送日(Oracle Transportation Planning)

ファイル・ベース・データ・インポートの使用

オーダー・インポート・テンプレートでDOO_ORDER_LINES_ALL_INTワークシートの属性を使用します。

約束出荷日
約束到着日

書式要件については、ワークシートの手順を参照してください。詳細は、オーダー管理へのオーダーのインポートの概要を参照してください。

REST APIの使用

明細エンティティでPromiseArrivalDateおよびPromiseShipDate属性を使用します。たとえば:

"lines" : [ {
  "PromiseArrivalDate" : "2024-10-22T20:49:12+00:00",
  "PromiseShipDate" : "2024-10-19T20:49:12+00:00",

バックグラウンドの場合は、「Oracle Supply Chain Management CloudのREST API」 > 「Order Management」>「Order Hubの販売オーダー」>「販売オーダーの作成」に移動します。

バック・トゥ・バック供給が早期に到着した場合のオーダー明細の出荷の再スケジュール

現在の予定日より前に供給が使用可能になると、品目を早期に出荷します。供給の使用可能日を前の日付に移動すると、オーダー明細の予定出荷日と到着日を再計算できます。

たとえば、購買オーダーの納期または作業オーダーの完了日を、現在スケジュールされている日付より前の日付に移動すると、Oracle Order Managementはオーダー明細の予定出荷および予定到着日を再計算できます。

次のような利点があります:

在庫の保管費を削減します。この更新の前に、品目を出荷するためにスケジュールされた出荷日まで待機する必要がありました。これで、そのアイテムを早めにドアから取り出して、保持する必要がある在庫の量を減らすことができます。
スケジューリング・エラーを削減します。 Order Managementでスケジューリング属性を更新した後で、スケジュールを上書きする方法を決定できるようになりました。
履行の正確性と顧客満足度を向上させます。供給が早期に出荷できる状態になると、履行のリード・タイムが向上します。顧客は出荷を早期に受け取ることが大好きです。

この機能は、バック・トゥ・バック・フローで使用します。

サプライヤが優先顧客または優先度の高いオーダーの品目を早期に搬送することに同意し、購買オーダーの約束搬送日を予定日より前に移動するとします。別の例として、重要な顧客オーダーの生産優先度が高くなります。つまり、作業オーダーの完了日が予想よりも早く発生します。

25Dを更新する前は、供給が早期に到着したときに、Order Managementはオーダー明細の予定出荷日と予定到着日を再計算しませんでした。現在、Order Managementでは、再計算された予定日がGlobal Order Promisingから取得され、それらを使用してオーダー明細の日付が更新されます。

例を見てみましょう。

品目の後処理リード・タイムを2日に設定し、ピック- パック・リード・タイムを倉庫の1日に設定します。
日曜日は出荷しません。
倉庫と顧客の出荷先事業所の間の移動時間は3日です。

7月8日に、リクエスト出荷日が7月12日の販売オーダーを作成します。納期回答では、7月24日の予定出荷日、7月27日の予定到着日が返され、購買オーダーが推奨されます。サプライヤは、7月21日に品目を倉庫に搬送すると約束します。後処理に2日、ピック・パックに1日を追加し、7月24日に出荷する準備ができました:

要求出荷日	供給日(PO納期)	後処理リード・タイム	ピッキング-梱包リード・タイム	予定出荷日	予定到着日
12年7月	21年7月	2	1	24年7月	27年7月

顧客が以前の配送をリクエストしています。サプライヤと交渉し、サプライヤは約束より7日早く品目を使用できるようにすることに同意します。改訂購買オーダーの搬送日は7月14日です。この機能を使用すると、オーダー明細の予定出荷日と予定到着日が改訂されます。

要求出荷日	供給日(PO納期)	後処理リード・タイム	ピッキング-梱包リード・タイム	予定出荷日	予定到着日
12年7月	14年7月	2	1	17年7月	20年7月

上書きスケジュールの当初値を保持

また、Order Managementによるスケジューリング属性の更新後に、新しい「上書きスケジュールの当初値保持」オーダー管理パラメータを使用して、オーダー明細の上書きスケジュール属性の設定方法を指定することもできます。

様々なソースによって、スケジューリング属性が更新される場合があります:

「Order Promising(オーダー納期回答)」作業領域
Oracle Backlog Management
スケジューリング属性の更新REST API
供給日の変更

Order Managementでは、オーダー明細の「スケジュールの上書き」属性が「はい」に設定され、これらのソースのいずれかから更新を受信するたびにリクエストが処理されます。これにより、Global Order Promisingでは、オーダー明細全体を再スケジュールせずに、スケジューリング属性の変更を受け入れます。

ただし、「スケジュールの上書き」属性は「はい」のままであり、後続のリビジョンに影響を与える可能性があります。たとえば、販売オーダーを改訂して数量またはリクエスト日を変更した場合、Global Order Promisingでは再スケジュールされませんが、需要の変更を考慮せずに同じ予定日または倉庫を保持します。

「上書きスケジュールの当初値を保持」パラメータを「はい」に設定すると、Order Managementによるスケジューリング属性の更新後に「上書きスケジュール」属性が元の値に戻ります。「上書きスケジュール」の当初値が「No」の場合、Order Managementでは、スケジュール属性の更新後に「No」に戻されます。その後、数量またはリクエスト日を改訂すると、納期回答ではオーダー明細の再計画時にその改訂が含まれます。パラメータは「No」として事前定義されています。これにより、Order Managementでスケジューリング属性を更新した後、常に「スケジュールの上書き」属性を「Yes」に設定するという現在の動作が保持されます。

パラメータをデフォルトの「いいえ」のままにするとします。スケジューリングattribute.Assumeを更新した後、オーダー明細に次の値が設定されると、「スケジュールの上書き」属性の値は「はい」のままになります。

予定出荷日	予定到着日	スケジュールの上書き
20年6月	25年6月	いいえ

サプライヤは、購買オーダーの約束搬送日を6月22日に移動します。 Order Managementは更新を処理し、新しい予定日を設定します:

予定出荷日	予定到着日	スケジュールの上書き
22年6月	27年6月	はい

Order Managementでは、この更新中に「スケジュールの上書き」属性も「Yes」に設定されます。納期回答では、数量またはリクエスト日を変更した場合でも、その変更によって新しい予定日が発生した場合でも、後続の改訂に対して同じ予定日が返されます。

サプライヤが供給日を変更するとします。「上書きスケジュールの当初値を保持」パラメータを「Yes」に設定すると、Order Managementは、更新の処理後に「上書きスケジュール」属性を元の値「No」にリセットします。その後、数量または日付を改訂すると、納期回答ではその改訂が考慮され、オーダー明細に次の値が設定されます。

予定出荷日	予定到着日	スケジュールの上書き
22年6月	27年6月	いいえ

「上書きスケジュールの当初値を保持」を「No」に設定すると、Order Managementでは、スケジュール属性の更新後に「上書きスケジュール」属性が「Yes」のままになります。

ノート

「バック・トゥ・バック供給が早期に到着したときにオーダー明細の出荷を再スケジュール」機能にオプト・インします。
必要に応じて、「設定および保守」作業領域の「Order Managementパラメータの管理」タスクを使用して、「上書きスケジュールの当初値を保持」パラメータの値を変更できます。
この機能は、バック・トゥ・バック・フローでのみ使用できます。直接出荷では使用できません。
再計算されたスケジュール日がダウンストリーム工程にどのように影響するかを評価します。以前の出荷および倉庫を管理し、在庫の削減を管理するために、出荷の変更が必要になる場合があります。
再計算された予定日では、最早許容日または最遅許容日は考慮されません。顧客から最も早い日付を要求された場合は、早期に出荷したくない場合があります。
需要が頻繁に変更されることが予想される場合は、「上書きスケジュールの当初値を保持」パラメータを「はい」に設定することを検討してください。たとえば、オーダー数量が頻繁に変化したり、要求出荷日や要求到着日を変更したり、バックログ管理やサプライヤから頻繁に更新される場合があります。
納期回答が最新の需要を持つように、データを定期的に収集する必要があります。これは、出荷セットの一部であるオーダー・ピック構成品目、キットまたはオーダー明細で特に重要です。出荷セットがあるオーダー明細の供給日を変更した後、毎回収集します。