1.本技术涉及订单管理业务处理技术领域，尤其涉及一种订单管理系统方法、系统、终端设备及存储介质。
背景技术：2.在新零售领域，快消行业的营销运营日益数字化，其对于快消品的产品数据需求主要集中在如何通过订单选购产品中。目前，市面上的厂家与经销商之间的订单管理相对孤立，在面对订单流通和管控方面，往往是通过业务员线下收集订单信息，或者用户通知函反馈运营手工录单。而这种方式往往存在以下弊端：
3.第一，依赖人工手动收集信息不仅易发生错误，且信息不透明，用户体验度较差；同时这种信息之间的流转往往需要耗费大量时间，严重影响了采购效率。
4.第二，经销商进行采购订单的时候，供方和买方之间信息相对孤立。由于缺乏对厂家产品的活动情况的统一了解，经销商根本无法根据市场情况对采购计划进行灵活调整，不仅灵活性差，且采购计划往往合理性欠佳。
5.第三，现有的订单管理通常采用固定的、统一的模板供经销商使用，由于不同经销商对于采购产品和购物车功能往往有自己的定制化需求，而现在方式由于缺乏可配置性，根本不能满足不同经销商的配置需求，可适配性差且缺乏针对性。
技术实现要素：6.本技术的目的在于提供一种订单管理系统方法、系统、终端设备及存储介质，以解决现有的订单管理流程中存在的信息孤立导致易出错、人工采集导致订单流转效率低、缺乏可配置性以及适配性差的问题。
7.为实现上述目的，本技术提供一种订单管理方法，包括：
8.接收并保存用户自定义的配置信息，所述配置信息包括购物车筛选条件及产品授权类型；
9.接收用户的下单请求，加载用户自定义的配置信息生成自定义下单页面，加载产品关联的活动规则生成产品标签，将产品标签和自定义下单页面发送给用户；
10.缓存用户添加到购物车的产品以及用户选择购物车的勾选状态，生成购物车信息并发送给用户；
11.接收用户的购物车确认指令，根据购物车勾选的数据并进行摊销计算，生成订单信息并发送给用户，待用户确认后生成订单购物车。
12.进一步，作为优选地，所述的订单管理方法，还包括：
13.接收用户的改单请求，重新加载订单购物车并发送给用户，待用户修改完成后生成新的订单信息，发送给用户进行确认。
14.进一步，作为优选地，所述配置信息还包括费用比例配置、摊销配置以及订单校验步骤。
15.进一步，作为优选地，所述加载产品关联的活动规则生成产品标签，包括：
16.根据活动规则查询产品的坎级信息，根据坎级信息计算赠品数量和折价金额，生成产品标签。
17.进一步，作为优选地，所述加载产品关联的活动规则生成产品标签，还包括：
18.调用产品检测服务，对产品进行授权检测、停用检测以及活动过期检测；并对过期的产品添加过期标签。
19.进一步，作为优选地，所述根据购物车勾选的数据并进行摊销计算，包括：
20.利用订单插件计算勾选的数据中的订单总金额、订单明细、摊销策略以及实付金额。
21.进一步，作为优选地，所述待用户确认后生成订单购物车，包括：
22.待用户确认后根据用户的全局购物车绑定当前订单信息，生成订单购物车。
23.本技术还提供一种订单管理系统，包括：
24.配置单元，用于接收并保存用户自定义的配置信息，所述配置信息包括购物车筛选条件及产品授权类型；
25.页面生成单元，用于接收用户的下单请求，加载用户自定义的配置信息生成自定义下单页面，加载产品关联的活动规则生成产品标签，将产品标签和自定义下单页面发送给用户；
26.购物车信息生成单元，用于缓存用户添加到购物车的产品以及用户选择购物车的勾选状态，生成购物车信息并发送给用户；
27.订单信息生成单元，用于接收用户的购物车确认指令，根据购物车勾选的数据并进行摊销计算，生成订单信息并发送给用户，待用户确认后生成订单购物车。
28.本技术还提供一种终端设备，包括：
29.一个或多个处理器；
30.存储器，与所述处理器耦接，用于存储一个或多个程序；
31.当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如上任一项所述的订单管理方法。
32.本技术还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上任一项所述的订单管理方法。
33.相对于现有技术，本技术的有益效果在于：
34.1、本技术通过订单计算规则，产品选购，购物车等模块都可以实现自定义配置，满足不同用户的要求，整个系统高度可配置化；
35.2、本技术的购物车产品数据和勾选状态在每次点击时已经进行了缓存，并不需要前端传入数据，实现了前端的无状态；
36.3、本技术的订单流程实现了与活动模块和费用模块的关联，实现了订单管理系统的闭环；
37.4、本技术的订单购物车和全局购物车的双重设计实现了改单，可以修改订单的产品。通过当前登陆人和经销商实现全局购物车。下单时，全局购物车将绑定订单id形成订单购物车，可以满足特定权限职位进行改单时通过订单购物车实现订单产品明细的更改，更加灵活方便。
附图说明
38.为了更清楚地说明本技术的技术方案，下面将对实施方式中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
39.图1是本技术某一实施例提供的订单管理方法的流程示意图；
40.图2是本技术另一实施例提供的订单管理方法的流程示意图；
41.图3是本技术某一实施例提供的订单管理配置的流程示意图；
42.图4是本技术某一实施例提供的订单管理系统的结构示意图；
43.图5是本技术某一实施例提供的终端设备的结构示意图。
具体实施方式
44.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
45.应当理解，文中所使用的步骤编号仅是为了方便描述，不对作为对步骤执行先后顺序的限定。
46.应当理解，在本技术说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本技术。如在本技术说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。
47.术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
48.术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。
49.请参阅图1-2，本技术某一实施例提供一种订单管理方法。如图1所示，该订单管理方法包括步骤s10至步骤s40。各步骤具体如下：
50.s10、接收并保存用户自定义的配置信息，所述配置信息包括购物车筛选条件及产品授权类型；
51.在某一个实施例中，所述配置信息还包括费用比例配置、摊销配置以及订单校验步骤。
52.s20、接收用户的下单请求，加载用户自定义的配置信息生成自定义下单页面，加载产品关联的活动规则生成产品标签，将产品标签和自定义下单页面发送给用户；
53.在某一个实施例中，所述加载产品关联的活动规则生成产品标签，包括：
54.根据活动规则查询产品的坎级信息，根据坎级信息计算赠品数量和折价金额，生成产品标签。
55.在某一个实施例中，所述加载产品关联的活动规则生成产品标签，还包括：
56.调用产品检测服务，对产品进行授权检测、停用检测以及活动过期检测；并对过期的产品添加过期标签。
57.s30、缓存用户添加到购物车的产品以及用户选择购物车的勾选状态，生成购物车
信息并发送给用户；
58.s40、接收用户的购物车确认指令，根据购物车勾选的数据并进行摊销计算，生成订单信息并发送给用户，待用户确认后生成订单购物车。
59.在某一个实施例中，所述根据购物车勾选的数据并进行摊销计算，包括：
60.利用订单插件计算勾选的数据中的订单总金额、订单明细、摊销策略以及实付金额。
61.在某一个实施例中，待用户确认后根据用户的全局购物车绑定当前订单信息，生成订单购物车。
62.在某一个实施例中，上述订单管理方法，还包括：
63.接收用户的改单请求，重新加载订单购物车并发送给用户，待用户修改完成后生成新的订单信息，发送给用户进行确认。
64.需要说明的是，针对现有的订单管理流程中存在的信息孤立导致易出错、人工采集导致订单流转效率低、缺乏可配置性以及适配性差等问题，本技术实施例旨在通过协议配置形成产品配置中心，使得用户可以通过在配置中心动态配置购物车选购的筛选条件，资金池和活动管理，通过策略模式和装饰者模式设计的订单计算插件实现经销商的可配置计算规则，通过勾选状态和购物车缓存设计，实时将活动信息和不同产品类型的数据进行摊销计算。
65.在某一个示例性的实施例中，执行步骤s10-s40时具体包括以下内容：
66.(1)用户可以在配置中心自定义配置产品授权，自定义购物车等。
67.(2)点击产品选购时，系统加载用户的自定义协议配置实现自定义下单系统ui显示。
68.(3)系统加载产品关联的活动规则，形成产品标签。
69.(4)用户将选择的活动产品添加到购物车。
70.(5)系统将缓存用户添加到购物车的产品和用户选择购物车的勾选状态。
71.(6)用户点击购物车确认时，订单计算插件自动计算购物车勾选的数据进行摊销计算。
72.(7)用户点击下单，用户的全局购物车会绑定当前订单，形成订单购物车。
73.(8)用户进行改单时，可以通过商城和订单购物车进行操作。
74.为了帮助理解，在本技术的某一具体实施例中，还提供了该订单管理方法的全部流程，包括以下内容：
75.步骤一：配置协议的设置，因为不同客户包含定制化的购物车筛选条件和其他配置项，所以客户可以在图4的全局配置面板实现勾选项配置，当用户点击保存后，配置信息会以json数据格式存放在数据库的全局配置表中；第二项是厂家根据不同的经销商，去选择下单可以扣钱的费用比例配置，这些配置信息存放在费用比例配置表中。
76.步骤二：当厂家选择经销商下单时，会触发协议配置的请求，协议包含两个层面。第一层是全局配置协议，当前端选择经销商后，会触发全局配置协议请求，这时后端会加载存放在全局配置表中的协议，包含开启授权，摊销配置，订单的校验步骤，购物车配置等信息。全局配置协议是对所有经销商生效的；第二层面根据具体传入的经销商信息，去查询和修改经销商配置的费用池，货补池，赠品，整体费用的比例配置信息。然后前端根据这些配
置信息实现自定义ui显示界面。其中，本步骤的订单管理配置的流程图如图3所示。
77.步骤三：后台系统将查询到的价盘，活动信息传递给客户。
78.步骤四：(4)后台将客户选择的活动产品，通过产品的活动信息，通过查询数据库得到坎级信息，通过如下所述的坎级计算公式得到赠品数量和折价金额：
[0079][0080]
步骤五：从步骤三获取的活动信息获得产品数据列表，然后根据产品数据列表调用产品检测服务(具有产品授权检测，产品停用检测，产品活动过期检测，产品停用检测)，对于过期的产品进行添加过期标签，并通过活动加载服务，将每个活动包含的产品一并显示在购物车界面。
[0081]
步骤六：后台将购物车中勾选的数据加载到订单计算插件中，订单插件是采用java编写的，因为客户在购物车选择产品后，选择货补产品，选择费用扣减后都会涉及到订单金额的改变和摊销的改变，所以在这些条件下，都会触发订单插件的调用，订单插件会加载购物车里面的产品信息，费用池的使用信息和货补产品的使用信息，转化为json数组对象，作为订单插件的初始数据入参，根据全局配置的是否开启摊销配置订单插件去选择不同的计算策略。订单插件第一步是会计算这些产品中的订单总金额，每个摊销的总金额和基本销售产品的总金额和总重量和总体积，实付金额，构建订单插件的订单对象出参。第二步是计算订单明细，首先按照产品编码进行产品的分组，然后计算每个产品组的占用的金额和摊销金额。第三步是根据摊销策略，计算每个产品组中每个产品摊销项金额，第四步是计算每个产品的实付金额。第五步是订单插件将产品组最后统一组装成订单详情数组，订单插件将订单对象和订单详情数组封装成一个json对象，传递给调用接口，最后传递到前端，具体的步骤如下：
[0082]
a)设订单总金额为o，首先按照产品进行分组分为：
[0083]
a[a
1,a2,
a3],b[b
1,b2,
b3],c[c
1,
c2]；
[0084]
每个产品组的总金额，总数量分别为ag，bg，cg，an，bn，cn其中每个产品组的中的产品编码都相同，只是产品选择的活动不同和销售方式不同。所以产品组内相同产品的价格会有所不同，但是订单计算要保证每个产品组的最终单价相同。
[0085]
b)摊销计算：对于每个产品组的对于每个摊销m的计算为：
[0086]
[0087][0088][0089]
假设当前配置的摊销组为[m1,m
2,
…
,mn],对于产品a1，可以得到总的摊销金额为：
[0090][0091]
c)实付金额计算：设产品的原价金额为pa，可以根据得到实付金额p
t
：
[0092][0093]
进一步地，得到产品a1的最终单价pf的计算公式为：
[0094][0095]
步骤七：客户点击确认订单，前端会发送确认订单请求，后台将根据通过传递进来的订单详情信息匹配保存在购物车中的数据，后台将匹配成功的数据添加一个绑定订单标识位，并且将该订单编码绑定在这些数据中，全局购物车只会加载没有绑定订单标识位的数据；然后后台会将整理上一步中订单插件计算好的订单实付金额作为现金对象，每个费用池货补池的使用金额作为费用对象，封装好后作为费用插件入参，并且加上类型，冻结金额来冻结下单使用的金额，费用插件也是采用java编写，是现金池和费用池数据变动的统一入口，通过锁机制和事务管理，确保现金池和费用池在并发操作情况下的数据一致性。
[0096]
步骤八：本步骤中，订单购物车可以实现产品信息的更改。当客户进行改单时，由于改单人不一定是当时下单的登陆人，不能加载当时下单的购物车信息，所以订单购物车和全局购物车的加载数据权限有所区分。全局购物车根据登陆人来加载，订单购物车则根据订单id进行加载。实现订单生命周期中订单生成之前和订单改单时数据的隔离。
[0097]
步骤九：当确认改单的信息后，也会调用订单插件去计算此次的订单实付金额和摊销金额。当改单提交时，后台会判断更改后订单与更改前订单的遍历比较，判断修改的类
型是产品信息还是基本信息，同时会调用上述步骤中提及的费用插件。第一步是会加载原订单的实付金额信息和费用池摊销金额信息，并且加上释放标识类型，封装成json对象后，调用费用插件去释放该订单已经冻结的金额；第二步是将此次改单后订单插件计算的实付金额和摊销金额传递给费用插件进行金额的重新冻结。
[0098]
步骤十：当订单签收时，会调用费用插件扣减签收的金额，如果订单部分完成会释放没有签收的金额。
[0099]
步骤十一：采购统计报表会按时调度统计每个产品下单的金额，签收的金额，发货的金额。因为客户会想了解某个产品或者某个品类在本月下单中的下单数据，签收数据，所以该报表也可以按照产品或者品类的维度去进行数据的分组筛选。
[0100]
综上，本技术实施例提供的订单管理方法至少可以实现以下内容：
[0101]
1)订单计算规则，产品选购，购物车等模块都可以实现自定义配置，满足不同客户的要求，整个系统高度可配置化。
[0102]
2)购物车产品数据和勾选状态在每次点击时已经进行了缓存，并不需要前端传入数据，实现了前端的无状态。
[0103]
3)订单系统实现了与活动模块和费用模块的关联，打通了业务闭环。
[0104]
4)订单购物车和全局购物车的双重设计实现了改单，可以修改订单的产品。通过当前登陆人和经销商实现全局购物车。下单时，全局购物车将绑定订单id形成订单购物车，可以满足特定权限职位进行改单时通过订单购物车实现订单产品明细的更改。
[0105]
请参阅图4，在某一实施例中，本技术还提供一种订单管理系统，包括：
[0106]
配置单元01，用于接收并保存用户自定义的配置信息，所述配置信息包括购物车筛选条件及产品授权类型；
[0107]
页面生成单元02，用于接收用户的下单请求，加载用户自定义的配置信息生成自定义下单页面，加载产品关联的活动规则生成产品标签，将产品标签和自定义下单页面发送给用户；
[0108]
购物车信息生成单元03，用于缓存用户添加到购物车的产品以及用户选择购物车的勾选状态，生成购物车信息并发送给用户；
[0109]
订单信息生成单元04，用于接收用户的购物车确认指令，根据购物车勾选的数据并进行摊销计算，生成订单信息并发送给用户，待用户确认后生成订单购物车。
[0110]
可以理解的是，本实施例提供的订单管理系统用于执行如上述任意一项实施例所述的订单管理方法，并实现与其相同的效果，在此不再进一步赘述。
[0111]
请参阅图5，本技术某一实施例提供一种终端设备，包括：
[0112]
一个或多个处理器；
[0113]
存储器，与所述处理器耦接，用于存储一个或多个程序；
[0114]
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如上所述的订单管理方法。
[0115]
处理器用于控制该终端设备的整体操作，以完成上述的订单管理方法的全部或部分步骤。存储器用于存储各种类型的数据以支持在该终端设备的操作，这些数据例如可以包括用于在该终端设备上操作的任何应用程序或方法的指令，以及应用程序相关的数据。该存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，例如静态随
机存取存储器(static random access memory，简称sram)，电可擦除可编程只读存储器(electrically erasable programmable read-only memory，简称eeprom)，可擦除可编程只读存储器(erasable programmable read-only memory，简称eprom)，可编程只读存储器(programmable read-only memory，简称prom)，只读存储器(read-only memory，简称rom)，磁存储器，快闪存储器，磁盘或光盘。
[0116]
在一示例性实施例中，终端设备可以被一个或多个应用专用集成电路(application specific 1ntegrated circuit，简称as1c)、数字信号处理器(digital signal processor，简称dsp)、数字信号处理设备(digital signal processing device,简称dspd)、可编程逻辑器件(programmable logic device，简称pld)、现场可编程门阵列(field programmable gate array，简称fpga)、控制器、微控制器、微处理器或其他电子元件实现，用于执行如上述任一项实施例所述的订单管理方法，并达到如上述方法一致的技术效果。
[0117]
在另一示例性实施例中，还提供一种包括计算机程序的计算机可读存储介质，该计算机程序被处理器执行时实现如上述任一项实施例所述的订单管理方法的步骤。例如，该计算机可读存储介质可以为上述包括计算机程序的存储器，上述计算机程序可由终端设备的处理器执行以完成如上述任一项实施例所述的订单管理方法，并达到如上述方法一致的技术效果。
[0118]
以上所述是本技术的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本技术原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本技术的保护范围。
技术特征：1.一种订单管理方法，其特征在于，包括：接收并保存用户自定义的配置信息，所述配置信息包括购物车筛选条件及产品授权类型；接收用户的下单请求，加载用户自定义的配置信息生成自定义下单页面，加载产品关联的活动规则生成产品标签，将产品标签和自定义下单页面发送给用户；缓存用户添加到购物车的产品以及用户选择购物车的勾选状态，生成购物车信息并发送给用户；接收用户的购物车确认指令，根据购物车勾选的数据并进行摊销计算，生成订单信息并发送给用户，待用户确认后生成订单购物车。2.根据权利要求1所述的订单管理方法，其特征在于，还包括：接收用户的改单请求，重新加载订单购物车并发送给用户，待用户修改完成后生成新的订单信息，发送给用户进行确认。3.根据权利要求1所述的订单管理方法，其特征在于，所述配置信息还包括费用比例配置、摊销配置以及订单校验步骤。4.根据权利要求1所述的订单管理方法，其特征在于，所述加载产品关联的活动规则生成产品标签，包括：根据活动规则查询产品的坎级信息，根据坎级信息计算赠品数量和折价金额，生成产品标签。5.根据权利要求1所述的订单管理方法，其特征在于，所述加载产品关联的活动规则生成产品标签，还包括：调用产品检测服务，对产品进行授权检测、停用检测以及活动过期检测；并对过期的产品添加过期标签。6.根据权利要求1所述的订单管理方法，其特征在于，所述根据购物车勾选的数据并进行摊销计算，包括：利用订单插件计算勾选的数据中的订单总金额、订单明细、摊销策略以及实付金额。7.根据权利要求1所述的订单管理方法，其特征在于，所述待用户确认后生成订单购物车，包括：待用户确认后根据用户的全局购物车绑定当前订单信息，生成订单购物车。8.一种订单管理系统，其特征在于，包括：配置单元，用于接收并保存用户自定义的配置信息，所述配置信息包括购物车筛选条件及产品授权类型；页面生成单元，用于接收用户的下单请求，加载用户自定义的配置信息生成自定义下单页面，加载产品关联的活动规则生成产品标签，将产品标签和自定义下单页面发送给用户；购物车信息生成单元，用于缓存用户添加到购物车的产品以及用户选择购物车的勾选状态，生成购物车信息并发送给用户；订单信息生成单元，用于接收用户的购物车确认指令，根据购物车勾选的数据并进行摊销计算，生成订单信息并发送给用户，待用户确认后生成订单购物车。9.一种终端设备，其特征在于，包括：
一个或多个处理器；存储器，与所述处理器耦接，用于存储一个或多个程序；当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-7任一项所述的订单管理方法。10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-7任一项所述的订单管理方法。
技术总结本申请公开了一种订单管理系统方法、系统、终端设备及存储介质，该方法包括：接收并保存用户自定义的配置信息，配置信息包括购物车筛选条件及产品授权类型；接收用户的下单请求，加载用户自定义的配置信息生成自定义下单页面，加载产品关联的活动规则生成产品标签，缓存用户添加到购物车的产品以及用户选择购物车的勾选状态，生成购物车信息并发送给用户；接收用户的购物车确认指令，根据购物车勾选的数据并进行摊销计算，生成订单信息并发送给用户，待用户确认后生成订单购物车。本申请通过产品配置协议实现订单管理的高可用配置，满足用户自定义定制需求，通过订单插件将费用控制和摊销计算方法整合到订单中，完成整个订单管理的闭环。单管理的闭环。单管理的闭环。
技术研发人员：陈畅 丁明 谭谈 许洁斌
受保护的技术使用者：广州市玄武无线科技股份有限公司
技术研发日：2022.07.11
技术公布日：2022/11/1
