CN108074069A - 保险的保全信息处理方法和装置 - Google Patents

Abstract

本发明涉及一种保险的保全信息处理方法，所述方法包括以下步骤：服务器获取数据库中存储的保全处理任务，所述保全处理任务中包括用户信息和保全项目；获取根据所述用户信息与所述保全项目确定的核保结果；当所述核保结果为核保通过时，根据所述用户信息和保全项目生成节点数据集合，每个节点数据中包含所述保全项目所需审批的审批项目和审批人员的员工标识；将所述节点数据集合发送至所述员工标识对应的审批终端，获取所述审批终端对所述保全项目进行审批所确定的审批结果；当所述审批结果为审批通过时，对所述保全项目进行保费结算。上述方法可提高保全信息的处理效率。此外，还对应提供了一种保险的保全信息处理装置。

Description

保险的保全信息处理方法和装置

技术领域

本发明涉及信息处理技术领域，特别是涉及一种保险的保全信息处理方法和装置。

背景技术

保险的保全通俗的理解就是对所办理的保险业务的相关信息进行变更。例如，变更受益人、追加保费等等。保险公司在处理客户发起的保全操作时，为了进行风险控制，需要对客户的信息进行层层审核。

传统的审核方式是在客户提交保全请求后，需要人工来审核确定所需的审批事项。比如首先由初级审核人员进行审核，并由初级审批人员人工判断是否超出自己审批权限来决定是否提交上级审批，直至审批结束。并且由于目前办理保险业务的客户人数众多，传统的人工处理的方法，处理效率低下。

发明内容

基于此，有必要针对上述技术问题，提供一种能够提高保全信息处理效率的保险的保全信息处理方法。

一种保险的保全信息处理方法，所述方法包括以下步骤：

服务器获取数据库中存储的保全处理任务，所述保全处理任务中包括用户信息和保全项目；

获取根据所述用户信息与所述保全项目确定的核保结果；

当所述核保结果为核保通过时，根据所述用户信息和保全项目生成节点数据集合，每个节点数据中包含所述保全项目所需审批的审批项目和审批人员的员工标识；

将所述节点数据集合发送至所述员工标识对应的审批终端，获取所述审批终端对所述保全项目进行审批所确定的审批结果；

当所述审批结果为审批通过时，对所述保全项目进行保费结算。

一种保险的保全信息处理装置，所述装置包括：

保全任务获取模块，用于获取数据库中存储的保全处理任务，所述保全处理任务中包括用户信息和保全项目；

核保模块，用于获取根据所述用户信息与所述保全项目确定的核保结果；

审批模块，用于当所述核保结果为核保通过时，根据所述用户信息和保全项目生成节点数据集合，每个节点数据中包含所述保全项目所需审批的审批项目和审批人员的员工标识；将所述节点数据集合发送至所述员工标识对应的审批终端，获取所述审批终端对所述保全项目进行审批所确定的审批结果；

保费结算模块，用于当所述审批结果为审批通过时，对所述保全项目进行保费结算。

上述保险的保全信息处理方法和装置，通过获取数据库中存储的保全处理任务，保全处理任务中包括用户信息和保全项目；然后获取根据用户信息与保全项目确定的核保结果；当核保结果为核保通过时，根据用户信息和保全项目生成节点数据集合，每个节点数据中包含保全项目所需审批的审批项目和审批人员的员工标识；再将节点数据集合发送至员工标识对应的审批终端，获取审批终端对保全项目进行审批所确定的审批结果；当审批结果为审批通过时，对保全项目进行保费结算。通过设置核保与节点数据集合，使得可实现对保全处理任务的自动化处理，减少了传统方案中所需的人工参与，提高了保全信息的处理效率。。

附图说明

图1为一个实施例中保险的保全信息处理方法的应用环境图；

图2为一个实施例中服务器的结构框图；

图3为一个实施例中保险的保全信息处理方法的流程图；

图4为一个实施例中根据保全项目生成对应的节点数据集合的步骤的流程图；

图5为一个实施例中对保全项目进行保费计算的步骤的流程图；

图6为一个实施例中保险的保全信息处理方法的质检的过程的流程图；

图7为一个实施例中保险的保全信息处理装置的结构框图；

图8为一个实施例中审批模块的结构框图；

图9为另一个实施例中保险的保全信息处理装置的结构框图。

具体实施方式

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

本发明实施例所提供的保险的保全信息处理方法，可应用于如图1所示的应用环境中。参考图1，用户终端110与员工终端130均通过相应的网络与服务器120相连。用户终端110可通过访问保险公司的相关网站或相关的应用软件与服务器120通信来办理保险业务或查询相关保险信息，比如，可办理保全业务。服务器120可为保险公司的服务器，该服务器120中可获取用户终端120所提交的保全处理任务，并获取与保全项目相关的用户信息，根据该用户信息与保全项目确定对应的保全处理流程，保全处理流程包括该保全任务需要依次经过的审核事项，将审核事项发送至对应的员工终端130。审核事项依次包括质检、核保、审批、收付汇总、保全确认中的一种或多种，每个员工终端130可对应审核其中的一种或多种事项，并将审核结果反馈为服务器120。服务器120可接收员工终端130的审核结果，使用户终端110可获知该审核结果，实现了对保险的保全信息处理。

在一个实施例中，服务器120包括保全项目收集服务器121和保全项目处理服务器122，保全项目收集服务器121用于接收用户终端110上报的保全请求，根据该保全请求生成保全处理任务，该保全请求中包括相应的保全项目，并存储至其内预设的数据库中。保全项目处理服务器122用于从保全项目收集服务器121获取保全处理任务；并与员工终端130进行交互，完成对该保全项目的审核。

