店舗とオンラインで在庫を一元管理するには？連携すべき情報

店舗とオンライン販売で同じ在庫情報を共有すれば、お客様に一貫した案内ができます。まず、各数量がどの商品と場所を示すのか、どの商品を販売できるのか、どのシステムが変更を受け付けるのかを決めます。こうした定義を決めずに二つの合計数を連携すると、スタッフが同じ数字を見ても解釈が異なることがあります。

まず、二つの店舗で扱う一つの商品から始めます。数量を整理し、販売、お客様の取り置き、返品、店舗間移動の流れを確認します。小売業の運営責任者は、スタッフやサプライヤーと具体的な手順を確認してから、お客様に表示する在庫状況を信頼できます。

数量ごとに管理責任を決める

以下の会社、数値、役割分担は架空の例です。北店と南店で1個ずつ数える、容量350 mlの青いマグカップ（SKU MUG-BLUE-350）を考えます。各販売チャネルの商品IDと店舗IDを、それぞれ該当する記録に正しく対応付けます。別サイズやセット商品が同じ在庫数を誤って共有しないようにします。

この例では、商品記録でバリエーションと単位を定義します。在庫台帳が商品と店舗ごとの確定在庫を管理します。レジとオンライン注文システムは識別情報付きの在庫変動を送信し、オンラインカタログは台帳から算出した在庫状況を表示します。不一致は運営責任者が調査します。店舗スタッフは承認済みの調整に実数を報告し、複数のシステムの在庫を個別に上書きしません。

北店の実在庫10個は、取り置き2個、受注済み3個、検品待ち1個、販売可能4個で構成されます。南店の実在庫6個は、取り置き1個と販売可能5個です。実在庫数にはこれらが含まれているため、別途加算しないでください。入荷予定数は別に管理し、返品された商品は実在庫に一度だけ数えます。

これらはこの例で定めた業務上の定義です。 Shopifyの在庫に関するガイダンスも商品と店舗ごとに、実在庫、販売可能、受注済み、販売不可の数量を区別しています。ただし、各用語はそのサービスの文脈で理解する必要があります。現行のガイダンスでは、下書き注文の予約は受注済みとして扱われ、「reserved」は別の販売不可状態です。店舗で「取り置き」と呼ぶ業務を、そのままサービスの「reserved」項目に対応付けられるとは限りません。

項目を対応付ける前に、各システムでの意味を記録してください。 Microsoftのシステム間の概念変換に関するガイダンスでは、似て見える業務概念も変換が必要な理由、継続的な保守、遅延の可能性を説明しています。ここで重要なのは、連携を通じて在庫変動の意味を保つことです。

四つの一般的な在庫変動を確認する

以下の各例は、上記の数量に戻って始めます。ここで示すのは運用案であり、特定のプラットフォームの初期設定に関する説明ではありません。

販売時に出荷前の在庫を引き当てる

会社の引当ルールに従い、台帳が北店のマグカップ1個分のオンライン注文を受け付けたとします。販売可能数は4個から3個に減り、受注済みは3個から4個に増えます。商品はまだ店舗にあるため、実在庫は10個のままです。スタッフが出荷すると実在庫は9個に減り、受注済みは3個に戻ります。ページ表示や決済情報だけでは、引当が確定したとは言えません。

取り置きには解除ルールが必要

スタッフがお客様の受け取り用に北店のマグカップ1個を取り置きます。この架空のモデルでは、販売可能数が4個から3個に減り、お客様の取り置きは2個から3個に増えます。会社は有効期限と、取り置きを解除する担当者または手順を決める必要があります。キャンセルや期限切れで販売可能数を戻せるのは、その商品が別の注文に引き当てられたり販売されたりしていない場合だけです。Shopifyの下書き注文による予約は、受注済みへの別途対応付けが必要です。

返品商品は販売可能になる前に入庫する

販売済みのマグカップ1個を受け取ると、北店の実在庫は10個から11個に、検品待ちは1個から2個に増えます。販売可能数は4個のままです。検品後、販売可能にするか、販売不可として記録します。返金と実際の商品の受け取りは別の処理です。どちらが済んだのかスタッフが把握できるようにします。

店舗間移動は出庫と入庫を記録する

再び初期状態から始めます。スタッフが識別番号付きの店舗間移動で、北店の販売可能なマグカップ2個を南店へ発送したとします。北店の実在庫は10個から8個に、販売可能数は4個から2個に減ります。南店の入荷予定数は2個から4個に増えますが、実在庫は6個、販売可能数は5個のままです。初期状態から入荷予定だった2個は別の移動です。

南店が新しい移動の商品を一度だけ受け取り、必要な確認を終えると、入荷予定は2個に戻り、実在庫は8個、販売可能数は7個になります。計画しただけの移動は、まだ出庫されていません。移動中の商品を両店舗が販売しないよう、販売を停止する時点と、入庫後に販売可能にする時点を決めてください。

最後の1個を誰に販売するかテストする

サプライヤーに、サポート対象の隔離されたテスト環境で以下の受け入れシナリオを実演してもらいましょう。架空の商品を使い、実際の在庫更新、注文、決済、出荷、顧客への通知が起きないようにします。スタッフが見る画面だけでなく、受信側システムの受け付け済み在庫変動と処理後の在庫数も確認します。

商品を1個だけ販売可能にし、レジとオンラインから同時に注文してみます。どこで在庫の引き当てを決めていますか。どちらの注文が受け付けられ、もう一方のお客様やスタッフに何が表示されるか確認します。キャッシュされた在庫表示だけでは、競合する注文の処理を決められません。

次に、注文の受付中に取り置き期限が切れる状況を試します。同じ商品が意図した状態に一度だけ移ることを確認します。返品の入庫または店舗間移動の入庫を二度送信し、実際の受け取りが一度だけだったとスタッフが判別でき、在庫数が二重に増えないことを確認します。これらのテストで確認できるのは、実演した条件での動作です。常に即時更新されることや、すべての過剰販売リスクをなくせることを証明するものではありません。

連携が停止したときは不確実な状態を表示する

確認前に連携を切断し、次に受信側が在庫変動を受け付けた後にも切断します。どちらも送信側には応答が届かない場合がありますが、在庫への影響は異なります。再送する前に、処理待ち、受付確定、結果不明をスタッフが区別できる必要があります。

再接続後、処理ID、商品、場所、数量、状態を受信側システムの記録と照合します。新しい応答の後に古い応答が届いたとき、連携が順序と最新性をどう判断するか確認します。到着時刻だけを理由に、古い在庫数が無断で正しい数として扱われてはいけません。

これらは会社が選択する運用ルールの例です。最も大きな数値や最後に届いた更新を採用することは、一般的な照合ルールではありません。実地棚卸で差異を発見できますが、修正には記録された理由と責任者が必要です。

スタッフが使える在庫連携表を作る

成果物には、合意した商品と店舗の対応表、各数量の定義、受け付け済み変更の管理責任者、結果不明の在庫変動や不一致への対応手順を含めます。テストした販売、取り置き、返品、店舗間移動の手順も添えます。スタッフが案内できる内容と確認が必要な内容を把握できるようにします。

共通の在庫表示は、現在利用している販売チャネルを支えます。在庫連携表を使えば、残作業が設定変更なのか、新たな連携なのか、スタッフの役割変更なのかを特定できます。連携が必要であれば、こうした在庫変動や例外処理に対応するAPI連携について相談できます。作業範囲と継続的な保守はプロジェクトごとに合意します。

在庫共有に関するよくある質問