在電商體系中，商品中心、訂單中心、庫存系統為最重要的三大核心系統，訂單系統（OMS系統）連接用戶和商家之間最重要的交易信息系統，本次闡述一下電商訂單系統的産品設計。

一、訂單系統的作用

1.1 對用戶來說

用戶在下單後實時查看訂單發貨狀态，物流信息狀态和最後交易糾紛的售後流程等。

1.2 對商家來說

商家管理訂單狀态，實時發貨，處理售後糾紛處理等，更好更快的滿足用戶需求，提升處理效率等。

1.3 對平台來說

在平台運營上，監管訂單，處理平台介入異常訂單信息，處理需求和供給兩端的糾紛，提供業務支撐，實現業務閉環，提升用戶價值，完善用戶體驗等。

二、訂單系統的特點

2.1 業務類型不同，訂單規則不同

訂單系統搭建需要考慮實際業務情況，分商品實物訂單，虛拟訂單等不同業務其訂單系統的設計區别都是很大，如：實物商品售賣，付費課程售賣和服務餐飲業務其電商設計都是根據實際業務劃分。

2.2 流程複雜，分正向逆向流程

前端用戶下單時正常時的正向流程為從商品下單，發貨，收貨到最後的訂單交易成功；發生售後異常時的逆向流程：用戶申請退貨，到退款結算一系列售後流程；其規則又有很大的不同。

2.3 信息交互複雜，邏輯性強

從訂單下單産生的訂單經過大約20個不同子系統的一系列信息的流轉，前端展現簡單的頁面展現，可能後端會經過大量的系統信息校驗和流轉。

三、怎麼設計一個訂單系統

從用戶下單總體流程為：用戶下單選擇下單方式（購物車，直接下單）——訂單下單——訂單拆單——生成訂單查看訂單狀态——交易成功或申請售後逆向流程等等；商家後台系統更改訂單狀态，對接發貨，物流，售後和最終的數據統計等。

3.1 下單方式：購物車的設計（篇幅有限，有機會續寫）

• 基本邏輯：購物車入口邏輯，購物車商品庫存邏輯（鎖定扣減邏輯），購物車的商品分開展示邏輯；
• 價格計算器：優惠類型劃分，優惠計算邏輯及展示；
• 離線購物車：登錄加購邏輯，未登錄加購邏輯；
• 立即購買：立即購買流程；
• 異常處理：失效商品邏輯及展示，優惠失敗邏輯及展示；
• 其他邏輯：湊單邏輯，商品推薦邏輯，對接的系統信息流轉邏輯。

3.2 訂單下單：訂單信息展示

• 用戶信息：用戶賬号，用戶等級；
• 訂單基礎信息：父訂單，子訂單，訂單編号，訂單狀态，訂單時間；
• 收貨信息：收貨地址，收貨人姓名，聯系電話，郵箱；
• 商品信息：SKU信息，規格，商品數量，價格，商品圖片，商家，商品鍊接；
• 優惠信息：優惠券，促銷活動，虛拟币抵扣金額；
• 支付信息：支付方式，支付單号，支付狀态，支付時間，商品總金額，實付金額，運費，虛拟币抵扣金額，促銷優惠金額，優惠券優惠金額，總優惠金額；
• 物流信息：物流公司，物流狀态，物流單号；
• 其他信息：發票信息，下單平台，分銷渠道。

3.3 訂單下單：訂單拆單

下單時拆訂單：父訂單拆子訂單

• 平台的不同店鋪商家需拆單：因為涉及到商品歸屬權不同，其财務結算，發貨情況不同所以需要拆單；
• 倉庫不同，需要拆單：一物多倉的情況下，可能按照地域時效選擇倉庫發貨物流信息不同需要拆單。

支付後拆發貨單：子訂單拆多個包裹

• 品類特殊包裝要求需要拆單：如易碎品需要特殊包裝，超大物品需要單獨包裝，有些不同品類的商品不能放在一起；
• 物流因素，超過物流運輸限制需要拆單，如超過規定物流公司重量需要拆單；
• 商品價值：海淘商品消費限額，貴重物品商品價格高需要單獨發貨，需要拆單。

3.4 訂單下單：訂單的計算

