Sourceのアルゴリズムと予約

Inventory Management の心臓部は、倉庫や店舗で事実上利用可能なすべての製品と手元を追跡します。 Sourceの Selection Algorithm と Reservations システムはバックグラウンドで動作し、売り上げ可能な数量を常に更新し、商品のチェックアウト時に競合が発生しないようにし、お勧めの配送方法を提供します。

NOTE
プログラムによる Inventory Management システムの操作について詳しくは、 開発者向けドキュメントを参照してください。

Source選定アルゴリズム

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

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

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

  • 在庫ごとに、割り当てられたすべてのソースの集計仮想売り出し可能数量を計算します:数量 – ソースあたりの在庫切れのしきい値の集計
  • 売り上げ可能数量から在庫切れのしきい値を減算して、売り上げ超過を防ぎます
  • 注文処理時および出荷時に在庫在庫から差し引いた在庫数量を注文送信時に引当てます
  • 負のしきい値に対する拡張オプションを使用してバックオーダーをサポート

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

  • 一部出荷を出荷し、特定の事業所から少数の製品のみを送付し、後で全受注を完了します。
  • 1 つのソースからのオーダー全体の出荷
  • 複数のソース間で異なる量の出荷を分割し、すべての倉庫と店舗でバランスの取れた在庫を維持します

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

NOTE
SSA の機能は、バーチャル製品とダウンロード製品では異なり、送料は発生しない場合があります。 この場合、システムは請求書の作成時にアルゴリズムを暗黙的に実行し、常に推奨結果を使用します。 バーチャル製品とダウンロード可能製品では、これらの結果を調整することはできません。

Source優先アルゴリズム

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

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

  • 上位から在庫レベルでソースの設定順序を処理します
  • リスト内のオーダー、有効数量およびオーダー数量に基づいて、製品ごとに出荷数量およびソースを推奨します。
  • 注文出荷が入力されるまでリストの下の方に進みます
  • リスト内に無効なソースが見つかった場合はスキップします

カスタム在庫のソースを設定、割り当て、注文します。 在庫のソースの優先順位付けを参照してください。

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

マウンテンバイクの SSA 推奨事項の例

距離優先アルゴリズム

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

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

  • Googleの地図 - Googleの地図 Platform サービスを使用して、発送先住所と発送元住所(住所および GPS 座標)の間の距離と時間を計算します。 このオプションでは、ソースの緯度と経度を使用します。 Geocoding APIDistance Matrix API を有効にしたGoogle API キーが必要です。 このオプションにはGoogle請求プランが必要で、Google経由で料金が発生する場合があります。

  • オフライン計算 - ダウンロードおよびインポートされたジオコードデータを使用して距離を計算し、出荷先住所に最も近いソースを決定します。 このオプションでは、配送先住所と発送元の国コードを使用します。 このオプションを設定するには、コマンドラインを使用して最初にジオコードをダウンロードして読み込むために、開発者の支援が必要な場合があります。

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

カスタムアルゴリズム

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

予約

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

NOTE
予約機能を使用するには、inventory.reservations.updateSalabilityStatus メッセージキューコンシューマーを継続的に実行する必要があります。 実行中かどうかを確認するには、bin/magento queue:consumers:list コマンドを使用します。 メッセージキューコンシューマーがリストにない場合は、開始します(bin/magento queue:consumers:start inventory.reservations.updateSalabilityStatus)。

予約の注文

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

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

受注から引渡しまでの引当

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

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

引当の計算

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

  • 顧客またはマーチャントが注文を行います。
  • 顧客またはマーチャントが注文の全部または一部をキャンセルした場合。
  • 販売者は、現物商品の出荷を作成します。
  • マーチャントは、仮想またはダウンロード可能な製品の請求書を作成します。
  • 商人はクレジット メモを発行します。

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

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

  • StockItem の数量. StockItem 数量は、現在の販売チャネルのすべての物理ソースから集計された在庫量です。 ボルチモアのソースに 20 個の製品があり、オースティンのソースに 25 個の同じ製品があり、リノのソースに 10 個がある例を考えてみましょう。 これらのソースがすべて在庫 A にリンクされている場合、この商品の在庫品目数は 55 (20 + 25 + 10)になります。 (品目が出荷されると、在庫インデクサーは各ソースで使用可能な数量を更新します)。

  • 未払いの予約。 システムは、補償されていないすべての初期予約を合計します。 この数値は常に負の値です。 顧客 A が 10 品目の予約を持ち、顧客 B が品目の予約を 5 に持っている場合、製品合計の未処理予約–15。

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

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

