在庫と価格で管理元を分け、在庫だけを一方向に流す

在庫は一つ。それでも、モールの手数料やポイント分を価格に乗せる、自社ショップだけ会員価格を出す、といった理由で、販売価格は販売先ごとに変えたくなります。在庫と価格を同じ経路で流すと、片方で直した価格がもう片方を上書きしたり、在庫だけ流したいのに価格まで揃ったりします。

運営者の時計店 Timeseek（timeseek.net）は Shopify の自社サイトだけで売っています。この記事は、一点物を複数の販売先に出す場合の型です。一元管理システムを入れるなら、システム側の在庫を正にして Shopify とモールへ反映する形が合う、と運営者は考えています。

販売先の数・注文の時間・価格の同期・返品の手順で、仕組みが要るかが決まる

この記事の判定で次の4つを選ぶと、仕組みが要るかが分かります。

  • 販売先の数: 自社ショップのほかに、同じ商品をいくつのモールに出しているか。今後増やす予定も含めて
  • 注文の件数と時間: 一日の注文が何件で、営業時間外にも入るか
  • 価格の同期: 今の連携や設定で、在庫と一緒に価格まで同期していないか
  • 返品の手順: 返品を検品してから在庫に戻す手順があるか

項目ごとに、どこが正か・どちらへ流すか・外れたらどうするかを決める

自社サイト（Shopify）と楽天市場の2販売先で売る店の例です。

項目管理元更新方向例外処理
在庫数一つに決める（Shopify、または一元管理サービス）管理元から自社サイト・楽天市場へ一方向モール側で直接編集しない。編集されていたら次の更新で管理元の数に戻す
販売価格販売先ごと（自社サイトの価格は自社サイトで、楽天市場の価格は楽天市場で持つ）流さない在庫連携の設定に価格同期が含まれていたら切る。切れないなら連携対象から価格を外す
商品コード管理元管理元から各販売先へ販売先ごとにコードが違う商品は対応表で変換する。対応表も管理元に置く
注文注文が入った販売先各販売先から管理元へ集める集める処理が遅れたら、その間の注文は管理元で先に在庫から引いておく（仮引当）
取消注文が入った販売先販売先から管理元へ。在庫は管理元で戻す出荷後の取消は返品として扱い、すぐには戻さない
返品管理元管理元で「検品中」にしてから、販売可能か販売不可かを決める検品前に在庫へ戻さない。販売不可なら在庫を増やさず、商品の状態を記録する
  • 「例外処理」の列が決まっていない項目は、手動運用でもサービス導入でもそこで止まる

一点物の在庫の状態は四つ

状態管理元の在庫注文が入っていない販売先の表示次の状態
販売中1販売中注文で「注文済み」へ
注文済み0売り切れ発送で「発送済み」へ。取消で「販売中」へ戻る
発送済み0売り切れ、または非表示返品があっても自動では戻さず、検品後に人が「販売中」へ戻す
連携停止管理元と販売先で食い違うことがある古い表示のまま再開時に差分を照合してから「販売中」か「注文済み」へ
  • 要点は「発送済み」の行。返品された一点物は検品して初めて売れる状態に戻る。在庫の数字だけ先に1へ戻すと、傷が増えた商品を元の説明のまま売ることになる

注文・取消・障害で在庫がどう動くかを、10件のテストで確かめる

時計を自社サイトと楽天市場で売る店の3商品（例）で並べます。実在の店の商品ではありません。DEMO-101は在庫1の一点物、DEMO-102は在庫3、DEMO-103は在庫0で、楽天市場の販売価格はどれも自社サイトより高く登録してあります。

