Shopify 管理者は、SKU が 42 ユニットあると言っています。棚には 37 個あります。一晩で 5 本のろうそくを盗んだ人はいません。プロセスのどこかで数値が乖離してしまい、どこを調べればよいのかがわかると、矛盾は謎ではなくなり、通常の容疑者の短いリストになり始めます。
この投稿では、これらの原因と、その再発を防ぐプロセスの修正について説明します。カウントを実行したり、単一の調整を記録したりする手順は説明されません (これらには独自のガイドがあり、以下にリンクされています)。これは、カウント画面を開く前に数値が間違っていた理由についてです。
なぜ齟齬が起こるのか
Shopify は、製品ごと、場所ごとに、利用可能、コミット済み、利用不可の 3 つの数値を追跡します。手元にあるのは、この 3 つの合計です。矛盾とは、これら 3 つのうち 1 つが、その時点で誰もそれに気づかずに現実から漂流したことを意味します。つまり、在庫を約束するはずだった注文がされなかったり、再入荷すべきではなかった返品がされたり、到着した荷物が記録されなかったりすることです。以下のすべての原因は、発生する特定の方法の 1 つです。
矛盾は謎ではありません。これは、棚と照らし合わせて誰も確認することなく番号を変更した特定のイベントです。
過剰販売と同期ラグ
ドラフトオーダーは最も一般的な盲点です。 Shopify は、誰かが明示的に「在庫を予約」をクリックしない限り、下書き注文のアイテムをコミット済みに移動しません。それが起こるまで、ユニットは完全に入手可能であり、電話顧客に見積もっていると同時に店頭を通じて販売可能です。チームが電話注文または卸売注文を予約せずに下書きとして作成すると、最終的には同じユニットを 2 回販売することになります。
もう 1 つの同期関連の原因は構造的なものであり、誰も犯す間違いではありません。単一の Shopify ロケーションには製品ごとに 1 つの数量が保持され、複数のチャネルまたはアプリがその番号に書き込む場合、あるチャネルまたはアプリからの書き込みが別のチャネルからの書き込みと遅れたり重複したりする可能性があります。これは文書化された Shopify 警告ではありません。これは在庫モデルの仕組みの結果です。
バンドルまたはキットを販売する場合は、疑わしいリストにもう 1 行追加してください。バンドルの販売によって各コンポーネントの在庫が実際に減るかどうかは、実際に自分のストアで確認する価値があります。二次情報源はデフォルトの動作について意見が異なるため、ここではそれを推測するつもりはありません。どちらかの方法を仮定するのではなく、直接確認してください。
受信エラー
「受信済み」は Shopify 独自の組み込み調整理由の 1 つであり、Shopify が受信ミスがよくあることを想定していることを示しており、明示的に指定する必要があります。通常のバージョン: ラッシュ時には 24 個入りの箱が 20 個としてカウントされるか、倉庫の場所宛ての出荷が代わりに小売店の場所に対して記録されます。次のカウントまで、どちらも間違っているとは表示されません。
静かなバージョンは一括ツールで発生します。 Shopify には、混同しやすい 2 つの異なる在庫関連 CSV があります。製品エクスポート CSV の「バリアント在庫数量」列と、専用在庫 CSV の「在庫 (新規)」列です。それらは交換可能ではありません。更新の受信中にそれらを混同すると、正常な番号が古い番号で静かに上書きされる可能性があります。
リターンは逆に受け取りますが、同じリスクを伴います。注文キャンセル時の「在庫を補充する」チェックボックスと返金時の「商品を補充する」チェックボックスは両方ともデフォルトで選択されているため、破損品または販売不可能な商品の返金を処理しているスタッフは、チェックを外そうと考えずに、販売不可能な在庫をすぐに「使用可能」に追加してしまいます。これは、システム上では問題がないように見えても、誰かがそれを販売しようとした瞬間には間違っているように見える矛盾です。
手動調整ミス
Shopify の在庫調整理由は、修正、カウント、受領、返品再入荷、破損、盗難または紛失、プロモーションまたは寄付であり、修正がデフォルトの選択です。スタッフが常に理由をデフォルトのままにしている店舗では、数値の変化に関する完全な監査証跡が残っていますが、その理由については記録がないため、6 週間後に根本的な原因となる再発する不一致を見つけることがはるかに難しくなります。実際の理由を選択するにはさらに 5 秒かかり、推測に頼る必要がなくなりました。
保持力も重要です。各商品の調整履歴には、商品ページ上の過去 180 日間が含まれます (Shopify は、2024 年 11 月にこれを 90 日間から 2 倍にしました)。古いものや店舗全体のビューの場合、在庫調整変更レポートはさらに遡り、SKU、場所、スタッフ メンバー、アプリ、および理由でフィルタリングできます。
単一の調整を正しく行う仕組み (どの UI パス、どの理由を選択するか、監査証跡にどのように記録されるか) については、Shopify での在庫調整ガイド。この投稿は、正しい調整を行う方法ではなく、そもそも間違った調整が発生する理由について説明しています。
盗難と縮小
盗難や紛失は、繰り返しになりますが、Shopify 独自の調整理由の 1 つです。これは、縮小が特殊なケースではなく、予期された記録可能なイベントとして扱われていることの証拠です。ここでの防止は、Shopify の設定ではなく、ほとんどが運用上のものです。実行中の推測ではなく、特定のカウントに対して収縮を調整し、実際の理由に基づいてログに記録することで、パターンが「修正」に消えるのではなく、後から表示されます。
予防チェックリスト
これらを修正するために新しいソフトウェアは必要ありません。一貫して適用するいくつかの習慣が必要です。
- 下書き注文は、顧客に在庫を約束した後ではなく、その瞬間に予約します。予約されていないドラフトは、引き続き誰にでも完全に販売できます。
- 破損した商品や販売不可能な商品に関する返金またはキャンセルの場合は、「再入荷」のチェックを外します。
- 修正のデフォルトではなく、実際の調整理由を毎回選択することで、実際に何が起こったのかが監査証跡で説明されます。
- チームが更新情報の受信に使用する CSV を標準化し、製品エクスポート CSV と在庫 CSV を混同しないようにします。
- 何か問題があるように見えるときだけではなく、スケジュール上の実際の数と調整してください。私たちのを参照してください在庫数ガイド実行ステップについては、サイクルカウントと完全な物理カウントの比較頻度を選択するため。
- Shopify の利用可能数、コミット済み数、手持ち数が実際にどのように推移するかについて初めての場合は、追跡メカニズムガイドステート マシンについては、この投稿全体が理解していることを前提としています。
手動調整は、月に数十の SKU にわたってこのパターンを手動で追跡するまで機能します。これは通常、店舗がスプレッドシートや保存されたフィルター ビューの代わりに専用の在庫アプリを参照する時点です。ストックキューこれは私たちのものです。以下の監査ログのエクスポートは、この特定の問題にとって重要な部分です。
ストックキュー
いくつかの SKU を超えると、誰がいつ何を調整したかまで不一致を追跡するのが遅くなります。 StockCue の Growth プランは完全な在庫監査ログをエクスポートするため、180 日間の履歴を一度に 1 つのバリアントをクリックする代わりに、スプレッドシートで SKU、場所、または理由によってフィルタリングできます。
Shopify に StockCue をインストール →よくある質問
Shopify の在庫数が棚にあるものと一致しないのはなぜですか?
なぜなら、Shopifyの手持ち数値は、物理的に真実ではなく、システムに何が起こったと言われているかを反映しているだけだからです。不一致は、予約されていないドラフト注文、破損した商品を黙って補充する返金、間違った場所に入力された受入カウント、または誰も記録していない縮小など、よくある容疑者の短いリストから生じます。この両者の差を捉えるのが定期的な在庫数だ。
過剰販売により、Shopify で在庫の不一致が発生する可能性がありますか?
はい。下書き注文では、明示的に予約しない限り、利用可能な在庫が減らないため、下書きが完了する前に同じユニットをオンライン ストアを通じて再度販売できます。同じ在庫レコードに書き込む複数の販売チャネルやアプリでも遅延や競合が発生し、後で手動での修正が必要になる過剰販売が発生する可能性があります。
受信エラーが在庫の変動を引き起こすのはなぜですか?
箱の数え間違い、出荷の記録が間違った場所、または数量が間違った CSV 列に入力された場合、実際に到着したものと一致しない数値が Shopify にプッシュされます。 Shopify には、列名が異なる 2 つの個別の在庫関連 CSV があり、一括更新中にそれらを混同することは一般的で回避可能なドリフトの原因です。
不一致の原因を見つける最も簡単な方法は何ですか?
まず、Shopify の在庫調整変更レポートから始めます。このレポートは、SKU、場所、スタッフメンバー、アプリ、調整理由でフィルターできます。各製品独自の調整履歴も、過去 180 日間を製品ページに直接表示します。これは、通常、何か問題が発生した日を特定するのに十分です。
この記事の基礎となる基礎については、まず以下から始めてください。在庫管理の基本ガイド。