編輯導語：訂單拆分對于訂單中心來說是很重要的，這個拆分并不是簡簡單單的對商品進行拆分，還要同時將優惠也進行拆分。訂單拆分不需要結合自身的業務場景，不同的業務情況，拆分的條件與拆分的邏輯都會有所不用，本文作者從訂單拆分與優惠信息兩方面為我們分析了拆分思路。

訂單拆分環節是整個訂單中心不可或缺的一部分，因為有了訂單拆分，方能更好的對自身的業務場景進行拓展。

在很多時候我們可以看到，將多個商品一起放入購物車下單結算的時，最終看到的并非一個訂單，而是多個訂單。并且拆分的邏輯不僅僅只是訂單，同時也會涉及到優惠信息的拆分，將拆分好的優惠信息分攤到各個訂單上。

筆者將本文分成兩部分給大家詳細講解訂單拆分和優惠信息拆分的思路。

一、訂單拆分場景

1. 按商家拆分

眾所周知，目前有很多電商平臺供商家入駐，用戶下單時普遍存在跨店鋪結算的情況，所以要將訂單內的信息進行拆分。同時將商品信息與優惠信息分攤到各自店鋪的訂單上，由此形成了首層的拆分。

例如：在下單時，直接將訂單內的商品按照不同的商家拆分成多個父訂單，然后根據不同的配貨倉庫拆分成不同的子訂單，即一個倉庫對應一個子訂單，但通常情況下用戶是感知不到拆分的，看到的仍然只有一個父訂單。

作為新零售平臺，我們可將商家可視為門店，那門店也就是前置倉，所以從這個角度上看，也可以理解為倉庫的拆分，若線上網店與線下門店是一對一的關系，可以不考慮該層次的拆分。

同時在連鎖模式下，根據用戶收貨地址匹配就近門店，所以門店自然也不會涉及到拆單，若該門店無庫存的情況下，商品為售罄狀態。

2. 按倉庫拆分

電商平臺商家存在多倉庫的情況（例淘寶），且自營平臺不同的商品存放在不同的自建倉庫（例京東）。

用戶下單時訂單內的商品存放于不同的倉庫，那就需要針對不同的倉庫進行拆分，將拆分完的子訂單匹配至各自的倉庫當中，最終根據商品的貨物數量進行出庫備貨。

每個子訂單對應一個運單號，且每個子訂單下每個商品SKU對應1個發貨單號，發貨單號與子訂單做關聯。最終即使做了訂單改派處理，也能夠對該訂單進行追蹤跟查詢，同時也方便日后財務做對賬。

若已經形成訂單的情況下，對訂單內的部分商品進行改派。

例如：將倉1的發貨單，改派至倉2當中，同時會帶上對應的子訂單。若不存在拆單的情況，則只有一個父訂單。

訂單內每個商品SKU分配獨立的發貨單號，每個發貨單號對應同一個父訂單（父訂單與子訂單為：一對多的關系；子訂單與發貨單為：一對多的關系，父訂單與發貨單同樣為：一對多的關系）

3. 按訂單類型拆分

訂單的類型由商品的類型進行歸屬分配，下單之后根據商品類型拆分成不同的子訂單類型。

例如：商品內存在跨境商品、普通商品、分銷商品等，根據不同的商品類型進行自動拆分。

特別是跨境商品，需要調用海關API，推到海關進行報關處理，或將跨境商品單獨拿出來與其他商品進行分單結算。

另一方面：由于跨境商品訂單的限制，每個用戶每年成交金額不可超過2W，且單筆訂單消費不可超過2千；若超過2千則將該訂單進行自動拆分處理，分單推送報關。

4. 按商品類目拆分

不同的商品有不同的類目，根據商品的類目進行分單處理，由于部分商品類目的特殊性。

例如：生鮮水果冷鏈食品以及其他易碎物品對快遞保護性、及時性等配置要求較高的，需要單獨進行包裝發貨，若訂單內存在該類目的商品，則需要將訂單進行拆分處理。

若訂單內包含預售的商品，本身這類商品的性質就有別與其他商品，所以用戶在下單之前就已經進行區分。自然這類商品在產品設計上就不會增加購物車這個功能，所以就不存在合并下單的情況。

若存在與其他商品一起下單的情況，則需要將普通商品和預售商品拆分成子訂單處理，將預售商品的訂單到貨后再發貨。

5. 按物流拆分

物流拆分可以說是整個拆分環節最末尾的拆分，由于訂單內部分商品的重量或體積已經超過了單個包裹發貨的范圍。

同時從成本的角度上考慮，一個包裹的發貨成本有可能會高于多個包裹的發貨成本，因此會將訂單拆分成多個包裹發貨。那么在這種情況下，可不生成子訂單，以發貨單號來進行區分即可。

6. 什么時候做拆單處理

正常情況下一般分為 “付款前拆單” 和 “付款后拆單”，用戶下單之后沒有立即支付，但已然形成待支付訂單。

每個父訂單下形成多個子訂單，不同的子訂單內分別包含多個商品SKU，每個子訂單都會存在物流查詢入口；若子訂單的商品分多個包裹發貨，那么物流查詢入口就會分為多個。

