訂單是電商體系的核心，有了訂單才有業績和盈利。

訂單中包含商品、優惠、用戶、收貨信息、支付信息等一系列實時數據。通過訂單中心，實現對線上訂單、線下訂單及第三方訂單的管理，支持訂單接收、訂單自動合并與拆分、自動匹配倉庫、庫存控制、自動匹配快遞、結算與支付等訂單生命周期中的一系列協調作業。依靠靈活多變的訂單產品設計架構，可滿足電商企業百萬級的訂單業務處理需求，提升訂單流轉的工作效率。

在訂單生成之后，會隨著訂單的流轉更新狀態。不同業務類型的訂單狀態，例如機票、服務訂單、商品服務訂單等，和最常見的純實物商品訂單狀態會有所區別。以實物商品為例，我們來討論下訂單狀態的流轉。訂單狀態主要有以下幾種類型。

（1）待付款：用戶剛提交訂單，尚未付款，等待用戶支付。由于待付款狀態會鎖定庫存，所以一般會設置超時自動取消功能。

（2）待發貨：用戶付款之后，等待商家發貨。

（3）待收貨：上級已發貨，等待用戶收貨

（4）交易成功：用戶確認收貨之后，訂單已完成交易

（5）已取消：付款之前取消訂單。超時未付款或用戶取消訂單都會產生這種訂單狀態

（6）售后中：用戶在付款后發貨前申請退款，或商家發貨后用戶申請退款、換貨，都會產生這種訂單狀態。

（7）交易關閉：當售后完成后的訂單狀態。“已取消”的訂單狀態可以合并到“交易關閉”中。

訂單狀態的正常流轉是：待付款、待發貨、待收貨、交易成功。但是訂單會有逆向流程，和發生的時間節點及類型相關，情況也很復雜。

訂單的售后狀態主要有以下幾種。

（1）待審核：用戶提交退貨、退款申請之后，等待審核的狀態。在用戶已付款待發貨的轉臺下，訂單未推送至倉庫或者在倉庫攔截發貨成功，系統可直接審核通過。當審核不通過時，回到正常流程中。

（2）待退貨入庫：退貨申請審核通過，等待用戶退貨入庫。

（3）待退款：退貨入庫成功后，等待退款給用戶

（4）待換貨入庫：換貨申請審核通過，等待用戶換貨入庫

（5）換貨出庫中：換貨入庫之后，生成換貨出庫單，訂單出庫。

（6）售后成功：當退貨、退款成功或換貨成功之后，流轉至“售后成功”狀態。退貨、脫困的售后成功在主流程下屬于“交易關閉”。

在售后管理中，還有一個值得思考的環節：多次售后。當換貨成功之后，在流程上還是允許客戶有售后環節的。那么在產品設計中，就應該考慮允許用戶多次發起售后。

一、訂單下單

（1）在訂單過程中進行安全校驗，主要是檢測用戶是否在黑名單上、用戶購買行為是否正常等，當檢測到不正常時，終止下單。

（2）從商品中心獲取商品信息（sku、規格、價格）

（3）從營銷中心獲取商品、訂單促銷信息（優惠券、促銷活動），判斷是否滿足優惠條件，計算優惠金額。

（4）在會員中心回去會員權益，例如平臺抵扣積分，折扣條件等。

（5）在調度中心校驗銷售層庫存，按照調度規則鎖定區域庫存。

（6）根據拆單規則（商家、倉庫、訂單類型等）將訂單拆分成若干個子訂單，根據運費模板計算運費，根據商品金額、運費、優惠金額計算應付金額（實付款）。

訂單包含的所有信息內容如下：

用戶信息：用戶賬號、用戶等級

訂單基礎信息：父訂單與子訂單、訂單編號、訂單狀態

收貨信息：收貨地址、收貨人姓名、聯系電話、郵編

商品信息：sku信息、規格、商品數量、價格、商品圖片、商家

優惠信息：優惠券、促銷活動、虛擬幣抵扣金額

支付信息：支付方式、支付單號、商品金額、實付金額、總、優惠金額

物流信息：物流公司、物流單號、物流狀態

