CN107527290A - 保险单据新增方法和装置 - Google Patents

Abstract

本发明涉及一种保险单据新增方法和装置，该方法包括：获取保险类型标识和投保人信息；获取险种标识，所述险种标识为与所述保险类型标识对应的险种标识；调用与获取的所述保险类型标识对应的业务系统的接口，使所述业务系统根据所述险种标识和所述投保人信息确定出与所述险种标识对应的所需要的保费；接收所述业务系统返回的与所述险种标识对应的所需要的保费，将所述所需要的保费发送至终端；接收所述终端发送的保单新增请求，根据所述保单新增请求中包含的投保人信息、被投保的险种标识及对应的所需要的保费进行保单新增操作，以生成保险单据。节省了系统资源。

Description

保险单据新增方法和装置

技术领域

本发明涉及计算机技术领域，特别是涉及一种保险单据新增方法和装置。

背景技术

当今社会，人们风险防护意识的增强，保险产品越来越受到大家的重视。保险机构所推出的保险产品也随之日益丰富。

传统方法中，不同类型的保险产品的相关数据是由不同的业务系统分开、独立的进行管理的。因此，需要在某一保险产品对应的业务系统中单独开通账号以获得授权，才能对该种保险产品进行相关业务操作，比如保险单据的新增、修改等处理操作。

这样一来，同一个保险业务员需要对不同的保险产品进行相关业务操作时，就需要分别在不同的业务系统中都开通账号，即一个保险业务员需要开通多个业务账号才能对不同的保险产品进行相关业务操作。显然，多账号的开通与管理非常的浪费系统资源。

发明内容

基于此，有必要针对上述问题，提供一种可以节省系统资源的保险单据新增方法和装置。

一种保险单据新增方法，所述方法包括以下步骤：

获取保险类型标识和投保人信息；

获取险种标识，所述险种标识为与所述保险类型标识对应的险种标识；

调用与获取的所述保险类型标识对应的业务系统的接口，使所述业务系统根据所述险种标识和所述投保人信息确定出与所述险种标识对应的所需要的保费；

接收所述业务系统返回的与所述险种标识对应的所需要的保费，将所述所需要的保费发送至终端；

接收所述终端发送的保单新增请求，根据所述保单新增请求中包含的投保人信息、被投保的险种标识及对应的所需要的保费进行保单新增操作，以生成保险单据。

在其中一个实施例中，所述获取险种标识的步骤，包括：

当所述保险类型标识对应的保险类型为可续保的类型时，调用与所述获取的保险类型标识对应的业务系统的接口，使所述业务系统查找是否存在与所述投保人信息对应的上一年度投保信息；

接收所述业务系统返回的查找到的上一年度投保信息，获取所述上一年度投保信息中包含的上一年度投保的险种标识。

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

实时监测对被调系统接口的访问并发量，所述被调系统包括所述业务系统；

获取预设的与所述被调系统接口对应的访问并发量阈值，当对所述被调系统接口的访问并发量达到对应的所述访问并发量阈值时，则断开与所述被调系统之间的交互。

在其中一个实施例中，所述根据所述保单新增请求中包含的投保人信息、被投保的险种标识及对应的所需要的保费进行保单新增操作，以生成保险单据的步骤，包括：

调用所述业务系统的审核接口，使所述业务系统根据所述保单新增请求中的所述投保人信息和所述被投保的险种标识对所述保单新增请求进行审核；

当对所述保单新增请求审核通过时，则调用支付系统的接口，使所述支付系统根据所述被投保的险种标识对应的所需要的保费进行支付操作；

当所述支付操作完成时，调用所述业务系统的承保接口进行承保操作以生成所述保险单据。

在其中一个实施例中，在生成保险单据的步骤之后，还包括：

根据所述被投保险种标识及对应的所需要的保费计算所述生成的保险单据对应的业务能力值，所述业务能力值用于表征业务员的业务能力。

在其中一个实施例中，所述根据所述被投保险种标识及对应的所需要的保费计算所述生成的保险单据对应的业务能力值的步骤，包括：

