オーダー納期回答での設定問題のトラブルシューティング

いくつかの問題とその解決方法の詳細を取得します。

問題	解決
通常、「オーダーの作成」ページには、各オーダー明細の手持有効数量のステータスが表示されます。在庫あり在庫切れ低在庫しかし、かわりにメッセージが表示されます。 `No Data was Retrieved` このメッセージは、ソース・ルール、割当セットまたはATPルールに問題がある可能性があることを示します。	ソース・ルールおよび割当セットを作成します。「転送元」ソース・タイプを使用するグローバル・ソース・ルールを作成します。割当セットを作成し、その割当レベルを「グローバル」、「品目」または「カテゴリ」に設定します。「組織」、「品目と組織」、または「カテゴリと組織」には設定しないでください。割当セットにグローバル・ソース・ルールを割り当てます。詳細は、サプライ・チェーンのソーシングを参照してください。 ATPルールを作成します。 ATPルールを作成し、その納期回答モードを「サプライ・チェーン有効数量検索」に設定します。「コンポーネントとリソースの検索」を選択します。供給タイプを「手持」に設定します。 ATPルールを品目または組織に割り当てます。詳細は、「割当および納期回答ルール」で始まる章を参照してください。サイト・レベルでMSP_DEFAULT_ASSIGNMENT_SETプロファイル・オプションを有効にします。この手順で前に作成した割当セットを使用します。「納期回答プロファイルの管理」を参照してください。権限がない場合は、プロファイル・オプションを有効にするように要求を送信します。これは、オーダー納期回答の設定タスクを管理する管理者に送信します。「Order Promisingサーバーのリフレッシュと起動」スケジュール済プロセスを実行します。グローバル・ソース・ルールをすでに設定しても、`「データは取得されませんでした。」`が引き続き表示される場合は、次の方法を試してください。割当セットの割当レベルを「グローバル」、「品目」または「カテゴリ」に設定したことを確認します。割当レベルを「品目カテゴリ」に設定した場合は、マスター・レベルでそのカタログを制御し、そのカテゴリを割り当てたことを確認してください。
「オーダーの作成」ページのオーダー明細の手持ステータスが、在庫にあるものと一致しません。オーダー納期回答では、ソース・ルール、ATPルール、供給データ、およびオーダーからの詳細を使用して、オーダー明細の追加時に在庫レベルを確認します。ルールに、手持有効数量がある組織が含まれていることを確認する必要があります。	割当セットにソース・ルールがあることを確認してください。ソース・ルールの割当レベルに「組織」という値が含まれていないことを確認してください。手持有効数量がある可能性があるソース組織が、ソース・ルールに含まれていることを確認してください。手持供給のデータを収集します。「プラン入力」ページの「供給および需要」領域を使用して、供給データを収集していることを確認します。
オーダー納期回答ルールの作成時に、品目、在庫組織またはその他の参照データが見つかりません。オーダー納期回答サーバーでこのデータが使用可能であることを確認する必要があります。	データを収集します。「プラン入力」ページまたは「供給ネットワーク・モデルの保守」ページを使用して、データを収集したことを確認します。「設定および保守」作業領域の「収集されたオーダー参照データのレビュー」ページで収集データをレビューします。

問題

解決

通常、「オーダーの作成」ページには、各オーダー明細の手持有効数量のステータスが表示されます。

在庫あり
在庫切れ
低在庫

しかし、かわりにメッセージが表示されます。

No Data was Retrieved

このメッセージは、ソース・ルール、割当セットまたはATPルールに問題がある可能性があることを示します。

ソース・ルールおよび割当セットを作成します。
1. 「転送元」ソース・タイプを使用するグローバル・ソース・ルールを作成します。
2. 割当セットを作成し、その割当レベルを「グローバル」、「品目」または「カテゴリ」に設定します。「組織」、「品目と組織」、または「カテゴリと組織」には設定しないでください。
3. 割当セットにグローバル・ソース・ルールを割り当てます。
  
  詳細は、サプライ・チェーンのソーシングを参照してください。
ATPルールを作成します。
1. ATPルールを作成し、その納期回答モードを「サプライ・チェーン有効数量検索」に設定します。
2. 「コンポーネントとリソースの検索」を選択します。
3. 供給タイプを「手持」に設定します。
4. ATPルールを品目または組織に割り当てます。
  
  詳細は、「割当および納期回答ルール」で始まる章を参照してください。
サイト・レベルでMSP_DEFAULT_ASSIGNMENT_SETプロファイル・オプションを有効にします。この手順で前に作成した割当セットを使用します。「納期回答プロファイルの管理」を参照してください。

権限がない場合は、プロファイル・オプションを有効にするように要求を送信します。これは、オーダー納期回答の設定タスクを管理する管理者に送信します。
「Order Promisingサーバーのリフレッシュと起動」スケジュール済プロセスを実行します。

グローバル・ソース・ルールをすでに設定しても、「データは取得されませんでした。」が引き続き表示される場合は、次の方法を試してください。

割当セットの割当レベルを「グローバル」、「品目」または「カテゴリ」に設定したことを確認します。
割当レベルを「品目カテゴリ」に設定した場合は、マスター・レベルでそのカタログを制御し、そのカテゴリを割り当てたことを確認してください。

「オーダーの作成」ページのオーダー明細の手持ステータスが、在庫にあるものと一致しません。

オーダー納期回答では、ソース・ルール、ATPルール、供給データ、およびオーダーからの詳細を使用して、オーダー明細の追加時に在庫レベルを確認します。ルールに、手持有効数量がある組織が含まれていることを確認する必要があります。

