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

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

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

以電商為例：

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

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

訂單包含的信息：

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

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

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

1、訂單創(chuàng)建

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

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

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

提交訂單頁原型：

以下為訂單生成的校驗：

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

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

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

商品

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

（2）、商品是否售罄；

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

運費

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

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

促銷活動

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

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

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

當(dāng)然一般這類活動還有一些限制條件，比如

（1）、訂單滿多少金額才可以參與

（2）、只限一定等級的會員

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

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

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

會員優(yōu)惠

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

優(yōu)惠券

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

（2）、是否已過期；

（3）、是否在適用時段內(nèi)；

（4）、是否已被使用等。

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

（1）、訂單中的商品庫存需要在商品模塊中進行凍結(jié)處理

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

（3）、訂單中使用的促銷活動權(quán)利應(yīng)該標(biāo)記為已使用該權(quán)利

（4）、訂單中扣減的積分應(yīng)該在用戶積分中進行扣減等

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

2、訂單管理

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

C端頁面：

B端的訂單管理頁：

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

關(guān)于訂單狀態(tài)

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

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

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

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

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

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

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

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

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

（5）、交易完成：一共有兩種情況會導(dǎo)致訂單變更為”交易成功“

1）是用戶確認(rèn)收貨；

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

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

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

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

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

關(guān)于訂單中的優(yōu)惠分?jǐn)?/strong>

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

因此在訂單生成時，就會針對使用優(yōu)惠活動的商品計算優(yōu)惠分?jǐn)偂?/p>

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

那么根據(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)先級進行參與。

假設(shè)退款時，是無法退還代金券的，那么在訂單生成時，我們來計算下每一層優(yōu)惠分?jǐn)傊螅珹、B、C的可退金額是多少：

第一層：活動1分?jǐn)偤?/p>

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

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

商品C=300元

第二層：活動2分?jǐn)偤?/p>

商品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元

第三層：代金券分?jǐn)偤?/p>

商品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)惠分?jǐn)偤?，A最終的實際可退金額為45.45元，B為90.91元，C為163.64元

關(guān)于拆單

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

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

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

-END-

【轉(zhuǎn)載說明】   若上述素材出現(xiàn)侵權(quán)，請及時聯(lián)系我們刪除及進行處理：[email protected]