处理电商订单时，经常会遇到客户同时购买了不同商家的多种商品，此时，电商平台应该如何进行结算？作者展示了此情况下的不同拆单方式及优点，同时也说明了拆单时不同的费用处理方式。一起来看看吧~

在平台型电商业务中，⽤户会有同时购买多样商品的场景出现，因为可以⼀次性完成支付，⽅便快捷。

以双⼗⼀为例，存在⼤量的跨店优惠商品、限时秒杀、限量销售等各种类型的活动，我们通过购物⻋（购物⻋只是⼀个概念，拼多多⽤【我的收藏】完成这⼀功能）完成同时购买多个商品，⼀次完成结算⽀付，既⽅便快捷，⼜能满⾜快速购买多样商品的需求。

支付完成了，接下来就是订单处理的问题了，如果按照上述情况，假设客户在大促期间同时购买了不同商家的商品，要怎么办呢？

比如说目前有A、B，2个商家，他们分别有a、b、c商品（A商家有a商品，单价50元；B商家有b、c商品，单价均为100元）现在客户购买同时购买3种商品各1件。如果按照同订单处理的话，此时订单上同时存在a、b、c商品，分别归属于A、B商家，订单总金额为250元（50+100+100=250元）。

那么在财务层面，对商家进行结算时，有可能会出现过多冻结影响商家现金流的情况。

电商平台对不同的商家通常是进行独立结算的，一般来说在订单确认收货后便可以进行结算，而在这种场景下，因为不同商家的物流不同，确认收货时间可能不一致，此外不同商品是否会发起退款退货的售后流程可能也不一致，如果进入售后，一般会做冻结，不能进行结算工作。

因此，按照一般规则，2个商家的可结算时间会出现不一致的情况（如果遇到售后流程，则时间差距更长，影响更大），这种情况下如果以订单纬度对2个商家进行统一处理，必然导致某一商家被过多冻结，因为非己原因导致的结算延迟情况，可能造成商家对平台不满的情况，影响商家经营，导致商家投诉量上升。

而平台难以给出合理解释，一来很难向商家解释为什么自己的商品结算时间会受到其他商家的影响。二来，冻结金额增多，会影响商家现金流，对部分商家不公平。

此时，唯⼀能够解决问题的⽅法就是对于多商品订单，且商品分别归属于不同商家的订单进行拆单！

一、拆单方式

依照商家归属不同，对商品进⾏分类，同⼀商家的产品为⼀个订单，保证一个订单上只有一个商家的商品，满⾜独⽴结算场景，解决订单归属问题，如此便能够解决上述在财务结算层面遇到的问题。同时注意需要对因拆单行为引起的订单金额的变化（包括商品金额调整、优惠分摊等）做处理。

（一）拆单节点与表现

按照上述的例子，在商品归属于不同商家的场景下，业内的主流处理方式为将拆单节点放在支付成功之后（比如京东、网易严选等），进入【待发货】状态之前。‍

下单时的表现：同一订单

取消支付后的订单展现：还是保持一个订单的状态

支付后，待发货时：订单已经拆分成多个

这样的做法，好处在于：

如果客户在【待支付】状态下取消了支付，后续再支付客户也只需要对一个订单进行操作，在这种状态下的客户体验更好，更加符合用户心智。同时，在【待支付】状态下，客户天然的会比较关心款项问题，一个订单，便于客户在实际支付前进行核算（特别是在有平台红包等跨店优惠的情况下）。主订单可以保留下客户的行为轨迹，既满足了客户的操作习惯（一次性支付），也能满足商家发货的拆单需求（不同商家分开发货）。

支付后的订单表现：拆单完成有2个订单，发货或者售后缓解均可开处理

如果不在这个节点拆单，又会怎么样呢？

如果节点往后移，支付成功后将进入待发货的物流环节，如果在该节点及之后进行拆单，那么就会出现同一订单进入不同商家的物流环节的情况，物流环节开始多为商家各自自主进行，因此可能导致订单上不同商品实际的物流情况进展不一，售后情况也极有可能不同步。

若不及时拆单，会导致系统处理逻辑上的复杂、订单展现上的复杂，可能导致商家混淆订单，发货工作、售后退款退货工作出错。

在进入物流环节前完成拆单工作，可以规避一个订单关联多个商家物流情况，多商家之间完全独立，售后也可以完全独立，不需要做数据上的关联，简洁高效，也降低了复杂度，降低了商家出错的概率。

如果节点往前移，在支付成功之前进行拆单可以吗？答案是可以，例如拼多多，将拆单节点放在了下单之后，支付之前，C端表现形式是若中途取消支付，订单列表内可以看到2个订单，但是重新发起支付时，订单会以【合并支付订单】的形式存在，需要一起支付。

下单时的表现：同一订单（一起支付）

取消支付后的订单展现：订单拆分

重新发起支付：拆分后的订单仍然需要合并支付

而拼多多之所以采取这样的方式，原因可能在于：

相比于支付之后拆单的逻辑，在下单后支付前拆单，订单的逻辑更加清晰、独立，不与其他商户订单产生关联，商家端订单的数据处理上，更加容易。如果支持单独支付，那么客户不仅需要支付多次，客户体验较差，而且有些跨店使用的优惠等可能存在逻辑漏洞（因为存在跨店优惠，因此一起支付是比较好的方式，防止出现一个支付了，另一个没有支付的情况，不满足优惠条件而享受优惠，容易让人钻漏洞给平台造成损失），因此在重新发起支付时，拼多多用了合并支付的方式，以主订单的维度进行支付。

