CN115907917A - 一种业务数据处理方法、装置及计算机可读介质 - Google Patents

Abstract

本申请公开一种业务数据处理方法、装置及计算机可读介质，该方法包括：确定结算业务涉及的各类型业务数据分别对应的数据状态信息；至少根据确定的数据状态信息，确定每一类型业务数据是否需参与当前轮结算处理中结算业务包含的各个子业务；若存在需参与当前轮结算处理的业务数据，根据结算业务包含的各个子业务分别对应的触发条件，确定当前需触发的目标子业务；获取需参与目标子业务的目标业务数据，并按目标子业务的处理逻辑对目标业务数据进行处理。本申请可避免不必要的数据重复参与到结算业务的业务处理中，通过控制各类型业务数据何时应该参与业务处理，何时不需要参与，保证最终数据的准确性，同时提升系统运算效率、降低系统的性能消耗。

Description

一种业务数据处理方法、装置及计算机可读介质

技术领域

本申请属于航空信息处理技术领域，尤其涉及一种业务数据处理方法、装置及计算机可读介质。

背景技术

航空公司收入结算业务，是航空公司确定收入的一项重要核心业务。其业务对应的结算系统处于整个业务链、数据链的中下游，负责处理上游系统和结算业务涉及的多方数据，基于这些数据，结算系统会进行复杂的运算，最终得到航空公司的待结算收入相关的数据。

在这个过程中，由于参与运算的数据源繁多，且数据质量、数据状态随业务的进行也在随时变化，而这诸多的变化都会触发结算系统中庞大数据的试算与运算，从而导致结算系统的运算工作量大、效率低且复杂度高。这些运算功能，在结算系统中由于其复杂度的原因，被设计为后台离线作业，作业过程也会占用极大的系统资源。

发明内容

有鉴于此，本申请提供一种业务数据处理方法、装置及计算机可读介质，用于解决现有技术存在的至少部分技术问题，提升系统运算效率、节约系统资源。

具体方案如下：

一种业务数据处理方法，包括：

确定结算业务涉及的各类型业务数据分别对应的数据状态信息；

至少根据各类型业务数据分别对应的数据状态信息，确定每一类型业务数据是否需参与当前轮结算处理中所述结算业务包含的各个子业务；

若存在需参与当前轮结算处理的业务数据，根据所述结算业务包含的各个子业务分别对应的触发条件，确定当前需触发的目标子业务；

获取需参与所述目标子业务的目标业务数据，并按所述目标子业务的处理逻辑对所述目标业务数据进行处理。

可选的，所述确定结算业务涉及的各类型业务数据分别对应的数据状态信息，包括：

获取各类型业务数据分别对应的用于票证状态管理的数据结构对象；

从对应的数据结构对象中读取相应类型业务数据的数据状态信息；

其中，所述用于票证状态管理的数据结构对象中，记录有用于表征对应类型业务数据的处理状态和状态变化轨迹的数据状态信息。

可选的，在所述确定结算业务涉及的各类型业务数据分别对应的数据状态信息之前，还包括：

基于创建的票证状态管理处理接口收集各类型业务数据的状态变化信息；

基于收集的状态变化信息，在相应类型业务数据对应的用于票证状态管理的数据结构对象中记录或更新该类型业务数据的数据状态信息。

可选的，所述至少根据各类型业务数据分别对应的数据状态信息，确定每一类型业务数据是否需参与当前轮结算处理中所述结算业务包含的各个子业务，包括：

根据所对应的数据状态信息，确定各类型业务数据在当前轮的时间周期内是否发生过状态变化；

根据各类型业务数据在当前轮的时间周期内是否发生过状态变化，各类型业务数据是否参与过所述结算业务包含的相应子业务，以及在参与过相应子业务的情况下所参与的子业务是否处理成功，确定每一类型业务数据是否需参与当前轮结算处理中所述结算业务包含的各个子业务。

可选的，所述根据所述结算业务包含的各个子业务分别对应的触发条件，确定当前需触发的目标子业务，包括：

按预设的子业务处理顺序，确定所述结算业务包含的各个子业务中待处理的下一子业务；

确定当前是否满足所述下一子业务对应的触发条件，若满足，确定所述下一子业务为当前需触发的目标子业务；

其中，各个子业务分别对应的触发条件，为与所对应业务数据的数据状态信息相关的条件。

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

确定所述结算业务包含的至少部分子业务的业务协议是否发生协议数据变更；

