店頭と通販の在庫をつなぐ前に、何を決める？

実在庫・画面の数・引当を分ける

在庫という同じ名前の欄にも、違う意味の数字があります。店内に実物がある数、これから販売できる数、すでに注文のために確保している数を、混ぜないことが出発点です。物が棚に残っていても、別の注文へ渡す約束があるなら、自由に売れるとは限りません。

• 実在庫：対象の場所に、いつ実物を何個確認したかという数です。後で販売や入荷があれば、同じ時点の数ではなくなります。
• 画面の在庫表示：その画面の定義と更新時点に従って表示される数です。実物の数なのか販売可能な数なのか、反映待ちを含むのかを提供元へ確かめます。
• 注文と引当：注文を受けた記録と、その注文のために在庫を押さえる扱いを分けます。ここでいう引当は、他の販売へ重ねて使わないよう確保することです。いつ確保するかは業務とサービスの仕様によります。
• 出荷：商品を発送する仕事です。注文が記録されたこと、引当が付いたこと、出荷したことを、同じ完了として扱いません。

例えばShopifyの在庫状態の説明では、手元にある在庫、販売可能な在庫、注文等のために確保した在庫などを分けています。これは同製品の定義で、自社の別の画面にも同じ意味を当てはめる根拠にはなりません。「在庫数」という欄名だけで対応付けず、意味と対象の場所、時点を確認しましょう。

正本は、その項目の判断と更新の根拠にする記録です。会社全体で一つの画面を無条件に優先する、という意味にはしません。商品情報の管理元と、在庫の確保を管理する場所が違う場合もあるため、何の値について、誰の確認を根拠にするかを決めます。

一個の在庫と、二つの記録を読み分ける

説明に使う商品名は作業灯Aです。実在する型番ではなく、この例の記録を読み合わせるための名前です。先に確認した時点と、後から現れる二つの記録を分けて読みます。

最初の時点で、何が分かっているか

14:00の説明用記録では、実物は1個、店頭側の画面は1、通販側の画面は1です。三つの数が同じでも、二つの画面が正しく連携していることや、以後の注文を二重に確約しないことを試した記録ではありません。

それぞれの操作時に、相手側の画面を見た値は未確認です。近い時刻の二つの記録から、反映に何分かかったか、片方が他方を上書きしたか、どちらが先に在庫を確保したかまでは判断できません。時刻もこの例の設定で、実サービスの反映時間を測定したものではありません。

図で確かめる問い：二つの画面が「0」になっていれば、どの注文へ何個出荷できるかまで分かるでしょうか。

原寸画像を開く

図を読んだ後の判断：同じ表示へそろったことだけで出荷可否を決めず、元の販売・注文の対象、内容、在庫を押さえた状態、現在の実物を照合します。この記録から「一個から二個売れた」「在庫が負になった」「店頭が先勝ち」と計算・決定しません。まず、判断に足りない情報を具体的な確認先へ戻します。

商品と拠点を合わせ、正本と更新の起点を決める

連携の前に、両側が本当に同じ在庫を指しているかを確かめます。同じ商品名でも、色や仕様、セットの単位、店舗と倉庫が違えば、同じ一個として扱えないことがあります。この例では、同じ商品を示す識別子の対応は未確認です。作業灯Aという表示名だけで、両側の商品番号や拠点が一致したとはしません。

1. 対象を合わせる。どの商品・仕様・販売単位・拠点をつなぐかを、商品を管理する担当と販売・出荷担当で確かめます。
2. 数の意味を合わせる。実物、販売可能、注文に確保済み、入荷予定など、画面の値がどの状態かを提供元へ聞きます。別の状態の数をそのままコピーしないようにします。
3. 正とする記録を決める。何の変更を、どの記録へ先に確定し、その結果をどこへ伝えるかを決めます。変更を受け付ける人と、差異が出たときの判断者もそろえます。
4. 更新の起点を決める。販売成立、注文受付、引当、出荷、取消、返品、入荷や棚卸のどの仕事で、どの数が変わるかを確認します。同じ取引を二度減らす案にしないでください。

例えば、「通販の注文を受け付けたら、その分を確保する」という業務上の回答が得られても、注文受付と引当を同じサービスで確定できるかは別の確認です。「店頭販売で実物を渡したときに減らす」という案と組み合わせるなら、すでに注文のために押さえた分を店頭で売らない方法も必要になります。

