判断の出発点
まず各事実の正本を決めます。物理在庫、販売可能数、価格、注文状態は同じシステムが管理するとは限りません。「双方向同期」の一言で済ませず、方向、遅延、競合処理を別々に定めます。
具体例で考える
架空の店舗に10個あり、2個が引当済み、1個が検品待ちなら、この例の規則では販売可能数は7個です。返品の返金が完了しても、検品が必要なら販売可能とは限りません。
選択肢とその負担
イベント方式は反映の遅れを減らせますが、重複と取りこぼしを扱います。まとめ処理は確認しやすい一方で時差ができます。定期照合は説明できない差を発見します。業務が許容できる遅れに合わせて組み合わせます。
見落としやすい点
商品名だけで照合せず、安定したID、単位、種類、通貨を対応させます。遅れた価格変更が受注済みの注文へどう影響するかと、競合の判断者を決めます。両方を闇雲に上書きしないでください。
接続実装の前に在庫の動きを定義する
販売可能七個の例に注文、取消し、返品を加えます。確保時点、未払い確保の期限、解放イベントを決めます。出荷後の取消しは出荷前とは異なります。返品は合意した検品後に販売可能へ戻します。運用が遷移を説明し、連携担当が実装・試験します。
商品コードを品種、保管場所、単位と対応付けます。箱と単品を曖昧な数量で共有しません。セットの構成品消費や対応のない商品の保留も定めます。価格は通貨、税の扱い、受注価格確定時点を明示し、業務の明示的要求なしに遅れた更新を過去の注文へ反映しません。
接続が切れた状態でも受け入れを試す
ERPが切れた間に二つの架空注文が残り在庫を争う例を試します。販売停止、管理された取り寄せ、別の承認済み確保方法を事業側が選びます。接続処理が方針を作ってはいけません。古さと対応を促す期限を示し、過去在庫を現在値として売らないようにします。
復旧後は同じ識別子と基準時刻で比較します。時差と欠落移動を区別し、照合報告に担当者と訂正理由を残します。元のイベント識別子で再処理し残高を確認します。重複や返金前の返品も含め、整った正常系だけで一貫性を判断しないでください。
依頼前に確認すること
どちらが在庫を引き当てるか。注文中に切断したらどうするか。未解決差分は誰が見るか。注文、取消、返品の例を連携設計へ持ち込んで規則を試します。