起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識OMS訂單拆單的流程中，要做哪些工作？
編輯導讀：訂單拆單的場景并不少見，可這其中的原由與底層邏輯你弄明白了嗎？看似微小的系統拆單，實際與用戶體驗直接關聯。本文作者結合行業內的觀察，總結出了關于訂單管理中的拆單整體邏輯，從訂單拆單的基礎概念出發，聯系實際場景列舉了相關可能性及結果。推薦相關領域的從業者閱讀學習～
一、什么是拆單
在網上購買商品下單成功后，過一段時間再次瀏覽時，有時會發現你的訂單會變成兩個或多個，這就是系統做了拆單而導致的。
拆單，就是將一個大的訂單依據某些規則的集合，將其分解成兩個或多個子訂單的過程，原來的訂單稱之為父訂單。
二、拆單的重要性
通常我們所說的拆單一般情況下是指用戶的銷售訂單，但在實際業務中，拆單情況隨處可見，如采購訂單的拆分、調撥單的拆分等等。本篇后續都是以銷售訂單的拆單講述的，請知悉！
在互聯網電商系統中銷售訂單是與C端用戶關聯最緊密的，單據量是最大的，是影響用戶體驗的，且拆單的規則相對來說是比較復雜的。
折單要求數據準確、及時，因為拆單后的子訂單是需要流入到倉儲進行生產作業的，它會進行揀貨、出庫、配送等一系統的流程，它也是后續財務系統對賬或結算、數據分析的重要數據來源。
三、拆單的場景
用戶在APP，電商等平臺下單后，由于商品的庫存數量不滿足，可能在前端進行拆單，即用戶自己選擇是否需要拆單，可以按最快送達或最小拆單的規則進行。
現在很少有會出現庫存不足的情況，就是拆單系統的功勞了，很多商家為了提升客戶體驗，對于商品可以多倉發貨時。因為單倉缺貨而需要拆單時，由用戶來選擇決定是否購買或者是由系統判定可以拆單的情況下而進行的自動拆單，這應該也是為了提高轉化率的一種方式。
還有一種場景，訂單涉及多商家，需要單獨付款的情況下，前端會直接進行拆單，但現在基本上都是合單支付了，因為這種拆單會使用戶體驗降低。
此外，有的商家既賣國內商品，也賣海淘商品，如果都混在一塊，那么在支付前是需要進行拆單的，因為海淘商品要求用戶的身份認證等信息的檢驗。
在多數情況下，都是用戶下單完成后，由系統進行在后臺進行拆單，拆單是要結合公司業務場景去考慮的。
四、用戶購買涉及幾種拆單
拆單除了以上幾種場景，對于用戶下單時系統上還會有什么操作嗎？
有一種情況即用戶下單時系統要根據用戶選擇的收貨地址、商品等信息，判斷是否有庫存，訂單應該歸屬哪個倉庫，是否可以購買等，這個服務嚴格來講應該歸屬于商品庫存服務，但是也可以將其稱為預拆單。
預拆單一般是調用一定范圍內的倉儲服務進行庫存的判斷，同時還要根據促銷活動進行一些優惠計算，所有的這些都需要前端系統在處理時對訂單商品進行一些標識，以便當用戶支付成功后，訂單流轉到OMS系統進行物理拆單。
前端用戶下單成功后，訂單經過OMS的拉單服務快速流轉到訂單中心，便開始訂單的再生成過程，訂單拆分后的子訂單可能會展示給用戶，也可能不展示給客戶，在退貨時由客戶統一退到一個倉庫方便客戶進行退貨，子訂單會展示到客戶原始訂單上進行展示，便于用戶跟蹤和查看。
所以在從用戶角度來看，一種是可以直接看到結果的拆單和一種無感知的預拆單過程。
五、拆單的時點與地點
預拆單是伴隨著購物流程進行的，這里不多討論，因為這個究竟是否屬于拆單也是要看我們如何定義。正常情況下用戶選購商品完成后，系統不會拆單，因為用戶有可能取消訂單或未支付成功。
拆單的時點是要在?“訂單支付成功”?后進行，且需要前端訂單已經流轉到后端生產庫，在訂單中心進行處理。
在前面有一種場景，如果購物中心不能合并支付時，在購物車中便拆分為幾個訂單，這時的拆單可以定義為一次拆單，也可以歸屬于購物流程，因為用戶不提交就不會生成訂單號，不會保存各個訂單的數據。
在用戶支付成功后，各個訂單同樣是要向后臺流轉，經過拆單服務的處理才可以繼續進行下面的生產。
在前面討論拆單場景時提到一種缺貨拆單，這種場景的拆單是在用戶下單支付成功后，訂單有可能已經拆分為不同的子訂單，但因某種原因倉庫無貨而導致的拆單。
這時拆單的時點是靈活的，一般是在客服系統中，根據用戶的反饋確定是否拆單的。
缺貨是影響用戶體驗的，但是缺貨是始終客觀存在的。
六、拆單分幾級
從上圖看，拆單應該為三級，即用戶創建的訂單為父訂單，然后經過拆單服務正常的分為多個子訂單為第二級，后續因為缺貨等原因子訂單再次拆分為子（孫）訂單。
在數據設計上，一般情況子訂單與父訂單的關聯都通過ParentID來進行關聯，但三級以上時，涉及原始訂單的查詢較麻煩。
具體看數據結構如何設計了，可以再增加一個原始訂單號來記錄最初的訂單號，方便統計查詢等，負責拆單服務的同學可以詳細討論下。
為了避免訂單的復雜度及系統的查詢、統計、分析等數據處理的難度，訂單最好最多到三級，不宜過多。
七、拆單狀態
以前專門梳理過訂單狀態的文章，詳見《訂單信息與狀態流轉看這個應該足夠了!》,在拆單過程中也涉及訂單狀態的變換。
- 當父訂單拆分為子訂單后，子訂單生效，父訂單應該置為無效。
- 子訂單或父訂單經過缺貨拆單后，原訂單狀態是無效還是其它？
- 訂單拆單后狀態應該置為“待下發”即需要通過下發服務，將訂單推送給倉庫發貨。
- 如果訂單已經下發到倉庫后需要缺貨拆單，單據狀態應保留原狀態。
這些都屬于細節，但不得不考慮，因為訂單的狀態涉及到其他業務系統的計算和統計。
如：財務系統在應付報表時是根據支付訂單進行統計和對賬的，如果訂單狀態是無效的，那么系統如何獲取此部分數據。
BI有些統計分析是按狀態和訂單數量等進行統計的，如客單價、有效訂單數等等。
所以針對拆單而導致的訂單狀態是否應該區分原有的訂單狀態分別標識，是需要綜合考慮的。
八、拆單原則
拆單的原因我們已經清楚，拆單的目的是為了保證履單，拆單的原則是什么？
- 首先是最小拆單原則，即能拆兩單，不能拆成三單，因為多拆一單不僅是單據數量的增加，它會增加系統的復雜度，降低用戶體驗，加大倉庫作業量，增加運費費用等。
- 最快送達原則，拆出的子訂單要快速生產，快速送達，這個是增加用戶體驗的最好辦法。但是快速送達，依賴于倉儲物流的布局，這個在多倉可以發送到一個城市時尤為重要。
一般情況下，拆單要遵循這兩條原則，同時我們也看到拆單服務，是依賴于基礎信息配置的，電商系統最復雜的是很多地方都有關聯。不過現在也有很多根據最低價格原則，或者是最小拆分原則等，這個需要根據實際業務對應不同的實際場景。
九、拆單規則
拆單的規則因每個公司的業務不同而不同，這里羅列一些常見的規則供參考。
1. 不同商家的訂單需要進行拆分
這個主要應用于平臺型的電商，一般情況用戶購買商品都進入不同的店鋪，創建的訂單也是歸屬這個商家的。但有的平臺采用合單支付，即用戶選購不同商家的商品，但支付是一次的。
這個和淘寶有些不同，淘寶上每個商家的收款賬號是不同的，所以不能一次支付，但平臺商家是平臺代收款的，所以可以一次支付后再拆單分攤金額。
2. 不同倉或不同供應商的商品需要進行拆單
倉庫不同訂單需要分開，對于不同的供應商訂單主要是指由供應商直接發貨的訂單即商品不存儲在倉庫，由供應商直送到用戶，這個和平臺商家類似。但是區別是簽署的合同不同，一個是購銷合同，一個是傭金扣點合同，細節不展開了，有興趣可以留言交流。
3. 商品類型不同需要拆單
一般區分奢侈品或有特殊要求的商品，這個需要業務根據商品要求進行設置。因為商品要求不同，后續在物流環節采用的物流產品類型也不同，物流費用也不同。這部分也可以根據商品信息，在倉儲進行處理，但最后在上位能夠提前區分。
4. 商品溫控屬性不同要進行拆單
此部分一般是指生鮮電商而言，同一個倉庫有常溫倉、冷藏倉、冷凍倉，存儲著不同的商品，商品的揀貨、包裝等都有不同的要求，所以需要進行拆單。
5. 大件商品拆單
大件商品與普通商品不同，它在倉庫的存儲位置、揀貨方式、包裝、運輸都有所區別，所以大件商品需要每一件都拆單，大件商品一般遵循最快送達，不需要最少拆單原因的限制。
6. 根據庫存拆單
這個是針對缺貨商品進行的拆單，即有庫存的一單，無庫存的一單，如果是二級訂單，則父訂單相同，子訂單衍生出子訂單，子訂單1的過程。
7. 線下門店商品不拆單
如果是線下門店購買商品，則不需要拆單。
8. 組合商品不能拆單
在促銷活動中，有時會有一些大禮包等商品的組合銷售，即A,B,C等商品經過倉庫的組合包裝后出庫，所以針對此類商品不能拆單。
在拆單服務中需要調用物料單信息，進行判斷，具體的要看系統如何設計了。
拆單的規則很多，在系統處理時，要依賴于規則設置的優先級來進行。
十、拆單算法
1. 稀缺商品算法
找所有商品在所有庫房最稀缺的商品，獲取該商品的階數。
2. 降階
找稀缺商品的都需要倉庫組合，這些倉庫是必須發貨的，把這些倉庫計入發貨列表，這樣就降階了，剩余倉庫再計算組合，減少運算數量。
3. 抽屜原理算法
找第一階的倉庫列表（發貨量最大的倉庫），這個庫房的庫存是必須要發的，然后再找次發貨量最大的倉庫，以此類推，用于后面的組合計算。
4. 找組合
按照倉庫順序逐漸增加倉庫個數找組合。
算法也只是拆單過程中的一個路徑參考，且算法依賴于拆單的規則而制定，無論如何要保證拆單的結果準確，拆單的速度要快。
十一、拆單服務兩步重要工作
以上一直在討論拆單是由1變2，由2變4的一些內容，在具體的拆單服務系統中要考慮哪些內容，又有哪些工作？
- 前面所說的都應該在設計時考慮，而且最重要的是要依賴規則進行設計，數據的流轉，時序等等。
- 金額分攤是拆單中最重要的一部分工作，也是最復雜的。
父訂單的拆分，商品的重新組合，生成新的訂單是第一步，第二步就是要將父訂單的金額合理的，正確的分攤到各個子訂單上。
訂單一般分為訂單主表和訂單商品表、訂單支付明細表和訂單活動表。
訂單金額有幾個主要的部分：訂單商品金額、折扣金額、禮品卡支付金額、積分支付金額、優惠券支付金額、訂單支付金額等幾個部分。
運費是訂單表中一個特殊字段，運費如何分攤是要特殊考慮的，一般情況是按金額占比進行。所以生成的子訂單中各部分金額，也要保證與父訂單金額一致。
訂單商品表、支付明細表、活動表屬于明細信息，要根據原始訂單明細表的數據和標識進行計算分攤。
子訂單的金額要保證橫向、縱向都正確才行，橫向是指子單的合與父單金額一致，縱向是指子單訂單主表與明細表金額一致。
此外，在金額分攤計算過程有一項重要規則不可避免，即開票金額的考慮。
這部分金額的分攤與公司繳稅息息相關，單據與發票要一致，要考慮商品信息、活動規則等等，非常復雜。
有的拆單服務將金額分攤獨立出來，以降低對拆單的影響，提高訂單流轉速度。
十二、拆單的速度要求
由于拆單后訂單才會下發到倉儲或商家進行生產，所以對于速度要求就是快。
在系統設計時可以依據規則等綜合考慮，多線程是最常用的方法，但多線程需要考慮資源競爭和安全性。一般情況，如果下單后已經確定了倉庫，那么可以按倉庫啟動多個服務，這樣可以避免程序的難度。
對于拆單和下發在系統上也要有數據監控，不能出現積壓的情況。如果拆單有異常時，在定時任務中，很多情況都是依賴一個信息字段的狀態來進行循環處理，在服務中要有容錯處理，不能一直停滯不前。
十三、拆單的影響
什么是拆單？為什么拆單？如何拆單？前面說了很多，但對于拆單有什么影響呢？
先說一個場景，公司搞促銷活動，買A贈B，但A與B商品的溫控屬性不同，所以用戶下單后一定會拆單。
拆單后倉儲揀貨、發貨是根據子訂單進行的，很有可能贈品B先發貨了，A后發貨。用戶先收到B簽收了，然后A進行拒收或取消。此時，如果在拒收或取消A時不判斷關聯子訂單，那么公司就會損失B。
如果判斷關聯子訂單的狀態，那么系統的復雜度將會非常之大，因為實際場景中一個父單拆為多單時是很常見的。
拆單后，子訂單數量增加，對于客單價、統計分析等報表需要考慮其影響，維度和統計口徑不同，數據結果必然不同，從而會影響到經營分析及決策。
影響，對于不同的業務有不同的理解，作為產品研發應該在拆單設計時還是需要要將利害與業務說清楚，尤其是運營人員(活動方面重點考慮），雖然這屬于一個后臺服務。
十四、總結
拆單是復雜的，合理的拆單會加快訂單的流轉，友好的用戶體驗，過度拆單則會產生冗余的數據，增加訂單的復雜關系，統計、計算、售后等各個環節。
本文由 @梁鳳財 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
正常情況下，后臺都是會顯示子訂單狀態的，只有前臺沒有顯示子訂單狀態，退款的時候，關聯訂單肯定是要一起退的。子訂單沒有完成，為什么父訂單狀態會變更？這個是有邏輯悖論的
顯示邏輯有兩種，第一種是顯示最新的子訂單邏輯，第二種是全部子訂單完成后才顯示訂單完成，這個得根據頁面的顯示去設計，如果頁面上直接顯示了子訂單，主訂單自作關聯用，那么主訂單則不需要顯示進度，只顯示子訂單的進度即可
如果父訂單含多個商品，且因某個商品在默認倉庫的庫存不足而拆單的話，運費應該在什么時候計算呢？是在生成父訂單的時候計算運費（按照默認倉庫計算），還是在拆分子訂單（不同倉庫）后計算運費呢？
根據業務的實際情況去考慮，這個需要跟實際業務人員，去公司考察，原來是先計算運費再退還是根據實際庫存扣減運費，還是在頁面顯示庫存充足時候運費，但是在實際發生的時候顯示一口價的運費
對訂單的管理和控制，合理安排運送計劃、有效降低庫存。
網上購物時的拆單竟是門大學問，拆單也是因為受到了優惠情況、庫存、身份認證等信息的檢驗等情況的影響，可以說是具體問題具體分析
對