この架空例では、正本・引当の時点・同時更新の扱いは、いずれも未確認です。業務担当が希望する決め方と、サービスが実現できる条件を対応させてから採用を判断します。片方の時刻が新しいという理由だけで、常に正しい在庫として上書きするルールにはしません。

IPAのデータの相互運用性向上のためのガイドの案内も、データ資産の整備や連携の準備、意味の認識の違いを減らす考え方を扱っています。ここでは、それを「一つの商品・場所・数の意味を合わせる」仕事へ具体化しています。特定サービスの同時更新や引当の保証を同資料から認定したものではありません。

注文と販売のどこで、在庫を押さえるか決める

「在庫を減らす」だけでは、顧客へいつ何を約束できるかが曖昧です。注文を受けた時点で確保するのか、決済等の条件を確かめてからか、店頭では取り置きをどう扱うかを業務担当へ確認します。この記事で、どのタイミングがすべての店に正しいと決めることはできません。

引当できるという回答なら、両方の販売で守られるかを確かめる

必要な時点で在庫を確保できると分かったら、どの記録で確保を確認し、他方の販売可能数にどう反映するかを尋ねます。一方だけで在庫を押さえても、他方がその分を自由に売れるままでは、店全体の確約条件はそろいません。取消や期限切れのときに、誰がどの根拠で確保を解除するかも合わせます。

表示を送れるだけなら、引当まで任せられるとは扱わない

サービス間で数字を渡せることと、競合する注文から同じ在庫を重ねて確保しないことは別です。「在庫連携に対応」という回答には、表示の更新、注文の取込み、引当、出荷のどこまで含むかを聞きます。必要な確認ができなければ、その機能を使えば必ず過剰な確約を防げるとは説明しません。

必要な確保を同じ条件で実現できない場合は、受け付け方、販売する範囲、両経路の確認手順など、業務側の案を見直します。適当な安全在庫の数を引いたり、通販の表示を一律に少なくしたりする方法を、この一例から万能の対策として選びません。何を保留し、何を続けるかを、販売と出荷の担当が理解できる形で決めます。

同時更新は、数字の上書きで決着させない

店頭と通販で近い時刻に操作が起きたら、どちらの画面を最後に保存したかだけを見ても、注文と在庫の関係は分かりません。双方が古い数を元に処理した可能性も、同じ更新が別経路から届いた可能性も、確認が必要です。この架空例が、実際にそのどれかの障害を起こしたと示しているわけではありません。

• 何の変更か：元の販売・注文の対象と、更新のきっかけをたどれるか。同じ取引をもう一度扱ったのか、別の取引かを分けます。
• どこで確定するか：在庫の確保や変更の可否を、どの記録が判断するか。その判断を他方の販売でも守れるかを確認します。
• 競合したらどう返すか：確保できない・まだ判断できない対象を、受付済み、保留、確認待ち等のどの状態で残し、誰へ知らせるかを決めます。呼び名と実際の意味は自社の業務に合わせます。
• 人はどこまで直してよいか：両側を別々に手直しして、連携がさらに上書きしないか。照合中の対象と、解除する条件を示します。

業務担当から「最後の一個は、在庫を確保できた取引にだけ確約したい」と回答が得られたら、それを実現する責任の所在と、失敗時に返る状態を提供元へ確かめます。特定の画面や連携ツールがその条件を実現できることは、仕様と必要な試験がそろって初めて判断します。時刻順や店舗優先を、根拠なくルールへ補いません。

既存のCRMと販売管理の連携の確認点も、項目の管理元や同時変更を扱っています。ここで追加している判断は、同じ希少な実在庫に二つの販売経路から要求が来たとき、どの取引に確保し、どこまで顧客へ約束してよいかです。単なる項目の対応や更新方向だけで終わらせないでください。

反映失敗・結果不明の確認先と、保留範囲を決める

一方への反映が失敗したと分かった場合と、反映したか分からない場合を分けます。応答がなかっただけなら、先に変更が確定している可能性もあります。確認せずに同じ更新を繰り返すのではなく、元の取引、送った変更、受け側の記録を同じ対象で照合します。

元の変更が確定していないと確認できた場合

どの条件が原因で受け付けられなかったかを確認し、訂正した対象だけを再処理する手順を決めます。権限不足なら必要な権限の担当へ、商品の対応が違うなら商品管理担当へ戻すなど、原因に合う確認先を選びます。この記事では、実際のエラーやその原因は観測していません。

