CN112527402A - 结算方法以及相关装置 - Google Patents

Abstract

本申请公开了一种结算方法及相关装置。其中，结算方法包括：获取待结算的订单，订单标注有属性信息，基于属性信息确定订单对应的分组，其中，不同的分组对应不同的结算方式，按照订单对应的分组的结算方式进行结算，得到结算结果。上述方案，能够提高结算方式的可扩展性。

Description

结算方法以及相关装置

技术领域

本申请涉及计算机技术领域，特别是涉及一种结算方法以及相关装置。

背景技术

随着信息技术的蓬勃发展，电子商务逐渐渗透于人们的日常生活、工作和学习中，例如：个人购买生活用品、个人购买电子产品、企业团购办公用品等等。此外，随着消费观念的改变，对于大额商品，人们也越来越倾向于通过消费金融公司采用分期等借贷形式进行支付订单。

然而，目前消费金融公司并不是单一从自有资源获取订单，往往是和诸如电商、线下商铺等其他渠道方合作的。来源于渠道方的订单成功后，就会对渠道方分佣。对于一笔订单，根据不同的贷款期数、产品属性、贷款总额，往往能够组合、衍生出多种多样的结算方式。此时，若采用诸如Java等的编程语言直接将结算方式编入结算程序，一来，当结算方式改变时需要重新编写结算程序，二来，受专业限制，重新编写的工作也只能由程序员完成，由此可见，直接将结算方式编入结算程序的方式结算方式的可扩展性受到极大的限制。有鉴于此，如何提高结算方式的可扩展性成为亟待解决的问题。

发明内容

本申请主要解决的技术问题是提供一种结算方法以及相关装置，能够提高结算方式的可扩展性。

为了解决上述问题，本申请第一方面提供了一种结算方法，包括获取待结算的订单，订单标注有属性信息；基于属性信息确定订单对应的分组，其中，不同的分组对应不同的结算方式；按照订单对应的分组的结算方式进行结算，得到结算结果。

为了解决上述问题，本申请第二方面提供了一种结算装置，包括获取模块、确定模块和结算模块，获取模块用于获取待结算的订单，订单标注有属性信息；确定模块用于基于属性信息确定订单对应的分组，其中，不同的分组对应不同的结算方式；结算模块用于按照订单对应的分组的结算方式进行结算，得到结算结果。

为了解决上述问题，本申请第三方面提供了一种结算设备，包括相互耦接的存储器和处理器；处理器用于执行存储器存储的程序指令，以实现上述第一方面的结算方法。

为了解决上述问题，本申请第四方面提供了一种存储装置，存储有能够被处理器运行的程序指令，程序指令用于实现上述第一方面的结算方法。

上述方案，获取待结算的订单，且订单标注有属性信息，基于该属性信息确定订单对应的分组，且不同的分组对应不同的结算方式，并按照订单对应的分组的结算方式进行结算，得到结算结果，也就是说，结算方式与结算程序是分离的，并不直接编入结算程序，从而当结算方式发生改变时，只需对结算方式进行更新即可，而不必重新编写结算程序，进而大大提升结算方式的可扩展性。

附图说明

图1是本申请结算方法一实施例的流程示意图；

图2是本申请结算方法另一实施例的流程示意图；

图3是图2中步骤S24一实施例的流程示意图；

图4是本申请结算方法又一实施例的流程示意图；

图5是基于本申请结算方法的结算系统一实施例的框架示意图；

图6是本申请结算装置一实施例的框架示意图；

图7是本申请结算设备一实施例的框架示意图；

图8是本申请存储装置一实施例的框架示意图。

具体实施方式

下面结合说明书附图，对本申请实施例的方案进行详细说明。

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、接口、技术之类的具体细节，以便透彻理解本申请。

本文中术语“系统”和“网络”在本文中常被可互换使用。本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。此外，本文中的“多”表示两个或者多于两个。

请参阅图1，图1是本申请结算方法一实施例的流程示意图。具体而言，可以包括如下步骤：

步骤S11：获取待结算的订单，订单标注有属性信息。

