CN107818484A - 管理开票规则的方法和系统 - Google Patents

Abstract

本发明提供一种管理开票规则的方法和系统，能够统一维护开票规则；保证开票规则变更后，各开票系统实时同步。该方法包括：配置规则信息，并将配置好的规则信息保存至数据库，各开票系统的服务器根据校验需求将所需的规则信息初始化至内存，以供开票校验；各开票系统的服务器接入分布式同步协调服务，当规则信息需要变更时，根据变更需求变更配置规则信息，并将变更后的规则信息发送至分布式同步协调服务；分布式同步协调服务将所述变更后的规则信息发送至各开票系统的服务器，各开票系统的服务器根据校验需求将与开票校验相关的变更后的规则信息更新至内存。

Description

管理开票规则的方法和系统

技术领域

本发明涉及计算机技术及软件领域，尤其涉及一种管理开票规则的方法和系统。

背景技术

发票是记录经济活动的重要载体，目前发票的类型大致分为四类：增值税普通发票(以下简称“普票”)、增值税电子发票(以下简称“电子票”)、增值税专用发票(以下简称“增票”)以及营业税发票。各种类型的发票都有各自的开票校验规则。例如普票的开票规则通常为：订单类型、商品类型、开票限额、开票明细条数等；增票的开票规则为：订单类型、商品类型、开票限额、税率、增票资质等；电子票开票规则为：订单类型、商品类型、税率等。

现有的发票开具过程中，各种发票类型的开票系统各自维护一套开票规则，这种开票规则的管理模式在实际使用过程中，具有诸多不便：

1、各开票系统各自维护一套开票规则，且通常情况下同种发票类型的开具又需要多个子系统的支持，从而导致开票规则维护成本较高；

2、一些开票系统为了保证发票开具的准确性，每次开票都访问数据库以获取准确开票规则数据，对数据库的性能造成较大影响；

3、为了减少数据库的访问次数，一些开票系统将开票规则初始化至内存中，但当开票规则发生变更后，其他开票系统或开票系统中的其他服务器无法实时更新，从而可能导致为无需开票的商品错开发票等现象的发生；

4、此外，开票系统中开票规则的变更较为死板，不够灵活，需要频繁的调整业务代码逻辑，重新部署上线，消耗大量人力等资源。

发明内容

有鉴于此，本发明提供一种管理开票规则的方法和系统，能够统一维护开票规则；减小数据库的访问压力；保证开票规则变更后，各开票系统实时同步；此外，还可避免调整开票规则带来的频繁上线部署的问题，提高工作效率，节省资源。

为实现上述目的，根据本发明的一个方面，提供了一种管理开票规则的方法。

本发明的一种管理开票规则的方法包括：配置规则信息，并将配置好的规则信息保存至数据库，各开票系统的服务器根据校验需求将所需的规则信息初始化至内存，以供开票校验；各开票系统的服务器接入分布式同步协调服务，当规则信息需要变更时，根据变更需求变更配置规则信息，并将变更后的规则信息发送至分布式同步协调服务；分布式同步协调服务将所述变更后的规则信息发送至各开票系统的服务器，各开票系统的服务器根据校验需求将与开票校验相关的变更后的规则信息更新至内存。

可选地，所述规则信息包括：基础规则节点及规则树，其中，规则树中根据校验需求定义了若干基础规则节点的校验顺序。

可选地，所述方法还包括：所述分布式同步协调服务基于ZooKeeper实现。

可选地，所述方法还包括：所述分布式同步协调服务在ZooKeeper不可用的情况下，基于消息队列实现。

为实现上述目的，根据本发明的另一方面，提供了一种管理开票规则的系统。

本发明的一种管理开票规则的系统包括：配置模块，用于配置规则信息，并将配置好的规则信息保存至数据库，以及当规则信息需要变更时，根据变更需求变更配置规则信息，并将变更后的规则信息发送至分布式同步协调服务模块；数据库，用于保存规则信息；各开票系统的服务器，用于根据校验需求将所需的规则信息初始化至内存，以供开票校验，还用于接入分布式同步协调服务模块，以及在接收到分布式同步协调服务模块发送的变更后的规则信息后，根据校验需求将与开票校验相关的变更后的规则信息更新至内存；分布式同步协调服务模块，用于接收配置模块发送的变更后的规则信息，以及将所述变更后的规则信息发送至各开票系统的服务器。

可选地，所述规则信息包括：基础规则节点及规则树，其中，规则树中根据校验需求定义了若干基础规则节点的校验顺序。

可选地，所述分布式同步协调服务模块基于ZooKeeper实现。

可选地，所述分布式同步协调服务模块在ZooKeeper不可用的情况下，基于消息队列实现。