图2为一个实施例中服务器的内部结构示意图。该服务器包括通过系统总线连接的处理器、非易失性存储介质、内存储器和网络接口。其中，该服务器的非易失性存储介质存储有操作系统、数据库和保险的保全信息处理装置。数据库中存储有相关信息以及各种保险的数据，比如存储保险用户的个人数据和保单数据等，还存储有各种保险的保全操作规则和审批程序和受理条件等数据。该保险的保全信息处理装置用于实现一种保险的保全信息处理方法。该服务器的处理器用于提供计算和控制能力，支撑整个服务器的运行。该服务器的内存储器为非易失性存储介质中的保险的保全信息处理装置的运行提供环境，该内存储器中可存储有计算机可读指令，该计算机指令可读指令被处理器执行时，可使得处理器执行一种保险的保全信息处理方法。该服务器的网络接口用于据以与外部的用户终端以及审核终端通过网络连接通信，比如接收用户终端上报的保全请求，接收审核终端发送的审核结果等。服务器可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

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

在一个实施例中，如图3所示，提供了一种保险的保全信息处理方法，该方法包括以下步骤：

步骤302，服务器获取数据库中存储的保全处理任务。

本实施例中，数据库中存储有多个待处理的保全处理任务，保全处理任务中包括用户信息和保全项目。用户信息包括用户的姓名、年龄、职务、联系方式、银行账号和历史保单信息等。该银行账号可包括多个，服务器可存储用户的每个银行账号在进行办理保险收退费的使用情况。保全项目即为用户所提交的保全请求信息，包括被保人的变更和被保人保费的变更等信息。比如，被保人的增加和删除、被保人保费的增加数额和减少数额。

进一步的，服务器可根据预设处理时间获取数据库中存储的保全处理任务。

数据库中可以以保全任务数据表的形式存储该保全处理任务。保全任务数据表中所存储的保全处理任务为保全项目收集服务器根据所接收到的用户终端发送的保全项目所生成的保全处理任务。

本实施例中，服务器可包括保全项目收集服务器和保全项目处理服务器。保全用户的用户终端可通过预设接口与保全项目收集服务器相连接，并向其发送对应的保全项目。保全项目收集服务器根据所接收到的保全项目与该保全用户的用户标识，生成相应的保全处理任务，将该保全处理任务存储到预先建立的保全任务数据表中。该保全任务数据表用于存储在未处理完毕的所有保全用户提交的保全处理任务。

保全项目处理服务器与该保全项目收集服务器建立了连接，并根据预设处理时间定期从该保全任务数据表中获取相应数量的保全处理任务。针对所获取的每个保全处理任务，进行相应的保全信息处理。可实现对保全处理任务的并行处理，提高保全信息处理的整理效率。

步骤304，获取根据用户信息与保全项目确定的核保结果。

本实施例中，核保是保全项目审核中的一个步骤，用于决定是否接受相应的保全风险。保全项目的核保包括对保全项目中所涉及的投保人资格的审核，是否具有保险利益；保险标的审核；保险金额审核；保险费率的审核和确定；投保人或被保险人的信誉审核等其中的一种或多种。服务器可根据数据库中所存储的核保规则信息，自动地对该保进行核保，并确定相应的核保结果。核保结果包括核保通过与核保不通过，若核保通过，则进行后续事项的审核，若核保不通过，则可向对应的用户终端发送保全请求不通过的信息，该保全处理任务处理结束。

进一步的，服务器还可将该保全项目与用户信息发送至核保人员的核保终端，并接收由核保终端对该保全项目进行审核所确定的核保结果。

步骤306，当核保结果为核保通过时，根据用户信息和保全项目生成节点数据集合。

本实施例中，节点数据集合包括多个节点数据，每个节点数据中包含保全项目所需审批的审批项目和审批人员的员工标识。不同的保全项目对应的审批项目不一定相同。审批项目包括财务审批项目、法务审批项目和总部审批项目。服务器中预先存储了不同保全项目与各个审批项目的对应关系，根据该对应关系可确定用户的保全项目所需的审批项目。每个审批项目均对应设置了一个或多个审批人员，服务器预先将每个审批人员的员工标识与相应的审批项目之间建立了关联关系。当确定了具体的审批项目后，可根据每个所需审批项目与其对应员工标识的关联信息确定该审批人员，当该关联的审批人员具有多个时，则从所关联到的多个审批人员中选取一个。

步骤308，将节点数据集合发送至员工标识对应的审批终端，获取审批终端对保全项目进行审批所确定的审批结果。

本实施例中，审批终端可按照预设的审批规则对被分配审批项目进行审批，得出相应审批项目的审批结果，并将该审批结果发送给服务器。当节点数据集合中的所有审批项目均审批通过时，则审批结果为审批通过，对保全项目进行保费结算。

若其中一个审批项目的审批结果为不通过，则判断该保全项目审核不通过。

步骤310，当审批结果为审批通过时，对保全项目进行保费结算。

本实施例中，保费结算包括退费计算和缴费结算。若该保全项目需退费，则将相应的退费数额转入用户预先设置的转账账户中。若需收费，则获取该用户的缴纳数额，将该缴纳数额转入预设的保险公司账户中。

本实施例中，服务器通过获取数据库中存储的保全处理任务，保全处理任务中包括用户信息和保全项目；然后获取根据用户信息与保全项目确定的核保结果；当核保结果为核保通过时，根据用户信息和保全项目生成节点数据集合，每个节点数据中包含保全项目所需审批的审批项目和审批人员的员工标识；再将节点数据集合发送至员工标识对应的审批终端，获取审批终端对保全项目进行审批所确定的审批结果；当审批结果为审批通过时，对保全项目进行保费结算。通过设置核保与节点数据集合，使得可实现对保全处理任务的自动化处理，减少了传统方案中所需的人工参与，提高了保全信息的处理效率。

