CN112465656A - 一种保险明细数据报送方法及装置 - Google Patents

Abstract

本说明书一个或多个实施例提供一种保险明细数据报送方法及装置，包括获取当日发生的所有保险业务数据；按照预定的交易逻辑规则，从中筛选出符合报送条件的保险业务数据；根据符合报送条件的保险业务数据，获取符合报送条件的保险业务数据所对应的保险明细数据；按照预定的分类标准，将保险明细数据划分为不同维度的保险明细数据；按照预定的数据转换规则，将各维度的保险明细数据转换为符合数据规则的保险明细数据，得到不同维度的符合数据规则的保险明细数据；按照预定的校验规则，对各维度的符合数据规则的保险明细数据进行校验；报送校验通过的保险明细数据。通过对保险明细数据进行统一的规范化处理，能够得到向报送机构上报的保险明细数据。

Description

一种保险明细数据报送方法及装置

技术领域

本说明书一个或多个实施例涉及数据处理技术领域，尤其涉及一种保险明细数据报送方法及装置。

背景技术

目前，各保险公司需要将当日发生的所有保险明细数据报送至保监会、中保信等报送机构，以便于各监管部门进行监管。同一保险公司的保险明细数据一般来源于不同保险机构、不同保险系统，数据类型多样，标准不一，在报送之前需要将所有保险明细数据进行统一的规范化处理，再将符合报送规范的保险明细数据上报。

发明内容

有鉴于此，本说明书一个或多个实施例的目的在于提出一种保险明细数据报送方法及装置，以解决保险明细数据的统一规范化处理问题。

基于上述目的，本说明书一个或多个实施例提供了一种保险明细数据报送方法，包括：

获取当日发生的所有保险业务数据；

按照预定的交易逻辑规则，从所有保险业务数据中筛选出符合报送条件的保险业务数据；

根据所述符合报送条件的保险业务数据，获取所述符合报送条件的保险业务数据所对应的保险明细数据；

按照预定的分类标准，将所述保险明细数据划分为不同维度的保险明细数据；

按照预定的数据转换规则，将各维度的保险明细数据转换为符合数据规则的保险明细数据，得到不同维度的符合数据规则的保险明细数据；

按照预定的校验规则，对各维度的符合数据规则的保险明细数据进行校验；

报送校验通过的保险明细数据。

可选的，所述交易逻辑规则包括新单逻辑规则、赔付逻辑规则、续保逻辑规则和再保逻辑规则，

按照预定的交易逻辑规则，从所有保险业务数据中筛选出符合报送条件的保险业务数据，包括：

按照新单逻辑规则、赔付逻辑规则、续保逻辑规则和再保逻辑规则，从所有保险业务数据中筛选出符合新单报送条件、赔付报送条件、续保报送条件和再保报送条件的保险业务数据。

可选的，按照预定的分类标准，将所述保险明细数据划分为不同维度的保险明细数据，包括：

按照保单、用户信息、理赔、保费、再保类别，将所述保险明细数据划分为保单维度的保险明细数据、用户信息维度的保险明细数据、理赔维度的保险明细数据、保费维度的保险明细数据、再保维度的保险明细数据。

可选的，所述按照预定的交易逻辑规则，从所有保险业务数据中筛选出符合报送条件的保险业务数据之后，还包括：

为符合报送条件的保险业务数据分配标识号；

所述按照预定的校验规则，对各维度的符合数据规则的保险明细数据进行校验之后，还包括：

如果存在校验未通过的保险明细数据，生成校验统计明细表，所述校验统计明细表包括所有校验未通过的保险明细数据及其对应的标识号、存在缺陷；

根据所述校验统计明细表，对校验未通过的保险明细数据进行修复，得到校验通过的保险明细数据。

可选的，所述报送校验通过的保险明细数据，包括：

导出包括所述校验通过的保险明细数据的上报文件；

对所述上报文件进行压缩处理，得到压缩后的上报文件；

发送所述压缩后的上报文件；

发送所述压缩后的上报文件已上传的通知报文。

可选的，所述通知报文包括保险公司标识、批次号和日期，所述批次号根据所述压缩后的上报文件生成。

可选的，发送所述压缩后的上报文件已上传的通知报文之后，还包括：

