物流串接完整指南：超商取貨、宅配與狀態回傳怎麼做
電商專案的需求清單上，「串物流」常常只佔一行。實際做起來卻會發現，它同時牽動結帳頁、出貨作業、客服查詢、退貨退款與每月對帳。
更麻煩的是，物流不像金流只有一個成功或失敗，它是一條持續好幾天、還會走回頭路的流程。這篇整理台灣常見的物流型態、串接時實際要做的事，以及最容易在上線後才爆出來的問題。
台灣常見的物流型態，先分清楚
不同型態的物流，對系統的要求差距很大：
超商取貨：顧客在結帳時指定一間門市，包裹送到門市後由顧客自行取件。分成「取貨付款」與「取貨不付款」兩種，前者等於是貨到付款，帳款由超商代收後再撥付給你，牽涉到金流對帳。這是台灣最普遍的選項，也是系統上最複雜的一種。
宅配到府：送到顧客填寫的地址，流程相對單純，但要處理指定送達時段、偏遠地區、大型商品限制等條件。
店到店（賣家寄件）：賣家把包裹拿到門市交寄，系統要產出的是可供門市掃描的寄件資訊，而不是宅配的託運單。
低溫與冷鏈：生鮮食品常用，除了溫層要在建單時指定，可配送區域與可配送時段的限制也比常溫嚴格，商品頁就要先擋掉不可配送的情況，否則訂單成立後才發現不能送，處理成本很高。
大型商品與安裝配送：家具、家電這類需要兩人搬運或現場安裝的品項，多半不是標準物流單能涵蓋的，常見作法是另外走人工排程，系統只負責記錄狀態。
盤點需求時，建議先列出你實際會賣的商品與出貨方式，再決定第一版要支援哪幾種。想一次支援全部，通常是專案延期的開端。相關的電商路線取捨可以先看電商網站開發指南。
「串接物流」實際上包含四件事
很多人以為串物流就是「把訂單送出去」，實際上至少有四段工作，缺一段流程就接不起來：
| 環節 | 在做什麼 | 常見卡關點 |
|---|---|---|
| 建立物流單 | 把訂單資料送給業者，取得託運單號 | 地址格式、門市代號、商品重量與材積缺漏 |
| 產出託運單／標籤 | 列印可供掃描的單據或標籤 | 列印格式、批次列印、出貨人員的實際動線 |
| 狀態回傳 | 業者把配送進度回拋給你的系統 | 通知延遲、重複通知、狀態名稱對應錯誤 |
| 退貨與逆物流 | 顧客退件或逾期未取的處理 | 退款時機、運費歸屬、庫存回沖 |
最常被忽略的是第四項。 建單與出貨在開發時大家都記得測，退貨卻常常等到上線後才第一次遇到。而逾期未取的包裹退回之後，該不該退款、運費誰吸收、庫存什麼時候補回去，這些是商業規則不是技術問題，必須在需求階段就由業務端拍板。把這類規則寫清楚的方法，可以參考軟體需求怎麼寫。
物流整合服務商，還是直接跟業者串
兩條路各有適用情境，沒有絕對優劣：
透過物流整合服務商：用一套介面同時取得多種物流選項，門市地圖、單號產生、狀態回傳都由同一個窗口提供，開發工作量明顯較小。適合品項單純、希望快速上線、沒有專職技術人力的團隊。代價是你的流程要配合服務商支援的範圍，某些特殊需求可能做不到。
直接與物流業者簽約串接：在服務條件與流程設計上彈性較大，也能依自身出貨量談條件。但每一家業者的技術文件、狀態定義、測試環境都不同，等於要做好幾次串接，還要自己整合對帳。需要投入的開發與維運資源明顯較高。
實務上常見的做法是先用整合服務商上線，等出貨量與流程穩定後，再評估是否針對主力物流改為直接串接。這個判斷邏輯與台灣金流串接指南提到的服務商與直連取捨非常相似，兩者也常常一起評估。
需要提醒的是：各業者的服務範圍、技術規格與申請條件會調整，規劃前務必以各業者的官方最新文件為準，不要依賴第三方整理的舊資料。
狀態同步與客服查詢怎麼設計
顧客問「我的東西到哪了」時，客服要能在自家後台一次看到答案，而不是開五個業者網站逐一查詢。要做到這件事，系統需要：
- 把訂單與物流單綁在一起：一筆訂單可能拆成多個包裹，資料結構上要允許一對多，否則分批出貨時會對不起來
- 保留狀態變更的歷史紀錄：只存「目前狀態」會讓異常無法追查，應該記錄每次狀態變更的時間與來源
- 定義自家的狀態語彙：各業者的原始狀態名稱不一致，前台顯示應統一為顧客看得懂的幾個階段
- 顧客自助查詢入口：訂單查詢頁或會員中心顯示進度，能吃掉相當比例的客服訊息
如果你已經有會員系統，把物流狀態接進會員的訂單頁是最省力的做法，設計原則可參考會員系統與 CRM 開發指南。若主要客服管道在通訊軟體上，也可以把查詢做成自動回覆，作法見LINE 機器人開發指南。
對帳與異常處理：上線後真正花時間的地方
物流的帳比金流更零碎，因為費用會因材積、重量、地區、溫層、退件而變動。規劃時至少要確認三件事：
運費怎麼算、由誰吸收。前台顯示給顧客的運費、實際跟業者結算的費用，兩者不一定相同。差額要能被看到，否則長期下來會侵蝕毛利而沒人察覺。
退件與逾期未取的費用歸屬。這筆錢常常沒人算，但累積起來並不小。商業規則先定好，系統才知道要記錄什麼欄位。
每月帳單與系統紀錄怎麼核對。業者提供的對帳檔案格式各不相同，若出貨量已有規模，建議一開始就把匯入與比對做成功能，而不是每月用試算表人工處理。和發票一起看會更完整，可參考電子發票串接指南。
異常處理則建議建立一份明確的清單：地址不完整、門市暫停收件、包裹遺失、破損、顧客拒收、逾期退回。每一種都要有負責的人與標準處理步驟，並在系統裡留下處理紀錄。
上線前該驗過的情境
物流的測試不能只測「成功建單」。建議把下列情境逐一走過，並列入驗收項目：
- 正常下單到完成取貨的完整路徑
- 顧客改門市、改地址（若允許）
- 業者回傳失敗或延遲時，訂單狀態是否卡住
- 同一筆訂單分批出貨
- 逾期未取自動退回，以及後續退款與庫存回沖
- 大量訂單同時建單時的處理速度
- 對帳檔匯入後與系統紀錄的差異報表
驗收的方法與缺陷分級可以參考軟體驗收怎麼做，整個上線前的完整檢查則見網站上線前檢查清單。若你同時有實體門市，庫存與出貨的整合還要納入POS 零售系統開發指南提到的考量。
物流串接的難處不在技術，而在流程與規則。把商品型態、出貨方式、退貨政策、費用歸屬先講清楚，開發就只是把規則寫成程式；反過來若帶著模糊的規則進入開發，上線後每一種異常都會變成臨時決策。
如果你正在評估電商的物流方案，或是現有系統的出貨與對帳已經開始吃掉人力，與 NETVANA 討論你的物流串接需求。NETVANA 的軟體服務採詢問報價制，沒有固定套餐，會先釐清流程與範圍再談，各服務的內容與交付物可以看軟體服務介紹。
延伸閱讀：電商路線怎麼選，先看電商網站開發指南；收款那一段的取捨，可以看台灣金流串接指南；串接外部系統的通用風險與驗收，可以看系統整合與 API 串接開發指南；出貨與門市庫存要整合時，可以看POS 零售系統開發指南；上線前的完整盤點，可以看網站上線前檢查清單。
