CN113706255A - 业务订单生成方法、装置、服务器及存储介质 - Google Patents

Abstract

本申请涉及数据处理，提供一种业务订单生成方法、装置、服务器及存储介质，该方法包括：获取多个历史业务订单，并根据预设的业务询价规则跑批多个历史业务订单，生成每个历史业务订单对应的业务询价单；从每个业务询价单中获取多个报价因子数据，并根据多个报价因子数据，确定每个业务询价单对应的预报价；根据多个业务询价单和每个业务询价单对应的预报价，生成多个目标询价单；获取移动端发送的确认信息，根据确认信息和确认信息对应的目标询价单，生成业务订单。本申请还涉及人工智能，旨在提高业务订单的处理效率。

Description

业务订单生成方法、装置、服务器及存储介质

技术领域

本申请涉及数据处理的技术领域，尤其涉及一种业务订单生成方法、装置、服务器及存储介质。

背景技术

随着人们对各类财产安全以及人身安全的注重，各大保险行业不断的兴起，购买保险的人也越来越多。当前，保险公司在客户的保险合同到期前，会询问被保险人是否续签当前保险合同，并根据客户意愿和当时的实际情况，可以对原合同条件稍加修改，重新签订保险合同，这种行为被称为续保。当前续保流程主要通过面签方式进行，在客户选择续保时，通常需要进行大量的续保费用计算以及保单信息核对工作，需要业务员申请询价拿到业务询价单，再根据业务询价单进行询价，还需要客户填写保单等操作，才能生成最终的业务订单，业务流程比较繁杂，处理效率较低。

发明内容

本申请的主要目的在于提供一种业务订单生成方法、装置、服务器及存储介质，旨在提高业务订单的处理效率。

第一方面，本申请提供一种业务订单生成方法，应用于服务器，所述方法包括：

获取多个历史业务订单，并根据预设的业务询价规则跑批多个所述历史业务订单，生成每个所述历史业务订单对应的业务询价单；

从每个所述业务询价单中获取多个报价因子数据，并根据多个所述报价因子数据，确定每个所述业务询价单对应的预报价；

根据多个所述业务询价单和每个所述业务询价单对应的预报价，生成多个目标询价单；

获取移动端发送的确认信息，根据所述确认信息和所述确认信息对应的目标询价单，生成业务订单。

第二方面，本申请还提供一种业务订单生成装置，所述业务订单生成装置包括：

跑批模块，用于获取多个历史业务订单，并根据预设的业务询价规则跑批多个所述历史业务订单，生成每个所述历史业务订单对应的业务询价单；

报价模块，用于从每个所述业务询价单中获取多个报价因子数据，并根据多个所述报价因子数据，确定每个所述业务询价单对应的预报价；

询价模块，用于根据多个所述业务询价单和每个所述业务询价单对应的预报价，生成多个目标询价单；

生成模块，用于获取移动端发送的确认信息，根据所述确认信息和所述确认信息对应的目标询价单，生成业务订单。

第三方面，本申请还提供一种服务器，所述服务器包括处理器、存储器、以及存储在所述存储器上并可被所述处理器执行的计算机程序，其中所述计算机程序被所述处理器执行时，实现如上所述的业务订单生成方法的步骤。

第四方面，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，其中所述计算机程序被处理器执行时，实现如上所述的业务订单生成方法的步骤。

本申请提供一种业务订单生成方法、装置、服务器及存储介质，本申请通过获取多个历史业务订单，并根据预设的业务询价规则跑批多个历史业务订单，生成每个历史业务订单对应的业务询价单；从每个业务询价单中获取多个报价因子数据，并根据多个报价因子数据，确定每个业务询价单对应的预报价；根据多个业务询价单和每个业务询价单对应的预报价，生成多个目标询价单；获取移动端发送的确认信息，根据确认信息和确认信息对应的目标询价单，生成业务订单。通过批量的对多个历史业务订单进行自动询报价处理，无需业务员被动地申请询报价操作，简化了续保处理过程，并减少人工接入，能够有效提高业务订单的处理效率。

附图说明

为了更清楚地说明本申请实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种业务订单生成方法的步骤流程示意图；

图2为图1中的业务订单生成方法的子步骤流程示意图；

图3为实施本实施例提供的业务订单生成方法的一场景示意图；