其它信息：發票信息、下單平臺、分銷渠道

【父訂單與子訂單】

當從購物車選中多件商品時，例如選中三個店鋪中的商品，會將這次購買行為拆分成三個店鋪的訂單。這次整體的購買行為記錄在父訂單下，當系統首次提交訂單結算時，會合并子訂單，針對父訂單進行結算。當提交訂單結算中斷，或結算之后，系統在更新送單狀態、物理追蹤時，針對的就是子訂單。

【優惠分攤】

在計算訂單應付金額時：

訂單實付金額=商品金額（sku金額合計）+運費—總優惠金額

其中：

總優惠金額=促銷活動優惠金額+優惠券優惠金額+虛擬幣抵扣金額

到這里，算是完成了訂單計算的第一步。但是這里又出現了一個問題。當優惠后的訂單發生部分退貨時，應該怎么退款給用戶？

1.優惠后訂單發生部分退貨如何處理：促銷活動（如滿減）涉及很多商品，優惠券也涉及很多商品，有時甚至跨店優惠。甚至還有整單能享受優惠，部分退貨后就不滿足優惠條件了，這時怎樣平衡用戶、商品、平臺之間的利益，在退貨、退款時應該怎么處理？

兩個場景：

（1）發生售后有可能是平臺的原因，不是用戶不買，而是店鋪的的商品由問題

（2）假設雙11時，用戶分別在A和B店鋪買了參加滿1000減200活動，各買了500元的貨品，后來在A店退了價值100元的東西。這種情況下，退貨后已不滿足活動條件，是否要求用戶給補100元？如果用戶補款，又補給誰？

從上面的例子可以看出，如果將退貨沒達到條件的促銷優惠條件考慮進去，系統復雜度會成倍增加。從人性的角度考慮，我們相信絕大部分用戶不會為了達到優惠條件故意多買，然后惡意退貨。

最合適的處理方法就是下單時就將優惠金額按比例分攤到子訂單、商品上。退貨時退還用戶實付金額，而不會去追究用戶因退單而沒有滿足促銷條件，允許用戶占平臺的便宜。

2.優惠券分攤原則

關于優惠券分攤原則，不但應該按比例分攤，還應在滿足優惠條件的商品上，按照商品金額的比例分攤，而不是盲目分攤。

先來看一個案例場景。

訂單中有甲乙兩店的商品A/B/C/D，包郵。商品A/D參加跨店滿200減40的活動（活動1），商品B/C參加滿100減10的活動（活動2），另外用戶還使用了100元的現金券。

如圖所示：

二、訂單拆單

訂單拆單在電商訂單中很常見。拆單有兩次，一次是在用戶提交訂單之后、支付之前拆單，這次是拆分的訂單；另一次是在用戶下單之后，商家發貨之前，去拆分發貨單（sku層面）。

兩次拆單的原則不同，第一次拆單是為了區分平臺商家、方便財務結算，第二次拆單是為了按照最后的發貨包裹進行拆單，如不同倉庫、不同運輸要求的sku、包裹重量體積限制等因素

【為什么要拆單】

方便發貨和結算

影響拆單的因素主要有以下幾點。

（1）店鋪商家。由于商品歸屬權不同，涉及財務結算和發貨的問題。店鋪商家不同，需要拆分訂單。

（2）倉庫。由于發貨倉庫不同，按照商品歸屬的倉庫進行拆單，若多倉有貨，還應按照地域時效選擇倉庫進行拆單。

（3）品類。由于商品屬性和價值的不同，同樣會產生拆單需求。

（4）物流因素。不同物流公司對單個包裹的重量或體積計算包裹總重量和體積，超出物流公司限制的也需要拆單

（5）商品價值。跨境海淘商品（單次限額）

【拆單流程】

【拆單之后的前端顯示】

在用戶提交訂單之后、支付之前的拆單，需要及時顯示給用戶，若用戶中斷支付，再回到支付環節，就需要分開支付。