若发生变更，根据相应子业务的协议数据变更信息，确定相应类型业务数据应发生的同步变化，并基于所述相应类型业务数据应发生的同步变化，更新所述相应类型业务数据对应的用于票证状态管理的数据结构对象。

可选的，所述根据相应子业务的协议数据变更信息，确定相应类型业务数据应发生的同步变化，包括：

根据相应子业务的协议数据变更信息，确定修改前的协议所对应范围内的业务数据中与修改后的协议不匹配的第一数据，以及修改后的协议相比于修改前的协议需新增的第二数据。

可选的，所述各类型业务数据包括运输数据、销售数据、进港到付数据和对内开账数据中的至少部分类型数据；

所述结算业务包含的各个子业务包括运价计算、运输分摊、运输收入计算、票证监控中的至少部分子业务。

一种业务数据处理装置，包括：

第一确定单元，用于确定结算业务涉及的各类型业务数据分别对应的数据状态信息；

第二确定单元，用于至少根据各类型业务数据分别对应的数据状态信息，确定每一类型业务数据是否需参与当前轮结算处理中所述结算业务包含的各个子业务；

第三确定单元，用于若存在需参与当前轮结算处理的业务数据，根据所述结算业务包含的各个子业务分别对应的触发条件，确定当前需触发的目标子业务；

业务处理单元，用于获取需参与所述目标子业务的目标业务数据，并按所述目标子业务的处理逻辑对所述目标业务数据进行处理。

一种计算机可读介质，其上存储有计算机程序，所述计算机程序包含用于执行如上文任一项所述的方法的程序代码。

综上所述，本申请提供一种业务数据处理方法、装置及计算机可读介质，该方法包括：确定结算业务涉及的各类型业务数据分别对应的数据状态信息；至少根据各类型业务数据分别对应的数据状态信息，确定每一类型业务数据是否需参与当前轮结算处理中所述结算业务包含的各个子业务；若存在需参与当前轮结算处理的业务数据，根据所述结算业务包含的各个子业务分别对应的触发条件，确定当前需触发的目标子业务；获取需参与所述目标子业务的目标业务数据，并按所述目标子业务的处理逻辑对所述目标业务数据进行处理。

本申请通过上述处理，可避免不必要的数据重复参与到结算业务的业务处理中，只有需要参与相应子业务的数据部分，如发生了状态变化的数据，才会重新触发对应的子业务流程。通过控制各类型业务数据何时应该参与业务处理，何时不需要参与，保证最终数据的准确性，同时提升系统运算效率、降低系统的运算量及性能/资源消耗。

附图说明

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

图1是本申请提供的业务数据处理方法的流程示意图；

图2是本申请提供的票证状态管理在业务处理中的应用示意图；

图3是本申请提供的各类型业务数据的修改方式示意图；

图4是本申请提供的业务数据处理装置的组成结构图。

具体实施方式

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

申请人发现，货邮收入管理平台需要处理的数据，在每一个数据处理单元中，都满足完整性、有效性和准确性后，方能结束对该数据处理单元的处理操作。但这些数据处理单元在实际业务中发生的时间不同，进入系统处理的时间不同，而且在系统中可能需要处理多次后才能达到最终准确性的目标。在这种前提下，就导致了相同的、未发生变化的数据处理单元在系统内多次、重复的被计算、被处理，并且这些重复的处理后的结果也是不变的。这种多次的重复处理，会降低系统处理性能，浪费系统资源，同时存在运算工作量大、效率低且复杂度高等问题。

结算系统的使用用户，一般都是航空公司的财务部门或结算部门。由于涉及金额，所以系统对数据准确性的要求比较高。同时随着结算业务的发展，数据处理数量也在快速的增长，数据处理的时效性得到了更多的关注。在结算系统中，包含了大量运算的功能，其中比较重要的功能如：运价计算、分摊处理及票证监控功能，这些功能基本上是航空公司结算业务的核心业务处理。这些核心功能由于逻辑复杂，计算量大，目前均采用离线作业的处理方式。参与运算的数据源包括：结算数据处理单元、各种协议(运价协议、分摊协议、销售协议等)、基本信息(航班信息、地理信息等)；同时在业务处理流程中，还有很多控制点，能都使数据处理单元中涉及的数据发生变化，诸如：数据处理单元中数据的修改、对数据的调整、对数据的审核、对协议的变更与作废；另外数据处理单元在业务中的发生顺序，也会对最终结果产生影响。

结算业务对系统处理的这种高要求，加上数据处理单元和其他辅助数据的多变性，使得必须有一整套完整的机制来控制结算系统的核心处理功能。