获取所述被投保险种标识对应的权重，根据所述权重和所述被投保险种标识对应的所需要的保费计算出所述生成的保险单据对应的业务能力值。

一种保险单据新增装置，所述装置包括：

获取模块，用于获取保险类型标识和投保人信息；

所述获取模块还用于获取险种标识，所述险种标识为与所述保险类型标识对应的险种标识；

系统调用模块，用于调用与获取的所述保险类型标识对应的业务系统的接口，使所述业务系统根据所述险种标识和所述投保人信息确定出与所述险种标识对应的所需要的保费；

所述获取模块还用于接收所述业务系统返回的与所述险种标识对应的所需要的保费，将所述所需要的保费发送至终端；

保险单据生成模块，用于接收所述终端发送的保单新增请求，根据所述保单新增请求中包含的投保人信息、被投保的险种标识及对应的所需要的保费进行保单新增操作，以生成保险单据。

在其中一个实施例中，所述获取模块还用于当所述保险类型标识对应的保险类型为可续保的类型时，调用与所述获取的保险类型标识对应的业务系统的接口，使所述业务系统查找是否存在与所述投保人信息对应的上一年度投保信息，接收所述业务系统返回的查找到的上一年度投保信息，获取所述上一年度投保信息中包含的上一年度投保的险种标识。

在其中一个实施例中，所述装置还包括：

监测模块，用于实时监测对被调系统接口的访问并发量，所述被调系统包括所述业务系统；

交互控制模块，用于获取预设的与所述被调系统接口对应的访问并发量阈值，当对所述被调系统接口的访问并发量达到对应的所述访问并发量阈值时，则断开与所述被调系统之间的交互。

在其中一个实施例中，其特征在于，所述装置还包括：

计算模块，用于根据所述被投保险种标识及对应的所需要的保费计算所述生成的保险单据对应的业务能力值，所述业务能力值用于表征业务员的业务能力。

上述保险单据新增方法和装置，通过获取保险类型标识和投保人信息；获取险种标识，所述险种标识为与所述保险类型标识对应的险种标识；调用与获取的保险类型标识对应的业务系统的接口，使业务系统根据险种标识和投保人信息确定出与险种标识对应的所需要的保费。即相当于，不需要再专门的注册管理保险类型相关信息的业务系统的账号，即可实现该业务系统所管理的险种标识的保费计算，避免了因注册多个账号造成的系统资源占用与浪费。接着，接收业务系统返回的与险种标识对应的所需要的保费，将所需要的保费发送至终端；接收终端发送的保单新增请求，根据保单新增请求中包含的投保人信息、被投保的险种标识及对应的所需要的保费进行保单新增操作，以生成保险单据。不需要再额外的针对每一个管理保险类型相关信息的业务系统的账号都注册一个账号，即可实现该业务系统所管理的保险单据的新增操作，同样节省了系统资源。

附图说明

图1为一个实施例中保险单据新增方法的应用环境图；

图2为一个实施例中保险单据新增方法的流程示意图；

图3为另一个实施例中保险单据新增方法的流程示意图；

图4为一个实施例中险种标识获取方法的流程示意图；

图5为一个实施例中访问并发量监控方法的流程示意图；

图6为一个实施例中保险单据生成方法的流程示意图；

图7为一个实施例中保险单据生成装置的结构示意图；

图8为另一个实施例中保险单据生成装置的结构示意图；

图9为又一个实施例中保险单据生成装置的结构示意图。

具体实施方式

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

本发明实施例所提供的保险单据新增方法可应用于图1所示的应用环境中，如图1所示，后台服务器120分别通过网络与终端110及业务服务器130进行通信连接。其中，业务系统运行于业务服务器130中，业务服务器130为至少一个。后台服务器120获取保险类型标识和投保人信息，以及获取险种标识。接着，后台服务器120调用与获取的保险类型标识对应的业务服务器130的接口，使业务服务器130根据获取的险种标识和投保人信息确定出与该险种标识对应的所需要的保费。进一步，后台服务器120会接收业务服务器130返回的该险种标识对应的所需要的保费，并将所需要的保费发送至至终端110。进一步，后台服务器120会接收终端110发送的保单新增请求，根据保单新增请求中包含的投保人信息、被投保的险种标识及对应的所需要的保费进行保单新增操作，以生成保险单据。即实现了对其他业务系统中的保险单据的新增，避免了需要额外开通其他业务系统的账号才能完成该业务系统的保险单据的新增操作，因此，节省了系统资源。此外，也节省了业务员的开单操作成本，提高了开单效率。

