序言生成后，还会继续一系列的循环，最后会送到用户手中。每个环节都有相应的操作，数据信息也要求其完整性。我们可以根据订单的每次状态变化进行计算分析，进而优化供应链路径，提高订单处理效率和用户体验。本文根据经验，从订单信息和订单状态两个方面对订单涉及的系统或业务流程进行了拆解。

1.关键字段

订单流转的效率取决于信息系统的数据流转结合仓库和快递的商品流转，因此有几个关键领域需要提前关注和了解。

2.订单信息

订单生成的时候，简单说下订单信息包括订单的基本信息和订单的产品信息，还有很多辅助信息，比如支付明细，关联用户，使用的礼品卡明细等等，如下图所示。

(1)订单基本信息

订单信息是订单的主表信息。我把它分成几个小部分:订单号、订购用户信息、订单基本信息、付款信息、收货信息、物流信息。

1)订单号:单独列出。你可能有疑问。这里有一个解释。

2)基本信息:

包括订单号的主要信息，如来源、分类、状态、所有权、仓库等。由于未来订单表的数据量将是最大的，所以每个字段的设计都需要考虑其真实含义以及是否能满足未来的扩展。

随着时间的推移和业务的快速变化和增长，有很多可能性会迫使你在未来添加字段或重新定义原有的字段，以至于在开发过程中只能不断地对这个表进行转义，大大增加了代码的复杂度。我个人比较喜欢预定义几个预留字段，所以设计的时候衡量一下利弊吧。

3)支付信息:

支付主要指订单级别使用的优惠券、礼品卡、积分和折扣。前端订单进入结算页面时，会根据相关信息进行计算和记录。同时，在核对单据时，一般遵循以下规则:订单金额-优惠券-礼品卡-积分=应付金额；订单金额=订单商品金额+运费金额；商品订单金额=商品实际售价*商品销售数量。

4)接收信息:

订单的订购用户和收货人可能不同。为了更好的提升用户体验，部分订单可以预留发货时间等。，所以这部分信息可以单独列出，也可以用附属信息保护。

5)物流信息:

这里需要记录快递公司和物流单号，关联详细物流信息调用。

(2)订单商品信息

此表是交易的详细商品信息。自然包括商品的基本信息，以及交易过程中商品的价格和优惠信息。同时还应包括商品在交易过程中所参与的活动的信息。

商品信息表是订单子表，数据量是订单表的几倍甚至十几倍。同时，订单层面的一些优惠金额需要根据商品进行分配。因为发票是基于商品信息的，所以分摊金额时要注意尾差；同时，在退货或换货时，应根据商品重新评估和计算金额。

对于退货时的重新分配和重新计算，这里有一个长篇大论的描述，是指用户下单时已经享受了订单级或商品的促销活动，退货或换货后商品发生变化时，订单级或换货的商品不能再享受促销折扣，需要重新计算折扣金额的过程。

(3)开票信息

账单信息，剪一张JD.COM的图，参考一下。

(4)付款详情

至于付款，订单生成的时候我们简单谈过。这里强调的是各种支付方式的支付明细数据。我之前说了，和钱有关的信息不能马虎，一定要记录清楚。必须有交易序列号(我公司或第三方机构的)，状态变化的过程就是支付日志。

这部分稍后会进入财务系统进行应收账款对账，发生退款时需要检查。如何设计和研究支付系统就不赘述了。官方的话是保证数据的准确性和及时性，以及出现异常后的补偿措施。在结算时，尽可能增加响应时间，即使需要1ms，用户体验也可能有很大提升。

对于付款，一般是按照母单来做。如果后续订单被拆分，相关付款信息需要通过父订单编号进行关联。

(5)物流细节

按照下面的状态分解时，还是会提到，这里只展示一张图供参考。

(6)订单明细表

这部分是根据实际业务情况设计的。比如订单支付过程中使用了购物卡，就要记录购物卡和订单号的关系，同时记录用了多少钱，余额多少，什么时候扣钱。这些需要与礼品卡系统相关联，以确保可以跟踪该用户名下礼品金额的变化。

同样，积分支付需要记录使用积分支付时有多少积分值多少钱、这个订单使用了多少积分、用户还有多少积分等时效性信息。

还是那句话，和钱有关的信息不能马虎；其他需要记录的信息，如果不方便或者不能在订单或商品表格中记录，可以附表格。但是，应该清楚的是，子表越多，代码可能越复杂，但是移动数据库和表可能越容易。

