訂單要做到集中處理就需要用到OMS系統(tǒng)，本篇文章筆者為大家總結(jié)介紹了OMS能處理的業(yè)務(wù)，僅限發(fā)貨前的訂單處理，供大家參考學(xué)習(xí)。

筆者一開始接觸電商的時(shí)候做的就是訂單系統(tǒng)，包括C端的訂單管理和商家端的訂單管理，涉及到簡(jiǎn)單的正向流程和逆向流程，當(dāng)時(shí)對(duì)商家接收到這些訂單之后在平臺(tái)之外是如何處理訂單的知之甚少。

后來開始接觸OMS，發(fā)現(xiàn)跟OMS相比，之前做的訂單管理簡(jiǎn)直是小巫見大巫，C端跟商家端只是簡(jiǎn)單的信息與流程處理，復(fù)雜的業(yè)務(wù)全在OMS系統(tǒng)。如果有同學(xué)正在接觸OMS系統(tǒng)，建議可以由點(diǎn)及面地逐步理解企業(yè)關(guān)于訂單的業(yè)務(wù)運(yùn)轉(zhuǎn)內(nèi)在邏輯和關(guān)聯(lián)。

我們知道當(dāng)前商家可選擇的賣貨平臺(tái)很多，像淘寶、天貓、京東、蘇寧、拼多多、小紅書等等，也可能有自營(yíng)平臺(tái)，那么這眾多平臺(tái)的訂單如何集中處理，就需要用到OMS系統(tǒng)了。

所以本次想給大家總結(jié)的OMS能處理的業(yè)務(wù)（僅限發(fā)貨前的訂單處理），是以以上場(chǎng)景為基礎(chǔ)的。

訂單管理系統(tǒng)架構(gòu)

用戶在各大平臺(tái)上產(chǎn)生的訂單，會(huì)經(jīng)過訂單翻譯中心，將平臺(tái)訂單翻譯為ERP訂單，后續(xù)的訂單處理都是基于ERP訂單，訂單處理完成會(huì)推送至倉(cāng)庫(kù)進(jìn)行揀貨發(fā)貨。

訂單翻譯

所謂訂單翻譯，就是將各大平臺(tái)訂單轉(zhuǎn)換為ERP訂單的過程。

訂單翻譯過程會(huì)做些什么？

1. 將平臺(tái)商品翻譯為ERP商品

平臺(tái)商品：即用戶在C端直接購(gòu)買的商品；

ERP商品：即倉(cāng)庫(kù)的實(shí)物商品，即用戶實(shí)際會(huì)收到的商品。

商家在真實(shí)售賣過程中，平臺(tái)商品跟ERP商品有可能不是一一對(duì)應(yīng)的，比如：用戶購(gòu)買的商品是某品牌面膜60片一盒，倉(cāng)庫(kù)實(shí)際給用戶發(fā)貨時(shí)有可能發(fā)的是2盒30片面膜，即一件平臺(tái)商品對(duì)應(yīng)了兩件ERP商品（這就是通常聽到的“組合商品”售賣場(chǎng)景）；而倉(cāng)庫(kù)發(fā)貨時(shí)僅會(huì)認(rèn)ERP商品，倉(cāng)庫(kù)是不知道運(yùn)營(yíng)在C端是怎么向消費(fèi)者售賣商品的，所以就需要翻譯中心將平臺(tái)訂單中的商品翻譯為ERP商品。

如何知道平臺(tái)商品對(duì)應(yīng)的是哪個(gè)ERP商品？

各大平臺(tái)的商品信息中有個(gè)字段是“商家編碼”，這個(gè)字段以前剛接觸電商的時(shí)候沒明白是干嘛的，現(xiàn)在知道了，是用來填對(duì)應(yīng)的ERP商品編碼的，通過這個(gè)信息，可以知道平臺(tái)商品所對(duì)應(yīng)的ERP商品，如果ERP商品本身是組合商品，就需要再通過組合關(guān)系對(duì)組合商品進(jìn)行拆分。

2. 獲取平臺(tái)訂單中的基本信息