其中，终端110包括但不限于各种个人计算机、智能手机、平板电脑、笔记本电脑、便携式穿戴设备等，在此不进行一一列举。

如图2所示，提供了一种保险单据新增方法，以该方法应用于后台服务器120中为例进行说明，该方法具体包括以下步骤：

步骤202，获取保险类型标识和投保人信息。

本实施例中，保险单据新增操作者，比如保险业务员，通过终端显示界面选定保险类型，并输入投保人信息，终端获取对应的保险类型标识和输入的投保人信息。进一步，终端将获取的保险类型标识和投保人信息发送至后台服务器，后台服务器获取终端发送的保险类型标识和投保人信息。进一步，保险类型包括健康险、养老险、车险等保险类型。

步骤204，获取险种标识，险种标识为与保险类型标识对应的险种标识。

可以理解，某一保险类型包括至少一种险种。比如，健康险包括医疗保险、疾病保险、收入保障保险及护理保险等险种，车险包括车辆损失险、第三者责任保险及盗抢险等险种。

进一步，后台服务器还会获取险种标识，这里所获取的险种标识是与获取的保险类型标识对应的险种标识，即获取的险种标识对应的险种是步骤202中所获取的保险类型标识对应的保险类型所包含的险种。具体地，可以是用户通过终端界面输入的险种，终端获取对应的险种标识并将获取的险种标识发送至后台服务器，后台服务器获取终端发送的险种标识。也可以是，后台服务器根据投保人信息查找到该投保人信息对应的上一年度的投保信息，获取上一年度的投保信息中包含的上一年度投保险种标识。

步骤206，调用与获取的保险类型标识对应的业务系统的接口，使业务系统根据险种标识和投保人信息确定出与险种标识对应的所需要的保费。

进一步，后台服务器中预先设置了保险类型标识与业务系统的对应关系，比如，养老险对应的是养老险系统。根据该对应关系，后台服务器会调用与获取的保险类型标识对应的业务系统的接口，使该被调用的业务系统根据获取的险种标识和投保人信息确定出该险种标识对应的所需要的保费。具体地，后台服务器调用与获取的保险类型标识对应的业务系统的接口，将获取的险种标识和投保人信息发送至该业务系统，业务系统会根据获取的险种标识和投保人信息确定出该险种标识对应的所需要的保费。

这里，业务系统指用于管理对应的保险产品相关数据的系统。比如，养老险系统用于管理养老险的相关数据。

可以理解，当获取的险种标识是终端发送的用户输入的险种对应的险种标识时，则使业务系统根据险种标识和投保人信息确定出的是用户输入的险种所需要的保费。当获取的险种标识是上一年度投保险种标识时，则使业务系统根据险种标识和投保人信息确定出的是本年度续保上一年度投保险种标识所需要的保费。

步骤208，接收业务系统返回的与险种标识对应的所需要的保费，将所需要的保费发送至终端。

步骤210，接收终端发送的保单新增请求，根据保单新增请求中包含的投保人信息、被投保的险种标识及对应的所需要的保费进行保单新增操作，以生成保险单据。

进一步，业务系统会将所确定出的与获取的险种标识对应的所需要的保费返回至后台服务器，后台服务器接收业务系统返回的与获取的险种标识对应的所需要的保费，并将所获取的所需要的保费发送至终端。

终端会将所需要的保费与对应的险种进行显示。用户通过终端显示界面查看险种标识与对应的所需要的保费。进一步，用户可以通过终端显示界面发起保单新增请求，该保单新增请求中包含投保人信息、被投保的险种标识及对应的所需要的保费。