在一个实施场景中，为了后续能够精确地确定订单对应的分组，属性信息可以包括但不限于：名称、编号、结算方式。例如，甲在某电商平台网购了一台智能手机，并通过分期付款的方式支付了采购订单，则消费金融公司与该电商平台之间的待结算订单中，可以包括名称、编号、结算方式，例如：名称为智能手机，编号为3101，结算方式为分期付款等，此外，还可以包括：分期期数(如6期、12期、24期)、贷款总额(如5000人民币、8000人民币、10000人民币)、渠道方(如电商1、电商2、电商3)等等，本实施例在此不做具体限制。

步骤S12：基于属性信息确定订单对应的分组，其中，不同的分组对应不同的结算方式。

在一个实施场景中，为了使结算方式首先适配不同渠道方，可以按照渠道方进行分组，从而得到多个分组，且不同的分组对应不同的结算方式。例如：分组1对应于渠道方为电商1，分组2对应于渠道方为电商2等等。

在另一个实施场景中，为了使结算方式更加精确地适配到渠道方和产品，可以按照渠道方和产品的编号进行分组，从而得到多个分组，且不同的分组对应不同的结算方式。例如：分组1对应于渠道方为电商1且产品编号为A，分组2对应于渠道方为电商1且产品编号为B等等。

此外，还可以根据其他方式对结算方式进行分组，本实施例在此不再一一举例。

举例来说，当获取到待结算的订单的同时，也获取到了订单的属性信息，例如：渠道方为电商1，分期期数为6期、贷款总额为5000人民币，则当按照渠道方分组时，基于该订单的渠道方为电商1，则确定对应的分组为分组1。当采用其他属性信息进行分组时可以以此类推，本实施例在此不再一一举例。

步骤S13：按照订单对应的分组的结算方式进行结算，得到结算结果。

在基于订单的属性信息确定订单的对应的分组之后，即可根据分组对应的结算方式进行结算，并得到结算结果。例如：对于渠道方为电商1，分期期数为6期、贷款总额为5000人民币的订单来说，在确定其对应的分组为分组1时，采用贷款总额的20％进行结算，从而得到结算结果为5000*20％，即1000。其他属性信息的订单可以以此类推，本实施例在此不再一一举例。

上述方案，获取待结算的订单，且订单标注有属性信息，基于该属性信息确定订单对应的分组，不同的分组对应不同的结算方式，并按照订单对应分组的结算方式进行结算，得到结算结果，也就是说，结算方式与结算程序是分离的，并不直接编入结算程序，从而当结算方式发生改变时，只需对结算方式进行更新即可，而不必重新编写结算程序，进而大大提升结算方式的可扩展性。

请参阅图2，图2是本申请结算方法另一实施例的流程示意图。本实施例中，图2具体为图1所示的结算方法一具体实施例的流程示意图。具体而言，可以包括如下步骤：

步骤S21：获取规则文件，并按照规则文件的属性信息和预设规则引擎分组方式划分规则文件，得到多个分组。

规则文件是用户根据具体应用场景而预先编辑好的在不同属性信息情况下的结算方式的集合。

规则引擎是一种推理引擎，它是根据已有的事实，从规则文件知识库中匹配规则文件，并处理存在冲突的规则文件，执行最后筛选通过的规则文件。

本实施例中，预设规则引擎可以是商业规则引擎iLog、jRules，开源规则引擎drools等等，本实施例在此不做具体限制。规则引擎可以获取规则文件，并按照规则文件的属性信息和预设规则引擎分组方式划分规则文件，得到多个分组。例如，当预设规则引擎为drools时，可以采用drools中的rule-flow-group语法元素对规则文件进行分组，例如根据规则文件中渠道方这一属性信息对规则文件进行分组。

如前述实施例，在一个实施场景中，可以按照属性信息中的渠道方和产品的编号对规则文件进行分组，例如：对于渠道方为电商1且产品的编号为A的规则文件划分至分组1、渠道方为电商1且产品的编号为B的规则文件划分至分组2等等，本实施例在此不做具体限制。

