电商所有模块中，订单系统作为最为核心的模块，决定了整个流程能不能顺畅的执行，起着承上启下的作用。相信很多PM都不陌生，到了一家电商公司，总会觉得公司现有的流程有不少问题，因为问题来自四面八方，一下子摸不着到底是哪里出了问题，PM就跟补丁师傅一样，遇到一个补一个。其实很多日常开发和测试提得需求都是表面需求，而这些表面上呈现出的各种问题，都是源自于流程上的不完整或者流程上某个环节上的缺失导致的。订单系统作为一个承上启下的模块，流程上出了问题，它肯定脱不了干系。
订单系统分为用户端和商家端，今天我们从商家端简单分析一下订单系统该如何设计和完善，才能不断适应公司的业务发展，减少因为流程导致的不必要的返工和“补丁”。为什么说订单系统是承上启下的作用，上游是什么，下游又是什么？这里我们先把问题放在这，后面讲到再作解释。
订单系统
设计订单系统需要考虑几个模块，只有所有模块都考虑清晰了，才能保证订单系统的稳定性和可扩展性。
订单字段
其实呈现在界面上的订单信息，都是由各种订单字段组合而成。订单字段齐全从某个程度上代表着订单流程的完整。
订单字段包括几个部分，其中金额信息因为特殊性，独立出来讲，实质上金额信息属于商品信息。
商品信息：商品信息属于订单系统的上游端，所有订单都是从商品演进而来，从商品到订单，订单系统必须搜集相关的商品信息，包括店铺信息，商品id，商品规格，商品数量，商品价格。获取到的商品信息将在订单详情页内展示，形成订单信息后供仓库方便拣货，包装。
用户信息：用户信息包括购买用户的ID，收货人，收货地址，联系方式。有些平台的用户成长体系是基于用户对平台的活跃度来计算的，例如京东，它有会员等级及积分卡等类似的成长标识，此时获取到的用户信息除了普通的信息字段外，还需要获取该用户的等级，该次购买后所获得的积分，以及该用户所在等级能在该订单上扣除的优惠等信息，具体怎么操作取决于公司的业务方向。
金额信息：因为金额信息的特殊性，所以独立出来讲，理论上金额信息应归属商品信息。金额信息的特殊性在于其不止一种金额，其涉及到商品金额，优惠金额，支付金额。而优惠金额中涉及到的信息较复杂，像有自营和第三方入驻的电商平台，都会有商家优惠和跨店优惠，而这些优惠又分不同类型，例如现金扣减，消费券扣减，积分获取，礼品卡扣减，或者以上几种的组合使用。想要涉及好这一块内容，需要根据目前自己公司的业务情况，列出所支持的优惠类型，再枚举出各种组合下的优惠类型，才能保证流程的完整性。
时间信息：记录各个卡点下的时间，一是记录，二也是方便售后验证和客户分析。订单时间是根据订单状态改变而改变的，比如我们常见的用户，下单未付款:即展示订单创建时间，下单时间；待发货状态:展示订单创建时间，下单时间，支付时间；待收货状态:展示订单创建时间，下单时间，支付时间，发货时间；交易完成状态:展示订单创建时间，下单时间，下单时间，支付时间，发货时间，完成时间；待退款状态:展示退款订单创建时间，申请退款时间；交易关闭-用户取消:展示订单创建时间，下单时间，用户取消时间；交易关闭-仅退款：订单创建时间，下单时间，支付时间，退款申请时间，退款成功时间；交易关闭-退货退款（包含部分仅退款）：订单创建时间，下单时间，支付时间，交易完成时间，退款申请时间，退款时间；时间信息看起来不重要，其实是订单系统一个重要的组成部分，原因大家可以思考一下。
订单信息：订单信息在订单系统最为核心，订单信息最重要的又是订单状态。很多公司都有订单状态机的说法，那到底什么是订单状态机，我个人的理解是在订单中，通过各种购物情景，触发订单状态，将订单的流转可视化，是订单状态机的一种具体呈现形式，而它实质就是在描述订单状态的转换。电商购物中，订单状态分别有以下几种：【待付款】【待发货】【待收货】【待评价】【交易完成】【用户取消】【仅退款】【退货退款】。而我们一般会将后三种统一放在订单售后独立呈现，去方便平时商家操作的便捷性。
ok，第一部分订单字段就先写到这，下一部分订单的流程分析，将会详细分析订单的正向流程与逆向流程，包括订单拆分单情况等，目前计划是每周一更，但是工作太忙，希望自己可以坚持完成，虽然码了不多字，但是大热天还在写文章，觉得有用的来个赞鼓励一下吧，感谢支持。
