訂單系統(tǒng)作為一個業(yè)務子系統(tǒng)，在電商、零售、餐飲、教育、醫(yī)療saas系統(tǒng)中都非常常見。

只要平臺存在交易行為，那么必然逃不開訂單系統(tǒng)，因為最終都需要通過創(chuàng)建訂單，并支付，從而完成交易。

由于訂單系統(tǒng)的高出現(xiàn)頻率，且不同業(yè)務的訂單設計思路大同小異，所以我們可以把它作為一個底層系統(tǒng)進行抽象，建立一套訂單的設計模型，便于我們快速應用到各個業(yè)務系統(tǒng)之中。

訂單系統(tǒng)架構

No. 1

以電商為例：

訂單作為電商最復雜的核心系統(tǒng)（或者稱之模塊），它建立其他系統(tǒng)模塊之上。

包括但不限于商品、優(yōu)惠券、會員、營銷活動、地址信息、積分、運費、購物車、支付、發(fā)收貨等模塊，都和訂單息息相關，任何一個模塊的改動，都可能影響到訂單。不夸張的說，訂單是交易平臺最核心的子系統(tǒng)。

訂單包含的信息：

電商訂單系統(tǒng)架構：

因此做好訂單管理，最重要的是覆蓋的全面性、和極強的可擴展性。

訂單系統(tǒng)模塊拆分

No. 2

訂單主要分：訂單創(chuàng)建和訂單管理兩部分.

一、訂單創(chuàng)建：

訂單創(chuàng)建可以由C端用戶、以及B端使用者發(fā)起創(chuàng)建，并在訂單系統(tǒng)中生成。

訂單創(chuàng)建的節(jié)點，在頁面上的展示，就是提交訂單頁面點擊“提交訂單”按鈕那一刻，訂單就會被創(chuàng)建。

當然表面上看，點擊“提交訂單”就觸發(fā)了訂單創(chuàng)建，但背后，創(chuàng)建過程會調(diào)用前面所說的各個模塊，并且夾雜了大量的邏輯判斷。

提交訂單頁原型：

以下為訂單生成的校驗：

即在“提交訂單”那一刻，會進行多個信息的邏輯判斷

配送信息：配送方式和配送地址。

需判斷是否填寫了配送方式和地址；（如果是外賣）配送地址是否超過配送范圍；

商品

1. 需判斷商品是否是上架狀態(tài)；

2. 商品是否售罄；

3. 商品庫存是否小于訂單中的商品數(shù)量；（如有贈品贈送）需判斷贈品是否庫存不足；

運費

1. 選擇收獲地址后，會根據(jù)后臺的運費模版自動進行運費計算，并回顯在【提交訂單】頁；

2. 提交訂單時需要校驗運費信息是否變動；

促銷活動

需判斷當前該用戶、該訂單商品適用的所有促銷活動。促銷活動一般分平臺級、店鋪級2個層級

1. 平臺級：針對平臺內(nèi)商品的促銷活動；

2. 店鋪級：針對店鋪內(nèi)商品的促銷活動。

當然一般這類活動還有一些限制條件，比如

1. 訂單滿多少金額才可以參與

2. 只限一定等級的會員

3. 只限某些類目，或指定商品才可以參與

4. 如果同時滿足多個活動參與的條件，則只能參與優(yōu)先級最高的活動；

等等，視促銷活動數(shù)量和復雜度而定。

會員優(yōu)惠

提交訂單時需判斷會員等級及相應優(yōu)惠權益是否變動，需判斷可用積分數(shù)量是否變動。

優(yōu)惠券

1. 需要判斷優(yōu)惠券是否已核銷；

2. 是否已過期；

3. 是否在適用時段內(nèi)；

4. 是否已被使用等。

一旦提交訂單后，則訂單即完成創(chuàng)建，這個時候訂單模塊還會發(fā)起指令要求其他模塊進行相應的配合：

1. 訂單中的商品庫存需要在商品模塊中進行凍結處理

2. 訂單中使用的優(yōu)惠券需要在優(yōu)惠券模塊中進行狀態(tài)變更

3. 訂單中使用的促銷活動權利應該標記為已使用該權利

4. 訂單中扣減的積分應該在用戶積分中進行扣減等

當然對于外賣而言，還需要在提交訂單的時候?qū)Φ赇伿欠裨谛菹r間、店鋪是否開啟該配送方式、訂單價格是否滿足起送價等各種情況進行確定，如存在變動則給出用戶相應提示。

二、訂單管理

當訂單被創(chuàng)建后，即進入訂單管理階段。

C端頁面：

B端的訂單管理頁：

訂單輪轉(zhuǎn)流程：

關于訂單狀態(tài)

從用戶端（買家）角度看，電商平臺的訂單流轉(zhuǎn)中間狀態(tài)一般有如下6大狀態(tài)：

1）待付款：當用戶提交訂單后，支付之前，都屬于待付款狀態(tài)，商家端也是待付款狀態(tài)。

2）待發(fā)貨：當用戶完成支付后，訂單狀態(tài)變更為待發(fā)貨，商家端也同步更新為“待發(fā)貨”狀態(tài)。

