起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識揭密訂單管理系統（OMS）要處理的那些事
訂單要做到集中處理就需要用到OMS系統，本篇文章筆者為大家總結介紹了OMS能處理的業務，僅限發貨前的訂單處理，供大家參考學習。
筆者一開始接觸電商的時候做的就是訂單系統，包括C端的訂單管理和商家端的訂單管理，涉及到簡單的正向流程和逆向流程，當時對商家接收到這些訂單之后在平臺之外是如何處理訂單的知之甚少。
后來開始接觸OMS，發現跟OMS相比，之前做的訂單管理簡直是小巫見大巫，C端跟商家端只是簡單的信息與流程處理，復雜的業務全在OMS系統。如果有同學正在接觸OMS系統，建議可以由點及面地逐步理解企業關于訂單的業務運轉內在邏輯和關聯。
我們知道當前商家可選擇的賣貨平臺很多，像淘寶、天貓、京東、蘇寧、拼多多、小紅書等等，也可能有自營平臺，那么這眾多平臺的訂單如何集中處理，就需要用到OMS系統了。
所以本次想給大家總結的OMS能處理的業務（僅限發貨前的訂單處理），是以以上場景為基礎的。
訂單管理系統架構
用戶在各大平臺上產生的訂單，會經過訂單翻譯中心，將平臺訂單翻譯為ERP訂單，后續的訂單處理都是基于ERP訂單，訂單處理完成會推送至倉庫進行揀貨發貨。
訂單翻譯
所謂訂單翻譯，就是將各大平臺訂單轉換為ERP訂單的過程。
訂單翻譯過程會做些什么？
1. 將平臺商品翻譯為ERP商品
平臺商品：即用戶在C端直接購買的商品；
ERP商品：即倉庫的實物商品，即用戶實際會收到的商品。
商家在真實售賣過程中，平臺商品跟ERP商品有可能不是一一對應的，比如：用戶購買的商品是某品牌面膜60片一盒，倉庫實際給用戶發貨時有可能發的是2盒30片面膜，即一件平臺商品對應了兩件ERP商品（這就是通常聽到的“組合商品”售賣場景）；而倉庫發貨時僅會認ERP商品，倉庫是不知道運營在C端是怎么向消費者售賣商品的，所以就需要翻譯中心將平臺訂單中的商品翻譯為ERP商品。
如何知道平臺商品對應的是哪個ERP商品？
各大平臺的商品信息中有個字段是“商家編碼”，這個字段以前剛接觸電商的時候沒明白是干嘛的，現在知道了，是用來填對應的ERP商品編碼的，通過這個信息，可以知道平臺商品所對應的ERP商品，如果ERP商品本身是組合商品，就需要再通過組合關系對組合商品進行拆分。
2. 獲取平臺訂單中的基本信息
獲取因企業內部業務需要的訂單基本信息，如收貨人、下單/支付時間、訂單實付、商品單價、商品數量、商品實付、商品優惠、會員平臺用戶名、用戶/商家備注等等，其中跟商品相關的數量、金額（包括優惠、實付、單價）需考慮組合商品拆分時的影響。
退款翻譯同訂單。
舉個例子（例子僅涉及商品相關部分）：
翻譯前
翻譯后
訂單處理
訂單處理中涉及的業務項很多，最終目的都是告知倉庫該發或者不該發什么商品。
訂單處理的本質是對訂單和訂單明細中的字段作出更改。
其中所包括的業務項如下圖所示：
添加贈品
添加贈品本質是在ERP訂單明細中添加商品明細行。
什么情況下會在OMS系統中添加贈品？
一般情況下各個平臺會有贈送贈品的營銷工具，那什么情況下會在OMS系統中為用戶添加贈品呢，筆者總結了幾點：
- 平臺無法滿足的部分送贈品場景，如天貓不支持贈送多SKU商品
- 運營期望給用戶驚喜時（在平臺上送贈品，用戶會提前看到）
- 部分不方便在平臺給用戶直接展示的贈品
- OMS送贈品可以提升運營人員工作效率時（如在平臺上，運營需每個店鋪單獨設置送贈品活動，但是在OMS系統運營可以同時為多個店鋪設置送贈品活動）
贈品添加的方式：
1. 單筆訂單單獨贈送贈品
售前客服為了提升轉化率，承諾給某個用戶贈送贈品、售后為了補償某個用戶，承諾給用戶贈送贈品等情況都會需要客服在某筆訂單上為用戶單獨添加贈品。
2. 通過活動規則為訂單添加贈品
此處的活動規則跟各大平臺上贈送贈品的規則類似，不過可滿足同時為多店鋪設置且可贈送平臺限制型贈品。
通過活動規則為訂單添加贈品應該在什么時候添加？
筆者認為在訂單翻譯完成后就可判斷訂單有無滿足的送贈品活動規則了，即此時可為訂單添加贈品，后面預分倉時可帶著贈品一起預分倉。而且添加贈品應該跟平臺維度保持統一，在渠道訂單的維度添加，即判斷渠道訂單是否滿足送贈品條件而不是ERP訂單是否滿足送贈品條件，這樣可以避免拆合單時贈品不知道如何處理的情況發生。
活動規則不僅可為未來訂單添加贈品也可為歷史訂單添加贈品：
現實運營中，偶爾會遇到運營漏送贈品的情況，這個時候再添加像平臺一樣的送贈品規則就不行了，因為已經產生的訂單（且未發貨）需要補送贈品，這種場景也是平臺無法滿足的，但是OMS為了真實場景需要可以滿足，在活動規則中配置是否需要影響已有的訂單即可。
刪除贈品
贈品有添加的需求就會有刪除的需求。刪除贈品的本質即在ERP訂單明細中刪除商品明細行。
什么情況下會刪除贈品？
- 客服手誤添加了錯誤的贈品
- 運營促銷規則建錯，贈送了錯誤的贈品（在平臺或OMS添加了錯誤的規則）
如何刪除贈品？
1. 單筆訂單單獨刪除贈品
同單筆訂單添加贈品類似，可以提供方便客服刪除贈品的功能。
2. 批量刪除贈品
篩選符合條件的訂單，批量刪除贈品。
3. 自動刪除贈品
一定時間內，符合條件訂單下載下來后自動刪除贈品（運營在平臺上促銷規則設錯的場景適用，可以不用等所有問題訂單全下載完再去刪除贈品）。
批量刪除贈品可與自動刪除贈品結合，通過批量刪除贈品規則實現，跟換貨類似，通過規則去觸發刪除贈品還可以方便查看贈品刪除歷史，有刪除錯誤的情況，可以撤消刪除。
指定倉庫
訂單什么時候可以指定倉庫？
訂單翻譯完成即可指定倉庫，這時指定倉庫可以即時占用倉庫庫存，防止超賣。
訂單指定倉庫的依據是什么？
- 倉庫是否有貨
- 哪個倉庫的快遞到達用戶收貨地址體驗最好（依據指定快遞公司標準判斷）
訂單指定倉庫后哪些情況會導致重新分倉？
訂單指定倉庫后不是一直不變的，如果部分信息發生變更，訂單需要重新分倉，大致有如下幾種情況：
- 收貨地址變更
- 商品明細變更（添加/減少商品、商品換貨）
- 更改快遞公司（原來的倉庫可能不支持指定的快遞公司）
指定快遞公司
訂單什么時候可以指定快遞公司？
訂單指定倉庫的時候可以同時指定快遞公司，畢竟指定倉庫時的依據之一就是快遞公司。
指定快遞公司的依據是什么？
- 商品類別（如較輕易損壞的發快遞，較重不易損壞的發物流）
- 快遞時效
- 快遞成本
- 快遞索賠成功率
庫存占用
訂單翻譯完成之后即可占用庫存，此時占用的庫存是虛擬層的庫存，等到訂單下發給倉庫，占用的是WMS層的實物庫存，關于庫存占用詳細業務下次再詳細介紹。
缺貨處理
虛擬層庫存不夠占用時，會導致訂單缺貨。
處理訂單缺貨需依賴客服、采購、運營三方協作的結果。
倉庫庫存增加時，會觸發沖銷訂單缺貨明細。
詳細的缺貨處理業務下次跟庫存一起介紹。
訂單攔截
所謂訂單攔截，即訂單在流轉過程中可能受到多方面的干預或檢測，導致訂單不能正常順暢地往下流轉，等到風險解除后訂單方可正常流轉的過程。
什么情況下會需要攔截訂單？
- 下單客戶是黑名單用戶（惡意下單者或職業打假人等）
- 訂單中有系統無法處理的客戶/客服備注，需要客服人工處理時
- 訂單各項金額校驗不通過時
- 訂單毛利過低時
- 臨時通知某個地區快遞禁發時
- 訂單中的商品正在盤點時
- ……
訂單攔截情況會有很多，具體也可以根據公司具體情況設定。
訂單攔截后的處理方法：
1. 攔截給客服人工審核
訂單未審核時遇到系統無法自動審核的情況（如下單客戶是黑名單客戶或有系統無法處理的備注等等）需要攔截分配給客服人工處理。
2. 因系統判定導致的攔截，需鎖定訂單，待技術或系統處理完成后方可解鎖
如訂單金額校驗不通過，收貨地址無法正常解析等情況下，需要通過攔截將問題訂單暴露出來，方便技術統一處理，處理完成后，可手動批量或系統自動標記處理完成，標記時訂單可自動檢測問題是否仍存在，若問題已解決，則可解鎖攔截。
3. 回滾訂單至上游某個狀態，重新流轉
訂單需要重新分配快遞，或者已審核的訂單其他信息發生變更（如收貨地址、添加/刪除贈品時等等），需要作廢原有的WMS單據，將訂單回滾至上游，重新流轉下發給WMS。
訂單攔截的實現方式：
1. 人工攔截
客服人工修改訂單信息時（如收貨地址，快遞公司）會觸發訂單攔截（已下發給WMS的情況下）。
2. 系統攔截
訂單符合系統設定的攔截條件時，會被攔截（如黑名單等）。
3. 攔截規則攔截
人工添加特定的攔截規則，將符合條件的訂單進行攔截。原則上系統攔截的大多數條件也可以通過攔截規則配置實現。
訂單換貨
訂單換貨的本質是更改訂單中的商品明細。
什么情況下需要換貨？
- 顧客主動提出想換貨（前提是貨物之間的價值近似）
- 顧客買的商品缺貨，與顧客溝通后換貨
- 運營失誤（填寫的ERP商家編碼有誤或后臺送贈品促銷規則有誤），需換成正確的商品
換貨需要注意什么？
換貨可能造成商品件數和商品種類的變化（如一個A換成一個B+一個C），因此需要對換貨后商品的單價、優惠、實付需要重新分攤。
如何換貨？
1. 單筆訂單換貨
針對單筆訂單中的商品進行換貨操作。
2. 批量換貨
篩選符合條件的訂單，批量進行換貨。
3. 自動換貨
一定時間內，符合條件訂單下載下來后自動換貨（運營商家編碼設錯的場景適用，可以不用等所有問題訂單全下載完再去換貨）。
批量換貨可與自動換貨結合，通過批量換貨規則實現，訂單的很多處理都可以通過規則去處理，換貨也是一種使用場景。通過規則去觸發換貨還可以方便查看換貨歷史，如果有換錯的情況，還可以撤消換貨。
訂單備注
什么情況下需要給訂單添加備注？
- 訂單未被審核前，售前如接收到用戶的任何需求，都是通過加訂單備注，標記在ERP訂單上，添加的訂單備注交由系統或審核客服處理
- 審核客服遇到的其他需要標記訂單的情況，如跟客戶溝通延遲發貨等等
訂單備注如何處理？
一部分備注只是客戶給訂單加的標記，方便回頭查訂單時溯源，是無需特殊處理的；
一部分備注是承載了客戶的要求，如指定快遞，指定發貨日期，更換收貨地址等等，這部分需要交由系統或人工處理，系統處理的方式是通過語義分析識別文字想要表達的含義然后再自動處理，下文會小小介紹下語義分析。
訂單備注添加的維度？
因為審核客服是在ERP訂單的維度處理訂單，下發給倉庫也是以ERP維度下發，所以備注的添加是基于ERP訂單維度，即為當前發貨單添加備注信息，不過這樣要注意訂單拆合對備注的影響（不能因為訂單拆合導致備注丟失）。
售中工單：
所謂售中工單就是訂單在審核后但未發貨前，客戶對訂單仍有修改需求的，由售前通過售中工單提交給訂單處理客服進行處理。
售中工單的處理方式：
1. 語義分析
跟普通備注一樣，售中工單也會先通過系統的語義分析識別文字想要表達的含義然后再自動處理，系統無法識別的交由人工處理。
2.. 人工處理
即人工按照售中工單的內容處理訂單。
語義分析
訂單處理的過程中哪些地方需要用到語義分析？
- 消費者提交訂單時添加了備注
- 訂單未審核前，售前為消費者通過備注的方式提交了訂單需求
- 訂單審核后未發貨前，售前為消費者通過售中工單的方式提交了訂單需求
總結下來，語義分析就是分析客戶或售前給訂單提交的修改需求。如果沒有語義分析，全靠客服人工處理訂單，處理量會相當大。
通過語義分析處理訂單時，需借助成熟的語義分析系統和公司本身建立的詞庫，去識別語義的含義類別，如將“請發中通快遞”維護在公司本身的詞庫后，語義分析遇到這種完全一樣的備注時，就知道這種是要指定快遞，便可調用訂單修改快遞公司接口修改快遞公司。
訂單開票
消費者在購買商品時或購買商品后，可能有開具發票的需求，一般會在平臺上通過申請發票入口向賣家申請發票，或者通過平臺聊天工具找到賣家向賣家索取發票。
商家可選擇的開票方式：
1. 接入平臺的開票服務進行開票
這個需要商家所使用的平臺開票服務均比較完善的情況下才可使用，否則部分平臺可開票，部分平臺未提供開票服務操作起來就比較麻煩。
2. 商戶自行開票
商戶統一收取各個平臺用戶的開票需求，統一路徑開票。收取的方式包括：通過平臺接口獲取用戶在平臺上所填寫的開票需求；通過客服人工錄入用戶的開票需求
發票類型：
1. 紙質發票
如果商家開具的是紙質發票，在發貨前開具的，可跟發貨商品一起發出，在發貨后開具的，需單獨用快遞寄出。無論在哪種場景下，都會增加線下人員的操作成本，發貨后開具的還會增加企業的快遞成本。
2. 電子發票
電子發票的出現解決了紙質發票遇到的問題，如果商品尚未發出，電子發票可在商品發出時開具，如果商品已發出，可即時開具。需要注意的是，開具完電子發票要及時通知用戶發票已開具，可通過將開票信息回傳至平臺告知，或給用戶發短信告知。
開票需求錄入維度：
開票需求是基于ERP訂單錄入，如果是開紙質發票的話，這樣可以避免合單的情況下需要開多次發票。
拆合單
什么情況下需要拆單？
- 同一訂單需由不同倉庫發貨（倉庫維度的判斷需放在第一位）
- 同一訂單中的商品不可同時打包，如鉆石（高價值商品）就不可與食品一起打包，或者公司層面基于物流成本考慮需要將不同的商品發不同的快遞（比較重的不易損壞的發物流，輕的易損壞的發快遞）
- 用戶主動放棄購買訂單中的部分商品，即訂單部分商品發生退款
- 訂單缺貨的情況下，用戶允許部分商品先發貨
- 其他特殊情況（需根據公司具體業務而定）
什么情況下需要合單？
為了節約公司快遞成本，將同一渠道同一客戶所提交的同一收貨地址分配在同一倉庫的未發貨訂單進行合并
訂單拆合單的本質是什么？
訂單拆合單的本質是不同訂單的明細自由組合，且是建立在一定規則基礎上的自由組合，因此訂單拆合的次數可以是不限的。組合過程中需始終記錄原始渠道明細單號（即渠道子訂單號，上文例子中的001001和001002），這樣的好處是可以溯源，如果用戶針對某個明細商品發生退款，我們可以準確地在ERP商品中標記出來，后續財務針對部分商品收款時（財務是以渠道訂單為基礎做的收款），也可以明確地知道是哪些ERP商品收款了。
訂單拆合單需注意什么？
- 訂單拆合過程中要對商品的總優惠及實付進行重新分攤或求和
- 如果拆出來的訂單取消了，需取消其對庫存的占用
- 如果原有訂單有發生缺貨，需同時更新其對應的缺貨信息（取消舊的缺貨信息，以拆合后的訂單判斷是否缺貨）
- 訂單需要重新分倉、分配快遞
- 訂單備注、開票需求不能因為拆合單丟失
- 訂單審核前拆合單，需重新觸發生成新的攔截記錄；訂單審核后拆合單，無需重新生成新的攔截記錄。
拆合單后系統UI層面需注意什么？
- 展示當前訂單的拆合單狀態
- 展示當前訂單的拆合原訂單，方便溯源
訂單退款
訂單從支付完成到最終發貨的過程中，用戶可能突然不想要了，申請退款，這時需要對申請退款的訂單作處理。
如何處理訂單退款？
直覺上而言，如果用戶申請退款，我們需要鎖定OMS訂單和WMS出庫單，訂單退款成功則取消相應的OMS訂單和WMS出庫單，訂單退款被商戶拒絕或用戶取消退款則解鎖OMS訂單和WMS出庫單繼續流轉。
但是細想這樣處理對OMS訂單而言是沒有問題的，但對WMS是不利的，為什么呢？考慮下現實場景和真實數據，訂單從翻譯至ERP到最終從倉庫發貨，退款的訂單量還是很大的，而且在這大批量的退款中99%商家都會同意用戶的退款申請給用戶退款的，這樣一來如果鎖住倉庫的出庫單，倉庫就會有一堆未出庫但已揀貨的打包盒，里面裝了要給用戶發貨的商品，等到出庫單解鎖時，需要倉庫從這一堆打包盒里面找出解鎖出庫單對應的打包盒進行出庫操作，可想而知有多影響倉庫效率，放在雙11這種時候更不敢想象。
因此理想的操作是：
如果訂單發生退款可以鎖定OMS訂單，但取消對應的出庫單；
若全部商品退款成功，可以取消OMS訂單；
若部分商品退款成功，可以自動拆單；
若訂單退款被商戶拒絕或用戶取消退款，則可以重新生成出庫單，讓倉庫當成新的揀貨任務進行揀貨，這樣可以提升倉庫的揀貨效率。
訂單審核
訂單審核是確認當前ERP訂單可以下發給倉庫（WMS）的確認操作。
訂單自動審核：
ERP訂單產生且預分倉成功后，會經過系統的層層篩選判斷，這些判斷匯集一下就兩大點：有無滿足的攔截條件和消費者/客服備注能否系統自動處理，如果訂單流轉順利未被攔截且其中的備注能被系統完全識別處理，則可以自動審核，下發至倉庫。
人工審核：
系統無法審核的，均交由人工處理。
ERP訂單關鍵信息說明
以上是結合目前所在公司真實業務思考所得，跟真實業務有偏差（真實業務因為各種原因某些方面雖不合理，但不致使影響使用，就沒硬照著可能正確的方向修正），如果各位同學看了覺得有可以優化的地方，可以及時交流。
作者：青檸，微信公眾號：一只進化中的產品汪（pm_move_forward），歡迎交流。
本文由 @青檸 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
學習了
訂單翻譯那里是不是有點問題？
方便留一下您的微信號嗎，謝謝
如何處理訂單退款？
這段我理解的是，退款成功的，wms取消發貨，部分不退款的或者全不退款的定單，重新揀貨，不在已打包的揀貨區取貨是么？如果是這意思也有很多成本啊。
Wms取消發貨可以有多個節點，波次運行，揀貨，復核這3個結點都可以，理論上只要未出庫都可以取消
很有幫助！喜歡
寫的很詳細，不過復用性不高，僅適合比較大的商家
很棒