因此对接拆单节点的问题，答案是，在物流环节开始前必须完成拆单工作（即完成支付之后），但是可以按照各自的需要，考虑将订单拆单节点放到支付之前。

（二）拆单时的费用处理

拆单时还有⼀件⾮常重要的事情是需要对订单⾦额进⾏分摊处理，特别是在遇到双⼗⼀等⼤型促销活动的情况下，叠加使⽤了不同的优惠券、、红包、折扣、积分等，造成⾦额计算逻辑⽐较复杂的情况，明确分摊逻辑以及优惠使用次序、使用范围尤为重要。

优惠、运费分摊后不仅仅能满足拆单需求，后续如果发生售后情况，需要进行部分商品的退款退货处理，拆单的做法可以令子订单的退款与结算工作都会变得相对容易，因为前期相关费用数据均已准备妥当，售后订单可以直接使用，不需要额外对于交易单的数据做计算，减少出错可能性。‍

在进行具体分摊计算前，我们需要思考不同的影响因素对分摊这件事情产生的影响，主要需要考虑的因素是否同类型优惠？

优惠是否可以叠加，有不同情况，可以组合出4种主要场景，即：

同类型优惠，可叠加同类型优惠，不可叠加不同类型优惠，可叠加不同类型优惠，不可叠加

同类型优惠，可叠加：比如新人满减优惠券和店铺满减优惠券，是同类型优惠，大多数情况会设置为可叠加使用，用于促进新用户的交易。这种情况下因为优惠券类型是相同的，因此分摊计算方式也是类似的（比如说上述的新人满减优惠券和店铺满减优惠券，本质上都是满减优惠，满多少优惠多少，分摊优惠的计算公式统一为：

单一优惠下商品分摊优惠=该商品金额/所有商品金额之和（即该商品金额占比）· 享受优惠金额。

但是因为优惠券可叠加，因此每件商品的分摊优惠，要把多张优惠券考虑进去，不要遗漏。

假设现在有不同店铺商品a，单价100元，商品b，单价200元，新人优惠券X满100-10，平台优惠券Y满300-60，优惠券商品a、b均可用，2张优惠券可以叠加。

则使用优惠券X的分摊计算公式为：

优惠券X分摊到商品a优惠=商品a金额/所有商品金额之和（商品a金额+商品b金额）·享受优惠金额X= 100/（100+200）· 10 =3.33元

优惠券X分摊到商品b优惠=商品a金额/所有商品金额之和（商品a金额+商品b金额）·享受优惠金额X= 200/（100+200）· 10 =6.67元

使用优惠券Y的分摊计算公式为：

优惠券Y分摊到商品a优惠=商品a金额/所有商品金额之和（商品a金额+商品b金额）·享受优惠金额Y = 100/（100+200）· 60=20元

优惠券Y分摊到商品b的优惠=商品b金额/所有商品金额之和（商品a金额+商品b金额）·享受优惠金额Y = 200/（100+200）· 60=40元

从上述例子可以发现，同类型的优惠，计算公式往往是类似的。

同时因为优惠可叠加，因此计算商品a的分摊优惠时，需要同时考虑优惠券X、优惠券Y分别产生的影响。因此：

商品a优惠分摊总金额=优惠券X分摊到商品a的优惠+优惠券Y分摊到商品a优惠=3.33+20=23.33元；

商品b优惠分摊总金额=优惠券X分摊到商品b的优惠+优惠券Y分摊到商品b优惠=6.67+40=46.67元。

除此之外，另外几种场景分别为：

同类型优惠，不可叠加：比如同一店铺的不同的满减优惠券（满100-10，满200-30）通常来说是同类型优惠券，但是不可叠加使用，只能选择其中一种优惠力度大的使用。这种情况下，相对于上面的同类型优惠可叠加的情况，分摊方式比较简单，因为优惠不可叠加，每样商品涉及到的优惠就只有一样，计算某件商品分摊优惠的时候不需要考虑多种优惠。不同类型优惠，可叠加：比如包邮优惠和店铺满减优惠券是不同类型的优惠，但是通常来说可以叠加使用。这种情况下除了可叠加优惠啊，计算分摊的时候需要计算多样优惠对于商品的影响外，在具体计算的时候，因为优惠的类型不同，因此具体的计算公式也是不同的（比如满减优惠的分摊优惠计算公式为：该商品金额/所有商品金额之和（该商品金额占比）·享受优惠金额，而包邮优惠怎是邮费统一为0，不同类型的优惠，计算公式很可能是不同的）。不同类型优惠，不可叠加：这部分就比较多了，比如说秒杀活动和限时折扣，是不同类型的优惠，但是通常来说不可叠加（这种一般来说优惠力度比较很大，叠加没有必要）。这种情况下，因为优惠的类型不同，因此具体的计算公式也是不同的。同时优惠券不用叠加，因此计算某件商品分摊优惠的时候不需要考虑多种优惠。

概括来说，是否同类型优惠，影响的是分摊优惠的具体计算公式，而是否可叠加决定了在计算某件商品分摊优惠的时候是否需要考虑多种优惠的叠加影响，不要遗漏。

本文由 @Emma 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。