为解决上述问题，本申请提供一种业务数据处理方法、装置及计算机可读介质，用于避免相同的数据处理单元，重复的参与计算和处理，降低数据数据单元的数据变化对整个数据链上各数据的影响，降低重复计算对系统资源的消耗，以达到提升系统处理效率，降低系统的运算量，节约系统资源的目的。

本申请所提供的业务数据处理方法，具体为基于票证状态管理的业务数据处理方法，将主要以面向航空公司结算的基于票证状态管理的业务数据处理为例进行说明。

为引用或清楚起见，首先将本申请实施例中涉及的技术术语、名词或英文缩写解释如下：

CMRM：是货邮收入管理平台的英文简称，英文全称为Cargo and Mail RevenueManagement system，可视为一种结算系统。

货单(AirWay Bill)：货邮运输的基本单据之一，是航空公司、代理人和货主之间的达成一致的运输和销售凭证。

舱单：航空公司运输的基本单据之一，记录了航空公司运输货单的内容。

转港舱单：如果发生联运，在各个航空公司之间单据流转的依据。

地面运输舱单：航空运输之外的地面运输凭证，目前主要指卡车运输。

数据处理单元：货邮收入管理平台所要处理的基本数据单元，按业务类型划分可分为：运输数据、销售数据、进港到付数据和对内开账数据。其中对应的基本业务单据包括：运输货单、运输舱单、运输转港舱单、地面运输舱单、销售货单、进港到付数据单据、对内开账数据单据。

计算逻辑单元：货邮收入管理平台中的重要计算逻辑功能，包含：运价计算引擎、运输分摊引擎、运输收入计算引擎、票证监控引擎。

参见图1所示的业务数据处理方法，本申请提供的业务数据处理方法包括以下处理过程：

步骤101、确定结算业务涉及的各类型业务数据分别对应的数据状态信息。

以航空公司的结算业务为例，各类型业务数据可以是指货邮收入管理平台所要处理的各种数据处理单元，即各种基本数据单元，如运输数据、销售数据、进港到付数据和对内开账数据等。

本申请实施例为各类型业务数据，如上述的各类基本数据单元，设计有多维度的数据结构的数据结构对象，用于记录各类型业务数据的相关属性信息，包括但不限于所属的业务单元、数据修改方式、计算逻辑单元之间的控制逻辑，以及数据处理逻辑的优先级等等，以用于票证状态管理，票证状态管理在业务处理中的应用示意图如图2所示。

数据结构对象的数据存储，可以采用多种方式进行持久化，包括但不限于内存对象、缓存、数据库等多种方式。

实际应用中，可基于面向对象技术，先为各类型业务数据创建票证状态管理的多维数据结构对象。并在结算系统如航空公司结算系统启动时，优先将票证状态管理的数据结构对象加载到服务器内存或缓存机制中。

与之相匹配，本申请实施例还根据各类型业务数据，如各类型数据处理单元中的各种数据修改方式，创建票证状态管理处理接口，供各个数据处理单元调用和处理，以此为基础实现在对应的数据结构对象中记录数据处理单元的时间与状态。有了数据处理单元的时间和状态，在票证状态管理中，就可以判断在计算逻辑单元触发计算时，对应数据处理单元是否应该参与或重新参与计算和处理。

值得说明，本申请实施例中，为简化描述，某些地方直接采用“数据处理单元”来指代上述的运输数据、销售数据、进港到付数据和对内开账数据等各类型业务数据，也即各类型基本数据单元，而在涉及到对这些数据的变更如增删改时，数据处理单元又可指代能用于基于对票证状态管理处理接口进行调用，而实现向数据结构对象进行状态信息记录的功能单元。

以航空公司的结算业务为例，本申请实施例将各类型业务数据所属的业务单元主要划分为：运输模块、销售模块、对内开账模块和进港到付模块，分别对应运输数据、销售数据、对内开账数据和进港到付数据。

该示例中，每个业务模块，分别对应有多种数据修改方式，也可理解为各类型数据处理单元的数据修改方式，如图3所示，分别如下：

运输数据：

添加、修改、删除运输货单；

添加、修改、删除运输舱单；

添加、修改、删除运输转港舱单；

添加、修改、删除运输地面运输舱单；

运输票证审核；

运输运价审核；

运输票证当月调整及跨期调整。

销售数据：

添加、修改、删除销售货单；

销售货单审核；

销售货单复审。

对内开账数据：

