投保数据审核方法、装置、计算机设备和存储介质与流程

本申请涉及计算机技术领域，特别是涉及一种投保数据审核方法、装置、计算机设备和存储介质。

背景技术：

随着保险业务的发展，为了保证自动核保的准确性，通常在进行保单数据审核时需要对保单执行成百上千条被编译为不同代码的核保规则。

然而，在传统的方式中，一般是将所有的核保规则毫无秩序的上传到规则引擎当中，通过对业务规则的lhs(antecedent或left-hand-side)的具体编写来控制规则是否执行，这样每次进行核保执行规则时需要将所有的核保规则都加载一遍，导致核保效率较低。

技术实现要素：

基于此，有必要针对上述技术问题，提供一种能够提高核保效率的投保数据审核方法、装置、计算机设备和存储介质。

一种投保数据审核方法，所述方法包括：

接收第一终端上传的投保数据，所述投保数据携带有关键字段；

利用所述关键字段对多个规则包进行筛选，并从所述规则包中筛选出与所述投保数据对应的规则文件；

根据所述关键字段确定筛选出的多个规则文件的执行顺序；

根据所述执行顺序加载筛选出的多个规则文件，根据加载后的规则文件对所述投保数据进行审核。

在其中一个实施例中，所述根据所述关键字段确定筛选出的多个规则文件的执行顺序包括：

读取配置文件，所述配置文件中记录了关键字段对应的优先级别；

根据所述关键字段对应的优先级别确定与所述关键字段对应的规则文件的执行顺序。

在其中一个实施例中，所述方法还包括：

接收第二终端上传的规则文件更新请求，所述更新请求中携带了关键字段以及更新后的规则文件；

根据所述关键字段获取更新前的规则文件；

根据所述更新后的规则文件覆盖所述更新前的规则文件。

在其中一个实施例中，所述方法利用所述关键字段对多个规则文件进行筛选之前还包括：

判断所述投保数据量是否达到预设阈值；

若是，获取多个投保数据的关键字段；

根据所述关键字段对所述投保数据进行分类处理。

在其中一个实施例中，所述根据所述关键字段对所述投保数据进行分类处理之后还包括：

根据所述投保数据生成待审核工作流；

获取当前日期和预存的日期表，所述日期表中携带多个日期标识；

根据所述日期表获取当前日期相对应的日期标识；

根据日期标识抓取所述待审核工作流。

在其中一个实施例中，所述接收第一终端上传的投保数据之前包括：

接收第一终端上传的规则文件，所述规则文件携带文件标识；

根据所述文件标识对所述规则文件进行分类打包，得到多个规则包。

一种投保数据审核装置，所述装置包括：

接收模块，用于接收第一终端上传的投保数据，所述投保数据包括关键字段；

筛选模块，用于利用所述关键字段对多个规则包进行筛选，并从所述规则包中筛选出与所述投保数据对应的规则文件；

确定模块，用于根据所述关键字段确定筛选出的多个规则文件的执行顺序；

审核模块，用于根据所述执行顺序加载筛选出的多个规则文件，利用加载后的规则文件对所述投保数据进行审核。

在其中一个实施例中，所述确定模块还用于读取配置文件，所述配置文件中记录了关键字段对应的优先级别；根据所述关键字段对应的优先级别确定与所述关键字段对应的规则文件的执行顺序。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述任一项所述的投保数据审核方法。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现任一项所述的投保数据审核方法。

上述投保数据审核方法、装置、计算机设备和存储介质，服务器首先接收第一终端上传的投保数据，投保数据携带有关键字段。利用关键字段对多个规则包进行筛选，并从所述规则包中筛选出与投保数据对应的规则文件。根据关键字段确定筛选出的多个规则文件的执行顺序，根据执行顺序加载筛选出的多个规则文件，根据加载后的规则文件对投保数据进行审核。上述方法利用关键字段筛选出与其相对应的规则文件，并根据执行顺序对保单数据进行审核，提高了保单数据的审核效率。

附图说明

图1为一个实施例中投保数据审核方法的应用环境图；

