電子商務的關鍵詞是交易，作為交易中最重要的維系雙方契約的憑據就是訂單。本文筆者將與大家剖析電子商城的訂單信息中的各個字段內容，enjoy~

訂單流程主要是訂單產生到交易結束的整個流程，按照現在電子商城（E-mall），倉庫管理（WMS），物流管理系統（TMS）的流轉過程主要如下圖。

由買家發起購物付款-倉庫發貨-用戶收貨流程為正向流程，反過來買家退款退貨-倉庫收貨-退款處理流程為逆向流程。

這篇文章討論的是電子商城E-mall的訂單信息，E-mall電子商城系統的訂單信息內容主要如下：

訂單詳細信息中字段內容：

訂單單號

訂單單號是訂單信息中的主Key，代表了該訂單的唯一性，并且使用在倉庫管理系統中，WMS作為拆分合并訂單中與電子商城中的訂單關聯的Key值。

訂單單號一般組成方式有以下兩種：

1）日期時間+隨機數字，初期業務量不多的時候20-26位足夠應付。

HHHHMMDDhhmmss（年月日時分秒） +6位隨機碼。

6位隨機碼表示一秒鐘可能生成的訂單數上，存在一百萬分之一的隨機并發相同導致下單失敗，因此在初期業務每秒下單量不高的時候選擇這種簡單的方法足夠滿足需求。

2）以日期時間+自增的方式，這樣就不會產生隨機數生成沖突，但是要注意防治被查看到銷售量需要將數字加密設置。

訂單倒計時時間

訂單里面顯示倒計時有：

1）下單未支付

商品下單后開始倒計時，一定時間內如果還未下單則超時關閉訂單。

普通商品一般采取3天時間，特價商品根據情況一般采取的是30分鐘，快消品一般采用的15分鐘。

2）已發貨確認收貨倒計時

商品一般是發貨開始后開始倒計時10天時間，O2O商品應該是送達即收貨。

• 滿1天記錄1天 XX天hh小時mm分鐘
• 小于1天小時則hh小時mm分鐘ss秒

防止發貨時間過長，發貨后用戶可以采用一次延長收貨，商家/平臺端則可以多次延長收貨。

訂單狀態

訂單狀態與商品狀態是獨立的，因為商品狀態在任意時間都可以申請退貨退款，訂單狀態根據買家/商家/平臺操作動作后的狀態遷移。

訂單狀態遷移圖

訂單狀態對應的操作按鈕內容

收貨人信息

確認訂單的時候，收貨人地址是否超出送貨范圍需要明示，超出指定送貨范圍則該訂單無法提交。

另外有一個關鍵詞是是否自提，增加自提地址是線上商城線下門店相結合的一個結合的方式。

注意：選擇自提和自提地址后需要去除運費。

商品信息

在購物車或者直接購買的情況下，確認訂單里面商品信息是帶有商品的庫存狀態，該狀態是通過WMS定時返回Emall中保存的，包括：商品上下架狀態，可預定庫存數量。下架商品，或者可預訂庫存小于購買數量則在確認訂單中設置成失效商品。

商品狀態遷移圖>

根據狀態遷移圖顯示的商品按鈕

*可以根據訂單情況退款退貨期間狀態可以再細分成待退貨等狀態，以及完成訂單以后也可以申請維權狀態。當然一開始可以不用考慮過于復雜，先完成核心必要的流程功能，如果出現該情況可以先人工溝通。

金額信息

按照每個訂單中商品金額比例計算優惠券，抵用券以及運費，為了在退款退貨時計算實際退款金額使用。

單個可使用商品金額 / Sum(可使用優惠商品金額） * 優惠金額或者抵用券金額 = 單個可使用商品金額的的優惠值。

每個商品的實際支付金額 ?= 商品金額 –?單個可使用商品金額的的優惠值

單個商品的運費金額是按照運費模板來計算的比例，運費計算方式參考這篇《【產品設計】 電商運費計算方式》

當退款訂單中某個商品全部退款則退款運費（發貨前）退還所分配的金額。

退款商品只退款部分金額時候，運費也則需要按比例計算。

該訂單結算給商家的金額則如下：

單個商品可獲取的金額=?商品金額 – 用戶退款金額 – 用戶退款金額/用戶支付總額 × 該商品的分配抵用券金額

商家可結算該訂單的金額 = Sum（單個商品可獲取的金額） + 可退運費

物流信息

在開發初期，只是查看物流流水信息，則可以集成第三方物流平臺比如快遞xx，在系統開發的后續階段，需要對接更多的物流狀態，以及物流打單，分配物流單號則需要直接對接物流平臺。

使用某第三方物流平臺的物流信息的界面

訂單信息推送

訂單的相關的消息什么時候推送，什么方式推送能促成用戶快速成單，又避免頻繁的打擾用戶這是心理學問題。

以下皆為我自己觀點，可以理性討論。

訂單相關推送時機與方式

訂單是整個交易的核心鏈路，需要保證訂單流程的可擴展性，穩定性。經驗有限，文中應該也有描述不足擴展不足情況。

擴展的問題以及其他平臺更深入的問題，可以不用開始初步階段的時候就考慮，但是需要提前預留。比如：剛開始沒有考慮訂單狀態和商品狀態分開，則后續修改將導致，則整個訂單狀態再修改的時候舊版本很難和新版本保證狀態的一致性。

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

題圖來自Unsplash，基于CC0協議