接收通知反馈报文；

从所述通知反馈报文中解析出上报查询码；

根据所述上报查询码，查询所述压缩后的上报文件的上报状态；

当根据所述上报状态判断所述压缩后的上报文件未成功上报时，根据所述上报状态确定未成功上报的原因；

根据所述未成功上报的原因，对所述压缩后的上报文件进行修复，得到修复后的上报文件；

报送所述修复后的上报文件。

可选的，根据所述上报查询码，查询所述压缩后的上报文件的上报状态之后，还包括：

当根据所述上报状态判断所述压缩后的上报文件已成功上报后，接收对账反馈报文；

从所述对账反馈报文中解析出对账查询码；

根据所述对账查询码，查询所述压缩后的上报文件的对账信息。

可选的，所述方法还包括：

创建日志文件，所述日志文件用于记录所述保险明细数据在每个处理阶段的处理状态。

本说明书实施例还提供一种保险明细数据报送装置，包括：

业务数据获取模块，用于获取当日发生的所有保险业务数据；

筛选模块，用于按照预定的交易逻辑规则，从所有保险业务数据中筛选出符合报送条件的保险业务数据；

明细数据获取模块，用于根据所述符合报送条件的保险业务数据，获取所述符合报送条件的保险业务数据所对应的保险明细数据；

分类模块，用于按照预定的分类标准，将所述保险明细数据划分为不同维度的保险明细数据；

转换模块，用于按照预定的数据转换规则，将各维度的保险明细数据转换为符合数据规则的保险明细数据，得到不同维度的符合数据规则的保险明细数据；

校验模块，用于按照预定的校验规则，对各维度的符合数据规则的保险明细数据进行校验；

报送模块，用于报送校验通过的保险明细数据。

从上面所述可以看出，本说明书一个或多个实施例提供的保险明细数据报送方法及装置，通过获取当日发生的所有保险业务数据，按照预定的交易逻辑规则，从所有保险业务数据中筛选出符合报送条件的保险业务数据，根据符合报送条件的保险业务数据，获取符合报送条件的保险业务数据所对应的保险明细数据，按照预定的分类标准，将保险明细数据划分为不同维度的保险明细数据，按照预定的数据转换规则，将各维度的保险明细数据转换为符合数据规则的保险明细数据，得到不同维度的符合数据规则的保险明细数据，按照预定的校验规则，对各维度的符合数据规则的保险明细数据进行校验，报送校验通过的保险明细数据。本实施例通过对当日发生的且需要上报的保险明细数据进行统一的规范化处理，得到能够向报送机构上报的保险明细数据。

附图说明

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

图1为本说明书一个或多个实施例的方法流程示意图；

图2为本说明书一个或多个实施例的装置结构示意图；

图3为本说明书一个或多个实施例的电子设备结构示意图。

具体实施方式

为使本公开的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本公开进一步详细说明。

需要说明的是，除非另外定义，本说明书一个或多个实施例使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。本说明书一个或多个实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系，当被描述对象的绝对位置改变后，则该相对位置关系也可能相应地改变。

如图1所示，本说明书一个或多个实施例提供一种保险明细数据报送方法，包括：

S101：获取当日发生的所有保险业务数据；

本实施例中，保险公司每日发生的保险明细数据都需要上报至报送机构。保险公司分为多个保险机构，例如河北分公司、山东分公司等，各保险机构维护各自的保险系统，按照保险类别，可分为长险系统、短险系统、分红险系统、万能险系统等；这样，保险公司当日发生的保险业务数据包括所有保险机构的所有保险系统中的保险业务数据。

一些实施例中，从每个保险机构的每个保险系统所获取的保险业务数据为能够表示所发生的保险业务的索引数据，保险业务数据包括保单号、保险类型、用户信息(包括投保人姓名、身份证号、被保人姓名等)、机构标识(保险机构的标识号)、业务类型(新单、赔付、续保、再保等)、缴费信息等数据项。

S102：按照预定的交易逻辑规则，从所有保险业务数据中筛选出符合报送条件的保险业务数据；

