航空结算系统中的数据治理与协议处理方法

冉长风

四川省机场集团有限公司，四川成都，610202

0 引言

航空业务结算系统主要是满足机场集团管理的各个机场全航班的航空性业务和地面服务业务的计费、结算、开账和管理需求，纳入本系统的业务适用于民航局《关于印发民用机场收费改革实施方案的通知》（民航发〔2007〕159号）、《关于印发民用机场收费标准调整方案的通知》（民航发〔2017〕18号）等文件中所规定的航空性业务收费项目、地面服务收费项目等。

航空业务结算系统可以有效提高机场集团财务管理能力和收入结算工作效率，通过系统与上下游系统的集成，可以实现从接收生产数据到计费、结算、开账和管理的全流程自动化处理，系统在航班服务完成并获取前端生产数据后，能实时完成数据处理和计费并开展即时结算，缩短结算时间，加快资金回笼，可为后续航空主业成本效益分析提供最真实准确的数据，加强企业业财融合治理能力。

1 航空业务结算系统建设的概要需求

航空业务结算系统主要是提供给机场财务结算岗位使用，而机场财务结算岗位的主要工作内容包括：（1）业务结算和报表生成；（2）挂账做凭证；（3）费用暂估；（4）拒付审核；（5）清理欠款；（6）确认收入和应收账款核销；（7）开具发票。

航空业务结算系统的主要目的是满足机场财务结算岗位的工作需求，而其中的核心功能是基于业务数据和收费协议计算机场相对航司所应收取的各项费用。同时，航司方面也会基于机场所提供的收费明细与航司系统内的业务数据相比对，数据一致的项目同意支付，数据不一致的项目则会提出异议和拒付要求。

因此，为了保障机场每月结算过程的顺利和高效，航空业务结算系统在机场实施过程中所面临的两个核心难点是：（1）如何确保业务数据的准确、完整、可靠与及时；（2）如何实现航司协议制定的灵活、多变和个性化。

同时，还需要充分考虑枢纽型机场与支线机场在业务、系统建设和组织架构上的异同，系统设计需要具有充分的灵活性，能适应不同场站的业务结算需求。

1.1 业务数据方面的需求

系统要处理的业务数据分为几个大类，分别是：（1）航班数据；（2）航空性业务数据；（3）地服业务数据；（4）基础数据等。结合项目前期需求调研的情况以及业务数据的特点，系统在业务数据方面，需要实现全面、准确、标准这三项基本要求，但业务数据处理面临的问题有以下几类。

（1）割裂的多源异构数据。系统涉及多数据源接入，需要集成的系统包括：机场ACDM系统、AODB系统、地服排班、地服货运、登机桥排班、机场数据中心、支线机场云服务平台、集团公司数据交换平台、OA系统、报文系统、数据仓库系统等。财务结算所需要的数据来源于不同的业务系统，这些割裂的多源异构数据造成了各种数据孤岛，这给数据分析处理带来非常大的挑战，航空业务结算系统需要把这些割裂的数据整合到统一的系统中，实现数据的融合与统一。举例来说，其中一个机场的业务数据来源及更新周期情况如图1所示。

图1 业务数据来源及更新周期

（2）数据规模与数据价值的矛盾。系统当前需要接入6个机场的所有业务数据，预计未来会接入更多的机场。从数据种类来看，系统需要涵盖航班数据、载运数据等机场航空性数据，也同时包含特车、桥载等地面服务数据。业务数据种类超过了20种，每个结算周期所关联的业务数据都在百万量级。上述数据需要在分钟级内完成数据校验、关联、协议匹配、费用计算和费用分配等不同业务要求，数据单位时间的计算工作量较大，这对业务数据的存储和处理方法提出了挑战，同时，不同业务的数据使用规则不一致，复杂程度也有所不同，航空业务结算系统需要对数据治理的规模进行控制，这样才能有效发挥数据的利用价值。

（3）旧有系统架构无法快速响应新增业务需求。随着机场航班量的增长和服务内容的增加，旧有系统的性能瓶颈也正在逐步出现。同时，传统框架下的核心系统结构，决定了当机场增加业务种类、改变服务流程标准和新增核心需求时，难以快速响应。航空业务结算系统需要从业务的新要求以及未来发展趋势出发，设计规划更加适配的系统运行架构，解决系统运行的性能瓶颈，实现业务的灵活扩展。

1.2 航司协议方面的需求

航司协议的制定要充分考虑机场、航司之间的切身利益和特点，因此，航司协议并不是标准的协议，每个航司之间都会有所不同，结合实际情况总结航司协议的主要异同点如下。

（1）协议需要区分母子公司，有些协议的承运方部分内容适用于航司的母公司以及分子公司，而有些协议则需要针对部分航司或者分子公司予以单独设置。