根据本发明的技术方案，通过统一配置、变更和保存开票规则信息，从而可以避免各开票系统各自维护一套开票规则，规范管理开票规则，减少开票规则的配置和维护成本，避免频繁上线部署的发生；通过各开票系统的服务器根据校验需求将开票规则保存至内存中，从而可以降低数据库的访问压力；通过将各开票系统的服务器接入分布式同步协调服务，且开票规则变更后，将变更信息通过分布式同步协调服务发送至各开票系统的服务器，从而可以保证开票规则的实时同步，避免各开票系统开票规则不同步造成的多开、错开发票等情况的发生；通过结合ZooKeeper和消息队列的分布式同步协调服务，从而使得同步开票规则更加可靠，ZooKeeper不可用时，自动降级使用消息队列的设置，使得开票规则的管理更稳定。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是根据本发明实施例的管理开票规则的方法的主要步骤的示意图；

图2是根据本发明实施例的规则节点及规则树关系示意图；

图3是根据本发明实施例的管理开票规则的方法的变更后的规则信息同步的主要流程的示意图；

图4是根据本发明实施例的管理开票规则的系统的主要部分的示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

本发明实施例的技术方案的主要为了实现统一维护开票规则，包括所有开票规则树以及规则节点；并且，保证在变更开票规则后，各个开票系统中的开票规则能实时同步，保证每个开票应用系统、每台分布式部署的服务器都能实时准确的获取最新开票规则，避免多开无用的发票；本发明实施例还可实现灵活调整开票规则树的执行顺序和开票规则节点的增删调整；此外，还能够避免增加数据库压力。

图1是根据本发明实施例的管理开票规则的方法的主要步骤的示意图。

如图1所示，本发明实施例的管理开票规则的方法主要包括如下步骤：

步骤S11：配置规则信息，并将配置好的规则信息保存至数据库，各开票系统的服务器根据校验需求将所需的规则信息初始化至内存，以供开票校验。本发明实施例中，规则信息包括：基础规则节点及规则树，其中，规则树中根据校验需求定义了若干基础规则节点的校验顺序。

步骤S12：各开票系统的服务器接入分布式同步协调服务，当规则信息需要变更时，根据变更需求变更配置规则信息，并将变更后的规则信息发送至分布式同步协调服务。本发明实施例中，分布式同步协调服务基于ZooKeeper实现，但在ZooKeeper不可用的情况下，还可降级基于消息队列实现。

ZooKeeper是一个分布式的、开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

消息队列(即Message queue，简称“MQ”)是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针对应用程序的数据(消息)来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息队列中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。

ZooKeeper和消息队列MQ是实现同步的最主要手段。其中，Zookeeper是主要的实现手段，消息队列MQ是消息队列技术的总称，包括ActiveMq，RabbitMQ，Jafka/Kafka等，它们都可用于实现本发明的分布式同步协调服务。

步骤S13：分布式同步协调服务将所述变更后的规则信息发送至各开票系统的服务器，各开票系统的服务器根据校验需求将与开票校验相关的变更后的规则信息更新至内存。

图2是根据本发明实施例的规则节点及规则树关系示意图；图3是根据本发明实施例的管理开票规则的方法的变更后的规则信息同步的主要流程的示意图。以下结合图2和图3对本发明实施例的管理开票规则的方法进行详细描述，尤其是开票规则统一配置流程以及开票规则变更后的同步流程。

如前所述，本发明实施例统一提供规则节点、规则树的维护和查询。基础规则节点只维护一套，而针对不同类型的发票开具，提供不同规则树的维护。每个开票系统，根据开票校验续期，查询本业务系统所需的规则信息，放置内存中，用于每次开票时的校验。

同时本发明实施例借助于开源组件Zookeeper的特有Watcher注册与异步通知机制实现变更后的规则信息的同步吧。这需要使用到开票规则的业务系统接入Zookeeper，一旦开票规则发生变化，则各个开票系统的服务器会在第一时间接收到推送来的最新开票规则信息，从而达到降低数据库压力、避免开出无用发票的目的。且在Zookeeper不可用的情况下，自动降级使用消息队列MQ的形式，依然可实现同步规则信息。

以下对开票规则信息的统一配置的流程进行详细说明。

如图2所示，本发明实施例统一维护开票规则信息，并且可维护多套规则树，规则树中定义多个规则节点的执行顺序。其中，规则节点和规则树仅用于举例说明规则节点、规则树，以及规则树与规则节点的关系，并非用于限定本发明。各开票系统可根据自身业务需求定制规则节点和规则树。例如：增票开具的规则树RULE_X，包含的规则节点以及执行顺序为：1.校验订单类型(订单类型为1、2可以开票，其他不可开票)；2.校验增票资质是否正确；3.校验商品类型是否可以开票；4.校验开票金额是否超额，是否需要拆票；5.校验商品税率是否相同，是否需要拆票。各个开票系统可定制属于自身适用的规则树。