图2为一个实施例中投保数据审核方法的流程示意图；

图3为一个实施例中规则文件执行顺序示意图；

图4为一个实施例中根据关键字段筛选多个规则文件步骤的流程示意图；

图5为一个实施例中利用关键字段对多个规则文件进行筛选之前步骤的流程示意图；

图6为一个实施例中投保数据审核方法装置的结构框图；

图7为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的投保数据审核方法，可以应用于如图1所示的应用环境中。其中，第一终端102和第二终端104通过网络与服务器106进行通信。其中，第一终端102和第二终端104可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，服务器106可以用独立的服务器或者是多个服务器组成的服务器集群来实现。服务器106接收第一终端102上传的投保数据，投保数据中携带有关键字段。服务器106利用关键字段对多个规则包进行筛选，并从所述规则包中筛选出与投保数据对应的规则文件。服务器106根据关键字段确定筛选出的多个规则文件的执行顺序，并且根据执行顺序加载筛选出的多个规则文件，根据加载后的规则文件对投保数据进行审核。并且，当服务器106接收第二终端104上传的规则文件更新请求，根据更新请求中携带的关键字段和更新后的规则文件进行规则文件更新。

在一个实施例中，如图2所示，提供了一种投保数据审核方法，以该方法应用于图1中的服务器为例进行说明，包括以下步骤：

s202，接收第一终端上传的投保数据，投保数据携带有关键字段。

s204，利用关键字段对多个规则包进行筛选，并从所述规则包中筛选出与投保数据对应的规则文件。

投保数据中包括投保用户的个人信息、投保信息以及有关于投保信息相对应的关键字段，关键字段包括文件标识和数据标识。规则包是指用于存储多个规则文件的压缩包或者文件夹。规则文件是指在终端预先编写用于审核投保数据的代码规则，在终端编写不同规则文件的同时为不同的规则文件添加不同的文件标识，通过文件标识识别该规则文件用于审核投保数据的哪一部分。将完成编写的规则文件发送给服务器，服务器接收到终端上传的规则文件时，获取规则文件的文件标识，根据文件标识对规则文件进行分类存储，不同类别的规则文件分别打包放入不同的规则包中。当服务器接收到第一终端上传的投保数据时，投保数据中携带了关键字段。其中，关键字段包括文件标识和数据标识。服务器利用文件标识确定该投保数据对应的规则文件所在的规则包，再利用数据标识对规则包内的规则文件进行筛选，从规则包中的多个规则文件中筛选出与投保数据相对应的规则文件。

例如，文件标识可以包括：通用规则文件、渠道规则文件、平台规则文件以及产品规则文件等。也就是说，根据上述文件标识进行规则文件的分类可以分为通用规则包、渠道规则包、平台规则包以及产品规则包四种。每个规则包中存储相应的规则文件。通用规则包则存储一类通用规则和二类通用规则，渠道规则包则存储网销规则和电销规则，平台规则包存储金管家规则、淘宝规则、陆金所规则和京东规则，产品规则包则存储2000产品规则、2002产品规则、2004产品规则以及2006产品规则，上述规则包以及规则包对应存储的规则类型不限于上述几种，可以根据实际情况进行设置。也就是说，关键字段中的数据标识包括但不限于以下：一类通用、二类通用、网销、电销、淘宝、陆金所、金管家、京东、2000、2002、2004以及2006。当服务器接收的第一终端上传的投保数据所携带的关键字段中的文件标识是渠道规则文件，以及数据标识是电销，则服务器根据渠道规则文件对所有的规则包进行筛选，获取该文件标识对应的渠道规则包。再利用数据标识电销从渠道规则包中筛选出与该数据标识电销所对应的电销规则。

s206，根据关键字段确定筛选出的多个规则文件的执行顺序。

s208，根据执行顺序加载筛选出的多个规则文件，根据加载后的规则文件对投保数据进行审核。

在一个实施例中，根据关键字段确定筛选出的多个规则文件的执行顺序包括：读取配置文件，配置文件中记录了关键字段对应的优先级别；根据关键字对应的优先级别确定与关键字段对应的规则文件的执行顺序。