需要说明的是，这里，被投保险种标识指在进行保费计算之后，用户最终确认的要投保的险种标识，即被投保险种标识是指用户从已经计算出所需要的保费的险种标识中确定出的最终要投保的险种标识。可以是在步骤208将计算完险种标识对应的所需要的保费返回至终端后，用户直接对该险种标识进行保单新增操作，终端对应生成保单新增请求发送至后台服务器。可以理解，用户也可以在查看终端上显示的后台服务器返回的获取的险种标识所对应的保费时，不选择该险种标识发起保单新增请求，而是另外选择其他险种标识，终端响应用户操作生成保费计算请求发送至后台服务器，以使后台服务器根据再次选择的险种标识和投保人信息进行保费计算。即重新进入步骤204至步骤208。比如，终端上第一次显示的是上一年度投保险种A对应的所需要的保费，用户不想要再次选择上一年度投保险种，因此，用户另外选择险种B，则会重新进入步骤204，即后台服务器会继续执行步骤206至步骤208的操作，并将险种B所需要的保费发送至终端。

进一步，后台服务器会根据保单新增请求中包含的投保人信息、被投保的险种标识及对应的所需要的保费进行保单新增操作，以生成保险单据。

本实施例中，通过获取保险类型标识和投保人信息；获取险种标识；调用与获取的保险类型标识对应的业务系统的接口，使业务系统根据险种标识和投保人信息确定出与险种标识对应的所需要的保费。即相当于，不需要再专门的注册管理保险类型相关信息的业务系统的账号，即可实现该业务系统所管理的险种标识的保费计算，避免了因注册多个账号造成的系统资源占用与浪费。接着，接收业务系统返回的与险种标识对应的所需要的保费，将所需要的保费发送至终端；接收终端发送的保单新增请求，根据保单新增请求中包含的投保人信息、被投保的险种标识及对应的所需要的保费进行保单新增操作，以生成保险单据。不需要再额外的针对每一个管理保险类型相关信息的业务系统的账号都注册一个账号，即可实现该业务系统所管理的保险单据的新增操作，同样节省了系统资源。

此外，也不需要分别登录每个业务系统进行对应的保险单据的新增操作，节省了操作成本，提高了操作效率。

如图3所示，在一个实施例中，提供了一种保险单据新增方法，以该方法应用于后台服务器120中为例进行说明，该方法具体包括以下步骤：

步骤302，获取保险类型标识和投保人信息。

步骤304，获取险种标识，险种标识为与保险类型标识对应的险种标识。

步骤306，调用与获取的保险类型标识对应的业务系统的接口，使业务系统根据险种标识和投保人信息确定出与险种标识对应的所需要的保费。

步骤308，接收业务系统返回的与险种标识对应的所需要的保费，将所需要的保费发送至终端。

步骤310，接收终端发送的请求，检测所述终端发送的请求的类型。当请求的类型为保单新增请求时，则进入步骤312。当请求的类型为保费计算请求，则重新进入步骤304。

步骤312，根据保单新增请求中包含的投保人信息、被投保的险种标识及对应的所需要的保费进行保单新增操作，以生成保险单据。

具体地，当终端发送的请求类型为保费计算请求，则获取保费计算请求中的险种标识，重新进入步骤304至步骤308进行保费计算及返回所需要的保费至终端。当终端发送的请求类型为保单新增请求时，则根据保单新增请求中包含的投保人信息、被投保险种标识及对应的所需要的保费进行保单新增操作，以生成保险单据。

如图4所示，在一个实施例中，获取险种标识的步骤包括以下步骤：

步骤402，当保险类型标识对应的保险类型为可续保的类型时，调用与获取的保险类型标识对应的业务系统的接口，使业务系统查找是否存在与投保人信息对应的上一年度投保信息。

本实施例中，可续保的保险类型，是指该保险类型的保险产品可以续保，比如车险可以续保。与之对应的是不可续保的保险类型。可以理解，可续保与不可续保的划分依据，是根据实际情况进行预先划分设置的。本实施例对哪些保险类型是可续保，哪些是不可续保并不作限定。