本实施例中，获取所有的保险业务数据之后，按照交易逻辑规则，筛选出需要上报的保险业务数据。即，并不是当日发生的所有保险业务数据都需要上报，只有符合报送条件的保险业务数据需要上报。

S103：根据符合报送条件的保险业务数据，获取符合报送条件的保险业务数据所对应的保险明细数据；

本实施例中，从所有保险业务数据中筛选出需要上报的保险业务数据之后，基于筛选出的保险业务数据，进一步从保险业务数据的数据源获取对应的保险明细数据。其中，保险明细数据是保险业务的所有相关数据项，保险明细数据在包括保险业务数据的基础上，还包括保单明细信息(生效日期、保单状态等)、用户明细信息(投保人住址、职业、家庭情况等，被保人年龄、身体状况、职业等)、财务明细信息(保费金额、应交保费、实收保费、已缴期数、现金价值、保费成本等)等数据项。

例如，经筛选，来自河北分公司的长险系统的一条保险业务数据需要上报，根据该条保险业务数据，从河北分公司的长险系统中获取有关该条保险业务数据的所有相关数据项作为对应于该条保险业务数据的保险明细数据。

S104：按照预定的分类标准，将保险明细数据划分为不同维度的保险明细数据；

本实施例中，获取所有需要上报的保险明细数据之后，按照预定分类标准对所有保险明细数据进行分类，将需要上报的保险明细数据整理成从不同维度划分的保险明细数据。

S105：按照预定的数据转换规则，将各维度的保险明细数据转换为符合数据规则的保险明细数据，得到不同维度的符合数据规则的保险明细数据；

本实施例中，将所有需要上报的保险明细数据整理为不同维度的保险明细数据之后，将所有保险明细数据转换为符合数据规则的保险明细数据。一些方式中，保险明细数据来自不同保险机构的不同保险系统，各保险系统的保险明细数据的数据标准不统一，因此，对于需要上报的保险明细数据，需要按照报送机构规定的数据格式，将保险明细数据中的每个数据项转换为符合数据规则的数据项，以满足数据上报的格式要求。其中，数据转换规则是根据保险明细数据的数据格式与报送机构规定的数据格式确定的，包括保险明细数据中的数据项与报送机构规定的对应数据项的转换关系。

例如，长险系统中记录的用户信息中，性别为女性的数据项记录为“女”，性别为男性的数据项记录为“男”，报送机构规定的性别为女性的数据格式为“F”，性别为男性的数据格式为“M”，则进行数据转换时，将“女”转换为“F”，将“男”转换为“M”。以上仅做示例性说明，不作为具体限定。

S106：按照预定的校验规则，对各维度的符合数据规则的保险明细数据进行校验；

S107：报送校验通过的保险明细数据。

本实施例中，对保险明细数据进行数据格式转换后，得到数据格式统一的保险明细数据。在上报之前，还需要对符合数据规则的保险明细数据进行校验，将校验通过的保险明细数据上报。

其中，对保险明细数据进行校验包括：对每条保险明细数据的每个数据项进行数据格式校验，判断数据项的数据格式是否符合报送机构的对应数据项的数据格式；判断每条保险明细数据的数据项是否完整；判断筛选出的需要上报的保险明细数据的数量是否与符合数据规则的保险明细数据的数量一致等。经过校验后，将数据格式符合报送机构的数据格式要求、数据项完整且保险明细数据完整的所有保险明细数据上报至报送机构。

一些方式中，由于各保险系统维护各自的保险明细数据，因而从各保险系统获取的保险明细数据的数据项可能存在不完整的情况，例如，长险系统中保存的某条保险明细数据中未记录投保人的身份证号，在对该条保险明细数据进行校验时，确定该条保险明细数据不存在投保人的身份证号，则该条保险明细数据校验未通过，不进行上报。后续，将该条保险明细数据的身份证号数据项补充完整后，校验通过后可以上报。

另一些方式中，通过筛选确定当日需要上报的保险明细数据的数量为1000条，经过校验后，确定符合数据规则的保险明细数据的数量小于1000条，则在数据处理过程中，部分保险明细数据丢失，则保险明细数据校验未通过，不进行上报。后续，定位出丢失的保险明细数据后，对完整的保险明细数据进行校验通过后，可以上报。

