前言订单产生后，接下来会继续进行一系列流转，最后送到用户手里。在每个环节都有对应的操作，数据信息也要求其完成性，可以根据订单的每个状态变化，来计算分析，进而进行优化供应链路径，以提升订单处理效率，提高用户体验。本篇就依据经验从订单信息及订单状态两方面拆解来说下本人对订单涉及的系统或业务流程。
订单信息1.关键字段
2.订单信息
订单生成时简单说了下订单信息包括订单基本信息与订单商品信息，还包括很多附属信息，如支付明细、关联用户、使用的礼品卡明细等等，具体如下图。
（1）订单基本信息
订单信息即订单主表信息，我这里将分为订单号、下单用户信息、订单基础信息、支付信息、收货信息和物流信息几个小部分。
1）订单号：单独列出来了，大家可能有疑问，这里解释一下。
订单号虽然只是一个单据号，但是这个号码格式是什么样的需要经过设计，因为有的公司订单号是年月日+序列号或随机号方式，这样设计没有什么问题，因为只要保证唯一性就可以了。但是，对于一些公司为了避免数据泄露（如友商通过订单号分析日订单量）在单据号格式进行了一些处理。此外，在履单过程中，单号是流转过程中非常重要的字段，所以如果好的OMS系统可以根据订单号进行分发流转，操作人员也可以根据单号来人为判断其订单类型或仓库等信息。附：Amazon中国的订单号格式：C01-2442712-9062228;京东订单号：106697775485;淘宝订单号：786699393282068525订单号的生成是需要有一个组件支撑的，首先要能够满足订单量的增长、用户并发等要求，其次随着数据量的增长订单表是要进行横向或纵向拆分进行分库分表，数据进行分布式存储（有兴趣的可以看下《大众点评订单系统分库分表实践》）。我们曾开启过分库分表项目实践，但因种种原因推进不顺利，最终仅上线了单号生成器及一些服务组件，挺遗憾的。
2）基础信息：
3）支付信息：
4）收货信息：
5）物流信息：
这里需要记录快递公司及物流单号，与物流明细信息进行关联调用。
（2）订单商品信息
这个表是交易的明细商品信息，自然包括商品的基本信息，同时包括交易时的商品价格、优惠信息，同时还应包括交易过程中商品参与的活动等信息。
商品信息表是订单从表，数据量是订单表的几倍或十几倍，同时对于订单级别的一些优惠金额需要根据商品进行分摊。由于发票是根据商品信息进行的，所以在分摊金额时要注意尾差；同时在订单发生退换货时是要根据商品进行金额的重摊重算。
对于退换货时的重摊重算，这里啰嗦一下，是针对于用户下单时已经享受了订单级或商品的促销活动，当发生退货或换货后由于商品发生变化，使得订单级或换的商品不能再享受其促销优惠了，需要重新计算优惠金额的过程。
（3）开票信息
对于开票信息，从京东上截了一张图片，参考下即可。
（4）支付明细
对于支付，在订单生成时简单聊过，这里强调一下是针对于各种支付方式的支付明细数据。以前说过，涉及到钱的信息不能马虎，一定要记录清楚，要有交易流水号（我司或第三方机构的），有状态变化的过程即支付日志。
（5）物流明细
下面根据状态分解时，仍会提到，这里也只展示一张图片供参考。
（6）订单附属表
同理，积分支付需要记录使用积分支付时多少积分抵多少钱，此订单用了多少积分，用户还有多少积分余额等这些时点性的信息。
至此，对于订单信息的分解就算完成了，订单一般都会经过拆单即一个订单会拆分成不同的子订单，后续的履单都是根据子订单进行的，下面从状态的角度再来梳理下。
订单状态
订单的状态，我将其分为三部分：
下面，按照新建到用户签收这一个完整过程来分别说下我的理解。
新建：即用户选择商品后，提交后产生的新订单。订单产生前是根据用户选择的收货地址进行商品的库存判断、商品的优惠活动、订单的优惠活动以及用户选择的支付方式、开票信息等生成的，详细过程大家可以参照《电商后台-订单生成》。
支付：用户支付已提交的订单，这时就需要记录支付的详细信息，支付完成后，订单状态就变为已支付，此时订单距离发货还需要经历几个过程。
待发货：在此状态的订单有可能没有下发到仓库，也可能已经下发了。但在此时，订单都是可以取消的。
看上面的图中，订单在发货前每个状态理论上都可以取消（用户主动或被动）。
订单取消后，状态就变为取消状态，这个状态我理解为是订单的终结状态中一个（取消、无效、关闭或签收）。
在此取消订单如果没有发生拆单，则可以根据支付或未支付进行，即涉不涉及用户退款;如果发生拆单，则订单是要根据子订单进行取消了，而且在取消过程中是否要判断是否可以取消，这就涉及促销或赠品或订单分类等信息，细节不说了。
这里补充一个订单状态，即如果订单发生拆单后其父订单的状态是什么？一般设置为无效订单，这个也是订单的一个终结状态。
一般情况下，在订单还没有开始分拣时，用户或系统仍然可以取消的，具体看订单取消的环节是如何设计的。
已发货：当仓库或商家操作发货后，订单便进入到下一个状态过程，即物流状态。此时的订单已经打包完成了，此时订单是不允许取消了，如果用户不要，那么只能进行拦截进行拒收处理。
物流状态信息：主要是四个节点，“已揽收->运输中->已派件->已签收”，这些都是对接第三方物流信息获取的。这些状态信息一般与订单主状态是分离的，记录在订单信息中的物流明细表中。在与物流公司对接时，它们会有很多状态码，哪些展示给用户，哪些不展示给用户可以根据情况进行筛选。但最好与物流的官方保持一致，因为有的用户会去快递的官网查询，如果有异常会进行投诉。
由于对接的是快递公司的开放接口，有些信息是要进行脱敏的，有些信息是要保存的，物流状态的更新需要及时，以便让用户看到最新信息。
签收：用户收到货后签字确认，此单完成。如果后续涉及质量等问题，就需要走售后流程。
拒收：淘宝订单一般很少有拒收，因为商家一般都要求先签收拍照后走售后（有的商品可以）。在大的垂直电商网站下单一般自营商品可以拒收。现在基本上没有货到付款了，在几年前购买商品可以选择货到付款，对于商品用问题或不满意的用户可以非常坦然的拒收，因为你没有付钱。虽然现在有支付宝等第三方支付了，但是拒收时涉及到与快递、商家三方的沟通，也是比较麻烦的。
商品拒收后，对于第三方物流是属于一个新的单子，快递费谁支付（用户还是商家）是个问题，所以一般都是先签收后退。
总结
为什么要考虑这么多的异常情况呢？其实最主要的还是责任及信任。后续针对订单的售后退换货流程结合客服系统再进行总结。