图4为本申请实施例提供的一种业务订单生成装置的示意性框图；

图5为图4中的业务订单生成装置的子模块的示意性框图；

图6为本申请实施例提供的一种服务器的结构示意性框图。

本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

附图中所示的流程图仅是示例说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解、组合或部分合并，因此实际执行的顺序有可能根据实际情况改变。另外，虽然在装置示意图中进行了功能模块的划分，但是在某些情况下，可以以不同于装置示意图中的模块划分。

本申请实施例提供一种业务订单生成方法、装置、服务器及存储介质。其中，该业务订单生成方法可应用于服务器中，该服务器可以为单台的服务器，也可以为由多台服务器组成的服务器集群。服务器可以是独立的服务器，也可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。

下面结合附图，对本申请的一些实施方式作详细说明。在不冲突的情况下，下述的实施例及实施例中的特征可以相互组合。

请参照图1，图1为本申请实施例提供的一种业务订单生成方法的步骤流程示意图。

如图1所示，该业务订单生成方法包括步骤S101至步骤S104。

步骤S101、获取多个历史业务订单，并根据预设的业务询价规则跑批多个历史业务订单，生成每个历史业务订单对应的业务询价单。

本申请实施例可以基于人工智能技术对多个历史业务订单等相关的数据进行获取和处理。其中，人工智能(Artificial Intelligence，AI)是利用数字计算机或者数字计算机控制的机器模拟、延伸和扩展人的智能，感知环境、获取知识并使用知识获得最佳结果的理论、方法、技术及应用系统。人工智能基础技术一般包括如云计算和分布式存储等技术。

其中，历史业务订单可以是待续保保单，也可以称为历史业务合同。获取在预设时间内到达保单截止日的待续保保单，得到多个历史业务订单，或者说，获取距离保单截止日预设时间之内的待续保保单，得到多个历史业务订单。历史业务订单为临近保单截止日且需要重新签订保险合同的保险单，该预设时间可根据实际情况灵活设置，例如为15天。

示例性的，待续保保单包括上年保单号，承保起止期，承保机构渠道信息，险种产品信息，销售信息，投保人/被保人/受益人信息等，以及被保险人名称，保险标的的名称及其存放地点或所处状态、保险金额、保险期限、保险费等，承保起止期包括保单起效日和保单截止日。

在一实施例中，获取当前时间信息，并获取多个保单的保单截止日；根据当前时间信息和预设时间期限确定目标时间期限；根据目标时间期限和多个保单的保单截止日，从多个保单中筛选出多个待续保保单作为历史业务订单。目标时间期限例如为7个工作日，本实施例对此不做具体限定。

示例性的，将当前时间信息和预设时间期限进行相加得到目标时间期限，其中，该目标时间期限用于确定保单是否在预设时间期限内到达保单截止日；将目标时间期限和每个保单的保单截止日进行比较；将保单截止日小于或等于目标时间期限的保单作为历史业务订单，得到多个在预设时间期限内达到保单截止日的历史业务订单。

在一实施例中，如图2所示，步骤S101包括：子步骤S1011至子步骤S1013。

子步骤S1011、从多个历史业务订单中剔除预设订单标识对应的失效订单，得到多个目标业务订单。

其中，预设订单标识包括但不限于已注销保单的保单标识、禁保业务保单的保单标识和记录在黑名单中的保单的保单标识。需要说明的是，根据多个历史业务订单的标识信息对多个历史业务订单进行筛选，得到多个目标业务订单。通过剔除预设订单标识对应的失效订单，从而清除无效的历史业务订单，得到多个有效的目标业务订单。

示例性的，获取每个历史业务订单的标识信息，并从数据库或存储器中获取预先设置好的预设订单标识，该预设订单标识如已注销保单的保单标识、禁保业务保单的保单标识和记录在黑名单中的保单的保单标识等；从多个历史业务订单中确定与预定保单标识对应的失效订单，并剔除与预定保单标识对应的失效订单，得到多个目标业务订单。

子步骤S1012、调用预设的业务询价接口，对多个目标业务订单进行跑批处理，生成每个目标业务订单的业务询价单。

其中，使用批处理方式，调用预设的业务询价接口对多个目标业务订单进行跑批理，以生成每个目标业务订单的业务询价单，业务询价单可以是续保询价单，该业务询价单例如包括保险产品信息、保险销售信息、保险机构信息、投保人/被保人/受益人信息、承保报价方案信息等。

