电子商务的关键词是交易，作为交易中最重要的维系双方契约的凭据就是订单。
订单流程主要是订单产生到交易结束的整个流程。按照现在电子商城（E-mall），仓库管理（WMS），物流管理系统（TMS）的流转过程主要如下图。
由买家发起购物付款-仓库发货-用户收货流程为正向流程，反过来买家退款退货-仓库收货-退款处理流程为逆向流程。
点击查看大图
这篇文章讨论的是电子商城E-mall的订单信息。E-mall电子商城系统的订单信息内容主要如下：
订单信息
订单详情
订单详细信息中字段内容：
订单单号
订单单号是订单信息中的主Key，代表了该订单的唯一性，并且使用在仓库管理系统中WMS作为拆分合并订单中与电子商城中的订单关联的Key值。
订单单号一般组成方式有以下两种：
1）日期时间+随机数字，初期业务量不多的时候20-26位足够应付。
HHHHMMDDhhmmss（年月日时分秒） +6位随机码。
6位随机码表示一秒钟可能生成的订单数上，存在一百万分之一的随机并发相同导致下单失败，因此在初期业务每秒下单量不高的时候选择这种简单的方法足够满足需求。
2）以日期时间+自增的方式，这样就不会产生随机数生成冲突，但是要注意防治被查看到销售量需要将数字加密设置。
当然订单号设计还远远不止于这些，还应该可以考虑渠道来源，商家业务，商品分类，用户类型等做标记,这里暂时不重点介绍，可以参考
订单倒计时时间
订单里面显示倒计时有
1）下单未支付。
商品下单后开始倒计时，一定时间内如果还未下单则超时关闭订单。普通商品一般采取3天时间，特价商品根据情况一般采取的是30分钟。快消品一般采用的15分钟。
2）已发货确认收货倒计时。
商品一般是发货开始后开始倒计时10天时间，O2O商品应该是送达即收货。
满1天记录1天 XX天hh小时mm分钟
小于1天小时则hh小时mm分钟ss秒
防止发货时间过长，发货后用户可以采用延长一次收货，并且商家/平台端可以多次延长收货。
订单状态
订单状态与商品状态是独立的。因为商品状态在任意时间都可以申请退货退款。订单状态根据买家/商家/平台操作动作后的状态迁移。
订单状态迁移图
订单状态说明
订单状态对应的操作按钮内容：
订单状态操作栏按钮
收货人信息
确认订单的时候，收货人地址是否超出送货范围需要明示，超出指定送货范围则该订单无法提交。
另外有一个关键词是是否自提，增加自提地址是线上商城线下门店相结合的一个接触方式。
注意：选择自提和自提地址后需要去除运费。
商品信息
在购物车或者直接购买的情况下，确认订单里面商品信息是带有商品的库存状态，该状态是通过WMS定时返回Emall中保存的。包括商品上下架状态，可预定库存数量。下架商品，或者可预订库存小于购买数量则在确认订单中设置成失效商品。
根据状态迁移图显示的商品按钮
商品状态操作栏
*可以根据订单情况退款退货期间状态可以再细分成待退货等状态，以及完成订单以后也可以申请维权状态。当然一开始可以不用考虑过于复杂，先完成核心必要的流程功能。如果出现该情况可以先人工沟通。
金额信息
按照每个订单中商品金额比例计算优惠券，抵用券以及运费，为了在退款退货时计算实际退款金额使用。
单个可使用商品金额 / Sum(可使用优惠商品金额） * 优惠金额或者抵用券金额 = 单个可使用商品金额的的优惠值。
每个商品的实际支付金额 = 商品金额 - 单个可使用商品金额的的优惠值
单个商品的运费金额是按照运费模板来计算的比例，运费计算方式参考这篇=》【电商基本功】| 电商运费计算方式
当退款订单中某个商品全部退款则退款运费（发货前）退还所分配的金额。
退款商品只退款部分金额时候，运费也则需要按比例计算。
该订单结算给商家的金额则如下：
单个商品可获取的金额= 商品金额 - 用户退款金额 - 用户退款金额/用户支付总额 × 该商品的分配抵用券金额
商家可结算该订单的金额 = Sum（单个商品可获取的金额） + 可退运费
物流信息
在开发初期，只是查看物流流水信息，则可以集成第三方物流平台比如快递xx，在系统开发的后续阶段，需要对接更多的物流状态，以及物流打单，分配物流单号则需要直接对接物流平台。
*第三方快递100的技术实现方式是对接快递100的公开平台，通过指定物流公司名称和编号和物流单号从快递100服务器获取JSON数据后保存在平台NoSQL数据库中。
*菜鸟物流也是类似实现方式。
使用第三方物流平台展示
订单信息推送
订单的相关的消息什么时候推送，什么方式推送能促成用户快速成单，又避免频繁的打扰用户这是心理学问题。以下皆为我自己观点，可以理性讨论。
订单相关推送时机与方式
最后：
订单是整个交易的核心链路，需要保证订单流程的可扩展性，稳定性。经验有限，文中应该也有描述不足扩展不足情况。
扩展的问题以及其他平台更深入的问题，可以不用开始初步阶段的时候就考虑，但是需要提前预留。比如刚开始没有考虑订单状态和商品状态分开，则后续修改将导致，则整个订单状态再修改的时候旧版本很难和新版本保证状态的一致性。