进一步，当保险类型标识对应的保险类型为可续保的类型时，后台服务器在获取到投保人信息时，会调用与获取的保险类型标识对应的业务系统的接口，使业务系统查找是否存在与获取的投保人信息对应的上一年度投保信息。即查找是否存在所获取的投保人信息在上一年度针对该保险类型进行投保的信息。具体地，后台服务器会调用与获取的保险类型标识对应的业务系统的接口，将投保人信息发送至该业务系统，业务系统根据投保人信息查找是否存在与该投保人信息对应的上一年度投保信息。

步骤404，接收业务系统返回的查找到的上一年度投保信息，获取上一年度投保信息中包含的上一年度投保的险种标识。

进一步，业务系统在查找到与投保人信息对应的上一年度投保信息时，会将查找到的上一年度投保信息返回至后台服务器。其中，上一年度投保信息包含上一年度投保的险种标识。后台服务器会获取上一年度投保信息中包含的上一年度投保的险种标识。

本实施例中，针对可续保的保险类型，在获取投保人信息时，查询与投保人信息对应的上一年度的投保信息，将上一年度投保信息中包含的上一年度投保的险种标识作为获取的险种标识进行保费计算，相当于可以直接提供给投保人续保信息，不需要进行额外的已投保信息输入和查询操作，节省了操作成本，进而提高了续保效率。此外，自动提供续保信息可以引导投保人进行续保，提高了续保率。

如图5所示，在一个实施例中，该方法还包括访问并发量的监控步骤，具体包括以下步骤：

步骤502，实时监测对被调系统接口的访问并发量，被调系统包括业务系统。

本实施例中，后台服务器会实时监测各个被调系统接口的访问并发量。其中，被调系统指被调用接口的系统。访问并发量，是指同时通过后台服务器请求访问被调系统的用户终端数量。

需要说明的是，对被调系统接口的访问并发量，即指对被调系统的总的访问并发量。比如，终端A通过后台服务器请求调用业务系统S的接口A，同时，终端B通过后台服务器请求调用业务系统S的接口B，那么此时，业务系统S的访问并发量则为2。

进一步，被调系统包括业务系统，其中，业务系统为至少一个。可以理解，因为后台服务器可以同时处理多个终端分别发送的保险类型标识和投保人信息，其中，不同终端发送的保险类型标识可以不同，也可以相同，后台服务器可以同时调用与各个保险类型标识对应的业务系统的接口，因此，这些被调用的业务系统可以是相同的，也可以是不同的。

可以理解，被调系统也可以包括支付系统或其他被调用的第三方关联系统。

步骤504，获取预设的与被调系统接口对应的访问并发量阈值，当对被调系统接口的访问并发量达到对应的访问并发量阈值时，则断开与被调系统之间的交互。

后台服务器中预先设置了被调系统与访问并发量阈值的对应关系。即针对各个被调系统分别设置了对应的访问并发量阈值。当对被调系统接口的访问并发量达到了对应的访问并发量阈值时，则断开与被调系统之间的交互。具体地，可以关掉与该被调系统之间的交互开关，以断开与被调系统之间的交互。本实施例中，针对各个被调系统分别设置了访问并发量阈值，实施监测各个被调系统的访问并发量，当监测到对被调系统的访问并发量达到对应的访问并发量阈值时，则断开与该被调系统之间的交互，以避免因被调系统的异常而影响到后台服务器中的其他模块的正常使用，保证了后台服务器运行的稳定性。

如图6所示，在一个实施例中，根据保单新增请求中包含的投保人信息、被投保的险种标识及对应的所需要的保费进行保单新增操作，以生成保险单据的步骤(简称保险单据生成步骤)包括以下步骤：

步骤602，调用业务系统的审核接口，使业务系统根据保单新增请求中的投保人信息和被投保的险种标识对保单新增请求进行审核。

