1. はじめに：ECの売上が本部へ戻らないと在庫判断が遅れる
「ECで売れた商品を本部の基幹システムへ毎日反映できず、前日以前の売上と在庫を前提に判断している」。
店舗とECを並行して運営するアパレル企業では、このような状況が起こります。
ECの受注・売上が基幹システムへ戻らなければ、本部は古い販売情報で補充、配分、発注、売上分析を進めることになります。
弊社へご相談いただいたケースでも、ECの売上を日々取り込めないため、基幹システムにある在庫分析機能を十分に使い切れていませんでした。
商品別や店舗別の数字を確認しても、ECで動いた数量が遅れて加わるなら、本部は「今どの商品が売れているか」を正しく比べられません。
店舗・EC在庫連携で最初に決めるのは、ECで販売してよい在庫の範囲です。
店舗に商品があっても、取り置き、引当済み、移動中、返品検品前の数量は、EC公開数に含められません。
EC公開数から除く在庫と、売上・引当・移動・返品が発生したときの更新時点を先に決めておくと、売り越しを防ぎ、本部も古い在庫で補充や配分を決めずに済みます。
本記事では、アパレル・小売で起こりやすい処理に沿って、店舗・EC・本部の在庫連携で決める内容を順に取り上げます。
2. 店舗・EC在庫連携とは
店舗・EC在庫連携とは、店舗、倉庫、ECサイトで動く在庫情報を渡し合い、各販売チャネルが販売できる数量を更新する仕組みです。
ただし、同じ在庫数を各画面に表示するだけでは、複数の販売先が同じ商品を販売可能として扱うおそれが残ります。
たとえば店舗に5点あっても、2点が取り置き、1点がEC受注へ引当済み、1点が店間移動の出荷待ちであれば、ECへ公開できる数量は1点です。
2.1. 連携するのは在庫数だけではない
ECと本部の間で渡すデータには、受注数、売上数、キャンセル数、返品数、引当数、入荷予定、店舗・倉庫の在庫数があります。
商品コード、カラー、サイズ、販売価格、会員IDといったマスタ情報もそろわなければ、同じ商品を別商品として扱ったり、売上を別SKUの実績として集計したりする恐れがあります。
特にアパレルでは、品番全体では在庫が残っていても、求められた色・サイズだけが欠品していることがあるため、連携単位はSKUまで確認します。
2.2. 在庫を一元化しても販売先の優先順位は残る
一つの基盤で管理している在庫でも、販売先ごとに使える数量は異なります。
店頭での取り置き、卸先への出荷確定分、EC注文の引当済み分、催事向けの確保分を差し引く順番は、会社の販売方針で変わります。
そこで連携設計では、「全在庫をECへ公開するか」ではなく、用途が決まった数量をEC公開数から外すかを決めます。
アパレル向け在庫管理システムの比較項目を先に知りたい場合は、アパレル在庫管理システムの比較ポイントをあわせてご覧ください。
本記事では製品の比較ではなく、店舗・EC連携で売り越しや対応遅れが起きる処理に絞ります。
3. EC公開数に含める在庫・含めない在庫
ECの公開在庫を決めるときは、画面に表示された総在庫数をそのまま渡さないことが基本です。
店舗や倉庫に物理的にある実在庫と、すでに別用途で使い道が決まった数量を分けなければ、ECでは注文を受けられたのに出荷できない状態が生まれます。
反対に、販売可能な数量まで一律に除外すると、在庫はあるのにECで欠品表示が続き、販売機会を逃します。
| 在庫の内訳 | EC公開数へ含める判断 | 公開前に確認すること |
| 店舗・倉庫の実在庫 | 販売に回せる条件を満たす分だけ含める | 店頭販売、取り置き、卸出荷の優先順位 |
| 引当済み在庫 | 原則として含めない | 引当がかかる時点と、キャンセル時の戻し方 |
| 移動中在庫 | 到着・検品前は含めない | 出荷元・受入先の双方で二重に数えていないか |
| 返品・検品待ち在庫 | 再販売可否が確定するまで含めない | 傷・汚れ・付属品不足を誰が判定するか |
| 入荷予定在庫 | 予約販売など条件を決めた場合のみ別枠で扱う | 入荷予定日の確度、遅延時の顧客連絡 |
ここで使うのが有効在庫です。
有効在庫は、実在庫から引当済みや出荷予定などを差し引き、次の販売・配分・補充へ回せる数量を表します。
ただし、差し引く対象は企業ごとに異なるため、EC公開数と有効在庫を常に同じ数にするのではなく、販売方針に沿って公開ルールを決めます。
引当済み数量と販売可能数の違いを掘り下げたい場合は、引当と有効在庫の考え方が次の確認材料になります。
在庫の内訳が決まったら、次はその数量がいつ更新されるかを確認します。
4. 売り越しを防ぐ更新タイミング
売り越しは、誤った在庫数だけでなく、在庫更新の時間差でも起こります。
店舗で売れた、ECで注文を受けた、倉庫で出荷したという事実が、それぞれの画面へ届くまでに時間差があると、同じ商品を複数の販売先が販売可能として扱います。
連携設計では「リアルタイム対応」という言葉だけで判断せず、各処理が在庫数を変える時点を比べます。
4.1. 店舗売上とEC受注が同じSKUに重なる場面
たとえば、黒のMサイズが店舗に最後の1点だけ残っているとします。
店舗でレジを通した売上が本部やECに反映される前に、ECで同じSKUの注文を受けると、EC上は在庫ありでも出荷できません。
この場合は、POS売上を反映する間隔、EC注文を引き当てる時点、在庫公開数に持たせる安全幅のどれで防ぐかを決めます。
4.2. 移動中在庫を販売可能数に二重計上しない
店間移動では、出荷元では数量が減っているものの、受入先はまだ商品を販売できません。
この期間の数量を、出荷元にも受入先にも販売可能在庫として残すと、店頭とECの双方で取り寄せや販売の約束をしてしまいます。
移動を扱う際は、出荷、輸送中、受入、検品完了のどこで在庫の所属と販売可能数を切り替えるかを決めます。
店舗間移動そのものの進め方は、店舗間移動で在庫を動かすときの確認点で説明しています。
店舗・EC連携では、移動の指示を出せるかよりも、移動中の商品をEC公開数から外せるかが日々の販売に直結します。
5. 取り寄せ・キャンセル・返品で変わる在庫の扱い
しかし、通常販売だけを前提に連携を設計すると、店舗受取、他店取り寄せ、注文後のキャンセル、EC返品の処理が後回しになります。
これらの処理が入ると、同じ商品でも「どの販売先が使える数量か」が変わります。
例外処理を後から追加すると、通常時は連携しているのに、返品や受取変更のたびに担当者が在庫数を手で直す運用が残ります。
5.1. 店舗受取・他店取り寄せは、確保した時点をそろえる
EC注文を店舗受取にする場合、注文を受けた時点で在庫を確保するのか、店舗が商品を確認した時点で確保するのかを決めます。
確保が遅いと、その間に店頭で売れてしまうことがあります。
一方で、確保した商品を長く取り置きし続けると、ほかの販売先が使える数量を減らすため、受取期限と解除の条件も決めます。
5.2. キャンセルと返品は、販売可能数へ戻す前に判定する
EC注文がキャンセルになった場合は、引当を解除した数量をどの時点でEC公開数へ戻すかを決めます。
また、返品品は、倉庫や店舗へ戻っただけでは再販売できません。
検品で商品の状態と付属品を確認し、再販売可能と判定された数量だけを販売可能在庫へ戻す流れにすると、返品後の誤出荷を抑えられます。
入荷、出荷、返品、移動の各処理で数量が変わるタイミングは、入出庫管理と在庫差異の改善ポイントで詳しく扱っています。
本記事の連携設計では、返品の数量をいつEC公開数へ戻せるかを、検品と在庫ステータスの流れに沿って決めることが要点です。
6. 連携前に本部が決める運用ルール
ベンダーへ連携可否を聞く前に、本部は日々の業務で使うルールを決めます。
ここが決まっていないと、ベンダーは一般的な連携方式を前提に設計するため、導入後に「この数量はECへ出せない」「この返品は別管理になる」といった差分が見つかります。
細かい要件を最初から書き切るより、判断が止まる処理を先に挙げる方が、打合せで確認する内容が具体になります。
| 先に決める項目 | 決めないまま連携した場合に起きること | 関わる担当 |
| EC公開数の計算 | 引当済み・移動中・取り置き分を重ねて販売する | EC、本部、店舗、物流 |
| 売上・受注の反映間隔 | 本部が古い売上と在庫で補充・配分を決める | EC、本部、情シス |
| キャンセル・返品の戻し方 | 販売可能数への復帰が早すぎる、または保留のまま残る | EC、店舗、倉庫 |
| 商品・SKUマスタの責任者 | 色・サイズ・JANのずれで、連携エラーや誤集計が起きる | MD、DB、EC、情シス |
| 会員ID・顧客情報のつなぎ方 | 店頭とECの購入履歴を別顧客として扱い、施策に使えない | EC、店舗、本部、情シス |
最初の作業は、店舗、EC、倉庫、本部がそれぞれ使っている在庫数を一枚に書き出すことです。
次に、引当済み、移動中、返品保留、入荷予定のうち、どれをEC公開数から外すかを決めます。
この順番で話すと、ベンダーへ「EC連携は可能ですか」と聞くだけではなく、「店間移動の出荷時点でEC公開数を減らせますか」と処理単位で質問できます。
7. Creative Vision.NETとLCVでデータをつなぐ方法
弊社のCreative Vision.NETでは、受注、仕入、在庫、配分、出荷、売上分析を同じ基盤で扱います。
連携要件を決める際は、ECカート側とCV.net側の受注・売上・商品・在庫の項目を対応付けます。
そのうえで、店舗・倉庫・本部で使う数量に差が出ない受け渡し方法を決めます。
連携方法や更新頻度は既存ECカートと会員IDの持ち方で変わるため、まず現在のデータの流れと、販売可能数を決める処理を確認します。
7.1. 受注後の在庫を販売可能数から外す
CV.netでは、実在庫と、引当分を差し引いた有効在庫を切り替え、販売に回せる数と引当済みの数を分けて表示します。
ECの注文を受けた後、配分や出荷指示を確定する処理に合わせて引当をかけることで、すでに別の注文へ使う数量をECや店頭の販売可能数へ重ねにくくなります。
また、店舗間・倉庫間の移動では、出荷から受入までの商品を積送在庫として扱えるため、出荷元と受入先の双方で同じ商品を販売可能と数えることを避けられます。
7.2. EC売上を本部の分析へ戻す
ECの売上データを基幹側の売上分析へ渡せば、本部は店舗だけの売れ行きではなく、ECを含めた商品・SKU・チャネル別の動きを比べられます。
C.P.Aでは、商品別の売上から月別推移や顧客属性へ掘り下げます。
ECで動いた商品が店頭でも売れているのか、特定の販売先だけで動いたのかを比べることで、売れ方の違いを次回の配分や発注の判断材料にできます。
ただし、分析画面だけ整えてもEC売上の取込が遅れれば判断は古くなるため、連携頻度とエラー時の対応手順を導入範囲に含めます。
7.3. 店頭とECの顧客情報を施策へつなぐ
Creative Vision.NETとLoyal Customer Visionは同じシステム基盤で連携しており、導入範囲を広げる場合は、店頭とECの購入履歴、会員情報、接客履歴を顧客単位で扱えます。
ECだけで購入したお客様、店頭だけで購入したお客様、両方を利用するお客様を分けて把握できれば、同じ内容の施策を一律に配信するのではなく、購入状況に合わせて案内を変えられます。
会員ID、ECカート側の顧客項目、更新のタイミングは既存環境ごとに確認し、重複登録や紐付け漏れが残らない方法を決めます。
8. まとめ：連携は在庫数を合わせるだけでは終わらない
店舗・EC在庫連携では、各画面に同じ数量を表示するだけでなく、用途ごとに販売可能数を使い分けます。
店舗スタッフが取り寄せを案内できる数、ECが注文を受けられる数、本部が補充・配分・発注に使う数という違いを、処理の順番に沿って反映させる必要があります。
最後に、連携を検討するときに社内で決める内容をまとめます。
- EC公開数から外す在庫を決める：引当済み、取り置き、移動中、返品検品前の数量を、ECで販売してよい在庫へ混ぜないようにします。
- 売上・受注・移動の反映時点をそろえる：POS売上、EC受注、倉庫出荷がどの時点で販売可能数を減らすかを、店舗・EC・本部で同じルールにします。
- 返品・キャンセルの戻し方を先に決める：キャンセル解除と返品検品の手順を分け、再販売できると判定した数量だけを公開在庫へ戻します。
- EC売上と顧客情報を本部の判断へ戻す：ECを別管理にせず、商品別の売上分析、配分、発注、顧客施策に使うデータとして基幹側へ渡します。
まずは、EC受注が発生してから、そのデータが本部の各システムへ反映されるまでの流れを図にし、更新が止まる箇所を洗い出してください。
そのうえで、店舗・EC・倉庫のどこで販売可能数の意味がずれるのかを確認すると、必要な連携範囲とベンダーへ聞く処理を決められます。
この記事の執筆・編集
株式会社ディー・ティー・ピー
システム営業部 編集チーム
株式会社ディー・ティー・ピー システム営業部 編集チームは、アパレル・小売企業向け基幹システムの専門チームです。
販売管理、在庫管理、受発注、配分、出荷、棚卸、売上分析、顧客管理を含むシステムの販売と導入を支援し、300社以上の導入実績があります。
店舗、EC、倉庫、本部が扱う在庫・売上・顧客情報を業務単位でつなぎ、販売可能数の判断と日々の分析に使える環境づくりを支援しています。