本实施例提供的保险明细数据报送方法，包括获取当日发生的所有保险业务数据；按照预定的交易逻辑规则，从所有保险业务数据中筛选出符合报送条件的保险业务数据；根据符合报送条件的保险业务数据，获取符合报送条件的保险业务数据所对应的保险明细数据；按照预定的分类标准，将保险明细数据划分为不同维度的保险明细数据；按照预定的数据转换规则，将各维度的保险明细数据转换为符合数据规则的保险明细数据，得到不同维度的符合数据规则的保险明细数据；按照预定的校验规则，对各维度的符合数据规则的保险明细数据进行校验；报送校验通过的保险明细数据。通过对当日发生的且需要上报的保险明细数据进行统一的规范化处理，得到能够向报送机构上报的保险明细数据。

一些实施例中，交易逻辑规则包括新单逻辑规则、赔付逻辑规则、续保逻辑规则和再保逻辑规则，

按照预定的交易逻辑规则，从所有保险业务数据中筛选出符合报送条件的保险业务数据，包括：

按照新单逻辑规则、赔付逻辑规则、续保逻辑规则和再保逻辑规则，从所有保险业务数据中筛选出符合新单报送条件、赔付报送条件、续保报送条件和再保报送条件的保险业务数据。

本实施例中，在所有保险业务数据中，符合新单报送条件的保险明细数据需要上报，符合赔付报送条件的保险明细数据需要上报，符合续保报送条件的保险明细数据需要上报，符合再保报送条件的保险明细数据需要上报。对于每一条保险业务数据，判定是否符合新单逻辑规则、赔付逻辑规则、续保逻辑规则或再保逻辑规则，若符合其中的一种规则，则该条保险业务数据需要上报。例如，根据一条保险业务数据的保单信息和财务信息，按照新单逻辑规则判定该保单的保单相关信息已经录入，新保单已经生成，但是尚未缴纳保费，则判断该条保险业务数据不符合新单报送条件，无需上报；根据一条保险业务数据的理赔信息和财务信息，按照赔付逻辑规则判断该保单已报案，材料正在审核阶段，尚未赔付，则判断该条保险业务数据不符合赔付报送条件，无需上报。以上仅为示例性说明，具体的交易逻辑规则和需要上报的保险明细数据可根据保险公司内部的交易处理流程和报送机构的规定确定，本实施例不做具体限定。

一些实施例中，按照预定的分类标准，将保险明细数据划分为不同维度的保险明细数据，包括：

按照保单、用户信息、理赔、保费、再保类别，将保险明细数据划分为保单维度的保险明细数据、用户信息维度的保险明细数据、理赔维度的保险明细数据、保费维度的保险明细数据、再保维度的保险明细数据。

本实施例中，基于筛选出的需要上报的保险业务数据，从保险业务数据的数据源获取对应的保险明细数据之后，将所有保险明细数据按照不同的分类标准划分为不同维度的保险明细数据，方便按照不同维度查阅、统计分析保险明细数据。

一些方式中，可将所有保险明细数据划分为保单维度的保险明细数据、用户信息的保险明细数据、理赔维度的保险明细数据、保费维度的保险明细数据、再保维度的保险明细数据。例如，将符合赔付报送条件的所有保险明细数据归为一类，得到理赔维度的保险明细数据；将涉及保费的保险明细数据归为一类，得到保费维度的保险明细数据；将涉及所有保险类型的保单的保险明细数据归为一类，得到保单维度的保险明细数据；按照用户信息将保险明细数据归为一类，得到用户信息维度的保险明细数据等。以上仅为示例性说明，保险明细数据的分类可以按照报送机构的需求进行确定划分，本实施例不做具体限定。

一些实施例中，按照预定的交易逻辑规则，从所有保险业务数据中筛选出符合报送条件的保险业务数据之后，还包括：

为符合报送条件的保险业务数据分配标识号；

则，按照预定的校验规则，对各维度的符合数据规则的保险明细数据进行校验之后，还包括：

如果存在校验未通过的保险明细数据，生成校验统计明细表，校验统计明细表包括所有校验未通过的保险明细数据及其对应的标识号、存在缺陷；

根据校验统计明细表，对校验未通过的保险明细数据进行修复，得到校验通过的保险明细数据。

