訂單管理系統是電商系統中最為複雜的系統，其作為中樞決定着整個商城的運轉，我們設計商城的目的就是讓用戶下單，然後發貨，然後訂單完成。訂單系統是電商系統最重要的模塊，沒有之一。

訂單系統設計的好壞，決定了商城的可用性，與使用價值；訂單系統貫穿于整個商城系統，其他各個系統的設計也是為訂單系統提供數據支撐。訂單的核心是流程問題，涉及資金流、物流、信息流，從用戶提交訂單的那一刻到訂單完成，到售後，都需要訂單管理系統來管理。

講解訂單管理系統就必須從它的流程來說，訂單訂單從無到有、流程分為這樣幾個流程：

1. 階段一、訂單數據流程：用戶選擇商品信息，優惠信息等，生成訂單價格，點擊提交訂單，這一非常小的一步，需要後台處理很多的數據，将最終的訂單金額計算出來。這屬于訂單的第一個階段；
2. 階段二、訂單物流流程：用戶支付成功，到發貨，收貨，訂單完成；這屬于訂單的第二個階段，如果沒有異常流程，訂單到這裡已經完成，正常的訂單分為這兩個大的流程；
3. 異常階段、售後流程：用戶在以上兩個階段中發生取消支付、退款、退貨、換貨等售後服務，這時訂單就會走異常流程；異常流程要比正常流程還要複雜。

不管訂單系統系統如何複雜，如何拓展，我将訂單流程分為以上三個部分，而這三部分之間相互獨立而又相互聯系。第一階段用戶提交訂單，系統處理訂單數據；第二階段付款成功，訂單走物流系統，直到訂單完成；第三階段是從一或者二階段中産生的異常流程

一、訂單數據流程

這個階段線上的操作并不是很多，主要是體現在系統對數據的處理上，我們在商城選擇想要的商品，選擇商品規格、數量、優惠券、然後系統會為我們生成最終的訂單價格。這個流程屬于系統内部的數據處理流程，需要調取系統各個模塊的數據，流程如下：

首先，是用戶在商城内選購商品，這個階段可以叫做前置用戶行為。

然後，是系統調取各個系統的數據，計算訂單的最終價格，這個階段可以叫做後置數據處理。

最後，是将訂單價格在用戶端顯示，這個階段叫做表現層顯示。

1.1 前置用後行為

這個過程比較簡單，是屬于訂單流程的前置條件，隻有觸發此行為，才會生成訂單，系統才會記錄訂單數據；

需要流程如下：

用戶進入商城，浏覽商品，進入商品詳情頁面，點擊購買商品，選擇商品規格、數量，點擊提交訂單，然後進入訂單詳情頁面。

1.2 後置數據處理

在訂單詳情頁面系統會做大量的數據處理來計算訂單的最終價格，而訂單的最終價格也是可以随之變動的。比如：當用戶選擇是否使用優惠券，修改商品數量，訂單的價格都會發生變化。

後置數據處理的流程如下：

1.2.1 從商品管理系統獲取商品的SKU信息

首先，第一步會先獲取用戶所選擇商品的SKU信息，用戶選擇不同的規格對應不同的SKU信息，而不同的SKU對應不同的商品價格，根據用戶選擇的規格和商品數量生成商品總價。

訂單詳情頁面展示商品數量、規格信息、商品總價格。

1.2.3 從會員中心獲取會員權益信息

第一步、根據當前用戶的信息：獲取用戶的成長體系——也就是用戶的會員權益，會員等級是多少折扣，會員等級折扣金額的計算金額是在商品總價的基礎之上的。

1.2.4 從物流中心獲取運費信息

第二步、獲取用戶的運費信息：因為添加商品時肯定是要選擇運費模闆，根據運費模闆和用戶的收貨地址計算運費，若是商品統一包郵，或者促銷活動條件滿足包郵，則不計算運費。

1.2.2 從促銷中心獲取商品的優惠信息

