本文詳解了電商系統訂單模塊中的各項流程，包括了訂單的概念、構成、狀態、流程、逆向訂單、訂單拆單等內容。

一、訂單概述

電商所有模塊中，訂單模塊是核心中的核心，電商所有模塊都是直接或者間接為訂單模塊服務的。

訂單模塊看似簡單，很多新人產品經理包括我自己，都覺得訂單模塊不就是瀏覽商品、加購、支付、訂單列表不就完了嗎？

后來隨著接觸的增多，發現訂單模塊并不是想象中的簡單，覺得簡單的只是看到了冰山的海面部分，其龐雜的體系都隱匿在海面一下。今天根據我的經驗，來和大家訂單做詳細的說明。

電商系統涉及到3流，分別時信息流，資金流，物流，而訂單系統作為中樞將三者有機的集合起來，訂單系統就從這三流開始吧。

訂單模塊是電商系統的樞紐，在訂單這個環節上需求獲取多個模塊的數據和信息，同時對這些信息進行加工處理后流向下個環節，這一系列就構成了訂單的信息流通。我們從以下幾個環節對訂單信息流動進行詳細的說明

1. 訂單場景

訂單場景的說明不言而喻，不同場景下訂單表現形式和數據傳遞方式也不相同，目前主流的訂單場景包括線上電商訂單、O2O電商訂單。

（1）線上電商訂單

這種電商就像淘寶、京東等，通過線上下單、支付后由自建物流或者第三方物流進行配送。這種電商系統通過，展示電商系統的商品模塊引導用戶對商品進行訂單模塊的處理，訂單模塊處理完成后將信息傳遞給WMS系統進行處理，當用戶收到貨品后在訂單系統進行確認。通過以上系統的協同處理來完成整個訂單信息的處理。如果是虛擬物品的話需要調用其他系統進行對接，通過接口返回參數方式完成信息的處理，比如充話費、買點卡等。

（2）O2O電商訂單

這種電商包括兩種外賣訂單和團購訂單。

外賣訂單和線上電商訂單有些類似，線上訂單處理完成后只是沒有經過倉庫環節進行處理，而是需要生產環節對數據進行處理，生產完成后將信息傳遞給物流環節，用戶確認收貨后再對訂單信息進行處理。

而團購訂單則是線上獲取商品信息后，通過訂單系統處理完成，將信息傳遞給wms系統進行庫存處理，只是對庫存進行信息處理而沒有物流配送環節，用戶線下到店后對訂單系統進行核銷處理，從而完成整個訂單信息的閉環。

二、訂單構成

我們先從訂單整個架構進行了解，以下是整個訂單系統的構成：

1. 用戶信息

用戶信息包括用戶賬號、用戶等級、用戶的收貨地址、收貨人、收貨人電話等組成，用戶賬戶需要綁定手機號碼，但是用戶綁定的手機號碼不一定是收貨信息上的電話。用戶可以添加多個收貨信息，用戶等級信息可以用來和促銷系統進行匹配，獲取商品折扣，同時用戶等級還可以獲取積分的獎勵等。

2. 訂單基礎信息

訂單基礎信息是訂單流轉的核心，其包括訂單類型、父/子訂單、訂單編號、訂單狀態、訂單流轉的時間等。

（1）訂單類型包括實體商品訂單和虛擬訂單商品等，這個根據商城商品和服務類型進行區分。

（2）同時訂單都需要做父子訂單處理，之前在初創公司一直只有一個訂單，沒有做父子訂單處理后期需要進行拆單的時候就比較麻煩，尤其是多商戶商場，和不同倉庫商品的時候，父子訂單就是為后期做拆單準備的。

（3）訂單編號不多說了，需要強調的一點是父子訂單都需要有訂單編號，需要完善的時候可以對訂單編號的每個字段進行統一定義和詮釋。

（4）訂單狀態記錄訂單每次流轉過程，后面會對訂單狀態進行單獨的說明。

（5）訂單流轉時間需要記錄下單時間，支付時間，發貨時間，結束時間/關閉時間等等。

3. 商品信息

商品信息從商品庫中獲取商品的SKU信息、圖片、名稱、屬性規格、商品單價、商戶信息等，從用戶下單行為記錄的用戶下單數量，商品合計價格等。

4. 優惠信息

