订单系统作为电商系统的“中轴线”贯穿了整个电商系统的全部流程。所有的核心系统都是围绕订单进行构建的。订单的发展也是随着电商、O2O行业发展逐渐演变进化的，今天跟大家来解构下这个平台的“生命中轴线”。

　　订单基本概念

　　设计订单系统时包含几个大的方向需要考虑，这些内容决定了订单系统的稳定性和可持续性。

　　订单字段

　　订单字段包含了订单中需要记录的信息，他的作用主要用于沟通其他系统，为下游系统提供信息依据。

　　订单信息

　　订单号作为订单识别的标识，往往由一串数字组成，根据订单的增加进行自增，也可以在设计订单号的时候考虑订单加密设置(否则别人通过订单编号就能计算出你们家的销售量)。订单号后续用作订单唯一标示用于对接WMS和TMS时的订单识别。

　　订单状态机在下面章节会详细描述，这里不做展开。

　　用户信息

　　这里指购买人的相关信息，主要包括姓名、地址、手机号。O2O还会多一种情况就是自提点，这样地址则会变为自提点的地址。地址信息在后续会作用在WMS和TMS上用于区分区域和配送安排。

　　购买商品信息

　　这里指购买商品的基本信息和库存，金额由于比较特殊所以我把金额独立在商品信息以外说，不过逻辑上其实都属于商品信息范畴。商品信息主要影响库存更新和WMS生产。

　　金额信息

　　订单产生的商品信息，这里面除了要记录最终的金额，过程金额也需要记录。比如商品分摊的优惠金额、支付金额，应付金额等。在后续的订单结算、退换货、财务等环节都需要使用。

　　时间信息

　　记录订单每个节点的触发时间。

　　订单流程

　　订单流程是指整个订单从产生到完成整个流转过程。他包括正向流程和逆向流程。

　　正向流程

　　订单正常生产到配送的过程。这里面列举的模块是一般电商通用的功能，部分可能根据实际业务场景有所增加调整。020场景下出库、合包裹、发票准备等工作是由商家方进行，部分工作是属于线下场景。

　　整个流程涉及到的环节非常多。这里面提几个细节上需要注意的地方：

　　订单生成环节存在超时未支付自动取消的过程。库存的占用会在订单取消后释放。

　　如果选择COD(货到付款)则支付环节相应转移到订单配送之后，而过程中所有与款项相关的逻辑变为只操作金额数字，不对结算和账户进行打退款操作。

　　金额分摊需要到品，这个在之前解构电商、O2O用户端“背后”的逻辑中有说明，这里就不细说了。

　　订单系统审核主要用户对恶意用户或者刷单情况进行处理。系统可根据白名单、黑名单、消费频次、促销品购买量当方面做风控规则。如果后续会进入到人工审核，则规则上可以适当从宽。当触发规则需要进行订单退订的行为。此处设计时要小心对用户体验的损害，往往前台文案上说明当前节点是审核状态或者是等待接单。

　　在O2O领域有催单的概念，而传统电商则是通过关联第三方物流的物流信息进行跟踪。催单触发考虑到实际场景，一般会设定一定的时间间隔，间隔时间内只触发一次催单的请求。

　　预售等货和移仓需要做成SOA服务，以便在交易页面计算预计时间和预计到货时间。移仓处理依赖仓库的情况，也会涉及到后续拆分和合并包裹的逻辑。

　　订单生产时先要判断报缺情况，如果出现报缺问题则要考虑整单报缺、部分报缺、换货或者换转退的情况(库存，仓促调拨和退款)。报缺情况分为系统报缺和实物报缺，这是承接但相对独立的两个环节。

　　电商系统要考虑7天无理由退货的情景，即订单状态完成后申请退货。此时主要涉及的是金额上的计算以及一些财务程序(如发票等)问题的处理。

　　逆向流程

　　逆向流程则指订单发生取消、退货等情况时引发的订单流程过程。在设计逆向流程时建议和正向独立分开，通过订单号等信息进行关联，避免耦合过多逻辑无法延展设计。

　　逆向流程的触发主要有几种情况

　　用户自主取消订单(整单)

　　风控系统触发取消订单(整单)

　　客服接到客诉仲裁后触发取消订单(整单)

　　超时未支付取消订单(整单)

　　换货报缺转为退单(整单、部分报缺)

　　触发条件考虑两个方面

　　订单状态机(某一节点后如订单生产后不允许取消订单)

　　订单生成时间(主要是O2O方面，考虑到配送时间和线下流程的不规范，有可能出现状态机没触发更新但实际流程在流转的情况)

　　其他要注意的一些内容

　　当退单被商家拒绝后需要转入客服仲裁的环节

　　部分退的订单促销一般保持享用状态，但金额按照分摊的金额进行退款。

　　订单状态机

　　关于状态机，我在百度上搜索了下定义。