订单系统作为电商系统的“中轴线”贯穿了整个电商系统的全部流程。所有的核心系统都是围绕订单进行构建的。订单的发展也是随着电商、O2O行业发展逐渐演变进化的，今天跟大家来解构下这个平台的“生命中轴线”。
订单基本概念
设计订单系统时包含几个大的方向需要考虑，这些内容决定了订单系统的稳定性和可持续性。订单字段
订单字段包含了订单中需要记录的信息，他的作用主要用于沟通其他系统，为下游系统提供信息依据。
订单流程
订单流程是指整个订单从产生到完成整个流转过程。他包括正向流程和逆向流程。正向流程订单正常生产到配送的过程。这里面列举的模块是一般电商通用的功能，部分可能根据实际业务场景有所增加调整。020场景下出库、合包裹、发票准备等工作是由商家方进行，部分工作是属于线下场景。
订单生成环节存在超时未支付自动取消的过程。库存的占用会在订单取消后释放。
如果选择COD（货到付款）则支付环节相应转移到订单配送之后，而过程中所有与款项相关的逻辑变为只操作金额数字，不对结算和账户进行打退款操作。
金额分摊需要到品，这个在之前解构电商、O2O用户端“背后”的逻辑中有说明，这里就不细说了。
订单系统审核主要用户对恶意用户或者刷单情况进行处理。系统可根据白名单、黑名单、消费频次、促销品购买量当方面做风控规则。如果后续会进入到人工审核，则规则上可以适当从宽。当触发规则需要进行订单退订的行为。此处设计时要小心对用户体验的损害，往往前台文案上说明当前节点是审核状态或者是等待接单。
在O2O领域有催单的概念，而传统电商则是通过关联第三方物流的物流信息进行跟踪。催单触发考虑到实际场景，一般会设定一定的时间间隔，间隔时间内只触发一次催单的请求。
预售等货和移仓需要做成SOA服务，以便在交易页面计算预计时间和预计到货时间。移仓处理依赖仓库的情况，也会涉及到后续拆分和合并包裹的逻辑。
订单生产时先要判断报缺情况，如果出现报缺问题则要考虑整单报缺、部分报缺、换货或者换转退的情况（库存，仓促调拨和退款）。报缺情况分为系统报缺和实物报缺，这是承接但相对独立的两个环节。
电商系统要考虑7天无理由退货的情景，即订单状态完成后申请退货。此时主要涉及的是金额上的计算以及一些财务程序（如发票等）问题的处理。
用户自主取消订单（整单）
风控系统触发取消订单（整单）
客服接到客诉仲裁后触发取消订单（整单）
超时未支付取消订单（整单）
换货报缺转为退单（整单、部分报缺）
订单状态机（某一节点后如订单生产后不允许取消订单）
订单生成时间（主要是O2O方面，考虑到配送时间和线下流程的不规范，有可能出现状态机没触发更新但实际流程在流转的情况）
当退单被商家拒绝后需要转入客服仲裁的环节
部分退的订单促销一般保持享用状态，但金额按照分摊的金额进行退款。
订单状态机
关于状态机，我在百度上搜索了下定义。关于状态机的一个极度确切的描述是它是一个有向图形，由一组节点和一组相应的转移函数组成。状态机通过响应一系列事件而“运行”。每个事件都在属于“当前” 节点的转移函数的控制范围内，其中函数的范围是节点的一个子集。函数返回“下一个”（也许是同一个）节点。这些节点中至少有一个必须是终态。当到达终态， 状态机停止。由上述定义可以看到，状态机的概念是用来表示按照一定的方向通过触发不同节点产生数据流转的过程。在订单中通过情景触发订单状态的变化来表达订单流转的过程就是订单状态机。电商
订单推送
当状态机发生变化时，需要将对应的变化情况告知给相关人员以便了解当前订单的情况。这就是订单推送的作用。 订单推送的触发依赖于状态机的变化，涉及到的信息包括推送对象（用户、物流人员、商家）
推送方式（push，短信）
推送节点（状态机）
订单的演变
电商平台的搭建变迁也是订单逐步稳固发展的过程。我们来看下订单的发展过程，结算环节由于是一个比较大的话题，这里面不展开说明了。订单第一阶段：实现订单流转
平台搭建的第一阶段要实现基本的订单流转，支持一些营销活动的购买（这里依赖附属系统的搭建情况，这里默认认为具备基本功能）。实现订单的生成、生产
支持订单审核（初期可支持人工审核即可）
支持用户端显示订单相关信息
支持促销金额的计算
母单负责订单整体信息的记录
子单记录单个商品的详细信息和金额情况
订单第二阶段：平台化搭建
随着平台的发展，越来越多的接入方需要订单的支持，POP平台的商家接入、第三方仓配的接入，更多快递合作伙伴的接入等等。订单的功能进入第二阶段的扩充。提供订单soa服务
支持跨平台交易单生成（即同一个大交易单内既有商家商品又有自营商品或者是多个商家的商品）
对接多个仓库，支持移仓模式
根据仓配情况计算预计送达时间（订单promise服务）
支持拆单、合单逻辑（配送单、支付单等）
支持快递分单
提供更丰富的订单推送服务，完善订单状态机
订单子母单结构，便于将信息进行梳理，减少耦合
拆单、合单逻辑主要是用于解决不同系统之间的耦合问题（如配送单主要运用于TMS，支付单提交给支付系统）。他们都通过交易订单信息项重新组合后添加部分自有系统的信息项而组成，通过订单编号来做关联。交易单和支付单是1：1，交易单和物流单也叫配送单则可能是N:N的关系。
移仓的逻辑和预计送达时间要依赖仓配结构和运输能力的测算，当然也可以通过拆包裹分多次发的方式减少移仓的次数，不过要考虑要前台用户体验和免责说明。
当自营品和商家品或者多个商家品的时候，优惠券的分摊计算要注意。要区分商家券和全场通用券可分摊的比例和优先级。
订单第三阶段：更多类型的订单模式
当平台发展到足够大的规模，提效、稳定变成一个重要的话题。这里面介绍两种情况：预售场景：无实物库存，但是顾客可以下单预定。当实物到货后，按照正常订单进行配送。 预售单需要设置预售库存数和预计到货时间。用户下单后不会直接进入生产，将预售订单放入单独的订单库（或增加预售品标识）。 预售商品到货后要判断涉及到货库存和预售订单是否相等。当实际库存小雨预售订单则按下单时间释放等量订单进行生产。系统需要回告库存系统重新计算预售占用库存量。JIT(准时制生产方式 Just In Time 简称JIT）场景：销售驱动生产，根据订单进行生产配送。JIT模式需要设定JIT波次情况和支持JIT的仓库
相同JIT仓库订单按照JIT波次时间点汇总订单并驱动产生ERP采购订单；JIT和目标仓告诉采销系统
ERP到货回告订单系统已到货
订单释放进入WMS生产
订单告知ERP，生成采购单直接回告供应商
供应商物流状态对应订单状态机进行同步更新
用户收货后通过邮寄方式提供发票
该模式不支持换货行为
结言
订单是电商、020的生命中轴线，他主导、串联了整个全部链路的系统。所有的系统都是围绕订单进行改建和扩张的。订单系统的强壮决定了平台的稳定性。高晖：10余年IT经验，互联网老兵。多年电商公司经历，曾参与过B2B,B2C,O2O等多个方向的电商项目，熟悉电商整体流程情况。曾就职当当网、到家美食会、美菜网等公司。现就职饿了么，目前负责新零售部门早餐业务的产品线工作。微信号公众号@杂谈暖阁。本文由专栏作者 @高晖 授权发布于产品社区，未经许可，禁止转载。
爱盈利-运营小咖秀（aiyingli.com）始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容；是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台；
【转载说明】 若上述素材出现侵权，请及时联系我们删除及进行处理：8088013@qq.com