在一个实施场景中，为了便于用户编辑、变更规则文件，用户可以在运行有规则文件管理程序的终端上进行规则文件的管理，规则文件管理程序可以是Guvnor等，本实施例在此不做具体限制。

步骤S22：获取待结算的订单，其中，订单标注有属性信息。

具体请参阅步骤S11。

步骤S23：通过路由多个分组，将所述规则文件的属性信息与订单的属性信息相同的分组确定为与订单对应的分组，其中，不同的分组对应不同的结算方式。

规则引擎路由多个分组，从而将属性信息与订单的属性信息相同的分组确定为与订单对应的分组。以前述实施例中的分组1为例，当按照渠道方和产品的编号进行分组时，分组1对应于渠道方为电商1且产品的编号为A的订单，该分组下一般包含多个规则文件，例如针对渠道方为电商1且产品的编号为A、分期期数为12期的规则文件，针对渠道方为电商1且产品的编号为A、分期期数为24期的规则文件等等。此时，在对分组路由时，针对渠道方为电商1且产品的编号为A、分期期数为12期的订单，首先在多个分组中，路由到同样渠道方为电商1且产品的编号为A的分组1，继续对分组1路由，最终路由到分期期数为12期的规则文件。

步骤S24：按照订单对应的分组的结算方式进行结算，得到结算结果。

具体请参阅步骤S13。

在一个实施场景中，请结合参阅图3，图3是图2中步骤S24一实施例的流程示意图，本实施例中，步骤S24具体可以包括：

步骤S241：获取与订单对应的分组匹配的分佣比例。

仍以上述分组为例，当路由多个分组，匹配到对应的分组后，再路由该分组内的规则文件，最终根据对应规则文件所定义的结算方式，确定分佣比例，例如20％。

步骤S242：按照分佣比例计算得到分佣结果。

根据得到的分佣比例，从而计算得到分佣结果为5000*20％，即最终得到的分佣结果为1000。

在一个实施场景中，还可以将结算结果保存到全局变量存储类中，从而使得结算程序可以从该全局变量存储类中调取结算结果。结算程序可以是采用Java等编程语言预先编好的预设程序，进而在得到结算结果之后，预设程序可以将调用到的结算结果存储，例如，存储至数据库中。

上述方案，在获取待结算的订单之前，按照规则文件的属性信息和预设规则引擎分组方式划分规则文件，从而使得后续基于属性信息确定订单对应的分组时，可以直接利用规则引擎路由多个分组，进而确定对应的分组，进一步提高了结算的效率。

请参阅图4，图4是本申请结算方法又一实施例的流程示意图。本实施例中，图4具体为图1所示的结算方法一具体实施例的流程示意图。具体而言，可以包括如下步骤：

步骤S41：判断是否扫描到新的规则文件。若是，则执行步骤S42。

在一个实施场景中，可能存在用户更新规则文件的情况，例如，消费金融公司与渠道方重新签订了分佣合同，则此时需要对规则文件进行更新。为了能够在后续结算过程中，采用新的结算方式，需要判断是否扫描到新的规则文件。

在一个实施场景中，可以在固定时间判断是否扫描到新的规则文件；在另一个实施场景中，还可以每隔一预设时长判断是否扫描到新的规则文件，本实施例在此不做具体限制。

在一个实施场景中，为了方便地扫描规则文件知识库，以判断其中是否存在新的规则文件，可以利用KieScanner等规则文件扫描工具对规则文件知识库进行扫描。

步骤S42：获取新的规则文件。

当扫描确定存在新的规则文件时，则获取该新的规则文件。

步骤S43：按照规则文件的属性信息和预设规则引擎分组方式划分规则文件，得到多个分组。

具体请参阅步骤S21。

步骤S44：获取待结算的订单，订单标注有属性信息。

具体请参阅步骤S22。

步骤S45：通过路由多个分组，将规则文件的属性信息与订单的属性信息相同的分组确定为与订单对应的分组。

具体请参阅步骤S23。

步骤S46：按照订单对应的分组的结算方式进行结算，得到结算结果。

具体请参阅步骤S24。

