超商取貨物流串接筆記:換單號、改金額的正確姿勢

超商取貨是台灣電商的標配,綠界的物流 API 也不難串——照文件做,建單、印單、出貨,一天就能通。真正的麻煩在上線之後:消費者說「我想多加一盒」、客服說「這單要改成貨到付款」、倉庫說「單印錯了要重印」。這時你會發現,超商物流最難的不是串接,是變更。

我們的自營電商每天出超商件,含貨到付款。以下是用真實訂單換來的筆記。

核心觀念:物流單沒有「修改」,只有「作廢重開」

先建立這個心智模型,後面全部說得通:物流訂單一旦建立,金額與關鍵資訊不能改。要改,就是作廢舊單、建一張新單,沒有第三種選項。想通這點之後,系統設計的方向就清楚了——你要做的不是「編輯物流單」功能,是「安全地作廢重開」功能。

貨到付款金額變更的正確姿勢

最常見的場景:消費者下單後想加購或換商品,金額變了,但這是一筆貨到付款、物流單已經建了。正確流程是:

1. 作廢原物流訂單;
2. 用全新的交易編號建新單——這是最容易踩的雷,交易編號(MerchantTradeNo)一旦用過就永遠不能重用,即使原單已作廢。我們的做法是訂單號後綴流水碼,每次重開遞增;
3. 新單金額為變更後金額,重新取得寄件代碼;
4. 把新舊單的關聯記錄下來,對帳時才追得回去。

順帶一提:金額變了,電子發票同樣要作廢重開,兩件事要一起處理,不然帳會對不上。

把作廢重開做成後台一鍵操作

這套流程手動跑一次要碰 API 兩三回,還要記得處理發票,交給客服口頭指揮工程師執行,遲早出錯——我們早期就發生過重開了物流單、發票卻忘了跟著作廢的狀況,月底對帳才發現,回頭補流程花的時間是當初好好做的好幾倍。我們把整段流程包成後台的一鍵操作:客服改完訂單內容按下去,系統自動作廢舊單、產新交易號、重建物流單、同步處理發票,並把每一步記進操作紀錄。做完這個功能之後,「改單」從一個工程師任務變回一個客服任務,這才是系統該有的樣子。

其他幾條實戰筆記

• 物流狀態查詢用新版 API。我們原本用舊版查詢,狀態欄位不完整,對不出貨件實際卡在哪;改用 V5 版查詢後才拿到完整狀態。串接前先確認文件版本。
• 門市代碼會失效。超商門市會關店、改建,消費者選的門市在出貨時可能已經不收件。建單失敗要有明確的錯誤處理,引導消費者重選門市,而不是讓訂單卡死在倉庫等一個不存在的門市。
• 取貨期限與退回件要有流程。七天不取,貨會退回。退回件的入庫、退款(貨到付款未取則是未收款)、發票處理,都要事先設計,不要等第一件退回才現想。到店提醒訊息(我們走 LINE 通知)能實際壓低未取率,值得做。
• 測試環境的物流是假的。測試環境不會真的有包裹進超商,寄件、取貨、退回這些實體流程只有正式環境才走得到。上線前用真實訂單寄一件給自己,完整體驗一次——這是我們上線前端對端測試的固定項目。

串得起來只代表你讀完了文件;改得動、退得掉,才代表你真的在營運。

物流、金流、發票是三位一體的,任何一個變更都會牽動另外兩個。如果你的系統目前是「改單靠工程師手動」,或許可以聊聊——我們的電商系統建置服務把這些變更場景當成標配在做,也歡迎直接與我們聯絡。