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