優惠信息記錄用戶參與的優惠活動，包括優惠促銷活動，比如滿減、滿贈、秒殺等，用戶使用的優惠券信息，優惠券滿足條件的優惠券需要默認展示出來，具體方式已在之前的優惠券篇章做過詳細介紹，另外還虛擬幣抵扣信息等進行記錄。

為什么把優惠信息單獨拿出來而不放在支付信息里面呢？

因為優惠信息只是記錄用戶使用的條目，而支付信息需要加入數據進行計算，所以做為區分。

5. 支付信息

（1）支付流水單號，這個流水單號是在喚起網關支付后支付通道返回給電商業務平臺的支付流水號，財務通過訂單號和流水單號與支付通道進行對賬使用。

（2）支付方式用戶使用的支付方式，比如微信支付、支付寶支付、錢包支付、快捷支付等。支付方式有時候可能有兩個——余額支付+第三方支付。

（3）商品總金額，每個商品加總后的金額；運費，物流產生的費用；優惠總金額，包括促銷活動的優惠金額，優惠券優惠金額，虛擬積分或者虛擬幣抵扣的金額，會員折扣的金額等之和；實付金額，用戶實際需要付款的金額。

6. 物流信息

物流信息包括配送方式，物流公司，物流單號，物流狀態，物流狀態可以通過第三方接口來獲取和向用戶展示物流每個狀態節點。

三、訂單狀態

1. 待付款

用戶提交訂單后，訂單進行預下單，目前主流電商網站都會喚起支付，便于用戶快速完成支付，需要注意的是待付款狀態下可以對庫存進行鎖定，鎖定庫存需要配置支付超時時間，超時后將自動取消訂單，訂單變更關閉狀態。

2. 已付款/待發貨

用戶完成訂單支付，訂單系統需要記錄支付時間，支付流水單號便于對賬，訂單下放到WMS系統，倉庫進行調撥，配貨，分揀，出庫等操作。

3. 待收貨/已發貨

倉儲將商品出庫后，訂單進入物流環節，訂單系統需要同步物流信息，便于用戶實時知悉物品物流狀態

4. 已完成

用戶確認收貨后，訂單交易完成。后續支付側進行結算，如果訂單存在問題進入售后狀態

5. 已取消

付款之前取消訂單。包括超時未付款或用戶商戶取消訂單都會產生這種訂單狀態。

6. 售后中

用戶在付款后申請退款，或商家發貨后用戶申請退換貨。

售后也同樣存在各種狀態，當發起售后申請后生成售后訂單，售后訂單狀態為待審核，等待商家審核，商家審核通過后訂單狀態變更為待退貨，等待用戶將商品寄回，商家收貨后訂單狀態更新為待退款狀態，退款到用戶原賬戶后訂單狀態更新為售后成功。

四、訂單流程

訂單流程是指從訂單產生到完成整個流轉的過程，從而行程了一套標準流程規則。而不同的產品類型或業務類型在系統中的流程會千差萬別，比如上面提到的線上實物訂單和虛擬訂單的流程，線上實物訂單與O2O訂單等，所以需要根據不同的類型進行構建訂單流程。

不管類型如何訂單都包括正向流程和逆向流程，對應的場景就是購買商品和退換貨流程，正向流程就是一個正常的網購步驟：訂單生成–>支付訂單–>賣家發貨–>確認收貨–>交易成功。而每個步驟的背后，訂單是如何在多系統之間交互流轉的，可概括如下圖：

1. 訂單創建

訂單創建是從用戶下單開始的，當用戶對商品進行下單后，系統會引導用戶來到確認訂單頁面，此時系統會獲取用戶預下單的商品信息，同時判斷商品是否涉及到優惠促銷的信息，這些優惠券包括促銷活動，優惠券，積分抵扣等。

除了獲取優惠信息外，還需要判斷用戶等級權益，比如VIP用戶8折優惠，新用戶立減優惠等，其中的券別在于一個是針對商品，一個針對的用戶等級權益，電商系統在開發初期如果不涉及用戶等級折扣而又有新用戶促活優惠的話，建議使用優惠券來做。而在優惠活動需要遵循配置的疊加規則和優先級規則，在預下單操作是需要做判斷。

在預下單操作時，需要對庫存進行查詢，而庫存從什么時候進行增減，目前主流有兩種方式：

