參考轉發:
鏈接：https://www.zhihu.com/question/31640837/answer/66374061
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
1、在拆單操作之后，是否需要拆分支付流水？
不需要，而且一般都是用第三方支付，支付流水你也沒得拆。
2、無論是否拆分支付流水，都會涉及到子訂單間的退款，優惠金額調整等問題，那么此時支付流水和退款流水如何設計會比較好？
退款按退款訂單處理，那么會產生獨立的退款流水，退款與原單只做基礎的單號關連。
———————————————————華麗的分割線—————————————————
正題：
1、先說說訂單基本的設計。
訂單設計最少也會包括兩個內容，訂單信息和商品信息。訂單時主表，商品時從表。訂單信息會包括訂單號、金額、購買人等等，商品會記錄訂單號、商品信息、商品數量、商品金額等。這個是最基本的情況，具體我就不細說了。
所謂拆單，我們一般是指拆訂單，不是拆支付流水。一個訂單對應多個商品，需要把其中某個商品或者某幾個商品進行分組，形成子訂單。也就是一次付款對應多個訂單的情況
什么時候才會有拆單的需求呢？
- 便於后期結算。一個訂單包含多個商家的商品，為了便於結算，必須按商家拆單啊。
- 便於后期發貨。一個訂單包含多個倉庫的商品，為了發貨，必須按倉庫拆單啊。
- 訂單合並付款。（這個好像不完全是拆單，只是訂單而已）
所有的合並和拆分都是基於訂單，那么這時候的訂單結構應該需要變成：主訂單、子訂單、商品三個表。
3、關於支付流水
現在的電商系統，支付基本都是用第三方支付，即使會用自家的支付體系（自主研發支付、積分等），也會將訂單和支付分開，收銀員只管收錢，不需要管你買的什么東西，是在哪個櫃台購買的，訂單和支付實際本來就是兩個業務，支付唯一影響的是訂單的付款狀態，我們應該將訂單和支付抽象，不要混在一起，所以支付不需要管具體的拆單，要拆單只需要拆訂單，而不需要拆支付流水。這就回答了第一個問題。
好吧，現在應該都知道了，訂單流水和主訂單關聯即可。一個支付流水對應一個主訂單，其他和支付流水沒有必須的關系。
關於退款，建議最好的方式是，生成“負”訂單。這里的負訂單，不一定強制要求數據是“負”的，只是要求 退款按照訂單的思路去處理，這樣的好處太多了。用了才知道爽。
- 結算數據清晰
- 部分退款實現簡單，不容易出錯
- 訂單結構清晰明了
5、最終的業務形態
用戶購買商品，形成訂單。
同一個商家，形成一個主訂單和一個子訂單
N個商家，形成一個主訂單和N個子訂單
用戶支付
修改主訂單的支付狀態
用戶退款
用戶選擇需要退款的商品，形成負訂單。訂單生成的規則和正常購買訂單的規則一樣，根據商家判斷是否形成多個子訂單。
發貨
同一倉庫同時發貨，則形成一個發貨單
不同倉庫或者不同時間發貨，則形成多個發貨單。
發貨單需要關聯發貨的商品明細，修改商品的發貨狀態。
結算
根據訂單狀態和商家生成結算數據即可，因為你的銷售和退款都是在同一個訂單表，那么直接計就好了，清爽無比。
當然，以上模擬的其實是比較簡單的業務情況，實際的業務情況會更加復雜，但是整體流程都不會出現很大變化，
有時也會有遇到一些奇葩的產品經理的想法，比如：1、根據商品拆訂單
2、強烈要求把退款獨立新的數據表存放
太多的人總是去模仿看到的系統的外表，卻沒有深入去了解別人如此設計的具體原因，看到的系統表現形式和實際的核心功能點未必就是一樣的。