訂單管理系統（Order Management System，簡稱 OMS）是把各銷售通路進來的訂單集中在同一處，依狀態推進付款確認、揀貨出貨、物流追蹤與退換貨，再把結果同步回庫存與會計的系統。挑選時先確認三件事：有哪些通路要匯入訂單、出貨由自己處理還是交給物流業者、庫存與發票以哪個系統為準。只有一個通路、訂單量不大時，電商後台內建的訂單功能可能就能應付；通路變多、同一批庫存要供多處販售，或企業客戶需要分批出貨與月結對帳時，再評估獨立的訂單管理系統或客製串接。
訂單管理系統在管什麼：從下單到結案
一張訂單從成立到結案，會經過客服確認內容、財務確認收款、倉庫揀貨包裝、物流配送，接著才是簽收結案；中途還可能取消、改地址、缺貨拆單或退貨。訂單管理系統的工作，是讓每張訂單在任何時間點都只有一個明確狀態，並記錄是誰、在什麼時候把它推進到下一步。
它和前台購物車分工不同：購物車負責下單與付款，訂單管理系統負責下單之後的處理。它也不等於進銷存系統，進銷存重點在數量和成本，訂單管理系統重點在每張訂單的處理進度與例外狀況。如果同一張訂單的狀態分散在通路後台、出貨表與對帳表裡，客服回答一句「出貨了嗎」要查三個地方，就值得把訂單處理集中起來。
多通路訂單匯整要先解決的三件事
官網購物車、電商平台的賣場、實體門市、LINE 官方帳號接單，以及企業客戶用電子郵件或表單下的訂單，各有各的格式。匯整之前先處理三件事，否則資料集中了，問題只是換個地方出現。
- 訂單編號對照：保留各通路的原始編號，另給一個內部編號，客服與財務才查得回原通路的交易紀錄。
- 商品料號對應：同一個商品在不同通路的名稱與規格寫法可能不同，要建立以內部料號為準的對照表，組合商品拆成哪些單品也要定義清楚。
- 庫存怎麼分配：所有通路共用同一份可賣量，還是各通路先分配固定數量；共用時要決定訂單成立就保留庫存，還是出貨時才扣除。
有 API 的通路可以自動取得訂單並回寫出貨資訊，只能下載報表的通路就要排定檔案匯入的時間與檢查規則，各種整合方式可參考系統整合的規劃步驟。
訂單狀態怎麼定義才不會亂
狀態太少，客服看不出卡在哪裡；狀態太多，每個人的理解又不一樣。先列出實際會遇到的狀態，寫清楚進入條件與由誰推進：
| 狀態 | 進入條件 | 由誰推進 |
|---|---|---|
| 待確認 | 訂單已匯入，尚未檢查內容與庫存 | 系統或客服 |
| 待付款 | 選擇轉帳等需要確認入帳的付款方式 | 財務或金流回傳 |
| 待出貨 | 內容與款項已確認，庫存已保留 | 倉庫 |
| 已出貨 | 取得託運單號並交給物流 | 倉庫或物流回傳 |
| 已完成 | 顧客簽收或取貨 | 物流回傳 |
| 取消或退貨處理中 | 顧客或客服提出取消、退貨 | 客服 |
另外要定義三種例外：部分出貨時一張訂單拆成多筆出貨紀錄；多張訂單合併出貨時仍要能分別追蹤；出貨後改地址或改商品要有審核與異動紀錄。狀態原則上只往前推進，需要退回時留下原因。
出貨與物流串接：揀貨單、託運單與配送追蹤
訂單進入待出貨後，系統依倉庫作業方式產生揀貨單與出貨單：訂單少時逐單揀貨，訂單多時可依商品彙總揀貨再分單包裝。包裝完成後取得託運單號，回寫到訂單並通知顧客，再由物流回傳配送狀態直到簽收。
串接物流時要確認：物流業者提供 API 還是檔案交換、託運單由哪一方列印、超商取貨與宅配的欄位差異、配送失敗時系統如何得知、出貨通知用電子郵件、簡訊或 LINE 發送。若出貨交給物流倉，訂單管理系統要傳出貨指示，再接收對方回傳的出貨結果與庫存，分工可參考第三方物流的服務範圍。出貨單上的收件人姓名、電話與地址屬於個人資料，查看與匯出權限要依職務設定。
退換貨流程：申請、驗貨、退款與發票
依消費者保護法第十九條，通訊交易的消費者得於收受商品後七日內，以退回商品或書面通知方式解除契約，無須說明理由及負擔任何費用或對價；但通訊交易有合理例外情事者不在此限，例外情事由行政院定之。同條另規定，企業經營者未依規定提供解除契約相關資訊時，七日期間自提供之次日起算，但自原七日期間起算已逾四個月者，解除權消滅。系統要記錄申請時間、收貨時間、商品類別與解約資訊的提供紀錄，客服才能判斷是否在期間內、是否屬於例外，實際適用以主管機關公告或專業意見為準。退貨在系統裡可以照這個順序處理：
- 顧客或客服建立退貨申請，選擇原因與退回方式。
- 審核後通知物流收回，或請顧客寄回。
- 倉庫驗貨，可再販售的回到可賣庫存，不良品轉入待處理。
- 依付款方式退款；換貨則建立新出貨單並連回原訂單。
- 電子發票有作廢、銷貨退回或折讓時，賣方營業人要依規定時限把資訊傳輸到財政部電子發票整合服務平台存證。
和庫存、會計同步：先決定哪個系統為準
訂單資料會同時影響庫存與帳務，導入前先決定每種資料以哪個系統為準。一種可行的分工是：商品主檔與成本在進銷存或 ERP，處理進度在訂單管理系統，付款與退款以金流回傳為準，發票以發票或會計系統為準。
- 庫存扣除時機：可以採訂單成立時保留、出貨時扣除的兩段式做法，取消時釋放保留量，退貨驗收後才加回可賣量。
- 同步頻率：可賣量推送到各通路，訂單與出貨結果回寫庫存系統，更新間隔太長容易超賣。
- 帳務資料：企業客戶月結要能依客戶彙總出貨、退貨與折讓，對應到應收帳款。
還沒有進銷存或 ERP 時，先釐清庫存要在哪裡管理，可參考進銷存系統的選型重點。
選型評估面向與導入步驟
| 做法 | 適合情境 | 要先確認的事 |
|---|---|---|
| 電商後台內建訂單功能 | 通路少、流程接近一般零售 | 其他通路的訂單能否匯入、資料能否完整匯出 |
| 雲端訂閱的訂單管理服務 | 多通路、流程標準 | 支援哪些通路與物流、計費方式、權限與操作紀錄 |
| 客製開發或串接既有系統 | 企業客戶訂單、特殊出貨規則、要和 ERP 深度整合 | 需求規格、驗收方式、上線後由誰維護 |
導入順序可以是：盤點通路與處理流程，畫出狀態與例外；整理料號對照與庫存規則；請候選方案用真實訂單示範匯入、出貨、退貨與對帳；確認匯出格式與權限；先選一個通路試行再逐步擴大。容易踩的雷是只看功能清單不看例外流程、沒整理料號就開始串接，以及上線前沒用退貨與部分出貨的情境驗收。
常見問題
訂單管理系統和進銷存系統要擇一嗎？
不需要擇一。訂單少時可以只用進銷存的銷貨單處理，通路多、例外狀況多時再加上訂單管理，兩邊用料號與單號串接，各自負責處理進度與數量成本。
只有官網一個通路，需要訂單管理系統嗎？
若官網後台已能處理付款確認、出貨與退貨，資料也能匯出給會計，可以先不用。等到開始經營電商平台賣場、門市或企業客戶訂單，人工彙整時間明顯增加時再評估。
多通路共用庫存要怎麼避免超賣？
可以縮短可賣量的更新間隔、保留一部分安全數量不開放販售，並在訂單匯入時檢查庫存，不足時轉入待確認，由客服聯繫顧客改期或取消。
訂單管理系統要保存哪些操作紀錄？
至少記錄狀態變更、地址或商品異動、取消與退款的操作人和時間，客訴或對帳時才能還原經過，也能檢查是否有人未經授權修改訂單或匯出個資。
導入時可以先只做部分功能嗎？
可以。例如先完成訂單匯整與狀態管理，再接物流與發票，接著處理退貨與對帳。每一階段都要定義新舊流程並行的期間與以哪邊資料為準，避免重複出貨。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
規劃訂單管理系統前，先把各通路的訂單流程、狀態與例外整理成一份清單，並確認庫存與發票以哪個系統為準，這份清單也是比較方案與驗收的依據。京采可以協助釐清需求、規劃訂單後台與狀態流程，並開發官網、銷售通路、物流與既有系統之間的串接，相關做法可參考網頁設計服務，或與我們聯繫討論你的通路與出貨方式。
