下面這篇是筆者整理分享的關于多平臺電商訂單履約系統設計的文章，包括訂單履約系統架構設計、訂單履約業務流程、訂單履約系統訂單狀態流轉等相關內容，感興趣的同學可以來看看哦！

最近終于完成了自己所負責的SaaS產品的電商訂單履約系統模塊重構，原本以為對該模塊已沉淀了一年，吃透了競品、聊過了用戶、梳理過了舊邏輯，那么做起來應該十分順利。結果，還是逃不過幾個通宵的寫方案和該方案。

這篇文章我們一起聊聊電商訂單履約系統設計，以此也總結復盤一下我的第一個大項目。

首先，為大家簡述下這款SaaS產品的背景。它是一款面向中小微商家的多平臺電商及自建商城訂單履約系統。由于定位于中小微商家，系統并沒有涉及預分倉、倉庫/門店下發等功能。

但是，我仍然選擇這次重構在系統架構設計上將履約全流程納入設計范圍，只是在業務功能實現的時候，我們做功能的精簡、流程的跳過以及根據實際產品情況做改動。原因很簡單：升維設計，降維打擊。這樣子設計出來的系統雖小可大，具備拓展性。（誰也說不準，明天老板就讓做一個供應商代發的系統)。

一、訂單履約系統架構設計

何為訂單履約？訂單履約就是從訂單交易產生后，交付給用戶包括售后的全過程。系統的主要實現目標是能高效、準確、透明的完成訂單履約全過程。

我們的系統主要承接了兩部分的訂單來源：第三方電商平臺和自建商城。第三方平臺是用戶在淘寶、天貓、拼多多等平臺上開的電商店鋪。自建商城是用戶自行搭建的商城系統，通過API的方式將訂單導入到的系統。

訂單進入到系統后，用戶的業務目標是：

1. 將訂單打印成快遞單后，揀貨、打包、快遞發貨，且物流單號要回傳到平臺/商城；
2. 物流的跟蹤管理，跟進物流的攬件、運輸、派件、簽收狀態。

那么，根據用戶的業務目標，我們可以設計以下的系統架構：

However，通過閱讀了《實戰供應鏈》全局了解了訂單履約全流程后，發現“訂單打印”放在訂單履約中心并不妥當。我們可以先從下圖看訂單履約全流程：

可以看到，在履約全流程里面訂單打印是在下發庫房后發生的，結合業務場景來看，包括快遞單在內的各類單據打印確實是在庫房里面進行，以及該系統操作背后是有揀貨、打包等作業流程。

如果將訂單打印放在訂單履約中心的話，后續若增加分倉發貨、波次生成等功能時，會導致訂單履約中心職責不明確、訂單混亂（若按倉庫拆分訂單的話，庫房會單獨成單。放到履約系統的話，會影響到原本的父子結構）。因此，我們可以做以下調整：

在這個架構中，我們將【訂單打印】抽出來成為“WMS”。

不過，此WMS非WMS，按照當前的公司戰略來看，“WMS”只需要承載訂單打?。òǖ幌抻诳爝f單、發貨單、揀貨單、拿貨單）。當然，也可以迭代一個【掃碼核對并發貨】的功能在”WMS“中，輔助用戶打包核對與回傳單號到電商平臺/自建商城。

總而言之，這樣的架構設計無論后續用戶/業務方/老板想增加什么樣的功能，功能都會有其合適的”歸屬“了。

其次，就是【倉儲路由中心】，按照當前的公司戰略和重構目標是可以先不實現的。

但是，作為SaaS產品經理來說，還是要看的更長遠一些，雖然當前的產品定位做的是SMB，但是如果哪天轉型做電商erp或者孵化分銷代發erp且要聯動現有產品的話（大概率），該模塊必不可少。因此，在設計之初產品和開發大哥們需要關注它。

• 訂單轉換中心：對接各個第三方平臺和自建商城系統。因為各平臺的訂單結構不盡相同，為了能統一在履約系統中對訂單進行管理，保證訂單內部流轉的標準化。適配的信息包括商品、地址、訂單狀態、物流公司等。
• 訂單履約中心：負責處理訂單履約的全過程，對上通過訂單轉換中心與銷售平臺進行信息同步，對下通過倉儲路由中心將訂單信息上下傳，內部可以通過調度中央庫存、配送系統、規則引擎等多個外圍系統對訂單信息進行層層拆解和組裝，將訂單加工為滿足履約條件的可執行指令。
• 倉儲路由中心：用以與倉庫系統/代發系統進行交互，將訂單路由分發至目標庫房/目標供應商，同時將目標庫房/目標供應商的發貨信息收集并回傳至訂單履約中心。
• “WMS”：可為倉儲管理系統，也可為供應商代發系統，當前為承接訂單打印的模塊。
• 物流中心：也是配送系統，對接“WMS”和物流公司系統。接收“WMS”下發的物流單號，對其進行物流查詢和異常監控，并將物流信息收集并回傳至“WMS”和訂單履約系統。