在支付之后，系統根據一些影響因素進行拆單，同一個子訂單可能會對應多個物流單，在訂單顯示頁面查看物流信息時，需要展示多個物流信息。但是現在許多平臺只能一個訂單對應一個物流單，有些訂單商品數量過多或商品體積過大，一個包裹裝不下。倉庫分多包裹發貨，反饋前端就一個物流單號，信息反饋上就有瑕疵。可以通過一個訂單對應多包裹實現。

三、訂單售后（退貨退款）

在訂單生成之后沒訂單的流轉過程會出現不同的逆向流程。

【待付款取消訂單】

當用戶提交訂單后主動取消訂單或者用戶超時未支付時，訂單的狀態變更為“已取消”，不需經過客服審核

【待發貨取消訂單】

當訂單在“待發貨”狀態時，用戶申請取消訂單。由于用戶在支付訂單后，發貨單可能已經推送至WMS，甚至已經交接發貨，狀態未及時回傳更新。未避免貨款兩失，要先暫停訂單出庫，在調度中查詢訂單是否推送至倉庫，若尚未推送，則停止出庫流程。若暫停失敗，則拒絕“取消訂單”申請，回復原因“訂單已出庫”；若暫停成功，“取消訂單”申請通過，進入退款流程，同時通知調度中心該訂單取消，WMS訂單進入返庫流程。

【待收貨/交易成功退貨】

當訂單在“待收貨”或“交易成功”的狀態時，用戶申請退貨。

【待收貨/交易成功退款】

當訂單在“待收貨”或“交易成功”的狀態時，用戶申請退款

四、線下服務訂單

純服務訂單是指線上購買服務，線下接受服務。對于純服務訂單，當提交訂單付款之后，系統生成核銷碼，如二維碼或者一串字母數字組合。當用戶到店接受服務之后，店鋪進行核銷，核銷碼失效，訂單交易成功。

商品服務訂單是指在線上購買商品，商品收貨之后，去指定門店接受商品附加服務。

對于商品服務訂單，商品發貨之后將服務核銷碼發送給用戶，當商品到貨后，提醒用戶進行商品附加服務。服務核銷之后，交易流程才算結束。

在系統中，可以將服務當做一種特殊類型的sku來處理。這類商品與服務之間的關系，可在商品中心進行維護。當購買此類商品后，訂單進入商品服務訂單流程。在下單時客戶可選擇服務門店，也可以不選，后期通過人工客服指定門店。當選擇門店之后，可選擇送貨到家或直接送到么蒂娜，當商品到貨后，進行商品服務。

商品服務訂單流程不同于一般商品的流程在于：當實物商品發生售后時，服務核銷仍有效。服務商提供服務后，還涉及相應服務的結算，為避免服務商刷單，應提供相應核銷碼作廢功能。

五、訂單數據統計

常規統計傾向于財務統計，主要包括銷售額、毛利、成本、純利潤、客單價等。流量分析統計更多是為了指導電商平臺運營工作，分析用戶行為，訂單流量等。在訂單流量中又分為三個維度，分別從訂單交易維度、商品維度、訂單來源等三個方面來分析。

【交易分析（訂單層面）】

交易維度分析需要統計一下幾個數據。

（1）統計周期內的訂單銷售額（統計周期可以是日、周、月或自定義）

（2）訂單量：統計周期內的訂單量

（3）客單價：統計周期內，翼支付的ID你滾蛋平均金額

（4）下單用戶數與支付用戶數

下單用戶數：統計時間內，提交訂單的去重買家人數，一個人購買多件或多筆，只算一個人

支付用戶數：統計時間內，提交訂單并支付的去重買家人數，一個人支付多件或多筆，只算一個人

（5）支付新用戶數與支付老用戶數

支付新用戶數：統計時間內支付一次且在最近365天內首次支付的用戶去重人數。可能會存在以前有下單未支付而統計時間段內來支付的用戶

支付老用戶數：統計時間內支付多次或最賤364天內有過支付且統計時間內再次支付的用戶去重人數

（6）訂單金額分布：訂單金額在各價位之間的占比。可以更清楚的知道店鋪用戶的購買價值分布，可以針對性地提高用戶客單價

