电商后台系统改造项目笔记(6)销售订单逆向流程

销售订单的正向流程比较好理解,也相对简单。逆向的,如退货退款,取消订单,这些就相对复杂了。

订单究竟有多少状态,这个是要结合每个公司业务实际来确定颗粒度的,并不是越多越好。很多时候,状态多了,只会把客户或自己给绕晕了。

在我们新系统的设计中,根据订单本身完成程度,有以下几种基本状态:

  • 未付款:指还没支付的订单,可以自行取消,或者让系统超过一定时限后自动设为取消状态。
  • 待发货:已支付,但是后台还没开始发货处理的订单。
  • 配送中:快递公司拣货并回传已发货信息后的状态。
  • 已完成:客户确认签收,或者拒收后的状态(拒收时,可以根据物流状态来更新订单状态)。
  • 已取消:未付款的订单,可以人工取消。

你可能会有点疑惑,为啥客户拒收也要定义为“已完成”状态呢?这就牵扯到订单的逆向流程载体的问题了。

如果直接在原始订单上添加各种逆向的状态,会显得很臃肿。所以,我们要用“单据关联‘的思想来进行设计。

具体来说,原始订单只有前面提过那5种状态,其他逆向的状态,靠对应的单据来承载。

待发货状态下,因为还没开始分配运单号、拣货等操作,这个时候订单可以取消,并申请退款。我们的系统逻辑是:确认允许取消后,自动生成一个待处理的退款单。这种情况下的退款单,我们给它定一个类型,叫做“仅退款”。

配送中或者已完成状态下,货物已经发出,库存已经扣减,要逆向就只有退换货和退款了。

  • 退货单:后台操作人员,根据从客服收到的退货申请,创建一个退货单。
  • 退款单(退款退货):仓库受到退货,并确认可以重新入库和二次销售后,即可自动生成一个待处理的退款单,类型为“退货退款”。
  • 换货单:某些特殊商品,我司允许用换货的形式来处理,如衣服买错尺码了。换货单实际上是退货+出货的结合体。
  • 退货入库单:如果退货能够重新入库,则需要一个入库单来承载。
  • 换货入库单:通过换货形式退回来的商品,若能够二次销售,也得入库处理。
  • 换货出库单:换出去寄给客户的商品,也得做一次出库动作。

从以上各种单据的介绍可以看出,我们的总体思路是保持原始销售订单数据的相对独立,通过关联单据来区分和承载正向和逆向的流程。这样一来,整个系统内的单据结构就会很清晰,订单本身的耦合度会大为降低,避免为后续业务扩展挖坑。不然的话,一个订单混杂了销售信息、退换货信息、退款信息、出入库信息,各个部门的人看着也晕,处理起来也很麻烦(因为你还要考虑到不同操作类型的权限隔离)。

类似的,对采购订单而言,也可以用单据分离的思路来设计逆向流程,这里我就不展开了,毕竟采购不是我司的高频业务。

发表评论

电子邮件地址不会被公开。 必填项已用*标注