獲取因企業(yè)內(nèi)部業(yè)務(wù)需要的訂單基本信息，如收貨人、下單/支付時(shí)間、訂單實(shí)付、商品單價(jià)、商品數(shù)量、商品實(shí)付、商品優(yōu)惠、會(huì)員平臺(tái)用戶名、用戶/商家備注等等，其中跟商品相關(guān)的數(shù)量、金額（包括優(yōu)惠、實(shí)付、單價(jià)）需考慮組合商品拆分時(shí)的影響。

退款翻譯同訂單。

舉個(gè)例子（例子僅涉及商品相關(guān)部分）：

翻譯前

翻譯后

訂單處理

訂單處理中涉及的業(yè)務(wù)項(xiàng)很多，最終目的都是告知倉(cāng)庫(kù)該發(fā)或者不該發(fā)什么商品。

訂單處理的本質(zhì)是對(duì)訂單和訂單明細(xì)中的字段作出更改。

其中所包括的業(yè)務(wù)項(xiàng)如下圖所示：

添加贈(zèng)品

添加贈(zèng)品本質(zhì)是在ERP訂單明細(xì)中添加商品明細(xì)行。

什么情況下會(huì)在OMS系統(tǒng)中添加贈(zèng)品？

一般情況下各個(gè)平臺(tái)會(huì)有贈(zèng)送贈(zèng)品的營(yíng)銷工具，那什么情況下會(huì)在OMS系統(tǒng)中為用戶添加贈(zèng)品呢，筆者總結(jié)了幾點(diǎn)：

• 平臺(tái)無法滿足的部分送贈(zèng)品場(chǎng)景，如天貓不支持贈(zèng)送多SKU商品
• 運(yùn)營(yíng)期望給用戶驚喜時(shí)（在平臺(tái)上送贈(zèng)品，用戶會(huì)提前看到）
• 部分不方便在平臺(tái)給用戶直接展示的贈(zèng)品
• OMS送贈(zèng)品可以提升運(yùn)營(yíng)人員工作效率時(shí)（如在平臺(tái)上，運(yùn)營(yíng)需每個(gè)店鋪單獨(dú)設(shè)置送贈(zèng)品活動(dòng)，但是在OMS系統(tǒng)運(yùn)營(yíng)可以同時(shí)為多個(gè)店鋪設(shè)置送贈(zèng)品活動(dòng)）

贈(zèng)品添加的方式：

1. 單筆訂單單獨(dú)贈(zèng)送贈(zèng)品

售前客服為了提升轉(zhuǎn)化率，承諾給某個(gè)用戶贈(zèng)送贈(zèng)品、售后為了補(bǔ)償某個(gè)用戶，承諾給用戶贈(zèng)送贈(zèng)品等情況都會(huì)需要客服在某筆訂單上為用戶單獨(dú)添加贈(zèng)品。

2. 通過活動(dòng)規(guī)則為訂單添加贈(zèng)品

此處的活動(dòng)規(guī)則跟各大平臺(tái)上贈(zèng)送贈(zèng)品的規(guī)則類似，不過可滿足同時(shí)為多店鋪設(shè)置且可贈(zèng)送平臺(tái)限制型贈(zèng)品。

通過活動(dòng)規(guī)則為訂單添加贈(zèng)品應(yīng)該在什么時(shí)候添加？

筆者認(rèn)為在訂單翻譯完成后就可判斷訂單有無滿足的送贈(zèng)品活動(dòng)規(guī)則了，即此時(shí)可為訂單添加贈(zèng)品，后面預(yù)分倉(cāng)時(shí)可帶著贈(zèng)品一起預(yù)分倉(cāng)。而且添加贈(zèng)品應(yīng)該跟平臺(tái)維度保持統(tǒng)一，在渠道訂單的維度添加，即判斷渠道訂單是否滿足送贈(zèng)品條件而不是ERP訂單是否滿足送贈(zèng)品條件，這樣可以避免拆合單時(shí)贈(zèng)品不知道如何處理的情況發(fā)生。

活動(dòng)規(guī)則不僅可為未來訂單添加贈(zèng)品也可為歷史訂單添加贈(zèng)品：

