シナリオ有限キャパシティウィンドウを使用した、購入前の集荷および出荷割り当ての計算
Get Checkout Shipment Plan (Pre-Purchase) API は、1 つ以上の複数数量のオーダー明細で構成されるカートまたはチェックアウトの出荷日、配達日、および出荷内訳情報を提供します。 この API は、 出荷 と ピックアップ 配達方法の両方をサポートします。
カートには、ユーザーが注文する予定のアイテムが保持されます。これは、カート・ページに表示されます。 カート・ページは、ショッパーが商品詳細ページから選択したすべてのアイテムおよびアイテム数量を表示する、オンライン・ショッピング・エクスペリエンスのサマリー・ページです。 各オーダー明細には、複数の数量を持つ固有の SKU ID が含まれています。
チェックアウト・ページは、ショッパーがオーダーを確認する前に表示されるオンライン・ショッピング・エクスペリエンスのページです。
Get Checkout Shipment Plan (Pre-Purchase) API は、すべてのオーダー明細のアイテム、在庫状況、およびキャパシティーの在庫状況に基づいて、最適なソリューションを計算します。 オーダー明細の数量を 1 つの出荷ノードから満たすことができない場合、API は、複数の出荷にわたってオーダー明細を分配します。 このプロセスでは、オーダー明細ごとに複数の配達見積が指定されます。
配達日に加えて、出荷日も各出荷で提供されるため、ショッパーは、割り当てられた出荷ノードから特定のアイテムが出荷されたことを認識できます。 詳細については、「 Get Checkout Shipment Plan (Pre-Purchase) API」を参照してください。
このAPIは、タグ固有のフルフィルメント要件に対応するため、各明細行に割り当てられた tagNumber 、 lotNo、および revisionNo の在庫タグ識別子 batchNo、またはをサポートしています。 タグ識別子が指定された場合、APIは一致するタグ付き在庫からのみデータを取得します。 この応答には、下流工程での追跡を可能にするため、各明細行に割り当てられた固有のタグ識別子が含まれています。 詳細については、 「シナリオ:特定の在庫要件に合わせたタグ対応のチェックアウト割り当て」 を参照してください。
配達予定日は、オーダー明細と出荷の両方で計算されます。 この API は、最初の配達日 (カート全体の最も早い配達日) と最後の配達日 (カート全体の最後の配達日) を返します。
v1 と v2 の違い
| 機能 | バージョン 1 | バージョン2 |
|---|---|---|
| 輸送期間 | 輸送期間 (および要約) | ゾーン間の輸送期間 |
| 容量の計算 | キャパシティー・スケジュール、オーバーライド、および処理時間 | カテゴリー ID を使用して容量を区別し、スロットおよび数量を使用して容量を追跡します。 タグを使用して、関連するキャパシティーを検索することもできます。 計算の処理時間は考慮されません。 |
| 約束日の計算と見積もり | できるだけ早く (デフォルト・オプション) | できるだけ速く出荷を最小化するためのオプション (デフォルト・オプション) |
ゾーン間の輸送期間
輸送期間とは、運送会社サービス (例えば、出荷会社のグラウンド) が、ピックアップ後に、ソース・アドレスから宛先アドレスにパッケージを配達するために要する時間のことです。 このパラメーターを構成して、テナント情報、アイテム ID、宛先情報などのパラメーターを使用して、購入前の要求カートでの配達予定日および出荷割り当てを計算します。 アプリケーションは、インテリジェントな約束日を設定する前に、在庫の分配、使用可能なキャパシティー、運送会社サービスのピックアップなどの詳細を考慮します。
別々に出荷
オーダーによっては、例えば、オーダーされたアイテムが壊れやすい場合などに、アイテムを別々に出荷する必要がある場合があります。 また、API は、オーダー内の他のアイテムから独立してアイテムを出荷するという制約も考慮します。 このようなオーダーを実行するために、API はそのようなアイテムごとに個別のパッケージを生成します。 ただし、出荷を最小化するために、個別に出荷された複数のアイテムを同じ出荷に含めることができます。
ノード・リストのオーバーライド
フルフィルメントの決定時に、事前選択されたノードまたはノードのリストのキャパシティーおよび在庫状況を計算して表示するように API を構成することができます。 「オーバーライド・ノード・リスト」の詳細については、 「オンライン購入・店頭受け取り(BOPIS)」 をご覧ください。
要求された配送およびピックアップ日
予定配達日およびピックアップ日の計算中に、API は、要求された日付以降の最も早い配達日またはピックアップ日を返すようになりました。
配送の希望納期に関する詳細については、 「シナリオ:店舗からの発送(SFS)」 を参照してください。 受け取り希望日に関する詳細については、 「オンライン購入・店頭受け取り(BOPIS)」 をご覧ください。
ストアに出荷
配達方法が pickupに設定されている場合、API は転送ルールが一致するかどうかを評価します。 一致が見つかった場合、API は、別のノードから、顧客が在庫をピックする元のノードに在庫を移動する可能性を考慮します。 詳しくは、 ストアへの出荷を参照してください。 API Transfer rules に関する詳細については、 「APIを使用した転送ルールの作成と削除」 を参照してください。
配信最適化オプション
- 最大出荷日数のソフト制約内で出荷を最小化しながら、商品がショッパーに配達されるように日付を計算します。 これはデフォルト・オプションです。 このオプションを利用するには、以下のようにします。
- ユーザー・インターフェースを使用して、出荷グループの 「デフォルトの輸送時間」 を構成します。 これは、商品をショッパーに配達する必要がある最大輸送期間です。 この期間は、運送サービスおよび独自の SLA に対して運送会社が提供するサービス・レベル契約 (SLA) を考慮して構成できます。
- 出荷を最小化するには、API を使用して
considerMaxSLADaysをtrueに設定します。
- 商品が可能な限り迅速にショッパーに配達されるように日付を計算します。 できるだけ速く配信するには、
considerMaxSLADaysをfalseに設定します。
カスタム属性を使用してプロミス・ルールを拡張する
ユーザー・インターフェースを使用して、新規カスタム属性を追加します。 次に、API Get
Checkout Shipment Plan (Pre-Purchase) (有限のキャパシティウィンドウを使用する)を利用する際は、` sourcingCriteria parameter` を使用して、APIの入力にカスタム属性を渡してください。 詳細については、 「カスタム属性の設定」 を参照してください。
チェックアウト・ビューのオプション
- オーダー明細の形式
- オーダー明細フォーマットでは、各オーダー明細には、出荷ノードから調達された 1 つ以上の出荷割り当てと、関連付けられたフルフィルメント数量が含まれます。 各オーダー明細のフルフィルメント数量の合計は、要求された合計数量で構成されます。
- 出荷明細の形式
- 出荷明細フォーマットでは、ショッパーは、各出荷にどの SKU が含まれているかを知ることができます。 出荷は、それぞれがさまざまなフルフィルメント数量を持つ複数の SKU で構成される場合があります。
不足数量の処理
また、 Get Checkout Shipment Plan (Pre-Purchase) API は、インベントリーおよびキャパシティーの不足の可能性についても説明します。 この場合、 Sterling Intelligent Promising は、部分数量を提供し、不足量を報告できる出荷ノードを見つけようとします。 不足金額は、要求された SKU 数量と、セラーが満たすことができない SKU 数量との差です。
カートのユース・ケース
複数のオーダー明細をサポートするだけでなく、出荷割り当ての計算をモデル化して、カートのユース・ケースで単一のオーダー明細要求を処理することもできます。 標準カートのユース・ケースでは、セラーは、オーダー明細ごとに個別の配達日の見積もりをリストしたい場合があります。 このアクションは、単一のオーダー明細要求で Get Checkout Shipment Plan (Pre-Purchase) API を使用して実行できます。
キャパシティー可用性の計算
タグ別に容量を分類し、各容量カテゴリーに可用性を割り当てることができます。 例えば、キャパシティーをピックアップのキャパシティーとしてタグ付けしたり、出荷のキャパシティーとしてタグ付けしたりすることができます。 そのため、配達方法に基づいてキャパシティーにタグを付けることができます。 設定が完了すると、API Get Checkout Shipment Plan (Pre-Purchase) は割り当ての決定を行う際、指定されたスロットに対して設定された容量を考慮します。
出荷割り当ての計算の例
e-コマース・サイトでの典型的なショッパー・チェックアウト・ワークフローについて考えてみます。 ショッパーは、それぞれ異なる要求数量を持つ 2 つのアイテムをカートに追加します。 この例では、要求された SKU ごとに在庫とキャパシティーの両方について在庫状況が存在することを前提としています。
| 注文明細番号 | アイテム | 数量 |
|---|---|---|
001 |
sku01 |
5 |
002 |
sku02 |
2 |
| 注文明細番号 | 出荷番号 | 出荷ノード | 配送日付 | アイテム | 割り当て済み数量 |
|---|---|---|---|---|---|
001 |
1 | node01 |
7月1日 | sku01 |
2 |
001 |
2 | node02 |
7 月 10 日 | sku01 |
3 |
002 |
1 | node01 |
7月1日 | sku02 |
1 |
002 |
3 | node03 |
7 月 5 日 | sku02 |
1 |
結果の概要
Node01は、sku01およびsku02を 1 つの出荷で配送できます。 ただし、要求されたすべての在庫があるわけではないため、残りの在庫は代替出荷ノードから調達する必要があります。Node02はsku01の残りの数量を満たすことができますが、sku02の在庫がないため、2 番目の出荷が形成されます。Node03はsku02を満たすことができ、sku01の在庫がないため、残りのsku02要求数量を満たすために 3 番目の出荷が形成されます。
その結果、最初の配達日は 7 月 1 日、最後の配達日は 7 月 10 日になります。 ショッパーは、要求されたオーダー明細を一緒に満たす 3 つの別個の配達を受け取ります。 このシナリオでは不足は検出されませんでした。
| 出荷番号 | 注文明細番号 | 出荷ノード | 配送日付 | アイテム | 割り当て済み数量 |
|---|---|---|---|---|---|
| 1 | 001 |
node01 |
7月1日 | sku01 |
2 |
| 1 | 002 |
node01 |
7月1日 | sku02 |
1 |
| 2 | 001 |
node02 |
7 月 10 日 | sku01 |
3 |
| 3 | 002 |
node03 |
7 月 5 日 | sku02 |
1 |
プロミシング計算の理解とトラブルシューティングに関する詳細については、 「プロミシング計算」および「診断API」 を参照してください。
- リード・タイム
- 詳細については、 「リードタイム」 を参照してください。
- 可用キャパシティー
- 詳細については、 「Capacity サービス」 を参照してください。
この機能を使用するには
Insert or update available capacityAPI 、[ ] を使用してください。 - 在庫状況
- 詳細については、 「需要と供給」 を参照してください。
- 運送業者ピックアップ
- 詳細については、 「配送業者の集荷スケジュールの設定」 を参照してください。
この機能を使用するには、
Define node carrier pickup scheduleAPI を使用します。 - 運送会社の輸送時間
- 詳細については、 「キャリアの輸送時間の設定」 を参照してください。
この機能を使用するには、
Upload transit duration (and optionally transit delay) by shipping zonesAPI を使用します。 - PICK 配送の場合、ショッパーからの半径