添加、修改、删除对内开账货单；

对内开账货单的审核与变更。

进港到付数据：

添加、修改、删除进港到付。

运价协议：

对协议信息进行签署、变更与发布；

运价计算对数据处理单元的修改。

运输分摊协议：

对协议信息进行签署、变更与发布；

修改分摊信息对数据处理单元造成的数据变更。

需要说明，运价协议属于运价协议模块，运输分摊协议属于运输分摊协议模块；这两个协议(模块)是“运价计算引擎”和“运输分摊引擎”数据处理单元的计算依据，有了依据(协议)、有了数据(运输、销售、对内开账、进港到付)就可以计算出结果，实现业务结算。

可选的，该示例中，将用于票证状态管理的多维数据结构对象，设计为多个属性，通过包含的属性，记录用于表征对应类型业务数据的处理状态和状态变化轨迹的数据状态信息，所包含的属性可以包括但不限于如下属性中的部分或全部：

a1)数据处理单元唯一标记；

其中，每条销售数据或运输数据、对内开账数据、进港到付数据都视为一个数据处理单元，并对应唯一标记，唯一标记具体可以为数据的ID或序号。

a2)销售数据处理状态；

如添加、修改、删除销售货单，销售货单审核，销售货单复审等状态。

a3)销售数据变更时间；

a4)运输数据处理状态；

如，“添加、修改及删除”运输货单、运输舱单、转港舱单、地面运输舱单，“票证监控”、“运价审核”、“当月调整和跨期调整”等。

a5)运输数据变更时间；

a6)对内开账数据处理状态；

a7)对内开账数据变更时间；

a8)进港到付处理状态；

a9)进港到付数据变更时间；

a10)运价计算处理状态；

a11)运价计算处理时间；

a12)运输分摊处理状态；

a13)运输分摊处理时间；

a14)运输入账数据处理状态；

a15)运输入账处理时间；

a16)票证监控数据处理状态；

a17)票证监控处理时间。

除了设计用于存储票证状态的多维数据结构对象的数据结构，还需要给各数据处理单元提供记录数据处理状态和处理时间的接口方法逻辑，即票证状态管理处理接口的接口方法逻辑，以用来收集数据的变化信息，为计算逻辑单元判断参与计算的数据范围提供数据依据。

该示例中，这些接口包含但不限于：

b1)获取票证管理状态的数据接口；

b2)销售数据变更接口；

b3)销售审核数据变更接口；

b4)销售复审数据变更接口；

b5)运输数据变更接口；

b6)运输舱单变更接口；

b7)运输运价审核数据变更接口；

b8)对内开账数据变更接口；

b9)进港到付数据变更接口；

b10)运价协议变更接口；

b11)分摊协议变更接口。

基于上述的处理，本申请实施例中，基于创建的票证状态管理处理接口收集各类型业务数据的状态变化信息，并基于收集的状态变化信息，在相应类型业务数据对应的用于票证状态管理的数据结构对象中记录或更新该类型业务数据的数据状态信息。

相应的，在此基础上，当需要确定结算业务涉及的各类型业务数据分别对应的数据状态信息时，具体可获取各类型业务数据分别对应的用于票证状态管理的数据结构对象，并从对应的数据结构对象中读取相应类型业务数据的数据状态信息。

步骤102、至少根据各类型业务数据分别对应的数据状态信息，确定每一类型业务数据是否需参与当前轮结算处理中所述结算业务包含的各个子业务。

可选的，具体可根据从用于票证状态管理的相应数据结构对象获取的数据状态信息，确定各类型业务数据在当前轮的时间周期内是否发生过状态变化；之后，根据各类型业务数据在当前轮的时间周期内是否发生过状态变化，各类型业务数据是否参与过所述结算业务包含的相应子业务，以及在参与过相应子业务的情况下所参与的子业务是否处理成功，确定每一类型业务数据是否需参与当前轮结算处理中所述结算业务包含的各个子业务。

当前轮的时间周期，可以理解为结算业务最近完成的一次处理与待触发的下一次处理之间所经历的时间，而这里的下一次处理，即可理解为当前轮计算处理，具体是当前轮待执行或待触发的结算处理。

以航空公司的结算业务为例，票证状态管理，主要控制的计算逻辑单元包含：运价计算引擎、运输分摊引擎、运输收入计算引擎和票证监控引擎。这些计算引擎，都是航空公司结算业务的核心数据处理操作。该示例中，结算业务包含的各个子业务，相应可以为上述各引擎分别提供的运价计算、运输分摊、运输收入计算和票证监控子业务。

