本文為筆者經(jīng)歷的一次電商系統(tǒng)訂單改造分享，并向我們介紹了銷售訂單架構(gòu)、前臺訂單模塊、后臺訂單模塊中的改造要點。

因為庫存架構(gòu)不完善，依賴的外部wms系統(tǒng)無法滿足銷售庫存-實物庫存的體系搭建，筆者被迫動手改造訂單體系，用于支撐在異國開展電商業(yè)務。

修正后的銷售訂單架構(gòu)

前臺訂單模塊

會涉及各種端口進來的訂單，APP/PC/H5/小程序、線下訂單、開放平臺、手工訂單、特殊場景訂單等，其包含核心的幾個功能：

1. 訂單生成：訂單生命周期的起點，最最最重要的一個環(huán)節(jié)
2. 訂單支付與退款：支付成功與否，直接決定了訂單的有效性
3. 訂單與庫存：銷售庫存直接決定了自營的各種不靠譜?。?/li>
4. 取消&修改
5. 訂單預拆單

后臺訂單模塊

后臺訂單，訂單體系中的核心環(huán)節(jié)，負責與各個相關(guān)模塊的對接，發(fā)票、售后、推單、財務系統(tǒng)、一環(huán)扣一環(huán)，負責指揮訂單的整體調(diào)度。其包含核心的幾個功能：

1. 訂單攔截：包括了庫存可用性校驗等，筆者遇到的架構(gòu)調(diào)整，就是因為沒有沒有倉庫實物庫存數(shù)據(jù)對訂單可用性檢查，導致推送倉儲后，需要大量涉及修改倉庫的需求；此外，針對特殊場景，可以在此設(shè)計靈活的推單邏輯，比如推送倉儲的截單時間、推單頻次。
2. 二次拆單及其合并：二次拆單場景：針對缺貨攔截的，可進行缺貨的二次拆單；也可根據(jù)承運商產(chǎn)品規(guī)則，在精細化進行二次拆單；與拆單相反的是訂單合并，這個場景主要面向有通用性規(guī)則的場景，如同一個倉庫的相同b2b訂單，為了節(jié)省物流費用，可以合并成一個發(fā)貨單或者一個批次推送到倉儲等。
3. 出入庫及庫存：跟倉庫系統(tǒng)對接產(chǎn)生的單據(jù)層面的流水記錄，這是oms體系與wms體系建立數(shù)據(jù)核對的關(guān)鍵一環(huán)，直接與實物庫存數(shù)據(jù)息息相關(guān)，很核心！
4. 發(fā)貨單模塊：這塊是筆者新增的模塊，僅用于使用后臺訂單與外部wms進行推單對接，不處理內(nèi)部流轉(zhuǎn)流，僅涉外對接，因此出現(xiàn)了單一訂單映射多發(fā)貨單場景，用于解決因沒有實物庫存導致大量調(diào)倉庫的場景。
5. 訂單分攤：這塊不展開細說，主要處理優(yōu)惠券邏輯在財務上的應用。
6. 訂單發(fā)票：這塊筆者所遇到的場景比較特殊，推單必須與發(fā)票相關(guān)（在還沒有普及電子發(fā)票的國度開展電商業(yè)務，很痛苦）
7. 訂單與財務：這塊不展開細說
8. 售后：這塊也不展開細說
9. 訂單取消、訂單修改：這塊也不展開細說
10. 監(jiān)控及可視化：一直想做還沒做，時效監(jiān)控、出庫庫異常監(jiān)控、數(shù)據(jù)可視化、推單策略等等

改造還在進行中，相比成熟的訂單架構(gòu)，還是差很多，共勉之！

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

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