本实施例中，后台服务器会调用业务系统的审核接口，使业务系统根据保单新增请求中的投保人信息和被投保的险种标识对保单新增请求进行审核操作。具体地，后台服务器调用业务系统的审核接口将保单新增请求中的投保人信息和被投保的险种标识发送至业务系统，业务系统根据投保人信息和被投保的险种标识进行审核。

可以理解，后台服务器可以根据预设的审核顺序多次调用业务系统的审核接口进行审核，当接到上一个审核通过的结果时，再调用业务系统进行下一个审核项目的审核。比如，后台服务器可以先调用业务系统的审核接口来对投保人信息和被投保的险种标识进行规则检查(比如检查投保人信息是否符合与被投保的险种标识对应的要求)，接着后台服务器可以再调用业务系统的审核接口来根据投保人信息和被投保的险种标识对保单新增请求进行核保。其中，核保是指保险人对投保申请进行审核，决定是否接受承保这一风险，并在接受承保风险的情况下，确定承保条件的过程。

当然，后台服务器也可以只调用一次业务系统的审核接口完成审核操作。具体根据实际审核需求来确定。本实施例对此不做限定。

步骤604，当对保单新增请求审核通过时，则调用支付系统的接口，使支付系统根据被投保的险种标识对应的所需要的保费进行支付操作。

进一步，当对保单新增请求审核通过时，后台服务器则调用支付系统的接口，使支付系统根据与被投保的险种标识对应的所需要的保费进行支付操作。具体地，后台服务器调用支付系统的接口，支付系统根据所需要的保费生成支付界面信息，终端将支付界面进行显示，用户通过支付界面输入支付信息并确认支付。支付系统接收终端发送的输入的支付信息和支付请求进行对应的支付操作。

步骤606，当支付操作完成时，调用业务系统的承保接口进行承保操作以生成保险单据。

当支付操作完成时，后台服务器接收支付系统发送的支付操作完成信息，接着，后台服务器会进一步调用业务系统的承保接口进行承保操作以生成保险单据。具体地，后台服务器会调用业务系统的承保接口，将被投保的险种标识和所需要的保费发送至业务系统，业务系统会根据被投保的险种标识和所需要的保费进行承保操作以生成保险单据。

本实施例中，后台服务器通过调用业务系统的审核接口完成对保单新增请求的审核操作，并于审核通过时，调用支付系统的接口完成支付操作，当支付操作完成时，调用业务系统的承保接口进行承保操作以生成保险单据。即后台服务器通过对不同被调系统的接口的调用完成保险单据的生成，不需要再额外的针对每一个管理保险类型相关信息的业务系统的账号都注册一个账号，即可实现该业务系统所管理的保险单据的新增操作，节省了系统资源。

此外，也不需要分别登录每个业务系统进行对应的保险单据的新增操作，节省了操作成本，提高了操作效率。

在一个实施例中，在生成保险单据的步骤之后，还包括：根据被投保险种标识及对应的所需要的保费计算生成的保险单据对应的业务能力值，业务能力值用于表征业务员的业务能力的步骤。

具体地，业务能力值，指用于表征业务员的业务能力的值。在生成保险单据之后，说明业务员完成了一项新增保单业务，那么后台服务器会进一步根据被投保险种标识及对应的所需要的保费计算所生成的保险单据对应的业务能力值，即根据该笔新增保单业务的相关数据来转化生成用于表征业务员业务能力的业务能力值。

本实施例中，可以自动的利用被投保险种标识及对应的所需要的保费来计算出表征业务能力的业务能力值，可以更加准确、直观地反映出业务员的业务能力，以便于对人力资源的合理分配与评估。

在一个实施例中，根据被投保险种标识及对应的所需要的保费计算生成的保险单据对应的业务能力值的步骤包括：获取被投保险种标识对应的权重，根据权重和所需要的保费计算出生成的保险单据对应的业务能力值的步骤。

具体地，后台服务器中预先设置了险种标识与权重之间的对应关系，根据该对应关系，获取被投保险种标识对应的权重，根据权重与所需要的保费计算出所生成的保险单据对应的业务能力值。比如，险种标识对应的权重为0.09，所需要的保费为1000，那么计算出的业务能力值则为0.09*1000＝90分。