在一实施例中，生成业务询价单的方法包括：获取业务询价单的预设模板，并获取目标业务订单中的多项数据信息；确定目标业务订单中的每项数据信息在业务询价单的预设模板中的目标位置；在业务询价单的预设模板中，将每项数据信息填充至各自对应的目标位置，得到目标业务订单的业务询价单。

在一实施例中，间隔预设时间对目标业务订单进行跑批处理，批量生成目标业务订单的业务询价单。其中，预设时间可根据实际情况进行设置，可选的该预设时间为30分钟。需要说明的是，与常规续保方式相比，增加定时跑批环节能够有效简化续保业务流程，提高业务订单的处理效率。

在一实施例中，获取服务器的当前吞吐量和/或当前时间信息；在当前吞吐量小于等于预设吞吐量和/或当前时间信息处于预设时间范围内时，生成多个目标业务订单的跑批任务；基于多个跑批任务，调用预设的业务询价接口对多个目标业务订单进行跑批处理，以获取每个目标业务订单的业务询价单。

其中，预设吞吐量和预设时间范围可根据实际情况进行设置，在当前吞吐量小于等于预设吞吐量时，表明服务器较为空闲，此时生成多个目标业务订单的跑批任务对多个目标业务订单进行跑批，可以合理的利用服务器资源，扩大服务器的使用效益；同理，在当前时间信息处于预设时间范围内时，生成多个目标业务订单的跑批任务，并调用业务询价接口对多个目标业务订单进行跑批处理，预设时间范围例如为晚上12点至凌晨6点，跑批流程可以在晚间服务器业务量较少的时间段执行，这样错峰执行可以合理的利用服务器的计算资源。

需要说明的是，通过业务询价接口的跑批处理生成多个目标业务订单的业务询价单，业务询价流程由服务器自动执行而不是由业务员人为地申请，使得业务员减少了询报价动作，简化了续保业务操作，能够有效提高业务订单的处理效率。

子步骤S1013、对每个目标业务订单的业务询价单进行信息校验，并获取通过校验的业务询价单作为历史业务订单对应的业务询价单。

生成每个目标业务订单的业务询价单之后，对每个业务询价单进行自动报价的信息校验，以确定通过校验的业务询价单，该通过校验的业务询价单即为能够进行自动报价的目标业务询价单，并将目标业务询价单作为历史业务订单对应的业务询价单。通过对业务询价单中进行自动报价的规则验证，确保业务询价单不出现重大纰漏，加强业务订单生成的安全性。

在一实施例中，对每个业务询价单的预设位置的字段数据进行核对校验。其中，预设位置可以是业务询价单中的多个信息填选框的坐标位置，信息填选框中充填有字段数据，将业务询价单的预设位置的字段数据与上一年最新保单(待续保保单)的字段数据进行逐一校验，若验证无误、字段数据一致，则通过验证；若逐一验证过程中存在不一致的字段数据，则不通过验证，需要转人工处理，即将不通过验证的相关业务询价单和历史业务订单发送至业务端。

在一实施例中，对每个业务询价单中的险种信息进行核对校验。例如，确定业务询价单中的险种信息与上一年最新保单(历史业务订单)的险种信息是否一致，若一致则通过校验，若不一致则不通过校验。能够避免业务询价单出现重大的信息错漏，保证续保业务无误。

示例性的，在生成业务询价单的过程中，向业务询价单中增加产品大类责任险，包括雇主责任险A和雇主责任险B，而与业务询价单对应的历史业务订单的险种信息不包括雇主责任险A和雇主责任险B，则对该业务询价单中的险种信息进行校验的结果为不通过校验，需要转人工处理。需要说明的是，转人工处理的，可以进行人工报价，生成报价任务，由核保人进行报价，生成报价结果。

在一实施例中，对每个业务询价单中的承保报价方案信息进行核对校验，以确定上一年的承保报价方案信息是否符合最新的承保报价方案的要求。例如，验证业务询价单中的承保报价方案信息中的费用信息及费用上限信息是否满足最新的承保报价方案的规则策略，若满足则通过校验，若不满足则不通过校验。获取通过验证的目标业务询价单，不通过验证的目标业务询价单可以转人工处理。