現(xiàn)實(shí)運(yùn)營(yíng)中，偶爾會(huì)遇到運(yùn)營(yíng)漏送贈(zèng)品的情況，這個(gè)時(shí)候再添加像平臺(tái)一樣的送贈(zèng)品規(guī)則就不行了，因?yàn)橐呀?jīng)產(chǎn)生的訂單（且未發(fā)貨）需要補(bǔ)送贈(zèng)品，這種場(chǎng)景也是平臺(tái)無法滿足的，但是OMS為了真實(shí)場(chǎng)景需要可以滿足，在活動(dòng)規(guī)則中配置是否需要影響已有的訂單即可。

刪除贈(zèng)品

贈(zèng)品有添加的需求就會(huì)有刪除的需求。刪除贈(zèng)品的本質(zhì)即在ERP訂單明細(xì)中刪除商品明細(xì)行。

什么情況下會(huì)刪除贈(zèng)品？

• 客服手誤添加了錯(cuò)誤的贈(zèng)品
• 運(yùn)營(yíng)促銷規(guī)則建錯(cuò)，贈(zèng)送了錯(cuò)誤的贈(zèng)品（在平臺(tái)或OMS添加了錯(cuò)誤的規(guī)則）

如何刪除贈(zèng)品？

1. 單筆訂單單獨(dú)刪除贈(zèng)品

同單筆訂單添加贈(zèng)品類似，可以提供方便客服刪除贈(zèng)品的功能。

2. 批量刪除贈(zèng)品

篩選符合條件的訂單，批量刪除贈(zèng)品。

3. 自動(dòng)刪除贈(zèng)品

一定時(shí)間內(nèi)，符合條件訂單下載下來后自動(dòng)刪除贈(zèng)品（運(yùn)營(yíng)在平臺(tái)上促銷規(guī)則設(shè)錯(cuò)的場(chǎng)景適用，可以不用等所有問題訂單全下載完再去刪除贈(zèng)品）。

批量刪除贈(zèng)品可與自動(dòng)刪除贈(zèng)品結(jié)合，通過批量刪除贈(zèng)品規(guī)則實(shí)現(xiàn)，跟換貨類似，通過規(guī)則去觸發(fā)刪除贈(zèng)品還可以方便查看贈(zèng)品刪除歷史，有刪除錯(cuò)誤的情況，可以撤消刪除。

指定倉(cāng)庫(kù)

訂單什么時(shí)候可以指定倉(cāng)庫(kù)？

訂單翻譯完成即可指定倉(cāng)庫(kù)，這時(shí)指定倉(cāng)庫(kù)可以即時(shí)占用倉(cāng)庫(kù)庫(kù)存，防止超賣。

訂單指定倉(cāng)庫(kù)的依據(jù)是什么？

• 倉(cāng)庫(kù)是否有貨
• 哪個(gè)倉(cāng)庫(kù)的快遞到達(dá)用戶收貨地址體驗(yàn)最好（依據(jù)指定快遞公司標(biāo)準(zhǔn)判斷）

訂單指定倉(cāng)庫(kù)后哪些情況會(huì)導(dǎo)致重新分倉(cāng)？

訂單指定倉(cāng)庫(kù)后不是一直不變的，如果部分信息發(fā)生變更，訂單需要重新分倉(cāng)，大致有如下幾種情況：

• 收貨地址變更
• 商品明細(xì)變更（添加/減少商品、商品換貨）
• 更改快遞公司（原來的倉(cāng)庫(kù)可能不支持指定的快遞公司）

指定快遞公司

訂單什么時(shí)候可以指定快遞公司？

訂單指定倉(cāng)庫(kù)的時(shí)候可以同時(shí)指定快遞公司，畢竟指定倉(cāng)庫(kù)時(shí)的依據(jù)之一就是快遞公司。

指定快遞公司的依據(jù)是什么？

• 商品類別（如較輕易損壞的發(fā)快遞，較重不易損壞的發(fā)物流）
• 快遞時(shí)效
• 快遞成本
• 快遞索賠成功率

庫(kù)存占用

訂單翻譯完成之后即可占用庫(kù)存，此時(shí)占用的庫(kù)存是虛擬層的庫(kù)存，等到訂單下發(fā)給倉(cāng)庫(kù)，占用的是WMS層的實(shí)物庫(kù)存，關(guān)于庫(kù)存占用詳細(xì)業(yè)務(wù)下次再詳細(xì)介紹。

