本文章描述我個(gè)人對B端OMS模塊的功能設(shè)計(jì)、流程設(shè)計(jì)與上下級模塊交互等。

因筆者一直從事的是電商相關(guān)行業(yè)，顧名思義，我定位的上級就是各個(gè)電商平臺，第三方等、下級類似于各個(gè)商家。

訂單大體產(chǎn)品結(jié)構(gòu)

看過很多筆者的文檔，對于訂單的組成概念大體都相同，大體可分為：

1. 訂單主表信息

訂單標(biāo)識號，訂單狀態(tài)，寄件人信息，收件人信息等。

2. 訂單明細(xì)表信息

商品信息，訂單價(jià)格屬性等。

3. 支付信息

支付方式,支付時(shí)間,支付單號,支付金額等。

4. 與下級模塊交互時(shí)可能會需要的字段

這塊根據(jù)各個(gè)產(chǎn)品制定，有些是屬于行業(yè)專屬類似于3c類目的sn碼，食品生鮮類目的保質(zhì)期等；

1. 發(fā)票信息：消費(fèi)者需開通發(fā)票，聯(lián)通開票系統(tǒng)時(shí)需存儲的信息

2. 標(biāo)識類內(nèi)容：例如來自于消費(fèi)者的留言信息，來自于商家前端客服人員的備注信息，訂單旗幟，標(biāo)簽等

3. 承運(yùn)方信息：例如某東下單時(shí)消費(fèi)者可選擇京配或京尊達(dá)等承運(yùn)方式，也可商家指定承運(yùn)方給到訂單信息，用于后續(xù)與wms,tms系統(tǒng)交互使用

4. 操作日志：check環(huán)節(jié)，涉及商家自主操作的環(huán)節(jié)，日志都是必不可少的，后續(xù)追訴問題時(shí)會用到

5. 重量：如預(yù)估重量，方便后續(xù)對接自動化設(shè)備或物流智選環(huán)節(jié)

流程

描述完了訂單結(jié)構(gòu)，描述一下大體流程：

流程圖簡要概括，紅色區(qū)域偏業(yè)務(wù)，可拓展性也強(qiáng)，競品優(yōu)勢體現(xiàn)也更明顯，下面描述下各個(gè)業(yè)務(wù)模塊的功能點(diǎn)及場景。

最頂端來源于上游接口，如電商平臺，第三方倉儲，線下訂單等，訂單數(shù)據(jù)拿到后做字段轉(zhuǎn)換，通俗理解就是講上游api中給的字段信息替換成我們自己的字段保存至我們業(yè)務(wù)表，在保存的過程中我提到了兩點(diǎn)：

1. 贈品規(guī)則

智能配贈品，絕大多數(shù)平臺會有平臺級的贈品規(guī)則，比如某寶聚劃算或上款界面都可設(shè)置比如前100購買次數(shù)會獲贈一個(gè)商品，金額滿500會獲贈一個(gè)商品等等，由于平臺規(guī)則等原因商家很多個(gè)性化營銷活動都在線下完成，會通過配置一定的策略在訂單下載時(shí)自動判斷，滿足規(guī)則后自動添加贈品至訂單。

贈品規(guī)則的觸發(fā)條件需提供入口給到商家配置，如下單觸發(fā)，付款觸發(fā)等，贈品規(guī)則通常情況下需要的維度。

1. sku級別

2. spu級別

3. 買家賬號，收貨人，收貨人聯(lián)系方式，收貨地址級別等

4. 訂單商品數(shù)量，訂單金額（包含應(yīng)付，已付）

5. 供分銷(供分銷管理，訂單可支持多級供銷推送及發(fā)貨回傳)

6. 發(fā)貨倉(多級倉庫管理，多地協(xié)同作業(yè))

2. 篩選規(guī)則

篩選規(guī)則的實(shí)用性會更加豐富，商家特殊單篩選（刷單）惡意買家篩選，平臺抽檢訂單篩選，或者更實(shí)用一點(diǎn)的——”新疆的訂單需要發(fā)ems””這幾天上海進(jìn)博會，不能發(fā)貨”…

滿足特定條件的訂單需用特定的方式操作，配合規(guī)則的實(shí)現(xiàn)就是篩選出地址為新疆的訂單并自動配快遞為ems，篩選出地址為上海的訂單自動轉(zhuǎn)為異常管理，同樣篩選規(guī)則的考慮維度和贈品規(guī)則類似再附加上來自消費(fèi)者的一些標(biāo)識信息如買家留言等。