第三步是從促銷中心篩選當前商品是否在已有的促銷活動之下（創建促銷活動需要指定商品）：若有所屬的促銷活動則在用戶端顯示所有的促銷活動、若沒有所屬的促銷活動則獲取商品所有可用的優惠券，并展示所有可用的優惠券。

（促銷活動與優惠券不可以同時使用，首選判斷商品是否有促銷活動，若有促銷活動并且當前狀态滿足促銷活動規則，則優惠券不可用；若有促銷活動，但是當前狀态不滿足促銷條件，則優惠券可用；若選擇了優惠券，即便訂單由于變動滿足促銷活動條件，促銷活動優惠不生效。）

訂單詳情頁面顯示商品當前的促銷活動，可使用的優惠券信息，同時顯示已經獲取的優惠信息：什麼優惠券優惠多少金額？或者，什麼活動優惠多少金額？

優惠金額的計算是在商品總價的基礎之上的。

說明：到此為止，訂單金額已經計算出來了，我們可能知道哪些地方需要計算優惠金額，但是關鍵的問題在于最終的優惠金額如何計算。

訂單金額的計算有兩種方式，不過一般來說使用第一種方式，第二種方式僅做了解。

（1）統一以訂單金額為基礎：就是所會員權益、優惠券金額、促銷活動金額的計算、都是在訂單金額的基礎之上的。

例如：商品SKU價格45元、數量2、運費10、會員優惠8折、促銷活動優惠5折、會員權益優惠15元，那麼最終的訂單價格為？

我們首先要定義“訂單金額”，訂單金額=商品SKU價格*購買數量 運費=100元；

以訂單金額為基礎，計算其他費用，那麼應支付就會這樣：

應支付金額=訂單金額-優惠券優惠金額-促銷活動優惠金額-會員權益優惠金額

現在的問題關鍵在于優惠金額的計算，如果是滿減就好說了，優惠金額一定，打折都是以訂單金額為基礎的。

應支付金額=100-（100*（1-0.8））-（100*（1-0.5））-（15）

也就是說，每項的優惠金額計算都是以訂單金額為基礎進行計算。

一般來說用這種方式比較好，能夠很好的體現每種金額優惠的價值，并且拓展性強，計算的順序不會影響最終的優惠效果，因為都是在訂單總價的基礎之上的，并且易于理解和計算。

（2）以順序計算訂單總金額：

——就是每一筆的計算都是在上一步金額的基礎之上的，具體算法如下：單價45元、數量2、運費5、會員9折、優惠8折。

首先，加上運費（（20*2） 5）=45元

然後，在上一步基礎上減去會員折扣45-45*0.1=40.5

最後，在上一步的基礎上減去會員權益的優惠金額40.5-40.5*0.2

這種方式不建議使用，計算順序會影響最終的優惠金額，比如：先計算促銷活動的優惠，和先計算會員權益最後導緻的訂單價格是有很大差别的

1.3 表現層顯示

當系統計算出訂單金額，就需要在頁面上顯示，訂單詳情頁面要顯示最終的訂單金額、同時還要顯示：

• 物流方式，運費
• 優惠券信息，優惠金額
• 促銷活動信息，優惠金額
• 會員權益，優惠金額

二、訂單物流流程

從用戶提交訂單就進入了物流流程，這個階段主要體現在商品的物流流轉以及物流信息的變更和記錄，訂單狀态的管理。

訂單物流流程如下:

2.1 用戶提交訂單，生成待付款訂單

當用戶提交訂單之後，雖然沒有支付，但是系統就會生成待付款訂單，對于生成訂單這個地方主要涉及這麼一個問題，就是訂單拆分的問題。

2.1.1 訂單拆分

可能大家也都知道訂單拆分，而怎麼拆分，為什麼拆分，大家可能都不清楚，但這也是我們需要知道的。

講一個小故事：首先我們先來說說訂單這個東西，現在有這麼個情況，小張在商家小紅的店鋪購買了一雙運動鞋，那麼商家小紅肯定是要為小張發貨的，所以他就需要聯系物流公司。