本实施例中，筛选出需要上报的保险业务数据之后，对每一条保险业务数据分配唯一的标识号，所获取的与保险业务数据对应的保险明细数据具有一致的标识号，这样，在后续的数据处理过程中，方便对每一条保险明细数据进行跟踪。在上报前的校验过程中，当存在校验未通过的保险明细数据时，可根据校验未通过的保险明细数据，生成校验统计明细表，利用校验统计明细表，可确定出存在缺陷的保险明细数据，并根据存在缺陷的保险明细数据的标识号，快速定位出导致缺陷的原因，进而快速解决缺陷问题，提高效率。

一些实施例中，报送校验通过的保险明细数据，包括：

导出包括校验通过的保险明细数据的上报文件；

对上报文件进行压缩处理，得到压缩后的上报文件；

发送压缩后的上报文件；

发送压缩后的上报文件已上传的通知报文。

本实施例中，报送保险明细数据时，先导出包括所有校验通过的保险明细数据的上报文件，如果保险明细数据的数量较小，可将所有保险明细数据列入一个上报文件导出，如果保险明细数据的数量较大，可将所有保险明细数据分别列入多个上报文件，分别导出多个上报文件，也可以是，按照维度划分后的保险明细数据，将各维度的保险明细数据分别列入对应的上报文件中，分别导出，文件导出的形式不做具体限定。导出上报文件之后，将上报文件进行压缩处理，得到适于上传的压缩后的上报文件，然后将压缩后的上报文件发送至报送机构，发送之后，还需要向报送机构发送预定格式的通知报文，用于通知报送机构，当日的保险明细数据已经报送。

一些方式中，向报送机构发送的通知报文包括保险公司标识、批次号和日期等信息，其中，批次号可基于压缩后的上报文件生成，用于标识所上报的保险明细数据的批次。报送机构接收到通知报文之后，接收压缩后的上报文件，对压缩后的上报文件进行解压，然后对解压后的上报文件进行核验，核验之后向保险公司发送核验通过或未通过的通知反馈报文。

一些实施例中，发送压缩后的上报文件已上传的通知报文之后，还包括：

接收通知反馈报文；

从通知反馈报文中解析出上报查询码；

根据上报查询码，查询压缩后的上报文件的上报状态；

当根据上报状态判断压缩后的上报文件未成功上报时，根据上报状态确定未成功上报的原因；

根据未成功上报的原因，对压缩后的上报文件进行修复，得到修复后的上报文件；

报送修复后的上报文件。

本实施例中，报送机构对上报的上报文件中的保险明细数据进行核验之后，向保险公司发送通知反馈报文，该通知反馈报文中携带了用于查询核验结果的上报查询码。接收通知反馈报文之后，从中解析出上报查询码，利用上报查询码查询上报的保险明细数据是否核验通过，如果核验通过，则本批次的保险明细数据成功上报，如果核验未通过，则本批次的保险明细数据未成功上报，可根据核验结果查询未成功上报的原因，后续根据未成功上报的原因有针对性的对压缩后的上报文件进行修复，修复缺陷后，重新上报修复后的上报文件。

一些实施例中，根据上报查询码，查询压缩后的上报文件的上报状态之后，还包括：

当根据上报状态判断压缩后的上报文件已成功上报后，接收对账反馈报文；

从对账反馈报文中解析出对账查询码；

根据对账查询码，查询压缩后的上报文件的对账信息。

本实施例中，如果报送机构对上报的保险明细数据核验通过，则本批次的保险明细数据成功上报，报送机构会对上报的保险明细数据进行对账，并在对账之后向保险公司发送对账反馈报文。保险公司接收对账反馈报文，从对账反馈报文中解析出对账查询码，利用对账查询码查询对账结果，后续可根据对账结果更新本批次报送的保险明细数据的财务状态。

一些方式中，发送的通知报文中的信息可以为密文形式，接收的通知反馈报文、对账反馈报文中的信息也可以是密文形式。保险公司与报送机构在通信之前，可以预先协商用于加密、解密密文形式的信息的加密密钥，或者以公钥、私钥形式对双方交互的密文形式的信息进行加密、解密处理，以提高数据安全性。

