- 登入
- 註冊
多平台庫存怎麼同步？避免蝦皮與官網同時超賣
蝦皮顯示 5 件、官網也顯示 5 件，不代表你有 10 件可賣。多平台共用庫存的核心，是只保留一個可追溯的庫存真相，再把「可承諾量」同步到各管道。每張訂單先預留，付款、取消、退款與出貨都以事件更新，失敗時能重送但不能重複扣庫。
如果目前只能匯出檔案或手動改數量，也能使用同一套原則，只是安全緩衝要更大、更新頻率要更保守。不要假設每個蝦皮賣家都有相同 API 權限，正式串接前需查當下賣家中心、授權服務商與官方文件。
先定義唯一的庫存真相
每個實體 SKU 在中央表或系統中保留：
- 實際在庫量 on_hand。
- 已成立但未出貨的預留量 reserved。
- 退貨待驗、瑕疵與隔離量 unavailable。
- 已確認但尚未驗收的在途量 inbound。
- 各平台安全緩衝 buffer。
- 最後事件時間、來源與事件 ID。
真正能對外承諾的量：
ATP = MAX(0, 實際在庫量 − 預留量 − 不可售量 − 安全緩衝)
ATP 是 Available to Promise。這是同單位數量的加減式，沒有分母；件、箱與組合套數要先換成同一基本單位。尚未驗收入庫的 inbound 不直接加進現貨 ATP；預購另建規則。計算結果為負時顯示 0，並產生異常，不能把負數悄悄改成零後當作沒事。
同步流程應由訂單事件驅動
一筆訂單可能經過建立、付款、取消、出貨、退款與退貨。每次狀態改變都產生事件：
- 新訂單通過有效性條件，建立預留。
- 付款或訂單成立，確認預留期限。
- 取消且尚未出貨，釋放預留。
- 出貨，從實際在庫扣除並結束預留。
- 退貨收到且驗收可售，才加回在庫。
- 退貨破損或未收到，不可回補可售庫存。
Google Cloud 的事件文件提醒事件可能被重送，因此處理程式需要 idempotent；Microsoft 的 Event Sourcing 模式也以事件重建狀態並特別處理重複事件。對小賣家而言，最低做法是每個事件有唯一 ID，處理前先查是否已完成。
冪等規則：同一 event_id 無論收到幾次，庫存只變動一次。
冪等與併發控制是兩道不同的保護
| 控制 | 解決的問題 | 不能單獨解決什麼 |
|---|---|---|
| 冪等 | 防止同一 event_id 被重送後重複執行 | 兩筆不同訂單同時搶同一庫存 |
| 併發控制 | 防止不同 order_id 同時預留相同庫存 | 同一事件日後被重送 |
不同 order_id 的兩筆訂單會有不同事件，不會被 event_id 去重。因此系統同時需要事件冪等，以及原子性的 ATP 檢查與預留。
假設案例：兩個平台同時賣最後一件
中央 ATP 為 1，官網訂單 A 與蝦皮訂單 B 幾乎同時各需要 1 件。若兩邊先各自讀到 ATP = 1，再分別增加 reserved，兩筆都可能成功；把 A 描述成一定先寫完、B 才判斷，會忽略真正的併發風險。
正確邏輯是：每一筆預留都要在同一個原子交易或條件式更新中，同時檢查與寫入：
只有 ATP >= 本次需求數量時，才能把 reserved 增加本次需求數量。
實作概念可以是資料庫交易搭配 row lock，或 compare-and-swap、條件式更新。無論採哪一種，系統都要檢查 affected rows：更新 1 列才代表預留成功；更新 0 列代表條件已不成立，不能繼續承諾庫存。
因此 A、B 競爭最後一件時，只有先成功完成原子預留的訂單能取得庫存。另一筆條件式預留失敗後，要進入缺貨、人工例外、延遲確認或取消流程，不要先向買家承諾，再期待後續補貨。
每次嘗試仍要保存 order_id、event_id、需求數量、檢查時間、預留結果與失敗原因。這份事件紀錄與稽核軌跡讓失敗事件可以安全重試及追查；重試時先通過 event_id 冪等檢查，再重新執行原子 ATP 條件，不可略過任何一道。
案例為示意。預留期限不能任意套固定分鐘數，應依管道付款與訂單成立機制設定，且不要早於平台仍可能完成交易的有效期間。
三種同步能力，安全策略不同
| 能力 | 更新方式 | 建議安全做法 |
|---|---|---|
| 即時官方 API/Webhook | 事件後立即更新 | 仍需冪等、重試與對帳 |
| 授權整合服務 | 由服務商同步 | 核對延遲、錯誤紀錄與權限 |
| CSV/人工 | 固定批次 | 提高 buffer、限制尾量、多次核對 |
網頁爬蟲或模擬點擊不適合作為正式庫存真相，登入、版面與規則變動都可能讓同步無聲失敗。優先使用平台當下允許的官方能力或經授權整合。
安全緩衝怎麼設
同步緩衝量 = 同步延遲期間的高需求量 + 未成熟訂單調整量 + 盤點誤差保留量
高需求量應用排除一次性活動後的 P80/P90 或明確高需求期間，不能任選最高一天。若同步延遲 10 分鐘，需求資料卻只有每日粒度，就不要假裝能精算分鐘風險，可先設定固定尾量保護並累積事件資料。
活動期間、直播或廣告突然放量時提高 buffer 或只開一個主要管道的尾量。新品樣本不足時人工設定上限。所有發布量先保留整數基本單位，組合換算完成後才向下取整；比率型監控則彙總後再四捨五入。
每天要對三組數字
第一組是中央帳、各平台顯示量與實體抽盤量。
第二組是已預留訂單、已出貨訂單與逾時預留。
第三組是取消、退款、退貨驗收與庫存回補。
同步差異量 = 平台可售量 − 中央應發布 ATP
差異不應只取絕對值，正值代表可能超賣，優先級高於負值造成的少賣。事件延遲超過一個正常同步週期，或差異持續兩輪，就不能只等下一次排程。
預留失敗時的降載方式
以下任一成立，立即把受影響 SKU 的各平台可售量降到安全值或暫停次要管道：
- 中央庫存為負或實物抽盤不符。
- 同一事件被重複扣減，冪等檢查失敗。
- 同步超過允許延遲且無法確認最後成功時間。
- 取消訂單大量未釋放，或退貨未驗就被回補。
- 活動量超出 buffer 可涵蓋範圍。
- 平台或整合商權限失效。
付款、退款、權限與不可逆庫存調整由授權人批准；AI 可以偵測異常和建議發布量，不可自行核准高風險操作。
盤點確認交給 循環盤點 SOP，補貨量交給 補貨點。這篇的下一步，是先為 20 個共用 SKU 建立唯一對照與事件流水，再做小量雙平台測試，不要一開始同步全店。
延伸資料
同步設計參考 Microsoft Azure 的 Event Sourcing 與 Google Cloud Eventarc 重送、冪等資料，查核到 2026-09-06。平台 API 和授權會改，正式串接前要重新確認官方文件。