在一个实施例中，用户信息中包括核保数值。保全项目包括涉费数额。

核保数值为根据用户信息中的核保因子所计算出的分值。该核保因子可从用户信息中获取和确定。核保因子包括累计保额、累计保费、累计赔付数额、职业类别风险系数、投保年龄赔付风险系数、高保额临分值等其中的多个。核保数值的计算过程可在步骤302之前即计算完成，并在获取高保全处理任务后，直接获取用户的核保数值。也可在步骤302之后，即开始计算并获取用户的核保数值。涉费数额包括应收费数额和应退费数额。

核保数值与高保额临分比、赔付率、职业类别风险系数以及投保年龄赔付风险系数成一定的比例。其中，高保额临分比为记累计保额与高保额临分值之比；赔付率为累计保额与累计赔付数额之比。进一步的，可成正比关系，即若高保额临分比、赔付率、职业类别风险系数以及投保年龄赔付风险系数越小，则对应的核保数值也越小，说明该保全项目的风险也越小。

具体的，可根据公式来计算出具体的核保数值。其中，b为累计保额为，g为高保额临分值，f为累计保费，p为累计赔付，z为职业类别风险系数，z为投保年龄赔付风险系数，b/g为高保额临分比，p/f为赔付率。q₁～q₄分别为对应的权值系数。

服务器中预设了每个职业类别对应的风险系数，以及每个年龄对应的赔付风险系数，使得可根据用户的职业以及年龄确定相应的职业类别风险系数与投保年龄赔付风险系数。

本实施例中，步骤304具体包括：当涉费数额小于预设数额，且服务器判断核保数值小于预设的核保阈值时，直接判定核保结果为核保通过；否则，查询与涉费数额相匹配的核保人员，并将保全项目发送至该核保人员的核保终端进行审核，以得到核保结果。

预设的核保阈值为服务器预先设置的用于自动判断保全项目是否通过的阈值。预设数额为预设的适用于自动核保判断的临界阈值，比如可设置为10000元人民币。预设数额可根据历史保全项目中的涉费数额来确定，将该预设数额设置为大于该所有涉费数额的一定比例的数额。比如将该预设数额设置为超过该在最近一年内的保全项目的涉费数额的80％的数额，使得服务器可对后续约80％的保全处理任务进行自动核保。

服务器可比较涉费数额与预设数额的大小，当小于该预设数额时，则获取相应的核保数值，判断该核保数值是否小于预设的核保阈值。若是，则判断审核通过。

进一步的，服务器中还设置了不同涉费数额与核保人员的员工标识之间的对应关系，使得根据该对应关系可查询出相应的核保人员。具体的，可对涉费数额设置相应数量的数额等级，每个等级对应相应的涉费数额区间。同时还对核保人员设置了相同数量的核保等级，每个数额等级与相应的核保等级相对应。同一核保等级包括多个核保人员。每个核保员工被分配了一定数量的核保任务，该核保任务即为审核保全处理任务中的保全项目是否核保通过。通过核保员工的员工标识可获取相应的核保任务以及核保任务数量。核保任务数量为核保员工为完成处理的核保任务的数量。

举例来说，如下表1所示，为一个实施例中的涉费数额与核保账号级别之间的对应关系表。

表1涉费数额与核保账号级别之间的对应关系表

涉费数额(单位：人民币)	核保员工级别
		10000以上	第一级别核保员工
10000～100000	第二级别核保员工
		100000～5000000	第三级别核保员工
500000以上	第四级别核保员工

当该涉费数额不小于预设数额，或核保数值不小于预设的核保阈值时，则可确定涉费数额所属的数额等级，并查找出与该数额等级对应的级别的核保员工的员工标识，以及核保员工的核保任务数量，将该保全项目发送至核保任务数量最少的核保人员的核保终端进行审核。并更新该核保人员的核保任务及和好任务数量。接收核保终端发送的核保结果。

本实施例中，由于用户信息中还包括核保数值，通过预先设置预设数额与核保阈值，当保全项目包含的涉费数额小于预设数额时，可使服务器对该保全项目进行自动核保，当涉费数额不小于预设数额，或核保数值不小于预设的核保阈值时，则将该保全项目分配给与涉费数额相匹配的其中一个核保人员进行审核，可满足一定的保证核保的风险控制要求上，提高了核保效率。

在一个实施例中，如图4所示，上述的根据用户信息和保全项目生成节点数据集合的步骤，包括：

步骤402，从用户信息中提取与保全项目对应的审批因子。

审批因子为用于确定该保全项目所需的审批流程的考虑因素。该审批因子可从用户信息中提取。具体的，审批因子包括该保全项目对应的涉费数额、用户的涉费频率和支付账号的安全等级等其中的一种或多种。优选的，包括该保全项目对应的涉费数额、用户的涉费频率和支付账号的安全等级这三种。

其中，服务器中预先存储了不同类型的保全项目与审批因子的对应关系。在接收到保全项目后，根据可判断出该保全项目的类型，并根据预先建立的该类型的保全项目与审批因子之间的对应关系来确定所需的审批因子。保全项目的类型可包括保全涉费类型的项目和保全增加保费的项目等。比如，可预先建立保全涉费类型的项目与涉费数额、用户的涉费频率和支付账号的安全等级这三种具体的审批因子之间的对应关系。

对于保全涉费类型的项目，服务器可根据所接收到的保全项目，从该保全项目中获取或计算出对应的涉费数额。涉费频率可根据用户在预设时间段内的涉费次数来确定。优选的，预设时间段可为用户最近3个月或1年等时间段。支付账号是指本次保全项目所留存的用户接收保全涉费的账号。用户所留存的用于办理保险转账等业务的账号可具有多个。服务器可根据用户标识将用户所办理的所有保险以及所留存的所有账号进行关联。并为每个账号设置对应的安全等级。比如可设置安全账号、低风险账号、中风险账号和高风险账号，不同的安全等级表示用户使用银行账号办理退保请求时所对应的风险大小。服务器在每次检测到用户的账号的交易记录后，可根据该交易记录对应更新其安全等级。