服务器预先设置配置文件，为保险数据的关键字段设定对应的优先级别并在配置文件中记录多个关键字段对应的优先级别。当服务器筛选出保单数据对应的规则文件之后，读取配置文件，根据规则文件对应的关键字段获取对应的执行优先级别。其中，由于关键字段包括文件标识和数据标识，并且文件标识和数据标识是相对应的，因此配置文件中可以只记录文件标识对应的优先级别或者数据标识对应的优先级别。通过文件标识和数据标识其中任意一个的优先级别即可确定规则文件的优先级别。例如，若配置文件通过设置文件标识的执行优先级别，若设定通用规则文件的执行优先级别为第一级，则通用规则包的执行优先级别为第一级，则该通用规则包内存储的一类通用规则和二类通用规则的执行优先级别均为第一级。若配置文件通过设置数据标识的执行优先级别，若设定一类通用为第一级，则一类通用所对应的通用规则包的执行优先级别为第一级，则通用规则包内存储的规则文件的执行优先级别均为第一级。

执行顺序根据优先级别的等级进行排序，优先级别越高的规则文件越先执行，优先级别越低的越后执行。设定的优先级别可以为：第一级、第二级、第三级、第四级等以此类推。并且级别大小关系可以为：第一级高于第二级高于第三级高于第四级，或者第四级高于第三级高于第二级高于第一级，可根据实际情况进行设定。若以第一级高于第二级高于第三级高于第四级为例：则优先级别为第一级的规则文件最先加载执行、然后加载执行优先级别为第二级的规则文件、其次加载执行优先级别为第三级的规则文件、最后加载执行规则文件为第四级的规则文件。

例如，如图3所示，提供一种规则文件执行顺序示意图。当服务器接收到的投保数据所携带的关键字段有：文件标识包括通用规则文件、渠道规则文件、平台规则文件以及产品规则文件，数据标识包括一类通用、网销、金管家、2000以及2006。服务器首先通过文件标识确定该保险数据涉及到的规则包有通用规则包、渠道规则包、平台规则包以及产品规则包，再利用数据标识一类通用规则、网销、淘宝、2000以及2006分别从通用规则包、渠道规则包、平台规则包以及产品规则包中筛选出一类通用规则、网销规则、淘宝规则、2000产品规则以及2006产品规则。服务器读取配置文件，根据配置文件中记录的关键字段对应的优先级别确定一类通用规则为第一级、网销规则为第二级、金管家规则为第三级、2000产品规则以及2006产品规则为第四级，则再根据该优先级别分别进行规则文件的加载对投保数据进行审核。其中，第四级别的产品规则文件有2002产品规则和2006产品规则，由于可能出现同一个用户对多个保险险种进行投保的情况，因此，当服务器根据用户投保数据的关键字段就可能存在从产品规则包中筛选出多个产品规则文件。因此，当根据投保数据筛选出多个产品规则文件时，则获取该用户的投保信息，根据投保信息确定用户所投保的保险险种的主次关系，筛选出主险产品和副险产品，优先执行主险产品的规则文件。例如2002产品为主险产品，2006产品为副险产品，则加载顺序为：首先加载一类通用规则对投保数据进行审核，然后加载网销规则对投保数据进行审核，其次加载淘宝规则对投保数据进行审核，最后先加载2002产品规则文件对投保数据进行审核，再加载2006产品规则文件对投保数据进行审核。

上述投保数据审核方法，服务器首先接收第一终端上传的投保数据，投保数据包括关键字段。利用关键字段对多个规则文件进行筛选，筛选出与投保数据对应的规则文件。根据关键字段确定筛选出的多个规则文件的执行顺序，根据执行顺序加载筛选出的多个规则文件，利用加载后的规则文件对投保数据进行审核。上述方法利用关键字段筛选出与其相对应的规则文件，并根据执行顺序对保单数据进行审核，提高了保单数据的审核效率。

在一个实施例中，如图4所示，提供一种规则文件更新方法，包括以下步骤：