缺貨處理

虛擬層庫(kù)存不夠占用時(shí)，會(huì)導(dǎo)致訂單缺貨。

處理訂單缺貨需依賴客服、采購(gòu)、運(yùn)營(yíng)三方協(xié)作的結(jié)果。

倉(cāng)庫(kù)庫(kù)存增加時(shí)，會(huì)觸發(fā)沖銷訂單缺貨明細(xì)。

詳細(xì)的缺貨處理業(yè)務(wù)下次跟庫(kù)存一起介紹。

訂單攔截

所謂訂單攔截，即訂單在流轉(zhuǎn)過程中可能受到多方面的干預(yù)或檢測(cè)，導(dǎo)致訂單不能正常順暢地往下流轉(zhuǎn)，等到風(fēng)險(xiǎn)解除后訂單方可正常流轉(zhuǎn)的過程。

什么情況下會(huì)需要攔截訂單？

• 下單客戶是黑名單用戶（惡意下單者或職業(yè)打假人等）
• 訂單中有系統(tǒng)無法處理的客戶/客服備注，需要客服人工處理時(shí)
• 訂單各項(xiàng)金額校驗(yàn)不通過時(shí)
• 訂單毛利過低時(shí)
• 臨時(shí)通知某個(gè)地區(qū)快遞禁發(fā)時(shí)
• 訂單中的商品正在盤點(diǎn)時(shí)
• ……

訂單攔截情況會(huì)有很多，具體也可以根據(jù)公司具體情況設(shè)定。

訂單攔截后的處理方法：

1. 攔截給客服人工審核

訂單未審核時(shí)遇到系統(tǒng)無法自動(dòng)審核的情況（如下單客戶是黑名單客戶或有系統(tǒng)無法處理的備注等等）需要攔截分配給客服人工處理。

2. 因系統(tǒng)判定導(dǎo)致的攔截，需鎖定訂單，待技術(shù)或系統(tǒng)處理完成后方可解鎖

如訂單金額校驗(yàn)不通過，收貨地址無法正常解析等情況下，需要通過攔截將問題訂單暴露出來，方便技術(shù)統(tǒng)一處理，處理完成后，可手動(dòng)批量或系統(tǒng)自動(dòng)標(biāo)記處理完成，標(biāo)記時(shí)訂單可自動(dòng)檢測(cè)問題是否仍存在，若問題已解決，則可解鎖攔截。

3. 回滾訂單至上游某個(gè)狀態(tài)，重新流轉(zhuǎn)

訂單需要重新分配快遞，或者已審核的訂單其他信息發(fā)生變更（如收貨地址、添加/刪除贈(zèng)品時(shí)等等），需要作廢原有的WMS單據(jù)，將訂單回滾至上游，重新流轉(zhuǎn)下發(fā)給WMS。

訂單攔截的實(shí)現(xiàn)方式：

1. 人工攔截

客服人工修改訂單信息時(shí)（如收貨地址，快遞公司）會(huì)觸發(fā)訂單攔截（已下發(fā)給WMS的情況下）。

2. 系統(tǒng)攔截

訂單符合系統(tǒng)設(shè)定的攔截條件時(shí)，會(huì)被攔截（如黑名單等）。

3. 攔截規(guī)則攔截

人工添加特定的攔截規(guī)則，將符合條件的訂單進(jìn)行攔截。原則上系統(tǒng)攔截的大多數(shù)條件也可以通過攔截規(guī)則配置實(shí)現(xiàn)。

訂單換貨

訂單換貨的本質(zhì)是更改訂單中的商品明細(xì)。

什么情況下需要換貨？

• 顧客主動(dòng)提出想換貨（前提是貨物之間的價(jià)值近似）
• 顧客買的商品缺貨，與顧客溝通后換貨
• 運(yùn)營(yíng)失誤（填寫的ERP商家編碼有誤或后臺(tái)送贈(zèng)品促銷規(guī)則有誤），需換成正確的商品

換貨需要注意什么？

換貨可能造成商品件數(shù)和商品種類的變化（如一個(gè)A換成一個(gè)B+一個(gè)C），因此需要對(duì)換貨后商品的單價(jià)、優(yōu)惠、實(shí)付需要重新分?jǐn)偂?/p>