簡述了訂單模塊的兩個(gè)規(guī)則類設(shè)置，針對不同的業(yè)務(wù)場景不同的行業(yè)，也會衍生出不同的規(guī)則，同時(shí)也需要考慮的就是多種規(guī)則的執(zhí)行順序，即優(yōu)先級問題。

訂單被”規(guī)則”后，流入OMS系統(tǒng)中，這部分也就是B端用戶對訂單的操作，我們大體可以對訂單類型做這樣的概括：

• 待付款

• 待發(fā)貨

• 異常

• 已發(fā)貨

代付款狀態(tài)比較好理解，消費(fèi)者下單后，或已經(jīng)產(chǎn)生單據(jù)或在購物車中，但并未付款。

待發(fā)貨狀態(tài)即消費(fèi)者已付款訂單，即可以發(fā)貨狀態(tài)。

異常狀態(tài)管理在我看來相對重要，這個(gè)環(huán)節(jié)也是根據(jù)不同系統(tǒng)的業(yè)務(wù)來決定的，多種異常分類管理及多種異常處理方式，與接口交互類的異常，如消費(fèi)者付款后又修改了訂單收貨地址，系統(tǒng)內(nèi)信息修改前拉入異常管理，修改后轉(zhuǎn)入發(fā)貨流程，異常精細(xì)管理，方便操作端。

訂單單據(jù)創(chuàng)建后，正式流入發(fā)貨階段前，其實(shí)商家可以對訂單進(jìn)行很多操作，如訂單信息修改，訂單成本估算，訂單預(yù)估發(fā)貨時(shí)間及預(yù)計(jì)到達(dá)時(shí)間等，這部分根據(jù)各自公司的客戶群體做差異化，融入行業(yè)特點(diǎn)，便利商家操作，提高競聘優(yōu)勢。

單據(jù)信息確認(rèn)后，可以推至WMS端進(jìn)入發(fā)貨流程，這個(gè)時(shí)候需要審單流程介入，審單通俗來說就是確認(rèn)訂單是否可以發(fā)貨，確認(rèn)來自消費(fèi)者的訴求 訂單上是否已經(jīng)實(shí)現(xiàn)，確認(rèn)發(fā)貨地址信息是否正確等，確認(rèn)無誤審核，預(yù)售業(yè)務(wù)介入。

當(dāng)前的各大銷售平臺都會推出預(yù)售活動，提前鎖定消費(fèi)者，使消費(fèi)者有一種“提前有意向后尾款會優(yōu)惠”的想法，類似預(yù)售活動會影響到訂單判斷庫存的邏輯，決定是否預(yù)留庫存給到預(yù)售訂單和如何預(yù)留，也是預(yù)留庫存業(yè)務(wù)的核心，這里就不再贅述，有興趣交流的同學(xué)我們也可以再繼續(xù)深入交流這個(gè)業(yè)務(wù)。審核的最后也就是判斷庫存，判斷發(fā)貨倉，判斷供銷商等環(huán)節(jié)。確認(rèn)后，成功推至WMS端，走進(jìn)發(fā)貨流程。

單據(jù)進(jìn)入WMS環(huán)節(jié)后OMS就完結(jié)了嗎？

不是的，不管訂單在哪個(gè)環(huán)節(jié)，來自于消費(fèi)者的需求都是有可能的，OMS需關(guān)聯(lián)至WMS端的訂單，實(shí)現(xiàn)后端同步前段修改，前端訂單信息發(fā)生了改變，后端需同步拉回，同步修改。

單據(jù)發(fā)貨后，可能會產(chǎn)生售后，售后環(huán)節(jié)我也放在了OMS側(cè)，售后操作流程大體如下：

消費(fèi)者申請售后，商家同意，銷售者寄出退回包裹并在平臺端填寫退回單號，商家倉庫人員收到退回包裹后check貨物，無誤后確認(rèn)收貨狀態(tài)，同步至OMS端并同步至平臺端，平臺退款給消費(fèi)者，這樣子的一個(gè)環(huán)節(jié)。

售后單據(jù)類型大體為僅退款業(yè)務(wù)，退貨退款，換貨，補(bǔ)發(fā)四種類型，如某寶支持發(fā)貨前消費(fèi)者申請僅退款，發(fā)貨后消費(fèi)者申請退款退款不支持僅退款，某貓支持消費(fèi)者申請換貨等、漏發(fā)等由于商家端的問題則會用補(bǔ)發(fā)補(bǔ)償消費(fèi)者。

對于收貨方式，不同的產(chǎn)品也會有不同的操作，可優(yōu)化的點(diǎn)也會體現(xiàn)出來，這里也就不再贅述了。