在一实施例中，对每个目标业务订单的业务询价单进行信息校验之后，获取通过校验的多个业务询价单作为每个历史业务订单对应的业务询价单。

在一实施例中，获取多个历史业务订单之后，调用预设的业务询价接口对多个历史业务订单进行跑批处理，得到多个业务询价单；对每个业务询价单进行信息校验，并获取通过校验的多个目标业务询价单，得到每个历史业务订单对应的业务询价单。通过对多个历史业务订单进行跑批处理和信息校验处理，无需业务员被动地申请询报价操作，直接将业务询价由服务器批量完成，有效提高续保业务的处理效率。

步骤S102、从每个业务询价单中获取多个报价因子数据，并根据多个报价因子数据，确定每个业务询价单对应的预报价。

将业务询价单中的客户历史数据作为报价因子数据，从每个业务询价单中获取多个报价因子数据。例如，报价因子数据包括业务类型、保险期限、满期赔付率、费用率、连续两年满期赔付率等信息。

在一实施例中，将每个业务询价单对应的多个报价因子数据输入至预设的险种定价算法，得到每个业务询价单对应的预报价。其中，报价因子数据和险种定价数据算法可根据实际情况进行设置，例如报价因子数据为历史保费、历史赔付系数、险种信息和保险期限等。

示例性的，险种信息为雇主责任险，预设的险种定价算法为：续保年保费＝上年标的年保费*方案调整系数*费用调整系数*历史赔付系数，报价因子数据包括上年标的年保费、方案调整系数、费用调整系数和历史赔付系数。其中，方案调整系数＝max(0.8，r1)，如果r>1，则r1＝0.5*(r-1)+1；如果r<＝1，则r1＝r，r＝(今年询价单主险纯风险保费+今年询价单所有附加险及纯风险保费之和)/(上年保单主险纯风险保费+上年保单所有附加险及纯风险保费之和)。

在一实施例中，获取业务询价单对应的险种信息；根据险种信息，从模型数据库中调用预先训练好的险种定价模型；根据多个报价因子数据，生成业务询价单的特征向量；将特征向量输入至险种定价模型进行处理，得到业务询价单对应的预报价。其中，险种信息与险种定价模型存在对应关系，模型数据库中预先存储有多个险种定价模型，不同险种定价模型用于计算不同险种信息的业务询价单对应的预报价。

需要说明的是，险种定价模型例如为卷积神经网络模型、循环神经网络模型和深度神经网络模型中的一种，通过多个业务询价单的特征向量作为训练样本对险种定价模型进行迭代训练，直至险种定价模型收敛，得到训练好的险种定价模型，并将训练好的险种定价模型存储至模型数据库，并建立该训练好的险种定价模型与险种信息之间的对应关系，以便后续快速地从模型数据库中调用险种定价模型。

在一实施例中，险种信息可以是多个。根据每个业务询价单对应的险种信息，对多个业务询价单进行分类，得到多个询价单集合，其中，每个询价单集合包括同一险种信息的多个业务询价单；确定每个询价单集合各自对应的险种定价模型；通过每个险种定价模型分别对各自对应的询价单集合中的多个业务询价单进行定价处理，得到每个业务询价单对应的预报价。通过对多个业务询价单进行分类，并利用不同的险种定价模型对多个业务询价单进行定价处理，使得每个业务询价单对应的预报价更加准确。

步骤S103、根据多个业务询价单和每个业务询价单对应的预报价，生成多个目标询价单。

根据业务询价单和预报价生成目标询价单，该目标询价单即为报价状态的询价单，该报价状态的询价单需要待客户确认。例如，将业务询价单对应的预报价充填至该业务询价单，得到目标询价单，该目标询价单未经客户签字确认，因此，可以将该目标询价单发送至客户持有的移动端，并由客户在该移动端上对报价状态的询价单进行签字确认。

在一实施例中，生成多个目标询价单之后，将该多个目标询价单推送给业务终端，该业务终端是对接多个历史业务订单的业务员持有的终端。例如将该多个目标询价单分配至业务终端的保险系统平台上的任务列表，以便业务员通过该任务列表查看多个目标询价单的相关信息，并根据目标询价单与对应的客户进行沟通，确保续保业务顺利进行。

在一实施例中，生成多个目标询价单之后，业务员基于业务终端生成目标询价单的确认链接，该确认链接用于指示客户参与投保确认流程；将目标询价单的确认链接发送给对应的移动端，以便客户在移动端上基于确认链接对目标询价单进行确认。