如何換貨？

1. 單筆訂單換貨

針對(duì)單筆訂單中的商品進(jìn)行換貨操作。

2. 批量換貨

篩選符合條件的訂單，批量進(jìn)行換貨。

3. 自動(dòng)換貨

一定時(shí)間內(nèi)，符合條件訂單下載下來后自動(dòng)換貨（運(yùn)營(yíng)商家編碼設(shè)錯(cuò)的場(chǎng)景適用，可以不用等所有問題訂單全下載完再去換貨）。

批量換貨可與自動(dòng)換貨結(jié)合，通過批量換貨規(guī)則實(shí)現(xiàn)，訂單的很多處理都可以通過規(guī)則去處理，換貨也是一種使用場(chǎng)景。通過規(guī)則去觸發(fā)換貨還可以方便查看換貨歷史，如果有換錯(cuò)的情況，還可以撤消換貨。

訂單備注

什么情況下需要給訂單添加備注？

• 訂單未被審核前，售前如接收到用戶的任何需求，都是通過加訂單備注，標(biāo)記在ERP訂單上，添加的訂單備注交由系統(tǒng)或?qū)徍丝头幚?/li>
• 審核客服遇到的其他需要標(biāo)記訂單的情況，如跟客戶溝通延遲發(fā)貨等等

訂單備注如何處理？

一部分備注只是客戶給訂單加的標(biāo)記，方便回頭查訂單時(shí)溯源，是無需特殊處理的；

一部分備注是承載了客戶的要求，如指定快遞，指定發(fā)貨日期，更換收貨地址等等，這部分需要交由系統(tǒng)或人工處理，系統(tǒng)處理的方式是通過語義分析識(shí)別文字想要表達(dá)的含義然后再自動(dòng)處理，下文會(huì)小小介紹下語義分析。

訂單備注添加的維度？

因?yàn)閷徍丝头窃贓RP訂單的維度處理訂單，下發(fā)給倉(cāng)庫(kù)也是以ERP維度下發(fā)，所以備注的添加是基于ERP訂單維度，即為當(dāng)前發(fā)貨單添加備注信息，不過這樣要注意訂單拆合對(duì)備注的影響（不能因?yàn)橛唵尾鸷蠈?dǎo)致備注丟失）。

售中工單：

所謂售中工單就是訂單在審核后但未發(fā)貨前，客戶對(duì)訂單仍有修改需求的，由售前通過售中工單提交給訂單處理客服進(jìn)行處理。

售中工單的處理方式：

1. 語義分析

跟普通備注一樣，售中工單也會(huì)先通過系統(tǒng)的語義分析識(shí)別文字想要表達(dá)的含義然后再自動(dòng)處理，系統(tǒng)無法識(shí)別的交由人工處理。

2.. 人工處理

即人工按照售中工單的內(nèi)容處理訂單。

語義分析

訂單處理的過程中哪些地方需要用到語義分析？

• 消費(fèi)者提交訂單時(shí)添加了備注
• 訂單未審核前，售前為消費(fèi)者通過備注的方式提交了訂單需求
• 訂單審核后未發(fā)貨前，售前為消費(fèi)者通過售中工單的方式提交了訂單需求

總結(jié)下來，語義分析就是分析客戶或售前給訂單提交的修改需求。如果沒有語義分析，全靠客服人工處理訂單，處理量會(huì)相當(dāng)大。

通過語義分析處理訂單時(shí)，需借助成熟的語義分析系統(tǒng)和公司本身建立的詞庫(kù)，去識(shí)別語義的含義類別，如將“請(qǐng)發(fā)中通快遞”維護(hù)在公司本身的詞庫(kù)后，語義分析遇到這種完全一樣的備注時(shí)，就知道這種是要指定快遞，便可調(diào)用訂單修改快遞公司接口修改快遞公司。

訂單開票

消費(fèi)者在購(gòu)買商品時(shí)或購(gòu)買商品后，可能有開具發(fā)票的需求，一般會(huì)在平臺(tái)上通過申請(qǐng)發(fā)票入口向賣家申請(qǐng)發(fā)票，或者通過平臺(tái)聊天工具找到賣家向賣家索取發(fā)票。