一些实施例中，保险明细数据报送方法还包括：

创建日志文件，用于记录保险明细数据在每个处理阶段的处理状态。

本实施例中，在获取当前发生的保险业务数据之前，先进行预处理，创建用于记录保险明细数据在每个处理阶段的处理状态的日志文件，便于追踪每一条保险明细数据的处理流程。例如，按照时间顺序，日志文件记录有所获取的所有保险业务数据，经过筛选后得到的保险业务数据及对应的处理状态(需要上报的保险业务数据的处理状态为需要上报，不需要上报的保险业务数据的处理状态为不需要上报)，对于需要上报的保险业务数据记录有所分配的标识号；获取的保险明细数据及对应的标识号；分类处理后的保险明细数据所属的维度；数据转换后的保险明细数据的处理状态(包括哪些数据项进行了数据转换，转换前的数据项及转换后的数据项)；校验后的保险明细数据的处理状态(校验通过或者校验未通过)；保险明细数据的导出状态(已导出或者未导出)；保险明细数据的发送状态(已发送及对应的批次号或者未发送)；保险明细数据的核验状态(核验通过或者核验未通过)；保险明细数据的对账状态(已对账或者未对账)等。

本实施例提供的保险明细数据报送方法，对于保险公司当天发生的保险业务数据，通过进行筛选确定出需要上报的保险业务数据，再获取需要上报的保险业务数据所对应的保险明细数据，对需要上报的保险明细数据进行分类、数据转换及校验等一系列统一的规范化处理，最终得到校验通过后可以上报至报送机构的保险明细数据，能够实现保险明细数据的统一处理及上报，达到报送机构的报送要求。

需要说明的是，本说明书一个或多个实施例的方法可以由单个设备执行，例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下，由多台设备相互配合来完成。在这种分布式场景的情况下，这多台设备中的一台设备可以只执行本说明书一个或多个实施例的方法中的某一个或多个步骤，这多台设备相互之间会进行交互以完成所述的方法。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

如图2所示，本说明书实施例还提供一种保险明细数据报送装置，包括：

业务数据获取模块，用于获取当日发生的所有保险业务数据；

筛选模块，用于按照预定的交易逻辑规则，从所有保险业务数据中筛选出符合报送条件的保险业务数据；

明细数据获取模块，用于根据符合报送条件的保险业务数据，获取符合报送条件的保险业务数据所对应的保险明细数据；

分类模块，用于按照预定的分类标准，将保险明细数据划分为不同维度的保险明细数据；

转换模块，用于按照预定的数据转换规则，将各维度的保险明细数据转换为符合数据规则的保险明细数据，得到不同维度的符合数据规则的保险明细数据；

校验模块，用于按照预定的校验规则，对各维度的符合数据规则的保险明细数据进行校验；

报送模块，用于报送校验通过的保险明细数据。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现。

上述实施例的装置用于实现前述实施例中相应的方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

图3示出了本实施例所提供的一种更为具体的电子设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。

处理器1010可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器1020可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。

输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

本实施例的计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本公开的范围(包括权利要求)被限于这些例子；在本公开的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本说明书一个或多个实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。

另外，为简化说明和讨论，并且为了不会使本说明书一个或多个实施例难以理解，在所提供的附图中可以示出或可以不示出与集成电路(IC)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本说明书一个或多个实施例难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本说明书一个或多个实施例的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本公开的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本说明书一个或多个实施例。因此，这些描述应被认为是说明性的而不是限制性的。

尽管已经结合了本公开的具体实施例对本公开进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态RAM(DRAM))可以使用所讨论的实施例。

本说明书一个或多个实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本公开的保护范围之内。

Claims (10)

1.一种保险明细数据报送方法，其特征在于，包括：

获取当日发生的所有保险业务数据；

按照预定的交易逻辑规则，从所有保险业务数据中筛选出符合报送条件的保险业务数据；

根据所述符合报送条件的保险业务数据，获取所述符合报送条件的保险业务数据所对应的保险明细数据；

按照预定的分类标准，将所述保险明细数据划分为不同维度的保险明细数据；

按照预定的数据转换规则，将各维度的保险明细数据转换为符合数据规则的保险明细数据，得到不同维度的符合数据规则的保险明细数据；

