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

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

訂單大體產品結構

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

1. 訂單主表信息

訂單標識號，訂單狀態，寄件人信息，收件人信息等。

2. 訂單明細表信息

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

3. 支付信息

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

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

這塊根據各個產品制定，有些是屬于行業專屬類似于3c類目的sn碼，食品生鮮類目的保質期等；

1. 發票信息：消費者需開通發票，聯通開票系統時需存儲的信息

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

3. 承運方信息：例如某東下單時消費者可選擇京配或京尊達等承運方式，也可商家指定承運方給到訂單信息，用于后續與wms,tms系統交互使用

4. 操作日志：check環節，涉及商家自主操作的環節，日志都是必不可少的，后續追訴問題時會用到

5. 重量：如預估重量，方便后續對接自動化設備或物流智選環節

流程

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

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

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

1. 贈品規則

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

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

1. sku級別

2. spu級別

3. 買家賬號，收貨人，收貨人聯系方式，收貨地址級別等

4. 訂單商品數量，訂單金額（包含應付，已付）

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

6. 發貨倉(多級倉庫管理，多地協同作業)

2. 篩選規則

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

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

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

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

• 待付款

• 待發貨

• 異常

• 已發貨

代付款狀態比較好理解，消費者下單后，或已經產生單據或在購物車中，但并未付款。

待發貨狀態即消費者已付款訂單，即可以發貨狀態。

異常狀態管理在我看來相對重要，這個環節也是根據不同系統的業務來決定的，多種異常分類管理及多種異常處理方式，與接口交互類的異常，如消費者付款后又修改了訂單收貨地址，系統內信息修改前拉入異常管理，修改后轉入發貨流程，異常精細管理，方便操作端。

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

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

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

單據進入WMS環節后OMS就完結了嗎？

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

單據發貨后，可能會產生售后，售后環節我也放在了OMS側，售后操作流程大體如下：

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

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

對于收貨方式，不同的產品也會有不同的操作，可優化的點也會體現出來，這里也就不再贅述了。