订单基本概念

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

订单栏位

订单栏位包含了订单中需要记录的资讯，他的作用主要用于沟通其他系统，为下游系统提供资讯依据。

订单资讯

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

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

使用者资讯

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

购买商品资讯

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

金额资讯

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

时间资讯

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

 

订单流程

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

正向流程

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

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

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

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

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

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

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

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

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

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

逆向流程

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

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

使用者自主取消订单（整单）

风控系统触发取消订单（整单）

客服接到客诉仲裁后触发取消订单（整单）

超时未支付取消订单（整单）

换货报缺转为退单（整单、部分报缺）

触发条件考虑两个方面

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

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

其他要注意的一些内容

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

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

 

订单状态机

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

关于状态机的一个极度确切的描述是它是一个有向图形，由一组节点和一组相应的转移函式组成。状态机通过响应一系列事件而 “执行” 。每个事件都在属于 “当前” 节点的转移函式的控制范围内，其中函式的范围是节点的一个子集。函式返回 “下一个”（也许是同一个）节点。这些节点中至少有一个必须是终态。当到达终态， 状态机停止。

由上述定义可以看到，状态机的概念是用来表示按照一定的方向通过触发不同节点产生资料流转的过程。在订单中通过情景触发订单状态的变化来表达订单流转的过程就是订单状态机。

电商

O2O

电商和 O2O 的主体流程是相同的，不同的在于物流配送环节电商较 O2O 更为复杂，此处只表明了主要的订单状态机，仓储物流内的物流单流转不在此范围内。状态机原则上使用结果值而不使用过程值，比如使用支付成功作为节点而不使用支付中作为节点。

订单状态机要融合订单流程来设计触发节点，订单流程的逻辑点要多于状态机，一般在当前流程环节完成后最后更新状态机。

 

订单推送

当状态机发生变化时，需要将对应的变化情况告知给相关人员以便了解当前订单的情况。这就是订单推送的作用。

订单推送的触发依赖于状态机的变化，涉及到的资讯包括

推送物件（使用者、物流人员、商家）

推送方式（push，简讯）

推送节点（状态机）

 

订单的演变

电商平台的搭建变迁也是订单逐步稳固发展的过程。我们来看下订单的发展过程，结算环节由于是一个比较大的话题，这里面不展开说明了。

 

订单第一阶段：实现订单流转

平台搭建的第一阶段要实现基本的订单流转，支援一些营销活动的购买（这里依赖附属系统的搭建情况，这里预设认为具备基本功能）。

实现订单的生成、生产

支援订单稽核（初期可支援人工稽核即可）

支援使用者端显示订单相关资讯

支援促销金额的计算

这个阶段搭建时核心是解决订单的基本流转，所以原则上一些功能可以后续再逐步完善。比如催单、拆单、系统稽核等。

另外在搭建订单结构的时候如果条件允许，在设计之初可以就考虑用子母单的形式，即两层结构

母单负责订单整体资讯的记录

子单记录单个商品的详细资讯和金额情况

 

订单第二阶段：平台化搭建

随著平台的发展，越来越多的接入方需要订单的支援，POP 平台的商家接入、第三方仓配的接入，更多快递合作伙伴的接入等等。订单的功能进入第二阶段的扩充。

提供订单 soa 服务

支援跨平台交易单生成（即同一个大交易单内既有商家商品又有自营商品或者是多个商家的商品）

对接多个仓库，支援移仓模式

根据仓配情况计算预计送达时间（订单 promise 服务）

支援拆单、合单逻辑（配送单、支付单等）

支援快递分单

提供更丰富的订单推送服务，完善订单状态机

这里说几个订单复杂化以后需要注意的细节

订单子母单结构，便于将资讯进行梳理，减少耦合

拆单、合单逻辑主要是用于解决不同系统之间的耦合问题（如配送单主要运用于 TMS，支付单提交给支付系统）。他们都通过交易订单资讯项重新组合后新增部分自有系统的资讯项而组成，通过订单编号来做关联。交易单和支付单是 1：1，交易单和物流单也叫配送单则可能是 N:N 的关系。

移仓的逻辑和预计送达时间要依赖仓配结构和运输能力的测算，当然也可以通过拆包裹分多次发的方式减少移仓的次数，不过要考虑要前台使用者体验和免责说明。

当自营品和商家品或者多个商家品的时候，优惠券的分摊计算要注意。要区分商家券和全场通用券可分摊的比例和优先顺序。

 

订单第三阶段：更多型别的订单模式

当平台发展到足够大的规模，提效、稳定变成一个重要的话题。这里面介绍两种情况：

预售

场景：无实物库存，但是顾客可以下单预定。当实物到货后，按照正常订单进行配送。

预售单需要设定预售库存数和预计到货时间。使用者下单后不会直接进入生产，将预售订单放入单独的订单库（或增加预售品标识）。

预售商品到货后要判断涉及到货库存和预售订单是否相等。当实际库存小雨预售订单则按下单时间释放等量订单进行生产。系统需要回告库存系统重新计算预售占用库存量。

JIT(准时制生产方式 Just In Time 简称 JIT）

场景：销售驱动生产，根据订单进行生产配送。

JIT 模式需要设定 JIT 波次情况和支援 JIT 的仓库

相同 JIT 仓库订单按照 JIT 波次时间点汇总订单并驱动产生 ERP 采购订单；JIT 和目标仓告诉采销系统

ERP 到货回告订单系统已到货

订单释放进入 WMS 生产

这里面需要说明的是 JIT 场景可以延伸为不入库直接由 WooCommerce 供应商提供物流配送后续工作，平台提供订单、发票等服务。这是流程会变为

订单告知 ERP，生成采购单直接回告 WooCommerce 供应商

WooCommerce 供应商物流状态对应订单状态机进行同步更新

使用者收货后通过邮寄方式提供发票

该模式不支援换货行为

 

结言

订单是电商、 020 的生命中轴线，他主导、串联了整个全部链路的系统。所有的系统都是围绕订单进行改建和扩张的。订单系统的强壮决定了平台的稳定性。