シナリオ:転送ルール
在庫をノード間で移動することは、お客様のフルフィルメントネットワークのすべての拠点で戦略的に在庫レベルを管理するために重要です。 在庫を移動して、アイテムの流通を最適化し、在庫が戦略的に重要な場所で常に利用可能であることを確保することができます。 Sterling Intelligent Promising 在庫が特定の場所で少なくなった場合などに、ノード間で在庫を移動させる転送ルールを作成する機能を提供します。 この機能により、転送ノードに十分な在庫を確保し、出荷準備が整ったノードやフルフィルメントノードが必要なときに在庫を提供できるようになります。
転送ルール
- 店頭での受け取り。
- 特定のフルフィルメントノードで特別な処理が必要なアイテム、例えば自転車など。
- 梱包ノードにおけるバンドル処理。
- 少数のフルフィルメントノードで在庫を低く抑える。
- 梱包コストの削減。
転送ルールは、まずすべての有望なルールが評価された後にのみ考慮されます。 転送ルールの主な役割は、ある場所から別の場所に転送される際にアイテムが通る経路を決定することです。
- アイテム
- 履行ノード
- カスタムソーシング属性
転送ノード
複数の場所にまたがって在庫を維持することはできますが、その在庫が適切に管理されていない場合、コストがかさむ可能性があります。 Sterling Intelligent Promising が提供する柔軟性は、例えばピーク時に顧客の需要を満たすために、在庫を配送センターから店舗に移動させるのに重要です。 特定の転送ノードを数か所の拠点に指定し、多くの異なるフルフィルメントノードに分散させるために、在庫の大半を保持することができます。 このアプローチを使用する場合、ほとんどの在庫を転送ノードに保管し、フルフィルメントノードに分配します。 このアプローチにより、オンライン、ピックアップ、店舗での注文に対応するために、ほとんどのフルフィルメントノードで在庫を低水準に維持することができます。
引継ぎルールと顧客による受け取り
- コストを最小限に抑えるため、各店舗では、来店客や取り置き注文に対応するために、少量の在庫のみを保管しています。 大量在庫は配送センターに保管されています。 戦略上、フルフィルメントマネージャーは、転送ノードとして機能するいくつかの配送センターを選択します。 これらのノードは、大量の転送をサポートするために、大量のアイテムを保持しています。
- 顧客がピックアップ用に注文すると、配送センターは顧客ピックアップ用のノードに在庫を移す。 また、在庫切れの際には、転送ノードからストアに素早く転送されます。
転送を設定するには、転送用の新しいルールのクラスが利用可能です。 これらのルールは、在庫を特定のフルフィルメントノードに転送する転送ノードを定義するために使用されます。
Ship-to-Storeシナリオでピックアップするアイテムの要件を定義するには、Checkout Assignment APIを使用できます。 詳細については、 Get Checkout Shipment Plan (Pre-Purchase) APIおよび Get Optimized Checkout Plan (Pre-Purchase) APIを参照してください。
例:店頭受取と宅配の配送ルール
シナリオ: 買い物客が 10 月 30 日までに店頭受け取りまたは自宅配送で T シャツ 4 枚と靴 4 足を注文します。
店舗に在庫がない場合、配送センターなどの転送ノードから注文を満たす転送ルールを作成することができます。 その後、次の図のように、商品は店舗での受け取り用に発送されるか、顧客の住所に発送されます。
- まず 、Woodbury 転送ノードには 、Colonie 転送ノードに転送可能なTシャツ3枚と靴3足があります。
- コロニーの転送ノードは転送のみを受け付け、 ウッドベリー からTシャツ3着と靴3足の転送を受け付けます。
- 次に、 コロニーの転送ノードには、配送に含めることができるTシャツ1枚と靴1足があります。
- 最後に 、コロニー は、11月7日の配達日までに利用可能で転送されたアイテムを店舗または顧客の自宅住所に配送するフルフィルメントノードとして選択されます。
転送ルールの制限
- ニューパルツ転送ノードには利用可能なアイテムがすべて揃っているわけではなく、転送できるのは T シャツのみです。 また、納品日は顧客の納品日に間に合わないほど早すぎます。
- コロニー転送ノードは転送のみを受け付け、他のノードにアイテムを転送することはできません。 ただし、このノードは、受け取り用の店舗や自宅住所など、他のノードにアイテムを配送することができます。
サンプルチェックアウト 割り当て API レスポンス
{
"earliestDeliveryTime":"2024-11-07T12:00:00.000Z",
"latestDeliveryTime":"2024-11-07T12:00:00.000Z",
"backordered":[ ],
"cartLines":[
{
"lineNo":2,
"itemInfo":{ "itemId":"T-Shirt", "unitOfMeasure":"EACH", "productClass":"NEW", "segment":"MERCH", "segmentType":"ONLINE" },
"quantity":4.0000
},
{
"lineNo":1,
"itemInfo":{ "itemId":"Shoes", "unitOfMeasure":"EACH", "productClass":"NEW", "segment":"MERCH", "segmentType":"ONLINE" },
"quantity":4.0000
}
],
"shipments":[
{
"shipmentNo":1,
"fulfillingNode":"Colonie-NY",
"carrierService":"FedEx_Ground",
"expectedShipTime":"2024-11-07T12:00:00.000Z",
"deliveryTime":"2024-11-07T12:00:00.000Z",
"cartLineList":[
{ "lineNo":2, "quantity":4.0000 },
{ "lineNo":1, "quantity":4.0000 }
],
"transferShipments":[
{
"transferShipmentNo":1,
"transferredFrom":"Woodbury-NY",
"transferCarrierService":"FedEx_Ground",
"transferShipTime":"2024-11-06T12:00:00.000Z",
"transferDeliveryTime":"2024-11-06T12:00:00.000Z",
"transferLineList":[
{ "lineNo":1, "quantity":3.0000 },
{ "lineNo":2, "quantity":3.0000 }
]
}
]
}
]
}
顧客の注文に応えるために転送ルールを使用する際には、出荷可能在庫と顧客の注文に応えるために転送可能な在庫に影響を与える出荷数量と出荷要件を考慮することが重要です。
この例では、 ニューヨーク州ウッドベリーにある転送ノード から、Tシャツ3枚と靴3足が転送されます。
ニューヨーク州コロニーの転送ノードでは、顧客が店舗で受け取るか、または顧客の自宅住所に送付される、Tシャツ4枚と靴4足を含む1件の出荷がサポートされます。
processingTimeForInboundTransfers が0秒に設定されているため、 transferDeliveryTime は expectedShipTime と同じです。 この期間を長くすると、最終ホップの履行を許可する前に、受信転送の処理に余裕を持たせることができます。