ソースアルゴリズムと予約

心 Inventory Management は、倉庫や店舗で事実上利用可能な、手元にあるすべての製品を追跡します。 ソース選択アルゴリズムと予約システムはバックグラウンドで実行され、販売可能な数量の更新、衝突のチェックアウト、推奨される出荷オプションを維持します。

ソース選択アルゴリズム

Source Selection Algorithm （SSA）は、在庫に設定されたソースの優先順位を使用して、ソースと出荷の最適な一致を分析および決定します。 注文出荷時に、アルゴリズムは、選択したアルゴリズムに従って差し引くソース、使用可能な数量および金額の推奨リストを提供します。 Inventory Management は、優先度アルゴリズムを提供し、新しいオプションの拡張をサポートします。

複数の配送元、グローバル顧客、様々な配送オプションや手数料を持つ配送業者を使用すると、実際に利用可能な在庫を把握し、最適な配送オプションを見つけることが難しい場合があります。 SSA は、すべてのソースの在庫販売可能数量の追跡から、出荷の計算および推奨の作成まで、作業を行います。

在庫の追跡 – 在庫とソースを使用して、SSA は受信した製品リクエストの販売チャネルをチェックし、使用可能な在庫を決定します：

出荷の管理 - アルゴリズムは、注文の処理と出荷に役立ちます。 アルゴリズムを実行して、商品の配送に最適なソースに関するレコメンデーションを取得したり、選択内容を次の値に上書きしたりできます。

SSA は、サードパーティのサポートと、費用対効果の高い出荷を推奨するためのカスタムアルゴリズムに対して拡張可能です。

ソースの優先度アルゴリズム

カスタム在庫には、ストアフロントを通じて利用可能な製品在庫を販売および出荷するためのソースの割り当てられたリストが含まれています。 ソース優先度アルゴリズムは、在庫の割り当てられたソースの順序を使用して、オーダーの請求および出荷時にソースごとの製品控除を推奨します。

実行時のアルゴリズムは次のとおりです。

カスタム在庫のソースを設定、割り当て、注文します。 参照： 在庫のソースの優先順位.

次の例では、マッピングされたソースの順序、有効数量、推奨ソースおよび控除および出荷金額を詳しく示します。 最上位のソースは、英国の直送の荷主で、使用可能な数量は 240 です。

距離優先アルゴリズム

距離優先アルゴリズムでは、出荷先所在地の事業所がソース事業所と比較され、出荷を履行する最も近いソースが決定されます。 距離は、読み込んだデータベースの場所またはGoogleの方向（車の運転、歩く、または自転車）を使用して、ある場所から別の場所へ移動するのに費やした物理的な距離または時間によって決定されます。

出荷履行の最も近いソースを検索するための距離と時間を計算するには、次の 2 つの方法があります。

設定するには、設定を選択し、Google API キーや配送データのダウンロードなど、追加の手順を実行します。 参照： 距離優先アルゴリズムの設定.

カスタムアルゴリズム

Commerce では、ソースに優先順位を付ける代替アルゴリズムを追加するためのカスタム開発および拡張機能をサポートしています。 例えば、地域に基づいて 1 つの優先アルゴリズムを設定し、在庫費用または顧客属性に基づいて別の優先アルゴリズムを設定できます。 在庫コストが変更されると、実装でアルゴリズムを簡単に変更して、コストを最小限に抑えることができます。

予約

在庫引当では、製品の在庫数量を即時に控除または追加するのではなく、受注が出荷または取消されるまで在庫金額が保持されます。 予約はバックエンドで完全に機能し、在庫レベルで販売可能な数量を自動的に更新します。

予約の注文

予約注文の送信時に販売可能数量から差し引かれた在庫数量に保留が適用されます。 予約は在庫レベルで行われ、注文の請求、出荷、キャンセルなどが行われるまで数量と照合してカウントされます。 受注の出荷時に、SSA の推奨事項を使用するか、ソースごとの数量控除項目を手動で入力できます。 出荷されると、予約は自動的に決済され、数量が差し引かれます。 販売可能数量は、更新された数量とシステムに残っている予約金額で在庫について再計算されます。

次の図は、注文中および出荷までの予約プロセスを定義するのに役立ちます。

