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

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

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

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

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

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

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

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

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

5、最终的业务形态

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

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

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

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

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

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

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