一方だけが変わった場合・結果が分からない場合

元の販売や注文と、両側の更新履歴、現在の確保状態を調べます。自動処理を再開する範囲、手で直す範囲、その間の販売・出荷の判断を決めます。表示を一致させるためだけに両方を上書きしたり、在庫の足し引きを推測したりしないでください。何が確定したか分かるまで、その対象の新たな確約をどう保留するかを業務担当へ確認します。

だれが何を照合し、再開を決めるか

販売担当は元の取引の内容、出荷・在庫担当は実物と確保状態、サービスや連携の担当は変更の受付と結果を確認します。これらは確認する役割の例で、この架空店の担当者が任命されたという意味ではありません。回答がそろったら、どこが正で、どの訂正や再実行が必要かを判断し、関係する経路へ同じ内容を伝えます。

この例の出荷の結果・顧客へ通知した結果・手作業で照合した結果は、いずれも未確認です。確認先を挙げたことや、照合の手順を説明したことを、実際の出荷や復旧の完了にはしません。

毎朝届く一方向ファイルの取込みや再送が課題なら、毎朝のファイル連携を段階ごとに決める方法で別に整理できます。本稿では、その一般的な流れを繰り返すより、二つの販売経路で同じ在庫へ約束する条件を優先して確かめます。

提供仕様で方式を選び、一商品で許可された試験をする

今回の記録では、反映の遅れと、提供サービスへ在庫を書き込める条件は未確認です。片方で値を取得できても、必要な在庫状態へ書き込めるとは限りません。利用するサービス・版・商品と拠点・認証や権限・対応する操作・更新や通知の制限を、実際の提供仕様で確かめます。

例えばSquareの在庫更新通知の説明には、変更を知らせる通知と、商品や拠点、イベントの識別情報等が示されています。これは同製品の技術資料で、通知を受け取れることが、別サービスへの書込みや店舗全体の引当まで保証するわけではありません。ここではアカウントへ接続したり、在庫を変更したりしていません。

回答に応じて、連携する範囲と方法を選ぶ

• 必要な更新と引当を実現できる：対象、起点、確定する記録、他方への反映、競合時の返し方を仕様へ結び、許可された環境で確かめます。
• 取得や表示の反映までに限られる：それを確約の仕組みの代わりにせず、人が確認する場面と範囲を残すか、受け付け方や仕組みを見直します。
• 仕様や権限の回答がない：自動更新の方式を確定せず、確認する窓口と未回答の点を明示します。現状資料の整理や、商品・場所・数の定義の確認は続けられます。

試験は、同じ商品・場所・取引の対応で確かめる

1. 試せる範囲を決める。テスト用の環境、権限、対象の商品と場所、元に戻す方法、実販売と切り離す条件を提供元・業務担当と確認します。実顧客の注文を勝手に使いません。
2. 期待する結果を先にそろえる。店頭だけ、通販だけ、近い時刻の両側操作、取消、反映失敗、結果不明、同じ変更の再到達について、今回必要な条件と、確保・保留・通知・再開の期待を決めます。
3. 同じ対象で結果をたどる。元の販売・注文、在庫の確保、両側の値と状態、更新履歴、必要な通知と次の担当が対応するかを見ます。数字が一致したことだけで合格にしません。
4. 差が出た条件へ戻す。対象の違いなら商品・場所の対応へ、意味の違いなら在庫状態の定義へ、競合や結果不明なら確定と保留の仕様へ戻し、修正が影響する範囲を同じ条件で確かめます。

この四つは今後の試験の組み立て方であり、実行結果ではありません。仕様が決まったこと、実装されたこと、試験で確かめられたこと、運用で対応できたことを、それぞれの根拠とともに区別します。商品や拠点、サービスの版、取消や出荷のルールが変わったら、関係する経路と確約の条件を見直します。

まとめ：一個を誰に確約できるか、根拠から決める

店頭と通販の在庫連携は、二つの画面の数を同じにするだけでは決まりません。同じ商品の同じ場所を指しているか、数は実物か販売可能数か、どこで在庫を確保し、どの取引に顧客への約束を結ぶかを先にそろえます。

架空の作業灯の例では、最初の実在庫一個と、後の販売・注文の記録、各側の表示0までが示されています。正本、引当、反映、同品の識別、出荷等は未確認です。近い時刻の操作を、二件の出荷成功や、特定の失敗原因へ読み替えず、元の取引と実物を確認する仕事へつなげます。