步骤404，根据审批因子计算审核保全项目所需的审批分支、每个审批分支中所需的审批项目以及对应的审批顺序。

本实施例中，每个审批分支中均设有若干个审批项目，不同的保全项目所需的审批分支以及审批分支中的审批项目不一定相同。审批分支包括财务分支、法务分支和总部分支等其中的一种或多种，优选的，审批分支包括财务分支、法务分支和总部分支三种，对应的审批项目即为财务审批项目、法务审批项目和总部审批项目。其中财务分支为审核该保全项目所必要的审批分支，服务器可根据审批因子对应确定财务分支中的具体所需财务审批项目。法务分支用于审核该保全项目是否符合法律法规以及风险大小等，总部分支用于对该保全项目进行综合审核。是否需要法务分支和中部分支可由与该保全项目对应的审批因子来确定。

服务器中预先存储了不同审批因子与审批分支及其对应的审批项目的对应关系，根据该对应关系可确定用户的保全项目所需的审批分支以及每个审批分支中所需的审批项目。

在一个实施例中，可根据该对应关系来确定该保全项目中的具体退费数额、用户退费频率以及支付账号的安全等级所需的审批分支及其审批项目。具体的，可检测该支付账号的安全等级是否超过预设的等级阈值，若是，则确定需要法务分支，并根据该支付账号的安全等级确定所需的法务审批项目；检测该退费频率是否超过预设的频率阈值，若是，则确定需要法务分支，并根据该退费频率确定所需的法务审批项目；检测该退费数额是否超过预设的数额阈值，若是，则确定需要总部分支，并根据该退费数额确定所需的总部审批项目。

下面对根据审批因子计算所需的审批分支进行举例说明，如下表2所示，为根据退费数额与所需的审批分支的关系表。

表2退费数额与所需的审批分支的关系表

退费数额x所属区间	所需的审批分支
		0≤x＜100000	财务分支
100000≤x＜500000	财务分支、法务分支
		x≥500000	财务分支、法务分支、总部分支

本实施例中，服务器还预先设置了每个审批项目的审批顺序，根据该审批项目的审批顺序来对应确定审批项目的审批顺序。

具体的，包括：获取审批项目的审批优先级；根据审批优先级确定每个审批项目的审批顺序。

本实施例中，服务器可设置每个审批项目的审批优先级，该优先级可以是确定不变的，也可以是根据保全项目的具体审批因子来确定。当优先级为确定不变时，可直接获取保全项目所需的审批项目的优先级。当优先级与审批因子相关联时，可根据该保全项目的具体审批因子按照该关联信息对应计算得出。

在确定了所需的审批项目的优先级后，可对该优先级按照由小至大的顺序对应确定所需的审批项目的审批顺序，也可对该优先级按照由大至小的顺序对应确定所需的审批项目的审批顺序。

在一个实施例中，审批项目的审批优先级的计算公式为：

其中，n为满足审批条件的因子数，a_i为与审批项目所对应的第i个审批因子的第一权值，b_i为具体退费数额与审批项目对应的第二权值，g为与审批项目对应的项目系数。

进一步的，设置不同审批因子与每个审批项目所对应的第一权值，服务器可设置不同退费数额区间与每个审批项目所对应的第二权值，并设置每个审批项目对应的项目系数。

当确定了所需的审批项目后，则可对应获取所需审批项目的a_i、b_i和g，再根据上述计算公式对应计算出所需的审批项目的优先级。

举例来说，审批因子为保全项目对应的退费数额、对应用户的退费频率和支付账号的安全等级。确定所需的审批项目为审批项目A、审批项目B和审批项目C。服务器可预先建立如下表3。

表3部分审批项目与审批因子之间的关系表

当退费数额为200000时，可对应计算出审批项目A、审批项目B以及审批项目C所对应的优先级分别为0.3、0.343、0.443。

在根据上述计算公式计算出所有所需的审批项目的优先级后，对该优先级按照由小至大的顺序对应确定所需的审批项目的审批顺序。比如，可确定上述的审批项目A、审批项目B以及审批项目C的审批顺序分别为审批项目A、审批项目B以及审批项目C。

步骤406，根据审批项目确定对应的审批人员。

步骤408，基于审批项目、审批顺序和审批人员，生成节点数据集合。

在确定了该保全项目具体的审批分支及其对应的审批项目和审批人员后，则可根据该具体的审批分支及其对应的审批项目和审批人员的员工标识生成节点数据集合。节点数据集合中还包括各个节点数据的审批顺序。

本实施例中，通过根据用户标识获取与保全项目对应的审批因子，进而根据该审批因子确定审核保全项目所需的审批分支及其审批项目和审批人员，最后生成节点数据集合，使得可通过该节点数据集合即可对应获知该保全项目所需的具体审核信息与审核进度。从而可提高保全处理任务的审核效率。

在一个实施例中，步骤406包括：获取与审批项目相关联的多个审批人员；获取每个审批人员未完成审批的审批项目的数量；将审批项目分配给数量最少的审批人员。

本实施例中，每个审批项目设置有审核状态标记，根据该审核状态标记可对应获知该审批项目的审批状态。该审批状态包括审核完成和审核未完成两大状态。审核未完成可包括待审核、审核中等，审核完成包括审核通过和审核不通过等。

服务器通过检测每个审批人员中所分配审批项目的审核状态标记，并实时统计该审核状态标记中表示审核未完成的数量，通过该数量即可获知每个审批人员未完成审批的数量。

