STEP 01
同じ棚の在庫を共有しているか、店ごとに分けているか
自社ECとモールAにそれぞれ10個と表示されていても、物理的に20個あるとは限りません。同じ10個を両方で売る共有型なのか、店ごとに数量を割り当てた型なのかを先に決めます。色・サイズなどを分ける管理単位がSKUです。商品全体ではなく、同じSKU・対象拠点の販売に使える数で考えます。
注文に確保済みの商品、破損品、まだ着いていない入荷予定を、今販売できる数へ混ぜないようにします。総数自体が実物と合わないときは、同期の設定より先に棚卸で照合します。間違った数を速く送っても、売れる数は正しくなりません。
店ごとの数を合計して仕入れを判断しないことも大切です。共有型の表示は同じ実物を重複して数えている可能性があるため、仕入れ判断に使う在庫は基準側へ戻って確認します。
STEP 02
商品対応と、誰が数を更新するかを決める
LOGILESSの在庫連携は、LOGILESSからモール・カートへ送る一方向の仕組みです。各店舗の商品とLOGILESSの商品を結び付ける商品対応表が必要で、商品コードが同じ場合でも省略できません。受注取込の自動実行など、開始前に必要な設定も公式手順で確認します。
商品名が同じだけでは、色・サイズまで一致したことにはなりません。店側の商品や選択肢を作り直したときは、送信対象が古いページや別のバリエーションへ向いていないかを見ます。複製した商品ページも、元ページの設定がそのまま正しく使えるとは考えません。
基準側、販売先、手動CSV、別アプリが同じ数量を更新すると、後から書いた数が残ることがあります。誰が入庫・返品・棚卸を反映し、どこから売る数を送るかを決めます。全店舗の値を手でそろえる前に、更新元と対象SKUを確かめましょう。
STEP 03
注文が入ってから、他店の数が減るまでを追う
在庫連携には、注文を販売先から取り込む段階と、減った販売可能数を販売先へ送る段階があります。『注文が入った時刻』『基準側に取り込んだ時刻』『数量を送った時刻』『販売先で変わったことを確認した時刻』を分けると、止まっている場所を調べられます。
LOGILESSはフリー在庫が変動した商品を一定間隔で送信し、受注タイミングによって売り越しが起こると説明しています。販売先による送信量の制約もあるため、すべてのSKU・販路が同じ秒数で必ず反映されるとは案内しません。
下の最後の1個の例では、もう一方の店へ0が届く前に注文が入ることが原因です。連携が故障していなくても、更新の間に受けた注文は残ります。対応できる注文と不足する注文を確認し、再送信しただけで解決済みにしないようにします。
STEP 04
最後の1個や集中販売は、共有するかを選び直す
架空の例として、販売に使える実物が1個で、自社ECとモールAへ各1個を表示した状態を考えます。自社ECで1個売れ、0への更新がモールAへ届く前にAでも1個売れると、注文は2個に対して実物は1個です。画面の1＋1は、実物2個という意味ではありません。
数量を厳格に制限したい商品や短時間に大量に売れる商品について、LOGILESSは在庫連携を行わないよう案内しています。こうした条件では、販売先を一つに絞る、物理在庫の範囲で販路別に割り当てるなど、共有方式そのものを見直します。実行可否と停止・再開方法は利用する各システムで確かめます。
予備在庫を引く設定もありますが、何個引けば絶対に防げるという共通値はありません。共有する数量、注文の集中、更新までの時間で変わります。予備を大きくした結果、売れる物まで表示0になっていないかも確認します。
STEP 05
数が合わないときは、送信履歴と販売先を照合する
LOGILESS公式FAQは、商品対応表、自動連携の有効状態、送信履歴、予備在庫・割当率・上下限などの設定を確認先として挙げています。基準のフリー在庫と販売先の表示が違っても、意図した配分の結果という場合があります。数字が違うだけで障害と決めつけません。
販売先で直接数を変えたり、商品CSVに古い在庫数を含めたりすると、次に基準側のフリー在庫が変動するまで、その数が残る場合があると説明されています。『待てば元に戻る』と一律に判断せず、どの操作が最後に数を変えたかを調べます。
送信済みの履歴があっても、正しい商品ページへ反映されたことまで確認します。商品情報の変更で対応がずれた場合などは、利用先の手順に沿って直し、必要な再送後に販売先を見ます。原因不明のまま全商品の再送や上書きを繰り返さないようにします。
STEP 06
販売を戻す前に、既存注文と表示の両方を確かめる
売り越しの恐れがある場合は、対象商品の新規受注を止めるなど、自店で可能な抑止策を先に選びます。同期だけを無効にしても、販売先に古い正の在庫が残れば売れ続ける場合があるため、購入できる状態そのものを確認します。
実物、確保済み注文、販売に使える数を照合し、不足する注文の対応は担当へ残します。そのうえで商品対応、連携設定、対象販路の表示を確かめ、影響を絞って再開します。実決済や自動出荷が動く可能性のあるテストは避け、利用先が提供する安全な確認手順を使います。
日常は、失敗の通知だけでなく、取込や送信が長く止まった商品、手動変更、商品ページの作り直しも確認のきっかけにします。同期の速さだけでなく、異常に気づき、売り続けない状態へ戻せることを運用の目標にします。