拆解电商订单背后的多场景与流程

　　电商系统中，由于场景多样导致了业务流程比较复杂，而为了优化开发成本、用户体验、供应链链路，掌握各类细分场景，进而梳理出业务流程为各类棘手问题提供解决方案显得格外重要。
　　本文将复盘自己亲身负责过自营多供应商（仓库）的垂直电商产品，在做整个电商后台时，无论业务流程还是功能当时都感到很大压力，接触比较深的是库存、会员、积分、订单、促销活动中心（券、拼杀限时、活动页）、分销、财务这几块业务。
　　尤其会员用户升降级，外加上促销活动下的商品参与，与运营反复沟通，自己也反复考虑场景与漏洞，最后结算还是搞得接口PHP反复修改。
　　在做分销上下级关系与分佣，也是好多场景没有想到。那段时间与技术团队闹得特别厉害，运营与技术、测试也不停撕逼。最后还是成了半个背锅侠。
　　一、订单概述
　　对于自营或平台电商的后台订单模块来说，除采购、仓库、评论、内容、CMS模块，可以说牵扯到了整个电商所有模块，是名副其实的核心模块。
　　前端（H5、APP、小程序）一个订单，会经过用户管理、商品管理、库存管理、配送中心、支付中心、财务管理、风控、促销活动、评论、发票管理及备注信息。
　　这么多的模块，订单模块是把这些模块进行了链接，最终让平台上的商品流动到客户手中达成交易。
　　二、订单流程概述
　　用户从购物车或商品详情下单，进入订单页面填写收货地址，选择优惠券、发票、配送方式时间等，最后选择支付方式进行支付。
　　此时前台订单正式生成，系统推向后台仓库，仓库再推送到物流中心发货，最后用户确认收货或平台默认收货。
　　此时订单完成，这是一个普通且正常的订单流程。
　　但在实际购物中，由于规格、质量等各种原因，经常会出现退货、换货、退货退款，当然也会出现奇葩现象（包裹消失、配送异地、用户找不到），给我们订单处理增加了难度，出现了商品回流，既订单的逆向流程。
　　三、订单的整体业务流程
　　用户下单后，订单中心锁定库存，读取用户信息及等级；
　　获取商品信息，包含sku、价格、数量；
　　风控中心同时开始检测用户信息及设备购买频次；
　　促销活动中心对商品是否参加活动、用户是否有优惠券、参与拼团、秒杀；
　　支付模块根据促销、商品、用户模块数据，计算出准确的订单金额，调出支付方式；
　　库存减，拆解订单，拆解订单，根据商品所属供应商、规格所在仓库、收货地址、重量合理拆分到具体仓库高效发货；
　　仓库收到订单，打印发货单，减库存，发货；
　　物流配送中心给出物流配送数据；
　　用户确认收货；
　　财务计算订单流失，订单发票；
　　在订单的不同阶段退换货，申请售后，售后根据条件是否通过（下文订单的逆向状态，有详解订单在正向流通中，发起的逆向退换货、退款操作）；
　　通过后，重新推送到订单中心，在订单处理模块需要对原库存释放，产生新的订单，或在原订单某件商品上取消且备注新增商品且备注。
　　四、订单与库存之间流程
　　当商品供应商多个时，优先发出供应商权重高的，权重根据评论、物流、仓库位置三个维度打分。
　　供应商库存不足，单个订单用户会收到多个快递现象，前端也会显示多个物流单号。
　　订单在库存、仓储模块正向流程不同阶段下，发起的逆向订单流程：
　　五、订单状态
　　用户在前端购买商品下订单，会有以下状态：
　　未付款，已付款；
　　未发货，已发货；
　　未签收，已签收；
　　交易成功；
　　取消订单；
　　退款、换货；
　　换货、退货退款；
　　交易关闭；
　　14为正向流程，58为逆向流程。
　　当用户或平台客服发起订单逆向时，用户发起时，前端订单详情页有相应的售后按钮，进入后分出退款、退货退款、换货3个入口。
　　用户选择相应原因提交后，平台审核、审核通过后，货物寄送至平台仓库、平台退款或换货，退款不需要用户确认，退款成功后交易关闭。
　　换货需用户确认收货，确认后售后入口仍然打开，从确认收货算起，向后15天后无退货退款换货，则交易关闭。
　　六、订单逆向流程中的状态01：
　　发起逆向流程的有两个角色，平台和用户。逆向流程有4种状态取消、退款、退货退款、换货；除取消外，其它3种都在售后里面。实际购物场景中经常会出现以下场景：
　　1）未发货
　　换货：拍错、不想要此款
　　退款：不想要、拍错
　　2）已发货未签收物流中
　　换货：缺货、拍错、不想要此款
　　退货：不想要、拍错、实物不符、发错货
　　退款：没收到快递、商品已完全损坏、实物不符、发错货
　　退货退款：全部原因
　　3）已签收状态
　　换货：缺货平台发货、拍错、不想要此款
　　退货：不想要了、拍错；签收后给平台寄回
　　退款：没收到快递、商品损害严重、实物不符、发错货
　　退货退款：全部原因02：
　　出现以上场景，在订单正向流程的不同阶段，用户发起逆向流程进入售后处理，选择取消、退货、换货、退货退款后，会有以下几种状态：
　　在未付款时，发起的取消订单可以直接取消订单，取消后交易关闭。
　　在未发货时，发起的换货、退货退款：
　　1）订单换货状态：全退（等价）
　　未审核，已审核；
　　平台订单拦截，成功则后台生成新的订单，
　　平台未发货，平台已发货；
　　用户未签收，用户已签收；
　　交易完成；
　　2）订单换货状态：部分换（正差价负差价）
　　未审核，已审核；
　　平台订单拦截，成功则后台生成新的订单，
　　用户未付款或平台未退款，用户已付款或平台已退款；
　　平台未发货，平台已发货；
　　用户未签收，用户已签收；
　　订单正常进行，2周后交易完成；
　　3）订单退货退款状态：全退（等价）
　　未审核，已审核；
　　平台订单拦截，成功则后台生成新的订单；
　　平台未退款，平台已退款；
　　交易关闭
　　4）订单退货退款状态：部分退（正差价负差价）
　　未审核，已审核；
　　用户未发货，用户已发货；
　　平台未签收，平台已签收；
　　用户未付款或平台未退款，用户已付款或平台已退款
　　订单正常进行，2周后交易关闭；03：
　　在已发货时，发起的换货、退货退款：
　　1）订单换货状态：（等价）
　　未审核，已审核；
　　用户未发货，用户已发货；
　　平台未签收，平台已签收
　　平台未发货，平台已发货；
　　用户未签收，用户已签收；
　　交易完成；
　　2）订单换货状态：（正差价负差价）
　　未审核，已审核；
　　用户未发货，用户已发货；
　　平台未签收，平台已签收；
　　用户未付款或平台未退款，用户已付款或平台已退款；
　　平台未发货，平台已发货；
　　用户未签收，用户已签收；
　　订单正常进行，2周后交易关闭；
　　3）订单退货退款状态：（等价）
　　未审核，已审核；
　　用户未发货，用户已发货；
　　平台未签收，平台已签收；
　　平台未退款，平台已退款；
　　交易关闭
　　4）订单退货退款状态：（正差价负差价）
　　未审核，已审核；
　　用户未发货，用户已发货；
　　平台未签收，平台已签收；
　　用户未付款或平台未退款，用户已付款或平台已退款
　　订单正常进行，2周后交易关闭；
　　七、订单逆向退货退款、换货业务流程
　　支付差价，考虑过退差价的处理方法，最后统一结算。
　　但如果商品参与活动，结算起来比较麻烦，担心中间有差价或其它问题，只好搬倒树摸老鸹退一个结算一个。
　　最后选择了换完就退款（流程图如下），当订单内有商品参与过促销活动模块退款时，如使用了优惠券或折扣时，需要拆解出参与单独每个商品sku或spu实际付款金额，退款时按照实付款返还。此时订单有换货入口，进入重新下单，支付后，合并订单。
　　换货后新商品合并到原订单，原订单退换的商品需要保留记录对账，打上取消标签，增加新商品，重新计算整个订单金额，对于促销活动商品满减券仍可用，这里就不写太详细了。
　　八、总结
　　当我们把不同状态下的实际场景中，总结出来业务流程，细分到订单流程不同阶段，最后梳理成流程图。当时做的电商后台距现在已不久，其实我的拆分法比较繁琐，并不是最优，还有很多内容和细节写的也不到位，像财务资金流出、平台发起的逆向、退款时每个SKU价格计算等都没写清楚。
　　这篇文章更多的是希望提供一些思路，能帮助大家多想一些场景，有了多场景思维方式的术，想到更多场景，能更全面的完善产品。场景之后就是解决方案了，这些可以交给时间或者团队一起完成。
　　电商后台这套系统很类似传统供应链中ERP的一些模块，像CRMWMS采购物流等系统。在实际业务中可能要面临技术团队的成本预估，及运营提出的一些参考。多思考各种场景下的细分场景，可以给出更多更好解决方案。最终达到优化我们开发成本、用户体验以及整个供应链链路。