具体的，服务器可实时更新每个审批人员所分配的审核状态为待审核以及审核中等表示审核未完成的审核项目的数量。将审批项目分配给审核未完成的审核项目的数量审批数量的审批人员。若存在具有多个数量最少的审批人员，则可在该多个数量最少的审批人员中随机确定一个。

本实施例中，通过设置审批项目的审批状态，将新的审批项目分配给审批数量最少的审批人员审核，使得可进一步提高审批效率。

步骤410，获取节点数据集合中的审核进度。

本实施例中，审核进度为保全项目的审核进度，包括审核未结束和审核结束。当该保全项目中的某一审批项目(即当前审批项目)正处在审核中时，则该审核未结束；若该节点数据集合中的某一审批项目的审核完成，且结果为不通过时，则审核结束，且该节点数据集合对应的保全项目为审核不通过；若该节点数据集合中的所有审批项目均审核完成且通过时，则审核结束，且该节点数据集合对应的保全项目为审核通过。节点数据集合中可同步每个审批人员对与其对应的审批项目的审核状态的修改，根据该修改进行更新。服务器通过检测节点数据集合中的对应审批项目的审核状态的更新信息，从而获知该节点数据集合对应的保全项目的审核进度。

在一个实施例中，服务器可通过预设的接口与签报系统同步对接，将节点数据集合上传到签报系统。该签报系统用于管理保全项目的审核事项。审批人员可通过在签报系统上登录对应的审批账号，并对为其所分配的审批项目进行审核，签报系统实时检测并获取每个审批人员对审批项目的审核结果，根据审核结果对应更新节点数据集合中的审核进度，将审核进度的更新信息发送给服务器。

本实施例中，通过在签报系统中进行实时监控保全项目的审核进度，可进一步提高对保全请求的审核效率。

步骤412，当审核进度为审核未结束时，根据审核进度确定当前的审批人员，向当前的审批人员的审批终端发送审核保全项目中的与当前审批人员对应的审核项目的信息。

进一步的，节点数据集合的每次更新信息中均携带时间戳，使得可通过比较每次更新的时间戳即可获知最新的更新信息，同时还可根据该时间戳可获知相应审批项目的审核状态更改时间，即审批人对对应的审批项目的审核完成时间。

服务器通过获取节点数据集合的更新信息，根据该更新信息可识别该保全项目的审核进度。即识别对应的保全项目是否已完成审核。当识别为未完成审核时，则获取节点数据集合中最新时间戳所对应的更新信息，根据该更新信息确定当前的审批人员。

具体的，识别该更新信息中的审批项目的审批结果，若审批结果为审批通过，则根据所确定的审批顺序获取位于该更新信息中的审批项目的下一审批项目，该下一审批项目即为当前审批项目。再获取该下一审批项目对应的审批人员的审批终端，并向其发送审核保全项目中的当前审批项目的信息。

在一个实施例中，上述的根据保全项目生成对应的节点数据集合的步骤还可不包括步骤410和412。

在一个实施例中，在步骤412之后，还包括：获取当前审批项目的审批期限；向当前审批项目对应的审批人员的审批终端发送时限提醒信息。

本实施例中，服务器还预设了每个审批项目所允许的审批期限，当服务器向当前审批人员的审批终端发送了审核当前审批项目的信息的同时，还记录所发送的时间，并根据该时间以及审批期限对应计算出当前审批项目的截止时间，将包含该截止时间的时限提醒信息发送给当前审批人员的审批终端。

具体的，当当前时间到达时限提醒的时间时，若当前审批项目未审核完成，则向当前审批项目对应的审批人员的审批终端发送时限提醒信息。

服务器还可预设与审批期限对应的提醒期限，该时限提醒用于确定向审批人员的审批终端发送对审批项目的时限提醒的时间，可以理解的，提醒期限不大于对应的审批期限。服务器通过检测是否在该时限提醒的时间之前获取到当前审批项目的审核完成的信息，若是，则不向当前审批项目对应的审批人员的审批终端发送时限提醒信息；若否，则在到达该时限提醒的时间时，向当前审批项目对应的审批人员的审批终端发送时限提醒信息。

审批结束包括对保全项目的审核通过和审核不通过的审核结果。比如，若审核通过，则向对应的支付账号转入相应的退费数额；若审核不通过，则可向对应的保险用户发送审核不通过的原因等信息。

本实施例中，通过节点数据集合获取对应保全项目的审核进度，根据该审核进度向当前审批人员的审批终端发送对当前保全项目的审核的信息，使得对保险审核进一步规范化，提高了保险审核的处理效率。

在一个实施例中，用户信息中包括用户在当前结算周期中的轧差数额和结算阈值。对保全项目进行保费结算的步骤，包括：当轧差数额不大于结算阈值时，对保全项目进行保费结算。

本实施例中，结算周期为服务器为用户所确定的周期。比如，可设置结算周期为一个月、一个季度或一年等任意时长。进一步的，该结算周期可适用于用户名下的所有团体保单。

服务器在每次接收到用户的保全请求后，则对应确定并记录该保全项目所产生的相应的待缴费的数额和待退费的数额，并累计当前结算周期下每次保全请求所对应的待缴费的数额和待退费的数额，以计算出用户在当前结算周期中的轧差数额。其中，轧差数额为用户向保险公司所需支付的数额以及保险公司所需向用户退还的数额之间进行互相抵减后，若最终为用户需要向保险公司进行缴纳保费时，用户所需缴纳的具体数额。

服务器在统计出当前周期下的轧差数额后，确定该周期的结算日和结算宽限天数，将该轧差数额及其明细信息、结算日和结算宽限天数发送给对应的保险用户。