仍以航空公司的结算业务为例，在基于用于票证状态管理的数据结构对象收集了系统中各业务数据的处理状态和变化轨迹信息(如处理状态和状态变化时间)后，本申请实施例以此为依据，判定各类型业务数据是否需参与当前轮结算处理中所述结算业务包含的各个子业务，如判断各数据处理单元(基本数据单元)是否需参与运价计算引擎、运输分摊引擎、运输收入计算引擎和票证监控引擎分别提供的子业务流程等。

以下提供一示例性判定逻辑：

c1)如果相关数据在当前轮的时间周期内没有发生过状态变化，也没有参与过相关子业务的计算流程，则可以参与该子业务的下次计算逻辑；

c2)如果相关数据在当前轮的时间周期内没有发生过状态变化，但已经参加过某子业务的相关计算，并且计算成功，则不需要参加该子业务的下次计算逻辑；

c3)如果相关数据在当前轮的时间周期内没有发生过状态变化，但最近一次参加过的子业务的相关计算失败了，则需要参与该子业务的下次计算逻辑；

c4)如果相关数据在当前轮的时间周期内发生过状态变化，不管最近一次参加过的子业务的相关计算是否成功或失败，则都需要参与该子业务的下次计算逻辑。

需要说明，子业务的下次计算逻辑，即指子业务在待触发的当前轮的处理。

通过上述判断，确定出，各类型业务数据何时应该参与某种子业务的业务处理，何时不需要参与。

步骤103、若存在需参与当前轮结算处理的业务数据，根据所述结算业务包含的各个子业务分别对应的触发条件，确定当前需触发的目标子业务。

结算业务的各个子业务之间，通常需按一定顺序执行，如航空公司的结算业务，一般先进行运价计算，再分摊，后入账，最后再进行票证监控。基于此，在上述各步骤的基础上，本步骤可进一步按预设的子业务处理顺序，确定结算业务包含的各个子业务中待处理的下一子业务，并确定当前是否满足该下一子业务对应的触发条件，若满足，确定该下一子业务为当前需触发的目标子业务。

其中，各个子业务分别对应的触发条件，为与所对应业务数据的数据状态信息相关的条件。

针对航空公司的结算业务，则可遵循先进行运价计算，再分摊，后入账，最后再进行票证监控的业务处理顺序，基于在票证状态管理中为各计算引擎增加的计算处理的触发条件，判定是否触发某一引擎的处理。

在票证状态管理中为各计算引擎增加的触发条件分别说明如下：

(一)运价计算引擎

作为最先的处理逻辑功能，任何进入系统的数据处理单元，均可参与运价计算引擎。例如：当运输货单进入系统后，仅有运输货单数据就可以进行运价计算，但这种仅有运输货单的数据，进行的运价计算所得的结果是不稳定的，也是不准确的。如果该运输处理单元的数据想计算出稳定、准确的数据，还需要更多的数据进入系统，所以当其他数据到来之后，该运输数据处理单元的数据，其运输数据处理状态和时间，都被更新，并准备参与新一轮的运价计算。

运价计算引擎触发条件：(数据处理单元在当前轮的时间周期内发生状态变化)或(上一次运价计算失败)。

(二)运输分摊引擎

运输分摊引擎的顺序，排在运价计算之后。相当于在确定了正确的运价计算引擎计算结果后的运输分摊结果，才是有效的。但这并不代表，运输分摊不能在未进行运价计算前被触发处理，数据处理单元在未进行运价引擎计算前就可以进行运输分摊引擎计算的处理。

运输分摊引擎计算触发条件：(数据处理单元在当前轮的时间周期内发生状态变化)或(上一次运输分摊计算失败)或(前序功能-运价计算引擎成功并且执行时间比上一次运输分摊时间晚)。

(三)运输收入计算引擎

运输收入计算的结果，是航空公司每期收入的最终值与确认值，这就要求它所处理的数据，都要是准确的、正确的，并且它所处理的数据，都要是被正确运价计算过的，也是正确被运输分摊过的数据处理单元的数据。

运输收入计算引擎触发条件：(数据处理单元在当前轮的时间周期内未发生状态变化)且(上一次运价计算结果成功且正确)且(上一次运输分摊结果成功且正确)且(数据处理单元数据变更时间要早于运价计算结果时间，运价计算结果时间要小于分摊结果时间)。

(四)票证监控处理引擎