此时，即使完成了订单信息的分解，一般也会进行订单拆分，即一个订单拆分成不同的子订单，后续的履行会根据子订单进行。我们从地位的角度来梳理一下。

订单的状态，我将其分为三个部分:

下面，按照从新楼到用户签约的全过程，分别谈谈我的理解。

New: 指用户选择产品并提交后生成的新订单。订单生成前，根据用户选择的收货地址，由用户选择的库存判断、商品优惠活动、订单优惠活动、付款方式、开票信息生成。详细流程请参见电子商务后台-订单生成。

支付:当用户支付提交的订单时，需要记录支付明细。付款完成后，订单状态将变为已支付。这时候订单还需要经过几道流程才能发货。

待发货:此状态的订单可能还没有分发到仓库，也可能已经分发了。但此时，所有订单都可以取消。

看上图。理论上，订单可以在交货前的任何状态下取消(主动或被动)。

订单取消后，状态会变为已取消状态，我理解是订单的结束状态之一(已取消、无效、关闭或已签署)。

如果这里没有订单拆分，取消可以基于支付或不支付，即不涉及用户退款；如果订单是拆分的，会根据子订单取消订单，取消的过程中要判断是否可以取消，这涉及到促销、赠品或者订单分类等信息。细节我就不说了。

这里添加一个订单状态，即如果订单被拆分，父订单的状态是什么？一般设置为无效订单，也是订单的一种结束状态。

接单:该状态在WMS系统中可以定义为待分拣或其他名称，在上层系统中分配或待发货。这个时候，订单开始在WMS系统中流转，但是用户一般不会关注你具体的履行节点，他们最关心的是你是否发货。

分拣/打包/发货:这些状态都是仓库或者商家的操作流程，发货速度是用户关心的。一般上层系统只关注什么时候发货，没有及时操作会给出提醒。虽然这些状态变化在存储中，但我认为需要同步到OMS系统中，这样我们可以分析订单的及时性，也有助于售后。

正常情况下，用户或系统仍然可以在排序前取消订单，这取决于订单取消流程是如何设计的。

已发货:当仓库或商家操作发货时，订单将进入下一个状态流程，即物流状态。此时，的订单已经打包。此时，订单不允许取消。如果用户不想要，只能拦截拒绝。

物流状态信息:主要有四个节点，“已收->；在途->:已发送->签收”，这些都是对接第三方物流信息获得的。该状态信息通常与订单的主要状态分开，并记录在订单信息的物流计划中。和物流公司对接的时候，他们会有很多状态码，哪些显示给用户，哪些不显示给用户，可以根据情况进行筛选。但是最好和官方物流保持一致，因为有些用户会去官网查询，有异常就会投诉。

因为对接的是快递公司的开放接口，有些信息是脱敏的，有些信息是保存的，物流状态的更新需要及时，让用户看到最新的信息。

签收:用户收到货物后签收确认，此订单完成。如果后续涉及质量等问题，需要走售后流程。

拒绝:淘宝订单很少被拒绝，因为商家一般要求售后签收拍照才能离开(部分商品还可以)。一般放在大型垂直电商网站的自营商品都可以拒收。现在基本上没有货到付款了。前几年进货可以选择货到付款。用户对商品的使用不满意可以很舒服的拒绝，因为你没有付费。虽然现在有支付宝等第三方支付，但是拒绝的时候和快递、商家沟通比较麻烦。

货物拒收后，第三方物流是新单子，快递费谁出是个问题(用户还是商家)，一般先收后退。

写到这里应该能简单理解订单生成，根据相关状态再一次了解单据流转过程。

了解了订单信息的构成和相关状态，相信对后续业务和方案设计的理解会有一点帮助，但这些都是非常笼统的理解，并没有退货逆向流程的总结。一般设计产品时处理正向标准流程相对容易，复杂的都是逆向或异常情况的考虑。

为什么要考虑那么多异常情况？其实最重要的是责任和信任。订单后续售后退换货流程将结合客服系统进行总结。

感谢您的阅读！

作者:倔强的萝卜；微信官方账号:倔强的萝卜

本文由@倔强的萝卜原创发布。每个人都是产品经理。未经作者允许，禁止转载。

图片来自Unsplash，基于CC0协议。