举例来说，如下表4所示，在接收到用户的保全请求(即表4中的当前保全请求)后，则根据该保全请求中所携带的保全项目计算出用户在当前保全请求中所产生的用户待缴费的数额和保险公司待退费的数额，并获取当前周期下的历史保全请求(即表4中的前1～4次保全请求)所产生的用户待缴费的数额和保险公司待退费的数额。并对应计算出用户在当前结算周期中的轧差数额为19200元。

表4当前周期下的保全请求所产生的交易数额表

服务器在统计出当前周期下的轧差数额后，确定该周期的结算日和结算宽限天数，将该轧差数额及其明细信息、结算日和结算宽限天数发送给对应的保险用户。

服务器还为不同用户设置了对应不同的结算阈值，该结算阈值为用于判断是否可继续允许用户提交新的保全请求的临界数值。

具体的，该结算阈值可由包括用户的信用值和对应保单的保费阈值确定，其中，保费阈值可为任意数值，优选的，可为用户在初期办理该团体险时所交保费的数额。信用值m又由评估因子确定，评估因子包括结算及时率v、提前结算天数a、逾期结算天数b、结算宽限天数c以及当前有效保单数n。

其中，v为由服务器所统计到的用户历次的结算的时间或者为在预设时间段中的结算的时间是否超期的以及未超期次数比例而得到的，且该结算可不局限于某一个保单。预设时间段可为最近3年等任意设置的时间段。举例来说，服务器统计到用户在预设时间段内发生了50次结算，其中有3次结算超期，47次未超期，则可计算出v＝94％。当服务器每检测到用户完成一次结算行为，则对应更新该结算及时率v。可以理解的，v为服务器所更新的最新的结算及时率。

进一步的，信用值m与结算及时率v成正比关系，当v越大，则对应的m值也越大。

更进一步的，信用值m可有下述公式来确定：

可以理解的，当用户在不考虑宽限期的结算日之前进行结算时，a为距离该结算日的剩下天数，b为0，c为用户可享受的宽限时长；当用户在结算宽限期内才进行结算时，则a为0，b为0，c为剩下的宽限天数；当用户超过结算宽限期后才进行结算时，则a为0，c为0，b为对应的超过天数。

在一个实施例中，结算宽限天数c又可与信用值m关联，m越大，则c也越大，对应的，当每更新用户的信用值m之后，则对应可根据c与m之间的关系来更新c的值，同样的，c为服务器所更新的最新的结算宽限天数。

在另一个实施例中，服务器可预先设置不同信用值范围对应的信用等级，并设置不同等级对应的结算比例，结算阈值即为结算比例与保费阈值的乘积。可以理解的，信用值越大，则用户的信用等级越高，对应的结算比例也越大。结算比例可为大于0的任意数值。

本实施例中，服务器可比较轧差数额与结算阈值的大小，判断轧差数额是否大于结算阈值。若是，则向用户提醒当前欠费数额较大，无法完成保全操作的提示信息。若否，则对保全项目进行保全操作。

具体的，当轧差数额不大于结算阈值时，服务器可根据该保全请求执行与其所携带的保全项目对应的保全操作。比如，该保全请求中包括新增被保人，保全项目中包括该新增被保人的基本信息、保费和保额等。服务器则为该被保人分配对应的分单号，将该被保人的基本信息、保费和保额添加到保单中。并计算出本次保全请求更新用户在当前结算周期中的轧差数额。

本实施例所提供的保费结算方法，通过获取与用户对应的结算阈值；并根据保全项目确定用户在当前结算周期中的轧差数额；当轧差数额不大于结算阈值时，对保全项目进行保全操作。从而避免了用户在每次提交保全请求都需要进行保费的结算，提高了用户的使用体验。且由于服务器也无需在每次受理保全请求时都进行调用银行接口与用户进行保费的结算，从而可减少对资源的占用，降低保险公司运营成本。

在一个实施例中，上述的对保全项目进行保费结算的步骤，还包括：检测该保全项目所对应的保单是否存在暂停标记，若不存在，则对保全项目进行保费结算。

本实施例中，服务器还对该用户设置了结算时间。结算时间为用户的保单在当前周期下考虑到了宽限期的最迟结算时间。超过结算时间时，服务器可对未及时结算的保单设置暂停标记，该暂停标记用于暂停用户的保全请求，以提醒用户及时完成保费的结算。

撤销暂停标记后，则用户的保全请求不受影响。进一步的，还根据该结算操作更新用户的结算及时率，以及对应的信用值和结算宽限天数。

本实施例中，通过对超过结算时间的保单设置暂停标记，可提醒用户及时进行保费结算，降低保费结算的风险。

在一个实施例中，上述的对保全项目进行保费结算的步骤，还包括：当轧差数额大于结算阈值时，对保单设置暂停标记，使得不允许发起新的保全请求；当轧差数额不大于结算阈值时，撤销暂停标记。

本实施例中，用户可通过对当前结算周期中的部分或全部的未结算的保全项目进行结算，服务器根据用户的结算更新轧差数额，当更新后的轧差数额不大于结算阈值时，则撤销暂停标记。并根据该结算操作更新用户的结算及时率，以及对应的信用值和结算宽限天数。

本实施例中，通过对轧差数额超过结算阈值的保单也设置暂停标记，可提醒用户及时进行保费结算，也进一步降低了保费结算的风险。

在一个实施例中，如图5所示，上述的对保全项目进行保费结算的步骤，包括：

步骤502，当轧差数额不大于结算阈值时，接收用户终端发送的预结算请求。

预结算请求为用户准备进行部分或全部保费的结算的请求，该保费可由一个或多个明细保费所构成。服务器可根据保全项目记录对应的明细保费。每个明细保费均对应用户的某一保单中的一个被保人的保费变更信息，该被保人包括被保人的增加的被保人和删除的被保人，保费变更信息包括保费的增加数额和减少数额，增加数额为用户需向对应保险公司缴纳的数额，减少数额为保险公司需向用户退还的数额。