1. 下單減庫存，用戶預下單成功時減少庫存數量，優點是系統邏輯比較簡單，庫存實時展示用戶體驗好，同時也帶來了惡意下單的風險。
2. 付款減庫存，用戶支付完成后再減少庫存，優點減少惡意下單的風險，缺點是第三方支付回調采取的是異步回調方式，回調結果返回系統需要時間，并發下單情況下可能導致庫存不足引發退款和投訴。

個人比較傾向于下單減庫存的方式，在電商這個競爭激烈的環境下，保障用戶體驗才是第一位的，同時需要做好相對的措施，預下單后馬上對庫存進行鎖定，鎖定時間同步訂單支付的限定時間。

比如淘寶的15分鐘，限定時間內沒有付款，將鎖定庫存進行回滾釋放。這種下單減庫存的方式，可以減少用戶因為下單后倉庫沒有貨的情況，減少用戶的挫敗感。

2. 訂單支付

訂單支付在支付層面涉及的方面比較多，比如默認支付渠道，支付渠道的路由，組合支付等，在這里就不多加敘述，訂單支付過程做需要選擇支付方式，支付完成后通過支付渠道會返回支付流水號，支付完成時間。系統需要記錄訂單同時生成支付流水，方便與支付渠道進行對賬。

支付完成后下一步是等待賣家發貨或者是訂單下放到倉庫，在此過程中，會涉及到拆單過程，一般拆單分為兩次拆單：

• 一次拆單：訂單層面的拆單，這個拆單主要是因為組合商品時，各個商品屬于不同商家，此時訂單需要使用父子訂單進行區分
• 二次拆單：商品層面的拆單，這個拆單由于商品分屬不同的倉庫，重量/體積限制，商品品類要求比如易燃或者貴重物品需要單獨打包，商品庫存原因，比如需要有些商品當天發生，有些商品48小時后發送，另外對于海淘來說還存在關稅問題需要拆單的。

對于拆單后面還會繼續進行說明。

3. 賣家發貨/倉儲處理

這個過程從線下走向線下，商家發貨過程已經形成一個標準化的流程，訂單內容會下放到倉庫，倉庫對商品進行打單、揀貨、包裝、交接快遞進行配送。

目前很多WMS系統都與主流電商系統進行了對接，訂單下單成功后直接進入到WMS系統，在此過程中會涉及到合并訂單，比如同一買家同一收貨信息分多筆下單的訂單，訂單審核，訂單重新分倉，下放庫房，生成批檢單，訂單打印等等。關于物流倉儲方面后面物流篇講進行詳述。

4. 確認收貨

訂單通過倉儲環節，已經發貨了，在訂單系統中會涉及到對物流信息的獲取，包括配送方式/物流公司/物流單號/物流狀態的實時顯示。

記得淘寶沒有打通物流查詢環節時，那時候想知道包裹到哪里，需要根據商家提供的物流公司和物流單號，在物流公司官網進行查詢，而現在很多物流公司開放了物流接口，可以根據物流接口獲取物流狀態信息。當用戶收到貨后，可以根據物流公司反饋的簽收結果，設置提醒用戶確認收貨。

5. 訂單完成

用戶確認收貨后，這個訂單總算完了，NO,NO,NO，演出才剛剛開始。

訂單完成后會涉及到需要提醒用戶進行訂單的點評，同時可能會涉及到訂單的售后問題。

交易成功是指在收貨后N天后，此時除去售后問題外，渠道側會涉及到平臺和支付渠道結算的問題，貨款需要從支付渠道流入平臺賬戶；商戶側會涉及到平臺需要生成待結算清單問題，明細該筆訂單商戶結算款是多少。如果涉及到三級分銷的話，還需要考慮到各級代理分潤問題。

五、逆向訂單

訂單逆向過程是個非常頭痛的問題，每次涉及訂單的時候，每次都傻傻地問boss可以不做退款退貨流程嗎？

老板很鄙夷地回答：沒有買賣就沒有傷害。有人的地方就有江湖，有訂單的地方就有退款退貨一個道理，所以安心設計好逆向流程才是王道。

關于訂單逆向流程，想想線下一些購買場景理解起來就方便很多了，接下來就舉例說明逆向訂單：

大傻去電腦城去買個筆記本電腦，在千挑萬選后終于在奸商小K的說服下，準備下單購買一臺聯想小新air，故事就這么發生了……

CASE1 修改訂單