比如申通小李，為了跟蹤這雙運動鞋在系統中的物流情況，在發貨的時候需要為鞋子匹配唯一的訂單号和運單編号（訂單号電商系統生成，運單号快遞公司生成），為什麼有訂單号了還要運單号呢，訂單号是電商系統用于記錄當前小張提交的這一筆訂單信息，而運單号是為了跟蹤鞋子的物流信息。

過了一段時間，小張又在小紅這裡買了一雙運動鞋，不過同時買了一個皮球，方便玩耍，所以将一雙鞋、一個球加入購物車，統一購買。然後提交訂單，生成一個訂單号。

這個時候雖然是兩件商品，但是小紅為了圖方便，就将皮球和運動鞋放在一起發貨了，那麼申通小李看到的其實還是一個包裹。

但是他不知道的是，包裹裡面有兩個物品，所以就會創建一個運單編号，這也是為什麼我們在網上購物的時候明明買了兩件商品，但是收貨信息隻有一條，因為放在一起了。這種情況是一個訂單編号，一個運單編号，兩件商品。但是在運輸的過程中由于鞋和球放在一起了，車輛過于颠簸，鞋子就把皮球炸爆了，當小張收到貨後非常生氣，小紅也感覺非常的慚愧并為小張做售後。

又過了一段時間，小張還是在小紅這裡買了一雙鞋和一個皮球，但是為了防止拿到貨時皮球又被鞋子炸爆，所以小張要求小紅将這兩件商品分别發貨。

小張同時又在店鋪小王的店鋪裡買了兩個籃球，那麼這一次買的有點多——一雙鞋、一個皮球、兩個籃球，并且還是在兩個店鋪裡面，因為電商平台需要為每個商家進行資金結算，所有需要通過訂單号記錄每個商家的訂單信息。但是，顯然如果這次所有的東西都用一個訂單号那就亂了，因為結算是通過訂單查詢商家信息每筆訂單對應一次結算，兩個商家這筆訂單的錢應該結給誰呢，所以這個時候就會出現第一次拆單。

如果用戶一次提交訂單，但是訂單包含多個商家，或者商家和平台自營同時出現，那麼就需要拆單。

小張提交的5件商品分為2個訂單，每個訂單号對應一個商家，同時如果小張另外在平台自營買了一件商品，道理也是一樣，也需要拆單。

因為平台自營的商品是不需要結算的，如果把平台的訂單放到商家一起，那麼給商家結算的時候，豈不是平台賣得東西算到商家頭上了。

回到上面，剛說拆分成了兩個訂單：第一個訂單我們叫他訂單号001，這個訂單下面是商家小紅的商品，一雙鞋，一個皮球；第二個訂單号002，這個訂單下面兩個籃球；小紅将這兩件商品分别發貨，于是申通小王發鞋子，另外喊來小王的同事申通小明發皮球。

顯然我們就知道了，鞋子會對應一個運單号，皮球也會對應一個運單号（也就是二次拆單），這兩件物品的物流信息分别記錄。但是，這兩個物品對應的是一個物流單号001，也就是說一個訂單，一個訂單編号下可能對應多個運單編号。

同時也就可以解釋這麼一個現象，利用訂單編号是查詢不到物流信息的，隻能靠運單編号（叫法問題，運單編号也叫物流單号），想一下我們在購物時看自己的未收貨商品時，我們可能就會想到，每一條信息的展示是對應一條運單号的，而上下排列的兩件商品列表，很有可能訂單編号是相同的。

也就是說，我們在購物車購買多個商品提交訂單時，可能會有多個訂單号（一次拆單，拆業務訂單，原因上不同商家、平台所導緻的），同時一個訂單号可能會有多個運單編号（二次拆單，拆發貨單，用戶端拆開顯示）

以上步驟是生成訂單：

2.2 用戶付款完成，待付款訂單流轉為待發貨訂單