s402，接收第二终端上传的规则文件更新请求，更新请求中携带了关键字段以及更新后的规则文件。

s404，根据关键字段获取更新前的规则文件。

s406，根据更新后的规则文件覆盖更新前的规则文件。

规则文件更新请求是指业务人员通过操作第二终端向服务器发送的用于请求更新规则文件的指令。当规则文件有更新需求时，业务人员可以预先在第二终端进行更新后规则文件的重新编写或者根据规则文件的关键字段首先从服务器中获取被更新的规则文件，然后根据需求对被更新规则文件进行补充编写。若更新的规则文件是重新编写的，则通过第二终端向服务器发送规则文件更新请求，并在更新文件请求中携带更新后的规则文件以及被更新的旧规则文件的关键字段。服务器接收到第二终端上传的规则文件更新请求后，根据关键字段中的文件标识对多个规则包进行筛选，筛选出文件标识对应的规则包。根据关键字段中的数据标识从规则包中筛选到与数据标识相对应的旧规则文件，也就是没有更新前的规则文件。获取到旧规则文件后，将更新后的规则文件覆盖旧规则文件，也就是更新后的规则文件覆盖更新前的规则文件。其中，覆盖为将更新前的规则文件完全删除，将更新后的规则文件存储进对应的规则包中，保证规则文件的唯一性。若规则文件是从服务器获取的补充编写的被更新规则文件，则在被更新规则文件补充编写完成后，通过第二终端想服务器发送更新请求，更新请求中携带被更新规则文件。服务器根据被更新规则文件的原存储路径进行存储。

在一个实施例中，如图5所示，利用关键字段对多个规则文件进行筛选之前还包括以下步骤：

s502，判断投保数据量是否达到预设阈值。

s504，若是，获取多个投保数据的关键字段。

s506，根据关键字段对投保数据进行分类处理。

当服务器接收到第一终端上传的投保数据后，可以实时对投保数据进行筛选审核工作，或者将投保数据进行存储用于批量式审核，可以根据实际需求进行设定。当服务器设置为批量式审核投保数据时，服务器定时扫描以存储的投保数据量，当投保数据的数据量达到预设的设定阈值时，获取多个投保数据的关键字段。其中，可以获取指定数量的投保数据对应的关键字段，也可以当投保数据量达到阈值时获取所有还未进行核保的投保数据的关键字段。根据关键字段对投保数据进行分类，有相同关键字段的投保数据分为同一类。利用分类后的投保数据对应的关键字段进行规则文件的筛选，根据关键字段再确定规则文件的执行顺序，根据该执行顺序同时对多个投保数据进行审核。例如，当有100个用户的投保数据的文件标识为通用规则文件、渠道规则文件、平台规则文件和产品规则文件，并且数据标识为二类、网销、淘宝以及2002产品。则将该100个用户的投保数据打包成一类，根据该相同的关键字段确定好规则文件后，统一对100个用户的投保数据进行审核。在本实施中，当投保数据达到阈值时，根据关键字段对投保数据进行分类并统一根据关键字段进行数据审核，通过批量审核保单数据保证了审核工作效率，节约资源。

在一个实施例中，根据关键字段对投保数据进行分类处理后还包括：根据投保数据生成待审核工作流；获取当前日期和预存的日期表，所述日期表中携带多个日期标识；根据日期表获取当前日期相对应的日期标识；根据日期标识抓取待审核工作流。

当服务器根据关键字段将投保数据进行分类处理后，根据每一个类型的投保数据生成待审核工作流，表示当前该类别的投保数据还没有进行审核。服务器定期获取当前日期和预存的日期表，日期表中的每个日期都携带日期标识。通过日期表与当前日期进行匹配，获取当前日期的日期标识。其中，日期标识包括工作日和非工作日，可以预先设定日期表中的周一至周五的日期标识为工作日，周六到周日的日期标识为非工作日。当前日期的日期标识若为工作日，则服务器不抓取待审核工作流，若当前日期为非工作日，则服务器随机抓取待审核工作流。抓取到待审核工作流后，获取该待审核工作流对应的投保数据，根据投保数据的关键字段进行规则文件的筛选，以及通过关键字段确定规则文件的执行顺序，按照顺序加载规则文件对待审核工作流对应的投保数据进行审核。在本实施例中，通过预设工作日和非工作日期标识进行投保数据审核，利用非工作日进行投保审核数据工作，不在工作日占用资源进行审核工作，并且保证了在非工作日有足够的资源进行数据审核工作。

