本文主要讲述了在传统电商企业中，订单系统应承载的角色，就订单系统所包含的主要功能模块梳理了设计思路，并对订单系统未来的发展做了一些思考。
在搭建企业订单系统之前，需要先梳理企业整体业务系统之间的关系和订单系统上下游关系，只有划分清业务系统边界，才能确定订单系统的职责与功能，进而保证各系统之间高效简洁的工作。
订单架构
订单架构
01 应用层
应用层直接面对终端用户，负责为用户提供订单交易服务，从是否为自建系统可以分为自建平台渠道和第三方平台渠道。自建系统渠道分为PC商城、App商城、小程序商城。第三方平台店铺可分为淘宝天猫店铺、京东店铺、拼多多店铺等。
尽可能的拓展应用层的服务渠道，通过各种渠道触达用户，从而提升订单交易量和交易额，这是应用层的使命。
02 服务层
服务层作为整个交易系统中最重要的一层架构，支撑着应用层各渠道的交易，为应用层提供基础服务能力。订单系统更像是一个调度指挥中心，井然有序地调用其他系统的服务来支撑订单交易的完成。订单交易系统的服务层包含：订单中心、支付中心、商品中心、营销中心、客户中心、仓储中心、采购中心。
订单中心：记录订单信息、商品信息、支付信息、物流信息等内容，并提供订单操作。
支付中心：为订单交易提供支付能力，包含支付方式和支付工具。
商品中心：为订单提供商品基础数据，包含SKU型号、商品参数、商品价格等信息。
营销中心：查询活动优惠信息，结合客户信息，判断当前订单是否满足活动优惠的条件，是否满足优惠券的使用条件，从而调用优惠信息。
客户信息：查询客户的身份及权益，以及可用于交易的虚拟资产，如积分、红包、卡券等。
仓储中心：提供商品的库存查询，商品锁库，以及负责订单商品出库、退换货入库等货物管理的有关能力。
采购中心：对于期货类订单、预售类订单，采购中心能够提供智能化的采购服务，缩短采购时间、减少采购成本。
03 数据层
数据层为交易系统提供数据分析能力，利用数据分析的结果驱动交易链路的服务体验优化，提升订单交易的增长，从而更好的实现业务目标。数据层从交易、商品、渠道三个方面来分析订单交易的过程。
交易分析：统计商品的下单转化率、订单的支付转化率；统计订单的付款人数、下单人数、订单量、累计交易额、人均交易额、平均每笔订单交易额；统计新老用户的付款人数、订单量、订单金额，新老用户的订单量占比。
商品分析：统计各单品的销量、销售额、付款人数、支付转化率；统计各类目销量、销售额、各类目销售占比、各类目与上一统计周期的环比情况。
渠道分析：统计PC商城、App应用、小程序、天猫淘宝店铺、京东店铺、拼多多店铺等渠道的销量、销售额、付款人数，以及各渠道的占比，各渠道与上一统计周期的环比情况。
二、订单流程
订单流程
- 用户通过购物车或商品详情页进行下单。下单时系统需判断有无活动优惠，有无可用的优惠券、红包，是否可使用积分抵扣等优惠信息，用户选择优惠券、积分抵扣，填写收货信息，确认没问题后提价订单；
- 选择支付方式（微信支付、支付宝支付、银行卡支付），进行订单付款。付款时，系统查询商品有无可用销售库存，若无可用库存则订单支付失败，并提示用户库存不足，若库存充足则进入下一个判断，判断是否超出支付时间。
- 库存充足，系统检查是否超出支付时间，若超出则支付失败，若未超出则执行支付。
- 完成付款后，系统锁定库存，订单进入待发货状态；
- 后台系统进行订单商品的拣货、清点及订单发货，系统扣减库存；
- 用户签收快递，并确认收货。若用户长时间未操作确认收货，系统则根据后台系统设置的规则，发货后15天自动收货；
- 订单完成交易，流程结束。
此为订单的正向交易流程，逆向交易流程属于订单售后模块，后续单独分析有关订单售后的系统设计。本流程重点讲解订单系统中涉及的后台业务流程，前端设计请查看文末的推荐阅读。
三、订单功能
01 订单查看
订单中心可通过订单列表和订单详情查看订单信息。
订单详情
订单信息的展示要考虑各种字段的全面性，字段展示考虑的如果足够的周到，也便于运营、客服等岗位的同学分析处理问题。后台订单详情页的展示不仅包含商品信息、单据信息、费用信息、地址信息，还包含仓储信息、发票信息、客户信息。
商品信息：包含但不限于商品名称、型号、规格、参数、促销价、市场价、类目、品牌等信息等数据字段。
单据信息：包含但限于订单来源、订单类型、配送方式、订单编号、下单时间、支付时间、订单状态等数据字段。订单来源包含PC商城、APP商城、小程序商城、淘宝天猫店铺、京东店铺、拼多多店铺。订单类型包含线上普通订单、团购订单（仅线上有）、预售订单（仅线上有）、线下订单等。配送方式包含快递发货、上门自提、同城配送。
费用信息：包含但不限于商品金额、运费金额、优惠券金额、红包金额、积分抵扣金额、订单金额、积分奖励数量等数据字段。订单金额=商品金额+运费金额-优惠券金额-红包金额-积分抵扣金额。
地址信息：包含收货地址和代发地址。地址信息展示的内容包含姓名、电话和街道地址。
仓储信息：包含但不限于订单锁定库存、仓库可用库存、仓库总库存、仓库编号、仓库区域，预计送达日期等数据字段。
发票信息：包含*票开**抬头名称（单位或个人）、单位税号、电话、注册地址。
客户信息：包含但不限于客户账号、客户名称、客户等级、客户下单量、客户交易额等数据字段。
2B类的客户订单，通常还会涉及到合同，订单详情页还应能够查看合同信息，合同支持在线预览和本地*载下**。系统根据订单商品、订单金额、客户信息、收货地址、卖家信息（一般为商城）自动生成订单销售合同。
订单详情示意图
订单列表
订单列表将详情页当中的最常用的字段展示出来即可，大家可根据自己的实际需要和查询习惯展示相应的字段。如果列表页展示的字段太多，可以通过设置面板，来控制列表页显示的字段，通过拖拽表单列来调整字段的显示顺序。
建议在列表数据的上方使用订单状态作为内页切换的标签，将不同状态的订单分别显示在不同的状态标签页下方，在页面设计时通常还会新增一个全部状态的Tab标签。订单列表支持的查询条件包含条件筛选类、关键字查询类和日期查询类条件。
条件筛选
包含订单渠道、订单类型、配送方式、支付方式、订单状态、结算状态、结算方式、*票开**状态。
订单渠道：包含PC商城、App商城、小程序商城，淘宝天猫店铺、京东店铺、拼多多店铺等第三方平台店铺。
订单类型：包含线上普通订单、团购订单（仅线上有）、预售订单（仅线上有）、线下订单。
配送方式：包含快递发货、上门自提和同城配送。上门自提需要线下有实体门店，同城配送一般为生鲜类商品。
支付方式：包含微信支付、支付宝支付、银行卡支付等支付方式。
订单状态：包含待支付、待发货、已发货、已完成、已取消和异常。已取消订单包含因支付超时取消的订单和客户不想要手动取消的订单。异常订单即因系统问题引发的订单出现的异常，如订单金额的计算错误、订单状态的错误、发货数量错误等各种由于各系统间的数据传递错误、数据逻辑运算出现的问题造成的订单异常。
结算状态：结算状态为商城与各商家之间的订单结算，一般分为未结算和已结算。
结算方式：结算方式分为手动结算、定期自动结算。
*票开**状态：*票开**状态即商城给客户开具的订单发票的开具状态，为未*票开**和已*票开**。
关键字查询
关键字查询包含支持按订单编号、商品编号、客户账号、收货人姓名、收货人手机号等内容模糊查询。
日期查询
订单列表支持按下单日期范围、发货日期范围查询订单。
订单列表的数据支持以Excel、PDF格式导出到本地。
订单列表示意图
02 订单处理
在订单中心可以对订单进行的处理操作包含：订单修改、订单关闭、合并订单、订单发货、订单备注、打印发货单、打印快递单、确认收货。
订单修改：订单未发货前，在订单后台可以修改订单的地址信息、订单费用信息和发票信息。地址信息包含收货地址和代发地址，支持修改姓名、电话和地址；订单费用信息包含运费金额、优惠金额，修改后系统重新计算订单金额；发票信息包含*票开**抬头（支持单位和个人）、单位税号。
部分ERP系统后台，还支持修改商品、单价、客户，基本上订单所有的信息都支持修改。很多ERP系统中支持商家为客户在后台下手工单，下单的整个过程都是商家代替客户操作。
订单关闭：由于某些特殊原因，常常需要后台提供关闭订单的灵活操作，如客户退单、订单异常等特殊情况。
合并订单：当同一个收货人（姓名、电话和地址全部相同）有多笔订单，且下单时间接近时，商家为了节省物流成本，通常会将销售订单进行合并，合并为一个发货单，进行一次性发货。
订单发货：用户付款后，需要进行订单发货操作。系统需要支持订单批量发货，发货时需在后台页面填写选择快递公司，填写运单号。具有成熟WMS系统的商城，这里可以不填写快递公司，快递单号，这一步只负责将订单推送至仓储系统。仓储系统进行拣货、清点后，进行最终发货时再填写快递公司和快递单号。
订单备注：编辑订单备注信息，通常是运营的同学提醒仓库部门需要注意的发货事项。
打印发货单：打印发货单信息，发货单信息包含商品信息、订单基础信息、收货信息。
打印快递单：打印快递单信息，快递单信息包含发货仓库、发货人姓名、电话、地址、快递单号。快递单内容支持编辑修改，默认根据系统规则推荐。
确认收货：对于用户已签收的订单，若用户忘记“确认收货”，运营人员可以在后台进行确认收货，确认收货的订单状态将变更为已完成，订单流程结束。
发货单示意图
快递单示意图
03 到货提醒
对于期货订单、预售订单、超卖订单，由于没有现货，用户需要经历漫长的等待。为了缓解用户的等待焦虑，提升服务体验，当货物到仓后，系统需要及时提醒下单用户。当订单货物到货后，系统需要通过短信、App Push消息、微信消息等多种方式告知用户。
对于此类订单，后台系统应有一个专门的页面用于查看订单到货情况，以及提醒消息的下发情况。便于订单运营人员或客服人员掌握客户订单的最新情况。
04 订单设置
订单后台系统需要针对商城订单进行一些基础设置。如订单支付时间设置、订单售后时间限制、自动好评设置。
支付时间：设置订单的支付时间，超出支付时间则订单将被自动取消。一般零售普通订单的支付时间为2小时以内，对于预售类订单，将会涉及预付款和尾款，需要对预付款和尾款分别设置订单支付时间。
售后时间：为订单设置售后的限制时间，超出售后限制时间则不允许用户申请售后。售后时间一般为确认收货后15天内，可以根据自己的实际情况灵活设置。
自动好评：可以设置自动好评的时间。用户在订单完成的某一时间内未进行评价，系统自动给与五星好评，具体时间各电商平台可以根据自己的实际情况进行灵活设置。
以上的订单设置完成后，将对PC商城、App商城和小程序商城的所有订单均生效。
05 权限控制
订单中心在整个电商系统中占据非常重要的位置，属于电商系统的核心功能。查看订单、处理订单的操作涉及各部门不同的人员，因此有必要针对订单系统设计权限。权限系统根据不同的作用与范围，可以分为菜单权限、操作数据、数据权限。
菜单权限用于控制后台用户能够看到的菜单，操作权限用于控制后台用户能够操作的按钮，数据权限则控制着后台用户能够看到的数据字段。将这三种权限共同作用于后台系统的用户账号，则可以实现对不同部门的员工账号实现精准掌控。大家根据自己的工作职责去申请配置账号的权限范围，与自己工作无关的数据或操作则进行系统限制，以避免引发一些不必要的麻烦。
账号与权限并不是直接建立关系的，需要引入角色来为连接它们。通常在后台系统中需要先定义角色，角色的定义与员工所处的部门、工作的岗位、工作的职责有关。根据岗位与职责定义角色，然后再为角色添加账号。简单的来说就是干相同工作的人同属于一个角色。角色创建完成后，再为角色配置权限，权限的配置则可以按照上文的菜单权限、操作权限和数据权限三个方面进行配置。
订单系统与各业务系统的关系
（1）对外系统：
所有给企业外部用户使用的系统都在这一层，包括官网、普通用户使用的C端，还包括给商户使用的商家后台和在各个销售渠道进行分销的系统，比如与银行信用卡中心合作、微信合作在合作商的平台露出本企业的产品。这类系统站在与客户接触的最前线，是公司实现商业模式的桥头堡。
（2）管理中后台：
每个C端的业务形态都会有一个对应的系统模块，如负责管理平台交易的订单系统，管理优惠信息的促销系统，管理平台所有产品的产品系统，以及管理所有对外系统显示内容的内容系统等。
（3）公共服务系统：
随着企业的发展，信息化建设到达一定程度后，企业需要将通用功能服务化、平台化，以保证应用架构的合理性，提升服务效率。这类系统主要给其他应用系统提供基础服务能力支持。
订单系统上下游关系
由此可见，订单系统对上接收用户信息，将用户信息转化为产品订单，同时管理并跟踪订单信息和数据，承载了公司整个交易线的重要对客环节。对下则衔接产品系统、促销系统、仓储系统、会员系统、支付系统等，对整个电商平台起着承上启下的作用。
4. 订单系统的业务架构
（1）订单服务
该模块的主要功能是用户日常使用的服务和页面，主要有订单列表、订单详情、在线下单等，还包括为公共业务模块提供的多维度订单数据服务。
（2）订单逻辑
订单系统的核心，起着至关重要的作用，在订单系统负责管理订单创建、订单支付、订单生产、订单确认、订单完成、取消订单等订单流程。还涉及到复杂的订单状态规则、订单金额计算规则以及增减库存规则等。在4节核心功能设计中会重点来说。
（3）底层服务
信息化建设达到一定程度的企业，一般会将公司公共服务模块化，比如：产品，会构建对应的产品系统，代码、数据库，接口等相对独立。但是，这也带来了一个问题，比如：订单创建的场景下需要获取的信息分散在各个系统。
如果需要从各个公共服务系统调用：一是会花费大量时间，二是代码的维护成本非常高。因此，订单系统接入所需的公共服务模块接口，在订单系统即可完成对接公共系统的服务。
2
订单系统核心功能
1. 订单中所包含的内容信息
为了使订单系统能够对订单进行高效、精准的管理和跟踪，订单会储存关于产品、优惠、用户、支付信息等一系列的订单实时数据，来和下游系统，如：促销、仓储、物流进行交互。
以一个通用B2C商城的订单为例，梳理其包含的信息如下：
这里要注意的是订单类型，随着平台业务的不断发展，品类丰富、交易方式丰富后，需要对订单进行多维度的分类管理，同时订单类型利于订单系统的扩展性。每种订单类型将会对应一套流程及一套状态，便于对订单进行分类管理和复用。
2. 流程引擎
流程是指从平台角度出发，将订单从创建到完成的整个流转过程进行抽象，从而行程了一套标准流程规则。而不同的产品类型或交易类型在系统中的流程会千差万别，因此为了方便对订单流程进行管理，会组建流程引擎模块。
每套订单流程中会包含正向流程及逆向流程，正向流程可以比作一次顺利的网购体验过程中，后台系统之间的信息流转。逆向流程则是修改订单、取消订单、退款、退货等各种动作引起的后台系统流程，同时每个流程触发的条件又可分为系统触发和人工触发两种场景。
（1）正向流程
以一个通用B2C商城的订单系统为例，根据其实际业务场景，其订单流程可抽象为5大步骤：订单创建>订单支付>订单生产>订单确认>订单完成。
而每个步骤的背后，订单是如何在多系统之间交互流转的，可概括如下图：
订单创建：
用户下单后，系统需要生成订单，此时需要先获取下单中涉及的商品信息，然后获取该商品所涉及到的优惠信息，如果商品不参与优惠信息，则无此环节。
接着获取该账户的会员权益，这里要注意的是：优惠信息与会员权益的区别，比如：商品满减是优惠信息，SUPER会员全场9.8折指的是会员权益，一个是针对商品，另一个是针对账户。其次就是优惠活动的叠加规则和优先级规则等。
增减库存规则是指订单中的商品，何时从仓储系统中对相应商品库存进行扣除，目前主流有两种方式：
下单减库存——即用户下单成功时减少库存数量
- 优势：用户体验友好，系统逻辑简洁；
- 缺点：会导致恶意下单或下单后却不买，使得真正有需求的用户无法购买，影响真实销量。
解决办法：
- 设置订单有效时间，若订单创建成功N分钟不付款，则订单取消，库存回滚；
- 限购，用各种条件来限制买家的购买件数，比如一个账号、一个ip，只能买一件；
- 风控，从技术角度进行判断，屏蔽恶意账号，禁止恶意账号购买。
付款减库存——即用户支付完成并反馈给平台后再减少库存数量
- 优势：减少无效订单带来的资源损耗；
- 缺点：因第三方支付返回结果存在时差，同一时间多个用户同时付款成功，会导致下单数目超过库存，商家库存不足容易引发断货和投诉，成本增加。
解决办法：
- 付款前再次校验库存，如确认订单要付款时再验证一次，并友好提示用户库存不足；
- 增加提示信息：在商品详情页，订单步骤页面提示不及时付款，不能保证有库存等。
综上所述，两种方式各有优缺点，因此，需结合实际场景进行考虑，如：秒杀、抢购、促销活动等，可使用下单减库存的方式。而对于产品库存量大，并发流量没有那么强的产品使用付款减库存的方式。
将两种方式带入到销售场景中，关联商品类型、促销类型、供需关系等，灵活使用，以充分发挥计算机系统的优势。
订单支付：
用户支付完订单后，需要获取订单的支付信息，包括支付流水号、支付时间等。支付完订单接着就是等商家发货，但在发货过程中，根据平台业务模式的不同，可能会涉及到订单的拆分。
订单拆分一般分两种：
- 一种是用户挑选的商品来自于不同渠道（自营与商家，商家与商家）；
- 另一种是在SKU层面上拆分订单：不同仓库，不同运输要求的SKU，包裹重量体积限制等因素需要将订单拆分。
订单拆分也是一个相对独立的模块，这里就不详细描述了。
订单生产：订单生产，是指产品从企业到用户这一流程的概述。如电商平台中，商家发货过程已有一个标准化的流程，订单内容会发送到仓库，仓库对商品进行打单、拣货、包装、交接快递进行配送。
订单确认：收到货后，订单系统需要在快递被签收后提醒用户对商品做评价。这里要注意，确认收到货不代表交易成功，相反是售后服务的开始。
订单完成：订单完成是指在收到货X天的状态，此时订单不在售后的支持时间范围内。到此，一个订单的正向流程就算走完了。
（2）逆向流程
上面说到逆向流程是各种修改订单、取消订单、退款、退货等操作，需要梳理清楚这些流程与正向流程的关系，才能理清订单系统完整的订单流程。
订单修改：可梳理订单内信息，根据信息关联程度及业务诉求，设定订单的可修改范围是什么，比如：客户下单后，想修改收货人地址及电话。此时只需对相应数据进行更新即可。
订单取消：用户提交订单后没有进行支付操作，此时用户原则上属于取消订单，因为还未付款，则比较简单，只需要将原本提交订单时扣减的库存补回，促销优惠中使用的优惠券，权益等视平台规则，进行相应补回。
退款：用户支付成功后，客户发出退款的诉求后，需商户进行退款审核，双方达成一致后，系统应以退款单的形式完成退款，关联原订单数据。因商品无变化，所以不许考虑与库存系统的交互，仅需考虑促销系统及支付系统交互即可。
退货：用户支付成功后，客户发出退货的诉求后，需商户进行退款审核，双方达成一致后，需对库存系统进行补回，支付系统、促销系统以退款单形式完成退款。最后，在退款/退货流程中，需结合平台业务场景，考虑优惠分摊的逻辑，在发生退款/退货时，优惠该如何退回的处理规则和流程。
（3）状态机
状态机是管理订单状态逻辑的工具。状态机可归纳为3个要素，即现态、动作、次态。
- 现态：是指当前所处的状态。
- 动作：动作执行完毕后，可以迁移到新的状态，也可以仍旧保持原状态。
- 次态：动作满足后要迁往的新状态，“次态”是相对于“现态”而言的，“次态”一旦被激活，就转变成新的“现态”了。
状态机的设计需要结合平台实际业务场景，将状态间的切换细化成了执行了某个动作。
以一个B2C商城的订单系统举例如下：
订单系统为了高效的对订单进行跟踪和管理，会对订单流程当中的关键节点，抽象出订单状态。而订单状态从不同用户的角度可分为，系统订单状态、商家订单状态、买家订单状态等。
对于订单系统来说，订单状态细分的颗粒度越细、越明确，订单系统管理的精度和可靠性就越高，比如：在待付款和待发货两个状态中，订单系统后台会细分为订单超时取消、订单支付失败、订单付款完成等。
因此，订单状态模块中，通常会维护状态映射表，以不同的用户角色对系统订单状态进行重新划分，以满足不同用户的需求。
除此以外，随着电商平台的不断发展，不同的业务类型，所对应的订单状态都会有所区别。所以，订单系统中一般会储存多套状态机，以满足不同的订单类型来使用。
3
订单系统的发展
订单系统的主体框架，和主要业务模块已基本讲完，那么随着企业的发展，业务量和业务形式不断变化，企业有可能形成多个订单系统并存以满足不同的业务需要的情况。
业务系统架构如下：
这种状况的出现，将会给平台带来非常大的发展瓶颈，如：
三个订单系统，每个订单系统处理不同类型的订单，没有统一的订单销量、订单状态信息，网站前台对订单的状态展示与控制不统一，只能是在网站前台会员中心硬代码维护一套面向会员的统一订单明细与状态数据。
而无线侧上线后，由于不了解前台网站会员中心的订单状态管理逻辑，所以需要把前台网站的订单明细及状态管理再在无线应用侧再实现一遍。
三套后台订单系统与公共业务系统如会员中心、支付与财务、促销工具、客户分单等系统都需要对接一遍，公共业务处理逻辑不统一，一旦逻辑变更多个系统统一个接口都要修改一遍，接口的重复维护开发工作量大。
订单开发目前分到事业部，各个事业部只会考虑自己的逻辑，不会考虑公共架构，只会越走越远。碰到像无线这样的项目，需要对接各个事业部，无线侧应用上线进展慢。
因此未来的订单系统可拆分为订单中心与业务订单系统两个模块，以管理公司所有订单数据，并为各个模块提供统一服务。
业务系统架构如下：
对于企业订单系统的搭建，并不是要做的大而全、也不是要小而精。而需要结合市场、公司、业务的实际情况来最终制定系统设计方案和产品迭代计划。最终，和公司整体发展相互协调，相辅相成。