上述步骤S41中，若判断未扫描到新的规则文件，则执行下述步骤S47。

步骤S47：返回执行步骤S44。

也就是说，当判断未扫描到新的规则文件时，则说明用户并未更新规则文件，则仍然沿用原来的规则文件即可，即继续获取待结算的订单，并执行通过路由多个分组，将属性信息与订单的属性信息相同的分组确定为与订单对应的分组以及后续步骤。

上述方案，通过判断是否扫描到新的规则文件，可以在用户更新规则文件时，规则引擎自动采用新的规则文件，并重新按照规则文件的属性信息进行分组，并继续对订单路由新的分组，得到相应的结算方式，并最终得到结算结果。

请参阅图5，图5是基于本申请结算方法的结算系统一实施例的框架示意图。如图5所示，本实施例中的结算系统可以基于drools规则引擎设计，当然，也可以基于其他规则引擎设计，例如iLog、jRules等等，本实施例在此不做具体限制。关于drools、iLog、jRules等规则引擎的具体标准为本领域的现有技术，本实施例在此不再赘述。在此基础上，为了便于用户新增、更改、删除规则文件，结算系统还可以包括规则文件管理程序，例如Guvnor等等。关于Guvnor等规则文件管理程序的具体标准为本领域的现有技术，本实施例在此不再赘述。在此基础上，为了便于管理结算项目，结算系统还可以包括项目管理工具，例如Maven，用户可以通过Maven将规则文件打包。关于Maven等项目管理工具的具体标准为本领域的现有技术，本实施例在此不再赘述。在此基础上，为了便于归集多个规则文件，结算系统还可以包括规则文件知识库，其中包含了用户通过项目管理工具打包上传的规则文件。在此基础上，为了扫描规则文件知识库中是否存在新的规则文件，结算系统还可以包括规则文件扫描工具，例如KieScanner等，关于KieScanner等规则文件扫描工具的具体标准为本领域的现有技术，本实施例在此不再赘述。

下面结合图5，举例说明本申请结算方法：

用户在诸如Guvnor等规则文件管理程序编辑规则文件，并根据规则文件的属性信息设置规则文件对应的结算方式，在一个实施场景中，当规则引擎采用drools时，根据属性信息的不同可以对渠道方1(merchantNo-1)设置相应的规则文件，如下为采用drools语法规则的规则文件：

上述规则文件的规则名称为“rule3101-24”，适用属性信息所包含的渠道方为merchantNo-1的待结算订单，并且设置相应的结算规则为：当待结算的订单的属性信息中的分期期数period为24期，且产品编号为3101时，结算结果为贷款总额goodsLoanAmt的10％。

或者，还可以包括如下同样采样drools语法规则的规则文件：

上述规则文件的规则名称为“rule3101-12”，适用属性信息所包含的渠道方为merchantNo-1的待结算订单，并且设置相应的结算规则为：当待结算的订单的属性信息中的分期期数period为12期，且产品编号为3101时，结算结果为贷款总额goodsLoanAmt的20％。

当用户编辑好规则文件之后，诸如Maven等项目管理工具将规则文件打包为jar包或war包，并上传到规则文件知识库中。仍以上述两则采用drools语法规则的规则文件为例，最终可以打包为：

诸如drools等的规则引擎一方面可以获取待结算的订单，其中，订单中标注有属性信息，例如名称、编号、贷款总额、分期期数、渠道方等等。

规则引擎另一方面可以从规则文件知识库中获取规则文件，并按照规则文件属性信息和预设规则引擎分组方式划分规则文件，得到多个分组，例如将上述两则采用drools语法规则的规则文件根据属性信息“rule-flow-group”所限定的渠道方而划分至同一分组。

规则引擎路由多个分组，首先可以路由到与订单中所标注的渠道方一致的分组，再在该分组下，继续路由，并路由到其他属性信息一致的规则文件。例如，订单乙所表述的属性信息为：渠道方为merchantNo-1、产品的编号为3101、分期期数为12期，则最终首先可以路由到包含规则文件“rule3101-24”和“rule3101-12”的规则文件，对这两个规则文件继续路由，则可以确定规则文件“rule3101-12”的属性信息与订单的属性信息一致，从而确定后续采用该规则文件所限定的结算方式进行结算。

