複数の倉庫や店舗から発送しているお店では、1つの注文がまとめて1か所から出ていくとは限りません。手前の倉庫にある2点だけ先に送り、残りの1点は入荷を待って後日お届けする。こうした分割出荷・部分出荷は、特別な事故ではなく日常的に起こる出来事です。この記事では、そんな状況でもShopifyの在庫同期を壊さずに済ませるための考え方を、順を追ってまとめていきます。
分割出荷がややこしく感じられるのは、在庫が動くタイミングが1回ではないからです。注文が入った瞬間と、実際に箱が倉庫から出ていく瞬間とで、Shopifyの中の数字は別々のかたちで動きます。そこへスプレッドシートからの在庫同期が重なると、どの数字を正しいものとして扱えばよいのか分からなくなってしまいます。まずは何がいつ動くのかを、落ち着いて確認していきましょう。
分割出荷のとき、在庫は実際にどう動くのか
分割出荷や部分出荷でつまずく原因は、たいてい在庫の状態が1種類ではないことにあります。Shopifyの在庫は、実際に棚にある数（実在庫）、注文のために取り置かれた数（確保済み）、これから販売できる数（販売可能）に分かれています。この3つを同じものだと思って運用していると、出荷が分かれた瞬間に数字の説明がつかなくなります。どのロケーションが選ばれるのかは、注文ルーティングの基本で仕組みを説明しています。
注文で確保され、出荷で引かれる
注文が成立した時点では、実在庫はまだ1つも減りません。減るのは販売可能の数だけで、その分が確保済みへと移ります。棚の上には商品がちゃんと残っているけれど、もう他のお客様には売れない状態、と言い換えると分かりやすいかもしれません。倉庫の担当者が棚を見に行けば、商品はまだそこにあります。
実在庫が減るのは、フルフィルメント（出荷処理）を行った瞬間です。伝票を印刷して箱に詰め、Shopifyの注文画面で発送済みにした時点で、確保済みが解消されると同時に実在庫がその分だけ引かれます。つまり在庫が動く場面は注文時と出荷時の2回あり、それぞれ意味も対象も違うということです。この2回を分けて考えられるかどうかが、分割出荷をうまく扱えるかどうかの分かれ道になります。
引かれるのは、実際に出荷したロケーション
次に押さえておきたいのが、実在庫が減る場所です。引き落としは、その商品を実際に発送したロケーションに対して行われます。東京倉庫から出した2点は東京の実在庫から、大阪倉庫から出した1点は大阪の実在庫から、それぞれ別々に引かれます。注文としては1件でも、在庫の動きとしては2つの倉庫で別々に発生しているわけです。
ここを見落とすと、出荷が終わったあとに「注文は1件なのに、なぜ2か所の数字が動いているのか」という混乱が起きます。とくに拠点ごとに担当者が分かれているお店では、自分の倉庫の数字しか見ていないために、隣の倉庫で何が起きたのかが分からないまま話が進みがちです。逆に言えば、注文を1つの塊ではなく、複数の場所から少しずつ在庫を引いていく取引として捉えられれば、画面上の数字はきちんと筋が通って見えてきます。多店舗運用では、この見方に切り替えることが最初の一歩になります。
残った数量は、元の場所で確保されたまま待つ
では、まだ発送していない残りの数量はどうなるのでしょうか。答えは単純で、割り当てられたロケーションで確保済みのまま待機します。3点の注文のうち2点を東京から先に送った場合、東京の実在庫は2つ減りますが、大阪に割り当てられた残り1点は大阪で確保されたまま、実在庫としては棚に残り続けます。
そのため部分出荷の途中は、実在庫と販売可能の差がふだんより大きく開きます。棚を数えれば商品はあるのに、Shopifyの販売可能はゼロに近い、という状態です。これは異常ではなく、待機中の注文がある正常な姿です。棚卸しの結果とストア画面の数字が食い違って見えるときは、この確保済みの存在をまず疑ってみてください。
在庫同期が分割出荷とぶつかる3つの場面
ここからが本題です。スプレッドシートを在庫の正本としてShopifyへ数量を書き込む運用は、誰が見ても分かりやすく、担当者が変わっても引き継ぎやすいという大きな利点があります。その反面、分割出荷の最中に同期が走ると数字がずれることがあります。ぶつかり方はおおむね3つのパターンに整理できるので、どれが自店に当てはまりそうかを考えながら順番に見ていきましょう。未出荷ぶんの扱い方は、未出荷注文ぶんを差し引く考え方で別に整理しました。
出荷処理の最中に数量を上書きしてしまう
1つ目は、倉庫が発送作業を進めている真っ最中に同期が走るケースです。担当者が箱詰めを終えてShopifyで発送済みにする、その数秒から数分のあいだにシートからの書き込みが入ると、Shopifyが引こうとしていた数量と、シートが書き込もうとしていた数量がすれ違います。
結果として、発送済みにしたはずなのに在庫が減っていない、あるいは減りすぎている、といった見え方になります。厄介なのは、この現象がエラーとして表に出ないことです。どちらの操作も単体では正しく、ただ順番が悪かっただけなので、あとから原因を追いかけるのが難しくなります。だからこそ、同期を走らせる時間帯そのものを設計する必要があります。
数時間前に数えたシートの数字を送ってしまう
2つ目は、シートの数字が古いまま同期されるケースです。朝いちばんに棚を数えてシートに入力し、その値を夕方に同期する。この間に何件も出荷が終わっていれば、朝の数字はもう現実を表していません。にもかかわらず同期はその値を正しいものとしてShopifyに書き込みます。
この場合、日中の出荷でShopifyが正しく減らした在庫が、朝の多い数字で上書きされて元に戻ってしまいます。見た目には在庫が復活したように見えるため、実際には棚にないものが販売可能として並び、売り越しにつながります。シートに入力した時刻と、同期を実行する時刻の距離は、思っている以上に大きなリスクを抱えています。
Shopifyが引いた分を、シートでもう一度引いてしまう
3つ目は、いちばん起きやすく、いちばん気づきにくい二重引き落としです。出荷が終わった担当者が、良かれと思ってシートの数量からも出荷分を手で引いてしまう。ところがShopifyは、フルフィルメントの時点ですでに実在庫を引いています。そこへ手で引いた数字が同期されると、同じ1回の出荷で在庫が2回減ることになります。
分割出荷ではこれが倉庫ごとに起こりうるため、被害が広がりやすいのも特徴です。東京でも大阪でも同じ気づかいが働けば、1つの注文で2か所の数字が余計に減ります。シートは棚の実数を写すもので、注文にともなう増減はShopifyに任せる。この役割分担をはっきりさせておくことが、いちばんの予防になります。
- 出荷作業の時間帯と同期のスケジュールが重なっていないかを確認する
- シートに入力した時刻と同期を実行する時刻が離れすぎていないかを見る
- 注文分を手で引く運用が現場に残っていないかを聞き取る
- 同じ商品を複数の担当者が別々に更新していないかを整理する
分割出荷があっても壊れない3つの型
ぶつかり方が分かれば、対策はそれほど複雑ではありません。新しいツールを導入したり、複雑な条件分岐を組んだりする必要もありません。同期の対象と、数える順番と、少しの余裕。この3つを決めるだけで、分割出荷が何度起きても数字は落ち着いた状態を保てます。順番に見ていきましょう。
同期するのは実在庫だけにする
いちばん効く型が、シートから送るのは実在庫だけ、と決めてしまうことです。販売可能や確保済みは、Shopifyが注文の状況に応じて自動的に計算してくれる結果の数字です。こちらから書きにいく必要はありませんし、書きにいくと確保済みの分と二重に差し引かれて、かえって現実から離れていきます。
シートの各列は、それぞれのロケーションに何個あるかを表す、と定義しておくと迷いがなくなります。実在庫だけを預かり、そこから先の計算はShopifyに任せる。役割がはっきりしていれば、分割出荷で確保済みが複数の倉庫に散らばっても、シート側の書き方は何も変わりません。初回の同期前に接続テストを走らせて、どの列がどのロケーションに対応しているかを確かめておくと、より安心です。実在庫と販売可能の違いは、Shopifyの在庫状態の読み解き方で確認できます。
数えるのは、出荷が終わってから
2つ目は、棚を数えるタイミングを出荷のあとに寄せることです。出荷の最中に数えた値は、数え終わった時点ですでに古くなっています。逆に、その日の発送がひととおり終わってから数えれば、シートに入る数字はいちばん現実に近い状態になります。
同期のスケジュールも、この数え終わりの直後に置くのが自然です。数えて、入力して、送る。この一連の流れが短い時間に収まっているほど、途中で現実が変わってしまう余地が小さくなります。逆に、朝数えて夜送るような運用は、それだけで一日分のずれを抱え込むことになります。
小さなバッファで競合を吸収する
3つ目は、少しだけ余裕を持たせるという考え方です。どれだけ丁寧に運用しても、出荷処理と同期が同じ瞬間に走る可能性をゼロにはできません。そこで、動きの速い商品や複数倉庫にまたがる商品については、シートに載せる数量を実数より数個少なめにしておきます。
こうしておけば、多少タイミングがずれても販売可能がマイナス方向に振れるだけで済み、売り越しという最悪の結果は避けられます。バッファは在庫を隠すための仕掛けではなく、人と機械の時間差を吸収するための余白です。売れ行きの穏やかな商品にまで広げる必要はないので、対象を絞って設定するのがおすすめです。
1つの注文を1つの場所と思い込まないこと。多店舗運用では、注文は複数の場所から少しずつ在庫を引いていく取引だと捉えるのが正解です。
分割出荷を前提にした運用チェックリスト
最後に、決めておくと現場が迷わなくなる項目を整理します。難しいルールは続かないので、いつ同期するか、誰が数えるか、何を残すか。この3点だけをはっきりさせておけば十分です。
同期の時間帯を決める
自動同期のスケジュールは、倉庫の入出荷がいちばん静かな時間帯に置きます。多くのお店では、当日の出荷が締まったあとの夕方から夜、あるいは翌朝の作業が始まる前が候補になります。出荷のピークと同期がぶつからないだけで、上書き事故の大半は起こらなくなります。
倉庫ごとに稼働時間が違う場合は、いちばん遅くまで動いている拠点に合わせて考えると安全です。3拠点あって1つだけ夜まで稼働しているなら、その拠点の終業後に全体をまとめて同期する、という組み方が素直でしょう。どうしても日中に同期したい事情があるなら、対象を動きの少ない商品に絞る、という選び方もできます。
誰が数えるのかを決める
同じ商品の数量を複数の人が別々に更新できる状態は、それ自体がずれの原因になります。ロケーションごとに、シートを更新してよい担当者を決めておきましょう。東京の列は東京の担当者、大阪の列は大阪の担当者、というように、書き込みの責任範囲を分けておくのが分かりやすい形です。
あわせて、注文分を手で引かないというルールも共有しておいてください。数えた実数をそのまま入れる。それ以外の計算はしない。この一言が現場に浸透しているだけで、二重引き落としはほとんど起きなくなります。新しく入った担当者にも、最初の説明で必ず伝えておきたいポイントです。
ログに何を残しておくか
何か食い違いが見つかったとき、あとから追いかけられるかどうかは記録の有無で決まります。誰が、いつ、どのロケーションの、どの商品を、いくつに更新したのか。この5点が残っていれば、原因の切り分けは驚くほど早くなります。シートの更新履歴と同期の実行時刻を突き合わせられる形にしておくのが理想です。
- 01同期を実行した日時と、その時点で送った数量を記録に残す
- 02棚を数えた日時と担当者をシートの欄に書き添える
- 03分割出荷が発生した注文は、どの倉庫がいつ出したかを控えておく
- 04数字が合わなかった事例は、原因と対処をひとことでもメモしておく
分割出荷や部分出荷は、複数の拠点を持つお店なら避けて通れない仕組みです。けれど、実在庫だけを同期する、出荷が終わってから数える、小さなバッファで競合を吸収する。この3つを押さえておけば、注文が何回に分かれて出ていっても在庫同期は落ち着いた状態を保てます。注文を場所の集まりとして捉える視点を、ぜひ日々の運用ルールに取り入れてみてください。