ID区分操作期待結果失敗したときの症状
T1正常自社サイトでDEMO-102が1点売れる管理元の在庫が3から2になり、楽天市場の在庫表示も2になる楽天市場が3のまま。売り越しの入口
T2正常楽天市場のDEMO-102の価格だけを変える自社サイトの価格は変わらない自社サイトの価格も変わる。価格が同期している
T3異常DEMO-101が自社サイトと楽天市場でほぼ同時に売れる先に管理元へ届いた注文だけを引当し、あとの注文は在庫なしで受けないか、保留にして買い手へ連絡する両方を受注する。二重販売
T4異常楽天市場の注文を出荷前に取り消す管理元の在庫が戻り、自社サイトの表示も戻る戻らない。売れる商品が欠品表示のまま
T5異常DEMO-102が1点返品される在庫は増えず「検品中」。確認後に販売可能へ戻すか、販売不可にする受付と同時に在庫が増え、検品前の商品が両方に再出品される
T6異常連携が止まっている間に自社サイトで売れる再開後、止まっていた間の注文を突き合わせ、楽天市場の在庫を引き直す再開後も差分が残る
T7異常DEMO-103（在庫0）を楽天市場の管理画面で1に書き換える次の更新で0に戻る1のまま。モール側の編集が管理元を上書きしている
T8異常連携を止めた状態で、自社サイトでDEMO-101が売れる楽天市場が販売中のまま残ることに、通知か手で下げる手順で気づける誰も気づかず、売り切れのはずの商品が楽天市場で売れる
T9異常管理元の在庫を手で1から0に変える各販売先が売り切れになり、手で変えた記録が残る記録がなく、あとで理由が分からない
T10異常楽天市場だけ商品コードを変えて登録する連携対象外として検出され、黙って無視されない黙って無視され、楽天市場の在庫が更新されない
  • 失敗条件は T3・T5・T8 の三つ
  • T3: 同時注文を先着で処理する仕組みがなければ、一点物に同時に注文が入ったとき、手動運用でもサービス導入でも二重販売が起こりうる。反映が5分おきなら5分、1分おきなら1分の間は、どの方法でも起こる。連携で防げるのは反映間隔の外側だけなので、内側は取消の手順で受け止める
  • T5: 返品を受け付けた時点で自動的に在庫へ戻す設定は、一点物や中古品では切る
  • T8: 連携が黙って止まり、誰も気づかないまま数日たつと、売り切れのはずの商品がモールで売れる

販売先が一つなら連携は要らず、三つ以上なら比べる

判断の順は次のとおりです。境目は運営者の目安です。

  • 販売先が Shopify 一つなら、連携は要らない。標準の在庫数だけで足りる
  • 販売先が二つ以上でも、注文が日に数件で、担当者が一人で営業時間内に処理できるなら、手動のルールで始め、T1・T4・T8を人の手で確かめる
  • 営業時間外にも注文が入る、担当者が複数いる、販売先が三つ以上になったら、一元管理サービスを比較する
  • 販売先ごとに価格を変える、商品コードの付け方が販売先で違うなど、標準の連携に収まらない条件があるなら、開発会社に頼む範囲を先に決める

注文が日に数件なら、仕組みより決まりで足りる

一日の注文が数件で、同じ商品が別の販売先で同じ日に売れることがまれな店なら、仕組みは要りません。決まりで足ります。

  • 管理元を Shopify の在庫に決め、モール側の在庫を日に一度、商品一覧の表（CSV）か手入力で合わせる
  • 販売価格はもともと各モールの管理画面で別々に登録するので、流さなければそれだけで別管理になる
  • 「モール側で在庫を直接触らない」「取消はすぐ戻す、返品は検品後に戻す」の二つを店の決まりにし、更新する人と時刻を決める
  • Shopify の標準機能で販売先ごとの価格や在庫をどこまで扱えるかは、対象のモールと現行の仕様で変わる。複製した環境で先に試す

次のどれかに当てはまったら、比較に進みます。

  • 同じ商品が別の販売先で同じ日に売れる
  • 手入力の遅れで売り越しか欠品表示が起きた
  • 販売先が3つ以上になった
  • すでに一元管理サービスを契約していて、価格まで同期する設定になっている

同じ表と10件のテストで、標準機能・サービス・開発会社への依頼を比べる

同じ表と同じ10件のテストを、標準機能・サービス・開発会社への依頼のどれで満たすかの比較です。料金は税抜です。