本发明实施例配置规则信息分为规则节点配置和规则树配置。且须先有规则节点的配置，才能配置规则树。本发明实施例中进行规则信息配置的配置中心包括可视化配置界面，基于可视化配置界面进行规则信息的配置。各规则节点下都为相应的明细列表，如：订单类型节点包含A订单类型、B订单类型等，只有这些订单类型才可开票。新增规则节点时，先添加规则节点名称，然后在规则节点下新增对应的明细列表。各规则树下包含了有顺序的规则节点，新增规则树时，先添加规则树名称，然后选择添加已经配置的规则节点，添加顺序即为规则校验执行顺序。规则节点明细以及规则树内容可随时调整，使得开票系统用到的开票规则信息配置灵活、便利、统一。规则信息配置完成后，保存在数据库中。

每个开票子系统的服务器在初始化时，根据数据库提供的查询接口，获取所需的规则树以及规则节点内容，并将规则信息加载到内存中，用于开票前的发票开具校验。

例如普票开具系统A，定制了自己的开票规则树RULE_A。RULE_A包含了1.订单类型校验2.商品类型校验3.开票金额限制4.明细行数限制。查询得到的规则校验顺序依次是1->2->3->4。则A系统会按照此顺序，此规则树校验每个订单，如果校验通过则可以开票；如果校验不通过，则不予开票。

若RULE_A规则树发生变化，即变为：1.校验商品类型2.校验订单类型3.开票金额限制。那么相应的A系统，也会按照当前最新规则顺序以及规则节点验证订单是否可以开票以及拆票规则。动态灵活的调整开票规则，而无需重新上线部署。

假如规则A系统的RULE_A和另外B系统的RULE_B都用到了规则节点“开票限额”，而开票限额发生变化，则相应的凡是用到这两个规则树的所有子系统都会实时更新内存中的规则信息。

以下对开票规则信息变更后的同步流程进行详细说明。

本发明实施例中为保证规则树或规则节点发生变化时，能实时通知各个子系统更新最新规则信息，需要引入Zookeeper的Watcher监听机制。所有用于开票的开票系统的服务器均接入Zookeeper集群，通过Zookeeper的create(“invoice/Rules”)方法，注册到Zookeeper的同一目录下。然后基于Zookeeper的Watcher方法，开票系统的每台服务器监听此节点的状态变化。

初始时，在Zookeeper的“invoice/Rules”节点下写入信息为空。一旦有规则树或规则树下的规则节点发生变化，就将发生变化的规则信息通过setData方法写入Zookeeper下的“invoice/Rules”节点中。此时所有监听此节点的开票系统的服务器都会基于Zookeeper的回调Watcher方法，接收到Zookeeper节点的变更通知。开票系统的服务器监听到变更后的规则信息是本开票系统用到的，则立即将变更后的规则信息更新进内存中，用于发票开具的校验。由此可保证规则树或规则节点变化后，实时同步所有使用到此规则的开票系统。

Zookeeper集群提供了高可用、高性能的协调服务，保证了系统的健壮性。

此外，本发明实施例中，如果Zookeeper写入不可用，即存在异常，则自动降级到使用消息队列MQ的消息异步通知机制，所有开票系统接入消息队列MQ“invoice_rules”方法，通过消息队列MQ的onMessage方法接收配置中心发来的变更消息。

具体变更后的规则信息的同步过程如下：在变动规则树或规则节点后，第一步骤写入数据库，以便后续其他开票系统的服务器查询使用。第二步骤写入Zookeeper，用于实时同步其他开票系统的各服务器。如果第二步骤写入失败，即Zookeeper不可用，则自动改为向消息队列MQ发送消息，将变更的规则树或规则节点通过消息队列MQ的sendMessage方法发送给消息队列“invoice_rules”方法，这样其他接入此消息队列MQ的开票系统的各个服务器也就能在相对实时的情况下，接收到变更后的规则信息，然后将变更后的规则树或规则节点更新进内存中，用于开票的校验。

至此，就可实现结合Zookeeper和MQ，搭建一套高可用、高性能的自动实时同步发票变更规则信息的框架。从而在规则信息变更时，无需重新部署或者重启应用服务器，节省人力物力资源，解决因信息不实时同步造成的开票错误的问题。