這個時候在小K的說服下大傻選購小新air，突然大傻對小新air配置還有一些優惠提出了新的疑問，好吧……正準備開單的小K為了促成這個交易在單子上面給大傻填寫贈送鼠標，背包…

修改訂單發生在預下單過程中，用戶沒有提交訂單，可以對訂單一些信息進行修改，比如配送信息，優惠信息，及其他一些訂單可修改范圍的內容，此時只需對數據進行變更即可。

CASE2 訂單取消

待支付情況下，各種單據都填好了，小K說：哥，你該付款了。大傻一摸口袋，錢包不見了。小K心里想，哥，你逗我玩呢？

這個時候有3種情況：

第一，大傻回去拿錢后給了小K錢。

第二，大傻說這個電腦不要了，單據作廢吧。

第三，大傻說我回去拿錢，返回后結果門店下班了，單據也作廢了。

這個狀態下對應電商場景下的 用戶主動取消訂單和用戶超時未支付，兩種情況下訂單都會取消訂單，而超時情況是系統自動關閉訂單，所以在訂單支付的響應機制上面要做支付的限時處理，尤其是在前面說的下單減庫存的情形下面，可以保證快速的釋放庫存。

另外需要需要處理的是促銷優惠中使用的優惠券，權益等視平臺規則，進行相應補回給用戶。

CASE3 退款

待發貨情況下，大傻及時付完款了，小K心里樂開了花，在去倉庫的路上一蹦一跳的，心里琢磨著這筆單下來晚上可以好好喝一杯了，結果跑到倉庫拿貨，倉庫告訴小K沒有貨了，小K心里一萬匹草泥馬在奔馳著。沒有辦法，小K只好回去告訴大傻，完了大傻對小K一頓咆哮，最終小K還是把錢退給了大傻。

故事還有另外一個版本：大傻及時付完款了，小K心里樂開了花，在去倉庫的路上一蹦一跳的，心里琢磨著這筆單下來晚上可以好好喝一杯了。還沒有到倉庫，前臺小姐姐給他打電話，大傻說隔壁王阿姨的姑姑的表姐的女兒出了車禍要借錢，所以大傻不要筆記本了，小K心里一萬匹草泥馬在奔馳著。沒有辦法，小K只好給大傻退款。

在待發貨訂單狀態下取消訂單時，分為商戶缺貨退款和用戶申請退款。

• 商戶缺貨退款由于訂單系統和WMS系統商品沒有進行及時同步導致，或者是倉管和客服分開產生的，這個情況下需要與用戶協商處理退款。
• 用戶申請退款，用戶下單后，商家還未發貨，系統應該支持用戶申請退款，如果發貨單已經下發到wms系統，但是尚未推送至倉庫，則應該挺推送至倉庫，推送至倉庫則需要WMS中進行攔截，攔截成功則暫定出庫，同步訂單系統 同意取消訂單，同時進入退款流程。

如果是全部退款則訂單更新為關閉狀態，若只是做部分退款則訂單仍需進行進行，同時生成一條退款的售后訂單，走退款流程。退款金額需原路返回用戶的賬戶。

CASE4 發貨后的退款

我們繼續那個故事：當小K從倉庫將筆記本電腦領出來后，將電腦拿給大傻，大傻一看包裝破破爛爛的啥玩意啊，老子不要了，不管小K好說歹說，大傻堅決不要了，拗不過他，小K最終還是給大傻退了錢。

發貨后的退款，發生在倉儲已經貨物的配送，在配送過程中商品遺失，用戶拒收，用戶收貨后對商品不滿意，這樣情況下用戶發起退款的售后訴求后，需要商戶進行退款的審核，雙方達成一致后，系統更新退款狀態，對訂單進行退款操作，金額原路返回用戶的賬戶，同時關閉原訂單數據。

僅退款情況下暫不考慮倉庫系統變化。如果發生雙方協調不一致情況下，可以申請平臺客服介入。在退款訂單商戶不處理的情況下，系統需要做限期判斷，比如5天商戶不處理，退款單自動變更同意退款。

CASE5 退款退貨

故事還沒有完，大傻沒有在小K家買成筆記本，又去了阿貍家買成了筆記本電腦，誰知道阿貍家筆記本更黑，翻新機做新機賣給大傻，大傻回去后筆記本沒用到1晚上就直接掛了。

