予約数

ノードまたはネットワークの予約の作成

ノードまたはネットワークのどちらの予約の場合も、予約 ID をカスタマイズする機能を使用できます。 詳しくは、 カスタム予約 ID を使用した予約の作成を参照してください。

ノード優先順位の動作を使用した予約

ネットワーク・レベルの予約が作成されると、システムは、在庫数量をブロックする前にネットワークの可用性を考慮します。 一部の複雑なシナリオでは、1 つ以上のノードが複数のネットワークの一部になっているため、すぐに過剰な販売シナリオが発生する可能性があります。

例えば、 Node1 に 5 つの数量があり、 Node2 に 7 つの数量の可用性があるとします。 2 つの分配グループが DG1 および DG2 として作成され、両方が同じノードを持つ場合、両方とも 12 数量の同じ可用性を監視します。 この従来の動作では、一方の分配グループに対して作成された予約は、他方のグループを認識しません。 これは、 DG1 と DG2 の両方が 12 の数量を予約して過剰販売につながる可能性があることを意味します。

この振る舞いを克服するには、セラーは、これらのネットワーク・レベルの予約をコミットされていない予約として追跡し、それらをノード・レベルの予約に変換して、過剰販売のリスクを軽減する必要があります。 分配グループのノード優先順位予約は、ネットワークからノードへの予約変換を実行する際のセラーの労力を最小限に抑えるために、予約ロジックで導入されます。

ノード優先順位の予約との基本的な違いは、システムが、要求された数量を受け入れたときに、分配グループ内の個々のノードとネットワークの両方で在庫チェックを実行するという点です。 同じノードを共有するすべてのネットワークが最新の在庫ピクチャーを持つように、予約数量がネットワーク・レベルではなくノードに割り当てられます。 分配グループ定義に複数のノードが存在する場合、予約はノード優先順位の値の順序で行われます。

ノードが考慮される順序を構成するために、ユーザーは分配グループ内の各ノードの優先順位の値を定義できます。これは、複数のノードが同じ優先順位の値を持つことができるためです。 タイ・ブレーカーは、最も古い在庫が最初に予約されているノードです。
詳しくは、 Distribution Group APIを参照。

例えば、 DG1 には、ノード優先順位シーケンスとして [Node2, Node1, Node3, Node4] があります。 これは、 Node2 の可用性が常に最初に予約されることを意味します。 Node2 が枯渇すると、予約要求数量が満たされるまで、システムは後続の優先順位ノードにトラバースします。

予約数量の更新中

予約の有効期限の定義

ノードまたはネットワークの予約を作成するとき、個々の予約行レベルまたは同じ参照を持つすべての予約に対して有効期限タイムスタンプを定義することができます。 予約の有効期限が切れると、予約された数量は可用性プールに戻される。 その時点で、可用性APIは更新されたインベントリを反映し、サブスクリプションが適切であれば、関連するイベントが公開されるかもしれない。 イベントには productAvailbaility, dgAvailability, supplyAvailbility イベントが含まれる。 詳しくは、 イベントフォーマットを参照。

カートまたは参照による予約の拡張

在庫予約の検索

在庫予約の検索では、アイテム、参照、または予約IDで予約を検索することができます。 また、APIの助けを借りて在庫予約を検索することもできます。 Search Reservations APIを使用します。

在庫予約を検索する手順の詳細については、 参照または予約IDによる在庫予約の検索を参照してください。

予約の削除

注文が変換される際に、選択した予約を削除したり、需要更新の一部として使用することができます。

予約状況

以下は、出荷またはピックアップに応じて、特定のノード、特定の分配グループ、および特定の配達方法に対して行うことができる予約タイプです。