訂單系統作為一個業務子系統，在電商、零售、餐飲、教育、醫療saas系統中都非常常見。
只要平臺存在交易行為，那么必然逃不開訂單系統，因為最終都需要通過創建訂單，并支付，從而完成交易。
由于訂單系統的高出現頻率，且不同業務的訂單設計思路大同小異，所以我們可以把它作為一個底層系統進行抽象，建立一套訂單的設計模型，便于我們快速應用到各個業務系統之中。
訂單系統架構
No. 1
以電商為例：
訂單作為電商最復雜的核心系統（或者稱之模塊），它建立其他系統模塊之上。
包括但不限于商品、優惠券、會員、營銷活動、地址信息、積分、運費、購物車、支付、發收貨等模塊，都和訂單息息相關，任何一個模塊的改動，都可能影響到訂單。不夸張的說，訂單是交易平臺最核心的子系統。
訂單包含的信息：
電商訂單系統架構：
因此做好訂單管理，最重要的是覆蓋的全面性、和極強的可擴展性。
訂單系統模塊拆分
No. 2
訂單主要分：訂單創建和訂單管理兩部分.
一、訂單創建：
訂單創建可以由C端用戶、以及B端使用者發起創建，并在訂單系統中生成。
訂單創建的節點，在頁面上的展示，就是提交訂單頁面點擊“提交訂單”按鈕那一刻，訂單就會被創建。
當然表面上看，點擊“提交訂單”就觸發了訂單創建，但背后，創建過程會調用前面所說的各個模塊，并且夾雜了大量的邏輯判斷。
提交訂單頁原型：
以下為訂單生成的校驗：
即在“提交訂單”那一刻，會進行多個信息的邏輯判斷
配送信息：配送方式和配送地址。
需判斷是否填寫了配送方式和地址；（如果是外賣）配送地址是否超過配送范圍；
商品
需判斷商品是否是上架狀態；
商品是否售罄；
商品庫存是否小于訂單中的商品數量；（如有贈品贈送）需判斷贈品是否庫存不足；
運費
選擇收獲地址后，會根據后臺的運費模版自動進行運費計算，并回顯在【提交訂單】頁；
提交訂單時需要校驗運費信息是否變動；
促銷活動
需判斷當前該用戶、該訂單商品適用的所有促銷活動。促銷活動一般分平臺級、店鋪級2個層級
平臺級：針對平臺內商品的促銷活動；
店鋪級：針對店鋪內商品的促銷活動。
當然一般這類活動還有一些限制條件，比如
訂單滿多少金額才可以參與
只限一定等級的會員
只限某些類目，或指定商品才可以參與
如果同時滿足多個活動參與的條件，則只能參與優先級最高的活動；
等等，視促銷活動數量和復雜度而定。
會員優惠
提交訂單時需判斷會員等級及相應優惠權益是否變動，需判斷可用積分數量是否變動。
優惠券
需要判斷優惠券是否已核銷；
是否已過期；
是否在適用時段內；
是否已被使用等。
一旦提交訂單后，則訂單即完成創建，這個時候訂單模塊還會發起指令要求其他模塊進行相應的配合：
訂單中的商品庫存需要在商品模塊中進行凍結處理
訂單中使用的優惠券需要在優惠券模塊中進行狀態變更
訂單中使用的促銷活動權利應該標記為已使用該權利
訂單中扣減的積分應該在用戶積分中進行扣減等
當然對于外賣而言，還需要在提交訂單的時候對店鋪是否在休息時間、店鋪是否開啟該配送方式、訂單價格是否滿足起送價等各種情況進行確定，如存在變動則給出用戶相應提示。
二、訂單管理
當訂單被創建后，即進入訂單管理階段。
C端頁面：
B端的訂單管理頁：
訂單輪轉流程：
關于訂單狀態
從用戶端（買家）角度看，電商平臺的訂單流轉中間狀態一般有如下6大狀態：
1）待付款：當用戶提交訂單后，支付之前，都屬于待付款狀態，商家端也是待付款狀態。
2）待發貨：當用戶完成支付后，訂單狀態變更為待發貨，商家端也同步更新為“待發貨”狀態。
3）待收貨：當商家在后臺確認發貨后，訂單狀態在買家端的顯示就會變成“待收貨”狀態，在賣家端會顯示“已發貨”，這里兩邊的展示會有一個區別。
假如買家收到貨一直不點確認，那么一般平臺會有一個周期（淘寶是14天），14天后系統自動確認收貨，變更為交易成功。
4）退款中：一共兩種情況會導致訂單變更為“退款中”的狀態。
是在“待收貨”狀態下，即商家已經發貨后，買家進行退款操作，那么訂單狀態會直接變成退款中；
是在“待發貨“狀態下，買家取消訂單／賣家操作全額退款，則進入退款中狀態。
是買家確認收貨后，申請退款，則進入”退款中“狀態，一般電商平臺都支持確認收貨后7天無理由退貨
5）交易完成：一共有兩種情況會導致訂單變更為”交易成功“
是用戶確認收貨；
是買家申請部分退款，退款流程結束，且剩余商品確認收貨后，訂單變更為“交易成功”。
6）交易關閉：一共有3種情況會出現“交易關閉”
是“交易成功”后發起全額退款，完成退款流程變更為“交易關閉”；
是在”待支付“的時候買家取消訂單／訂單超時過期）；
是“待發貨”的時候買家申請退款，商家確認后訂單變更為“交易關閉”。
關于訂單中的優惠分攤
為什么要考慮優惠分攤，如果下單的時候使用了某種優惠活動，當訂單進行部分退款的時候，我們肯定不能給買家直接退商品的原價，這樣對賣家的損失就很大了。
因此在訂單生成時，就會針對使用優惠活動的商品計算優惠分攤。
舉例
我們舉個最簡單的例子，買家購買了一個商品A100元，一個商品B200元，提交訂單時參與了滿100減50的促銷活動，那么最后支付了250元。
假如買家收到貨后覺得A不滿意，申請退款，賣家同意后且完成退款流程后，應該退給A多少呢？
A的退款金額=100*250/（100 200）=83.33元（保留2位小數點）
他并不能收到100元，因為假如他收到了100元，相當于最終用了150元買到了B，這是存在漏洞的。
再舉個更復雜的案例：這個案例涉及到平臺跨店促銷優惠、店鋪促銷優惠、優惠券優惠券
舉例
買家購買了1個商品A100元（甲店）、1個商品B200元（甲店）、1個商品C300元（乙店）。
提交訂單時，參與甲店的滿200減50的促銷活動1，同時還參與了平臺滿200減100的促銷活動2，此外還使用了一張150元的平臺代金券。
那么根據優先級首先A B的商品享受甲店的活動1后變成了（100 200-50）=250元，然后A B C繼續參與平臺的活動2后變成了（250 300-100）=450元，最終使用一張平臺代金券后支付（450-150）=300元，即最終需支付300元。
即依次按照活動1>活動2>代金券的優先級進行參與。
假設退款時，是無法退還代金券的，那么在訂單生成時，我們來計算下每一層優惠分攤之后，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元
所以經過優先級從高到底的三層優惠分攤后，A最終的實際可退金額為45.45元，B為90.91元，C為163.64元
2、關于拆單
在電商平臺中，只要有購物車功能，就會出現買家跨店購買商品的情況。
比如一筆訂單買了甲店的商品A一件，買了乙店的商品B一件，對于買家來說，他只是下了一筆訂單；但是對平臺來說，需要把A的訂單信息推送給甲店，把B的訂單信息推送給乙店，這就需要對買家的訂單進行拆單。
另外對于提交給甲店的訂單來說，如果訂單包含多個商品A、B、C，可能還會涉及到發貨單的拆單，比如A、B一起發貨，C單獨發貨。
作者：鄭海華，深耕 B 端業務多年，熟悉電商、醫療等業務，具有多個從 0 到 1 的大型產品孵化經驗。