（2）协议所关联的服务方部分需要单独配置。按照目前集团的组织架构，双流机场的收入费用分别归属于集团、股份和地服公司，天府机场的收入费用分别归属于天府分公司和地服公司。绝大部分支线机场的收入归各支线机场，个别的收费项目由地服公司收取。因此，需要单独配置各个机场的协议，同时需要将相关的收入项目划分给不同的公司或者业务部门。

（3）协议的配置需要考虑各种特殊情况，需要具备足够的灵活性和扩展空间。首先，协议关联的收费项目需要可以灵活删减和修改，例如，疫情期间因防疫工作要求会额外增加新的收费项目。其次，飞机在各个航司之间会存在湿租和干租的情况，有些时候是固定航班，有些时候是固定飞机，各种情况都会存在，系统需要能适配各种场景，最大限度地实现系统结算收费，避免人工调整和干预。

（4）协议的配置需要考虑正班航班、公务机、临时航班在业务处理上的异同。类似双流和天府这种大型枢纽型机场，所运行的航班包括正班航班、公务机、临时航班等不同类型的航班，其中公务机一般会由专门的公务机服务公司保障，而临时航班的业务一般是由代理公司申请和发起，属于临时发生和执行的航班任务。系统在业务数据处理以及收费协议配置方面，需要全面考虑上述不同业务在业务流、数据流、价值流方面的异同，需要实现上述业务在系统内的数据全覆盖和结算流程全覆盖。

（5）协议的设置需要包含正常收费协议和打折优惠协议。机场市场部门为了机场业务发展的需要，或者整个地区区域发展的需要，往往需要从更多的层面鼓励或者开放某一航线的运行，从而制定一定的优惠条件和要求，当航司作为承运人满足这些条件要求时，机场会给予一定的打折优惠，比如航班每月运行满一定架次之后会给予一个优惠价格，运行到达更多架次区间之后会给予另外一个优惠价格。

（6）财务收费尾差的处理需要贯穿结算工作的整个流程。在结算的整个过程中，需要从一开始就要考虑财务收费尾差的自动化处理，这包括协议的配置、业务结算、收入分配、应收单的生成等等，其中部分业务是需要系统自动化处理尾差的，另外一部分业务，则是按照用户要求将尾差结余在某个收费项之中。

2 关键需求的实现方法

2.1 业务数据的治理

2.1.1 数据治理工作的分阶段实施内容

航空业务结算系统关联的业务数据来源几乎覆盖机场现有所有的生产应用系统，每个系统由于系统建设时间、建设背景以及业务需求的不同，数据的内容、提交的周期以及审核校验的要求都各有不同，能为财务结算提供的数据质量参差不齐。数据治理指的是将零散的数据变为规划统一的数据、从具有很少或者没有组织和流程到企业范围内的综合数据治理、从处理混乱数据到井井有条的一个过程。数据治理可以让数据资产得到有效的治理，使数据的框架、原则和过程方面都得到正确的履行[1]。数据治理工作分阶段实施内容如图2所示。

图2 数据治理工作分阶段实施内容

2.1.2 消息总线MQ以及唯一FlightID的组合应用

财务结算所需要的数据来源于不同的业务系统，这些割裂的多源异构数据造成了各种数据孤岛，航空业务结算系统需要把这些割裂的数据整合到统一的系统中，实现数据的融合与统一。因此，系统选择通过消息总线MQ来实现与外部系统的接口对接，在内部，系统同样采用消息总线MQ来实现不同微服务之间的数据接口对接[2]（图3）。

同时，一个航班关联的数据种类，目前超过了20种，每种外部数据的数据结构都有所不同，但是所有数据都有一个大致的共同点，可以基于航班这一条主线把所有数据串联起来（训练飞行等特殊任务除外）。因此，系统在所有的外部数据进入内部数据表之前，给航班数据和业务数据都设置一个FlightID（业务数据的FlightID是通过各种约束限制添加的），通过这个FlightID可以关联系统内所有相关的航班数据和业务数据，同时，通过这个FlightID，系统内部代码在SQL查询条件、内部缓存覆盖、多进程并行计算等诸多方面做了针对性的优化，即使百万量级的业务数据分配需求，也可以在几分钟以内完成各种的数据校验和精准计算，实现了数据计算效率的有效控制。

2.1.3 数据湖的建设以及分层应用

通过对集团航空业务结算系统业务数据治理的需求进行梳理和分析后，结合当前相对成熟和先进的数据湖和流式数据实时处理技术，最终形成数据一体化存储，平台逻辑统一、物理分散、统一部署的数据湖架构（图4）。

图4 结算系统数据湖应用架构