NOTE
在庫切れのしきい値を使用したバックオーダーおよびしきい値を下回る数量の通知の設定も、販売可能数量の計算に影響しますが、これらの設定はこのトピックの範囲外です。 これらの設定について詳しくは、 設定 Inventory Management を参照してください。

予約オブジェクト

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

パラメーター
データタイプ
説明
reservation_id
整数
システム生成 ID
stock_id
整数
商品が割り当てられている在庫の ID
sku
文字列
商品の SKU
quantity
浮動小数点
この予約の項目数
metadata
文字列
この予約のイベントタイプ、オブジェクトタイプ、オブジェクト ID。 例:`{“event_type”:“order_placed”,“object_type”:“order”,

メタデータ event_type には、次の値を含めることができます。

  • order_placed
  • order_canceled
  • shipment_created
  • creditmemo_created
  • invoice_created

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

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

予約のライフサイクル

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

  1. 顧客は 25 単位の商品 SKU-1 を購入します。 予約には、次の情報が含まれています。

    code language-text
    reservation_id = 1
    stock_id = 1
    sku = SKU-1
    quantity = -25
    event_type = order_placed
    
  2. お客様は 20 品目の請求書を送付し、基本的に注文した単位のうち 5 個をキャンセルします。

    code language-text
    reservation_id = 2
    stock_id = 1
    sku = SKU-1
    quantity = 5
    event_type = order_canceled
    
  3. 商人は購入した 20 ユニットを出荷します。

    code language-text
    reservation_id = 3
    stock_id = 1
    sku = `SKU-1`
    quantity = 20
    event_type = shipment_created
    

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

処理済の予約の削除

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

inventory_reservations_cleanup cron ジョブは、inventory.reservations.cleanup メッセージキューコンシューマーとは異なります。 消費者は製品が削除された後、製品 SKU によって予約を非同期で削除しますが、cron ジョブは予約テーブル全体をクリアします。 ストアの設定で「カタログと同期 Stock オプションを有効にする場合、コンシューマーは必要です。 設定ガイド 🔗 の メッセージキューの管理 を参照してください。

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

NOTE
予約の不整合を検出および管理するために使用できる CLI コマンドがあります(Inventory Management CLI リファレンスを参照)。

予約の更新

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

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

  • 送信済み注文 – 複数の製品の注文が送信されると、その金額の予約が入力されます。 例えば、米国の web サイトから 5 つのバックパックを注文すると、その SKU と在庫の -5 の予約が入力されます。 売り出し可能量は 5 減少します。

  • 受注の取消:受注の全部または一部が取り消されると、その金額を決済するために報酬予約が入力されます。 例えば、3 つのバックパックをキャンセルすると、その SKU と在庫の+3 予約が入力され、保留が解除されます。 売り上げ可能量は 3 増加します。

  • 出荷済受注 – 受注の全部または一部が出荷されると、その金額を決済するために報酬予約が入力されます。 例えば、2 つのバックパックを出荷すると、その SKU と在庫の+2 予約が入力され、保留が解除されます。 製品数量は出荷に対して 2 分の 1 直接削減されます。 算出した販売可能数量は、減少した在庫金額に対しても更新されますが、予約の影響を受けなくなります。

予約の更新

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

NOTE
予約を確認する場合は、一連のコマンドラインオプションを使用できます。 確認できるのは、コマンドラインインターフェイスを介した場合のみです。 CLI コマンドを使用する場合、開発者向け支援が必要になることがあります。 Inventory Management CLI リファレンスを参照してください。

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

NOTE
ソースの割り当てを解除すると、すべての数量データがクリアされます。 ソースの再割り当てによって、販売可能な数量、予約、および保留中の注文に関する問題が発生する可能性があります。 ソースの割り当てを解除する前、または他のソースを変更する前に、すべての注文を処理することをお勧めします。 また、新しいコマンドを使用して予約を検出および更新することもできます。 詳細は、「Inventory Management CLI Reference」を参照してください。
recommendation-more-help
c1792860-ac60-428b-ad4b-59517d4ea712