根据本发明实施例的管理开票规则的方法可以看出，通过统一配置、变更和保存开票规则信息，从而可以避免各开票系统各自维护一套开票规则，规范管理开票规则，减少开票规则的配置和维护成本，避免频繁上线部署的发生；通过各开票系统的服务器根据校验需求将开票规则保存至内存中，从而可以降低数据库的访问压力；通过将各开票系统的服务器接入分布式同步协调服务，且开票规则变更后，将变更信息通过分布式同步协调服务发送至各开票系统的服务器，从而可以保证开票规则的实时同步，避免各开票系统开票规则不同步造成的多开、错开发票等情况的发生；通过结合ZooKeeper和消息队列的分布式同步协调服务，从而使得同步开票规则更加可靠，ZooKeeper不可用时，自动降级使用消息队列的设置，使得开票规则的管理更稳定。

图4是根据本发明实施例的管理开票规则的系统的主要部分的示意图。

如图4所示，本发明实施例的管理开票规则的系统40主要包括如下部分：配置模块401、数据库402、各开票系统的服务器403以及分布式同步协调服务模块404，其中，

配置模块401用于配置规则信息，并将配置好的规则信息保存至数据库402，各开票系统的服务器403根据校验需求将所需的规则信息初始化至内存，以供开票校验；各开票系统的服务器403接入分布式同步协调服务模块404，当规则信息需要变更时，配置模块401根据变更需求变更配置规则信息，并将变更后的规则信息发送至分布式同步协调服务模块404；分布式同步协调服务模块404将所述变更后的规则信息发送至各开票系统的服务器403，各开票系统的服务器403根据校验需求将与开票校验相关的变更后的规则信息更新至内存。

其中，规则信息包括：基础规则节点及规则树，其中，规则树中根据校验需求定义了若干基础规则节点的校验顺序。

本发明实施例中，分布式同步协调服务模块404可以基于ZooKeeper实现。

此外，分布式同步协调服务模块404在ZooKeeper不可用的情况下，还可以基于消息队列实现。

从以上描述可以看出，通过统一配置、变更和保存开票规则信息，从而可以避免各开票系统各自维护一套开票规则，规范管理开票规则，减少开票规则的配置和维护成本，避免频繁上线部署的发生；通过各开票系统的服务器根据校验需求将开票规则保存至内存中，从而可以降低数据库的访问压力；通过将各开票系统的服务器接入分布式同步协调服务，且开票规则变更后，将变更信息通过分布式同步协调服务发送至各开票系统的服务器，从而可以保证开票规则的实时同步，避免各开票系统开票规则不同步造成的多开、错开发票等情况的发生；通过结合ZooKeeper和消息队列的分布式同步协调服务，从而使得同步开票规则更加可靠，ZooKeeper不可用时，自动降级使用消息队列的设置，使得开票规则的管理更稳定。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (8)

1.一种管理开票规则的方法，其特征在于，包括：

配置规则信息，并将配置好的规则信息保存至数据库，各开票系统的服务器根据校验需求将所需的规则信息初始化至内存，以供开票校验；

各开票系统的服务器接入分布式同步协调服务，当规则信息需要变更时，根据变更需求变更配置规则信息，并将变更后的规则信息发送至分布式同步协调服务；

分布式同步协调服务将所述变更后的规则信息发送至各开票系统的服务器，各开票系统的服务器根据校验需求将与开票校验相关的变更后的规则信息更新至内存。

2.根据权利要求1所述的方法，其特征在于，所述规则信息包括：基础规则节点及规则树，其中，规则树中根据校验需求定义了若干基础规则节点的校验顺序。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：所述分布式同步协调服务基于ZooKeeper实现。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：所述分布式同步协调服务在ZooKeeper不可用的情况下，基于消息队列实现。

5.一种管理开票规则的系统，其特征在于，包括：

配置模块，用于配置规则信息，并将配置好的规则信息保存至数据库，以及当规则信息需要变更时，根据变更需求变更配置规则信息，并将变更后的规则信息发送至分布式同步协调服务模块；

数据库，用于保存规则信息；

各开票系统的服务器，用于根据校验需求将所需的规则信息初始化至内存，以供开票校验，还用于接入分布式同步协调服务模块，以及在接收到分布式同步协调服务模块发送的变更后的规则信息后，根据校验需求将与开票校验相关的变更后的规则信息更新至内存；

分布式同步协调服务模块，用于接收配置模块发送的变更后的规则信息，以及将所述变更后的规则信息发送至各开票系统的服务器。

6.根据权利要求5所述的系统，其特征在于，所述规则信息包括：基础规则节点及规则树，其中，规则树中根据校验需求定义了若干基础规则节点的校验顺序。

7.根据权利要求5所述的系统，其特征在于，所述分布式同步协调服务模块基于ZooKeeper实现。

8.根据权利要求5所述的系统，其特征在于，所述分布式同步协调服务模块在ZooKeeper不可用的情况下，基于消息队列实现。