示例性的，通过业务终端上的保险系统平台生成目标询价单的确认链接，例如业务员登录保险系统平台，通过触发该保险系统平台上的分享投保确认的相关控件或者按钮，生成目标询价单的确认链接，通过该目标询价单的确认链接可以跳转至该保险系统平台，并参与该保险系统平台预先设置的投保确认流程。

步骤S104、获取移动端发送的确认信息，根据确认信息和确认信息对应的目标询价单，生成业务订单。

其中，目标询价单需要待客户确认后才能生效，通过获取至少一个移动端发送的确认信息，并根据至少一个确认信息和至少一个确认信息对应的目标询价单，生成至少一个经客户确认的业务订单。

在一实施例中，获取移动端发送的确认信息之前，还包括：生成每个目标询价单的确认链接，并确定每个目标询价单对应的移动端；将每个目标询价单的确认链接发送至各自对应的移动端，以供每个移动端通过确认链接，生成目标询价单的确认信息。

需要说明的是，可以根据目标询价单生成确认链接，该确认链接用于指示客户参与投保确认流程，将确认链接发送给目标询价单对应的移动端，该移动端为客户持有的移动终端，以便客户能够浏览报价状态的询价单，并基于该确认链接对目标询价单进行签字确认等确认操作，本实施例不做具体限定。

例如，通过触发确认链接跳转至保险系统平台链接的网页，该网页显示有目标询价单的预览图，客户在浏览预览图中的各项条文信息和预报价等信息后，服务器确认预览图的浏览完成，则网页自动显示签字确认页面，客户可以通过该签字确认页面输入签字信息。

在一实施例中，获取移动端发送的确认信息之后，从确认信息中获取签名信息，其中，签名信息是客户在签字确认页面中输入的，签字确认页面是客户触发确认链接后生成的；确定确认信息对应的目标询价单的目标区域，目标区域为待合成签名信息的区域；在目标区域内对签名信息进行签名合成，得到带有客户签名的业务订单。

示例性的，移动端通过确认链接显示目标询价单的签字确认页面，其中，签字确认页面包括目标询价单的预览图。需要说明的是，客户通过预览图核对目标询价单中的各项数据信息；按照预设的投保确认流程，客户在确认目标询价单上的各项数据信息无误后，会进行签字确认，从而能够获取客户对移动端进行触控操作签下的签名信息。

示例性的，从确认信息中获取签名信息之后，调用电子签名合成服务，在目标询价单的目标区域内将签名信息进行签名合成，得到带有客户签名的业务订单，该业务订单包括客户的签名信息。需要说明的是，这里的电子签名合成服务，即电子签名技术，直观视觉角度而言是将客户签字合成到电子投保单指定位置，实际上不可见的对电子投保单进行数字签名，进行加密，防伪、防篡改，更为重要，主要目的是识别双方身份，不可篡改抵赖。

请参照图3，图3为实施本实施例提供的业务订单生成方法的一场景示意图。

如图3所示，服务器10获取多个历史业务订单，并根据预设的业务询价规则跑批多个历史业务订单，生成每个历史业务订单对应的业务询价单；服务器10从每个业务询价单中获取多个报价因子数据，并根据多个报价因子数据，确定每个业务询价单对应的预报价；服务器10根据多个业务询价单和每个业务询价单对应的预报价，生成多个目标询价单；服务器10确定每个目标询价单对应的移动端20，并将每个目标询价单发送给各自对应的移动端20；移动端20显示目标询价单的签字确认页面，该签字确认页面包括目标询价单的预览图，客户在浏览预览图中的各项条文信息后，可以通过移动端20显示该签字确认页面输入签字信息，以供客户在签字确认页面中输入签字信息，并由移动端20将客户输入的签字信息发送给服务器10；服务器10获取移动端20发送的签名信息，并根据签名信息和签名信息对应的目标询价单，生成带有客户签名的业务订单。