商家可選擇的開票方式：

1. 接入平臺(tái)的開票服務(wù)進(jìn)行開票

這個(gè)需要商家所使用的平臺(tái)開票服務(wù)均比較完善的情況下才可使用，否則部分平臺(tái)可開票，部分平臺(tái)未提供開票服務(wù)操作起來就比較麻煩。

2. 商戶自行開票

商戶統(tǒng)一收取各個(gè)平臺(tái)用戶的開票需求，統(tǒng)一路徑開票。收取的方式包括：通過平臺(tái)接口獲取用戶在平臺(tái)上所填寫的開票需求；通過客服人工錄入用戶的開票需求

發(fā)票類型：

1. 紙質(zhì)發(fā)票

如果商家開具的是紙質(zhì)發(fā)票，在發(fā)貨前開具的，可跟發(fā)貨商品一起發(fā)出，在發(fā)貨后開具的，需單獨(dú)用快遞寄出。無論在哪種場(chǎng)景下，都會(huì)增加線下人員的操作成本，發(fā)貨后開具的還會(huì)增加企業(yè)的快遞成本。

2. 電子發(fā)票

電子發(fā)票的出現(xiàn)解決了紙質(zhì)發(fā)票遇到的問題，如果商品尚未發(fā)出，電子發(fā)票可在商品發(fā)出時(shí)開具，如果商品已發(fā)出，可即時(shí)開具。需要注意的是，開具完電子發(fā)票要及時(shí)通知用戶發(fā)票已開具，可通過將開票信息回傳至平臺(tái)告知，或給用戶發(fā)短信告知。

開票需求錄入維度：

開票需求是基于ERP訂單錄入，如果是開紙質(zhì)發(fā)票的話，這樣可以避免合單的情況下需要開多次發(fā)票。

拆合單

什么情況下需要拆單？

• 同一訂單需由不同倉(cāng)庫(kù)發(fā)貨（倉(cāng)庫(kù)維度的判斷需放在第一位）
• 同一訂單中的商品不可同時(shí)打包，如鉆石（高價(jià)值商品）就不可與食品一起打包，或者公司層面基于物流成本考慮需要將不同的商品發(fā)不同的快遞（比較重的不易損壞的發(fā)物流，輕的易損壞的發(fā)快遞）
• 用戶主動(dòng)放棄購(gòu)買訂單中的部分商品，即訂單部分商品發(fā)生退款
• 訂單缺貨的情況下，用戶允許部分商品先發(fā)貨
• 其他特殊情況（需根據(jù)公司具體業(yè)務(wù)而定）

什么情況下需要合單？

為了節(jié)約公司快遞成本，將同一渠道同一客戶所提交的同一收貨地址分配在同一倉(cāng)庫(kù)的未發(fā)貨訂單進(jìn)行合并

訂單拆合單的本質(zhì)是什么？

訂單拆合單的本質(zhì)是不同訂單的明細(xì)自由組合，且是建立在一定規(guī)則基礎(chǔ)上的自由組合，因此訂單拆合的次數(shù)可以是不限的。組合過程中需始終記錄原始渠道明細(xì)單號(hào)（即渠道子訂單號(hào)，上文例子中的001001和001002），這樣的好處是可以溯源，如果用戶針對(duì)某個(gè)明細(xì)商品發(fā)生退款，我們可以準(zhǔn)確地在ERP商品中標(biāo)記出來，后續(xù)財(cái)務(wù)針對(duì)部分商品收款時(shí)（財(cái)務(wù)是以渠道訂單為基礎(chǔ)做的收款），也可以明確地知道是哪些ERP商品收款了。

訂單拆合單需注意什么？

• 訂單拆合過程中要對(duì)商品的總優(yōu)惠及實(shí)付進(jìn)行重新分?jǐn)偦蚯蠛?/li>
• 如果拆出來的訂單取消了，需取消其對(duì)庫(kù)存的占用
• 如果原有訂單有發(fā)生缺貨，需同時(shí)更新其對(duì)應(yīng)的缺貨信息（取消舊的缺貨信息，以拆合后的訂單判斷是否缺貨）
• 訂單需要重新分倉(cāng)、分配快遞
• 訂單備注、開票需求不能因?yàn)椴鸷蠁蝸G失
• 訂單審核前拆合單，需重新觸發(fā)生成新的攔截記錄；訂單審核后拆合單，無需重新生成新的攔截記錄。