具体的，终端上可提供结算界面，用户可在该结算界面中直接输入预结算数额，将包含该预结算数额的预结算请求发送给服务器。终端还可在结算界面中进一步提供保单选择和保单下的明细保费选择子界面，用户可在明细保费选择子界面中选择准备结算的具体明细保费，根据该明细保费选择结果生成对应的预结算数额，将所包含的明细保费和预结算数额发送给服务器。具体的，终端可为每个明细保费提供一个勾选框，通过接收用户对每个明细保费的勾选框的选中和不选中来对应确定所选择的具体明细保费。

进一步的，该预结算请求不局限于用户的单个保险，当存在多个保险时，可对该多个保险同时进行一次预结算请求。

步骤504，检测预结算请求中是否包含明细保费，若否，则执行步骤506，否则，执行步骤508。

步骤506，根据预设的结算明细匹配规则自动计算明细保费。

本实施例中，结算明细匹配规则可为按照明细保费的生成时间的先后顺序进行匹配，也可为按照明细保费的数额由大到小的顺序进行匹配，还可为按照保单生成时间的先后顺序进行匹配等规则，直至所确定的明细保费所对应的总数额与该结算金额相等。若所选取的明细保费的总数额与结算金额不相等，则将所选取的最后一个明细保费拆分成两个子明细保费，使得其中一个子明细保费与之前所选取的明细保费的总数额与结算金额相等。

步骤508，根据预设的结算明细匹配规则自动确定明细保费，根据自动确定明细保费计算结算数额。

步骤510，进行结算数额的结算。

本实施例中，通过根据预结算请求来对应确定明细保费，可简化用户的保费结算操作，提高保费结算效率。

在一个实施例中，如图6所示，上述的保险的保全信息处理方法还包括质检的过程，该质检的过程可在步骤304之前执行，具体包括以下步骤：

步骤602，检测保全项目中是否携带质检标记，若是，则执行步骤604，否则，执行步骤606。

本实施例中，服务器可预先对数据库中的部分保全处理任务的保全项目设置质检标记。设置了质检标记的保全项目则需要进行质检。质检是指检查所录入的用户信息是否存在录入错误。

具体的，服务器可根据预先设置的质检比例对数据库中的部分保全处理任务的保全项目设置质检标记。质检比例是指服务器中所获取到的所有的保全处理任务可能被进行质检的比例。

进一步的，该质检比例可与涉费数额区间相对应，根据该涉费数额所属的涉费数额区间，获取与该区间对应的质检比例。涉费数额区间越大，则对应的质检比例越高。

本实施例中，服务器中预先接收了大量的保全处理任务。服务器可根据保全处理任务中的保全项目的涉费数额，统计每个涉费数额所属的涉费数额区间的保全处理任务数量，并根据该涉费数额区间对应的质检比例计算出在该涉费数额区间内的保全处理任务所需的质检数量，并对相应数量的保全项目设置质检标记。

并从涉费数额区间内的保全处理任务中选取对应所需的质检数量的保全处理任务，对其保全项目进行质检。

步骤604，向质检终端发送对用户信息进行质检的消息，接收质检终端对该用户信息进行质检所生成的质检结果。

当确定需要质检时，服务器可向对应的质检终端发送对该用户信息进行质检的消息，该消息中携带用户标识，使得质检终端根据该用户标识可获取到对应的用户信息，并进行质检。

具体的，可将所需进行质检的保全处理任务对应的用户信息发送至质检任务数量最少的一个质检终端，使其对所接收到的保全处理任务的用户信息进行质检，并向服务器反馈质检结果。其中，质检结果包括质检通过和质检不通过，当质检不通过时，则说明该用户信息存在录入错误，并对用户信息进行更正，并根据更正后的用户信息进行后续的核保检测。

步骤606，判断质检通过。

若不存在质检标记，则无需对该保全项目进行质检，并默认质检通过。

本实施例中，通过设置质检比例，通过质检比例确定保全处理任务是否需要进行质检。可实现在保证保全信息的处理效率的基础上，提高用户信息的准确性。

在一个实施例中，如图7所示，提供了一种保险的保全信息处理装置，该装置包括：

保全任务获取模块702，用于获取数据库中存储的保全处理任务，保全处理任务中包括用户信息和保全项目。

核保模块704，用于获取根据用户信息与保全项目确定的核保结果。

审批模块706，用于当核保结果为核保通过时，根据用户信息和保全项目生成节点数据集合，每个节点数据中包含保全项目所需审批的审批项目和审批人员的员工标识；将节点数据集合发送至员工标识对应的审批终端，获取审批终端对保全项目进行审批所确定的审批结果。

保费结算模块708，用于当审批结果为审批通过时，对保全项目进行保费结算。

在一个实施例中，用户信息中还包括核保数值；保全项目包括涉费数额。

核保模块704还用于当涉费数额小于预设数额，且服务器判断核保数值小于预设的核保阈值时，直接判定核保结果为核保通过；否则，查询与涉费数额相匹配的核保人员，并将保全项目发送至该核保人员的核保终端进行审核，以得到核保结果。

在一个实施例中，如图8所示，审批模块706还包括：

审批因子获取单元802，用于从用户信息中提取与保全项目对应的审批因子。

审批项目确定单元804，用于根据审批因子计算审核保全项目所需的审批分支、每个审批分支中所需的审批项目以及对应的审批顺序；根据审批项目确定对应的审批人员。

节点数据集合生成单元806，用于基于审批项目、审批顺序和审批人员，生成节点数据集合。

