原文链接（顶部链接可直达）：
概述
本文主要述说了在传统电商企业中，订单系统应承载的角色，就订单系统所包含的主要功能模块梳理了设计思路，并对订单系统未来的发展做了一些思索。
1.订单系统在企业中的角色
在搭建企业订单系统之前，须要先梳理企业整体业务系统之间的关系和订单系统上下游关系，只有界定清业务系统边界，就能确定订单系统的职责与功能，从而保证各系统之间高效简约的工作。
2.订单系统与各业务系统的关系
（1）对外系统：
所有给企业外部用户使用的系统都在这一层，包括官网、普通用户使用的C端，还包括给商户使用的店家后台和在各个销售渠道进行分销的系统，例如与农行信用卡中心合作、微信合作在合作商的平台漏出本企业的产品。这类系统站在与顾客接触的最前线，是公司实现商业模式的桥头堡。
（2）管理中后台：
每位C端的业务形态就会有一个对应的系统模块，如负责管理平台交易的订单系统，管理让利信息的促销系统，管理平台所有产品的产品系统，以及管理所有对外系统显示内容的内容系统等。
（3）公共服务系统：
随着企业的发展，信息化建设抵达一定程度后，企业须要将通用功能服务化、平台化，以保证应用构架的合理智，提高服务效率。这类系统主要给其他应用系统提供基础服务能力支持。
3.订单系统上下游关系
由此可见，订单系统对上接收用户信息，将用户信息转化为产品订单，同时管理并跟踪订单信息和数据，承载了公司整个交易线的重要对客环节。对下则衔接产品系统、促销系统、仓储系统、会员系统、支付系统等，对整个电商平台起着承上启下的作用。
4.订单系统的业务构架
（1）订单服务
该模块的主要功能是用户日常使用的服务和页面，主要有订单列表、订单详情、在线下单等，还包括为公共业务模块提供的多维度订单数据服务。
（2）订单逻辑
订单系统的核心，起着至关重要的作用，在订单系统负责管理订单创建、订单支付、订单生产、订单确认、订单完成、取消订单等订单流程。还涉及到复杂的订单状态规则、订单金额估算规则以及增减库存规则等。在4节核心功能设计中会重点来说。
（3）底层服务
信息化建设达到一定程度的企业，通常会将公司公共服务模块化，例如：产品，会建立对应的产品系统，代码、数据库，插口等相对独立。并且，这也带来了一个问题，例如：订单创建的场景下须要获取的信息分散在各个系统。
假如须要从各个公共服务系统调用：一是会耗费大量时间，二是代码的维护成本十分高。为此，订单系统接入所需的公共服务模块插口，在订单系统即可完成对接公共系统的服务。
订单系统核心功能1.订单中所包含的内容信息
为了使订单系统还能对订单进行高效、精准的管理和跟踪，订单会存储关于产品、优惠、用户、支付信息等一系列的订单实时数据，来和下游系统，如：促销、仓储、物流进行交互。
以一个通用B2C商城的订单为例，梳理其包含的信息如下：
这儿要注意的是订单类型，随着平台业务的不断发展，品类丰富、交易方法丰富后，须要对订单进行多维度的分类管理，同时订单类型利于订单系统的扩充性。每种订单类型将会对应一套流程及一套状态，以便对订单进行分类管理和复用。
2.流程引擎
流程是指从平台角度出发，将订单从创建到完成的整个流转过程进行具象，因而产生了一套标准流程规则。而不同的产品类型或交易类型在系统中的流程会千差万别，因而为了便捷对订单流程进行管理，会成立流程引擎模块。
每套订单流程中会包含正向流程及逆向流程，正向流程可以称作一次顺利的网购体验过程中，后台系统之间的信息流转。逆向流程则是更改订单、取消订单、退款、退货等各类动作导致的后台系统流程，同时每位流程触发的条件又可分为系统触发和人工触发两种场景。
（1）正向流程
以一个通用B2C商城的订单系统为例，依据其实际业务场景，其订单流程可具象为5大步骤：订单创建>订单支付>订单生产>订单确认>订单完成。
而每位步骤的背后，订单是怎样在多系统之间交互流转的，可概括如右图：
订单创建：
用户下单后，系统须要生成订单，此时须要先获取下单中涉及的商品信息，之后获取该商品所涉及到的让利信息，假如商品不参与让利信息，则无此环节。
接着获取该帐户的会员权益，这儿要注意的是：让利信息与会员权益的区别，例如：商品满减是让利信息，SUPER会员全场9.8折指的是会员权益，一个是针对商品，另一个是针对帐户。其次就是让利活动的叠加规则和优先级规则等。
增减库存规则是指订单中的商品，何时从仓储系统中对相应商品库存进行交纳，目前主流有两种形式：
下单减库存——即用户下单成功时降低库存数目
解决办法：
设置订单有效时间，若订单创建成功N分钟不付款，则订单取消，库存回滚；限贷，用各类条件来限制卖家的订购件数，例如一个帐号、一个ip，只能买一件；风控，从技术角度进行判别，屏蔽恶意帐号，严禁恶意帐号订购。
付款减库存——即用户支付完成并反馈给平台后再降低库存数目
解决办法：
付款前再度校准库存，如确认订单要付款时再验证一次，并友好提示用户库存不足；降低提示信息：在商品详情页，订单步骤页面提示不及时付款，不能保证有库存等。
综上所述，两种方法各有优劣点，为此，需结合实际场景进行考虑，如：秒杀、抢购、促销活动等，可使用下单减库存的形式。而对于产品库存量大，并发流量没有这么强的产品使用付款减库存的形式。
将两种形式带入到销售场景中，关联商品类型、促销类型、供需关系等，灵活使用，以充分发挥计算机系统的优势。
订单支付：
用户支付完订单后，须要获取订单的支付信息，包括支付流水号、支付时间等。支付完订单接着就是等店家发货，但在发货过程中，按照平台业务模式的不同，可能会涉及到订单的分拆。
订单分拆通常分两种：
订单分拆也是一个相对独立的模块，这儿就不详尽描述了。
订单生产：订单生产，是指产品从企业到用户这一流程的概述。如电商平台中，店家发货过程已有一个标准化的流程，订单内容会发送到库房，库房对商品进行打单、拣货、包装、交接快件进行配送。
订单确认：收到货后，订单系统须要在快件被签收后提醒用户对商品做评价。这儿要注意，确认收到货不代表交易成功，相反是售后服务的开始。
订单完成：订单完成是指在收到货X天的状态，此时订单不在售后的支持时间范围内。到此，一个订单的正向流程即使走完了。
（2）逆向流程
里面说到逆向流程是各类更改订单、取消订单、退款、退货等操作，须要梳理清楚这种流程与正向流程的关系，能够理清订单系统完整的订单流程。
订单更改：可梳理订单内信息，按照信息关联程度及业务诉求，设定订单的可更改范围是哪些，例如：顾客下单后，想更改收件人地址及电话。此时只需对相应数据进行更新即可。
订单取消：用户递交订单后没有进行支付操作，此时用户原则上属于取消订单，由于还未付款，则比较简单，只须要将原先递交订单时扣减的库存补回，促销让利中使用的让利券，权益等视平台规则，进行相应补回。
退货：用户支付成功后，顾客发出退货的诉求后，需商户进行退票初审，双方达成一致后，系统应以退票单的方式完成退票，关联原订单数据。因商品无变化，所以不需考虑与库存系统的交互，仅需考虑促销系统及支付系统交互即可。
退款：用户支付成功后，顾客发出退款的诉求后，需商户进行退票初审，双方达成一致后，需对库存系统进行补回，支付系统、促销系统以退票单方式完成退货。最后，在退票/退款流程中，需结合平台业务场景，考虑让利均摊的逻辑，在发生退货/退款时，让利该怎么退回的处理规则和流程。
（3）状态机
状态机是管理订单状态逻辑的工具。状态机可归纳为3个要素，即现态、动作、次态。
现态：是指当前所处的状态。动作：动作执行完毕后，可以迁移到新的状态，也可以仍然保持原状态。次态：动作满足后要搬到的新状态，“次态”是相对于“现态”而言的，“次态”一旦被激活，就转弄成新的“现态”了。
状态机的设计须要结合平台实际业务场景，将状态间的切换细化成了执行了某个动作。
以一个B2C商城的订单系统举例如下：
订单系统为了高效的对订单进行跟踪和管理，会对订单流程当中的关键节点，具象出订单状态。而订单状态从不同用户的角度可分为，系统订单状态、商家订单状态、买家订单状态等。
对于订单系统来说，订单状态细分的颗粒度越细、越明晰，订单系统管理的精度和可靠性就越高，例如：在待付款和待发货两个状态中，订单系统后台会细分为订单超时取消、订单支付失败、订单付款完成等。
因而，订单状态模块中，一般会维护状态映射表，以不同的用户角色对系统订单状态进行重新界定，以满足不同用户的需求。
除此以外，随着电商平台的不断发展微信订单系统，不同的业务类型，所对应的订单状态就会有所区别。所以，订单系统中通常会存储多套状态机，以满足不同的订单类型来使用。
订单系统的发展
订单系统的主体框架，和主要业务模块已基本讲完，这么随着企业的发展微信订单系统，业务量和业务方式不断变化，企业有可能产生多个订单系统并存以满足不同的业务须要的情况。
业务系统构架如下：
这些状况的出现，将会给平台带来特别大的发展困局，如：
三个订单系统，每位订单系统处理不同类型的订单，没有统一的订单销量、订单状态信息，网站前台对订单的状态展示与控制不统一，只能是在网站前台会员中心硬代码维护一套面向会员的统一订单明细与状态数据。而无线侧上线后，因为不了解前台网站会员中心的订单状态管理逻辑，所以须要把前台网站的订单明细及状态管理再在无线应用侧再实现一遍。
三套后台订单系统与公共业务系统如会员中心、支付与财务、促销工具、客户分单等系统都须要对接一遍，公共业务处理逻辑不统一，一旦逻辑变更，多个系的同一个插口都要更改一遍，插口的重复维护开发工作量大。
订单开发目前分到事业部，各个事业部只会考虑自己的逻辑，不会考虑公共构架，只会越走越远。遇到像无线这样的项目，须要对接各个事业部，无线侧应用上线进展慢。
因而未来的订单系统可分拆为订单中心与业务订单系统两个模块，以管理公司所有订单数据，并为各个模块提供统一服务。
最后
对于企业订单系统的搭建，并不是要做的大而全、也不是要小而精。而须要结合市场、公司、业务的实际情况来最终制订系统设计方案和产品迭代计划。
最终，和公司整体发展互相协调，相辅相成。
免责声明：部分文章信息来源于网络以及网友投稿，本站只负责对文章进行整理、排版、编辑，出于传递更多信息之目的，并不意味着赞同其观点或证实其内容的真实性，如本站文章和转稿涉及版权等问题，请作者在及时联系本站，我们会尽快为您处理。