票证监控是一个可以随时触发的逻辑功能。随时触发意味着，他可以随时监控所有数据处理单元的处理状态，但如果要最终稳定的结果，就需要数据处理单元本身数据稳定，运价计算、运输分摊、运输收入结果正确且是最新的。

票证监控处理引擎触发条件：可随时触发；但最终的稳定数据要求(数据处理单元在当前轮的时间周期内未发生状态变化)且(上一次运价计算结果成功且正确)且(上一次运输分摊结果成功且正确)且(上一次运输入账计算结果成功且正确)且(数据处理单元数据变更时间要早于运价计算结果时间，运价计算结果时间要小于分摊结果时间，分摊结果时间要晚于运输入账计算结果时间)。

业务本身有处理的先后顺序，对于航空公司的结算业务，一般情况下这些作业的先后顺序为：运价计算引擎最先，运输分摊在后，进行了运价计算和运输分摊后才可以进行运输收入计算；最后是票证监控。并且这个顺序是可以灵活定制的。正因为有这种业务处理上的先后顺序，当数据处理单元未按照顺序进入系统处理，或未按照顺序在业务中发生，就会有先参与后续作业，但最终数据不准确的问题存在。本申请实施例的基于票证状态管理的业务处理控制，就是控制这种处理顺序，并降低重复无意义的计算消耗，增加系统吞吐量和运行效率。

当业务数据如数据处理单元的数据未发生任何变化，基于本申请方案，其不需要重复参与到相应子任务即相应计算逻辑单元的处理，只有业务处理单元中的数据发生了变化，才会重新触发对应计算逻辑单元的处理。票证状态管理就是控制数据处理单元，何时应该参与计算，何时不需要参与计算，借此保证最终数据的准确性，同时降低系统性能消耗。

步骤104、获取需参与所述目标子业务的目标业务数据，并按所述目标子业务的处理逻辑对所述目标业务数据进行处理。

在基于各子业务如运价计算、运输分摊、运输收入计算或票证监控的触发条件，确定出当前需触发的目标子业务后，可进一步有针对性的获取需参与该子业务的目标业务数据，并对获取的数据触发目标子业务的处理流程，按目标子业务的处理逻辑对目标业务数据进行处理。

综上所述，本申请提供的业务数据处理方法，包括：确定结算业务涉及的各类型业务数据分别对应的数据状态信息；至少根据各类型业务数据分别对应的数据状态信息，确定每一类型业务数据是否需参与当前轮结算处理中所述结算业务包含的各个子业务；若存在需参与当前轮结算处理的业务数据，根据所述结算业务包含的各个子业务分别对应的触发条件，确定当前需触发的目标子业务；获取需参与所述目标子业务的目标业务数据，并按所述目标子业务的处理逻辑对所述目标业务数据进行处理。

本申请通过上述处理，可避免不必要的数据重复参与到结算业务的业务处理中，只有需要参与相应子业务的数据部分，如发生了状态变化的数据，才会重新触发对应的子业务流程。通过控制各类型业务数据何时应该参与业务处理，何时不需要参与，保证最终数据的准确性，同时提升系统运算效率、降低系统的运算量及性能/资源消耗。

在一实施例中，本申请提供的业务数据处理方法，还可以包括以下处理：

确定结算业务包含的至少部分子业务的业务协议是否发生协议数据变更；

若发生变更，根据相应子业务的协议数据变更信息，确定相应类型业务数据应发生的同步变化，并基于所述相应类型业务数据应发生的同步变化，更新所述相应类型业务数据对应的用于票证状态管理的数据结构对象。

其中，根据相应子业务的协议数据变更信息，确定相应类型业务数据应发生的同步变化，可进一步实现为：根据相应子业务的协议数据变更信息，确定修改前的协议所对应范围内的业务数据中与修改后的协议不匹配的第一数据，以及修改后的协议相比于修改前的协议需新增的第二数据。

也就是说，对协议数据的变更，主要分两种情况，其一是修改前的协议所包含范围内的部分或全部业务数据如数据处理单元，不再适用修改后的该协议，这类数据即可确定为上述的第一数据；其二是修改后的协议所包含范围内的业务数据相比于修改前的协议发生了新增，这类数据即可确定为上述的第二数据。这两种情况，均会导致业务数据如数据处理单元的数据发生变化，所以都需要对票证状态管理的核心数据结构中的相关状态数据，进行更新记录，并按照上文实施例的处理逻辑判断发生变化的数据是否需参与各个子任务的处理，并结合对应的触发条件触发相应子任务的计算逻辑单元重新计算。

