分配グループ
分配グループは、配送センター (またはノード) のネットワークであり、1 つ以上の配送センターおよびストアを含むことができます。 分配グループは、主に地理的位置に基づいて作成されます。
セラーは、分配グループを作成して管理することができます。各分配グループには、オーダー・フルフィルメントのために複数のノードを含めることができます。 この場合 Promising service、これらの配布グループを使用して、プロミス処理中の計算APIが対象とするノードのリストを制限することができます。
ノード全体での集約を考慮するには、以下の目的ごとにディストリビューショングループを作成する必要があります
- 在庫
- Inventory service で在庫水準や安全在庫ルールなどの機能を使用する場合は、これが必要です。
- ソーシング
- ディストリビューショングループが有望なルール、推定配信日(EDD)、およびチェックアウト割り当てに必要である場合、ソーシング目的を割り当てる必要があります。
- 調達
- 注文を満たすためにノードの転送を検討している場合は、転送ルールにアクセスするためにこの配布グループを作成する必要があります。
注 :配布グループは、名称と目的によって一意に識別されます。 DG1 ( node1、 node2 )をSOURCING目的で設定するが、同じノードの在庫も追跡する必要がある場合は、INVENTORY目的で新しい DG2 ( node1、 node2 )を作成する必要があります。 また、配布グループの目的を変更することはできません。 そのため、配布グループを削除し、正しい目的で再作成する必要があります。
詳細については、 「配布グループの作成」 およびAPI Manage DG を参照してください。
出荷場所が近接しているからといって、必ずしも配送グループを作成する必要はありません。 分配グループを作成して、自分のノードと外部サプライヤーを区別することができます。
例えば、以下の図は、東海岸や中央海岸などの複数の分配ノード・グループを示しています。

未割り当て要求
未割り当て需要とは、特定のノードに関連付けられていない需要を指す。 このような需要は、顧客からの注文や、販売による今後の顧客ニーズの予測によって生まれることがある。 未割り当ての需要は、将来の注文の可能性を表すため、在庫計画の際に重要である。
- 未割り当て需要の要因
- 以下は、未指定要求の原因となる可能性のある要因である:
- 在庫または生産能力の不足
- 需要を満たすのに十分な在庫や生産能力がないかもしれない。
- 計画上の制約
- 割り当てルール、リードタイム、ノードの可用性は、システムが供給を割り当てることを妨げる。
- データの問題
- 計算ミスのため、誤った需要予測や注文入力が行われ、未割り当ての需要が発生する。
- タイミングの不一致
- 時には、需要に見合う供給が適切な時期や場所で行われないこともある。
- 未割り当て需要の影響
- カスタム・サービス
- 未達成の注文が発生し、注文の遅延、注文のキャンセル、売上の損失、コストの増加につながる可能性がある。
- 可用性
- 未割り当ての需要が注文処理に計上されない場合、不正確な在庫量計算につながり、過剰約束や過小在庫につながる可能性がある。
- 未割り当て需要の検討
- 未割り当てのデマンドがディストリビューショングループの可用性に考慮されるようにするには、 considerUnassignedDemand の値を trueに設定する必要があります。 詳細については、APIを Define distribution group 参照してください。
- 例
- DG1、注文処理に参加する流通グループとして検討する。 オーダーは捕捉され、参加しているノードは、未割り当ての需要がノード割り当てによって割り当てられた需要に変換されるように、オーダーを履行する。
分配グループ定義でのノード優先順位の構成
Distribution Group API (PUT
configuration/distributionGroups/{distributionGroupId}) は、ノードの優先順位を取ります。 Distribution
Group PUT API を使用して、分配グループのノードの優先順位を設定します。
この例では、分配グループ
この例では、分配グループ
DG1 のノード優先順位は、 Node2 を優先順位 1、 Node1 を優先順位 2、 Node3 を優先順位 3、 Node4 を優先順位 4 として設定されています。{ "shipNodes":[
{ "shipNode" : "node2", "priority" : 1},
{ "shipNode" : "node1", "priority" : 2},
{ "shipNode" : "node3", "priority" : 3},
{ "shipNode" : "node4", "priority" : 4}
]
}ノード優先順位の例
- 例 1: ノード優先順位を考慮したネットワーク予約
- それぞれのノード内の数量を持つノード優先順位は、以下のように割り当てられます。DG1 での合計可用性は 5 + 10 + 2 = 17 です。
ノード 数量 優先度 Node1 5 数量 優先度 1 Node2 10 数量 優先順位 2 Node3 2 数量 優先順位 3
5 数量の DG1 に対して予約が行われたとします。 システムは、分配グループの優先順位定義に従って、2 つの数量の Node3 と 3 つの数量の Node2 に対して在庫を分配します。
v2Reservation のPOST APIに関する詳細については、 「日付による予約」 を参照してください。 - 例 2: 同じノードを共有する他の分配グループに対するノード優先順位の予約の効果
- ネットワークに対してネットワーク予約が正常に作成されると、要求された数量は優先順位ノードの 1 つで保留されます。 同じノードを共有している配信グループがある場合、それらの可用性にも影響が及びます。
例えば、 DG1 には、ディストリビューショングループ構成と各ノードの可用性を持つ以下のノードがあります。Item1 が 2021 年 1 月 28 日に DG1 アイテムに対して 2 つの数量の予約を行った場合、 Node2 はノード優先順位が 1 であっても在庫がないため、2 つの数量の Node1 に対して予約が行われます。表 1. Item1のノード可用性 ノード 数量 優先度 Node1 200 2 Node2 0 1 Node3 10 3 Node4 50 4 { "availabilityType": "SELL", "lines": [ { "deliveryMethod": "SHP", "distributionGroup": "dg1", "lineId": "1", "quantity": 2, "totalReservedQuantity": 2, "reservations": [ { "expirationTs": "2021-01-28T00:15:00Z ", "id": "5040f3e2-2af0-4f50-bcc4-d515b410b25b", "shipNode": "node1", "quantity": 2 } ] } ] }重要: 複数のノードが同じ優先順位を持つ場合、タイ・ブレーカーは、インベントリーが最も多いノードに基づいています。 - 例 3: 単一ノードの利用可能数量を上回るノード優先順位の予約
- 同じセットアップの DG1を使用して、 DG1での予約要求が 202 数量あるとします。 Node1 では 200 数量しか使用できないため、複数のノードが予約のためにピックされます。 次に、システムは残りの2つの数量を Node3 に対して予約します。
結果として得られる予約ペイロードは以下の通りです。 Node1 で200個、 Node3 で2個確保されています。{ "availabilityType": "SELL", "lines": [{ "deliveryMethod": "SHP", "distributionGroup": "dg1", "lineId": "1", "quantity": 202, "totalReservedQuantity": 202, "reservations": [{ "expirationTs": "2021-01-28T00:20:00Z ", "id": "ad8af5d4-0d14-4eaa-a5d4-210cb8677176", "shipNode": "node1", "quantity": 200 }, { "expirationTs": "2021-01-28T00:20:00Z ", "id": "0cb34fe8-f313-41eb-9117-c77b61745c59", "shipNode": "node3", "quantity": 2 } ] } ] }