规则引擎根据规则文件获取对应订单的分佣比例，并根据分佣比例计算得到最终需要分配给渠道方的分佣结果。以确定规则文件“rule3101-12”为订单乙所适用的规则文件，因此，获取到该规则文件所限定的分佣比例为20％，则计算得到的分佣结果为：贷款总额的20％。对于多个待结算的订单而言可以以此类推得到分佣结果，本实施例在此不再一一举例。

规则引擎将计算得到的分佣结果存入到全局变量存储类中，从而诸如采用Java等编程语言编写的预设程序可以从全局变量存储类中获取得到计算得到的分佣结果，并进行存储，在一个实施场景中，预设程序将分佣结果存储至数据库中。

此外，在上述步骤实施过程中，诸如KieScanner等的规则文件扫描工具还可以以一预设时间间隔或在预设时间点，对规则文件知识库进行扫描，以判断规则文件知识库中是否上传了新的规则文件，当确定存在新的规则文件后，则可以反馈给规则引擎，由规则引擎获取新的规则文件，并重新按照规则文件的属性信息和预设规则引擎分组方式划分规则文件，得到多个新的分组，并继续执行后续的步骤。

此外，上述实施例中，规则文件管理程序、项目管理工具、规则文件知识库、规则引擎、规则文件扫描工具、预设程序可以集成于同一结算平台，也可以分属于不同的平台，本实施例在此不做具体限制。

上述方案，可以将规则文件所限定的逻辑与逻辑中具体的数据分隔开，从而当结算方式发生改变时，只需对结算方式进行更新即可，而不必重新编写结算程序，进而大大提升结算方式的可扩展性。

请参阅图6，图6是本申请结算装置60一实施例的框架示意图。具体而言，结算装置60包括获取模块61、确定模块62、结算模块63，其中，获取模块61用于获取待结算的订单，订单标注有属性信息，确定模块62用于基于属性信息确定订单对应的分组，其中，不同的分组对应不同的结算方式；结算模块63用于按照订单对应的分组的结算方式进行结算，得到结算结果。

上述方案，获取待结算的订单，且订单标注有属性信息，基于该属性信息确定订单对应的分组，且不同的分组对应不同的结算方式，并按照订单对应的分组的结算方式进行结算，得到结算结果，也就是说，结算方式与结算程序是分离的，并不直接编入结算程序，从而当结算方式发生改变时，只需对结算方式进行更新即可，而不必重新编写结算程序，进而大大提升结算方式的可扩展性。

在一些实施例中，结算装置60还包括分组模块，用于获取规则文件，并按照规则文件的属性信息和预设规则引擎分组方式划分规则文件，得到多个分组。确定模块62具体用于通过路由多个分组，将属性信息与订单的属性信息相同的分组确定为与订单对应的分组。属性信息包括名称、编号或结算方式中的任一种或多种。

区别于前述实施例，在获取待结算的订单之前，按照规则文件的属性信息和预设规则引擎分组方式划分规则文件，从而使得后续基于属性信息确定订单对应的分组时，可以直接利用规则引擎路由多个分组，进而确定对应的分组，进一步提高了结算的效率。

在一些实施例中，结算模块63包括匹配子模块，用于获取与订单对应的分组匹配的分佣比例，结算模块还包括计算子模块，用于按照分佣比例计算得到分佣结果。

在一些实施例中，结算装置60还包括判断模块，用于判断是否扫描到新的规则文件，当判断模块判断扫描到新的规则文件时，分组模块还用于获取新的规则文件，并按照规则文件的属性信息和预设规则引擎分组方式划分规则文件，得到多个分组。

区别于前述实施例，通过判断是否扫描到新的规则文件，可以在用户更新规则文件时，规则引擎自动采用新的规则文件，并重新按照规则文件的属性信息进行分组，并继续对订单路由新的分组，得到相应的结算方式，并最终得到结算结果。

