WooCommerceの在庫同期は、ERP、WMS、外部カタログから数量をコピーするだけではありません。課題は、店舗での販売、倉庫での入荷、キャンセル、一時的な予約、手動修正など、異なる時点で行われる判断を調整することです。2つのシステムが異なる数値を示していても、それぞれのタイミングとルールに従って動作していることがあります。
その差異によって、すでに利用できない単位を販売できてしまう場合、またはそれを避けるために購入の各段階で店舗が外部システムを参照または待機する場合にリスクが生じます。前者は過剰販売を引き起こし、後者はカタログ、カート、チェックアウトのパフォーマンスや購入体験を低下させるおそれがあります。アーキテクチャでは、購入体験と運用処理を分離し、各変更を検証可能にする必要があります。
在庫タイプごとの信頼できる情報源を定義する
API、Webhook、スケジュールタスクを選ぶ前に、各数値が何を表すかを定義する必要があります。「在庫」は通常、互換ではない概念をひとまとめにします。
- 物理在庫:実際にあるロケーションに存在する単位。
- 引当済み在庫:継続中の注文に割り当てられた単位。
- 予約在庫:購入中または支払い検証中に一時的に確保された単位。
- 販売可能在庫:商取引ルール、予約、安全在庫に基づき、顧客に提示できる数量。
- 公開在庫:WooCommerceで現在表示または適用されている値と、その更新時刻および更新元。
ERPまたはWMSは通常、物理在庫と倉庫移動の権威ある情報源です。WooCommerceは、カート、注文の状態、および購入セッションに関連付けられた予約の権威ある情報源になり得ます。販売可能性には、たとえば次のような独自のルールが必要になる場合があります。
販売可能在庫 = 物理在庫 - 引当済み在庫 - 予約在庫 - 安全在庫
このルールには明確な所有者が必要です。WooCommerceと外部システムで計算方法が異なる場合、最終数値を交換しても不整合は解決しません。在庫が複数倉庫にまたがる場合は、計算日時、イベントのバージョンまたはシーケンス、影響を受けるロケーションも保存することが推奨されます。
リスクに応じて更新フローを選択する
すべての変更に同じ扱いが必要なわけではありません。夜間インポートは情報提供用カタログには十分かもしれませんが、回転率の高い商品や在庫が少ない商品には不十分です。
イベント、照会、バッチ、ハイブリッドアプローチ
- イベントによる更新:外部システムが在庫変更を発行し、コンシューマーがWooCommerceの利用可能なプロジェクションを更新します。レイテンシは減りますが、再試行、重複、順序の管理が必要です。
- オンデマンド照会:店舗がカートに入る時点または支払い前に在庫状況を照会します。個別の検証としては有用ですが、サプライヤーの在庫可用性を各ページの同期的な依存関係にしてはなりません。
- 定期同期:プロセスが変更をバッチで取得します。大規模なカタログではより単純ですが、実行間の時間枠によって不一致のリスクが高まります。
- ハイブリッドモデル:緊急の変更にはイベント、取りこぼしを回復するためには定期プロセス、重要な商品には最終検証を使用します。
実務では、ハイブリッドモデルによって、購入時の高速な読み取りと低速な在庫運用を分離することがよくあります。WooCommerceはローカルの在庫プロジェクションを提供し、イベントはバックグラウンドでそのプロジェクションを更新し、照合は到達しなかった、または適用できなかったものを検出します。
二重に減算せず購入中に予約する
予約は必ずしも販売ではありません。定義された時点で作成され、有効期限を持ち、キャンセル、支払い失敗、離脱により解放できなければなりません。WooCommerceが注文の作成またはステータス変更時にネイティブ在庫を減算し、さらにERPがその注文を受け取った時点で同じ単位を減算すると、二重減算が生じる可能性があります。
解決には、単一の会計フローを定義する必要があります。たとえば、WooCommerceはローカル予約を記録し、識別可能な予約要求を外部システムへ送信できます。支払いが確定すると、その予約は外部運用に応じて引当または出庫に移行します。期限切れの場合、両者は検証可能な解放を受け取るか、または導出できなければなりません。
予約には最低限、注文またはセッションの識別子、SKUまたはバリエーション、数量、状態、有効期限、固有の操作キーを含める必要があります。集計数量を保存するだけでは不十分です。識別性がなければ、何を解放すべきか、または在庫不足をどう説明するかを把握できません。
可視の在庫減少、運用上の予約、物理的な移動は別々の遷移です。それぞれがどこで発生するかを決めることで、エラーの原因を隠す後続の手動調整を回避できます。
キュー、冪等性、順序で変更を処理する
在庫更新は、カタログ、カート、またはチェックアウトのWebリクエスト内で重い処理として実行すべきではありません。エンドポイントはメッセージを迅速に検証・永続化でき、非同期コンシューマーが後で更新を処理し、結果を記録して制御された再試行を適用します。
キューは、イベントの急増をWooCommerceおよび外部システムの処理能力から切り離します。ただし、キューだけで重複や順序外イベントを修正することはできません。各メッセージには冪等な識別子が必要であり、プロセッサーはその操作をすでに適用したかを記憶しなければなりません。
冪等性キー = 発信元 + イベント種別 + 操作識別子
各SKU、ロケーション、または在庫を共有する組み合わせについて、信頼できるシーケンスまたはタイムスタンプを保持することが推奨されます。新しいイベントの後に古いイベントが到着した場合、明示的なルールなしに上書きしてはなりません。グローバルな順序が保証されない場合は、イベントを受け入れ、エンティティを照合対象としてマークし、修正前に権威ある状態を照会するほうが望ましいです。
能力も制限する必要があります。最大バッチサイズ、コンシューマーの並行性、漸増待機を伴う再試行、上限を超えたメッセージ用の障害キューです。無効な認証情報や存在しないSKUを無期限に再試行しても、遅延が蓄積され、問題が隠されるだけです。
店舗を停止させずに遅延と停止へ対応する
店舗には縮退ポリシーが必要です。ERPが応答しない場合、各商品詳細ページが外部システムの応答待ちでブロックされるのは合理的ではありません。ページでは最後に判明したプロジェクションを利用できますが、データの鮮度と商品の重要度に応じて何が起こるかを組織として決定する必要があります。
- 在庫が潤沢な場合は、遅延についてアラートを出しながら、公開済みの在庫状況を維持できます。
- 在庫が少ない商品または需要の高い商品では、購入を非表示にする、保守的なマージンを適用する、または確定前に追加検証を要求できます。
- すでに開始された注文では、販売メッセージと例外ポリシーが定義されている限り、最終確認まで進行を許可できます。
注文確認も長時間タスクに依存すべきではありません。購入意思を永続的に記録し、後続プロセスを起動する必要があります。外部予約が失敗した場合、その注文には、確認、支払い保留、またはキャンセルのための明確な運用ステータスが必要であり、顧客への曖昧な応答やブロックされたプロセスであってはなりません。
最近の判断を消さずに差異を照合する
照合では、WooCommerceのプロジェクションを、権威ある在庫情報源および有効な予約と比較します。これはスケジュール実行するほか、インシデント、メッセージの蓄積、外部サービスの復旧後にも実行する必要があります。
すべての数量を盲目的に置き換えるべきではありません。修正によって、数秒前に作成され、まだ伝播していない予約が上書きされる可能性があります。調整を適用する前に、両者のタイムスタンプ、バージョンまたはシーケンス、保留中の操作、アクティブなローカル予約を確認する必要があります。説明できない差異は、特に支払い済み注文または負の在庫を持つ商品に影響する場合、レビューに回す必要があります。
有用な照合では、原因を分類します。イベント未受信、処理失敗、手動変更、SKUの誤った関連付け、販売可能在庫の計算差異、または合意済みの時間枠内にある通常の遅延です。原因を記録せずに数値を修正すると、同じエラーが再発します。
統合を有効化する前のトレーサビリティとテスト
各変更には監査証跡を残す必要があります。SKUとバリエーション、発生元、変更前後の数量、移動タイプ、イベント識別子、関連する注文または予約、受信日時、有効日時、結果、拒否理由です。この情報により、顧客がなぜ在庫ありと見たのか、なぜ単位が解放されたのか、なぜ商品が調整されたのかに答えられます。
段階的な有効化の前に、テストでは単に正しく更新されるだけでなく、運用条件をシミュレートする必要があります。
- 最後の1単位に対する同時購入が2件発生するケース。
- 重複、遅延、順序外で受信されるイベント。
- キャンセル、支払い拒否、予約の期限切れ、返品。
- ERP、WMS、またはカタログAPIの一時的な停止。
- 在庫変更の急増と、蓄積したキューの復旧。
- WooCommerceおよび外部システムでの手動編集。
- バリエーション、キット、チャネル間で共有される商品、SKU変更。
現在の設計を評価するための判断リスト
- 物理在庫、販売可能在庫、予約、引当について、信頼できる情報源は定義されていますか。
- 予約がいつ作成、確定、解放されるかを正確に把握していますか。
- 各操作は冪等であり、注文、SKU、発生元に関連付けられますか。
- 重い更新はカタログ、カート、チェックアウトの外部で処理されていますか。
- 古いデータまたは利用不能な外部サービスに対する明示的なポリシーはありますか。
- 照合は最近の操作を保護し、差異の原因を分類しますか。
- eコマースチームと運用チームは、記録を通じて特定の在庫可用性を説明できますか。
いずれかの回答が否定的である場合、優先すべきなのは、ただ同期頻度を上げることではありません。再設計では、状態、データの所有権、予約遷移、障害からの復旧に焦点を当てる必要があります。これにより、WooCommerceの在庫同期は、外部在庫を単一のブロッキングポイントにせずに販売を保護できます。