审核进度获取单元808，用于获取节点数据集合中的审核进度，当审核进度为审核未结束时，根据审核进度确定当前的审批人员，向当前的审批人员的审批终端发送审核保全项目中的与当前审批人员对应的审核项目的信息。

时限提醒单元810，用于获取当前审批项目的审批期限；向当前审批项目对应的审批人员的审批终端发送时限提醒信息。

在一个实施例中，上述的审批模块706可不包括审核进度获取单元808和/或时限提醒单元810。

在一个实施例中，用户信息中包括用户在当前结算周期中的轧差数额和结算阈值。

保费结算模块708还用于当轧差数额不大于结算阈值时，对保全项目进行保费结算。

在一个实施例中，保费结算模块708还用于检测该保全项目所对应的保单是否存在暂停标记，若不存在，则对保全项目进行保费结算

在一个实施例中，如图9所示，上述的保险的保全信息处理装置还包括：

质检模块703，用于根据涉费数额确定保全项目的质检比例；根据质检比例确定是否对保全项目进行质检。

在一个实施例中，保全任务获取模块702还用于根据预设处理时间从预设的保全任务数据表中获取所存储的保全处理任务，保全任务数据表中所存储的保全处理任务为保全项目收集服务器根据所接收到的用户终端发送的保全项目所生成的保全处理任务。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一非易失性计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)等。

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

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

Claims (10)

1.一种保险的保全信息处理方法，其特征在于，所述方法包括以下步骤：

服务器获取数据库中存储的保全处理任务，所述保全处理任务中包括用户信息和保全项目；

获取根据所述用户信息与所述保全项目确定的核保结果；

当所述核保结果为核保通过时，根据所述用户信息和保全项目生成节点数据集合，每个节点数据中包含所述保全项目所需审批的审批项目和审批人员的员工标识；

将所述节点数据集合发送至所述员工标识对应的审批终端，获取所述审批终端对所述保全项目进行审批所确定的审批结果；

当所述审批结果为审批通过时，对所述保全项目进行保费结算。

2.根据权利要求1所述的方法，其特征在于，所述用户信息包括核保数值；所述保全项目包括涉费数额；

获取根据所述用户信息与所述保全项目确定的核保结果的步骤，包括：

当所述涉费数额小于预设数额，且所述服务器判断所述核保数值小于预设的核保阈值时，直接判定所述核保结果为核保通过；

否则，查询与所述涉费数额相匹配的核保人员，并将所述保全项目发送至该核保人员的核保终端进行审核，以得到核保结果。

3.根据权利要求1所述的方法，其特征在于，所述根据所述用户信息和保全项目生成节点数据集合的步骤，包括：

从所述用户信息中提取与所述保全项目对应的审批因子；

根据所述审批因子计算审核所述保全项目所需的审批分支、每个审批分支中所需的审批项目以及对应的审批顺序；

根据所述审批项目确定对应的审批人员；

基于所述审批项目、审批顺序和审批人员，生成所述节点数据集合。

4.根据权利要求1所述的方法，其特征在于，所述用户信息中包括所述用户在当前结算周期中的轧差数额和结算阈值；

所述对所述保全项目进行保费结算的步骤，包括：

当所述轧差数额不大于所述结算阈值时，对所述保全项目进行保费结算。

5.根据权利要求1至4中任一项所述的方法，其特征在于，在所述根据所述用户信息与所述保全项目的涉费数额确定对应的核保结果的步骤之前，还包括：

检测所述保全项目中是否携带质检标记，若是，则向质检终端发送对所述用户信息进行质检的消息，并接收所述质检终端对所述用户信息进行质检所生成的质检结果，否则，判断质检通过。

6.一种保险的保全信息处理装置，其特征在于，所述装置包括：

保全任务获取模块，用于获取数据库中存储的保全处理任务，所述保全处理任务中包括用户信息和保全项目；

核保模块，用于获取根据所述用户信息与所述保全项目确定的核保结果；

审批模块，用于当所述核保结果为核保通过时，根据所述用户信息和保全项目生成节点数据集合，每个节点数据中包含所述保全项目所需审批的审批项目和审批人员的员工标识；将所述节点数据集合发送至所述员工标识对应的审批终端，获取所述审批终端对所述保全项目进行审批所确定的审批结果；

保费结算模块，用于当所述审批结果为审批通过时，对所述保全项目进行保费结算。

7.根据权利要求6所述的装置，其特征在于，所述用户信息包括核保数值；所述保全项目包括涉费数额；

所述核保模块还用于当所述涉费数额小于预设数额，且所述服务器判断所述核保数值小于预设的核保阈值时，直接判定所述核保结果为核保通过；否则，查询与所述涉费数额相匹配的核保人员，并将所述保全项目发送至该核保人员的核保终端进行审核，以得到核保结果。

8.根据权利要求6所述的装置，其特征在于，所述审批模块包括：

审批因子获取单元，用于从所述用户信息中提取与所述保全项目对应的审批因子；

审批项目确定单元，用于根据所述审批因子计算审核所述保全项目所需的审批分支、每个审批分支中所需的审批项目以及对应的审批顺序；根据所述审批项目确定对应的审批人员；

节点数据集合生成单元，用于基于所述审批项目、审批顺序和审批人员，生成节点数据集合。

9.根据权利要求6所述的装置，其特征在于，所述用户信息中包括所述用户在当前结算周期中的轧差数额和结算阈值；

所述保费结算模块还用于当所述轧差数额不大于所述结算阈值时，对所述保全项目进行保费结算。

10.根据权利要求6至9中任一项所述的装置，其特征在于，所述装置还包括：

质检模块，用于检测所述保全项目中是否携带质检标记，若是，则向质检终端发送对所述用户信息进行质检的消息，并接收所述质检终端对所述用户信息进行质检所生成的质检结果，否则，判断质检通过。