本文中，我个人努力做的自营多供应商(栈)的垂直电商产品，在做整个电商后台时压力很大，不考虑业务流程，库存、会员、积分、订单、推广流量中心(优惠券、拼/杀/限时、流量页)、分销、财务等业务深度接触。

特别是会员用户的升级降级，推广流量下的商品介入和操作频繁是一样的。也经常想场景和瑕疵，最后界面PHP修改频繁。

还有很多场景是我在做上下级关系，分提成的时候没有想到的。那段时间和工艺团队很陌生，运营、工艺、测试总是撕个不停。最后，他成了一个后腰。

一、订单概述

对于自营或平台电商的后端订单模块，除了采购、堆码、讨论、内容、CMS模块，可以说涉及了整个电商的所有模块，是名副其实的焦点模块。

前端(H5、APP、小程序)一个订单会经过用户管理、商品管理、库存管理、配送中心、支付中心、财务管理、风险控制、促销流程、讨论、发票管理、备注信息。

这么多模块，订单模块就是把这些模块链接起来，最终让平台上的商品流向客户进行买卖。

二、订单流程概述

用户从购物车或商品详情下单，进入订单页面填写送货地址，选择优惠券、发票、送货方式和时间，最后选择付款方式支付。

这时前台订单正式诞生，系统推送到后台栈，再由栈推送到物流中心发货。最后用户确认收货或者平台默认收货。

此时订单完成，这是一个大众化的正常订单流程。

但在现实购物中，由于规格、质量等原因，经常会出现退货、换货、退款的情况。当然也会有奇怪的迹象(包裹不见了，快递在异地，用户找不到…)，这就增加了我们处理订单的难度，出现了货物回流，也就是订单的逆向流程。

三、订单的整体营业流程

用户下单后，订单中央锁定库存，读取用户信息及品级；
获取商品信息，包罗sku、价钱、数目；
风控中央同时最先检测用户信息及装备购置频次；
促销流动中央对商品是否加入流动、用户是否有优惠券、介入拼团、秒杀；
支付模块凭据促销、商品、用户模块数据，盘算出准确的订单金额，调出支付方式；
库存减，拆解订单，拆解订单，凭据商品所属供应商、规格所在堆栈、收货地址、重量合理拆分到详细堆栈高效发货；
堆栈收到订单，打印发货单，减库存，发货；
物流配送中央给出物流配送数据；
用户确认收货；
财政盘算订单流失，订单发票；
在订单的差别阶段退换货，申请售后，售后凭据条件是否通过（下文订单的逆向状态，有详解订单在正向流通中，提议的逆向退换货、退款操作）；
通事后，重新推送到订单中央，在订单处置模块需要对原库存释放，发生新的订单，或在原订单某件商品上作废且备注新增商品且备注。

四、订单与库存之间流程

当商品供应商不止一家时，优先考虑权重高的供应商，并从权重凭证讨论、物流、栈位三个维度进行评分。

如果供应商库存不足，单个订单用户会收到多个快递签收，前端会显示多个物流单号。

库存和仓储模块正向流程不同阶段下的订单的建议反向订单流程:

五、订单状态

当用户在前端购买商品并下单时，会有以下几种状态:

未付款，已付款；
未发货，已发货；
未签收，已签收；
买卖乐成；
作废订单；
退款、换货；
换货、退货退款；
买卖关闭；

1-4是正向过程，5-8是反向过程。

当用户或平台客服提出订单反转时，前端订单详情页有响应售后按钮，分为退款、退货退款、换货三个入口。

用户选择回复原因并提交后，商品会被送到平台栈，平台会退款或换货。退款不需要用户确认，退款成功后会关闭销售。

换货需要用户确认收货，确认后售后入口依然开放。如果在确认收到后15天内没有退款，销售将被关闭。

六、订单逆向流程中的状态
01

提出逆向流程的有两个角色，平台和用户。反向流程有四种状态——作废、退款、退货退款、换货；除了无效，其他三个都在售后服务。真实购物场景中经常出现以下场景:

最赚钱的自由职业类型有哪些？这七个职业一定要看。

1)未交付

换货：拍错、不想要此款…
退款：不想要、拍错…

2)已装运但未签字/在物流中

