COD问题的基础--订单结构设计

还是COD这个话题，今天抠一下细节，关于COD订单的基础结构设计。

如果在搭建系统时候，PHP作为基础语言的话，Woo Commerce或者Magento作为底层都是不错的选择，能节省不少时间，Java的话，主流的选择会少一些。但是在订单这块依旧还是

需要一定的优化来满足COD的业务需求，更多的是对字段的理解与运用。

COD常见问题

COD不同于常规在线支付的模式的有这么几点问题：

• COD订单未付款状态，常规ERP逻辑无法进入发货流程，需要定制修改
• 订单的流失情况有多种，结构不合理，则会数据混乱，很难系统化分析
• 订单涉及到妥投资金回款的统计问题，系统不到位，只能大量人工弥补

那么我们来分析一下：

单看第一个问题好解决，只要调整ERP的处理逻辑就好，但问题在于后两者。

先看第二个问题，COD订单的流失分析是至关重要的，我们按照时间梳理一下订单的常见状态，按照常规的支付方式，有两个业务线：Online & COD

Online的业务线比较常规：

1. 下单后待付款

2. 下单支付失败订单超时

3. 下单后付款成功

4. 发货前用户取消订单

5. 配货待发货

6. 发货在途

7. 签收后退货

8. 签收妥投归档

COD可能就会有些特别：

1. 下单后订单生成

2. 下单后用户自己取消

3. 客服审单后取消

4. 审单进入ERP待处理

5. 配货待发货

6. 发货在途

7. 投递后拒收

8. 签收后退货

9. 签收妥投归档

因为我们要找问题，优化业务，就需要精准的数据来支持。我们需要一个能把两者兼容到一起的结构设计，能够在任何时间，知道任何一个订单发生了什么，就像树的“年轮”一样。

常规来看，我们一定会有“支付状态”字段，“物流状态”字段，然后增加一个“状态”字段，来标记订单的各类情况，然后发现审单没法标记，就再加一个“审批状态”字段来标记，随着业务需要，再不断地增加字段来控制。那么这么设计跑业务是没问题，分析的时候就会懵圈了，因为无法完全了解到订单的真实状态，“状态”字段的值会异常的多，一方面在后期资金统计的时候会让人懵圈，另一方面用户端的订单状态也很难调和。

接下来看第三个问题，那就是涉及的订单资金统计问题，每个订单会有很多关于“钱”的信息，比如：

• 商品单价
• 订单总价
• 订单折扣
• 订单物流费
• 订单税费
• COD代收款费用
• 收回实际款项
• 退款额度等等

S2B2C模式还会有：B的价格和C的价格两套价格体系，以及COD代收款的利润返还计算等等。

我们在进行系统结构调研讨论的时候，很多印度公司的底层结构设计和中国不同，很难说是文化差异还是什么原因，比如部分公司，在线订单付款失败后不会在后台生成待支付订单，只能重新下单；有的公司不存在主订单和子订单的概念等等。

解决思路，换一个角度思考

我们来观察以上的思维方式，是贴近业务的思路，但是因为业务的复杂性，我们需要能更加底层角度来思考，就像计算机虽然只有二进制，但可以完成如今我们在电脑上所有的操作一样，自己的推演：

• 电商涉及到三大流，物流、金流、信息流，我们无非是把这三大流搞定。
• 主订单和子订单的分工，主订单一定承载的是整体的状态，子订单承载的是信息，信息决定状态
• 跳出单字段的一维逻辑，1+1>2，多字段完全可以排列组合承载更多的信息
• 用户端和后台的订单状态逻辑无需完全一样，底层信息足够，完全可以做的真正的用户友好，操作员工也是用户。 

架构设计案例

那么实操层面，谈一下自己的想法，其实：支付渠道Channel、支付状态Payment、发货状态Fulfillment、主状态Status，四个字段足够表达所有的业务状况，但是需要换个角度来理解：

1. Channel：这个最简单，具体标记订单的渠道来源，用来隔离不同支付类型的业务订单，值可以只有2个：CODOnline，后期也可以引入Online的具体网关。
2. Payment：资金状态，这个最常见，但是这个最需要重新定义和理解，因为支付与否不是业务直接触发状态改变，而是子订单的信息来决定，子订单信息的改变，触发该状态的改变，记录的是资金流的情况。
3. Fulfillment：发货状态，该字段反应发货状态，同理，该字段的改变不是业务直接触发，而是子订单信息来触发改变，记录的是物流的改变。
4. Status：总状态，该字段不是用于标记业务状态，而是更加宏观的来标记订单的终极状态，决定订单的可编辑性，以及财务结算分割。

那么接下来，我们把上文提到的两条业务线融入到这个多元状态的体系中来看一下效果：

如上图，可以看到，基本所有的订单状态基本涵盖在其中，而图中填充颜色的部分是终结状态，无填充的则为过程状态。在系统后台则完全可以按照这个方式追踪到所有订单的状态，也可以轻松计算出“签收率”，“退货率”，以及这些订单对应的资金状态和数额，扩展分析也是非常的自由，不在话下。

这次就写这么多，以上是自己的一些粗浅的思考，欢迎大家交流指正。