像TB、PD一样的平台有多种店家，因发货地不同则须要拆单。
根据商家拆单比较随意马虎理解，比如你在电商平台上买了二个商品，一个是玩具，一个是图书。图书和衣服基本都是平台的东西，以是你买的这两个东西很可能是两个不同商家的。
当你购物车里面同时买了图书和衣服的时候，只管是你一次付款的，但由于背后是两个不同的商家，以是会把你的这笔订单拆成2个不同的子订单，每个子订单由相应的商家发货。由于不同商家的货都是存在自己商家的仓库里面，以是不可能同时从2个不同的商家发货，这也便是为什么购物车里面要根据不同的商家进行拆单。
品类限定
自营平台本身有多家仓库，用户购买后会从不同的仓库发货。这种情形便是，自营平台内的商品会有品类的限定，每一个品类都会有分外的属性，比如有效期、超大物品、易碎品之类的须要单独包装，这样就不能放在一起，以是须要设计拆单规则。
为什么拆单？
1）为了优化用户体验
用户不才单之后能看到清晰的订单和物流信息。
2）为了平台管理方便
在前期大多数平台的订单系统和支付系统都是分开设计的，像订单系统有多个子订单：订单A，订单B，订单C，当这个订单支付完了之后会合并在一起，传入支付系统，那后者看到的只有一个单号，
3）为了后台的操作灵巧度
所谓拆单，一样平常的是指拆订单。把稳，这里的【拆】不是拆支付流水，为什么?
很大略，一个订单可以对应多个商品；这样的话，就须要把个中某个商品或者某几个商品进行分组，形成子订单，形成了一次付款对应多个订单的情形。
那你就问了，什么场景下才会有拆单？个人有限的履历见告我，无非出于两点：
便于结算，一个订单包含多个商家的商品，为了却算方便；便于发货，一个订单包含多个仓库的商品，为了发货方便。拆单基本流程从图中可以看出，用户在付款后须要平台去判断该订单是否须要拆单，怎么拆，这块要根据自己平台的业务去制订详细的规则。
须要把稳的是，如果用户已经天生了订单但没有付款，这时该订单会在待付款展示。把稳：这时候的订单是不拆的，只有在用户付完款之后才会去判断拆单流程。
怎么拆
之前的退款逻辑是对一个订单内的商品进行依次退款，所可能发生的情形。现在如果进行拆单，就涉及前端显示问题，我们是根据供应商的不同所进行的拆单。前端页面上会显示每一个供应商下的商品订单，也可以看到根据规则拆出来的商品价格。
这里给大家几个问题思考：
根据自身公司的业务须要怎么拆单？
我的订单内如果有的商品发货，有的商品没有发货前端怎么展示？
待发货，待收货，待评价又怎么展示？怎么根据供应商或者商家进行退款？
拆单后的订单也是可以查看详情的，是给用户展示商品原价，还是展示订单拆完每一笔的钱这。这里会涉及两个问题：展示原价时，用户可能会被搞蒙，不知道自己每笔订单分别付了多少钱，但底部会显示实付金额；显示拆单的价格时，用户退款是否可以退显示的商品价钱，这会涉及第一个问题，怎么拆？
订单号，查看物流，确认收货，申请退款所对应商品信息以及层级关系，
这里会涉及后台部分，我们最开始拆单没有拆订单号，而是在一个订单里进行收货，查看物流和确认收货的操作，之后由于一些缘故原由就换掉了。这里须要考虑每一个状态所对应的是后台的哪部分。
写在末了
这一块很繁芜，我在之前的文章中总结过一篇电商的退款逻辑，之后的内容可能会跟上一篇文章有关联。如果大家看完有任何异议的地方可以查看我的上一篇文章，会有些启示，末了，希望大家能负责看也欢迎大家补充。
写了这么多，把好多踩过的坑和涉及到的都写在文章里了。
电商拆单这一块，涉及的地方很多，大多数情形都须要推倒本身的业务重做。以是，在设计这一部分的时候也要额外把稳，否则就要被开拓爸爸们群攻了。
末了，希望正在设计这一块的产品看到这篇文章后能有所启示。
#干系阅读#
做电商，必须知道这些退款逻辑
作者：胡子邯；"大众年夜众号：产品经理的日常思考。
本文由 @胡子邯 原创发布于大家都是产品经理。未经容许，禁止转载
题图来自Unsplash，基于CC0协议
