注：一个订单系统的设计并不简单，它需要一批又一批的人去维护、去优化，根据公司的业务情况做出改变和兼容。本文主要分析一下电商订单系统该如何设计。

电商所有模块中，订单系统作为最为核心的模块，决定了整个流程能不能顺畅的执行，起着承上启下的作用。相信很多PM都不陌生，到了一家电商公司，总会觉得公司现有的流程有不少问题，因为问题来自四面八方，一下子摸不着到底是哪里出了问题，PM就跟补丁师傅一样，遇到一个补一个。

其实很多日常开发和测试提得需求都是表面需求，而这些表面上呈现出的各种问题，都是源自于流程上的不完整或者流程上某个环节上的缺失导致的。订单系统作为一个承上启下的模块，流程上出了问题，它肯定脱不了干系。

订单系统分为用户端和商家端，今天我们从商家端简单分析一下订单系统该如何设计和完善，才能不断适应公司的业务发展，减少因为流程导致的不必要的返工和“补丁”。

为什么说订单系统是承上启下的作用，上游是什么，下游又是什么？

这里我们先把问题放在这，后面讲到再作解释。

订单系统

设计订单系统需要考虑几个模块，只有所有模块都考虑清晰了，才能保证订单系统的稳定性和可扩展性。

1. 订单字段

其实呈现在界面上的订单信息，都是由各种订单字段组合而成。订单字段齐全从某个程度上代表着订单流程的完整。

订单字段信息

订单字段包括几个部分，其中金额信息因为特殊性，独立出来讲，实质上金额信息属于商品信息。

商品信息：商品信息属于订单系统的上游端，所有订单都是从商品演进而来，从商品到订单，订单系统必须搜集相关的商品信息，包括店铺信息，商品id，商品规格，商品数量，商品价格。获取到的商品信息将在订单详情页内展示，形成订单信息后供仓库方便拣货，包装。

用户信息：用户信息包括购买用户的ID，收货人，收货地址，联系方式。有些平台的用户成长体系是基于用户对平台的活跃度来计算的，例如京东，它有会员等级及积分卡等类似的成长标识，此时获取到的用户信息除了普通的信息字段外，还需要获取该用户的等级，该次购买后所获得的积分，以及该用户所在等级能在该订单上扣除的优惠等信息，具体怎么操作取决于公司的业务方向。

金额信息：因为金额信息的特殊性，所以独立出来讲，理论上金额信息应归属商品信息。金额信息的特殊性在于其不止一种金额，其涉及到商品金额，优惠金额，支付金额。而优惠金额中涉及到的信息较复杂，像有自营和第三方入驻的电商平台，都会有商家优惠和跨店优惠，而这些优惠又分不同类型，例如现金扣减，消费券扣减，积分获取，礼品卡扣减，或者以上几种的组合使用。想要涉及好这一块内容，需要根据目前自己公司的业务情况，列出所支持的优惠类型，再枚举出各种组合下的优惠类型，才能保证流程的完整性。

时间信息：记录各个卡点下的时间，一是记录，二也是方便售后验证和客户分析。订单时间是根据订单状态改变而改变的，比如：我们常见的用户。

• 下单未付款：即展示订单创建时间、下单时间；

• 待发货状态：展示订单创建时间、下单时间、支付时间；

• 待收货状态：展示订单创建时间、下单时间、支付时间、发货时间；

• 交易完成状态：展示订单创建时间、下单时间、下单时间、支付时间、发货时间、完成时间；

• 待退款状态：展示退款订单创建时间、申请退款时间；

• 交易关闭-用户取消：展示订单创建时间、下单时间、用户取消时间；

• 交易关闭-仅退款：订单创建时间、下单时间、支付时间、退款申请时间、退款成功时间；

• 交易关闭-退货退款（包含部分仅退款）：订单创建时间、下单时间、支付时间、交易完成时间、退款申请时间、退款时间。

时间信息看起来不重要，其实是订单系统一个重要的组成部分，原因大家可以思考一下。

订单信息：订单信息在订单系统最为核心，订单信息最重要的又是订单状态。很多公司都有订单状态机的说法，那到底什么是订单状态机？

我个人的理解是：在订单中，通过各种购物情景，触发订单状态，将订单的流转可视化，是订单状态机的一种具体呈现形式，而它实质就是在描述订单状态的转换。

电商购物中，订单状态分别有以下几种：【待付款】、【待发货】、【待收货】、【待评价】、【交易完成】、【用户取消】、【仅退款】、【退货退款】。而我们一般会将后三种统一放在订单售后独立呈现，去方便平时商家操作的便捷性。

电商订单流程