解讀新零售-電商系統前後台設計全面解析——訂單管理

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

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

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

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協議