结算系统中的协议数据，如航空公司结算系统中的协议数据，虽不是业务数据(数据处理单元)的一部分，但也是业务处理所涉及的关键数据之一，业务数据是参与计算的数据，而协议则是用于对数据进行计算的逻辑依据，这部分数据的变化，同样也会引起业务数据的适应性变化，同样也会影响参与业务处理的数据范围的变化。本实施例通过执行上述的与协议数据变化相匹配的处理，可有效实现对因协议数据变化而引起的业务数据变化进行准确、快速、高效的业务处理。

对应于上述的业务数据处理方法，本申请还提供一种业务数据处理装置，该装置的组成结构如图4所示，包括：

第一确定单元10，用于确定结算业务涉及的各类型业务数据分别对应的数据状态信息；

第二确定单元20，用于至少根据各类型业务数据分别对应的数据状态信息，确定每一类型业务数据是否需参与当前轮结算处理中所述结算业务包含的各个子业务；

第三确定单元30，用于若存在需参与当前轮结算处理的业务数据，根据所述结算业务包含的各个子业务分别对应的触发条件，确定当前需触发的目标子业务；

业务处理单元40，用于获取需参与所述目标子业务的目标业务数据，并按所述目标子业务的处理逻辑对所述目标业务数据进行处理。

在一实施方式中，第一确定单元10，具体用于：

获取各类型业务数据分别对应的用于票证状态管理的数据结构对象；

从对应的数据结构对象中读取相应类型业务数据的数据状态信息；

其中，所述用于票证状态管理的数据结构对象中，记录有用于表征对应类型业务数据的处理状态和状态变化轨迹的数据状态信息。

在一实施方式中，上述装置还包括：数据状态维护单元，用于：

基于创建的票证状态管理处理接口收集各类型业务数据的状态变化信息；

基于收集的状态变化信息，在相应类型业务数据对应的用于票证状态管理的数据结构对象中记录或更新该类型业务数据的数据状态信息。

在一实施方式中，第二确定单元20，具体用于：

根据所对应的数据状态信息，确定各类型业务数据在当前轮的时间周期内是否发生过状态变化；

根据各类型业务数据在当前轮的时间周期内是否发生过状态变化，各类型业务数据是否参与过所述结算业务包含的相应子业务，以及在参与过相应子业务的情况下所参与的子业务是否处理成功，确定每一类型业务数据是否需参与当前轮结算处理中所述结算业务包含的各个子业务。

在一实施方式中，第三确定单元30，具体用于：

按预设的子业务处理顺序，确定所述结算业务包含的各个子业务中待处理的下一子业务；

确定当前是否满足所述下一子业务对应的触发条件，若满足，确定所述下一子业务为当前需触发的目标子业务；

其中，各个子业务分别对应的触发条件，为与所对应业务数据的数据状态信息相关的条件。

在一实施方式中，上述装置还包括：

协议变更处理单元，用于：确定所述结算业务包含的至少部分子业务的业务协议是否发生协议数据变更；若发生变更，根据相应子业务的协议数据变更信息，确定相应类型业务数据应发生的同步变化，并基于所述相应类型业务数据应发生的同步变化，更新所述相应类型业务数据对应的用于票证状态管理的数据结构对象。

在一实施方式中，协议变更处理单元根据相应子业务的协议数据变更信息，确定相应类型业务数据应发生的同步变化时，具体用于：

根据相应子业务的协议数据变更信息，确定修改前的协议所对应范围内的业务数据中与修改后的协议不匹配的第一数据，以及修改后的协议相比于修改前的协议需新增的第二数据。

在一实施方式中，各类型业务数据包括运输数据、销售数据、进港到付数据和对内开账数据中的至少部分类型数据；

结算业务包含的各个子业务包括运价计算、运输分摊、运输收入计算、票证监控中的至少部分子业务。

对于本申请实施例提供的业务数据处理装置而言，由于其与上文方法实施例提供的业务数据处理方法相对应，所以描述的比较简单，相关相似之处请参见上文方法实施例的说明即可，此处不再详述。

本申请还提供一种计算机可读介质，其上存储有计算机程序，所述计算机程序包含用于执行如上文方法实施例提供的业务数据处理方法的程序代码。

在本申请的上下文中，计算机可读介质(机器可读介质)可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

需要说明的是，本申请上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(射频)等等，或者上述的任意合适的组合。

上述计算机可读介质可以是电子设备中所包含的；也可以是单独存在，而未装配入电子设备中。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

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

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