在一个实施例中，接收第一终端上传的投保数据之前包括：接收第一终端上传的规则文件，规则文件中携带文件标识；根据文件标识对规则文件进行分类打包，得到多个规则包。

规则文件是指用于加载执行审核投保数据的代码文件。在服务器正式接收投保数据进行审核之前，预先将业务人员编写的规则文件上传至服务器进行存储，等到服务器进行投保数据审核工作时，即可直接调用相应的规则文件。并且，当服务器接收到由业务人员通过第一终端上传的规则文件后，通过规则文件对应的文件标识对规则文件进行分类处理，并将相同类别的规则文件打包存储至一个规则包中，得到多个规则包。其中，文件标识在业务人员进行规则文件的编写时，根据业务类型的不同为规则文件添加不同的文件标识。用户进行投保时的投保信息一般包括用户所投保保单的通用类型、用户投保的渠道，用户投保的平台，以及用户所投保的保险产品等等。根据用户的投保信息可以确定业务人员需要编写的规则文件，即用于审核投保数据的规则文件一般包括用于审核保单通用类型的规则文件，审核投保渠道的规则文件，审核投保平台的规则文件以及审核投保产品的规则文件。因此，业务人员在编写用于审核保单类型的规则文件时，添加的文件标识为通用规则文件；编写用于审核投保渠道的规则文件时，添加的文件标识为渠道规则文件；编写用于审核投保平台的规则文件时，添加的文件标识为平台规则文件；以及编写用于审核投保产品的规则文件时，添加的文件标识为产品规则文件。

在一个实施例中，规则包包括：通用规则包，渠道规则包，平台规则包以及产品规则包。

服务器接收到由业务人员通过第一终端上传的规则文件后，根据规则文件携带的文件标识进行分类打包，得到的多个规则包，包括：通用规则包，渠道规则包，平台规则包以及产品规则包。例如，保单类型一般分为一类通用和二类通用，业务人员在编写一类通用规则和二类通用规则时则为该规则文件添加通用规则文件的文件标识，服务器根据该通用规则文件标识将一类通用规则和二类通用规则打包存储至通用规则包中。同样的，保单渠道分为网销和电销，业务人员在编写网销规则和电销规则时则为该规则文件添加渠道规则文件的文件标识，服务器根据该渠道规则文件标识将网销规则和电销规则打包存储至渠道规则包中。投保平台一般包括京东、陆金所、淘宝以及金管家，业务人员在编写京东平台规则、陆金所平台规则、淘宝平台规则以及金管家平台规则时则为上述规则文件添加平台规则文件的文件标识，服务器根据该平台规则文件标识将京东平台规则、陆金所平台规则、淘宝平台规则以及金管家平台规则打包存储至平台规则包中。

在本实施例中，传统通常都是将所有的规则文件存储至服务器中，服务器进行投保数据审核时需要将所有的规则文件加载一遍选择对应的规则文件进行审核。但是，本实施例根据不同的规则文件添加不同的文件标识，服务器再根据文件标识对规则文件进行分类。在服务器进行保单数据审核工作时，即可获取对应的规则包和规则文件，不需要加载所有的规则文件，提高审核工作的效率。应该理解的是，虽然图2、4和5的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2、4和5中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图6所示，提供了一种投保数据审核装置，包括：接收模块602、筛选模块604、确定模块606和审核模块608，其中：

接收模块602，用于接收第一终端上传的投保数据，投保数据携带有关键字段；

筛选模块604，用于利用关键字段对多个规则包进行筛选，并从所述规则包中筛选出与投保数据对应的规则文件。