在数据湖数据采集存储以及应用建设过程中，充分考虑实时业务结算以及海量数据分析处理两类不同的业务需求，结合集团业务的实际情况，依据数据敏感程度不同，将数据湖的底座基础按照分层应用思路区分为原始层和治理层两个基本层次，其中原始层用于保存近1年周期范围内的所有业务数据、结算数据和应收数据，治理层则用于保存长期的历史数据以及基于历史数据以及会计周期所生成（定期自动触发）的统计分析结果。采用这种分层应用处理架构的优点是，将两者数据区别存储、应用区别开发、服务区别部署，既可以满足结算岗位实时数据处理以及每月快速数据结算的需求，又可以满足统计分析岗位历史大数据统计和决策需求[3-4]。

2.2 航司协议的管理

2.2.1 协议的定义

航司协议是指航空公司作为承运方，机场作为服务方，双方就承运方使用机场以及服务方所提供的保障服务事宜所达成的有关双方责任和义务规定的协议。协议服务的内容一般包括民航局所规定的航空性服务内容及收费标准、承运方需要服务方所提供的地面代理服务内容以及收费标准，举例来说，民航局所下发的民航发[2007]159号中定义了民用机场业务收费项目、收费标准基准价及浮动幅度等内容。

航空业务结算系统的建设重点之一就是在系统内管理和维护航司收费协议。由于航司大小、市场环境等的不同，各航司的协议呈现出航空性业务大致相似、地面服务业务千司千面的特点，航空业务结算系统从结算业务的需求出发，整理和设计了机场内与财务收费相关的所有业务数据模型和结算业务收费模型，模型在设计过程中，特意强调了两个统一，即数据需求与模型设计的统一、模型设计与物理实现的统一。

以民航发〔2017〕18号文中内地航空公司内地航班航空性收费项目的旅客服务费为例，其中定义一类二级机场，针对国内离港航班，每一个成人收取40元的旅客服务费。该旅客服务费在系统内，关联到了“国内流向旅客服务费”这一个收费项目，而这个收费项目在结算系统内的定义，包含条件、单价、数量等要素（表1），而在定义条件时，系统允许财务人员直接使用类似“任务代码分类”“航段国际国内属性”以及“到离港”等内置的条件变量抽样语义，像编写数学表达式一样，可以很方便地实现上述各种收费协议的配置。

表1 某一航司国内流向旅客服务费的协议定义

航司收费协议所关联的收费项目、条件变量和计算变量，可以基于业务数据的统计或分析结果进行设置，也可以将计算后的收费结果作为协议条件参与二次计算。整个结算模型的体系是一种可往复循环的设计，系统可以不断地吸纳新的业务数据和收费项目，新增的收费项目可以扩展现有的协议条件，收费的结果也可以用于协议优惠的计算，这种设计可以适配各种复杂特殊的业务协议场景，满足机场市场发展拓展的各种需求。

同时，结算模型仅仅是整个结算流程的一部分，一个完整的结算过程关联了航班数据、业务数据、基础数据和客户协议，整个过程是一个完整的事务，模拟了数据库事务的原子性和一致性的特点，整个过程是一个完整的操作事务，事务的各元素是不可分的。事务中的所有元素必须作为一个整体提交或回滚。如果事务中的任何元素失败，则整个事务将失败。当事务完成时，数据必须处于一致状态。航班结算处理的流程大致如图5所示。

图5 航班结算流程示意图

2.2.2 表达式引擎

通过对上述航司协议复杂度情况的分析，发现如果采用传统的技术实现方式进行开发实现的话，在应用系统中会存在大量的if……then……else结构的代码来实现对相应业务规则的判断与处理。而这种直接使用源码定义业务逻辑、规则的方式很难满足航空结算业务对航司协议规则变化的需求，相应的财务用户的使用和技术人员的维护成本也将大大提高。为了实现上述目标，在本项目的建设过程中，借鉴了DDD（领域驱动设计）的相关理念和方法，从财务结算领域的航司协议逻辑规则入手，对该领域的相关技术实现逻辑进行分析、规划、定义与解析，通过引入领域表达式元模板的概念，利用定制开发的语言解析程序来辅助财务人员基于领域表达式元模板对相应的航司协议规则的逻辑进行直接定义和调整[5]。航司协议规则处理服务的整体逻辑架构如图6所示。

图6 航司协议表达式规则处理流程

3 总结

相比一线业务部门生产保障所使用的信息集成系统、ACDM系统、站坪系统等，航空业务结算系统主要关联的业务部门是机场的市场部、财务部、战略规划部等，但是所利用的业务数据，则来自机场一线生产保障的方方面面，是机场生产运行数据集中处理的典型应用。航空业务结算系统当前可以结算超过100多家国内外航司的定期航班费用收入，并且实践证明，系统已经具备快速处理海量化、异构化数据的能力，同时系统也充分满足了机场与航司所签署的各类具有差异化、个性化特点的收费协议结算要求。利用结算系统可有效推动实现机场业财融合，提高集团管控能力，推进实现机场集团业财融合和业财一体化建设的远景目标。