订单合并付款之后，是否需要拆分支付流水？

参考转发:

作者：李欢
链接：https://www.zhihu.com/question/31640837/answer/66374061
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

1、在拆单操作之后，是否需要拆分支付流水？
不需要，而且一般都是用第三方支付，支付流水你也没得拆。
2、无论是否拆分支付流水，都会涉及到子订单间的退款，优惠金额调整等问题，那么此时支付流水和退款流水如何设计会比较好？
退款按退款订单处理，那么会产生独立的退款流水，退款与原单只做基础的单号关连。

———————————————————华丽的分割线—————————————————
正题：
1、先说说订单基本的设计。
订单设计最少也会包括两个内容，订单信息和商品信息。订单时主表，商品时从表。订单信息会包括订单号、金额、购买人等等，商品会记录订单号、商品信息、商品数量、商品金额等。这个是最基本的情况，具体我就不细说了。

2、再说说拆单。
所谓拆单，我们一般是指拆订单，不是拆支付流水。一个订单对应多个商品，需要把其中某个商品或者某几个商品进行分组，形成子订单。也就是一次付款对应多个订单的情况
什么时候才会有拆单的需求呢？

• 便于后期结算。一个订单包含多个商家的商品，为了便于结算，必须按商家拆单啊。
• 便于后期发货。一个订单包含多个仓库的商品，为了发货，必须按仓库拆单啊。
• 订单合并付款。（这个好像不完全是拆单，只是订单而已）

所有的合并和拆分都是基于订单，那么这时候的订单结构应该需要变成：主订单、子订单、商品三个表。

3、关于支付流水
现在的电商系统，支付基本都是用第三方支付，即使会用自家的支付体系（自主研发支付、积分等），也会将订单和支付分开，收银员只管收钱，不需要管你买的什么东西，是在哪个柜台购买的，订单和支付实际本来就是两个业务，支付唯一影响的是订单的付款状态，我们应该将订单和支付抽象，不要混在一起，所以支付不需要管具体的拆单，要拆单只需要拆订单，而不需要拆支付流水。这就回答了第一个问题。
好吧，现在应该都知道了，订单流水和主订单关联即可。一个支付流水对应一个主订单，其他和支付流水没有必须的关系。

4、关于退款
关于退款，建议最好的方式是，生成“负”订单。这里的负订单，不一定强制要求数据是“负”的，只是要求退款按照订单的思路去处理，这样的好处太多了。用了才知道爽。

• 结算数据清晰
• 部分退款实现简单，不容易出错
• 订单结构清晰明了

5、最终的业务形态

用户购买商品，形成订单。
同一个商家，形成一个主订单和一个子订单
N个商家，形成一个主订单和N个子订单

用户支付
修改主订单的支付状态

用户退款
用户选择需要退款的商品，形成负订单。订单生成的规则和正常购买订单的规则一样，根据商家判断是否形成多个子订单。

发货
同一仓库同时发货，则形成一个发货单
不同仓库或者不同时间发货，则形成多个发货单。
发货单需要关联发货的商品明细，修改商品的发货状态。

结算
根据订单状态和商家生成结算数据即可，因为你的销售和退款都是在同一个订单表，那么直接计就好了，清爽无比。

当然，以上模拟的其实是比较简单的业务情况，实际的业务情况会更加复杂，但是整体流程都不会出现很大变化，

有时也会有遇到一些奇葩的产品经理的想法，比如：
1、根据商品拆订单
2、强烈要求把退款独立新的数据表存放
太多的人总是去模仿看到的系统的外表，却没有深入去了解别人如此设计的具体原因，看到的系统表现形式和实际的核心功能点未必就是一样的。