3）待收貨：當商家在后臺確認發(fā)貨后，訂單狀態(tài)在買家端的顯示就會變成“待收貨”狀態(tài)，在賣家端會顯示“已發(fā)貨”，這里兩邊的展示會有一個區(qū)別。

假如買家收到貨一直不點確認，那么一般平臺會有一個周期（淘寶是14天），14天后系統(tǒng)自動確認收貨，變更為交易成功。

4）退款中：一共兩種情況會導致訂單變更為“退款中”的狀態(tài)。

1. 是在“待收貨”狀態(tài)下，即商家已經(jīng)發(fā)貨后，買家進行退款操作，那么訂單狀態(tài)會直接變成退款中；

2. 是在“待發(fā)貨“狀態(tài)下，買家取消訂單／賣家操作全額退款，則進入退款中狀態(tài)。

3. 是買家確認收貨后，申請退款，則進入”退款中“狀態(tài)，一般電商平臺都支持確認收貨后7天無理由退貨

5）交易完成：一共有兩種情況會導致訂單變更為”交易成功“

1. 是用戶確認收貨；

2. 是買家申請部分退款，退款流程結束，且剩余商品確認收貨后，訂單變更為“交易成功”。

6）交易關閉：一共有3種情況會出現(xiàn)“交易關閉”

1. 是“交易成功”后發(fā)起全額退款，完成退款流程變更為“交易關閉”；

2. 是在”待支付“的時候買家取消訂單／訂單超時過期）；

3. 是“待發(fā)貨”的時候買家申請退款，商家確認后訂單變更為“交易關閉”。

關于訂單中的優(yōu)惠分攤

為什么要考慮優(yōu)惠分攤，如果下單的時候使用了某種優(yōu)惠活動，當訂單進行部分退款的時候，我們肯定不能給買家直接退商品的原價，這樣對賣家的損失就很大了。

因此在訂單生成時，就會針對使用優(yōu)惠活動的商品計算優(yōu)惠分攤。

舉例

我們舉個最簡單的例子，買家購買了一個商品A100元，一個商品B200元，提交訂單時參與了滿100減50的促銷活動，那么最后支付了250元。

假如買家收到貨后覺得A不滿意，申請退款，賣家同意后且完成退款流程后，應該退給A多少呢？

A的退款金額=100*250/（100 200）=83.33元（保留2位小數(shù)點）

他并不能收到100元，因為假如他收到了100元，相當于最終用了150元買到了B，這是存在漏洞的。

再舉個更復雜的案例：這個案例涉及到平臺跨店促銷優(yōu)惠、店鋪促銷優(yōu)惠、優(yōu)惠券優(yōu)惠券

舉例

買家購買了1個商品A100元（甲店）、1個商品B200元（甲店）、1個商品C300元（乙店）。

提交訂單時，參與甲店的滿200減50的促銷活動1，同時還參與了平臺滿200減100的促銷活動2，此外還使用了一張150元的平臺代金券。

那么根據(jù)優(yōu)先級首先A B的商品享受甲店的活動1后變成了（100 200-50）=250元，然后A B C繼續(xù)參與平臺的活動2后變成了（250 300-100）=450元，最終使用一張平臺代金券后支付（450-150）=300元，即最終需支付300元。

即依次按照活動1>活動2>代金券的優(yōu)先級進行參與。

假設退款時，是無法退還代金券的，那么在訂單生成時，我們來計算下每一層優(yōu)惠分攤之后，A、B、C的可退金額是多少：

第一層：活動1分攤后

商品A=100-50/（100 200）*100=83.33元

商品B=200-50/（100 200）*200=166.67元

商品C=300元

第二層：活動2分攤后

商品A=83.33-100/550*83.33=68.18元

商品B=166.67-100/550*166.67=136.37元

商品C=300-100/550*300=245.46元

注釋：83.33 166.67 300=550元

第三層：代金券分攤后

商品A=68.18-150／450*68.18=45.45元

商品B=136.37-150/450*136.37=90.91元

商品C=245.46-150/450*245.46=163.64元

注釋：68.18 136.37 245.46=450元

所以經(jīng)過優(yōu)先級從高到底的三層優(yōu)惠分攤后，A最終的實際可退金額為45.45元，B為90.91元，C為163.64元

2、關于拆單

在電商平臺中，只要有購物車功能，就會出現(xiàn)買家跨店購買商品的情況。

比如一筆訂單買了甲店的商品A一件，買了乙店的商品B一件，對于買家來說，他只是下了一筆訂單；但是對平臺來說，需要把A的訂單信息推送給甲店，把B的訂單信息推送給乙店，這就需要對買家的訂單進行拆單。

另外對于提交給甲店的訂單來說，如果訂單包含多個商品A、B、C，可能還會涉及到發(fā)貨單的拆單，比如A、B一起發(fā)貨，C單獨發(fā)貨。

作者：鄭海華，深耕 B 端業(yè)務多年，熟悉電商、醫(yī)療等業(yè)務，具有多個從 0 到 1 的大型產(chǎn)品孵化經(jīng)驗。