官網、購物平台、門市 POS 與 ERP 往往各自保存一部分真相：平台知道訂單狀態，倉庫知道實際數量，ERP 負責進銷存，客服又可能直接修改訂單。同步專案不能只畫一條 API 箭頭，而要決定每個欄位由誰主導、何時更新、衝突時相信哪一邊，以及失敗後如何恢復。

01商品主檔要有唯一對照

同一商品在不同平台可能使用不同 SKU、名稱與規格順序，組合包、贈品和加價購又會對應多個庫存單位。導入前應建立中央商品編碼與平台對照表，清楚記錄規格、條碼、單位、組合關係及啟用狀態。對照不到的新品不能直接用名稱模糊配對，應進入待確認清單。商品下架或規格更名時也要保留歷史映射，否則舊訂單回傳後可能找不到原品項，導致庫存扣錯或報表斷裂。

02先定義什麼叫可售庫存

實體在庫不等於平台可售數量，還要扣除已保留訂單、安全庫存、瑕疵品、調撥中與待檢退貨。各通路是否共用庫存池、是否預留配額，也會影響同步結果。專案應把每種庫存狀態的加減規則寫清楚，指定哪個系統是最終來源，並決定更新頻率與可接受延遲。促銷或流量高峰前要有額外緩衝，當同步中斷時則能暫停銷售或降低可售量，避免系統仍用過期數字持續接單。

03訂單狀態需要跨平台翻譯

不同平台對「已付款、處理中、待出貨、取消」的定義不完全相同，有的平台付款後仍可取消，有的則在建立物流單後才算出貨。應建立狀態對照與允許轉換路徑，說明哪個事件會建立 ERP 訂單、預扣庫存、釋放庫存或通知倉庫。遲到的 webhook 不應把較新的狀態改回舊狀態，同一事件重送也不能重複扣庫。每次轉換要保存來源時間與平台訂單號，讓客服查得到訂單目前卡在哪一段。

04取消、退貨與組合品另訂流程

取消訂單何時釋放庫存，要看是否已揀貨、已交寄或已開立發票；退貨則必須等商品回倉驗收，不能收到申請就直接加回可售。組合商品也要按實際組成品回補，部分退貨與贈品未回收更需要人工判斷。系統應區分申請、核准、運送中、待驗與完成等狀態，並讓異常進入負責人的工作清單。若只用一個「已退貨」欄位控制所有動作，很容易同時造成庫存、退款與帳務不一致。

05同步失敗要能安全重送

平台限流、網路中斷與欄位驗證失敗都會讓同步暫停。每筆訂單和事件應有唯一識別碼，重送時先檢查是否已處理，避免重複建立訂單、扣庫或出貨。暫時性錯誤可以依間隔自動重試，資料缺漏或狀態衝突則要停止並通知人員，不宜無限重送。監控畫面除了失敗數量，也要顯示最舊未處理時間、受影響平台與訂單，讓團隊判斷是否需要暫停銷售或改用人工備援。

06定期盤點與端到端核對

即使 API 都回傳成功，長期仍可能因人工改單、平台規則變更或漏掉事件而產生差異。應定期比較平台可售量、ERP 帳面庫存與倉庫實際數量，並核對訂單筆數、取消、退貨與出貨總額。測試時要從建立訂單一路走到扣庫、出貨、取消和退貨，不能只確認資料有傳出去。差異要能追到事件與操作紀錄，修正後也要更新來源規則，避免靠人工直接改數字把問題暫時蓋掉。

多平台同步的目標不是讓所有系統看起來一模一樣，而是讓每個系統在清楚的責任下交換可靠狀態。先從商品主檔與單一通路建立端到端流程，再逐步加入平台與例外，會比一次全面串接更容易控制超賣和重複作業風險。

常見問題

庫存同步一定要做到即時嗎？

不一定。要依銷售速度、安全庫存與平台限制決定。高周轉或稀缺商品可能需要接近即時，低風險品項則可定時批次；無論採哪種方式，都要定義延遲期間的超賣防護。

不同平台的商品編碼不同怎麼辦？

應建立中央商品主檔與平台對照表，將各平台 SKU、規格、組合品與贈品映射到內部唯一編碼。對照缺漏時應停止更新並列入例外，不能只靠商品名稱猜測。

同步失敗可以一直自動重送嗎？

不宜無限制重送。系統要區分暫時性錯誤與資料錯誤，設定重試次數、間隔與唯一識別碼，避免同一訂單重複建立；超過門檻後應通知負責人處理。

退貨商品何時可以加回可售庫存？

應在實際收貨並完成商品狀態檢查後決定。退貨申請成立不代表商品已回倉或仍可銷售，系統需區分運送中、待驗、可售、整新與報廢等狀態。