条件標準機能アプリ・サービス開発会社に頼む
在庫を管理元から一方向に流す日に一度のCSVか手入力。頻度は運用次第ネクストエンジン: Shopify は受注と在庫が連携の対象で、商品登録には使えない。自動連携にはアプリが必要。ネクストエンジン側の在庫数を Shopify へ自動で反映する方式（マルチロケーションは非対応）。CROSS MALL: Shopify は在庫管理と受注管理に対応し、商品登録には使えない。在庫の管理元を CROSS MALL と Shopify のどちらに置けるかは公開されていない頼む範囲に入れる
販売価格を販売先ごとに別管理各モールの管理画面で個別登録価格の同期を止められるかを、どちらのサービスも T2 で見る価格を連携から外す設計を頼む
同時注文の二重販売を防ぐ（T3）手動では防げない。一点物は受注後の確認で止める同時注文の扱いを、どちらも T3 で見る仮引当を頼む範囲に入れる
取消・返品で在庫を戻す（T4・T5）手順書で運用返品の自動戻しを切れるかを、どちらも T5 で見る状態の表と10件のテストを渡して範囲を決める
必要プラン・追加費用既存契約の範囲ネクストエンジン: 基本料金3,000円/月（受注200件まで）、初期費用0円。201件目からは1件ごとの従量で、201〜400件が35円、401〜1,000件が30円と区分ごとに下がり、区分ごとに計算して合算。店舗数を増やしても追加費用なし。無料体験は申込日を含め30日間。契約から1年たつと毎年、前年分の年間保守費用15,000円。有料アプリは別料金で、Shopify の自動連携アプリは初期・月額とも0円。CROSS MALL: 月額固定で受注件数や金額による課金なし。プラン1000が10,000円×店舗数（商品1,000点まで）、プラン3000が15,000円×店舗数、プラン5000が20,000円×店舗数、プラン15000が25,000円×店舗数。初期費用0円。無料の体験は日数を決めた試用ではなく、担当者が電話で解説するオンラインデモ開発会社の見積もり
切り戻しCSVで戻す解約して手入力へ戻す戻し方も頼む範囲に入れる
  • 料金は課金の単位から見る。ネクストエンジンは受注件数で、CROSS MALL は店舗数と商品点数で月額が変わる。初期設定とサポートの範囲も並べて比べ、期限が切れた料金では計算しない
  • 同じ期間と件数で構成を並べる練習には、構成と費用を比べる計算機（架空例）が使える

次にすることは、選ぶ方法で変わります。

  • 一元管理サービスを入れる: 本番につなぐ前に、試し用の環境で T1〜T10 を流し、価格の同期を切れるか、返品を自動で在庫に戻さないか、同時注文をどう扱うかを見る。CROSS MALL の無料の体験は担当者が電話で解説するオンラインデモなので、T1〜T10 のどれをデモで見られるかを、日時を決める連絡のときに尋ねる
  • 社内や今の開発先に渡す: 管理元の表と10件のテストを先に渡し、T1から一件ずつ通しながら進める
  • 設計に迷う場合: 運営者への有料の相談も用意している（受付は準備中）

複製した環境で10件を通し、戻すときは連携を止めて手で反映する

本番の在庫と価格は書き換えず、複製した環境か架空データで進めます。

  1. 販売先ごとに在庫と価格をいまどこで更新しているかを見て、上の表のとおり項目ごとの管理元を決める
  2. 価格の同期があれば切り、在庫だけを管理元から各販売先へ流す設定にする
  3. 例の3商品（DEMO-101〜103）を、本番とは別の試し用の環境に登録し、T1〜T10を順に実行して、期待結果どおりかを見る。本番のモールの口座が要る項目は、ここでは流せない
  4. 本番の在庫・価格に触れていないことを、変更した設定とファイルで確かめる
  5. 本番の切り替えは、T3・T5・T8の結果と戻し方の共有が済んでから、別の承認で行う
  • 商品ページに検索エンジン向けの裏側のデータ（構造化データ）を出しているなら、その販売先の価格と在庫を画面と一致させる。販売先ごとに価格が違っても、自社ページの構造化データに載せるのは自社ページの価格だけ

戻し方は一つで、連携を止めて手で反映します。

  • 連携を止めたら、管理元の在庫数を商品一覧の表（CSV）で各販売先へ反映する。価格は連携に載せていないので、戻す対象に入らない
  • 一元管理サービスを外す場合は、モール側の在庫の更新が止まった時点で、各モールの在庫数を管理元の数と突き合わせてから、手入力へ戻す
  • 本番の戻し作業は自動で走らせず、対象と影響を確かめてから手で行う