确定模块606，用于根据关键字段确定筛选出的多个规则文件的执行顺序。

审核模块608，用于根据执行顺序加载筛选出的多个规则文件，根据加载后的规则文件对投保数据进行审核。

在一个实施例中，确定模块606还用于读取配置文件，配置文件中记录了关键字段对应的优先级别；根据关键字对应的优先级别确定与关键字段对应的规则文件的执行顺序。

在一个实施例中，投保数据审核装置还包括更新模块，用于接收第二终端上传的规则文件更新请求，更新请求中携带了关键字段以及更新后的规则文件；根据关键字段获取更新前的规则文件；根据更新后的规则文件覆盖所述更新前的规则文件。

在一个实施例中，接收模块602还用于判断投保数据量是否达到预设阈值；若是，获取多个投保数据的关键字段；根据关键字段对投保数据进行分类处理。

在一个实施例中，接收模块602还用于根据投保数据生成待审核工作流；获取当前日期和预存的日期表，日期表中携带多个日期标识；根据日期表获取当前日期相对应的日期标识；根据日期标识抓取待审核工作流。

在一个实施例中，接收模块602还用于接收第一终端上传的规则文件，规则文件携带文件标识；根据文件标识对规则文件进行分类打包，得到多个规则包。

关于投保数据审核装置的具体限定可以参见上文中对于投保数据审核方法的限定，在此不再赘述。上述投保数据审核装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图7所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储投保数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种投保数据审核方法。

本领域技术人员可以理解，图7中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：

接收第一终端上传的投保数据，投保数据携带有关键字段；

利用关键字段对多个规则包进行筛选，并从所述规则包中筛选出与投保数据对应的规则文件。

根据关键字段确定筛选出的多个规则文件的执行顺序。

根据执行顺序加载筛选出的多个规则文件，根据加载后的规则文件对投保数据进行审核。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：

读取配置文件，配置文件中记录了关键字段对应的优先级别；

根据关键字段对应的优先级别确定与关键字段对应的规则文件的执行顺序。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：

接收第二终端上传的规则文件更新请求，更新请求中携带了关键字段以及更新后的规则文件；

根据关键字段获取更新前的规则文件；

根据更新后的规则文件覆盖所述更新前的规则文件。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：

判断投保数据量是否达到预设阈值；

若是，获取多个投保数据的关键字段；根据关键字段对投保数据进行分类处理。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：

根据投保数据生成待审核工作流；获取当前日期和预存的日期表，日期表中携带多个日期标识；根据日期表获取当前日期相对应的日期标识；根据日期标识抓取待审核工作流。

在一个实施例中，处理器执行计算机程序时还实现以下步骤：

接收第一终端上传的规则文件，规则文件携带文件标识；

根据文件标识对规则文件进行分类打包，得到多个规则包。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

接收第一终端上传的投保数据，投保数据携带有关键字段；

利用关键字段对多个规则包进行筛选，并从规则包中筛选出与投保数据对应的规则文件。

根据关键字段确定筛选出的多个规则文件的执行顺序。

根据执行顺序加载筛选出的多个规则文件，根据加载后的规则文件对投保数据进行审核。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：

读取配置文件，配置文件中记录了关键字段对应的优先级别；

根据关键字段对应的优先级别确定与关键字段对应的规则文件的执行顺序。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：

接收第二终端上传的规则文件更新请求，更新请求中携带了关键字段以及更新后的规则文件；

根据关键字段获取更新前的规则文件；

根据更新后的规则文件覆盖所述更新前的规则文件。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：

判断投保数据量是否达到预设阈值；

若是，获取多个投保数据的关键字段；根据关键字段对投保数据进行分类处理。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：

根据投保数据生成待审核工作流；获取当前日期和预存的日期表，日期表中携带多个日期标识；根据日期表获取当前日期相对应的日期标识；根据日期标识抓取待审核工作流。

在一个实施例中，计算机程序被处理器执行时还实现以下步骤：

接收第一终端上传的规则文件，规则文件携带文件标识；

根据文件标识对规则文件进行分类打包，得到多个规则包。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。