二、訂單履約業務流程

由于我的產品并不涉及訂單履約全流程，所以該部分內容主要闡述我的系統所承接的履約節點，其他節點會有所提及但不會深入。如果想要深入了解的，強烈推薦閱讀羅靜老師的《實戰供應鏈》~當然，最有效的還是到現場多學多看多問~

對一個中小微電商商家來說，一個訂單會經歷以下節點，中間仍然會涉及到銷售平臺、訂單轉化中心、訂單履約中心等多個系統。系統設計目標如上文提到的：能高效、準確、透明的完成訂單履約全過程。進而，讓供應鏈各個節點通暢協同。

1. 新訂單

訂單系統接到新單的狀態，此處根據業務分為兩塊邏輯處理：第三方平臺訂單，自建商城訂單。

第三方平臺訂單：客戶在第三方平臺上完成支付后，訂單系統接收第三方平臺同步的訂單。如果是預售或定制訂單的話，應當待用戶付完尾款后再進入訂單系統。

自營平臺訂單：客戶提交訂單后，訂單系統便生成一張新訂單。

2. 訂單拆分

用戶在電商平臺上一次購物，通常會將多個商家的多個商品作為一個訂單支付，但是一張訂單里面會包含多個商家、多個供應商的商品，因此需要對訂單進行拆分。

履約流程設計圖中訂單拆分發生在新訂單后，但是在實際業務中會出現在訂單履約的多個環節中的，場景較多也比較靈活，圖中僅代表其首次拆分的節點。那么，在系統設計上，可以部分場景系統做自動拆分，部分場景提供人工拆分，看具體的業務情況。以下是訂單拆分考慮的幾個維度：

1. 店鋪維度：銷售平臺、不同店鋪
2. 倉庫維度：不同的發貨倉庫
3. 供應商維度：不同的供應商
4. 商品品類維度：商品屬性、商品價值、配送條件
5. 訂單類型維度：預售商品、實物商品、虛擬商品
6. 物流因素：根據快遞公司的價格，將訂單根據重量或體積拆分成多個包裹、代收貨款金額快遞公司上限、跨境訂單出關金額限制、根據上述的維度，我們可以將訂單的拆分分成銷售層、調度層、倉庫層3層去進行。

• 店鋪、訂單類型可以在銷售層進行拆分
• 商品品類、倉庫、供應商可以在調度層進行拆分
• 物流可以在倉庫層進行拆分

3. 訂單合并

為降低運費成本和庫房作業成本，會根據自動合并條件，將多筆訂單合并為一筆訂單進行物流發貨。

通常，訂單合并我們會設計自動合并+手動合并。新訂單進來時，系統先自動合并。為避免用戶操作失誤取消合并或系統異常沒有執行合并，仍會保留自動合并操作按鈕。

常見的訂單合并條件：同銷售平臺、同收貨地址、同收貨人、同手機號、同出庫倉庫、同訂單類型（如普通訂單、預售訂單）、同配送方式（自提/配送）

不給過，除了根據業務劃分出來的訂單信息相同合并以外，還要考慮訂單各類狀態是否可以合并，如打印狀態的未打印和已打印是否可以合并，發貨狀態的未發貨和已發貨是否可以合并等。

4. 訂單打印

打單員按照消費者需求/公司要求/倉庫作業流程，將每張訂單的快遞面單、紙質發票、發貨清單等各類單據打印出來。

對于訂單數量大，倉庫分區多的商家，通常會采用波次揀選。根據波次生成分揀任務，打印批揀單后揀貨員進行揀貨。揀貨過程可以”先揀后分“或者”變揀邊分“，分完后再將【訂單打印】環節的單據對應打包和貼單。

對于訂單量適中，但是倉庫分區簡單、動線不復雜的商家，通常直接生成揀貨單給揀貨員進行揀貨。后續過程與上面一樣。

對于訂單小，倉庫也小【倉庫規?；旧鲜且粋€人和一個小鋪面】的商家（我的產品所服務的主要客群），則是直接打印快遞單進行揀貨（最省事）。

倉庫人員按照揀貨打包要求在系統里面對訂單做篩選，篩選出A條件訂單后進行批量打印快遞單，根據快遞面單自定義區的商品信息去揀貨、打包貼單。然后再用B條件篩選訂單，往復循環至當天要發出的訂單打包完成。

5. 訂單發貨

發貨員將包裹交由快遞員攬收，并在系統中操作發貨。發貨以后，若實際發貨物流有變化，回傳實際的物流公司及物流單號至履約系統，履約系統再通過訂單轉換中心將物流信息回傳銷售平臺。

不過現在的第三方電商平臺對于商家的發貨履約規則制度越來越完善，加上商家為了降低運費成本選擇一些快遞黃牛發貨，如果等有攬件記錄再回傳到履約系統和銷售平臺，可能會發貨履約超時導致罰款。