（7）地域分布：分析各區域的購買轉化率及訂單量、客單價，有針對性性地進行營銷

【商品分析（商品層面）】

商品維度分析需要統計以下數據

（1）被下單商品數：統計周期內，被下單數大于0的商家商品數總和

（2）被支付商品數：統計周期內被支付訂單數大于0的上架商品數總和

（3）被訪商品數：統計周期內，被訪問uv大于0的上架商品數總和

（4）商品收藏次數：統計周期內，商品被來訪者收藏的次數

（5）商品銷量統計：統計周期內，按照單一商品維度統計上架商品的銷售數量，按品類統計銷售額、銷量

（6）加購件數：統計周期內，，買家加入購物車商品件數之和

【訂單來源分析】

訂單來源分析需要統計以下數據

（1）統計出每個訂單的來源，包括訂單的來源媒介（站外廣告渠道）、用戶端（APP、H5商城、PC端等）

（2）記錄每個訂單的產生流程，包括在的那個單創建之前的商品瀏覽、加入購物車、提交購物車等關鍵步驟的數據分析

（3）追蹤訂單來源，包括來源的媒介、來源關鍵詞、來源網站等。

六、擴展：購物車

【購物車的妙用】

1.湊單

用戶瀏覽商品詳情頁的時候，有兩種選項：一種是“立即購買”，另一種是“加入購物車”。當用戶本身需求較多，想一次購買多種商品，或者參與到優惠活動中，這時候將商品加入購物車進行湊單

2.促銷

購物車還有促銷方面的功能，用于提高客單價。當有粗次奧活動時，用戶將商品加入購物車之后，可以查看是否滿足優惠條件和優惠之后的金額

3.收藏

對于大部分用戶來說，購物車發揮更多的是收藏哪個的作用

【購物車的設計】

1.通用顯示

購物車在展示時，基本的展示信息主要有：商品標題、商品圖片、價格、規格、數量、商家、庫存狀態。購物車的選中策略有三種：打開時默認全選、打開時默認全不選、云端同步選中狀態。用戶的購物車數據需要記錄在數據庫中，保證APP端和web端同步，下次登錄后不會丟失。

2.離線購物車

離線購物車指的是用戶在未登錄狀態下把商品加入購物車，一般通過創建虛擬用戶實現。為了更好的用戶體驗，需要讓用戶在下單之前，允許未登錄先將商品加入購物車。

用戶登錄之后，涉及離線購物車和在線購物車合并。首先判斷當前是否有離線購物車。然后將離線購物車的數據和在線購物車的數據進行合并

3.庫存監控

由于商品庫存會發生變動，在庫存緊張或無貨的時候，會在前端給與提示。除了提醒用戶，在庫存緊張時還有促單的功效。購物車更新時，去查詢對應的商品庫存，判斷當前商品的數量，當庫存數大于0并小于提醒值時，提醒用戶庫存不足，請盡快下單；當庫粗數等于0時，提醒無貨；當商品下架后，提示商品無效。無效商品進入無效商品列表中，可批量清除。

4.排序分類

商品在購物車中顯示有幾個維度：（1）商家店鋪，將不同店鋪的商品分開；（2）優惠不同，在購物車中將優惠活動相同的商品聚合在一起；（3）加入時間，按照加入購物車的時間倒序排列，最近添加的商品排列在前

5.促銷信息

購物車中顯示促銷相關信息，類似滿減、滿贈、贈品等信息。

6.商品推薦

在購物車底部，是最好的商品宣傳位，可以添加為商品推薦區域。至于商品推薦的內容，會根據用戶數據做定向推薦

7.價格監控

購物車的商品價格變動時給用戶提示

8.編輯

編輯購物車時主要可以機型的操作：產出商品、加減商品數量、更改商品規格等。

【購物車的結算】

在購物車選中商品時，會實時算出訂單金額。在購物車中計算時，需要將優惠金額算進去，但是這部分優惠只包括滿減的部分。

在購物車中未將優惠券的優惠金額算入，主要是因為實際場景中可能有多種優惠券滿足訂單的情況，用戶可根據需要自由選擇相應的優惠券。