電商系統最終的目的還是下單支付，所以對于訂單系統的設計也成了重中之重，本文站在從0到1的角度上概述訂單系統搭建時需要重點處理的功能點，希望能給大家帶來一點收貨，同時也給自己做一個總結。

下面分別從以下幾個方面講解：

1. 支付后訂單拆單處理；
2. 商品優惠分攤；
3. 訂單價格體系；
4. 銷售訂單處理流程；
5. 售后訂單處理流程。

一、支付后訂單拆單處理

1. 為什么需要拆單？

客戶同時在多家店鋪下單，不同的店鋪的商品在正常情況下是要拆開的，否則無法跟蹤物流信息，無法分開收款和對賬。

物流信息的跟蹤：即便是同一商家的不同的貨物，如果訂單的商品分別需要從不同的倉庫中發出，那么會存在多個發貨單，多個包裹；不同包裹物流信息和狀態肯定是不一致的，而且在系統中也需要分開收貨和結賬。

2. 拆單的處理細節點

需要根據電商平臺的實際情況，確定拆單的維度，是根據不同的店鋪進行拆單還是根據不同的包裹拆單，還是兩者都需要。

拆單的節點：如果生成訂單之后沒有直接去支付，那么就會存在待付款的訂單，從用戶體驗的角度上來說，用戶肯定是更期望多個子訂單一起支付的，這里建議在訂單列表中可以以母訂單的形式展示。

拆單的價格：如果被拆開的多個訂單同時享受同一項優惠，如果處理好優惠金額在不同子訂單的分攤也是需要注意的，剩余的誤差需要放至一個子訂單中。

二、商品優惠分攤

1. 為什么要對訂單金額進行分攤？

首要因素是退款，在訂單付款成功之后，如果不針對單個商品進行金額分攤，那么如果用戶需要退訂單中的部分商品，沒法計算需要退的金額，需要分別退給商家和平臺多少錢等。

財務對賬：將優惠金額分攤到每個商品上，能核算統一母訂單下的子訂單分別分攤的優惠金額，比如：平臺券，一個使用平臺券的母訂單最終需要計算每個子訂單分攤的優惠金額，以確定每個子訂單的實際付款金額和享受平臺優惠的金額，否則無法與商家進行賬務核對。

核算成本：通過把優惠金額分攤到每個商品上去，運營，財務或采購人員可以評估營銷活動的成本。

2. 優惠金額分攤邏輯

按照最小粒度進行分攤：即優惠金額需要分攤到每個商品，且同一個商品采購數量大于1時，該商品最終只能有一個分攤后的價格。

優惠分攤比例：按照商品金額分攤對應比例的優惠，保證不同商品享受優惠的公平性，否則會出現商品應分攤的優惠大于商品的銷售價或影響用戶體驗。

分攤順序：先分攤多商品的優惠，再分攤店鋪維度的優惠，最后分攤平臺層面的優惠。

誤差處理：減小誤差主要途徑是在算法層面上進行優化，同時也無法避免誤差，多余的誤差需要按照不同的優惠活動分別存儲起來，在財務對賬和退款的時候需要用到。

三、訂單價格體系的設計

該部分是貫穿整個訂單流程中最核心的部分，訂單相關信息在需要展示在不同操作系統，如：平臺總后臺、商家端、APP、PC端、小程序、公眾號，需要結合數據庫的結構一起設計。

訂單系統在數據庫設計層面至少需要存在以下幾個表：訂單表、訂單明細表、售后訂單表、售后訂單明細表（也可以把售后訂單和銷售訂單結合起來設計表結構），分別需要定義各個不同表的字段及其含義。

比如，在我們系統中會定義訂單中商品存在的價格層次：

