訂單合併付款以後，是否須要拆分支付流水？

一、在拆單操做以後，是否須要拆分支付流水？
不須要，並且通常都是用第三方支付，支付流水你也沒得拆。
二、不管是否拆分支付流水，都會涉及到子訂單間的退款，優惠金額調整等問題，那麼此時支付流水和退款流水如何設計會比較好？
退款按退款訂單處理，那麼會產生獨立的退款流水，退款與原單隻作基礎的單號關連。

———————————————————華麗的分割線—————————————————
正題：
一、先說說訂單基本的設計。
訂單設計最少也會包括兩個內容，訂單信息和商品信息。訂單時主表，商品時從表。訂單信息會包括訂單號、金額、購買人等等，商品會記錄訂單號、商品信息、商品數量、商品金額等。這個是最基本的狀況，具體我就不細說了。

二、再說說拆單。
所謂拆單，咱們通常是指拆訂單，不是拆支付流水。一個訂單對應多個商品，須要把其中某個商品或者某幾個商品進行分組，造成子訂單。也就是一次付款對應多個訂單的狀況
何時纔會有拆單的需求呢？

• 便於後期結算。一個訂單包含多個商家的商品，爲了便於結算，必須按商家拆單啊。
• 便於後期發貨。一個訂單包含多個倉庫的商品，爲了發貨，必須按倉庫拆單啊。
• 訂單合併付款。（這個好像不徹底是拆單，只是訂單而已）

全部的合併和拆分都是基於訂單，那麼這時候的訂單結構應該須要變成：主訂單、子訂單、商品三個表。

三、關於支付流水
如今的電商系統，支付基本都是用第三方支付，即便會用自家的支付體系（自主研發支付、積分等），也會將訂單和支付分開，收銀員只管收錢，不須要管你買的什麼東西，是在哪一個櫃檯購買的，訂單和支付實際原本就是兩個業務，支付惟一影響的是訂單的付款狀態，咱們應該將訂單和支付抽象，不要混在一塊兒，因此支付不須要管具體的拆單，要拆單隻須要拆訂單，而不須要拆支付流水。這就回答了第一個問題。
好吧，如今應該都知道了，訂單流水和主訂單關聯便可。一個支付流水對應一個主訂單，其餘和支付流水沒有必須的關係。

四、關於退款
關於退款，建議最好的方式是，生成「負」訂單。這裏的負訂單，不必定強制要求數據是「負」的，只是要求退款按照訂單的思路去處理，這樣的好處太多了。用了才知道爽。

• 結算數據清晰
• 部分退款實現簡單，不容易出錯
• 訂單結構清晰明瞭

 

五、最終的業務形態

用戶購買商品，造成訂單。
同一個商家，造成一個主訂單和一個子訂單
N個商家，造成一個主訂單和N個子訂單

用戶支付
修改主訂單的支付狀態

用戶退款
用戶選擇須要退款的商品，造成負訂單。訂單生成的規則和正常購買訂單的規則同樣，根據商家判斷是否造成多個子訂單。

發貨
同一倉庫同時發貨，則造成一個發貨單
不一樣倉庫或者不一樣時間發貨，則造成多個發貨單。
發貨單須要關聯發貨的商品明細，修改商品的發貨狀態。

結算
根據訂單狀態和商家生成結算數據便可，由於你的銷售和退款都是在同一個訂單表，那麼直接計就行了，清爽無比。

固然，以上模擬的實際上是比較簡單的業務狀況，實際的業務狀況會更加複雜，可是總體流程都不會出現很大變化，

有時也會有遇到一些奇葩的產品經理的想法，好比：一、根據商品拆訂單二、強烈要求把退款獨立新的數據表存放太多的人老是去模仿看到的系統的外表，卻沒有深刻去了解別人如此設計的具體緣由，看到的系統表現形式和實際的核心功能點未必就是同樣的。