最后，还需要说明的是，在本文中，诸如第一、第二、第三和第四等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种业务数据处理方法，其特征在于，包括：

确定结算业务涉及的各类型业务数据分别对应的数据状态信息；

至少根据各类型业务数据分别对应的数据状态信息，确定每一类型业务数据是否需参与当前轮结算处理中所述结算业务包含的各个子业务；

若存在需参与当前轮结算处理的业务数据，根据所述结算业务包含的各个子业务分别对应的触发条件，确定当前需触发的目标子业务；

获取需参与所述目标子业务的目标业务数据，并按所述目标子业务的处理逻辑对所述目标业务数据进行处理。

2.根据权利要求1所述的方法，其特征在于，所述确定结算业务涉及的各类型业务数据分别对应的数据状态信息，包括：

获取各类型业务数据分别对应的用于票证状态管理的数据结构对象；

从对应的数据结构对象中读取相应类型业务数据的数据状态信息；

其中，所述用于票证状态管理的数据结构对象中，记录有用于表征对应类型业务数据的处理状态和状态变化轨迹的数据状态信息。

3.根据权利要求2所述的方法，其特征在于，在所述确定结算业务涉及的各类型业务数据分别对应的数据状态信息之前，还包括：

基于创建的票证状态管理处理接口收集各类型业务数据的状态变化信息；

基于收集的状态变化信息，在相应类型业务数据对应的用于票证状态管理的数据结构对象中记录或更新该类型业务数据的数据状态信息。

4.根据权利要求1所述的方法，其特征在于，所述至少根据各类型业务数据分别对应的数据状态信息，确定每一类型业务数据是否需参与当前轮结算处理中所述结算业务包含的各个子业务，包括：

根据所对应的数据状态信息，确定各类型业务数据在当前轮的时间周期内是否发生过状态变化；

根据各类型业务数据在当前轮的时间周期内是否发生过状态变化，各类型业务数据是否参与过所述结算业务包含的相应子业务，以及在参与过相应子业务的情况下所参与的子业务是否处理成功，确定每一类型业务数据是否需参与当前轮结算处理中所述结算业务包含的各个子业务。

5.根据权利要求1所述的方法，其特征在于，所述根据所述结算业务包含的各个子业务分别对应的触发条件，确定当前需触发的目标子业务，包括：

按预设的子业务处理顺序，确定所述结算业务包含的各个子业务中待处理的下一子业务；

确定当前是否满足所述下一子业务对应的触发条件，若满足，确定所述下一子业务为当前需触发的目标子业务；

其中，各个子业务分别对应的触发条件，为与所对应业务数据的数据状态信息相关的条件。

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

确定所述结算业务包含的至少部分子业务的业务协议是否发生协议数据变更；

若发生变更，根据相应子业务的协议数据变更信息，确定相应类型业务数据应发生的同步变化，并基于所述相应类型业务数据应发生的同步变化，更新所述相应类型业务数据对应的用于票证状态管理的数据结构对象。

7.根据权利要求6所述的方法，其特征在于，所述根据相应子业务的协议数据变更信息，确定相应类型业务数据应发生的同步变化，包括：

根据相应子业务的协议数据变更信息，确定修改前的协议所对应范围内的业务数据中与修改后的协议不匹配的第一数据，以及修改后的协议相比于修改前的协议需新增的第二数据。

8.根据权利要求1所述的方法，其特征在于，所述各类型业务数据包括运输数据、销售数据、进港到付数据和对内开账数据中的至少部分类型数据；

所述结算业务包含的各个子业务包括运价计算、运输分摊、运输收入计算、票证监控中的至少部分子业务。

9.一种业务数据处理装置，其特征在于，包括：

第一确定单元，用于确定结算业务涉及的各类型业务数据分别对应的数据状态信息；

第二确定单元，用于至少根据各类型业务数据分别对应的数据状态信息，确定每一类型业务数据是否需参与当前轮结算处理中所述结算业务包含的各个子业务；

第三确定单元，用于若存在需参与当前轮结算处理的业务数据，根据所述结算业务包含的各个子业务分别对应的触发条件，确定当前需触发的目标子业务；

业务处理单元，用于获取需参与所述目标子业务的目标业务数据，并按所述目标子业务的处理逻辑对所述目标业务数据进行处理。

10.一种计算机可读介质，其特征在于，其上存储有计算机程序，所述计算机程序包含用于执行如权利要求1-8任一项所述的方法的程序代码。

Images