拆合單后系統(tǒng)UI層面需注意什么？

• 展示當(dāng)前訂單的拆合單狀態(tài)
• 展示當(dāng)前訂單的拆合原訂單，方便溯源

訂單退款

訂單從支付完成到最終發(fā)貨的過程中，用戶可能突然不想要了，申請(qǐng)退款，這時(shí)需要對(duì)申請(qǐng)退款的訂單作處理。

如何處理訂單退款？

直覺上而言，如果用戶申請(qǐng)退款，我們需要鎖定OMS訂單和WMS出庫(kù)單，訂單退款成功則取消相應(yīng)的OMS訂單和WMS出庫(kù)單，訂單退款被商戶拒絕或用戶取消退款則解鎖OMS訂單和WMS出庫(kù)單繼續(xù)流轉(zhuǎn)。

但是細(xì)想這樣處理對(duì)OMS訂單而言是沒有問題的，但對(duì)WMS是不利的，為什么呢？考慮下現(xiàn)實(shí)場(chǎng)景和真實(shí)數(shù)據(jù)，訂單從翻譯至ERP到最終從倉(cāng)庫(kù)發(fā)貨，退款的訂單量還是很大的，而且在這大批量的退款中99%商家都會(huì)同意用戶的退款申請(qǐng)給用戶退款的，這樣一來如果鎖住倉(cāng)庫(kù)的出庫(kù)單，倉(cāng)庫(kù)就會(huì)有一堆未出庫(kù)但已揀貨的打包盒，里面裝了要給用戶發(fā)貨的商品，等到出庫(kù)單解鎖時(shí)，需要倉(cāng)庫(kù)從這一堆打包盒里面找出解鎖出庫(kù)單對(duì)應(yīng)的打包盒進(jìn)行出庫(kù)操作，可想而知有多影響倉(cāng)庫(kù)效率，放在雙11這種時(shí)候更不敢想象。

因此理想的操作是：

如果訂單發(fā)生退款可以鎖定OMS訂單，但取消對(duì)應(yīng)的出庫(kù)單；

若全部商品退款成功，可以取消OMS訂單；

若部分商品退款成功，可以自動(dòng)拆單；

若訂單退款被商戶拒絕或用戶取消退款，則可以重新生成出庫(kù)單，讓倉(cāng)庫(kù)當(dāng)成新的揀貨任務(wù)進(jìn)行揀貨，這樣可以提升倉(cāng)庫(kù)的揀貨效率。

訂單審核

訂單審核是確認(rèn)當(dāng)前ERP訂單可以下發(fā)給倉(cāng)庫(kù)（WMS）的確認(rèn)操作。

訂單自動(dòng)審核：

ERP訂單產(chǎn)生且預(yù)分倉(cāng)成功后，會(huì)經(jīng)過系統(tǒng)的層層篩選判斷，這些判斷匯集一下就兩大點(diǎn)：有無滿足的攔截條件和消費(fèi)者/客服備注能否系統(tǒng)自動(dòng)處理，如果訂單流轉(zhuǎn)順利未被攔截且其中的備注能被系統(tǒng)完全識(shí)別處理，則可以自動(dòng)審核，下發(fā)至倉(cāng)庫(kù)。

人工審核：

系統(tǒng)無法審核的，均交由人工處理。

ERP訂單關(guān)鍵信息說明

以上是結(jié)合目前所在公司真實(shí)業(yè)務(wù)思考所得，跟真實(shí)業(yè)務(wù)有偏差（真實(shí)業(yè)務(wù)因?yàn)楦鞣N原因某些方面雖不合理，但不致使影響使用，就沒硬照著可能正確的方向修正），如果各位同學(xué)看了覺得有可以優(yōu)化的地方，可以及時(shí)交流。

作者：青檸，微信公眾號(hào)：一只進(jìn)化中的產(chǎn)品汪（pm_move_forward），歡迎交流。

本文由 @青檸 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議