在一些实施例中，结算模块63还用于将结算结果保存到全局变量存储类中。

在一些实施例中，结算装置60还包括存储模块，用于通过预设程序存储结算结果。

请参阅图7，图7是本申请结算设备70一实施例的框架示意图。结算设备70包括相互耦接的存储器71和处理器72，处理器72用于执行存储器71存储的程序指令，以实现上述任一结算方法实施例中的步骤。

具体而言，处理器72用于控制其自身以及存储器71以实现上述任一结算方法实施例中的步骤。处理器72还可以称为CPU(Central Processing Unit，中央处理单元)。处理器72可能是一种集成电路芯片，具有信号的处理能力。处理器72还可以是通用处理器、数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(Application SpecificIntegrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。另外，处理器72可以由多个集成电路芯片共同实现。

上述方案，将结算方式与结算程序分离，而并不直接编入结算程序，从而当结算方式发生改变时，只需对结算方式进行更新即可，而不必重新编写结算程序，进而大大提升结算方式的可扩展性。

请参阅图8，图8是本申请存储装置80一实施例的框架示意图。存储装置80存储有能够被处理器运行的程序指令81，程序指令81用于实现上述任一实施例中的结算方法。

上述方案，将结算方式与结算程序分离，而并不直接编入结算程序，从而当结算方式发生改变时，只需对结算方式进行更新即可，而不必重新编写结算程序，进而大大提升结算方式的可扩展性。

在本申请所提供的几个实施例中，应该理解到，所揭露的方法和装置，可以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性、机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施方式方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

Claims (10)

1.一种结算方法，其特征在于，包括：

获取待结算的订单，所述订单标注有属性信息；

基于所述属性信息确定所述订单对应的分组，其中，不同的分组对应不同的结算方式；

按照所述订单对应的分组的结算方式进行结算，得到结算结果。

2.根据权利要求1所述的结算方法，其特征在于，所述获取待结算的订单的步骤之前还包括：

获取规则文件，并按照所述规则文件的属性信息和预设规则引擎分组方式划分所述规则文件，得到多个所述分组；

所述基于所述属性信息确定所述订单对应的分组的步骤包括：

通过路由多个所述分组，将所述规则文件的属性信息与所述订单的属性信息相同的分组确定为与所述订单对应的分组。

3.根据权利要求1所述的结算方法，其特征在于，所述属性信息包括所述订单的名称、编号或结算方式中的任一种或多种。

4.根据权利要求1至3任一项所述的结算方法，其特征在于，所述按照所述订单对应的分组的结算方式进行结算，得到结算结果的步骤包括：

获取与所述订单对应的分组匹配的分佣比例；

按照所述分佣比例计算得到分佣结果。

5.根据权利要求2所述的结算方法，其特征在于，所述方法还包括：

判断是否扫描到新的规则文件；

若是，则获取所述新的规则文件，并重新执行按照所述规则文件的属性信息和预设规则引擎分组方式划分所述规则文件，得到多个所述分组的步骤以及后续步骤。

6.根据权利要求1所述的结算方法，其特征在于，所述按照所述订单对应的分组的结算方式进行结算，得到结算结果的步骤还包括：

将所述结算结果保存到全局变量存储类中。

7.根据权利要求1或6所述的结算方法，其特征在于，所述按照所述订单对应的分组的结算方式进行结算，得到结算结果的步骤之后还包括：

通过预设程序存储所述结算结果。

8.一种结算装置，其特征在于，包括：

获取模块，用于获取待结算的订单，所述订单标注有属性信息；

确定模块，用于基于所述属性信息确定所述订单对应的分组，其中，不同的分组对应不同的结算方式；

结算模块，用于按照所述订单对应的分组的结算方式进行结算，得到结算结果。

9.一种结算设备，其特征在于，包括相互耦接的存储器和处理器；

所述处理器用于执行所述存储器存储的程序指令，以实现权利要求1至7任一项所述的方法。

10.一种存储装置，其特征在于，存储有能够被处理器运行的程序指令，所述程序指令用于实现权利要求1至7任一项所述的方法。

Images