按照预定的校验规则，对各维度的符合数据规则的保险明细数据进行校验；

报送校验通过的保险明细数据。

2.根据权利要求1所述的方法，其特征在于，所述交易逻辑规则包括新单逻辑规则、赔付逻辑规则、续保逻辑规则和再保逻辑规则，

按照预定的交易逻辑规则，从所有保险业务数据中筛选出符合报送条件的保险业务数据，包括：

按照新单逻辑规则、赔付逻辑规则、续保逻辑规则和再保逻辑规则，从所有保险业务数据中筛选出符合新单报送条件、赔付报送条件、续保报送条件和再保报送条件的保险业务数据。

3.根据权利要求1所述的方法，其特征在于，按照预定的分类标准，将所述保险明细数据划分为不同维度的保险明细数据，包括：

按照保单、用户信息、理赔、保费、再保类别，将所述保险明细数据划分为保单维度的保险明细数据、用户信息维度的保险明细数据、理赔维度的保险明细数据、保费维度的保险明细数据、再保维度的保险明细数据。

4.根据权利要求1所述的方法，其特征在于，所述按照预定的交易逻辑规则，从所有保险业务数据中筛选出符合报送条件的保险业务数据之后，还包括：

为符合报送条件的保险业务数据分配标识号；

所述按照预定的校验规则，对各维度的符合数据规则的保险明细数据进行校验之后，还包括：

如果存在校验未通过的保险明细数据，生成校验统计明细表，所述校验统计明细表包括所有校验未通过的保险明细数据及其对应的标识号、存在缺陷；

根据所述校验统计明细表，对校验未通过的保险明细数据进行修复，得到校验通过的保险明细数据。

5.根据权利要求1所述的方法，其特征在于，所述报送校验通过的保险明细数据，包括：

导出包括所述校验通过的保险明细数据的上报文件；

对所述上报文件进行压缩处理，得到压缩后的上报文件；

发送所述压缩后的上报文件；

发送所述压缩后的上报文件已上传的通知报文。

6.根据权利要求5所述的方法，其特征在于，所述通知报文包括保险公司标识、批次号和日期，所述批次号根据所述压缩后的上报文件生成。

7.根据权利要求5或6所述的方法，其特征在于，发送所述压缩后的上报文件已上传的通知报文之后，还包括：

接收通知反馈报文；

从所述通知反馈报文中解析出上报查询码；

根据所述上报查询码，查询所述压缩后的上报文件的上报状态；

当根据所述上报状态判断所述压缩后的上报文件未成功上报时，根据所述上报状态确定未成功上报的原因；

根据所述未成功上报的原因，对所述压缩后的上报文件进行修复，得到修复后的上报文件；

报送所述修复后的上报文件。

8.根据权利要求7所述的方法，其特征在于，根据所述上报查询码，查询所述压缩后的上报文件的上报状态之后，还包括：

当根据所述上报状态判断所述压缩后的上报文件已成功上报后，接收对账反馈报文；

从所述对账反馈报文中解析出对账查询码；

根据所述对账查询码，查询所述压缩后的上报文件的对账信息。

9.根据权利要求1-8中任意一项所述的方法，其特征在于，还包括：

创建日志文件，所述日志文件用于记录所述保险明细数据在每个处理阶段的处理状态。

10.一种保险明细数据报送装置，其特征在于，包括：

业务数据获取模块，用于获取当日发生的所有保险业务数据；

筛选模块，用于按照预定的交易逻辑规则，从所有保险业务数据中筛选出符合报送条件的保险业务数据；

明细数据获取模块，用于根据所述符合报送条件的保险业务数据，获取所述符合报送条件的保险业务数据所对应的保险明细数据；

分类模块，用于按照预定的分类标准，将所述保险明细数据划分为不同维度的保险明细数据；

转换模块，用于按照预定的数据转换规则，将各维度的保险明细数据转换为符合数据规则的保险明细数据，得到不同维度的符合数据规则的保险明细数据；

校验模块，用于按照预定的校验规则，对各维度的符合数据规则的保险明细数据进行校验；

报送模块，用于报送校验通过的保险明细数据。

Images