超賣不是運氣不好
同一批貨掛在自有商城、蝦皮和 momo，三邊各自顯示「有貨」。實際上倉庫只剩最後一件，三個通路同時成交，於是你要打兩通電話道歉、吃兩次負評。
這種事發生的頻率跟你的運氣無關，跟庫存數字從一個地方傳到另一個地方要多久有關。這篇講那個延遲是怎麼來的，以及怎麼壓掉它。
為什麼「都上架同一批貨」這麼難
問題不在上架，在扣減。
每個通路成交之後，都要有人（或某個程式）回頭告訴其他通路「少一件了」。手動做的話，最快也是幾小時一次；而超賣只需要幾分鐘的空窗。
常見的三種做法，延遲差很多：
| 做法 | 同步延遲 | 超賣風險 | 人力成本 |
|---|---|---|---|
| 人工定時對 | 數小時到一天 | 高 | 高，且隨通路數線性成長 |
| 各通路分配固定安全庫存 | 無延遲（但犧牲可售量） | 低 | 低 |
| 單一庫存來源 + 自動扣減 | 秒到分鐘 | 低 | 低 |
做法二的代價：你把庫存切碎了
「每個通路各分 10 件」很直覺，也真的能防超賣。代價是你讓每個通路都看起來缺貨。
30 件貨切成三份，任一通路想賣第 11 件就賣不掉，即使倉庫裡還有 20 件躺著。熱賣品最吃這個虧——它剛好是你最不該缺貨的東西。
小量、低頻的商品用這招沒問題。會轉的品項不適合。
做法三怎麼運作
核心概念只有一句：庫存只有一份，放在系統裡；通路上顯示的數字是它的投影。
實際流程：
- 通路成交，通路平台發出通知（webhook）或系統定時去拉訂單
- 系統從對應倉別扣掉庫存，並留下一筆異動紀錄（哪一張通路訂單造成的）
- 扣完之後，把新的可售數量推回所有通路
關鍵在第 2 步的異動紀錄。沒有它，你之後對不出來「為什麼少了 3 件」；有它，每一筆扣減都能追回到來源訂單。這也是事後查帳唯一可靠的方式。
實務上會踩到的三件事
一、通路通知不保證送到。 Webhook 會漏、會重送。所以不能只靠通知，還要有定時補拉；而重複的通知必須能被識別成同一筆，不然會扣兩次。
二、退貨要回補，而且退貨比出貨慢很多。 出貨是分鐘，退貨可能是兩週後。這段時間那件貨既不在倉、也不算賣掉，庫存狀態要能表達「在途」，否則帳一定對不起來。
三、各通路的商品編號一定不一樣。 同一件貨在三個平台有三個 ID。對應表要單獨維護，而且要能處理「一個通路品項對應多個倉庫料號」的組合包情況。
SynERP 的蝦皮通路串接就是照這個模型做的：成交後自動從對應倉別扣減，每筆異動都留可追溯的紀錄。
先做哪一步
如果你現在是人工對帳，不必一次做到全自動。順序建議：
- 先把庫存收成一份。 決定哪個系統是唯一來源，其他地方都只是顯示。這一步不寫程式也能做，是流程決定。
- 再自動化最大的通路。 通常一個通路就佔掉大部分工作量，先接那個。
- 其餘通路逐一接上。 有了第 1 步的單一來源，後面每接一個都是同樣的模式，不會越接越亂。
延伸閱讀
- 進銷存系統和 ERP 差在哪——庫存做對之後的下一層
- 中小企業什麼時候該導入 ERP——「通路越多人越累」是訊號五
- 電子發票怎麼開——多通路的發票也要合併處理
- 多倉庫與調撥怎麼設計——通路之下，倉庫層的設計