10.1 訂單下單
電商產品經理寶典：電商後台係統產品邏輯全解析 作者：劉誌遠 投票推薦 加入書簽 留言反饋
先回想一下我們平時在網上購物的場景。
某天準備出遠門時，想到沒有充電寶，就打開京東或天貓超市，選擇一個心儀的充電寶，“哎喲，居然還有一個10元的優惠券”，下單付款，下午快遞員敲門，充電寶就到家了。
用戶的一小步，係統的一大步。在用戶選擇商品之後提交訂單的一瞬間，訂單實際上經過了各係統之間的漫長回路，如圖10-1所示的訂單下單流程。
圖10-1 訂單下單流程
（1）在訂單過程中進行安全校驗，主要是檢測用戶是否在黑名單上、用戶購買行為是否正常等，當檢測到不正常時，終止下單。
（2）從商品中心獲取商品信息（sku、規格、價格等）。
（3）從營銷中心獲取商品、訂單促銷信息（優惠券、促銷活動），判斷是否滿足優惠條件，計算出優惠金額。
（4）在會員中心獲取會員權益，例如平台抵扣積分、折扣條件等。
（5）在調度中心校驗銷售層庫存，按照調度規則鎖定區域庫存。
（6）根據拆單規則（商家、倉庫、訂單類型等）將訂單拆分成若幹個子訂單，根據運費模板計算運費，根據商品金額、運費、優惠金額計算應付金額（實付款）。
至此生成訂單，此時訂單狀態為待付款。如圖10-2所示，在存儲的訂單信息中，主要包含以下內容：用戶信息、訂單基礎信息、收貨信息、商品信息、優惠信息、支付信息、物流信息、其他信息等。訂單的內容複雜精細，在存儲時除了表結構的設置，還應該注意信息冗餘。特別是商品信息，由於商品的內容不斷編輯變化，要保存下單時的商品快照，避免過長時間後，商品信息丟失。加 入 會 員 微 信
圖10-2 訂單信息
訂單包含的所有信息內容如下。
用戶信息：用戶賬號、用戶等級。
訂單基礎信息：父訂單與子訂單、訂單編號、訂單狀態。
收貨信息：收貨地址、收貨人姓名、聯係電話、郵編。
商品信息：sku信息、規格、商品數量、價格、商品圖片、商家（店鋪）。
優惠信息：優惠券、促銷活動、虛擬幣抵扣金額。
支付信息：支付方式、支付單號、商品總金額、實付金額、運費、虛擬幣抵扣金額、優惠券優惠金額、總優惠金額。
物流信息：物流公司、物流單號、物流狀態。
其他信息：發票信息、下單平台、分銷渠道。 【父訂單與子訂單】
當從購物車選中多件商品時，例如選中三個店鋪中的商品，會將這次購買行為拆分成三個店鋪的訂單。這次整體的購買行為記錄在父訂單下，當係統首次提交訂單結算時，會合並子訂單，針對父訂單進行結算。當提交訂單後結算中斷，或結算之後，係統在更新訂單狀態、物流追蹤時，針對的就是子訂單。 【優惠分攤】
在計算訂單應付金額時：
訂單實付金額＝商品金額（sku金額合計）＋運費-總優惠金額
其中：
總優惠金額＝促銷活動優惠金額＋優惠券優惠金額＋虛擬幣抵扣金額
到這裏，算是完成了訂單計算的第一步。但是這裏又出現了一個問題。當優惠後的訂單發生部分退貨時，應該怎麽退款給用戶？
1.優惠後訂單發生部分退貨如何處理
產品經理遇到的情況是：促銷活動（如滿減）涉及很多商品，優惠券也涉及很多商品，有時甚至跨店優惠。甚至還有整單能享受優惠，部分退貨後就不滿足優惠條件了，這時候怎樣平衡用戶、商品、平台之間的利益，在退貨、退款時應該怎麽處理？
其中涉及用戶與平台之間的博弈，也考驗著產品規則設計者的智慧。目前的處理規則基本都是“優惠分攤，偏向用戶”。
我們先看一下兩個場景。
（1）發生售後有可能是平台的原因，不是用戶不買，而是店鋪的商品有問題。
（2）假設雙11時，用戶分別在a和b店鋪跨店買了參加滿1000減200活動，各買了500元的貨品，後來在a店退了價值100元的東西。這種情況下，退貨後已不滿足活動條件，是否要求用戶給補100元？如果用戶補款，又補給誰？
從上麵的例子可以看出，如果將退貨沒達到條件的促銷優惠條件考慮進去，係統複雜度會成倍增加。從人性的角度，我們相信絕大部分用戶不會為了達到優惠條件故意多買，然後惡意退貨。
最合適的處理方法就是下單時就將優惠金額按比例分攤到子訂單、商品上，同樣實付金額也分攤到子訂單、商品上。退貨時退還用戶實付金額，而不會去追究用戶因退單而沒滿足促銷條件，允許用戶占平台的便宜。
2.優惠分攤原則
關於優惠分攤原則，不但應該按比例分攤，還應在滿足優惠條件的商品上，按照商品金額的比例分攤，而不是盲目分攤。
先來看一個案例場景。
訂單中有甲、乙兩店的商品a、b、c、d、e，包郵。商品a、d參加跨店滿200減40的活動（活動1），商品b、c參加滿100減10的活動（活動2），另外用戶還使用了100元的現金券。
如表10-1所示，訂單總共優惠150元，其中活動1優惠40元，活動2優惠10元，優惠券100元。並不是將優惠完全平均分攤至每個商品上，而是按照優惠分攤原則，比如活動1在商品a、d的優惠金額分別是40x（80/320）＝10元、40x（240/320）＝30元，其他優惠金額詳見表中。
表10-1 優惠分攤的案例
根據表10-1中的數據，我們能夠清晰地計算出店鋪、商品在每次促銷活動中的收入。另外在用戶部分退貨時，也能按照其實付金額進行退款。例如用戶退商品a、b時，隻退款82元（54元＋28元）。這樣還能避免與用戶發生糾紛。
本節主要介紹了訂單的正向流程，但是在實際應用中又會衍生出許多變化。例如支付服務：有第三方支付、分期付款、貨到付款等，都影響訂單的狀態；還有自營平台會將出庫狀態加入到訂單狀態中；還有從其他渠道（線下訂單、京東等第三方訂單）導入到係統的訂單，不僅涉及與第三方平台的打通，還有對這些訂單的管理，以及同步狀態至第三方平台。
某天準備出遠門時，想到沒有充電寶，就打開京東或天貓超市，選擇一個心儀的充電寶，“哎喲，居然還有一個10元的優惠券”，下單付款，下午快遞員敲門，充電寶就到家了。
用戶的一小步，係統的一大步。在用戶選擇商品之後提交訂單的一瞬間，訂單實際上經過了各係統之間的漫長回路，如圖10-1所示的訂單下單流程。
圖10-1 訂單下單流程
（1）在訂單過程中進行安全校驗，主要是檢測用戶是否在黑名單上、用戶購買行為是否正常等，當檢測到不正常時，終止下單。
（2）從商品中心獲取商品信息（sku、規格、價格等）。
（3）從營銷中心獲取商品、訂單促銷信息（優惠券、促銷活動），判斷是否滿足優惠條件，計算出優惠金額。
（4）在會員中心獲取會員權益，例如平台抵扣積分、折扣條件等。
（5）在調度中心校驗銷售層庫存，按照調度規則鎖定區域庫存。
（6）根據拆單規則（商家、倉庫、訂單類型等）將訂單拆分成若幹個子訂單，根據運費模板計算運費，根據商品金額、運費、優惠金額計算應付金額（實付款）。
至此生成訂單，此時訂單狀態為待付款。如圖10-2所示，在存儲的訂單信息中，主要包含以下內容：用戶信息、訂單基礎信息、收貨信息、商品信息、優惠信息、支付信息、物流信息、其他信息等。訂單的內容複雜精細，在存儲時除了表結構的設置，還應該注意信息冗餘。特別是商品信息，由於商品的內容不斷編輯變化，要保存下單時的商品快照，避免過長時間後，商品信息丟失。加 入 會 員 微 信
圖10-2 訂單信息
訂單包含的所有信息內容如下。
用戶信息：用戶賬號、用戶等級。
訂單基礎信息：父訂單與子訂單、訂單編號、訂單狀態。
收貨信息：收貨地址、收貨人姓名、聯係電話、郵編。
商品信息：sku信息、規格、商品數量、價格、商品圖片、商家（店鋪）。
優惠信息：優惠券、促銷活動、虛擬幣抵扣金額。
支付信息：支付方式、支付單號、商品總金額、實付金額、運費、虛擬幣抵扣金額、優惠券優惠金額、總優惠金額。
物流信息：物流公司、物流單號、物流狀態。
其他信息：發票信息、下單平台、分銷渠道。 【父訂單與子訂單】
當從購物車選中多件商品時，例如選中三個店鋪中的商品，會將這次購買行為拆分成三個店鋪的訂單。這次整體的購買行為記錄在父訂單下，當係統首次提交訂單結算時，會合並子訂單，針對父訂單進行結算。當提交訂單後結算中斷，或結算之後，係統在更新訂單狀態、物流追蹤時，針對的就是子訂單。 【優惠分攤】
在計算訂單應付金額時：
訂單實付金額＝商品金額（sku金額合計）＋運費-總優惠金額
其中：
總優惠金額＝促銷活動優惠金額＋優惠券優惠金額＋虛擬幣抵扣金額
到這裏，算是完成了訂單計算的第一步。但是這裏又出現了一個問題。當優惠後的訂單發生部分退貨時，應該怎麽退款給用戶？
1.優惠後訂單發生部分退貨如何處理
產品經理遇到的情況是：促銷活動（如滿減）涉及很多商品，優惠券也涉及很多商品，有時甚至跨店優惠。甚至還有整單能享受優惠，部分退貨後就不滿足優惠條件了，這時候怎樣平衡用戶、商品、平台之間的利益，在退貨、退款時應該怎麽處理？
其中涉及用戶與平台之間的博弈，也考驗著產品規則設計者的智慧。目前的處理規則基本都是“優惠分攤，偏向用戶”。
我們先看一下兩個場景。
（1）發生售後有可能是平台的原因，不是用戶不買，而是店鋪的商品有問題。
（2）假設雙11時，用戶分別在a和b店鋪跨店買了參加滿1000減200活動，各買了500元的貨品，後來在a店退了價值100元的東西。這種情況下，退貨後已不滿足活動條件，是否要求用戶給補100元？如果用戶補款，又補給誰？
從上麵的例子可以看出，如果將退貨沒達到條件的促銷優惠條件考慮進去，係統複雜度會成倍增加。從人性的角度，我們相信絕大部分用戶不會為了達到優惠條件故意多買，然後惡意退貨。
最合適的處理方法就是下單時就將優惠金額按比例分攤到子訂單、商品上，同樣實付金額也分攤到子訂單、商品上。退貨時退還用戶實付金額，而不會去追究用戶因退單而沒滿足促銷條件，允許用戶占平台的便宜。
2.優惠分攤原則
關於優惠分攤原則，不但應該按比例分攤，還應在滿足優惠條件的商品上，按照商品金額的比例分攤，而不是盲目分攤。
先來看一個案例場景。
訂單中有甲、乙兩店的商品a、b、c、d、e，包郵。商品a、d參加跨店滿200減40的活動（活動1），商品b、c參加滿100減10的活動（活動2），另外用戶還使用了100元的現金券。
如表10-1所示，訂單總共優惠150元，其中活動1優惠40元，活動2優惠10元，優惠券100元。並不是將優惠完全平均分攤至每個商品上，而是按照優惠分攤原則，比如活動1在商品a、d的優惠金額分別是40x（80/320）＝10元、40x（240/320）＝30元，其他優惠金額詳見表中。
表10-1 優惠分攤的案例
根據表10-1中的數據，我們能夠清晰地計算出店鋪、商品在每次促銷活動中的收入。另外在用戶部分退貨時，也能按照其實付金額進行退款。例如用戶退商品a、b時，隻退款82元（54元＋28元）。這樣還能避免與用戶發生糾紛。
本節主要介紹了訂單的正向流程，但是在實際應用中又會衍生出許多變化。例如支付服務：有第三方支付、分期付款、貨到付款等，都影響訂單的狀態；還有自營平台會將出庫狀態加入到訂單狀態中；還有從其他渠道（線下訂單、京東等第三方訂單）導入到係統的訂單，不僅涉及與第三方平台的打通，還有對這些訂單的管理，以及同步狀態至第三方平台。