接《订单系统总结》章节，上面所讲的都是订单的正向流程中的履单，逆向流程并没有介绍，今天我们就主要说说订单逆向流程这些事。

由于历史原因，官网并未做订单逆向流程，每天所有的退款都需要客服人员手动录入系统处理，不但效率低，还容易出错。因此这次做订单系统规划时（也考虑了逆向流程），主要从以下几点介绍：

1. 订单状态机

逆向流程节点及其状态确定，见图：

总结：订单状态的确定，我们当时规划的时候和研发同时开了三次会，最终确定；经过就不多说了。主要说下订单状态确定思路吧。

我们当时是先画了一个订单的主线流程图，然后在订单的主线流程图每个节点开始考虑都会存在哪些状态；最终前台确定了这六个状态，但后台的订单状态可远远不止这些；基本上要比前台的状态多了一倍还要多；当然会有这么多状态，也是因为交互的系统比较多导致；一般初期的电商系统这几个状态也够用。

2. 退款场景

从状态机中不难看出，退款发生的场景主要有以下几类

1. 未付款时，取消订单；系统自动取消订单一般会根据自身公司实际情况来决定；我们当时是因为有占存的概念，因此暂定是30分钟
2. 已付款待发货申请：因为公司的仓库都是自己的，可以控制；因此可以根据实际情况来做拦单，同时客服审核后可直接退款
3. 已付款且已发货申请：这块一般公司会根据自己的规则决定是否先行退款还是是收到退货后再退，一般业务会根据实际情况处理售后。在此，既要考虑用户体验，又要考虑商品退货风险

3. 退款业务流程

其实，做后台系统，需求调研的时候，他们也说不出个一二三，除非经验比较深的，或许能提出一些信息点；很多时候是需要产品经理主动给出一条思路进行引导的；经过和相关部门的沟通，最终确定了业务流程，具体如图：

用户操作流程图：

总结：根据不同的订单状态，显示不同的退款类型入口。

一般对于退款申请，未发货的订单申请退款都可以整单申请退，逻辑上相对要简单一些；如果是退款退货，相对来说比较复杂

• A. 无各种优惠的时候 ，选择某一商品申请退款，申请后按业务流程处理即可；
• B. 订单有优惠的时候，选择某一商品申请退款，则牵涉到退款金额的计算。

如：两件商品A（20元）、B（80元），订单共100元；提示满90包邮；现在用户申请退A商品，就牵涉到退款金额计算；是按比例退款，还是是按实际售价退；所有的金额计算要和相关业务部门沟通，根据实际情况来确定退款金额计算规则后执行。