01 退货退款整体流程
最近加班，主要在赶工处理售后系统退款和退货需求。按照公司业务场景，小Q总结了退款退货的触发场景主要分为两类：
一、客户线上发起申请，平台审批；
二、客户联系客服，由客服代为从后台发起申请。
同时，由于公司业务同时存在自营平台和三方POP商家两种业务模式，以及在线支付和货到付款两种支付方式的订单，小Q总结并梳理出整体业务场景蓝图：
▲ 退货退款场景罗列
02 退货退款系统流程详解
根据退货退款触发的时机不同，小Q将退货退款流程分为订单发货前、订单发货后、订单签收后3大节点，单独设计系统流程。
1.订单发货前的退货退款流程
用户下单以后，在实物订单未出库之前，用户尚未拿到实物商品，订单也还处于正向履约流程中，还不涉及到逆向物流场景。在此场景下发起的退货退款，在系统层面操作为：
一、取消订单；二、退款。
根据订单所处的履约节点，系统处理逻辑再细分为3个子节点：
（1）订单未支付：特指货到付款订单已提交，和在线支付订单已提交未付款的场景。 此时由于尚未支付，所以只需要取消订单即可，不涉及退款；
（2）订单已付款，但尚未下发库房/商家：此时订单还在中台订单履约系统中，实物尚在库房未动。在系统层面的处理为：
①取消订单；
②在线支付的订单，由系统或者人工生成退款单，审核通过后将订单实付金额原路退回用户支付账户（货到付款的订单未付款，无需退款）。
（3）订单已下发库房：此时订单已产生波次进行发货生产了，所以退款之前需确保实物商品尚未真实发出，将商品还货上架。为防止系统信息流转过程中存在滞后性，故在取消订单前，最好核实一下库房/商家实物的真实情况。在系统层面的处理为：
①尝试取消订单，若商品未发货，则可取消成功。否则取消失败，退款失败；
②库房将已取消订单拦截并还货上架；
③在线支付订单，生成退款单，审核通过后原路退款至用户支付账户。
▲ 订单发货前的取消及退款流程
2.订单拒收的退货退款流程
订单发货以后，实物已经在运输途中，但用户尚未签收，此时，若用户拒绝签收，则产生了拒收。货到付款的订单，拒收时并未收费，也无需退款。
系统处理逻辑为：
（1）客服核实拒收原因，若用户还想继续要，则联系物流公司对进行再投，正常签收订单。此过程仍为订单正向流程，未涉及售后流程。
（2）若协商同意退货，则由客服发起一个退货申请下发至库房（自营业务）或者商家端（三方POP商家业务），等待包裹被物流送回以后，核实确认无误后，将在线支付订单原路退款，货到付款订单因尚未收款，无需退款。
此处需要说明的是，自营平台订单，一般在库房操作WMS系统，退货入库状态可与上游系统实时互通，故在库房退货入库以后可自动触发退款；而商家系统最好由商家明确确认收到实物以后（多了一步商家确认的动作），再触发退款。
平台退款以后，与商家进行结算订单应收时需排除已退款订单。
▲ 订单拒收退货及退款流程
3.订单签收后的退货退款流程
订单签收以后发起的退款，与签收前主要有两点不同：
（1）货到付款订单此时已收款，所以涉及到订单退款；
（2）签收前的退货都是整单维度，签收后可支持部分退货。
系统处理流程为：
（1）用户或客服发起退货申请；
（2）平台或商家审核退货申请，同意后，用户将包裹寄回。若为自营平台订单，只需要平台审核通过即可寄回包裹；若为商家订单，还需商家审核同意。
（3）库房/商家收到寄回包裹后，生成退款单，按照约定路径将货款退回用户账户。原则上要求按原路返回，但部分为现金支付的货到付款订单，或者其它情况，可以协商其它线上退回路径。
▲ 订单签收后的退货退款流程
03 订单、退货单与退款单
由于1张订单可能会产生多次退货，每次退货会生成1张退货单。同时，1张订单也有可能触发多次退款。所以，小Q将退货单、退款单单独设计，与订单库独立存在、相辅相成。
退货单和退款单是怎样的关系呢？ 小Q调研完一圈下来发现，并不是每一张退货单都会生成退款单，更不是每一张退款单都会有退货单，就像并不是每一滴牛奶都叫xx苏一样，嘿嘿~例如货到付款的订单退货，就只会有退货单，不需要退款单；有些情况下，客服会针对某些订单只为客户退款，而无需退货，例如承诺超时赔付等。所以，退货单和退款单只有在常规退货退款场景下才是一对一的关系，在特定的场景下并不具备强关联关系。
▲ 订单、退货单与退款单
根据退货单的操作状态，小Q将退货单设计为待审核、待入库、入库完成、驳回 4个状态：
①待审核：在订单逆向过程中，客户或客服新发起退货申请，系统生成退货单的初始状态；
②待入库：退货单审核通过，同意退货的状态。此时，等待客户包裹寄回；
③入库完成：包裹寄回仓库，库房已完成入库；
④驳回：退货申请被驳回的状态。
▲ 退货单状态图
按照退款节点，退款单的状态设计为待审核、待退款、退款完成、驳回 4个状态：
①待审核：退款申请刚提交的初始状态；
②待退款：退款单由财务审核通过，同意退款；
③退款完成：由财务手工或系统自动触发退款，退款成功后的状态；
④驳回：退款申请被驳回的状态。
▲ 退款单状态图
04 退款金额计算
订单签收前的取消和拒收引起的退款，都是整单退货（全退）。而签收以后的退货，经常由于部分商品问题，所以会存在部分退货（半退）。如果在订单下单时使用了优惠券、抵扣金、积分等，也需要考虑退回用户账户。
全退情况的退款处理比较简单，小Q给出的解决方案为：①按订单实付总金额退款；②未过期的优惠券、积分等优惠信息原路返回。
半退情况下的退款处理相对复杂，小Q向阿辉、老A等老铁们逐个请教和讨论后，总结如下：
①若无组合优惠信息，按商品实付金额退款；
②若使用了组合优惠信息（如整单满减券），有两种主流处理方式：
a.优惠按照商品金额比例分摊，按照分摊后的实付金额退款；
b.退款时需考虑剩余商品是否满足优惠，重算优惠后退款。
为加强理解，举例说明：
a.优惠按照商品金额比例分摊，按照分摊后的实付金额退款。(参考：淘宝)
举例：某用户购买商品ABC各1个，使用了满150减20的优惠券，按比例分摊后的实付金额如下:
如上，若退A，则退款90元；退B，则退款54元；退C，则退款46元。
此规则简单易实现，但存在凑单刷优惠券的风险。存在用户为了凑单使用优惠券，签收后又将其它不需要的SKU退货的情况。一般规避方案为：①用户责任导致的退货运费由用户承担；②恶意刷优惠券退货的行为，将用户做降级处理、或加入黑名单。
b.退款时重新计算优惠，若剩余SKU继续满足优惠，则按原价退款；否则扣除优惠后再退款，若扣退款金额尚不够优惠，则不能单独退此商品。参考：
举例1：某用户购买商品ABC各1个，使用了满150减20的优惠券，实付金额如下：
①若退C，则剩余A和B，原金额合计160，仍然满足优惠条件，故退款40元；
②若退B，则剩余A和C，原金额合计140，不再满足优惠条件，需扣除优惠，故退款金额=60–20=40元。
举例2：某用户购买商品AB各1个，使用了满100减50的优惠券，实付金额如下：
①若退A，剩余B（原金额为40），不再满足优惠条件，需扣除优惠，可退款金额=60-50=10元
②若退B，则剩余A（原金额为60），不再满足优惠条件，需扣除优惠，但因B的原金额（40）小于已优惠金额（50），故不允许单独退B。
此规则可预防刷优惠券的情况，但规则较复杂，解释成本和系统实现成本较大。
以上两种方案，小Q更倾向于方案a。因为在医药行业，药品一经售出，原则上不退不换，所以本来退货就是个低概率事件，加上用药的特殊性，为了套优惠券而凑单再退货的概率就更低了。系统设计时也遵循大道至简原则，平台在发放促销优惠时，只要保证整体上成本能cover住，系统也就无需设计的过于复杂了。
对于以项目驱动的加班，小Q从不排斥。项目赶工期间，为了在计划时间内有成果产出，无数次自愿加班，赶最后一班地铁到家后继续挑灯夜战；也曾经连续奋战24小时，到宾馆短暂休息后又自觉奔赴项目现场，只会担心新上线项目有所闪失；更有连续一个月奋战到凌晨三点，只为在别人下班期间腾出时间做系统联调。那些日子很苦，但回忆起来都是甜，心之所向，自驱而动，无怨也无悔。
当996的矛盾在网络上升级到ICU高度的时候，已然成了企业和员工之间的阶级矛盾，正反方各执己见、争锋相对。对于996，小Q有自己的理解，相比从上往下灌输的政策和自下而上应对的对策，小Q更加崇尚有意义的自驱式价值观，而不希望制度沦为一种自欺欺人惺惺作态式的企业与员工博弈的戏台。
纵观历史，一切以反人性为出发点的制度都是阻碍历史前行的绊脚石，终将被历史所淘汰。 9也好，6也罢，上下班时间本该只是自我价值实现的一条记录，凌晨4点的街头也不应该成为朋友圈炫耀的资本。当然，价值的体现因人而异，有人为了名，有人为了利，有人为了自我提升，也有人为了自我实现。最理想的做法是企业了解每位员工诉求，给予他们想要的，激发每个人的潜能，不断提升员工做事的效率和投入度。
