航空結算系統中的數據治理與協議處理方法

冉長風

四川省機場集團有限公司，四川成都，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多家國內外航司的定期航班費用收入，并且實踐證明，系統已經具備快速處理海量化、異構化數據的能力，同時系統也充分滿足了機場與航司所簽署的各類具有差異化、個性化特點的收費協議結算要求。利用結算系統可有效推動實現機場業財融合，提高集團管控能力，推進實現機場集團業財融合和業財一體化建設的遠景目標。