上述实施例提供的业务订单生成方法，通过获取多个历史业务订单，并根据预设的业务询价规则跑批多个历史业务订单，生成每个历史业务订单对应的业务询价单；从每个业务询价单中获取多个报价因子数据，并根据多个报价因子数据，确定每个业务询价单对应的预报价；根据多个业务询价单和每个业务询价单对应的预报价，生成多个目标询价单；获取移动端发送的确认信息，根据确认信息和确认信息对应的目标询价单，生成业务订单。通过批量的对多个历史业务订单进行自动询报价处理，无需业务员被动地申请询报价操作，简化了续保处理过程，并减少人工接入，能够有效提高业务订单的处理效率。

请参照图4，图4为本申请实施例提供的一种业务订单生成装置的示意性框图。

如图4所示，该业务订单生成装置200，包括：跑批模块201、报价模块202、询价模块203和生成模块204。

跑批模块201，用于获取多个历史业务订单，并根据预设的业务询价规则跑批多个所述历史业务订单，生成每个所述历史业务订单对应的业务询价单；

报价模块202，用于从每个所述业务询价单中获取多个报价因子数据，并根据多个所述报价因子数据，确定每个所述业务询价单对应的预报价；

询价模块203，用于根据多个所述业务询价单和每个所述业务询价单对应的预报价，生成多个目标询价单；

生成模块204，用于获取移动端发送的确认信息，根据所述确认信息和所述确认信息对应的目标询价单，生成业务订单。

在一个实施例中，如图5所示，跑批模块201包括：

剔除子模块2011，用于从多个所述历史业务订单中剔除预设订单标识对应的失效订单，得到多个目标业务订单；

调用子模块2012，用于调用预设的业务询价接口，对多个所述目标业务订单进行跑批处理，生成每个所述目标业务订单的业务询价单；

校验子模块2013，用于对每个所述目标业务订单的业务询价单进行信息校验，并获取通过校验的业务询价单作为所述历史业务订单对应的业务询价单。

在一个实施例中，跑批模块201还用于：

获取所述服务器的当前吞吐量和/或当前时间信息；

在所述当前吞吐量小于等于预设吞吐量和/或所述当前时间信息处于预设时间范围内时，生成多个所述目标业务订单的跑批任务；

基于多个所述跑批任务，调用预设的业务询价接口对多个所述目标业务订单进行跑批处理，以获取每个所述目标业务订单的业务询价单。

在一个实施例中，跑批模块201还用于：

对每个所述业务询价单的预设位置的字段数据进行核对校验；和/或

对每个所述业务询价单中的险种信息进行核对校验；和/或

对每个业务询价单中的承保报价方案信息进行核对校验。

在一个实施例中，报价模块202还用于：

获取所述业务询价单对应的险种信息；

根据所述险种信息，从模型数据库中调用预先训练好的险种定价模型；

根据多个所述报价因子数据，生成所述业务询价单的特征向量；

将所述特征向量输入至所述险种定价模型进行处理，得到所述业务询价单对应的预报价。

在一个实施例中，询价模块203还用于：

生成每个所述目标询价单的确认链接，并确定每个所述目标询价单对应的移动端；

将每个所述目标询价单的确认链接发送至各自对应的移动端，以供每个所述移动端通过所述确认链接，生成所述目标询价单的确认信息。

在一个实施例中，生成模块204还用于：

从所述确认信息中获取签名信息，其中，所述签名信息是客户在签字确认页面中输入的，所述签字确认页面是客户触发所述确认链接后生成的；

确定所述确认信息对应的目标询价单的目标区域，所述目标区域为待合成所述签名信息的区域；

在所述目标区域内对所述签名信息进行签名合成，得到带有客户签名的业务订单。

需要说明的是，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的装置和各模块及单元的具体工作过程，可以参考前述业务订单生成方法实施例中的对应过程，在此不再赘述。

上述实施例提供的装置可以实现为一种计算机程序的形式，该计算机程序可以在如图6所示的服务器上运行。

请参阅图6，图6为本申请实施例提供的一种服务器的结构示意性框图。

如图6所示，该服务器包括通过系统总线连接的处理器、存储器和网络接口，其中，存储器可以包括存储介质和内存储器，存储介质可以是非易失性的，也可以是易失性的。

存储介质可存储操作系统和计算机程序。该计算机程序包括程序指令，该程序指令被执行时，可使得处理器执行任意一种业务订单生成方法。

处理器用于提供计算和控制能力，支撑整个服务器的运行。

内存储器为存储介质中的计算机程序的运行提供环境，该计算机程序被处理器执行时，可使得处理器执行任意一种业务订单生成方法。