提交訂單系統就會生成訂單，此時訂單是待付款訂單，用戶付款完成之後，流轉成待發貨訂單。而當用戶提交訂單長時間沒有支付的話，訂單就會自動取消，生成已取消訂單。同時用戶對于待付款訂單也可以主動取消，生成已取消訂單。

用戶可以對待付款訂單進行付款操作。

2.3 後台選擇物流進行發貨，待發貨訂單流轉成待收貨訂單

用戶付款完成之後，後台就會顯示買家已付款，這個時候就需要進行發貨，發貨需要填寫運單編号、物流公司，運單編号物流公司提供。

發貨完成之後系統就會跟蹤物流信息，同時訂單狀态變為待收貨狀态。

用戶可以對待收貨訂單進行收貨/申請退貨操作。

隻要商品發貨完成，用戶以後都可以查看物流信息。

如果用戶付款之後但是還沒有進行發貨，用戶可以執行退款操作。

2.4 用戶進行收貨，或者時間段内自動收貨，待收貨訂單流轉為已完成訂單

用戶通過查看物流信息，進行線下取貨，确定商品完好之後可以進行确認收貨操作，确認收貨之後，訂單變已完成狀态。

用戶在确認收貨操作之前可以進行申請退貨操作，卻已經确認收貨則不可以申請售後。

三、異常階段、售後流程

在整個購物流程當中除了正常的流程，有時候還會後異常的流程，這些流程會改變訂單應該有的流轉狀态。

3.1 取消支付

當用戶提交訂單但是取消支付：

當用戶提交訂單的時候系統就會同時生成待付款訂單，這個時候拉起支付頁面，如果用戶支付成功，訂單流轉為待發貨狀态，如果用戶支付失敗或者退出支付，那麼訂單就會保持待付款狀态。

對于待付款的訂單，用戶可以繼續進行支付，一般來說待付款是有支付剩餘時間的，就是在一定時間内如果用戶沒有支付成功，那麼訂單就會關閉，流轉為已關閉訂單，對于已經關閉的訂單用戶僅可執行删除操作。

對待支付訂單用戶可以主動取消訂單，生成已關閉訂單。

3.2 退款

用戶付款完成在沒有發貨之前申請退款：

當用戶付款完成，訂單就會流轉為待發貨狀态，這個時候後台是要準備發貨的。那麼在用戶付款之後，商家發貨之前，這個時候用戶可以申請退款。

申請退款需要填寫退款理由，然後提交商家審核，如果是多商戶，所有的售後流程都由商家來進行審核，平台無需幹涉。後台會看到用戶的審核狀态為申請退款中，這個時候商家要确定是否已經發貨了，沒有發貨的話同意退款，資金按原路返還給客戶。拒絕申請需要給客戶說明拒絕理由，比如訂單已經發貨，無法退款。

3.3 退貨

發貨之後，用戶在未确認收貨之前申請退貨：

當商品發貨，但是用戶未确認收貨前可以申請退貨，申請退貨一般是在用戶已經收到貨了，但是對商品不太滿意。

比如：衣服不太合身，這個時候就需要申請退貨，首先提交退貨申請，填寫退貨原因，後台初步審核通過後，訂單狀态變為待退款，退貨訂單；用戶聯系快遞公式發貨，填寫發貨信息，主要是快遞單号，當商家收到貨後會查看商品是否完好，确認後，在後台執行确認退貨退款操作，資金自動返還給用戶。

3.4 換貨

發貨之後，用戶在未确認收貨之前申請退貨：

換貨的流程與退貨相似，用戶申請換貨，審核通過後，用戶進行發貨，商家收到貨後訂單完成；在從新為用戶進行新的發貨。

四、線下服務訂單

線下服務訂單就很簡單了，用戶付款完成系統會生成唯一的核銷碼，比如：6為數字，然後用戶線下到店消費，出示核銷碼，商家進行核銷，訂單完成。

本文由 @謝謝張先生 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議

,