编辑导读：订单管理系统，是整个电商系统的核心系统之一，有一定的复杂性。本文将从六个方面，围绕订单管理系统展开分析，希望对你有帮助。
一、 关于订单管理系统
订单管理系统即处理订单的系统，主要管理订单的输入，处理，输出。其在一般电商系统中或在有交易功能的系统中，都是核心系统/功能之一，有一定的复杂度；但是虽然复杂，并不代表理解起来困难。
关于商品的文章里面，我们已经从商品的输入、维护、输出的流程来介绍了商品系统，那订单也一样，我们本文把订单看成一个流程即订单流来理解。
二、 订单管理系统与整体系统的关系
订单系统会与购物车、商品系统，营销系统、会员系统、支付系统、物流系统、仓库系统、财务系统、内容系统，具体请看示例图：
-
- 购物车：个人认为是订单的起点，商品会被加入购物车，然后会被提交。
- 商品系统：在提交订单页面会看到该订单所包含的商品信息，例如商品名称、所购买数量、价格、售后信息等。
- 营销系统：会显示商品是否优惠信息，例如满减、优惠券。
- 会员系统：会显示该会员是否有基于会员等级的折扣信息(如淘宝的88会员)，或是否有可抵扣金额的会员点数(如京豆)；会显示该会员下面的收货地址信息、也会显示该会员下面是否有充值卡、运费券等。
- 仓库系统：基于收货地址信息显示发货仓库，自提地点等，并且订单最终会流转到该系统进行发货操作。
- 支付系统：显示支付方式(如货到付款、在线支付等)、并且在支付的时候计算该会员实际应付的金额，以及显示银行卡信息等。
- 物流系统：显示配送时间、配送方式、运费等，并且在订单发货后会显示实际的配送路径。
- 财务系统：显示开票信息等，在订单完成后会生成发票。
- 内容系统：显示订单留言等。
三、订单的输入
个人认为订单的输入(亦可称之为来源)可分为内部和外部两种方式：
1. 内部：即自建商城传输过来的订单
- 自建商城的订单系统涉及的其他系统比较多，基本上上图所示的系统都涉及到了。
- 自建商城订单在订单创建时有着更多的判断逻辑，如是否需要事先拆单的、优惠信息是否可用、商品库存是否满足要求、会员是否正常等。
- 内部订单由于存在支付的动作，所以会有多出待付款，待评价这2个状态。
- 内部订单由于涉及支付和营销，所以对订单系统的并发能力、负载能力以及支付能力有相当高的要求，每一步都不允许出错，一旦出错就意味着营业额的损失和用户的流失。
- 订单数据计算和处理的要求更高，商品多少金额，优惠了多少金额，抵扣了多少金额，实付多少金额等都需要准确计算，在财务报表内能够清晰展示。
2. 外部：即第三方系统传输过来的订单
一般代表性的就是分销订单，如供应商的订单系统会接收外部系统的订单。
- 第三方系统传输的订单，由于订单比较独立，所以涉及的相关系统会少很多。
- 第三方订单在订单接收时主要判断传输方是否有资格，商品是否上架状态，库存是否满足，收货人信息是否完整等。
- 由于该类订单相对来说不需要很高的实时性(意思是该类订单对于消费者来说已经付款了，现在只是后端处理)，所以对接口负载性能等要求相对就没有那么高。
- 订单数据处理方面，一般都是线下核对账单，线下结算款项，所以主要在数据记录和处理的准确性方面有很高要求。
以上就是订单的输入，接下来我们聊订单的处理。
四、 订单的处理
个人认为主要有3种处理方式：
1. 流转处理
在订单系统内，系统会对订单进行各种逻辑规则判断，判断后就会根据业务规则分发订单，可简单看示例图：
基本上订单的流转处理是秒级，甚至是毫秒级就能处理完毕的，不能处理的或者处理失败的都会把订单归类到异常订单。
下面是订单各状态的流程图：
2. 发货处理
订单一般流转到仓库进行发货操作，发货后仓库会把物流信息回传到订单系统，订单系统接收消息后会对订单进行发货：
- 如果是内部订单则订单状态直接改变(消费者端也会同步看到订单状态变化)；
- 如果是外部订单则会通过接口告诉第三方系统该订单的物流信息；
3. 特殊情况处理
在特殊情况下，就需要对订单进行人工处理，例如订单无法流转到下一级、订单有备注等。人工处理的结果可能是跟消费者协商后让其退款，也可能是手动的传输订单等。
五、 订单的完成
1. 内部订单
内部订单的完成并不在发货后就完成，一般来说在客户接收到订单商品后即算完成。
但是对不同类型的商城有所区别：
- 自营商城：一般客户收货后就完成订单，例如京东。
- 非自营商城：客户需要自己点击确认收货或经过一段时间后系统自动确认收货。
2. 外部订单
外部订单系统订单一般在发货后就算完成。
六、 订单管理系统设计想法
在我们设计订单系统的时候，应该先思考下公司业务类型和逻辑，理清业务上订单流的起止。
理清后从订单源头开始设计订单系统：
- 如果是自建商城类的那么订单模块会涉及到其他系统，需要与其他系统的产品经理(如多人)去讨论，如何让订单系统与他们负责的系统进行对接；如果是供应链类型的订单系统，则需要考虑如何让订单能够从外部顺利传输到系统，是我们提供统一标准的API呢还是我们去各自对接第三方系统等等。
- 考虑输入方式后，我们就要依据公司业务运营方式来考虑订单的处理逻辑，订单进入系统后如何 让系统自动处理订单，依据什么规则；同时也要考虑对异常订单的处理。
- 在考虑好订单处理逻辑后，就要考虑如何输出订单，是直接输出给WMS还是会再输出给其他ERP等等。由于是自动化的输出，也就要考虑与其他系统的对接方式。
- 最后，我们就要用把公司业务代入到系统内，看看是否能行程闭环，是否还有欠缺或者是否遗漏了细节等。
订单管理系统涉及的其他系统比较多，所以在系统设计上应该具有独立性、拓展型和准确性，独立性代表订单系统的维护或者异常不会影响到其他系统；拓展型代表订单系统在以后增加功能的时候方便快捷；准确性是指订单数据涉及到财务方面，所以应该严谨和准确。
后台系统订单页面的设计：
1）订单列表页面的设计
根据公司业务需要来设计列表页展示的数据和布局，以及筛选查询的关键字段，具体可看示例图：
2）订单详情页的设计
订单详情页一般来说是模块化的展示设计，订单基础信息、商品信息、物流信息、支付信息等都需要有所区分，这样设计有利于详情快速查看以及在系统研发的过程中让开发小哥哥不容易搞错哦，具体可看示例图：
3）订单规则设计
订单规则根据业务的大小有简单和复杂，所以具体需要看业务规模。
如果公司现阶段刚起步，则订单规则可直接写进订单系统；如起步有一段时间了或者发展比较快，则可事先就开发好订单规则模块，以后有新的订单规则直接通过运营人员设置即可，更加的方便和更快速地适应业务的发展。
本文由 @Milomasson 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。