订单信息与状态流转，看这一篇就够了.pdf

订单信息与状态流转，看这一篇就够了

前言订单产生后，接下来会继续进行一系列流转，最后送到用户手里。在每个环节都有对

应的操作，数据信息也要求其完成性，可以根据订单的每个状态变化，来计算分析，进而

进行优化供应链路径，以提升订单处理效率，提高用户体验。本篇就依据经验从订单信息

及订单状态两方面拆解来说下本人对订单涉及的系统或业务流程。

订单信息

1.关键字段

订单的流转效率取决于信息系统的数据流转同时结合仓库、快递的商品流转，所以有几个

关键字段要提前关注并了解。

订单是从哪流入到OMS（订单管理系统）的，这就是订单来源。不同来源的订单销卖渠道

不同，而且有的流转也是不同的，如由第三方负责发货的订单，系统是需要根据开放平台

来传递信息，对于发货、物流等控制与自营订单不同。

订单是什么类型的，因为订单类型不同，在OMS系统中处理有所不同，有的可以有跨节点，

有的可能是逆向流程，如退货订单在是从用户到商家的一个过程，它与正向订单的处理要

复杂，因为它是要根据正向订单流转过程中产生的信息进行获取再根据规则进行计算处理。

仓库，即订单来了要送到哪里去作业处理，在仓库中的流转需要有哪些标准流程，不同的

仓可能归属不同的分公司，那么在成本核算上又会有哪些不同，虽然在OMS前期不关注，

但要保证这些信息的准确性。而且对于有的商家在A仓缺货后，可能安排B仓发货即订单

转仓，不通过仓间调拨的方式，所以订单中要记录最终的发货仓。

支付状态，此字段与支付相关，不同的支付方式需要对接不同的接口，状态的回传是否及

时等等。支付状态与订单状态可以合并成一个字段。

订单状态，即在不同的操作节点上订单所处的状态，有些信息是展示给用户的，有的是

内部查看的。后续有详细的介绍。

2.订单信息

订单生成时简单说了下订单信息包括订单基本信息与订单商品信息，还包括很多附属信息，

如支付明细、关联用户、使用的礼品卡明细等等，具体如下图。

（1）订单基本信息

订单信息即订单主表信息，我这里将分为订单号、下单用户信息、订单基础信息、支付信

息、收货信息和物流信息几个小部分。

1）订单号：单独列出来了，大家可能有疑问，这里解释一下。

订单号虽然只是一个单据号，但是这个号码格式是什么样的需要经过设计，因为有的公司

订单号是年月日+序列号或随机号方式，这样设计没有什么问题，因为只要保证唯一性就

可以了。但是，对于一些公司为了避免数据泄露（如友商通过订单号分析日订单量）在单

据号格式进行了一些处理。

此外，在履单过程中，单号是流转过程中非常重要的字段，所以如果好的OMS系统可以根

据订单号进行分发流转，操作人员也可以根据单号来人为判断其订单类型或仓库等信息。

附：Amazon中国的订单号格式：C01-2442712-9062228;京东订单号：106697775485;淘宝

订单号：786699393282068525

订单号的生成是需要有一个组件支撑的，首先要能够满足订单量的增长、用户并发等要求，

其次随着数据量的增长订单表是要进行横向或纵向拆分进行分库分表，数据进行分布式存

储（有兴趣的可以看下《大众点评订单系统分库分表实践》）。我们曾开启过分库分表项

目实践，但因种种原因推进不顺利，最终仅上线了单号生成器及一些服务组件，挺遗憾的。

2）基础信息：

包括除单号的主要信息如来源、分类、状态、归属、所属仓库等，由于订单表未来是数据

量最大的，所以每个字段设计时需要考虑其真正的意义及是否能够满足未来的扩展。

随着时间的推移及业务的快速变化与增长，未来有很多种可能会迫使你去加字段或将原字

段进行二次定义，使得此表在开发过程中要进行不断转义才可以，大大增加了代码的复杂

度。个人是比较倾向于预定义几个预留字段，优劣大家在设计时去衡量吧。

3）支付信息：

支付主要是对在订单级使用的优惠券、礼品卡、积分及折扣等，在前端订单进入到结算页

时会根据相关信息进行计算并记录，同时在单据查时一般遵循：订单金额-优惠券-礼品

卡-积分=应付金额;订单金额=订单商品金额+运费金额;订单商品金额=商品实际售价*商品

售卖数量。

4）收货信息：

订单的下单用户与收货人可能是不同的，为了更好的提高用户体验，有的订单可以预约送

货时间等，所以此部分信息可以单独列出来或以附属信息进行护展。

5）物流信息：

这里需要记录快递公司及物流单号，与物流明细信息进行关联调用。

（2）订单商品信息

这个表是交易的明细商品信息，自然包括商品的基本信息，同时包括交易时的商品价格、

优惠信息，同时还应包括交易过程中商品参与的活动等信息。

商品信息表是订单从表，数据量是订单表的几倍或十