订单系统核心功能

晓萌 · 发布于 2023-6-4 22:49:42

文章目录

1.订单中所包含的内容信息

为了使订单系统可以对订单停止高效、精准的管理和跟踪，订单会贮存关于产品、优惠、用户、支付信息等一系列的订单实时数据，来和下游系统，如：促销、仓储、物流停止交互。
以一个通用B2C商城的订单为例，梳理其包含的信息如下：
这里要注意的是订单类型，随着平台业务的不时开展，品类丰富、交易方式丰富后，需要对订单停止多维度的分类管理，同时订单类型利于订单系统的扩展性。每种订单类型将会对应一套流程及一套状态，便于对订单停止分类管理和复用。
2.流程引擎

流程是指从平台角度动身，将订单从创建到完成的整个流转过程停止笼统，从而形成了一套规范流程规则。而不同的产品类型或交易类型在系统中的流程会千差万别，因而为了方便对订单流程停止管理，会组建流程引擎模块。
每套订单流程中会包含正向流程及逆向流程，正向流程可以比作一次顺利的网购体验过程中，后台系统之间的信息流转。逆向流程则是修改订单、取消订单、退款、退货等各种动作引起的后台系统流程，同时每个流程触发的条件又可分为系统触发和人工触发两种场景。
2.1 正向流程

以一个通用B2C商城的订单系统为例，根据其实际业务场景，其订单流程可笼统为5大步骤：订单创建>订单支付>订单消费>订单确认>订单完成。
而每个步骤的背后，订单是如何在多系统之间交互流转的，可概括如下图：

2.1.1 订单创建

用户下单后，系统需要生成订单，此时需要先获取下单中涉及的商品信息，然后获取该商品所涉及到的优惠信息，假设商品不参与优惠信息，则无此环节。
接着获取该账户的会员权益，这里要注意的是：优惠信息与会员权益的区别，比如：商品满减是优惠信息，SUPER会员全场9.8折指的是会员权益，一个是针对商品，另一个是针对账户。其次就是优惠活动的叠加规则和优先级规则等。
增减库存规则是指订单中的商品，何时从仓储系统中对相应商品库存停止扣除，目前主流有两种方式：
下单减库存——即用户下单胜利时减少库存数量

处置办法：

付款减库存——即用户支付完成并反响给平台后再减少库存数量

处置办法：

综上所述，两种方式各有优缺点，因而，需结合实际场景停止考虑，如：秒杀、抢购、促销活动等，可使用下单减库存的方式。而对于产品库存量大，并发流量没有那么强的产品使用付款减库存的方式。
将两种方式带入到销售场景中，关联商品类型、促销类型、供需关系等，灵敏使用，以充沛发挥计算机系统的优势。
2.1.2 订单支付

用户支付完订单后，需要获取订单的支付信息，包括支付流水号、支付时间等。支付完订单接着就是等商家发货，但在发货过程中，根据平台业务形式的不同，可能会涉及到订单的拆分。
订单拆分一般分两种：

订单拆分也是一个相对独立的模块，这里就不详细描绘了。
2.1.3 订单消费

订单消费，是指产品从企业到用户这一流程的概述。如电商平台中，商家发货过程已有一个规范化的流程，订单内容会发送到仓库，仓库对商品停止打单、拣货、包装、交接快递停止配送。
2.1.4 订单确认

收到货后，订单系统需要在快递被签收后提醒用户对商品做评价。这里要注意，确认收到货不代表交易胜利，相反是售后效劳的开端。
2.1.5 订单完成

订单完成是指在收到货X天的状态，此时订单不在售后的支持时间范围内。到此，一个订单的正向流程就算走完了。
2.2 逆向流程

上面说到逆向流程是各种修改订单、取消订单、退款、退货等操作，需要梳理清楚这些流程与正向流程的关系，才干理清订单系统完好的订单流程。
订单修改：可梳理订单内信息，根据信息关联水平及业务诉求，设定订单的可修改范围是什么，比如：客户下单后，想修改收货人地址及电话。此时只需对相应数据停止更新即可。
订单取消：用户提交订单后没有停止支付操作，此时用户原则上属于取消订单，因为还未付款，则比较简单，只需要将原本提交订单时扣减的库存补回，促销优惠中使用的优惠券，权益等视平台规则，停止相应补回。
退款：用户支付胜利后，客户发出退款的诉求后，需商户停止退款审核，双方达成一致后，系统应以退款单的形式完成退款，关联原订单数据。因商品无变化，所以不需考虑与库存系统的交互，仅需考虑促销系统及支付系统交互即可。
退货：用户支付胜利后，客户发出退货的诉求后，需商户停止退款审核，双方达成一致后，需对库存系统停止补回，支付系统、促销系统以退款单形式完成退款。最后，在退款/退货流程中，需结合平台业务场景，考虑优惠分摊的逻辑，在发生退款/退货时，优惠该如何退回的处置规则和流程。
2.3 状态机

状态机是管理订单状态逻辑的工具。状态机可归纳为3个要素，即现态、动作、次态。

订单系统为了高效的对订单停止跟踪和管理，会对订单流程当中的关键节点，笼统出订单状态。而订单状态从不同用户的角度可分为，系统订单状态、商家订单状态、买家订单状态等。
对于订单系统来说，订单状态细分的颗粒度越细、越明确，订单系统管理的精度和可靠性就越高，比如：在待付款和待发货两个状态中，订单系统后台会细分为订单超时取消、订单支付失败、订单付款完成等。
因而，订单状态模块中，通常会维护状态映射表，以不同的用户角色对系统订单状态停止重新划分，以满足不同用户的需求。
除此以外，随着电商平台的不时开展，不同的业务类型，所对应的订单状态都会有所区别。所以，订单系统中一般会贮存多套状态机，以满足不同的订单类型来使用。
3.订单系统的开展

随着企业的开展，业务量和业务形式不时变化，企业有可能形成多个订单系统并存以满足不同的业务需要的情况。

这种情况的呈现，将会给平台带来非常大的开展瓶颈:
三个订单系统，每个订单系统处置不同类型的订单，没有统一的订单销量、订单状态信息，网站前台对订单的状态展示与控制不统一，只能是在网站前台会员中心硬代码维护一套面向会员的统一订单明细与状态数据。而无线侧上线后，由于不理解前台网站会员中心的订单状态管理逻辑，所以需要把前台网站的订单明细及状态管理再在无线应用侧再实现一遍。
三套后台订单系统与公共业务系统如会员中心、支付与财务、促销工具、客户分单等系统都需要对接一遍，公共业务处置逻辑不统一，一旦逻辑变卦，多个系的同一个接口都要修改一遍，接口的反复维护开发工作量大。
订单开发目前分到事业部，各个事业部只会考虑自己的逻辑，不会考虑公共架构，只会越走越远。碰到像无线这样的项目，需要对接各个事业部，无线侧应用上线停顿慢。
因而将来的订单系统可拆分为订单中心与业务订单系统两个模块，以管理公司所有订单数据，并为各个模块提供统一效劳。