前言订单产生后，接下来会继续进行一系列流转，最后送到用户手里。在每个环节都有对应的操作，数据信息也要求其完成性，可以根据订单的每个状态变化，来计算分析，进而进行优化供应链路径，以提升订单处理效率，提高用户体验。本篇就依据经验从订单信息及订单状态两方面拆解来说下本人对订单涉及的系统或业务流程。
1. 关键字段
订单的流转效率取决于信息系统的数据流转同时结合仓库、快递的商品流转，所以有几个关键字段要提前关注并了解。
订单是从哪流入到OMS（订单管理系统）的，这就是订单来源。不同来源的订单销卖渠道不同，而且有的流转也是不同的，如由第三方负责发货的订单，系统是需要根据开放平台来传递信息，对于发货、物流等控制与自营订单不同。
订单是什么类型的，因为订单类型不同，在OMS系统中处理有所不同，有的可以有跨节点，有的可能是逆向流程，如退货订单在是从用户到商家的一个过程，它与正向订单的处理要复杂，因为它是要根据正向订单流转过程中产生的信息进行获取再根据规则进行计算处理。
仓库，即订单来了要送到哪里去作业处理，在仓库中的流转需要有哪些标准流程，不同的仓可能归属不同的分公司，那么在成本核算上又会有哪些不同，虽然在OMS前期不关注，但要保证这些信息的准确性。而且对于有的商家在A仓缺货后，可能安排B仓发货即订单转仓，不通过仓间调拨的方式，所以订单中要记录最终的发货仓。
支付状态，此字段与支付相关，不同的支付方式需要对接不同的接口，状态的回传是否及时等等。支付状态与订单状态可以合并成一个字段。
订单状态，即在不同的操作节点上订单所处的状态，有些信息是展示给用户的，有的是内部查看的。后续有详细的介绍。
订单生成时简单说了下订单信息包括订单基本信息与订单商品信息，还包括很多附属信息，如支付明细、关联用户、使用的礼品卡明细等等，具体如下图。
订单信息即订单主表信息，我这里将分为订单号、下单用户信息、订单基础信息、支付信息、收货信息和物流信息几个小部分。
1）订单号：单独列出来了，大家可能有疑问，这里解释一下。
订单号虽然只是一个单据号，但是这个号码格式是什么样的需要经过设计，因为有的公司订单号是年月日+序列号或随机号方式，这样设计没有什么问题，因为只要保证唯一性就可以了。但是，对于一些公司为了避免数据泄露（如友商通过订单号分析日订单量）在单据号格式进行了一些处理。
此外，在履单过程中，单号是流转过程中非常重要的字段，所以如果好的OMS系统可以根据订单号进行分发流转，操作人员也可以根据单号来人为判断其订单类型或仓库等信息。附：Amazon中国的订单号格式：C01-2442712-9062228 ;京东订单号：106697775485;淘宝订单号：786699393282068525
订单号的生成是需要有一个组件支撑的，首先要能够满足订单量的增长、用户并发等要求，其次随着数据量的增长订单表是要进行横向或纵向拆分进行分库分表，数据进行分布式存储（有兴趣的可以看下《大众点评订单系统分库分表实践》）。我们曾开启过分库分表项目实践，但因种种原因推进不顺利，最终仅上线了单号生成器及一些服务组件，挺遗憾的。
2）基础信息：
包括除单号的主要信息如来源、分类、状态、归属、所属仓库等，由于订单表未来是数据量最大的，所以每个字段设计时需要考虑其真正的意义及是否能够满足未来的扩展。
随着时间的推移及业务的快速变化与增长，未来有很多种可能会迫使你去加字段或将原字段进行二次定义，使得此表在开发过程中要进行不断转义才可以，大大增加了代码的复杂度。个人是比较倾向于预定义几个预留字段，优劣大家在设计时去衡量吧。
3）支付信息：
支付主要是对在订单级使用的优惠券、礼品卡、积分及折扣等，在前端订单进入到结算页时会根据相关信息进行计算并记录，同时在单据查时一般遵循：订单金额 -优惠券-礼品卡-积分=应付金额;订单金额=订单商品金额+运费金额;订单商品金额=商品实际售价*商品售卖数量。
4）收货信息：
订单的下单用户与收货人可能是不同的，为了更好的提高用户体验，有的订单可以预约送货时间等，所以此部分信息可以单独列出来或以附属信息进行护展。
5）物流信息：
这里需要记录快递公司及物流单号，与物流明细信息进行关联调用。
这个表是交易的明细商品信息，自然包括商品的基本信息，同时包括交易时的商品价格、优惠信息，同时还应包括交易过程中商品参与的活动等信息。
商品信息表是订单从表，数据量是订单表的几倍或十几倍，同时对于订单级别的一些优惠金额需要根据商品进行分摊。由于发票是根据商品信息进行的，所以在分摊金额时要注意尾差；同时在订单发生退换货时是要根据商品进行金额的重摊重算。
对于退换货时的重摊重算，这里啰嗦一下，是针对于用户下单时已经享受了订单级或商品的促销活动，当发生退货或换货后由于商品发生变化，使得订单级或换的商品不能再享受其促销优惠了，需要重新计算优惠金额的过程。
（3）开票信息
对于开票信息，从京东上截了一张图片，参考下即可。
（4）支付明细
对于支付，在订单生成时简单聊过，这里强调一下是针对于各种支付方式的支付明细数据。以前说过，涉及到钱的信息不能马虎，一定要记录清楚，要有交易流水号（我司或第三方机构的），有状态变化的过程即支付日志。
此部分后续会进入到财务系统进行应收对账，同时发生退款时需要检验。对于支付系统如何设计与研发就不啰嗦了，官方的话就是要保证数据的准确、及时以及发生异常后的补偿措施；在结算时要尽可能提升响应时间，哪怕1ms也可能大大提升用户体验。
对于支付，一般都是按父订单进行的，后续如果发生拆单，则相关的支付信息还需要通过父单号进行关联。
（5）物流明细
下面根据状态分解时，仍会提到，这里也只展示一张图片供参考。
（6）订单附属表
此部分是根据实际业务情况进行设计，譬如订单支付过程使用了礼品卡，那么就需要记录礼品卡与订单号的关系，同时记录使用了多少钱，余额是多少，什么时间扣款的，这些需要与礼品卡系统进行关联，以保证此用户名下的礼品的金额变化是有迹可循的。
同理，积分支付需要记录使用积分支付时多少积分抵多少钱，此订单用了多少积分，用户还有多少积分余额等这些时点性的信息。
还是那句话，与钱相关的信息马虎不得；对于其它需要记录的信息，如果不方便或不能记录在订单请表或商品表中，都可以通过附加表方式。但要清楚附属表越多，代码可能会复杂，但对于迁库迁表可能会容易些。
至此，对于订单信息的分解就算完成了，订单一般都会经过拆单即一个订单会拆分成不同的子订单，后续的履单都是根据子订单进行的，下面从状态的角度再来梳理下。
订单状态
订单的状态，我将其分为三部分：
用户相关的状态，即用户在我的订单中可以查看跟踪的订单状态变化；
仓库/商家的状态，是指订单分配到仓库或商家后，在其作业过程中产生的状态；
物流状态，即仓库/商家发货后，包裹发货到用户签收过程中的相关状态。
下面，按照新建到用户签收这一个完整过程来分别说下我的理解。
新建：即用户选择商品后，提交后产生的新订单。订单产生前是根据用户选择的收货地址进行商品的库存判断、商品的优惠活动、订单的优惠活动以及用户选择的支付方式、开票信息等生成的，详细过程大家可以参照《电商后台-订单生成》。
支付：用户支付已提交的订单，这时就需要记录支付的详细信息，支付完成后，订单状态就变为已支付，此时订单距离发货还需要经历几个过程。
拉单服务：是将前端服务器产生的订单拉取到后端生产库（一般也叫内部ERP库），这个就是要求快，不能有订单的积压。
拆单服务：折单分为两部分，在前端下单时会进行预拆单，即将不同的商品根据规则进行分堆打标，供后续的拆单服务使用。拆单是在支付完成后进行的，这时会根据商品的属性、配送条件要求或是否缺货等原因进行拆分，这时是将商品进行分堆，然后生成子订单，一般订单主表的相关金额信息会根据子订单的商品重新计算。拆单规则有很多，此篇不深入梳理了。
订单下发服务：WMS系统是与OMS系统或ERP分离的，如果使用第三方的仓储系统，数据的传输是必不可少的。对于单据的下发与状态回传系统是如何设计的，目前都是定时任务+消息队列的方式进行。订单可以根据仓库下发的WMS系统，也可以通过开放平台传递给合作商家由其进行发货。在京东上下单完成后，你会清楚的看到类似如下系统消息“您的订单已经分配到XXX仓库……”给用户。
订单拦截服务，在用户创建订单或支付后，在没有拆单前，还应该有一个订单拦截服务。此服务的目的是进行恶意订单的判断，对于特殊订单的审核，这都依赖于相关规则设置。当订单拦截后，订单可能会被强制取消，目的是为了释放库存或避免用户刷单，这个过程有的被称之为订单的回滚期，我理解就类似于回收站一样。
待发货：在此状态的订单有可能没有下发到仓库，也可能已经下发了。但在此时，订单都是可以取消的。
看上面的图中，订单在发货前每个状态理论上都可以取消（用户主动或被动）。
订单取消后，状态就变为取消状态，这个状态我理解为是订单的终结状态中一个（取消、无效、关闭或签收）。
在此取消订单如果没有发生拆单，则可以根据支付或未支付进行，即涉不涉及用户退款;如果发生拆单，则订单是要根据子订单进行取消了，而且在取消过程中是否要判断是否可以取消，这就涉及促销或赠品或订单分类等信息，细节不说了。
这里补充一个订单状态，即如果订单发生拆单后其父订单的状态是什么？一般设置为无效订单，这个也是订单的一个终结状态。
接收订单：这个状态在WMS系统中可能定义为待分拣或其它名称，在上位系统就是已下发或待发货。此时订单就开始在WMS系统中进行流转了，但用户一般不会关注你具体的履单节点，他最关心的是你发货还是没发。
分拣/打包/发货：这几个状态都是仓储或商家的作业过程，其发货速度是用户关注的，一般上位系统只关注于何时发货，如果没有及时操作会进行提醒。对于这些状态的变化，虽然是仓储中的，但是我认为需要同步到OMS系统中，这样可以分析订单的时效，而且对于售后也是有帮助的。
一般情况下，在订单还没有开始分拣时，用户或系统仍然可以取消的，具体看订单取消的环节是如何设计的。
已发货：当仓库或商家操作发货后，订单便进入到下一个状态过程，即物流状态。此时的订单已经打包完成了，此时订单是不允许取消了，如果用户不要，那么只能进行拦截进行拒收处理。
物流状态信息：主要是四个节点，“已揽收->运输中->已派件->已签收”，这些都是对接第三方物流信息获取的。这些状态信息一般与订单主状态是分离的，记录在订单信息中的物流明细表中。在与物流公司对接时，它们会有很多状态码，哪些展示给用户，哪些不展示给用户可以根据情况进行筛选。但最好与物流的官方保持一致，因为有的用户会去快递的官网查询，如果有异常会进行投诉。
由于对接的是快递公司的开放接口，有些信息是要进行脱敏的，有些信息是要保存的，物流状态的更新需要及时，以便让用户看到最新信息。
签收：用户收到货后签字确认，此单完成。如果后续涉及质量等问题，就需要走售后流程。
拒收：淘宝订单一般很少有拒收，因为商家一般都要求先签收拍照后走售后（有的商品可以）。在大的垂直电商网站下单一般自营商品可以拒收。现在基本上没有货到付款了，在几年前购买商品可以选择货到付款，对于商品用问题或不满意的用户可以非常坦然的拒收，因为你没有付钱。虽然现在有支付宝等第三方支付了，但是拒收时涉及到与快递、商家三方的沟通，也是比较麻烦的。
商品拒收后，对于第三方物流是属于一个新的单子，快递费谁支付（用户还是商家）是个问题，所以一般都是先签收后退。
写到这里应该可以简单的了解了订单生成后，根据相关的状态再一次了解了单据流转过程。
总结
了解了订单信息的组成以及相关的状态，相信对于后续业务的理解与方案设计会有一点点帮助，但这些都是非常泛的理解，对于退货的逆向流程也没有总结，在设计产品时一般对于正向的标准流程处理基本都是比较容易的，复杂的都是逆向或异常情况的考虑。
为什么要考虑这么多的异常情况呢？其实最主要的还是责任及信任。后续针对订单的售后退换货流程结合客服系统再进行总结。
感谢您的阅读！