火大的大傻第二天就找到阿貍要退貨，阿貍各種忽悠還是沒有忽悠到大傻這顆要退款退貨執著的心，萬般不情愿下阿貍終于將筆記本重新入庫后，給大傻退了錢。

用戶退款退貨的流程和用戶僅退款的流程差不多，需要與商戶進行協商，如果協商過程存在爭議平臺客服介入進行協調。如無爭議，商戶審核通過后告知用戶退貨流程及退回的收件信息，進入退貨流程后，商家收到用戶退貨商品后，庫存系統進行補回，退貨入庫，訂單系統確認后進行退款，同時關閉訂單。

當訂單中發生部分退貨時，原訂單的狀態不變，維持待收貨或交易成功狀態，同時退貨的部分生成交易售后訂單。剩余未退貨部分仍然允許申請售后。如果退貨商品在驗收環節存在用戶導致的問題，可以通過線下協商后，將商品重新發回給用戶，或者進行退部分款項。

之前在聊促銷活動時，說到過優惠金額的處理方式，之前只是針對平臺類和單店鋪模式進行說明，本節對優惠券和促銷進行訂單逆向的退款退貨進行說明，主要進行部分退款進行說明。

講解前先列公式，便于計算：

好了公式列完了開始講故事了：

618大促時夏天正好快到了，王小胖在某商城進行血拼，在618之前王小胖已經領取幾張優惠券分別時平臺服飾類優惠券滿500減50，小貓門店滿800減200優惠券，小花花門店滿400減100優惠券。

以下就是羅列每件商品的優惠券金額和實付金額：

如果王小胖對小貓門店休閑長褲不滿意，退款只需要退款149.31元即可。

到這里關于訂單正向和逆向流程已經說明完畢，拋出一個問題，如果同一個SKU里面有多件商品，需要對某件商品進行退款怎么操作？

六、訂單拆單

為什么要拆單呢？

因為電商平臺存在購物車進行合并付款，如果不拆單會遇到無法跟蹤物流或者會存在多個物流，另外做結算時不方便進行核賬等，哪怕時同一家店鋪也會存在發貨時間、分不同物流發貨問。這個時候我們需要進行拆單。

從訂單表層面，我們需要將訂單建立父子訂單，加購后提交訂單時需要創建父子訂單和編號，這個從用戶體驗角度來說方便用戶進合并付款，減少用戶操作提高轉化率。

拆單的原因包括：

• 店鋪：在多商戶商場下，商品歸屬不同商戶，所以涉及到商戶后臺的財務結算和物流發貨問題。
• 倉庫：商品不在同一個倉庫時需要按照倉庫歸屬進行拆單
• 屬性：有些商品需要單獨運配送，購買沙發和衣柜都需要獨立包裝，商品不在一起需要進行拆單
• 價值：這個涉及跨進電商，政策對跨境電商有單次限額，超過金額翻，也需要對訂單進行拆單。

第一次拆單 訂單層面拆單

訂單層面拆單主要加購下單后存在上面說的對應不同的商戶和不同倉庫，用戶完成支付后可以訂單中有多個不同的子訂單。

父訂單是記錄一次下單和合并支付的依據，同樣在促銷層面來說可以通過父訂單享受購物的優惠，然后通過子訂單進行分攤，而子訂單是跟蹤物流，售后、結算的依據。所以在設計訂單設計需要所有訂單都設計父子訂單。

從物流層面來說訂單生成后，訂單會進行下放。對于平臺會將訂單推送到調度系統進行處理，多商戶商城可以將訂單導出安排發貨，在更新發貨信息；自接系統會將訂單同步WMS系統或者ERP里，安排發貨。

第二次拆單 物流層面拆單

訂單推送至調度層后，調度中心需要進行審核處理，審核通過后訂單開始進行調撥和配貨，這個時候需要倉儲需要根據發貨單進行拆單，這次拆單會包括商品屬性/價值/體積/重量/庫存進行拆單，子訂單包括多個包裝，也存在多個物流信息。

以上就是整個訂單信息流的說明，關于訂單還包括訂單結算，訂單支付等流程，這塊屬于支付和結算體系需要考慮的范疇，有機會再后面會進行支付和結算體系的說明。

作者：產品_空，微信號king_mario

本文由 @產品_空 原創發布于人人都是產品經理 ，未經許可，禁止轉載。

題圖來自 unsplash，基于 CC0 協議