本实施例中，预先为各个险种标识设置权重，自动的获取被投保险种标识对应权重，利用权重与所需要的保费来计算出表征业务能力的业务能力值，可以更加准确、直观地反映出业务员的业务能力，以便于对人力资源的合理分配与评估。

在一个实施例中，根据被投保险种标识及对应的所需要的保费计算生成的保险单据对应的业务能力值的步骤包括：获取被投保险种标识下的保费与业务能力值之间的对应关系，根据对应关系，查找所需要的保费对应的业务能力值，即为生成的保险单据对应的业务能力值。

具体地，后台服务器中预先针对各个不同的险种标识设置与之对应的保费与业务能力值之间的对应关系。进一步，后台服务器获取被投保险种标识下的保费与业务能力值之间的对应关系，根据该对应关系，查找所需要的保费对应的业务能力值。其中，所查找到的所需要的保费对应的业务能力值极为生成的保险单据对应的业务能力值。

本实施例中，预先针对各个不同的险种标识设置与之对应的保费与业务能力值之间的对应关系，自动查找所需要的保费对应的表征业务能力的业务能力值，可以更加准确、直观地反映出业务员的业务能力，以便于对人力资源的合理分配与评估。

如图7所示，在一个实施例中，提供了一种保险单据生成装置，该装置包括获取模块702、系统调用模块704及保险单据生成模块706，其中：

获取模块702，用于获取保险类型标识和投保人信息。

获取模块702还用于获取险种标识，险种标识为与保险类型标识对应的险种标识。

系统调用模块704，用于调用与获取的保险类型标识对应的业务系统的接口，使业务系统根据险种标识和投保人信息确定出与险种标识对应的所需要的保费。

获取模块702还用于接收业务系统返回的与险种标识对应的所需要的保费，将所需要的保费发送至终端。

保险单据生成模块706，用于接收终端发送的保单新增请求，根据保单新增请求中包含的投保人信息、被投保的险种标识及对应的所需要的保费进行保单新增操作，以生成保险单据。

在一个实施例中，获取模块702还用于当保险类型标识对应的保险类型为可续保的类型时，调用与获取的保险类型标识对应的业务系统的接口，使业务系统查找是否存在与投保人信息对应的上一年度投保信息，接收业务系统返回的查找到的上一年度投保信息，获取上一年度投保信息中包含的上一年度投保的险种标识。

如图8所示，在一个实施例中，该装置还包括：

监测模块708，用于实时监测对被调系统接口的访问并发量，被调系统包括业务系统。

交互控制模块710，用于获取预设的与被调系统接口对应的访问并发量阈值，当对被调系统接口的访问并发量达到对应的访问并发量阈值时，则断开与被调系统之间的交互。

在一个实施例中，保险单据生成模块706还用于调用业务系统的审核接口，使业务系统根据保单新增请求中的投保人信息和被投保的险种标识对保单新增请求进行审核；当对保单新增请求审核通过时，则调用支付系统的接口，使支付系统根据被投保的险种标识对应的所需要的保费进行支付操作；当支付操作完成时，调用业务系统的承保接口进行承保操作以生成保险单据。

如图9所示，在一个实施例中，该装置还包括：

计算模块712，用于根据被投保险种标识及对应的所需要的保费计算生成的保险单据对应的业务能力值，业务能力值用于表征业务员的业务能力。

在一个实施例中，计算模块712还用于获取被投保险种标识对应的权重，根据权重和被投保险种标识对应的所需要的保费计算出生成的保险单据对应的业务能力值。

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

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

Claims (10)

1.一种保险单据新增方法，所述方法包括以下步骤：

获取保险类型标识和投保人信息；

获取险种标识，所述险种标识为与所述保险类型标识对应的险种标识；

调用与获取的所述保险类型标识对应的业务系统的接口，使所述业务系统根据所述险种标识和所述投保人信息确定出与所述险种标识对应的所需要的保费；

