销售订单的正向流程比较好理解，也相对简单。逆向的，如退货退款，取消订单，这些就相对复杂了。
订单究竟有多少状态，这个是要结合每个公司业务实际来确定颗粒度的，并不是越多越好。很多时候，状态多了，只会把客户或自己给绕晕了。
在我们新系统的设计中，根据订单本身完成程度，有以下几种基本状态：
- 未付款：指还没支付的订单，可以自行取消，或者让系统超过一定时限后自动设为取消状态。
- 待发货：已支付，但是后台还没开始发货处理的订单。
- 配送中：快递公司拣货并回传已发货信息后的状态。
- 已完成：客户确认签收，或者拒收后的状态（拒收时，可以根据物流状态来更新订单状态）。
- 已取消：未付款的订单，可以人工取消。
你可能会有点疑惑，为啥客户拒收也要定义为“已完成”状态呢？这就牵扯到订单的逆向流程载体的问题了。
如果直接在原始订单上添加各种逆向的状态，会显得很臃肿。所以，我们要用“单据关联‘的思想来进行设计。
具体来说，原始订单只有前面提过那5种状态，其他逆向的状态，靠对应的单据来承载。
待发货状态下，因为还没开始分配运单号、拣货等操作，这个时候订单可以取消，并申请退款。我们的系统逻辑是：确认允许取消后，自动生成一个待处理的退款单。这种情况下的退款单，我们给它定一个类型，叫做“仅退款”。
配送中或者已完成状态下，货物已经发出，库存已经扣减，要逆向就只有退换货和退款了。
- 退货单：后台操作人员，根据从客服收到的退货申请，创建一个退货单。
- 退款单（退款退货）：仓库受到退货，并确认可以重新入库和二次销售后，即可自动生成一个待处理的退款单，类型为“退货退款”。
- 换货单：某些特殊商品，我司允许用换货的形式来处理，如衣服买错尺码了。换货单实际上是退货+出货的结合体。
- 退货入库单：如果退货能够重新入库，则需要一个入库单来承载。
- 换货入库单：通过换货形式退回来的商品，若能够二次销售，也得入库处理。
- 换货出库单：换出去寄给客户的商品，也得做一次出库动作。
从以上各种单据的介绍可以看出，我们的总体思路是保持原始销售订单数据的相对独立，通过关联单据来区分和承载正向和逆向的流程。这样一来，整个系统内的单据结构就会很清晰，订单本身的耦合度会大为降低，避免为后续业务扩展挖坑。不然的话，一个订单混杂了销售信息、退换货信息、退款信息、出入库信息，各个部门的人看着也晕，处理起来也很麻烦（因为你还要考虑到不同操作类型的权限隔离）。
类似的，对采购订单而言，也可以用单据分离的思路来设计逆向流程，这里我就不展开了，毕竟采购不是我司的高频业务。