顧客が注文を送信します。 Commerce 現在の在庫販売可能数量を確認します。 在庫レベルで十分な在庫が利用可能な場合、予約は（その在庫の）製品 SKU を一時的に保持し、販売可能な数量を再計算します。

受注の請求後、ソースから控除および出荷する製品金額を決定します。 出荷が処理され、選択した 1 つ以上のソースから顧客に送信されます。 数量はソース在庫数量から自動的に差し引かれ、予約決済されます。 詳細と例については、を参照してください。 受注ステータスおよび予約について.

引当の計算

次のイベントが発生すると、システムによって各製品の予約が作成されます。

予約は追加専用の操作で、イベントのログに似ています。 初期予約には負の数量の値が割り当てられています。 オーダーの処理中に作成される後続の予約はすべて正の値です。 注文が完了すると、商品のすべての予約の合計は 0 になります。

システムは、新しい注文に対応して予約を発行する前に、注文を満たすのに十分な販売可能な品目があるかどうかを判断します。 次の数量が計算に組み込まれます。

したがって、顧客の注文が 40 （55 + -15）単位未満である限り、マーチャントは着信注文を履行できます。

オーダーの処理を完了すると（完了、取消、クローズ）、そのオーダーの範囲内のすべての予約は次のように解決されます 0. これにより、すべての販売可能な数量保留がクリアされます。

予約オブジェクト

予約には、次の情報が含まれます。

メタデータ event_type 次の値を指定できます。

現在、メタデータオブジェクトタイプは、である必要があります order、オブジェクト ID は注文 ID です。

今後のリリースでは、顧客が買い物かごに商品を追加する際に、予約を作成できる可能性があります。 各商品は 15 分など一定の時間に予約できるので、お客様は買い物を続けながら商品を予約できます。 このタイプの予約を有効にすると、追加のタイプの情報がメタデータに含まれる場合があります。

予約のライフサイクル

次の例は、単純な注文に対して生成される予約のシーケンスを示しています。

三 quantity 値の合計は 0 になります（–25 + 5 + 20）。 既存の予約は変更されません。

処理済の予約の削除

この inventory_cleanup_reservations cron ジョブは SQL クエリを実行して、予約データベーステーブルをクリアします。 デフォルトでは、毎日午前 0 時に実行されますが、時間と頻度は設定できます。 cron ジョブは、数量値の合計が 0 である完全な予約シーケンスを見つけるためにデータベースに問い合わせるスクリプトを実行します。 同じ日（または設定された他の時間）に発生した特定の製品のすべての予約が補正されると、cron ジョブは予約をすべて一度に削除します。

この inventory_reservations_cleanup cron ジョブはと同じではありません inventory.reservations.cleanup メッセージキューコンシューマー。 消費者は製品が削除された後、製品 SKU によって予約を非同期で削除しますが、cron ジョブは予約テーブル全体をクリアします。 コンシューマーは、 カタログと同期 ストア設定の「在庫」オプション。 参照： メッセージキューの管理 が含まれる 設定ガイド.

多くの場合、1 日に作成されたすべての初期予約は、その日に補償されません。 この状況は、顧客が cron ジョブが開始される直前に注文を行った場合や、銀行振込などのオフラインの支払い方法で購入した場合に発生する可能性があります。 補正された予約シーケンスは、すべて補正されるまでデータベースに残ります。 各予約の合計が 0 であるため、この方法では予約計算が妨げられることはありません。

予約の更新

注文と製品金額の変更が完了すると、 Commerce 予約報酬を自動的に入力します。 これらの保留を更新またはクリアするために、管理者またはコードを通じて報酬を入力する必要はありません。 予約は、数量を保留する、または保留金額を消去する（予約を補償する）ために入力された予約の影響のみを受けます。

その仕組みを次に示します。

注文のフルフィルメント、商品のキャンセル、クレジットメモの発行などが完了した場合は、すべての予約を補償でクリアする必要があります。 補償が予約をクリアしない場合は、スタシスで保持された数量がある可能性があります（販売には利用できず、出荷されません）。

注文が保留されている在庫の製品からすべてのソースを削除すると、予約が保留になっている可能性があります。