但是，平臺也對物流商履約做了約束，如果過早回傳單號到平臺，在一定時間內物流沒有產生軌跡，那么會被判為攬收超時，同樣會被罰款。因此，在設計訂單發貨功能時，可以增加一些自動化規則配置/定時任務給到商家使用，商家可以結合自己的發貨安排和物流商履約承諾來選擇適當的時間點在系統進行發貨。

6. 物流攬件

物流公司快遞員收到包裹后，將包裹帶回攬件網點在快遞系統中操作攬件。攬件網點將攬收的包裹打包集中，然后通過小型運輸車輛將攬收的包裹送到就近的攬件中心。

攬件操作信息可由配送系統調用物流公司提供的接口獲取，解析完后回傳到訂單系統中。

7. 物流運輸

到達攬件中心（也稱分揀中心，是大規模的包裹集散中心）后，對于到達本地的包裹，攬件中心根據包裹的詳細地址，將包裹分發給對應的派件網點。對于發往外地的包裹，攬件中心根據包裹的行政區，如省、市、區/縣，將包裹分發給對應的派件中心，從攬件中心分發到派送中心的包裹，通常通過大型運輸車輛專程運送。

從攬件中心發出，也代表包裹正式進入物流運輸。

8. 物流派件

包裹到達派送中心后，派送中心根據包裹的詳細地址，將包裹分發給對應的派件網點。派件網點根據包裹的詳細地址，指派指定的派件員進行派送，將包裹送到收貨人手中。

9. 物流簽收

包裹送達客戶手中，完成簽收。

三、 訂單履約系統訂單狀態流轉

根據羅靜老師的《實戰供應鏈》一書得知，訂單履約系統狀態有如下：

不過，根據我的產品定位、目標群體和其他客觀情況，我的電商訂單履約系統的訂單狀態做了一些調整。訂單狀態由三種獨立狀態共同組成：正向的發貨狀態，逆向的售后狀態，快遞單打印狀態。發貨后的物流攬件、運輸、派件、簽收由訂單的獨立物流狀態承接。

發貨狀態：分為待發貨、部分發貨、已發貨三種狀態。

若父訂單中的子訂單（子訂單對應的就是一個sku）都沒有發貨，則為待發貨；若父訂單中的僅部分子訂單發貨，則為部分發貨；若父訂單中的所有子訂單發貨，則為已發貨。

發貨狀態的區分可以讓用戶知曉哪些訂單未回傳到銷售平臺，這關乎到用戶的發貨履約。

售后狀態：由于系統主要還是以正向的發貨狀態為主，售后狀態只區分用戶申請售后（即售后開始）、售后成功、售后失敗。

當用戶發起無論何種類型的售后時，訂單會標記為”用戶申請售后“，前端也會透出；當售后成功時，訂單會標記為”售后成功“，前端也會透出；當售后失敗時，訂單會標記為”售后失敗“，但是前端不透出。

售后狀態的區分可以讓用戶知曉哪些訂單可以正常發貨，輔助用戶在訂單打印流程中篩選有效發貨訂單，避免多發導致資損。

快遞單打印狀態：分為未打印和已打印。

其主要記錄訂單是否打印了快遞單，如上述中小微商家是通過多次篩選進行批量打印的，而非全部訂單一次性批量打印，因此記錄訂單打印狀態流轉十分有必要。如果打印狀態流轉不正確，那么就會導致多打一張面單，多發一個包裹導致資損。

那么，為什么要通過三種獨立狀態進行組合成訂單狀態呢？

首先，通過上述三個狀態的介紹可以看出，這三個狀態無非就是告訴商家哪些訂單可以打印、哪些訂單還沒發貨回傳這兩件事情。而打印和發貨也是整個訂單履約倉庫發貨環節要實現的業務目標，因此是很核心的。

再結合中小微商家訂單打印、揀貨、核對打包的業務場景與流程，【訂單篩選】是個高頻核心的系統操作。

那么，如何將這三種獨立狀態實現高效的訂單篩選呢？

答案就是組合成虛擬的訂單狀態。何為虛擬的訂單狀態？即將后端的這三種獨立狀態組合成前端界面上的tab標簽，tab標簽名字即虛擬的訂單狀態，其本質是三種獨立狀態預置條件篩選的結果，這通過接口入參控制十分好實現。虛擬的訂單狀態既實現了核心狀態的高校篩選，也降低了用戶對系統的理解成本，十分適用于中小微商家了。

除此之外，還有一個原因：因為我們是做SaaS產品的，用戶或其上下游可能會使用其他產品對訂單進行處理，即不一定每筆訂單的每個節點流轉都是由我們的系統發起。因此，無法像羅老師梳理出來的訂單狀態來設計該產品后端的訂單狀態。

因此，所謂訂單狀態是虛擬的訂單狀態，具體流轉設計如下：

四、 結尾

此次項目讓我對訂單履約系統有了進一步的深入了解，不得不感嘆前輩們留下的豐富經驗背后到底踩了多少坑。供應鏈系統的龐大和復雜，只有沉下心、多鉆研、多思考、多總結才能成為優秀的供應鏈人呀！