配送流程架构图（制定配送计划的流程） - 原点资讯

那么在配送单创建时，待下达、已创建、已分配骑手等各个状态节点，都有可能发生顾客的退货申请。此时我们如果继续呼叫配送，就会出现以下问题。

1）顾客部分退货申请通过了，但是骑手仍然将所有的货物都配送到顾客手中。此时：

那么，店员只能将货物报损，造成商家损失。

2）顾客全部退货申请通过了，但是配送费已经结算给承运商了，造成这笔订单无收入，但是产生了配送费用。如：

那么从企业应收的角度来看，我们必须保证货物不超发，同时杜绝无效配送费支出，以减少对企业营收的影响。但是在实际设计过程中，我们需要权衡的因素很多。那么我们分场景看一下，不同状态节点截停逻辑的设计权衡。

1. 创建承运单时

检查是否有未处理退单，如果有，则不生成配送单，并通过强制通知功能通知相关人员处理，见文章《我对B端通知提醒功能的设计思考 | 人人都是产品经理 (woshipm.com)》。处理完成后，正常呼叫创建承运单。

当然，这个逻辑受到了业务方很大的挑战，O2O业务与电商业务不同，履约时效性非常强。那么即时通过强制通知等强提醒的手段，要求相关人员及时处理退单，仍然可能出现拉长履约时间进而导致客诉的场景出现。

那么有客户就认为：履约时效性高是客户希望给顾客展示的企业价值取向，这个的价值大于由此带来的损失。那么对于SaaS来讲，也应该尊重客户的选择，并可以通过配置的方法来实现不同客户的价值诉求，可参考文章《我对B端系统配置功能的设计思考 | 人人都是产品经理 (woshipm.com)》进行配置的设计；

此时OMS正在尝试呼叫承运商，顾客申请退货，此时应将配送取消，等待退单审核完成后，根据是否需要继续配送，来决定是否是否重新呼叫配送。此逻辑仍然与创建承运单时截停的逻辑一样，被客户以相同的方式挑战。故也需要进行配置；

此时在承运商侧下单成功，顾客申请退货，但需要区分不同的承运商的政策：

顺丰同城：由于发单成功就扣减运费，故系统自动拒绝顾客退货申请，或建议店员手动拒绝顾客退货申请，此时不自动取消配送。如果店员同意退货，那么会有两种情况：

部分退申请：继续配送；
整单退申请：OMS调用接口取消配送，运费损失由商家承担。大部分商户来讲，仍然期望可以由店员联系用户后，手动确定是否同意退货，出发点仍然是企业的价值取向或经营策略，避免不必要的投诉和差评，而非一味的避免直接营收损失。

此时承运商已经分配骑手，骑手到店取货，顾客申请退货。

骑手取货的过程，实际是物权移交的过程，OMS系统要在这个时机，实际在ERP系统中扣减库存，增加收入。

这个时机也是最后一次店员有机会避免货物超发的时机，因为在承运单生成前后发生的退货申请，店员都有可能由于种种原因，没有处理，如果在骑手取货交接货物这一流程中，如果不查看是否有未处理的退单，就会造成货物的超发或者无效的配送。

电商业务由于履约时效性没有O2O业务时效性这么强，仓库发货作业也更加严谨，所以通常在出库时是需要仓库人员手工复核的，但是O2O业务，门店发货的场景下，我们有几种方式来应对：

推进店员交接货物时，复核一下是否有未处理的退单，将已退货的商品捡出。这种方式实际增加了店员的工作量，推行实际是比较困难的。
骑手已分配，运费已确认结算给承运商了，此时退单统统自动拒绝。部分客户仍然会因为上文中的原因挑战此逻辑。
承认这种场景的存在，并且承担相应损失：即时从逻辑推演来说，这是最差的方案，但是如果考虑到其他方案店员的工作成本、方案推行成本，潜在的被差评的成本，在退单量较小的情况下，反而是此方案的成本和损失是最小的。

骑手已经正在配送了，系统自动拒绝顾客退货申请，或建议店员手动拒绝顾客退货申请。与上文一样，要支持不同的客户不同的配置。

七、发单时机的逻辑设计

那么接下来要理清楚的一个问题，就是在各个配送场景下，什么时机发单给承运商。

配送流程架构图,制定配送计划的流程(9)

八、详细产品设计

接下来我们进行详细的产品设计：

配送流程架构图,制定配送计划的流程(10)

配送流程架构图,制定配送计划的流程(11)

商家在呼叫第三方物流时，总会出现预设的承运商都无法配送的场景，那么就需要一个保底机制，一般有两种方法：

一般有两种方式：

按照价格由低到高呼叫：4PL系统调用各承运商平台预创建订单接口，获取承运商是否可配送以及运费，4PL系统由低到高的呼叫承运商。如承运商在预设时间内，仍无骑手接单或承运商直接抛异常，则呼叫下一承运商；
根据预设顺序依次呼叫：如创建订单失败、或承运商在预设时间内，仍无骑手接单或承运商直接抛异常，则呼叫下一承运商。