用户进行了订单签收并不意味着终结，这只是一个新的开始，因为商品送达后可能会由于运输过程包装或商品有破损，商品本质量并非商品详情中所描述的那样等各种原因使用户进行退货或换货；还有一种场景是用户签收后发现有的商品漏发、少发或因质量问题但无需退回等原因，需要商家再补发商品给用户。
本篇再简单介绍下，退、换、补几种场景下，业务和系统如何处理的。
简易流程图
这是一个最简单的，也只是主要的几个大点流程，描述了从商品签收后，退、换、补的过程,对于熟悉电商业务的或经常在网上购物的同学来说，这个非常熟悉，看到这如果都清楚，那么可以洗洗睡了：）。
退、换、补场景说明
这里按照上面的简易流程来进行逐个节点的说明，希望您在阅读的同时能够结合自己实际接触过的内容来丰富下相关内容，温故而知新。
1. 签收订单
这个在前面订单状态等梳理时都进行过梳理，系统处理过程如下。
签收对于用户表示其实际收到了商品，但订单来讲，签收是根据快递单号的状态由系统自动变更信息的，所以路由信息解析获取以及状态码的处理是需要与运单接口确认好。
在订单状态的变更，还应该区分订单来源、订单类型等关键字段，如线上或线下订单的处理是不同的，如果在门店购买商品，订单在付款结算时用户已经拿到了商品，会直接跳过订单下发、发货、出库等状态，直接变成已签收。
对于正常、换货、补发等订单，由于数据存储不同，单据的节点及关联信息也有区别，所以要区分每种订单，获取不同的信息再进行处理。
而且在系统在更改订单状态时，为了保证数据的完整性，需要将每个状态变化时的日志补全，相关的单据信息补全，同时要扣减商品库存并记录其变更明细。在产品设计或代码编写时，这些细节是需要考虑的，如果数据缺失会影响售后，影响相关的分析报表。
2. 售后发起与工单创建
只有订单商品有问题了用户才会发起售后，有的电商为了提升用户体验提出7天无理由退货，有的则要求提供图片或视频等，经过沟通才能发起售后。
退换补的售后发起有不同的途径，一种方式是可以联系线上客服或直接线下打电话由客服协助处理，此外可以直接在网上发起退换货，由用户录入售后申请单，然后进入审核阶段。
无论哪种方式，最终的售后都会流转到客服系统中集中处理，这时客服系统的处理速度与问题的解决是关键，如果不当很可能会影响用户的再次购物。
当然对于售后，不仅是退换补，还有商品咨询，投诉建议或发票及商务合作等各种事项。
客服收到用户申请后，会在售后系统创建工单，以便于后续跟进处理进展及结果。
工单管理是CS系统的重要模块，它是用户与商家的联系过程记录，也是客服人员工作效率、解决问题方式方法的记录。
3. 客服受理
工单生成只是第一步，此时会在工单池中，经过系统按规则分配给相关受理人员经过审核确认后，才会继续流转。
此时就会有多种场景需要考虑，以下列出几个较常用的工单分配原则：
按工单紧急程度及工单时间
同一客户优先级
相同问题类型分配规则
相同商家分配规则
退、换、补货的原因确认，客服人员会根据用户上传的图片、视频及描述进行审核，必要的时候售后会电话联系，沟通处理方式，与您进行协商处理。
受理单的问题原因多种多样，有商品自身的原因，有商家的原因，如果是第三方商家商品，售后还会联系第三方商家进行确认或直接委派给商家客服人员。
处理结果有几种，退货、换货或补发，此外还有一种就是给用户赔偿，即创建理赔单据（赠送礼品卡、现金券或给予折扣等）。
4. 换货单
换货是处理的一种结果，这种处理方式不会对于用户有影响，但是会保证用户收到一件商品。
换货会生成两种单据，即换货出库订单与换货入库订单，它们都是订单的一种类型，但是这里要注意，换货入库单是不需要给用户退款的，这在上面的流程图上也没有体现出来，换货出库单也不需要用户付款（对于商品差价，一般都是商家承担了，为了提升用户体验）。
这里解释一下什么是无实物回库?
无实物回库是指换入的商品或退货的商品，由于损坏严重或运输成本过高等原因不值得再逆向返回仓库，这种就是无实物回库。
对于商家来说，无实物回库商品是属于损失，所以需要生成一个商品报损出库单，单据类型为无实物，以便于财务进行账务上的处理。
无实物回库在生鲜食品上比较普遍（譬如海鲜或水果都有保质期，运回仓库就坏了也无法销售，回库只会增加成本）。
5. 退货单
退货单是客服在受理时，根据关联的订单商品，创建回库订单，当然有的商品可退，有的不可退，具体依赖商品属性及用户下单时的活动规则等条件。
商品发生退货也会有实物或无实物两种情况，对于有实物回库的商品，那么也会和换货入库单一样生成一张退货入库单由快递返回商家并进行入库。
退货入库或换货入库不同的是，退货单需要给用户退款，何时退款是也是用户体验的重要环节。
财务要控制资金风险，业务运营要提升用户体验，是在商品入库后给用户退款，还是在之前的某个环节退，可以根据实际情况设计。
6. 退款单
退款数据是根据客服受理的工单要求（原路或非原路）与退货的原订单的支付明细进行计算而生成的。
退款有原路和非原路两种，所谓的原路是哪来哪去，非原路是付款的支付方式与退款的收款方式不一致。
退款单一般由售后系统根据规则生成，退款的金额是否考虑运费、是否考虑原来的活动等细节。
FMS系统一般只获取结果，不参与业务上的计算（退款与支付结算类似都归属前端业务系统），所以在设计系统时边界的确定是非常必要的，这个需要业务架构师去平衡了。
退款单的生成逻辑是系统的重要部分，如果有促销的重摊重算那么相对复杂一点，系统要考虑的有如下几点：
获取原订单的支付明细以及商品的金额分摊。此部分是在订单拆单时要进行的一个重要工作，即根据订单参与的促销折扣等活动，将其分摊到订单商品明细表的每个商品中，包括运费金额的分摊。
获取退货单的实际退货商品数量明细数据。
计算原订单涉及的每种支付方式应退金额，支付方式有实际支付金额（如支付宝、微信、银联等）
计算订单支付时使用的优惠券、积分、礼品卡等；对于优惠券一般返还或原券作废(涉及使用期限)，积分退还原用户，这里可能涉及积分与金额的转换，礼品卡支付金额直接退还给原卡中。
运费的扣款，由于涉及用户运费（是用户承担还是商家承担），需要重新计算；此部分会有异常场景，即退的商品金额不足以抵扣运费（如果是用户承担），这些细节一般需要人工参与灵活处理。
最后生成一张退款明细单，对于实际支付的退款方式根据受理单采用原路或非原路方式进行标识，推送给FMS支付模块。
7. 补货单
相对于少发或漏发的场景，如果用户同意是需要给用户进行补发的，其次如果损坏严重，用户接受补发一个也可以。
这时的补货单实际上就是一个换货单，如何定义可以根据业务来确认。
补货单的生成是由客服操作的，此单无需用户支付的，由于补货单、换出单都会走正常订单的出库流程，所以数据应该与订单数据保持一致，只是订单类型不同而已。
总结
退、换、补单据的简单售后节点说完了，对于几种单据在数据流转与业务操作上有相同的，也有不同的。具体每种单据细节设计远比这复杂，而且这些都属于客服系统的范畴，对于WMS系统就是出库与入库，保证出入库单据完整，增加或扣减库存顺序正确应该就可以了。
相对于FMS财务进销存则要求其金额正确，该收的要收回来，该退的要及时退给用户，不能多也不能少；而且财务成本计算、应收、应付、库存等都要依赖于WMS出入库及相关的单据，不遗漏业务应该就不会有问题。
至此，以商品流转介绍系统也算画上一个句号，介绍的都是粗粒度的，后续计划仍以供应链为主，以某个节点为主深入梳理总结细节。
感谢您的阅读！