该网络接口用于进行网络通信，如发送分配的任务等。本领域技术人员可以理解，图6中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的服务器的限定，具体的服务器可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

应当理解的是，处理器可以是中央处理单元(Central Processing Unit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。其中，通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

其中，在一个实施例中，所述处理器用于运行存储在存储器中的计算机程序，以实现如下步骤：

获取多个历史业务订单，并根据预设的业务询价规则跑批多个所述历史业务订单，生成每个所述历史业务订单对应的业务询价单；

从每个所述业务询价单中获取多个报价因子数据，并根据多个所述报价因子数据，确定每个所述业务询价单对应的预报价；

根据多个所述业务询价单和每个所述业务询价单对应的预报价，生成多个目标询价单；

获取移动端发送的确认信息，根据所述确认信息和所述确认信息对应的目标询价单，生成业务订单。

在一个实施例中，所述处理器在实现所述根据预设的业务询价规则跑批多个所述历史业务订单，生成每个所述历史业务订单对应的业务询价单时，用于实现：

从多个所述历史业务订单中剔除预设订单标识对应的失效订单，得到多个目标业务订单；

调用预设的业务询价接口，对多个所述目标业务订单进行跑批处理，生成每个所述目标业务订单的业务询价单；

对每个所述目标业务订单的业务询价单进行信息校验，并获取通过校验的业务询价单作为所述历史业务订单对应的业务询价单。

在一个实施例中，所述处理器在实现所述调用预设的业务询价接口，对多个所述目标业务订单进行跑批处理，生成每个所述目标业务订单的业务询价单时，用于实现：

获取所述服务器的当前吞吐量和/或当前时间信息；

在所述当前吞吐量小于等于预设吞吐量和/或所述当前时间信息处于预设时间范围内时，生成多个所述目标业务订单的跑批任务；

基于多个所述跑批任务，调用预设的业务询价接口对多个所述目标业务订单进行跑批处理，以获取每个所述目标业务订单的业务询价单。

在一个实施例中，所述处理器在实现所述对每个所述目标业务订单的业务询价单进行信息校验时，用于实现：

对每个所述业务询价单的预设位置的字段数据进行核对校验；和/或

对每个所述业务询价单中的险种信息进行核对校验；和/或

对每个业务询价单中的承保报价方案信息进行核对校验。

在一个实施例中，所述处理器在实现所述根据多个所述报价因子数据，确定每个所述业务询价单对应的预报价时，用于实现：

获取所述业务询价单对应的险种信息；

根据所述险种信息，从模型数据库中调用预先训练好的险种定价模型；

根据多个所述报价因子数据，生成所述业务询价单的特征向量；

将所述特征向量输入至所述险种定价模型进行处理，得到所述业务询价单对应的预报价。

在一个实施例中，所述处理器在实现所述获取移动端发送的确认信息之前，还用于实现：

生成每个所述目标询价单的确认链接，并确定每个所述目标询价单对应的移动端；

将每个所述目标询价单的确认链接发送至各自对应的移动端，以供每个所述移动端通过所述确认链接，生成所述目标询价单的确认信息。

在一个实施例中，所述处理器在实现所述根据所述确认信息和所述确认信息对应的目标询价单，生成业务订单时，用于实现：

从所述确认信息中获取签名信息，其中，所述签名信息是客户在签字确认页面中输入的，所述签字确认页面是客户触发所述确认链接后生成的；

确定所述确认信息对应的目标询价单的目标区域，所述目标区域为待合成所述签名信息的区域；

在所述目标区域内对所述签名信息进行签名合成，得到带有客户签名的业务订单。

需要说明的是，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述服务器的具体工作过程，可以参考前述业务订单生成方法实施例中的对应过程，在此不再赘述。

本申请可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序中包括程序指令，所述程序指令被执行时所实现的方法可参照本申请业务订单生成方法的各个实施例。

其中，所述计算机可读存储介质可以是前述实施例所述的服务器的内部存储单元，例如所述服务器的硬盘或内存。所述计算机可读存储介质也可以是所述服务器的外部存储设备，例如所述服务器上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。

应当理解，在此本申请说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本申请。如在本申请说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种业务订单生成方法，其特征在于，应用于服务器，所述方法包括：

获取多个历史业务订单，并根据预设的业务询价规则跑批多个所述历史业务订单，生成每个所述历史业务订单对应的业务询价单；

从每个所述业务询价单中获取多个报价因子数据，并根据多个所述报价因子数据，确定每个所述业务询价单对应的预报价；

根据多个所述业务询价单和每个所述业务询价单对应的预报价，生成多个目标询价单；

获取移动端发送的确认信息，根据所述确认信息和所述确认信息对应的目标询价单，生成业务订单。

2.如权利要求1所述的业务订单生成方法，其特征在于，所述根据预设的业务询价规则跑批多个所述历史业务订单，生成每个所述历史业务订单对应的业务询价单，包括：

从多个所述历史业务订单中剔除预设订单标识对应的失效订单，得到多个目标业务订单；

调用预设的业务询价接口，对多个所述目标业务订单进行跑批处理，生成每个所述目标业务订单的业务询价单；

对每个所述目标业务订单的业务询价单进行信息校验，并获取通过校验的业务询价单作为所述历史业务订单对应的业务询价单。

3.如权利要求2所述的业务订单生成方法，其特征在于，所述调用预设的业务询价接口，对多个所述目标业务订单进行跑批处理，生成每个所述目标业务订单的业务询价单，包括：

获取所述服务器的当前吞吐量和/或当前时间信息；

在所述当前吞吐量小于等于预设吞吐量和/或所述当前时间信息处于预设时间范围内时，生成多个所述目标业务订单的跑批任务；

基于多个所述跑批任务，调用预设的业务询价接口对多个所述目标业务订单进行跑批处理，以获取每个所述目标业务订单的业务询价单。

4.如权利要求2所述的业务订单生成方法，其特征在于，所述对每个所述目标业务订单的业务询价单进行信息校验，包括：

对每个所述业务询价单的预设位置的字段数据进行核对校验；和/或

对每个所述业务询价单中的险种信息进行核对校验；和/或

对每个业务询价单中的承保报价方案信息进行核对校验。

5.如权利要求1-4中任一项所述的业务订单生成方法，其特征在于，所述根据多个所述报价因子数据，确定每个所述业务询价单对应的预报价，包括：

获取所述业务询价单对应的险种信息；

根据所述险种信息，从模型数据库中调用预先训练好的险种定价模型；

根据多个所述报价因子数据，生成所述业务询价单的特征向量；

将所述特征向量输入至所述险种定价模型进行处理，得到所述业务询价单对应的预报价。

6.如权利要求1-4中任一项所述的业务订单生成方法，其特征在于，所述获取移动端发送的确认信息之前，还包括：

生成每个所述目标询价单的确认链接，并确定每个所述目标询价单对应的移动端；

将每个所述目标询价单的确认链接发送至各自对应的移动端，以供每个所述移动端通过所述确认链接，生成所述目标询价单的确认信息。

7.如权利要求6所述的业务订单生成方法，其特征在于，所述根据所述确认信息和所述确认信息对应的目标询价单，生成业务订单，包括：

从所述确认信息中获取签名信息，其中，所述签名信息是客户在签字确认页面中输入的，所述签字确认页面是客户触发所述确认链接后生成的；

确定所述确认信息对应的目标询价单的目标区域，所述目标区域为待合成所述签名信息的区域；

在所述目标区域内对所述签名信息进行签名合成，得到带有客户签名的业务订单。

8.一种业务订单生成装置，其特征在于，所述业务订单生成装置包括：

跑批模块，用于获取多个历史业务订单，并根据预设的业务询价规则跑批多个所述历史业务订单，生成每个所述历史业务订单对应的业务询价单；

报价模块，用于从每个所述业务询价单中获取多个报价因子数据，并根据多个所述报价因子数据，确定每个所述业务询价单对应的预报价；

询价模块，用于根据多个所述业务询价单和每个所述业务询价单对应的预报价，生成多个目标询价单；

生成模块，用于获取移动端发送的确认信息，根据所述确认信息和所述确认信息对应的目标询价单，生成业务订单。

9.一种服务器，其特征在于，所述服务器包括处理器、存储器、以及存储在所述存储器上并可被所述处理器执行的计算机程序，其中所述计算机程序被所述处理器执行时，实现如权利要求1至7中任一项所述的业务订单生成方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，其中所述计算机程序被处理器执行时，实现如权利要求1至7中任一项所述的业务订单生成方法的步骤。

Images