翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 自動補充
自動補充機能を使用して、インベントリ管理を自動化することで、保持するインベントリの量と、より多くのインベントリを注文するタイミングを決定できます。自動補充は、インベントリ、予測需要をモニタリングし、設定されたインベントリポリシー、注文スケジュール、最小注文数量、ベンダーリードタイムに基づいて項目を自動的に並べ替えることで、インベントリ管理プロセスを合理化します。
自動補充を使用して、ERP にインポートできる発注書リクエストを生成したり、購入システムを使用してサプライヤーの発注書 (POsを作成したりできます。
# キー入力
自動補充は、在庫補充について正確で情報に基づいた計算を行うために、次の入力に依存します。
+ **需要** – 需要データは補充計算の基本的な入力です。このデータは、過去の売上または将来の予測の観点から需要 AWS Supply Chain を把握し、将来のタイムバケットの在庫要件を判断できるようにするのに役立ちます。需要予測または過去の売上履歴を需要データの入力として提供できます。需要予測が利用できない場合は、販売履歴を提供することができ、補充計算に過去の消費量 AWS Supply Chain を使用します。
+ **インベントリ** – 自動補充では、補充計算の入力として手持ち在庫と注文時在庫が使用されます。手元在庫は、需要を満たすために使用できる場所で利用可能な在庫です。注文時在庫は、在庫場所への未処理の購入または転送注文です。需要は、正味供給要件を決定するために、手元在庫と注文在庫から計算されます。
+ **リードタイム** – リードタイムは、注文とアイテムの受け取りにかかる時間です。リードタイムは、どの程度前に注文する必要があるか AWS Supply Chain を判断するのに役立ちます。サプライヤーから注文または調達されたアイテムの場合、リードタイムはサプライヤー/ベンダーのリードタイムを指します。これは、サプライヤーが注文を実行し、商品を配送するのにかかる時間です。内部注文処理、品質チェック、または処理に必要な時間は、リードタイムの一部として含める必要があります。ディストリビューションセンターやフルフィルメントセンターなど、エンタープライズの内部ロケーションから転送されるアイテムまたは製品の場合、リードタイムとは、配送元ロケーションから配送先ロケーションへの輸送と配送に必要な輸送時間を指します。
+ **調達ルール** – 調達ルールを使用して、サプライチェーンのネットワークトポロジをモデル化できます。調達ルールを使用して、さまざまなレベルのロケーション間の関係 (リージョン DC から中央 DC など) や、サプライヤーとそのサイト間の関係を定義します。これらの関係は、製品グループまたはリージョンレベル、または製品またはサイトレベルでモデル化できます。
+ **調達スケジュール** – 自動補充を使用して、実行ごとに項目を定期的にモニタリングして補充したり、補充する項目に事前定義されたスケジュールを設定したりできます。調達スケジュールを使用して、サプライヤーまたは配送スケジュール、および輸送スケジュールに基づいて注文スケジュールを定義します。調達スケジュールを定義して、1 週間に複数回、1 週間に 1 回、または特定の週にアイテムを補充できます。
+ **インベントリポリシー** – インベントリポリシーは、補充要件の促進に使用されるターゲットインベントリレベルを決定するためのキー入力です。インベントリポリシーは、最も詳細な製品レベル、サイトレベル、または製品グループ、製品セグメント、サイト、リージョンなどの集計レベルで設定できます。自動補充は、絶対インベントリレベル、カバー日数、サービスレベルのインベントリポリシーをサポートします。設定されたインベントリポリシーのターゲット値を定義し、ターゲット値 AWS Supply Chain を使用してターゲットインベントリレベルを決定できます。
供給計画に必要なデータフィールドの詳細については、「」を参照してください[供給計画](entities-supply-planning.md)。
# 計画プロセス
補充要件は、項目の設定されたネットワークトポロジに基づいて計算されます。以下は、補充注文の生成に関連するさまざまな計算を記述するために使用するネットワークトポロジの例です。
![\[供給計画プロセス\]](http://docs.aws.amazon.com/ja_jp/aws-supply-chain/latest/userguide/images/Supply_planning_process.png)
自動補充は、スポークノードからハブノードへの転送要件 (リージョン DCs から中央 DC など) を生成し、ハブノードからサプライヤーへの購入要件 (中央 DC からサプライヤーなど) を生成します。次の手順は、補充注文の生成に関連しています。これらのステップは、補充計画の対象となる製品とサイトの組み合わせごとに繰り返されます。ダウンストリームノードの要件は、調達ルール情報に基づいてアップストリームに伝達され、その項目のルートノードに到達するまでプロセスはアップストリームノードで繰り返されます。
![\[供給計画プロセス手順\]](http://docs.aws.amazon.com/ja_jp/aws-supply-chain/latest/userguide/images/Supply_planning_process_procedure.png)
+ **需要処理** – 補充計画設定に基づいて、過去の需要または予測データを AWS Supply Chain 準備します。需要または予測は、補充計画の設定に基づいて、製品、サイト、日、または週のレベルで処理されます。販売履歴または予測データは、製品、サイト、顧客または製品、サイト、チャネルなど、より詳細なレベルで提供されている場合、製品およびサイトレベルで集計されます。同様に、補充計画が週レベルで設定されている場合、日単位の集計が行われます。前の例では、需要はリージョンDCs であるスポークノードから取得され、製品、サイト、日/週レベルで集計されます。消費または需要ベースのインベントリポリシーが使用されている場合、過去 30 日間の需要 (販売履歴) を使用して平均消費量が計算されます。
+ **ターゲットインベントリレベル** – 需要または予測を、設定されたインベントリポリシーとともに使用して、特定の期間のターゲットインベントリレベルを決定します。自動補充は、2 つの異なる補充モデルをサポートしています。
+ 予測駆動型補充
+ 消費ベースの補充
AWS Supply Chain は、予測に基づいてインベントリターゲットを生成します。これらの在庫目標は、需要と供給のリードタイムの変動を考慮して、リードタイムと調達スケジュールに基づいて決定されます。
+ **移管または購入要件** – AWS Supply Chain は、供給 (手持ち在庫 \$1 注文在庫) から将来の期間に予測在庫までの各期間の需要を相殺します。 は、前のステップで計算されたターゲット在庫レベルと同じレベルで予測在庫レベル AWS Supply Chain を維持します。予測在庫レベルとターゲット在庫レベルの違いは、正味供給要件または再注文数量 (RoQ) です。 は最小注文数量 AWS Supply Chain を適用するか、複数の を注文して最終的な移管要件または購入要件 (POR) を生成します。 は、移管またはベンダーのリードタイム AWS Supply Chain を使用して日付別に注文を決定します。ロットサイズのデフォルトは 1.0 で、最小注文数は 0 です。
**計算ロジック**
```
rounding=f(RoQ,MOQ,Lot_Size)
=Lot_Size×Max(RoQ,MOQ)
```
前述の式では、自動補充の四捨五入ロジックについて説明します。 は、 AWS Supply Chain まず再注文数量 RoQ と最小注文数量 MOQ を比較し、最終的な注文提案を取得し、次に実際の数量のロットサイズ係数を乗算します。ロットサイズは、 フィールド *qty\$1multiple* を持つソーシングルールエンティティで設定されます。
+ **要件の伝達** – スポークノードの場合、 はソーシングルール AWS Supply Chain を使用して親ノードを検索し、転送要件をアップストリームノードに伝達します。 AWS Supply Chain 転送リードタイムによって必要な配信日を設定して、親ノードで必要な日付を決定します。 は単一のソーシング AWS Supply Chain のみをサポートします。ハブノードのすべての子ノードまたはスポークノードに対してこのステップが完了すると、 はハブノードで前のステップ AWS Supply Chain を繰り返します。このプロセスは、項目のトポロジのルートノードに到達するまで繰り返されます。
自動補充では、ベンダー向けサイトの発注書リクエストのみが表示されます。ベンダー向けサイトには 2 種類あります。
+ 他のサイトを提供するベンダー向けサイト
+ 他のサイトを提供しないベンダー向けサイト
![\[供給計画プロセス\]](http://docs.aws.amazon.com/ja_jp/aws-supply-chain/latest/userguide/images/Supply_planning_process_procedure2.png)
他のサイトを提供するベンダー向けサイトの場合、再注文数量は子サイトの再注文数量と、独自の需要からの独立した再注文数量です。他のサイトを提供しないベンダー向けサイトの場合、注文数量はサイトの需要予測に基づいて計算されます。ベンダー向けサイトの独立した注文数量は、注文数量の計算と同じロジックに従います。依存する需要は、すべての子サイトの合計です。カバレッジ日数が 7 の場合、RoQ は、対象期間中のすべての注文の数量の合計です。次の例は、サイトごとに 1 つの注文しかない計画期間のシナリオを示し、計算について説明します。
![\[Supply Planning プロセスの例\]](http://docs.aws.amazon.com/ja_jp/aws-supply-chain/latest/userguide/images/Supply_planning_example.png)
# インベントリポリシー
自動補充は、3 つの異なるインベントリポリシーをサポートしています。各ポリシーは異なるアルゴリズムに基づいてプランを計算し、各ポリシーには異なる入力が必要です。
**Topics**
+ [絶対インベントリレベル](absolute-inventory-level.md)
+ [カバー日数](doc-forecast.md)
+ [サービスレベル](service-level.md)
# 絶対インベントリレベル
*絶対数量*を使用してインベントリレベルを管理する場合は、このポリシー設定を使用してターゲットインベントリレベルと RoQ を計算できます。絶対インベントリレベルポリシーは、計算されたインベントリレベル (位置) ではなく、設定されたターゲットインベントリレベルを使用します。ターゲットインベントリレベルは target*\$1inventory\$1qty *の値です。
## 入力とデフォルト
絶対インベントリレベルポリシーには、次の表に示すように、絶対インベントリレベルポリシーの予測、リードタイム、および設定が必要です。
| 必要なデータ | エンティティ | フィールド | 値 | 注意事項 |
| --- | --- | --- | --- | --- |
| インベントリポリシー | inventory\$1policy | ss\$1policy | abs\$1level | NA> |
| インベントリポリシー | inventory\$1policy | target\$1inventory\$1qty | インベントリレベルの数量 | NA> |
| Forecast | 予測 | NA | NA | 平均数量または予測数量。> |
| リードタイム | transportation\$1lane | NA | NA | 送信元の場所から送信先へのリードタイム。 |
| リードタイム | vendor\$1lead\$1time | NA | NA | ベンダーから送信先までのリードタイム。 |
ターゲットインベントリレベルで使用されている *inventory\$1policy データエンティティからの target\$1**inventory\$1qty*
## 順序変更数量の計算
再注文数量 (RoQ) 計算の入力は、ターゲットインベントリレベルと現在のインベントリレベルです。インベントリレベルのレコードがない場合、 はレビューする計画例外 AWS Supply Chain を生成します。
## 計算ロジック
![\[絶対インベントリレベルの計算ロジック\]](http://docs.aws.amazon.com/ja_jp/aws-supply-chain/latest/userguide/images/AbsoluteInventoryLevel.png)
再注文数量は、ターゲットインベントリレベルと現在のインベントリレベルの差です。現在のインベントリレベルがターゲットインベントリレベルよりも高い場合、再注文数量は 0 です。
絶対ポリシーの目標は、各レビュー日に、目的のインベントリレベルに一致するのに十分な手元インベントリがあることを確認することです。内部最大関数は、ターゲットレビュー日 (配信後の最初のレビュー日) より前の追加需要を計算します。カバー期間は、予想される配信日から始まり、ターゲットレビュー日で終了します。現在の手元在庫または配送日が特定の期間の需要をカバーできる場合、再注文数量は 0 です。最大 関数は、追加で注文する必要があるかどうかを決定します。外部 max 関数はインベントリの不足を計算し、注文を行うかどうかを決定します。が他のサイトに提供するサイトの注文数量の計算は、カバー日数 (DOC) インベントリポリシーで説明されているロジックに従って計算されます。
# カバー日数
カバー日数 (DoC) を使用してインベントリレベルを管理する場合、これはターゲットインベントリレベルと RoQ の計算を促進するための適切なポリシー設定になります。DoC インベントリポリシーは、設定されたカバレッジ日数を使用します。このポリシーでは、調達スケジュール (ベンダーレビューカレンダー) やベンダーによる DOC の計算リードタイムは考慮されません。DOC は inventory*\$1policy データエンティティの target\$1doc\$1limit* フィールドに基づいています。 **週次計画では、*target\$1doc\$1limit* は引き続き 1 日の単位を使用することに注意してください。2 週間のカバレッジは 14 日間になります。DoC ポリシーは、予測 (*doc\$1fcst*) または需要 (*doc\$1dem*) で使用できます。*doc\$1fcst* と *doc\$1dem* の違いは予測ソースです。*doc\$1fcst* は予測に基づいており、*doc\$1dem* *は outbound\$1order\$1line* の需要履歴に基づいています。予測ベースのカバレッジ日は予測の P50 を使用しますが、需要ベースの計画では過去 30 日間の需要履歴を使用して平均消費率を計算します。
## 入力とデフォルト
ターゲットインベントリレベルまたはターゲットインベントリ位置 (TIP) は、特定の日付の希望するインベントリ位置またはレベルです。在庫位置には、手元在庫、転送中在庫、または注文時在庫が含まれますが、在庫レベルは手元在庫のみです。インベントリ位置はサービスレベル (sl) インベントリポリシーに使用され、インベントリレベルは *doc\$1fcst*、*doc\$1dem*、*abs\$1level* インベントリポリシーに使用されます。DOC ポリシーには、インベントリポリシーの予測、リードタイム、設定が必要です。
*doc\$1fcst* ポリシーでは、次の情報を提供する必要があります。
| 必要なデータ 1 | エンティティ | フィールド | 値 | 注意事項 |
| --- | --- | --- | --- | --- |
| インベントリポリシー | inventory\$1policy | ss\$1policy | doc\$1fcst | NA> |
| インベントリポリシー | inventory\$1policy | target\$1doc\$1limit | 日数 | NA> |
| Forecast | 予測 | NA | NA | 平均数量または予測数量。> |
| リードタイム | transportation\$1lane | NA | NA | 送信元の場所から送信先へのリードタイム。 |
| リードタイム | vendor\$1lead\$1time | NA | NA | ベンダーから送信先までのリードタイム。 |
カバレッジ日に基づくインベントリポリシーの場合、カバーする日数は *target\$1doc\$1limit* 値です。
## DOC\$1fcst ポリシーの計算ロジック
![\[DOC_fcst ポリシーの計算ロジック\]](http://docs.aws.amazon.com/ja_jp/aws-supply-chain/latest/userguide/images/doc_fcst.png)
## doc\$1dem ポリシーの計算ロジック
![\[doc_dem ポリシーの計算ロジック\]](http://docs.aws.amazon.com/ja_jp/aws-supply-chain/latest/userguide/images/doc_dem.png)
カバレッジポリシーの日数の目標は、各レビュー日に、設定されたカバレッジ日数をカバーするのに十分な在庫が手元にあることを確認することです。式の最初の部分は、次のレビュー日から設定されたカバレッジの終了日までのカバレッジの日数を計算します。合計カバー期間は *DOCP,S*for product *P* and site *S* です。 計算式の 2 番目の部分は、ターゲットレビュー日 (配信後の最初のレビュー日) より前の追加需要を計算します。カバー期間は、予想される配信日から始まり、ターゲットレビュー日で終了します。配信日の現在の手元在庫がこの期間の需要をカバーできる場合、システムは 0 を並べ替えます。最大関数は、追加で注文する必要があるかどうかを決定します。
## 順序変更数量の計算
再注文数量計算の入力は、ターゲットインベントリレベルと現在のインベントリレベルです。インベントリレベルのレコードがない場合、システムはレビューする計画例外を生成します。
![\[注文数量の計算\]](http://docs.aws.amazon.com/ja_jp/aws-supply-chain/latest/userguide/images/roq_calculation.png)
製品 *P*、サイト *S*、日付 *D* の再注文数量は、ターゲットインベントリレベルと現在のインベントリレベルの差です。現在のインベントリレベルがターゲットインベントリレベルよりも高い場合、再注文数量は 0 です。
# サービスレベル
在庫率を使用して在庫レベルを管理する場合は、このポリシー設定を使用して、ターゲット在庫レベルと補充の計算を推進できます。
## 入力とデフォルト
*sl* ポリシーの場合、 Supply Planning には次のフィールドが必要です。これらのフィールドが空の場合、デフォルト値は *null* に設定され、アプリケーションは例外をスローします。
| 必要なデータ | エンティティ | フィールド | 値 | 注意事項 |
| --- | --- | --- | --- | --- |
| インベントリポリシー | inventory\$1policy | ss\$1policy | sl | サービスレベルは *sl* と略されます。> |
| インベントリポリシー | inventory\$1policy | target\$1sl | パーセンテージ値 | 例: 0.8> |
| Forecast | 予測 | NA | NA | 平均数量または予測数量。> |
| リードタイム | transportation\$1lane | NA | NA | 送信元の場所から送信先へのリードタイム。 |
| リードタイム | vendor\$1lead\$1time | NA | NA | ベンダーから送信先までのリードタイム。 |
| 調達スケジュールまたはベンダースケジュール | sourcing\$1schedule と sourcing\$1schedule\$1details | NA | NA | ベンダーが注文を受け入れるカレンダーまたは日数を定義します。 |
## ターゲットインベントリレベルの計算
ターゲットインベントリ位置 (TIP) は、サービスレベル (sl) インベントリポリシーに使用されます。TIP は、特定の日付の希望する在庫位置を表します。TIP には、オンハンドインベントリとオンオーダーインベントリが含まれます。サービスレベルのポリシーに必要な入力は、予測、リードタイム、調達スケジュール (および調達スケジュールの詳細）、サービスレベルの設定です。
![\[ターゲットインベントリレベルの計算\]](http://docs.aws.amazon.com/ja_jp/aws-supply-chain/latest/userguide/images/targetinventorylevel.png)
TIP は予測分布に基づいています。Supply Planning は、クリティカル率 (CR または service\$1level) を適用して分布を予測し、需要を計算し、カバーする日数を合計します。クリティカル率 (サービスレベル) を予測分布に適用する使用可能な方法を以下に示します。
まず、Supply Planning は線形補間を使用して、予測 (P10/P50/P90) の分散に CR を適用します。
![\[予測レベルで CR をディストリビューションに適用する\]](http://docs.aws.amazon.com/ja_jp/aws-supply-chain/latest/userguide/images/service_level.png)
Supply Planning は target\$1sl=0.1 に P10、target\$1sl=0.5 に P50、target\$1sl=0.9 に P90 を使用します。予測エンティティに存在しないパーセンタイルの場合、Supply Planning は線形補間アプローチを使用します。Supply Planning は、P10/P50/P90 に基づいて需要予測の他のパーセンタイルを計算します。P40 (target\$1sl=0.4) と P75 (target\$1sl=0.75): P40=50−1040−10 ×(P50−P10)\$1P10 P75=90−5075−50 ×(P90−P50)\$1P50
Supply Planning が需要を取得すると、需要は合計され、カバーする日数で任意の合計が使用されます。カバーする日数は、次の配信日から次の配信日より後の配信日まで開始されます。
![\[日数でカバーする需要の概要\]](http://docs.aws.amazon.com/ja_jp/aws-supply-chain/latest/userguide/images/service_level_example.png)
前の図に示すように、黄色の期間はカバーする日数です。対象期間の開始日は、計画期間の最初の日から開始されません。その理由は、 Supply Planning が対象とできない日数は注文しないためです。Supply Planning は、失われたすべての売上は回復できないことを前提としています。R1: 調達スケジュールに基づく最初のレビュー日。R2: 調達スケジュールに基づく 2 回目のレビュー日。LT\$1R1: R1 に注文を行うリードタイム。LT\$1R2: R2 に注文を行うリードタイム。R\$1R1: 調達スケジュールに基づくレビュー期間。RD\$1R1: R1 以降の最初のレビュー日。R1\$1R\$1R1 に相当します。DD\$1R1: 送信順序が R1 の場合の配信日。DD\$1R1 = R1 \$1 LT\$1R1。DD\$1R2: 送信順序が R2 の場合の配信日。DD\$1R2 = R2 \$1 LT\$1R2。
次の例は、TIP 計算を示しています。
![\[TIP 計算レベル\]](http://docs.aws.amazon.com/ja_jp/aws-supply-chain/latest/userguide/images/tip_calculation.png)
## 順序変更数量の計算
*sl* 再注文数量計算の入力は、ターゲットインベントリレベルと現在のインベントリレベルです。Supply Planning は、インベントリレベルのレコードがない場合に例外をスローします。
![\[計算ロジックの順序を変更する\]](http://docs.aws.amazon.com/ja_jp/aws-supply-chain/latest/userguide/images/reorder.png)
再注文数量は、ターゲット在庫位置と現在の在庫レベルの差です。現在の在庫位置がターゲット在庫位置よりも高い場合、再注文数量は 0 に設定されます。
# 自動補充の設定
自動補充を使用すると、インベントリ管理を自動化することで、保持するインベントリの量と、より多くのインベントリを注文するタイミングを表示できます。
**Topics**
+ [Supply Planning を初めて使用する](#supply-planning-firsttime)
+ [概要:](#sp_overview)
+ [発注書リクエスト](#purchase_order_requests)
+ [計画の例外](#exceptions)
+ [供給計画設定](#supply-planning-settings)
## Supply Planning を初めて使用する
サプライチェーンを計画する方法と時期を定義できます。
**注記**
Supply Planning に初めてログインすると、その主な機能をハイライトしたオンボーディングページを表示できます。これにより、 Supply Planning の機能に慣れることができます。
1. AWS Supply Chain ダッシュボードの左側のナビゲーションペインで、 **Supply Planning** を選択します。
**Supply Planning** ページが表示されます。
1. **今すぐ始める** を選択します。
1. **プランの選択**ページで、**自動補充**を選択します。
1. **今すぐ始める** を選択します。
1. **Supply Planning** ページで、**Next** を選択します。
説明を読んで Supply Planning が提供する内容を理解するか、「」の「」ページ**の横にある******「」を選択できます。
1. **Supply Planning Setup** ページには、 Supply Planning を設定する 4 つのステップがあります。
+ **名前と範囲** – 供給計画の名前を入力し、供給計画に含める製品とリージョンを選択します。
+ **Horizon and Schedule** – Supply Planning が計画スケジュールを生成する時間枠を定義します。
+ **入力** – Supply Planning でプロセス需要予測を使用する方法を定義します。
+ **出力** – Amazon S3 コネクタに発行する Supply Planning 出力を選択します。マテリアルプランにマテリアル偏差率を使用することもできます。
1. **Horizon and Schedule** では、以下を実行できます。
+ **計画期間** – 以下を定義することで、計画期間を設定できます。
+ **曜日の開始** – 毎週の供給計画を定義できます。たとえば、**週の開始日**が月曜日で、今日が 7 月 3 日の場合、供給計画期間は 7 月 3 日から 9 日になります。
+ **Time Bucketization** – 時間の詳細を定義します。日次オプションと週次オプションがサポートされています。
+ **Time Horizon** – 計画期間を定義します。サポートされている範囲は 1～90 日、または 1～104 週間です。
+ **計画スケジュール** – 供給計画をいつ実行する必要があるかを定義します。
+ **計画の頻度** – 供給計画を実行する頻度を定義します。
+ **開始時刻** – スケジュールされた日に計画を開始するタイミングを定義します。
+ **リリース時間** – Supply Planning が承認された発注書を ERP システムにリリースする時間を定義します。
+ **需要と予測** – 需要予測のソースを定義します。
+ **Demand Planning** – Supply Planning は、*Demand Planning *から公開された予測を使用します。
+ **External** – Supply Planning with は、データレイクの *Forecast* データエンティティに取り込まれた需要予測を使用します。
+ **消費ベースの計画における平均需要計算の過去日数** – 製品、在庫ポリシーが *doc\$1dem* に設定されたサイトの組み合わせの場合、 Supply Planning は *OutboundOrderLine* データエンティティから過去日数の販売履歴を調べて、1 日あたりの平均需要を決定します。平均を生成するときに、30、60、90、180、270、または 365 日のいずれかを選択できます。Supply Planning は、対応する過去の売上データの日数を考慮します。
+ **Forecast Netting ** – 独立需要には、実際の顧客の注文と予測需要の両方が含まれます。Forecast Netting には、これらの需要対策を管理および確認するための 4 つの異なる方法があります。実際の顧客のニーズと予測データを効果的に組み合わせることで、企業はインベントリレベルをより適切に管理し、運用プロセスを改善できます。適切なネットリング方法を選択すると、需要に合わせて供給が調整され、非効率性が軽減され、顧客満足度が向上します。
+ **予測需要を変更しない ** 予測需要を変更しない – 実際の顧客の注文を無視して、供給計画を推進するために予測需要のみに依存します。
+ **予測需要を予測よりも高い実際の注文に置き換え**る – 予測需要と実際の顧客の注文の両方が同じ時間バケット内にある場合は、2 つの値のうち高い方を使用します。
+ **予測された需要に実際の注文を追加する** 予測された需要に実際の注文を追加する – 予測された需要と実際の顧客の注文の両方が同じ時間バケット内に収まる場合は、2 つの値を追加します。
+ **需要時間フェンスと予測消費を有効にする** – 需要時間フェンス内の予測需要は無視されます。タイムフェンスとは別に、予測需要は、予測消費ウィンドウ内で実際の注文数量をサブストレートすることで調整されます。このオプションを使用するには、需要時間フェンス日数、予測消費量のバックワード日数、予測消費量のフォワード日数も指定する必要があります。
+ **Demand Time Fence Days** – 現在の日付から需要時フェンスの日付までの日数。需要時間フェンス日以前のすべての予測は、計画エンジンによって無視されます。
+ **Forecast Consumption Backward Days** – 計画エンジンが逆算して、販売注文の期日から消費する一致する予測エントリを検索する日数。
+ **Forecast Consumption Forward Days** – 販売注文の期日から消費する一致する予測エントリを見つけるために計画エンジンが進む日数。
+ **計画で満たされていない需要 (バックオーダー) を引き継ぎますか?** – **Yes** を選択して、現在の期間に満たされていない注文を次の期間に引き継ぎます。
+ **供給** – 供給関連の入力を定義します。
+ **Past Due Orders** – *InboundOrderLine* データエンティティの注文が配信されず、予想される配信日が実行日より前である場合、デフォルトで Supply Planning はこの注文を無視します。ただし、インバウンドインベントリが在庫を並べ替えることを考慮するように、期限を過ぎた日数を設定できます。例えば、*期限を過ぎた注文*を 7 日間設定し、注文が 4 日前に予定されていた場合、その商品は引き続きインバウンドインベントリと見なされます。
1. [**続行**] をクリックしてください。
1. [**Finish**] を選択してください。
## 概要:
次の例のページに示すように、組織の全体的な供給計画を表示できます。
![\[供給計画の概要\]](http://docs.aws.amazon.com/ja_jp/aws-supply-chain/latest/userguide/images/supply_planning_overview.png)
+ **供給ネットワーク** – 供給ネットワークでは、現在の供給計画で現在の製品、サイト、サプライヤーを表示できます。
+ **インベントリと注文** – 在庫と現在サプライヤーと注文中の在庫を含む、サイト全体の合計在庫を表示します。
+ **購入プラン** – システムで生成された発注書リクエストを表示して、サイトの在庫を補充します。
+ **承認が必要** – Supply Planning は、**「設定**」で設定した承認基準を使用して、発注書の承認リクエストにフラグを付けます。
+ **リリース予定** – **設定**でスケジュールした時点でアウトバウンドコネクタにリリースされる予定の承認済みまたは自動承認済みの発注書リクエスト。
+ **Plan to Purchase Order Conversion** – ERP または購入システムの POsされた発注書リクエスト。正確なメトリクスを計算するには、ソースシステムからの発注書データに、アウトバウンドに発行された発注書リクエスト ID への参照を返す必要があります。このメトリクスは、プランナーが POs、修正アクションを実行するのに役立ちます。
+ **発注書自動化率** – 注文数量に対するユーザーオーバーライドなしで、自動承認されアウトバウンドにリリースされた発注書リクエストの割合。
+ **Supply Insights** – 現在進行中または承認待ちのすべての発注書を表示できます。各インサイトを選択して表示し、アクションを実行できます。詳細については、「[計画の例外](#exceptions)」を参照してください。
自動補充計画の入力、中間計算、出力を含む供給計画レポートをローカルコンピュータにダウンロードできます。
1. 「供給計画**の概要**」ページで、**「エクスポート**」を選択します。
**Export Supply Plan** ウィンドウが表示されます。
1. [**ダウンロード**] を選択します。
## 発注書リクエスト
現在の発注書リクエストの詳細とステータスを表示できます。
1. **フィルター**オプションを使用して、検索条件に従って発注書をフィルタリングできます。は、ベンダー、製品、サイト、注文額、注文数量、およびリクエストされた配送日に基づいて発注書を検索できます。
1. **適用** を選択してフィルター条件を現在の発注書に適用し、**フィルターグループの保存 **を選択して検索フィルターを保存します。
![\[Supply Planning 発注書リクエスト\]](http://docs.aws.amazon.com/ja_jp/aws-supply-chain/latest/userguide/images/supply_planning_purchase_order.png)
1. **Order Quantity** で、**Edit** を選択して数量を表示および更新します。
次の入力に基づいて数量を更新できます。
+ **手元** – 現在在庫があります。
+ **注文時** – 選択したサイトでリリースされた発注書の製品数の合計。
+ **数量の再注文** – インベントリを満たすために必要な製品数量。
+ **必須** – インベントリを満たし、予測を満たすために必要な数量を並べ替えます。
+ **Minimum** – データセットの *VendorProduct.min\$1order\$1unit* で定義されている最小注文数。Supply Planning は、最小数量を満たすように数値を四捨五入します。
+ **推奨** — 調整後の最終的な順序変更数量。
+ **カバー日数** – 補充する日数。
1. **更新** を選択して数量リクエストを更新します。
1. **Product** で、製品を選択して、製品の計画された需要を表示します。
![\[Supply Planning の編集\]](http://docs.aws.amazon.com/ja_jp/aws-supply-chain/latest/userguide/images/Edit_SP.png)
1. **Planned Demand** で、補充計画を表示するサイトを選択します。
1. **補充計画**タブが表示されます。
**注記**
**補充計画**ページが空で表示されます。需要予測を表示するには、必ず製品とサイトを選択してください。
1. **製品/サイトの変更**を選択します。
**製品とサイトの組み合わせの選択**ページが表示されます。
1. **Product** に製品を入力します。
1. Site に****サイトを入力します。
1. **[Apply]** (適用) を選択します。
1. **注文数量の入力** で、提案された**注文数量**を更新できます。
1. **更新と承認**を選択します。
1. **アクション**で、**承認**を選択して発注書を承認します。
1. Show ****ドロップダウンを使用して、ステータスとリリース時間に基づいて発注書をフィルタリングすることもできます。
## 計画の例外
計画できなかった製品サイトの組み合わせのリストを表示できます。**Exception Type** 列には、免除の根本原因が表示されます。インベントリポリシー関連の属性やリードタイムなどの欠落した情報は、データコネクタを介して提供することも、更新されたデータセットを Amazon S3 にアップロードすることもできます。
**Product** では、複数の例外を選択して削除することも、**Product** ヘッダーを選択してすべての例外を削除することもできます。選択したら、**アクション**ドロップダウンから例外**の削除 (複数可)** を選択します。
## 供給計画設定
発注書の計画と実行の方法とタイミングを定義できます。
1. AWS Supply Chain ダッシュボードの左側のナビゲーションペインで、**設定**アイコンを選択します。**Enterprise と Configuration** を選択し、次に **Supply Planning** を選択します。
**プラン設定**ページが表示されます。
1. Supply Planning の設定を編集する[Supply Planning を初めて使用する](#supply-planning-firsttime)には、「」のステップに従います。
1. **「計画の**リセット」で**「計画のリセット**」を選択して既存の計画を削除し、新しい供給計画を開始します。
**注記**
管理者のみが供給計画をリセットできます。
**プラン全体のリセット**ページが表示されます。
1. **はいを選択し、プランをリセット**して、現在の供給計画と既存の発注書リクエストをすべて削除します。
1. **[保存]** を選択します。
# ビジネスワークフロー
自動補充では、在庫補充プロセスを管理するための次のワークフローが提供されます。
![\[在庫補充を管理する自動補充ワークフロー\]](http://docs.aws.amazon.com/ja_jp/aws-supply-chain/latest/userguide/images/business_workflow.png)
+ 補充計画の生成 – Supply Planning は、設定されたスケジュールに従って補充計画を生成します。補充計画の生成に必要な最近の入力データは、 AWS Supply Chain データレイクから取得されます。Supply Planning は、設定データ、トランザクションデータ、計画設定を使用して、発注書リクエストを含む補充計画を生成します。
+ 計画例外の確認 – Supply Planning は、必要な設定データ (リードタイム、調達スケジュールなど) または手元在庫などの必要なトランザクションデータを持たない製品とサイトの組み合わせの*計画例外*を生成します。プランナーは例外を確認し、次の計画サイクルの前に必要なデータを提供して、問題を修正し、補充計画を生成できます。
+ 発注書リクエストの確認と承認 – 生成された発注書リクエストは、プラン設定で設定された承認基準に応じて、自動承認されるか、手動承認のフラグが付けられます。プランナーは、 を使用して発注書リクエストを確認、上書き、または承認できます AWS Supply Chain。
+ ユーザーは、システム生成の発注書リクエストの注文数量、注文日、および予想配送日を手動で更新できます。更新後、ユーザーはページの右上隅にある Run Plan を選択して、これらの注文を確定済みとしてマークし、プランをアドホックモードで再実行できます。計画が実行されると、システムは確定発注書リクエストを保持し、補充計画ページですべての計画対策を再計算します。その後、更新された計画データを Data Lake の supply\$1plan エンティティと自動的に同期します。次回の計画実行では、確定発注書リクエストがクリアされ、現在のデータに基づいて新しい発注書リクエストが生成されます。
+ アウトバウンドへの発行 – 承認済み (自動または手動) 発注書リクエストは、プラン設定で設定されたスケジュールでアウトバウンド Amazon S3 に発行されます。これらの発注書リクエストを ERP または購入システムに統合して実行できます。発注書に変換される発注書リクエストは、インバウンドコネクタを使用して AWS Supply Chain データレイクに取り込まれます。 は、これらの発注書が元の発注書リクエストへの参照を伝達することを AWS Supply Chain 期待します。このリファレンスは、発注書リクエストから発注書への変換を追跡するのに役立ちます。