OMS订单拆单的流程中要做哪些工作( 二 ) _淘宝为什么不能一次结算

五、拆单的时点与地点预拆单是伴随着购物流程进行的，这里不多讨论，因为这个究竟是否属于拆单也是要看我们如何定义。正常情况下用户选购商品完成后，系统不会拆单，因为用户有可能取消订单或未支付成功。
拆单的时点是要在 “订单支付成功”后进行，且需要前端订单已经流转到后端生产库，在订单中心进行处理。
在前面有一种场景，如果购物中心不能合并支付时，在购物车中便拆分为几个订单，这时的拆单可以定义为一次拆单，也可以归属于购物流程，因为用户不提交就不会生成订单号，不会保存各个订单的数据。
在用户支付成功后，各个订单同样是要向后台流转，经过拆单服务的处理才可以继续进行下面的生产。
在前面讨论拆单场景时提到一种缺货拆单，这种场景的拆单是在用户下单支付成功后，订单有可能已经拆分为不同的子订单，但因某种原因仓库无货而导致的拆单。
这时拆单的时点是灵活的，一般是在客服系统中，根据用户的反馈确定是否拆单的。
缺货是影响用户体验的，但是缺货是始终客观存在的。
六、拆单分几级从上图看，拆单应该为三级，即用户创建的订单为父订单，然后经过拆单服务正常的分为多个子订单为第二级，后续因为缺货等原因子订单再次拆分为子（孙）订单。
在数据设计上，一般情况子订单与父订单的关联都通过ParentID来进行关联，但三级以上时，涉及原始订单的查询较麻烦。
具体看数据结构如何设计了，可以再增加一个原始订单号来记录最初的订单号，方便统计查询等，负责拆单服务的同学可以详细讨论下。
为了避免订单的复杂度及系统的查询、统计、分析等数据处理的难度，订单最好最多到三级，不宜过多。
七、拆单状态以前专门梳理过订单状态的文章，详见《订单信息与状态流转看这个应该足够了!》,在拆单过程中也涉及订单状态的变换。

文章插图
当父订单拆分为子订单后，子订单生效，父订单应该置为无效。子订单或父订单经过缺货拆单后，原订单状态是无效还是其它？订单拆单后状态应该置为“待下发”即需要通过下发服务，将订单推送给仓库发货。如果订单已经下发到仓库后需要缺货拆单，单据状态应保留原状态。这些都属于细节，但不得不考虑，因为订单的状态涉及到其他业务系统的计算和统计。
如：财务系统在应付报表时是根据支付订单进行统计和对账的，如果订单状态是无效的，那么系统如何获取此部分数据。
BI有些统计分析是按状态和订单数量等进行统计的，如客单价、有效订单数等等。
所以针对拆单而导致的订单状态是否应该区分原有的订单状态分别标识，是需要综合考虑的。
八、拆单原则拆单的原因我们已经清楚，拆单的目的是为了保证履单，拆单的原则是什么？
首先是最小拆单原则，即能拆两单，不能拆成三单，因为多拆一单不仅是单据数量的增加，它会增加系统的复杂度，降低用户体验，加大仓库作业量，增加运费费用等。最快送达原则，拆出的子订单要快速生产，快速送达，这个是增加用户体验的最好办法。但是快速送达，依赖于仓储物流的布局，这个在多仓可以发送到一个城市时尤为重要。

文章插图
一般情况下，拆单要遵循这两条原则，同时我们也看到拆单服务，是依赖于基础信息配置的，电商系统最复杂的是很多地方都有关联。不过现在也有很多根据最低价格原则，或者是最小拆分原则等，这个需要根据实际业务对应不同的实际场景。