割当セットにソース・ルールがあることを確認してください。
ソース・ルールの割当レベルに「組織」という値が含まれていないことを確認してください。
手持有効数量がある可能性があるソース組織が、ソース・ルールに含まれていることを確認してください。
手持供給のデータを収集します。
「プラン入力」ページの「供給および需要」領域を使用して、供給データを収集していることを確認します。

オーダー納期回答ルールの作成時に、品目、在庫組織またはその他の参照データが見つかりません。

オーダー納期回答サーバーでこのデータが使用可能であることを確認する必要があります。

データを収集します。
「プラン入力」ページまたは「供給ネットワーク・モデルの保守」ページを使用して、データを収集したことを確認します。
「設定および保守」作業領域の「収集されたオーダー参照データのレビュー」ページで収集データをレビューします。

Global Order Promisingリプレイ・データの抽出

グローバルOrder Promisingリプレイ・データの抽出スケジュール済プロセスを使用すると、販売オーダーのスケジュール時に発生する問題のトラブルシューティングに役立ちます。たとえば、有効数量のチェック時、販売オーダーの自動スケジュール時、データの収集後にオーダーを再度納期処理し、予定日を上書きする場合などです。たとえば:

納期回答では、供給を使用して販売オーダーを納期回答しますが、他の需要ではすでにその供給が消費されています。
需要に関する情報が十分でないか、需要に関する一部の側面が事前定義済制限を超えているため、納期回答は販売オーダーを正確に納期回答できません。
その他の技術的な問題が発生。このスケジュール済プロセスを使用して、問題の原因となる状況をトレースできます。

ノート: このスケジュール済プロセスは、Oracle製品チームから実行を求められた場合、またはGlobal Order Promisingのサービス・リクエストを作成したときにのみ実行します。

演習

Order Promising作業領域に移動し、「タスク」>「Order Promisingオプション」をクリックして、「リプレイ・データ・セットの生成」オプションにチェック・マークが付いていることを確認します。
問題の原因となるステップを実行します。

スケジュール済プロセス作業領域に移動し、グローバルOrder Promisingリプレイ・データの抽出スケジュール済プロセスを実行します。

これらのパラメータを使用して、スケジュール済プロセスが参照するデータをフィルタします。

パラメータ	説明
要求タイプ	トラブルシューティングが必要なリクエストのタイプを選択します。 RepromiseScheduleSalesOrders CheckAvailability AutoSchedule ScheduleSalesOrders
要求日	トラブルシューティング中の品目を納期回答するリクエストを受け取った日付を選択します。スケジュール済プロセスでは、リクエスト・タイプ・パラメータで設定した値に従って選択できる日付がフィルタされます。 2023年6月1日と2023年6月5日に空き時間を確認し、リクエスト・タイプをCheckAvailabilityに設定したとします。リクエスト日を2023-06-01または2023-06-05に設定できます。詳細は、有効数量のチェックを参照してください。
要求者ユーザー	リクエストを行ったユーザーを選択します。スケジュール済プロセスによって、リクエストを実行したユーザーに応じて選択できるユーザーがフィルタされます。 Diane Choが2023年6月1日に利用可能状況をチェックし、June Tsaiが2023年6月5日に利用可能状況をチェックするとします。リクエスト・タイプをCheckAvailabilityに設定し、リクエスト日を2023-06-01に設定した場合は、リクエスト元ユーザーをDiane Choにのみ設定できます。ユーザーがOrder Management作業領域からリクエストを実行した場合、Order Managementはユーザーの名前を送信せず、かわりに一般値をPromisingに送信する場合があります。これが発生した場合は、Requested-by Userをその汎用値に設定します。
販売オーダー番号	トラブルシューティングする必要がある販売オーダーを識別する番号を選択します。スケジュール済プロセスでは、リクエスト・タイプ、リクエスト日およびリクエスト・ユーザーで設定した値に従って、選択できるオーダー番号がフィルタされます。 Diane Choが、6月1日に販売オーダー76546と販売オーダー76546に対して可用性をリクエストするとします。 Request TypeをCheckAvailability、Request Dateを2023-06-01、Requested-by UserをDiane Choに設定した場合、Sales Order Numberを76546または76546に設定できます。
リプレイ・キー	品目を納期処理するリクエストを一意に識別する値を選択します。スケジュール済プロセスによって、選択できる値がフィルタされます。アプリケーションが品目の納期回答リクエストを複数回送信した場合、納期回答では一意の連番値を使用して各リクエストが識別されます。最も高い値を選択して、最新のリクエストのトラブルシューティングを行います。

すべてのパラメータが必要です。

スケジュール済プロセスによって、GOPReplay_ replayKey zipファイルが作成されることに注意してください。これには、ReplayHeader_ replayKey csvファイルおよびReplayData_ replayKey csvファイルが含まれます。
「Order Promisingのオプション」ページの「リプレイ・データ・セットの生成」オプションからチェック・マークを削除します。続行する前に、このオプションを無効にする必要があります。長期間にわたって有効にしたままにすると、デプロイメントのパフォーマンスに影響する可能性があります。
GOPReplay_ replayKey zipファイルをハード・ドライブに保存し、分析のためにOracle製品チームに送信します。
Oracle製品チームと協力して問題を解決してください。

重要な詳細は、「Order Managementでスケジュール済プロセスを使用するためのガイドライン」および「Global Order Promisingリプレイ・データの抽出」を参照してください。

詳細なヘルプ

詳細なヘルプは、次を参照してください。