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

一、訂單系統的作用

1.1 對用戶來說

用戶在下單后實時查看訂單發(fā)貨狀態(tài)，物流信息狀態(tài)和最后交易糾紛的售后流程等。

1.2 對商家來說

商家管理訂單狀態(tài)，實時發(fā)貨，處理售后糾紛處理等，更好更快的滿足用戶需求，提升處理效率等。

1.3 對平臺來說

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

二、訂單系統的特點

2.1 業(yè)務類型不同，訂單規(guī)則不同

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

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

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

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

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

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

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

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

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

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

• 用戶信息：用戶賬號，用戶等級；
• 訂單基礎信息：父訂單，子訂單，訂單編號，訂單狀態(tài)，訂單時間；
• 收貨信息：收貨地址，收貨人姓名，聯系電話，郵箱；
• 商品信息：SKU信息，規(guī)格，商品數量，價格，商品圖片，商家，商品鏈接；
• 優(yōu)惠信息：優(yōu)惠券，促銷活動，虛擬幣抵扣金額；
• 支付信息：支付方式，支付單號，支付狀態(tài)，支付時間，商品總金額，實付金額，運費，虛擬幣抵扣金額，促銷優(yōu)惠金額，優(yōu)惠券優(yōu)惠金額，總優(yōu)惠金額；
• 物流信息：物流公司，物流狀態(tài)，物流單號；
• 其他信息：發(fā)票信息，下單平臺，分銷渠道。

3.3 訂單下單：訂單拆單

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

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

支付后拆發(fā)貨單：子訂單拆多個包裹

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

3.4 訂單下單：訂單的計算

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

3.5 生成訂單：訂單狀態(tài)

不同業(yè)務類型商品訂單狀態(tài)不同，實物商品訂單和虛擬商品訂單狀態(tài)都有所不同，訂單狀態(tài)最重要的是各個時間節(jié)點的數據流轉，這里介紹下實物商品訂單的訂單流轉狀態(tài)：

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

待發(fā)貨：用戶付款之后，等待商家發(fā)貨；

待收貨：商家已發(fā)貨，等待用戶收貨；

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

已取消：付款之前取消訂單，超時未付款或用戶自動取消訂單都會產生這種訂單狀態(tài)；

售后中：用戶在付款后發(fā)貨前申請退款，或商家發(fā)貨后用戶申請退換貨狀態(tài)，需要注意的是售后狀態(tài)也有單獨的訂單流轉狀態(tài)：待審核，待退貨入庫，待退款，待換貨入庫，換貨出庫中，售后成功；

交易失?。寒斒酆笸瓿珊蟮挠唵螤顟B(tài)，”已取消“的訂單狀態(tài)可以合并到“交易關閉”中。

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

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

待付款取消訂單：用戶提交訂單后，主動取消訂單或超時未支付時候，訂單狀態(tài)為“已取消”；

待發(fā)貨取消訂單：用戶支付訂單后，到“待發(fā)貨”狀態(tài)時，用戶申請取消訂單需要判斷數據到哪個環(huán)節(jié)了，訂單未到調度中心和就在調度中心未下發(fā)到倉庫管理系統或從調度中心到了倉庫管理系統（WMS系統）但攔截下來了，則可以取消成功；否則取消失敗，訂單繼續(xù)發(fā)貨；

待收貨/交易成功取消訂單：收到貨物后，當SKU全退時，原訂單變成“交易關閉”；當發(fā)生訂單部分退貨，退款時候，原訂單保持不變，維持“待收貨”或“交易成功”狀態(tài)，同時生成部分售后訂單，剩余的訂單還可以進行售后。

3.7 訂單的數據統計

訂單交易維度：

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

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

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

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

商品分析維度：

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

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

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

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

訂單來源維度：

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

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

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

四、總結

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

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

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

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

本文由 @十甫君 原創(chuàng)發(fā)布于人人都是產品經理，未經作者許可，禁止轉載。

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