下面這篇是筆者整理分享的關(guān)于多平臺電商訂單履約系統(tǒng)設(shè)計的文章，包括訂單履約系統(tǒng)架構(gòu)設(shè)計、訂單履約業(yè)務(wù)流程、訂單履約系統(tǒng)訂單狀態(tài)流轉(zhuǎn)等相關(guān)內(nèi)容，感興趣的同學(xué)可以來看看哦！

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

這篇文章我們一起聊聊電商訂單履約系統(tǒng)設(shè)計，以此也總結(jié)復(fù)盤一下我的第一個大項目。

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

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

一、訂單履約系統(tǒng)架構(gòu)設(shè)計

何為訂單履約？訂單履約就是從訂單交易產(chǎn)生后，交付給用戶包括售后的全過程。系統(tǒng)的主要實現(xiàn)目標(biāo)是能高效、準(zhǔn)確、透明的完成訂單履約全過程。

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

訂單進(jìn)入到系統(tǒng)后，用戶的業(yè)務(wù)目標(biāo)是：

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

那么，根據(jù)用戶的業(yè)務(wù)目標(biāo)，我們可以設(shè)計以下的系統(tǒng)架構(gòu)：

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

可以看到，在履約全流程里面訂單打印是在下發(fā)庫房后發(fā)生的，結(jié)合業(yè)務(wù)場景來看，包括快遞單在內(nèi)的各類單據(jù)打印確實是在庫房里面進(jìn)行，以及該系統(tǒng)操作背后是有揀貨、打包等作業(yè)流程。

如果將訂單打印放在訂單履約中心的話，后續(xù)若增加分倉發(fā)貨、波次生成等功能時，會導(dǎo)致訂單履約中心職責(zé)不明確、訂單混亂（若按倉庫拆分訂單的話，庫房會單獨成單。放到履約系統(tǒng)的話，會影響到原本的父子結(jié)構(gòu)）。因此，我們可以做以下調(diào)整：

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

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

總而言之，這樣的架構(gòu)設(shè)計無論后續(xù)用戶/業(yè)務(wù)方/老板想增加什么樣的功能，功能都會有其合適的”歸屬“了。

其次，就是【倉儲路由中心】，按照當(dāng)前的公司戰(zhàn)略和重構(gòu)目標(biāo)是可以先不實現(xiàn)的。

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

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

二、訂單履約業(yè)務(wù)流程

由于我的產(chǎn)品并不涉及訂單履約全流程，所以該部分內(nèi)容主要闡述我的系統(tǒng)所承接的履約節(jié)點，其他節(jié)點會有所提及但不會深入。如果想要深入了解的，強(qiáng)烈推薦閱讀羅靜老師的《實戰(zhàn)供應(yīng)鏈》~當(dāng)然，最有效的還是到現(xiàn)場多學(xué)多看多問~

對一個中小微電商商家來說，一個訂單會經(jīng)歷以下節(jié)點，中間仍然會涉及到銷售平臺、訂單轉(zhuǎn)化中心、訂單履約中心等多個系統(tǒng)。系統(tǒng)設(shè)計目標(biāo)如上文提到的：能高效、準(zhǔn)確、透明的完成訂單履約全過程。進(jìn)而，讓供應(yīng)鏈各個節(jié)點通暢協(xié)同。

1. 新訂單

訂單系統(tǒng)接到新單的狀態(tài)，此處根據(jù)業(yè)務(wù)分為兩塊邏輯處理：第三方平臺訂單，自建商城訂單。

第三方平臺訂單：客戶在第三方平臺上完成支付后，訂單系統(tǒng)接收第三方平臺同步的訂單。如果是預(yù)售或定制訂單的話，應(yīng)當(dāng)待用戶付完尾款后再進(jìn)入訂單系統(tǒng)。

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

2. 訂單拆分

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

履約流程設(shè)計圖中訂單拆分發(fā)生在新訂單后，但是在實際業(yè)務(wù)中會出現(xiàn)在訂單履約的多個環(huán)節(jié)中的，場景較多也比較靈活，圖中僅代表其首次拆分的節(jié)點。那么，在系統(tǒng)設(shè)計上，可以部分場景系統(tǒng)做自動拆分，部分場景提供人工拆分，看具體的業(yè)務(wù)情況。以下是訂單拆分考慮的幾個維度：

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

• 店鋪、訂單類型可以在銷售層進(jìn)行拆分
• 商品品類、倉庫、供應(yīng)商可以在調(diào)度層進(jìn)行拆分
• 物流可以在倉庫層進(jìn)行拆分

3. 訂單合并

為降低運費成本和庫房作業(yè)成本，會根據(jù)自動合并條件，將多筆訂單合并為一筆訂單進(jìn)行物流發(fā)貨。

通常，訂單合并我們會設(shè)計自動合并+手動合并。新訂單進(jìn)來時，系統(tǒng)先自動合并。為避免用戶操作失誤取消合并或系統(tǒng)異常沒有執(zhí)行合并，仍會保留自動合并操作按鈕。

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

不給過，除了根據(jù)業(yè)務(wù)劃分出來的訂單信息相同合并以外，還要考慮訂單各類狀態(tài)是否可以合并，如打印狀態(tài)的未打印和已打印是否可以合并，發(fā)貨狀態(tài)的未發(fā)貨和已發(fā)貨是否可以合并等。