接收所述业务系统返回的与所述险种标识对应的所需要的保费，将所述所需要的保费发送至终端；

接收所述终端发送的保单新增请求，根据所述保单新增请求中包含的投保人信息、被投保的险种标识及对应的所需要的保费进行保单新增操作，以生成保险单据。

2.根据权利要求1所述的方法，其特征在于，所述获取险种标识的步骤，包括：

当所述保险类型标识对应的保险类型为可续保的类型时，调用与所述获取的保险类型标识对应的业务系统的接口，使所述业务系统查找是否存在与所述投保人信息对应的上一年度投保信息；

接收所述业务系统返回的查找到的上一年度投保信息，获取所述上一年度投保信息中包含的上一年度投保的险种标识。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

实时监测对被调系统接口的访问并发量，所述被调系统包括所述业务系统；

获取预设的与所述被调系统接口对应的访问并发量阈值，当对所述被调系统接口的访问并发量达到对应的所述访问并发量阈值时，则断开与所述被调系统之间的交互。

4.根据权利要求1所述的方法，其特征在于，所述根据所述保单新增请求中包含的投保人信息、被投保的险种标识及对应的所需要的保费进行保单新增操作，以生成保险单据的步骤，包括：

调用所述业务系统的审核接口，使所述业务系统根据所述保单新增请求中的所述投保人信息和所述被投保的险种标识对所述保单新增请求进行审核；

当对所述保单新增请求审核通过时，则调用支付系统的接口，使所述支付系统根据所述被投保的险种标识对应的所需要的保费进行支付操作；

当所述支付操作完成时，调用所述业务系统的承保接口进行承保操作以生成所述保险单据。

5.根据权利要求1所述的方法，其特征在于，在生成保险单据的步骤之后，还包括：

根据所述被投保险种标识及对应的所需要的保费计算所述生成的保险单据对应的业务能力值，所述业务能力值用于表征业务员的业务能力。

6.根据权利要求5所述的方法，其特征在于，所述根据所述被投保险种标识及对应的所需要的保费计算所述生成的保险单据对应的业务能力值的步骤，包括：

获取所述被投保险种标识对应的权重，根据所述权重和所述被投保险种标识对应的所需要的保费计算出所述生成的保险单据对应的业务能力值。

7.一种保险单据新增装置，其特征在于，所述装置包括：

获取模块，用于获取保险类型标识和投保人信息；

所述获取模块还用于获取险种标识，所述险种标识为与所述保险类型标识对应的险种标识；

系统调用模块，用于调用与获取的所述保险类型标识对应的业务系统的接口，使所述业务系统根据所述险种标识和所述投保人信息确定出与所述险种标识对应的所需要的保费；

所述获取模块还用于接收所述业务系统返回的与所述险种标识对应的所需要的保费，将所述所需要的保费发送至终端；

保险单据生成模块，用于接收所述终端发送的保单新增请求，根据所述保单新增请求中包含的投保人信息、被投保的险种标识及对应的所需要的保费进行保单新增操作，以生成保险单据。

8.根据权利要求7所述的装置，其特征在于，所述获取模块还用于当所述保险类型标识对应的保险类型为可续保的类型时，调用与所述获取的保险类型标识对应的业务系统的接口，使所述业务系统查找是否存在与所述投保人信息对应的上一年度投保信息，接收所述业务系统返回的查找到的上一年度投保信息，获取所述上一年度投保信息中包含的上一年度投保的险种标识。

9.根据权利要求7所述的装置，其特征在于，所述装置还包括：

监测模块，用于实时监测对被调系统接口的访问并发量，所述被调系统包括所述业务系统；

交互控制模块，用于获取预设的与所述被调系统接口对应的访问并发量阈值，当对所述被调系统接口的访问并发量达到对应的所述访问并发量阈值时，则断开与所述被调系统之间的交互。

10.根据权利要求7所述的装置，其特征在于，所述装置还包括：

计算模块，用于根据所述被投保险种标识及对应的所需要的保费计算所述生成的保险单据对应的业务能力值，所述业务能力值用于表征业务员的业务能力。