另一種情況為：付款之后拆分成不同的子訂單，每個子訂單對應多個運單號，有些平臺為了方便財務做對賬，會在付款之后才進行拆單處理。

二、訂單的拆分邏輯判斷

既然有不同的拆分場景，那一定就有拆分的先后順序，以下的拆分邏輯，根據自身實際業務場景采用即可。

通常情況下，涉及到2-3個拆分邏輯是會比較多的，具體拆單順序如下所示：

1. 商家拆單：SKU1、SKU2、SKU3、SKU4（匹配商家1）、SKU5、SKU6、SKU7、SKU8、SKU9（匹配商家2）；
2. 倉庫拆單：SKU1、SKU2（匹配倉庫2）、SKU3、SKU4（匹配倉庫1）、SKU5、SKU6、SKU7、SKU8（匹配倉庫3）、SKU9（匹配倉庫4）；
3. 類型拆單：SKU5、SKU6、SKU7（匹配普通商品）、SKU8（匹配跨境商品，若不繼續往下拆，形成子訂單，并填寫運單號，并形成發貨單號，打包發貨）、其他SKU先在此省略；
4. 類目拆單：SKU5、SKU6（匹配正常類目）、SKU7（匹配特殊類目，例如生鮮冷鏈商品等，形成子訂單，并填寫運單號，并形成發貨單號，打包發貨）；
5. 分開發貨：SKU5、SKU6歸屬于同一個子訂單，但會分為不同的運單號和發貨單號，最終打包發貨。

三、優惠信息拆分

訂單被拆分之后，拆分的不僅僅只是商品，還有訂單內的金額信息、優惠信息等，目的是在用戶產生售后問題時所造成退款退貨，需要將優惠信息進行合理的分配返還。

因為訂單存在退部分的商品，不可能將訂單內所有的優惠信息返還給用戶，所以需要將訂單內的優惠信息合理的分攤到子訂單上，同時需要將訂單內每一個優惠信息字段進行區分。

當我們在進行優惠分攤時，同時應該按照商品的金額計算出比例進行分攤，以平衡商家與用戶之間的利益，所以我們要遵循一定的分攤原則進行。

優惠信息分攤計算公式：

• 單個商品SKU總金額：單品金額*購買數量；
• 促銷信息：滿減活動；
• 抵扣信息：積分、虛擬金幣；
• 優惠券信息：優惠券抵扣；
• 運費金額：是否包郵；
• 實付金額=商品總金額+運費金額-總優惠信息；
• 子訂單分攤金額=單個商品SKU總金額/父訂單總金額*優惠總金額。

舉例說明優惠信息的分攤計算（需將促銷信息與優惠券信息單獨分開計算），訂單拆分成4個子訂單，每個子訂單對應1個SKU：

1. SKU 1（子訂單A）的分攤金額計算

先算出單品優惠：SKU 1 單品優惠（-5）；

SKU 1商品總金額：30*2=60；

滿減分攤優惠：（60-5）/（55+80+100+60）*20=3.72；

優惠券分攤優惠：（60-5）/（55+80+100+60）*10=1.86；

子訂單實付款：60-5-3.72-1.86=49.42。

2. SKU 2（子訂單B）的分攤金額計算

SKU 2商品總金額：40*2=80；

滿減分攤優惠：80/（55+80+100+60）*20=5.42；

優惠券分攤優惠：80/（55+80+100+60）*10=2.71；

子訂單實付款：80-5.42-2.71=71.87。

3. SKU 3（子訂單C）的分攤金額計算

SKU 3商品總金額：50*2=100；

滿減分攤優惠：100/（55+80+100+60）*20=6.77；

優惠券分攤優惠：100/（55+80+100+60）*10=3.38；

子訂單實付款：100-6.77-3.38=89.85。

4. SKU 4（子訂單D）的分攤金額計算

SKU 4商品總金額：60；

滿減分攤優惠：60/（55+80+100+60）*20=4.06；

優惠券分攤優惠：60/（55+80+100+60）*10=2.03；

子訂單實付款：60-4.06-2.03=53.91。

最終分攤到每個子訂單上的優惠金額，因只截取后兩位小數，所以會存在些許誤差。將只針對SKU 1的滿減單獨進行計算，然后再將每個子訂單的滿減優惠與優惠券分攤計算。

但如果用戶涉及的訂單金額資金過大，還是需要通過人工來處理分攤信息：

• 若訂單內只退部分商品，那優惠券是不會返還的；
• 若退整筆訂單，那優惠券返還至用戶賬號當中，同時使用的虛擬金幣和積分，處理的方式與滿減和優惠券的方式相同；
• 若每個SKU有多個數量，如購買數量為2，但只退1，那最終以分攤到這個SKU上的分攤金額，再進行均攤。

總結：

本篇文章主要講解了，訂單拆分與優惠信息的拆分思路。

筆者描述的訂單拆分不僅僅只是以上這幾種，需要結合自身的業務場景，不同的業務情況，拆分的條件與拆分的邏輯都會有所不用。

同時優惠的分攤計算方式也有多種，只要能將最終的分攤金額合理的分攤到每個子訂單上即可，當然計算方式越簡單越好。

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

題圖來自 Pexels，基于 CC0 協議