本文主要描述B端OMS模塊的功能設計、流程設計與上下級模塊交互等。

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

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

訂單大體產(chǎn)品結構

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

1. 訂單主表信息

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

2. 訂單明細表信息

商品信息，訂單價格屬性等。

3. 支付信息

支付方式,支付時間,支付單號,支付金額等。

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

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

1. 發(fā)票信息：消費者需開通發(fā)票，聯(lián)通開票系統(tǒng)時需存儲的信息
2. 標識類內(nèi)容：例如來自于消費者的留言信息，來自于商家前端客服人員的備注信息，訂單旗幟，標簽等
3. 承運方信息：例如某東下單時消費者可選擇京配或京尊達等承運方式，也可商家指定承運方給到訂單信息，用于后續(xù)與wms,tms系統(tǒng)交互使用
4. 操作日志：check環(huán)節(jié)，涉及商家自主操作的環(huán)節(jié)，日志都是必不可少的，后續(xù)追訴問題時會用到
5. 重量：如預估重量，方便后續(xù)對接自動化設備或物流智選環(huán)節(jié)

流程

描述完了訂單結構，描述一下大體流程：

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

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

1. 贈品規(guī)則

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

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

1. sku級別
2. spu級別
3. 買家賬號，收貨人，收貨人聯(lián)系方式，收貨地址級別等
4. 訂單商品數(shù)量，訂單金額（包含應付，已付）
5. 供分銷(供分銷管理，訂單可支持多級供銷推送及發(fā)貨回傳)
6. 發(fā)貨倉(多級倉庫管理，多地協(xié)同作業(yè))

2. 篩選規(guī)則

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

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

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

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

• 待付款
• 待發(fā)貨
• 異常
• 已發(fā)貨

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

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

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

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

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

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

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

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

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

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

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

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

因為當前工作就是這個行業(yè),很多細節(jié)文章里中不便拿出來分享了，關于OMS后續(xù)的操作端，例如WMS，TMS，MRP，CRM等環(huán)節(jié)有興趣的同學也可評論或一起來交流學習，平時有整理出一整套企業(yè)erp組成的prd文檔及腦圖等材料，有需要同學也可評論。

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

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