1. 原價：即后臺設置的商品初始銷售價格；
2. 銷售價：沒有參加單品活動的商品的銷售價為原價，參加特價/買降活動的商品的銷售價為促銷價；作為訂單詳情中商品統一展示的價格，還用來計算商品總額；
3. 結算價：商品經過店鋪優惠活動分攤之后的價格；可以用來展示給店鋪，作為他們的成本價，也用來計算該訂單需要支付給商家的金額，該字段不能展示給采購用戶；
4. 實際價：商品經過店鋪優惠和平臺優惠分攤之后的價格；主要用來展示給平臺，從平臺的角度衡量成本，關鍵是可以用作退款時實際退款給采購商金額的計算；
5. 滿減分攤：商品經過滿減分攤，分攤的金額；主要用于退款時計算需退還滿減優惠；
6. 店鋪券分攤：商品經過店鋪券分攤，分攤的金額；主要用于退款時計算需退還店鋪券優惠；
7. 平臺券分攤：商品經過平臺券分攤，分攤的金額；主要用于退款時計算需退還平臺券優惠；
8. 已退數量：商品發生部分退貨或退款的總數量（生成待審核的退款單時減數量，取消訂單或退款關閉則把數量加回來）。

同理在訂單列表和售后訂單列表，也需要設計相關字段，限于篇幅和隱私限制，僅就核心事項進行說明：

1. 同一個字段，母訂單和子訂單分別需要有不同的解釋；
2. 子訂單金額之和要=母訂單金額（否則影響用戶體驗且在退款時無法處理干凈）；
3. 字段設計時必須兼顧所有系統相關頁面需要展示的信息，對于銷售訂單，售后訂單來說，用戶、店鋪平臺各自分別需要看到什么信息，不能看到什么信息；
4. 字段設計時需要考慮訂單優惠金額和退款時限制的最高可退金額；
5. 平臺優惠未分攤完的金額需要放至子訂單中。

四、銷售訂單處理流程

對于訂單流程的設計，是電商系統設計中最基礎的環節，不同業務場景的訂單流程會有不同，最終核心離不開以下幾個點：

1. 生成訂單：一般來說在確認訂單頁面點加購物車按鈕時生成訂單，同時也進行庫存的相關操作
2. 付款成功：從確認訂單頁面或訂單列表中進來收銀臺頁面選擇支付方式進行支付；（訂單銷售數據一般也是基于已付款的訂單進行統計）
3. 發貨：付款成功和發貨之間，可能涉及平臺確認訂單，ERP相關操作（訂單狀態變為已發貨），同時需要進行庫存的相關調整
4. 收貨：點擊確認收貨按鈕，進行確認收貨，訂單完成且狀態變為交易完成
5. 取消訂單：取消訂單后需要生成退款訂單，同時訂單狀態變為交易關閉（交易關閉可以定義為交易未達成，不涉及財務對帳，這個有時間再講一下財務系統相關設計）
6. 申請售后：售后訂單完成且退款成功后，如果是整單退款，那么訂單需要變為交易關閉
7. 訂單狀態超時：包括超過一定的時間自動取消訂單和自動確認收貨等

在設計好各個訂單處理環節及訂單狀態之后，需要定義不同狀態下的操作按鈕，操作按鈕包括：立即付款、申請售后、確認收貨、查看物流，當然需要注意一點就是用戶操作的界面與后臺商家或平臺處理訂單的按鈕是不一樣的。

此外訂單流程往往需要涉及電商系統與ERP對接的問題，這一塊也比較復雜，后面單獨再聊聊開放平臺的設計經驗。

五、售后訂單處理流程

售后訂單的狀態及操作按鈕設計的思路與銷售訂單基本一致，值得重點注意的是：

1. 售后流程的設計需要結合實際的需求去考慮，是否支持部分退貨，什么情況下可以退貨，流程是怎樣的，是否需要審核等；
2. 支付及財務清算方案會影響到退款的邏輯，所以需要結合一起考慮；
3. 退款時，如何處理分攤的優惠金額，按照什么金額給用戶退錢，怎么和商戶之間針對售后訂單進行結算；
4. 退款時也涉及服務費退還，平臺優惠退還等。

以上是本人對于訂單系統的一點經驗總結，講的較為籠統，對于售后流程的處理還有很多細節值得去探討，以后有時間可以單就售后的流程在詳細介紹一下。

有補充或不對之處，歡迎大家指正探討！

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

題圖來自Unsplash，基于CC0協議