4. 訂單打印

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

對于訂單數(shù)量大，倉庫分區(qū)多的商家，通常會采用波次揀選。根據(jù)波次生成分揀任務(wù)，打印批揀單后揀貨員進(jìn)行揀貨。揀貨過程可以”先揀后分“或者”變揀邊分“，分完后再將【訂單打印】環(huán)節(jié)的單據(jù)對應(yīng)打包和貼單。

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

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

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

5. 訂單發(fā)貨

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

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

但是，平臺也對物流商履約做了約束，如果過早回傳單號到平臺，在一定時間內(nèi)物流沒有產(chǎn)生軌跡，那么會被判為攬收超時，同樣會被罰款。因此，在設(shè)計訂單發(fā)貨功能時，可以增加一些自動化規(guī)則配置/定時任務(wù)給到商家使用，商家可以結(jié)合自己的發(fā)貨安排和物流商履約承諾來選擇適當(dāng)?shù)臅r間點在系統(tǒng)進(jìn)行發(fā)貨。

6. 物流攬件

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

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

7. 物流運輸

到達(dá)攬件中心（也稱分揀中心，是大規(guī)模的包裹集散中心）后，對于到達(dá)本地的包裹，攬件中心根據(jù)包裹的詳細(xì)地址，將包裹分發(fā)給對應(yīng)的派件網(wǎng)點。對于發(fā)往外地的包裹，攬件中心根據(jù)包裹的行政區(qū)，如省、市、區(qū)/縣，將包裹分發(fā)給對應(yīng)的派件中心，從攬件中心分發(fā)到派送中心的包裹，通常通過大型運輸車輛專程運送。

從攬件中心發(fā)出，也代表包裹正式進(jìn)入物流運輸。

8. 物流派件

包裹到達(dá)派送中心后，派送中心根據(jù)包裹的詳細(xì)地址，將包裹分發(fā)給對應(yīng)的派件網(wǎng)點。派件網(wǎng)點根據(jù)包裹的詳細(xì)地址，指派指定的派件員進(jìn)行派送，將包裹送到收貨人手中。

9. 物流簽收

包裹送達(dá)客戶手中，完成簽收。

三、 訂單履約系統(tǒng)訂單狀態(tài)流轉(zhuǎn)

根據(jù)羅靜老師的《實戰(zhàn)供應(yīng)鏈》一書得知，訂單履約系統(tǒng)狀態(tài)有如下：

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

發(fā)貨狀態(tài)：分為待發(fā)貨、部分發(fā)貨、已發(fā)貨三種狀態(tài)。

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

發(fā)貨狀態(tài)的區(qū)分可以讓用戶知曉哪些訂單未回傳到銷售平臺，這關(guān)乎到用戶的發(fā)貨履約。

售后狀態(tài)：由于系統(tǒng)主要還是以正向的發(fā)貨狀態(tài)為主，售后狀態(tài)只區(qū)分用戶申請售后（即售后開始）、售后成功、售后失敗。

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

售后狀態(tài)的區(qū)分可以讓用戶知曉哪些訂單可以正常發(fā)貨，輔助用戶在訂單打印流程中篩選有效發(fā)貨訂單，避免多發(fā)導(dǎo)致資損。

快遞單打印狀態(tài)：分為未打印和已打印。

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

那么，為什么要通過三種獨立狀態(tài)進(jìn)行組合成訂單狀態(tài)呢？

首先，通過上述三個狀態(tài)的介紹可以看出，這三個狀態(tài)無非就是告訴商家哪些訂單可以打印、哪些訂單還沒發(fā)貨回傳這兩件事情。而打印和發(fā)貨也是整個訂單履約倉庫發(fā)貨環(huán)節(jié)要實現(xiàn)的業(yè)務(wù)目標(biāo)，因此是很核心的。

再結(jié)合中小微商家訂單打印、揀貨、核對打包的業(yè)務(wù)場景與流程，【訂單篩選】是個高頻核心的系統(tǒng)操作。

那么，如何將這三種獨立狀態(tài)實現(xiàn)高效的訂單篩選呢？

答案就是組合成虛擬的訂單狀態(tài)。何為虛擬的訂單狀態(tài)？即將后端的這三種獨立狀態(tài)組合成前端界面上的tab標(biāo)簽，tab標(biāo)簽名字即虛擬的訂單狀態(tài)，其本質(zhì)是三種獨立狀態(tài)預(yù)置條件篩選的結(jié)果，這通過接口入?yún)⒖刂剖趾脤崿F(xiàn)。虛擬的訂單狀態(tài)既實現(xiàn)了核心狀態(tài)的高校篩選，也降低了用戶對系統(tǒng)的理解成本，十分適用于中小微商家了。

除此之外，還有一個原因：因為我們是做SaaS產(chǎn)品的，用戶或其上下游可能會使用其他產(chǎn)品對訂單進(jìn)行處理，即不一定每筆訂單的每個節(jié)點流轉(zhuǎn)都是由我們的系統(tǒng)發(fā)起。因此，無法像羅老師梳理出來的訂單狀態(tài)來設(shè)計該產(chǎn)品后端的訂單狀態(tài)。

因此，所謂訂單狀態(tài)是虛擬的訂單狀態(tài)，具體流轉(zhuǎn)設(shè)計如下：

四、 結(jié)尾

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