换货：缺货、拍错、不想要此款
退货：不想要、拍错、实物不符、发错货
退款：没收到快递、商品已完全损坏、实物不符、发错货
退货退款：所有缘故原由

3)登录状态

换货：缺货平台发货、拍错、不想要此款
退货：不想要了、拍错；签收后给平台寄回
退款：没收到快递、商品损害严重、实物不符、发错货
退货退款：所有缘故原由

02

在上述场景中，在正向订单流程的不同阶段，用户提出反向流程进入售后处置，选择作废、退货、换货、退货退款后，会出现以下状态:

当未付款时，可以直接作废建议作废的订单，作废后交易关闭。

商品未发货时，建议退换货:

1)订单更换状态:全额退货(等价)

未审核，已审核；
平台订单阻挡，乐成则后台天生新的订单，
平台未发货，平台已发货；
用户未签收，用户已签收；
买卖完成；

2)订单交换状态:部门交换(正价差/负价差)

未审核，已审核；
平台订单阻挡，乐成则后台天生新的订单，
用户未付款或平台未退款，用户已付款或平台已退款；
平台未发货，平台已发货；
用户未签收，用户已签收；
订单正常举行，2周后买卖完成；

3)订单退货退款状态:全额退款(等值)

未审核，已审核；
平台订单阻挡，乐成则后台天生新的订单；
平台未退款，平台已退款；
买卖关闭

4)订单退货退款状态:部门退款(正差价/负差价)

未审核，已审核；
用户未发货，用户已发货；
平台未签收，平台已签收；
用户未付款或平台未退款，用户已付款或平台已退款
订单正常举行，2周后买卖关闭；

03

当货物已经交付时，建议的货物更换和退款:

1)订单替换状态:(等价)

未审核，已审核；
用户未发货，用户已发货；
平台未签收，平台已签收
平台未发货，平台已发货；
用户未签收，用户已签收；
买卖完成；

2)订单替换状态:(正差价/负差价)

未审核，已审核；
用户未发货，用户已发货；
平台未签收，平台已签收；
用户未付款或平台未退款，用户已付款或平台已退款；
平台未发货，平台已发货；
用户未签收，用户已签收；
订单正常举行，2周后买卖关闭；

3)订单退货退款状态:(等价)

未审核，已审核；
用户未发货，用户已发货；
平台未签收，平台已签收；
平台未退款，平台已退款；
买卖关闭

4)订单退货退款状态:(正差价/负差价)

未审核，已审核；
用户未发货，用户已发货；
平台未签收，平台已签收；
用户未付款或平台未退款，用户已付款或平台已退款
订单正常举行，2周后买卖关闭；

七、订单逆向退货退款、换货营业流程

支付差价，考虑退还差价的处置方式，最后统一结算。

但是如果涉及到商品的流转，结算会比较贫穷，洼地中心的差价或者其他问题，只好搬下树摸老太太回一个结算。

最后我选择了换货后退款(流程图如下)。当订单中有已参与促销流模块的商品进行退款时，如果使用优惠券或折扣，则需要将每件商品所涉及的sku或spu的实际支付金额进行拆解，按照实际支付进行返还。此时订单有了替换入口，订单重新下单。付款后，订单合并。

替换后，新货合并到原订单中。从原始订单退回的货物需要记录和核对，标记为无效，添加新的货物，并重新计算整个订单金额。移动商品推广还是有的，这里就不写太多细节了。

八、总结

当我们从不同状态的真实场景中总结出业务流程，再细分为订单流程的不同阶段，最后整理成流程图。那时候电子商务的背景是现在没多久。其实我的拆分方式比较繁琐，也不是最优的，其他很多内容和细节都写的不到位，比如财务资金的流出，平台提议的反转，退款时每个SKU的价格计算等等。

这篇文章更多的是提供一些思路，可以帮助大家更多的思考一些场景。多场景思考的技术，可以思考更多场景，更全面的完善产品。场景之后就是解决方案，可以交给时间或者团队去完成。

电商后台系统和传统供应链中ERP的一些模块非常相似，比如CRM/WMS/采购/物流系统。在现实业务中，我们可能要面对工艺团队的成本估算和运营提出的一些参考。多思考各种场景下的细分场景，才能给出更多更好的解决方案。最后可以优化我们的开发成本，用户体验和整个供应链环节。