• 訂單實付金額=商品總金額 運費-商品優惠總金額
• 商品優惠總金額=優惠券 促銷活動 積分抵扣 會員抵扣

3.5 生成訂單：訂單狀态

不同業務類型商品訂單狀态不同，實物商品訂單和虛拟商品訂單狀态都有所不同，訂單狀态最重要的是各個時間節點的數據流轉，這裡介紹下實物商品訂單的訂單流轉狀态：

待付款：用戶提交訂單，尚未付款，等待用戶支付，由于待付款狀态會鎖定庫存，所以一般會設置超時自動取消；

待發貨：用戶付款之後，等待商家發貨；

待收貨：商家已發貨，等待用戶收貨；

交易成功：用戶确認收貨後，訂單已完成交易；

已取消：付款之前取消訂單，超時未付款或用戶自動取消訂單都會産生這種訂單狀态；

售後中：用戶在付款後發貨前申請退款，或商家發貨後用戶申請退換貨狀态，需要注意的是售後狀态也有單獨的訂單流轉狀态：待審核，待退貨入庫，待退款，待換貨入庫，換貨出庫中，售後成功；

交易失敗：當售後完成後的訂單狀态，”已取消“的訂單狀态可以合并到“交易關閉”中。

3.6 訂單的售後：訂單逆向流程

訂單的逆向流程可以是用戶主動發起或者客服發起，需要注意的是不同節點申請退換貨，系統的處理方式不同，逆向流程複雜，還涉及到優惠分攤返還的邏輯，這裡不詳細介紹，以下為各個時間節點的訂單售後流轉情況：

待付款取消訂單：用戶提交訂單後，主動取消訂單或超時未支付時候，訂單狀态為“已取消”；

待發貨取消訂單：用戶支付訂單後，到“待發貨”狀态時，用戶申請取消訂單需要判斷數據到哪個環節了，訂單未到調度中心和就在調度中心未下發到倉庫管理系統或從調度中心到了倉庫管理系統（WMS系統）但攔截下來了，則可以取消成功；否則取消失敗，訂單繼續發貨；

待收貨/交易成功取消訂單：收到貨物後，當SKU全退時，原訂單變成“交易關閉”；當發生訂單部分退貨，退款時候，原訂單保持不變，維持“待收貨”或“交易成功”狀态，同時生成部分售後訂單，剩餘的訂單還可以進行售後。

3.7 訂單的數據統計

訂單交易維度：

統計周期内訂單銷售額（GMV）【最重要】

訂單量：統計周期内訂單量

客單價：統計周期内，已支付的訂單平均金額

下單用戶數支付用戶數，訂單金額分布，地域分布等等

商品分析維度：

被下單的商品數：統計周期内，被下單數>0的上架商品總和

被支付的商品數：統計周期内，被支付訂單數>0的上架商品總和

被訪商品數：統計周期内，被訪問uv數>0的上架商品總和

商品收藏次數，商品銷售統計，加購件數等等。

訂單來源維度：

統計每個訂單的來源：如H5，公衆号，APP，小程序，pc端；

記錄每個訂單的産生過程，包括在創建之前的商品浏覽，加入購物車，提交訂單等關鍵路徑的數據分析；

追蹤訂單來源：包括來源的網站，關鍵詞，來源網站等等。

四、總結

訂單系統與各個系統之間信息交互複雜，要求邏輯思維能力較強，對于産品設計來說，邏輯比具體的原型頁面更為重要，需要考慮每個節點具體的前置後置條件，流程設計是否足夠容易理解、易用。

每個系統産品設計時候都要根據實際業務情況分階段完成，按照用最小化成本設計産品，實現業務需求，例如實物商品訂單系統中訂單狀态欄待付款，逆向流程中退換貨中換貨狀态等等開始也可以先不用設計，後期根據業務實際情況在進行設計。

訂單系統具體的界面複雜，不同業務模式下其設計特點很大差異，多參考不同業務類型下的訂單系統，門檻低的如淘寶，有贊，拼多多等等電商前後台訂單系統搭建。

篇幅有限，歡迎大家交流社交語音産品，電商前後台産品的産品設計，VX：1332616842；共同交流學習，謝謝！

本文由 @十甫君 原創發布于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

,