售后的处理流程是履单中的重要部分，对于订单的售后处理主要涉及两部分的处理即：物和款；物是指商品的处理，包括实物商品或虚拟商品的逆向流转，款是指用户已经支付及享受的优惠的款项计算。
这里再简单将所了解的订单取消与退货两种场景进行一次总结。
取消与退货业务流程
订单有很多种状态，新建、待发货、已发货、已签收、已取消、已关闭、已拒收、待支付、已支付等……
用户购买商品产生订单后很可能取消，所以取消订单可以在哪个状态节点进行，是在设计时重点考虑的，因为不同的时间点，订单取消时的系统处理也是不一样的。
在零售电商公司中，有自营、平台商家两大模式，自营也分为供应商直发与仓库发货两种方式；对于有线下门店的则主要涉及退货，订单取消则较少。
下面结合订单状态和业务模式来分别说下取消与退货。
取消
一般情况下，在订单发货前都是可以取消的，这时系统主要处理的就是用户退款问题，当订单发货后正常的流程是不允许用户取消订单了，因为商品已经交由快递公司进行配送，系统涉及的流程比较复杂，一般情况下用户可以做拒收处理。
订单支付前取消
用户取消订单时还是有一个订单支付状态的考虑，如果未支付则用户可以随时取消，系统不会涉及实际支付金额的退款，但是需要考虑在提交订单时选择的积分、礼品卡、优惠券等的支付。
订单支付前用户如果取消，则需要返还积分到用户账户，礼品卡使用的金额到原卡中；优惠券一般是使用或未使用状态，取消后重置状态即可。
由于订单未支付，所以不会影响平台商家模式的代收与代退款，即不会影响财务结算。
订单下发前取消
此状态是指订单已经支付，但是还没有下发到仓库或没有同步到商家平台或供应商平台中，仓或商家、供应商均未操作。
此时用户如果要取消订单，主要涉及的是款项的退还。
为了提升客户体验，关于此类取消订单，都是原路退款的，微信、支付宝等会实时退款到账，信用卡等可能会等待银行回款通知。
订单取消一般是用户主动发起的，所以基本上在我的订单中都可以直接操作。取消时系统要更新订单状态为取消，同时要根据支付明细生成退款单与积分、礼品卡、优惠券的返还操作。
退款单由于是原路退款，不需要财务审核，系统自动调用第三方支付接口申请退款即可。
在平台商家模式中，由于是平台代收和代退款，所以是需要后期财务对账的，但由于取消与支付都是相同的金额，此类订单可以不进入到后续的财务结算单中。
关于平台商家的结算，在生成结算单时要考虑商家刷单的风险「商业下单后在某一阶段再进行取消或退货」，所以商家结算单一般都是在订单签收后的一周的订单，考虑商品的退换货时间。
订单待发货前取消
此状态是指订单已经支付，且已经将订单同步到下位WMS或平台商家、供应商平台系统中，等待仓库、商家或供应商进行发货安排。
以仓库为例，订单下发后，WMS系统中一般会先接单，然后生成波次，再安排拣货，如果订单是待发货则表示仓库还没有开始处理。
此时订单的取消操作与待下发前取消的过程相似，即生成退款单、返还用户积分、礼品卡或优惠券到用户账户。
但由于订单已经下发，此时涉及上位与下位系统的数据同步，多系统的协作是有延时；而且履单的过程是实时的，用户在取消订单时可能仓库还未开始处理，即订单状态是待发货，但是当用户提交时WMS系统中正好在进行接单处理，这样便可能取消失败。
所以此种状态的订单取消，一般是要有个系统审核的过程，即用户提交取消申请后，OMS系统先进行红单撤回，如果撤回成功则直接更新为订单取消，并进行退款等流程。
其实红单撤回可以手动也可以自动发起，所谓的红单撤回就是将已下发的订单进行取消下发，如果撤回不成功则不能取消。
在现实业务场景中，为了提升用户满意度，客服是手动进行红单撤回的，即便仓库已经拣货，也是可以进行订单拦截的，这些在产品与系统设计时都应该考虑。
如果是商家发货或供应商直发的业务模式，此种状态下的订单取消时可能会涉及商家或供应商的ERP系统，状态的回传可能会延时。
订单发货前取消
一般仓库接单后，仓库就会安排拣货，在拣货到发货之间还有分拣、打包、面单打印等一系列操作，在此节点进行订单取消就意味着仓库的一些作业都白做了:(,所以有些电商在此节点是不允许订单取消的。
在商家发货或供应商直发模式中，商家和供应商的履单能力不一样，甚至有些商家或供应商内部可能都没有系统，即便有也是一个简单的进销存，所以有很多作业状态与系统是不匹配的。
此时应该尽量将商家平台或供应商平台的功能完善，以便商家与供应商可以在我们开发的系统中进行操作，保证OMS系统与各系统的数据同步，并及时反馈给前端用户。
只要订单未发货，原则上都允许用户进行取消，取消后主要是的流程是在仓储系统中，已拣货、打包的要进行取消，这就是仓储内的订单拦截。实际的业务场景可能会更复杂，但仓储系统主要是保证实物的正常流转，所以取消后上位系统仍然是对款的处理。
在此状态的订单取消，由于涉及单据的拦截，所以在用户申请取消后，需要有一个仓库申核的过程，以避免拦截不成功，也为了提升用户体验，避免前端显示取消成功，但后续处理失败的风险。
退货
对于退货，一般是用户已经收货后，发现商品有质量或其他问题进行的流程，有很多电商公司支持7天无理由退货，所以于用户来说还是比较有利的。
订单退货是有期限的，当订单关闭后则不可能再进行退货，但像电子产品等可以进行保修。为了提高服务质量，现在像手机、电脑等在用户购买时都推出了碎屏险、一年或三年的全机保修服务。
退货不仅涉及货款的返还，还涉及到商品的退还，订单的退货率也是衡量经营的一个重要参考指标。
退款流程有的是要求商品回货或回到商家与供应商后，经过确认才给用户返还金额，周期可能需要几个工作日，从用户角度看体验不是很好，但这要做的目的是为了防止一些恶意用户薅羊毛。
退货分为部分退货或整单退货，退款单则是根据退货订单及原订单信息、原订单的支付明细生成，也分为两部分：
- 用户实际支付的金额：根据商品实际的支付明细生成「订单在支付成功后，经过拆单、金额分摊，系统会记录每个商品的金额明细」
- 积分、礼品卡与优惠券等金额返还「金额同样会根据商品使用条件进行分摊」
自营商品退货的风险低于平台商家的商品，因为平台商家是平台代收代退款的，具体如下图。
购物平台经常会有促销活动，商家入驻平台有时也需要配合平台进行促销，如双11、618等，商家参与促销时就会涉及到促销产生的费用如何分摊。
如平台发放的满300减100优惠券，平台承担比例是60%,商家承担比例是40%,则在生成订单金额分摊后，在退货时同样要进行计算，这些不仅在退货单及退款单计算时考虑，在最终平台结款给商家时同样要考虑。
关于实物商品的退回，是平台是否退款给用户的一个重要因素。正常的流程是商品退货入库后WMS系统会回传退货单状态给到OMS系统,OMS系统会同步到财务退款单，触发系统退款给用户，现在基本上都是在线支付，所以金额都是原路返。
实物商品也并非都要进行入库的，对于生鲜水果，有的就无需进行返回仓库。所以就分为有实物商品退货入库和无实物商品入库，但是退款单仍然应该依赖于退货入库单的状态判断是否返款给用户。
在设计系统时，虽然退货单类型不同，但是应该保证主流程一致，尽量不要为了减少工作量而减少单据状态或数据的记录，前端用户使用可以合并一些操作，后台需要按正常流程处理，如果为了降低响应时间，可以设计成异步方式，通过消息或任务进行逻辑处理。
退货之于商家与平台都有风险，而且有些用户会利用系统的一些漏洞或延迟进行一些恶意操作，个人觉得涉及到金额的如果不能判断风险，可以让子弹飞一会再进行处理，即增加一些「系统已经理，财务正在审核中的!」等文案，让系统等待一会再进行一些接口状态的判断。
此外，需要增加必要的审核流程，客服、商家、财务等等，用户的体验提升并不是一味的满足用户，而是应该解决用户的问题，根据二八法则，抓住关键用户，对于极少的用户的特殊需求或体验可以舍弃。
风险及难点
对于取消与退货的风险，如果可以通过增加审批或校验节点「手动要减少，应该尽量采用系统处理」来控制应该还是比较好的。
个人觉得最难的应该是因为促销而产生的复杂计算，而且即便经过重重计算，有时金额计算的也不完全符合要求。
这里列举几个场景供大家参考：
拆单后的子订单取消
用户下单时购买商品可能是一个订单，但是经过系统拆单后分为两个或多个订单。虽然金额已经进行了分摊计算，且都记录的促销活动，但是用户可能会取消一个子订单。
这时子订单的取消可能就会引起促销的重算，重算后其他订单便不满足促销活动，这时系统计算就会非常之麻烦。
如果平台商家与自营商品同时享受全场促销活动，计算则需要考虑促销承担比例等。
发生拆单后，如果进行关联限制，则对于用户来说体验会非常差且系统校验逻辑也非常复杂。此部分在原来的公司时曾与相关产品同事讨论过，但最终考虑用户体验及订单取消率及退货率，没有进行关联限制。
订单的部分退货
这个场景与拆单类似，不同的是是在单个订单内发生的部分退货，同样是促销的重摊重算。
退货会产生运费、及未退货商品享受的优惠是否继续的场景。有时因为退款可能用户不仅没有退款，还需要补款的情况。
如：用户购买A、B两件商品,A售价90,B售价10元，享受促销活动满100减20，如下表。
用户收到商品后，进行B的退货，此时假设还会有5元的运费需要用户承担，退货后不能再享受100减20的订单。
这时A商品恢复90元原价，所以此时用户如果退货，则需要再支付18+5-8=15元，这个例子虽然有些极端，但是可以说明，享受优惠购买的商品退货后，于用户并不一定有利。
对于用户需要补货款的，如何处理呢？在梳理通用促销平台时介绍过，可以生成一个「虚拟商品订单」，然后由用户进行支付结算，当然如果作为正常的用户肯定会选择换货或整单退货。
以上两种场景，仅是取消与退货处理的一部分，在如今获取用户成本居高不下的竞争环境下，个人觉得即便发生取消或退换货也不应该进行促销的重摊重算，应该将这部分损失统一归结到财务销售费用中。
总结
关于订单的取消与退货的业务细节仍需要以实际业务场景为主，根据退换货的比率来确定方案，对于商家、购物平台、用户的几个业务主体，也应该去平衡，不要因某一商家或某一用户的投诉就去进行大的系统调整，需求要计算抽入产出，要根据生产数据进行分析，有失才有得。
再啰嗦几句，前期有朋友提醒，文章在IOS系统下英文的展示像飞一样,如下图：
一直以为是使用了「MdNice」编辑器导致的，今天在公众号中利用壹伴编辑器进行了Html源码的查看与对比，才发现实际上是由于在编辑文章时采用了「Zapfino」的原因，现在调整回「Arial」应该正常了，如果您在iPhone下仍显示不正常，请给我留言，您的体验是我最大的幸福！
