• No results found

A potential Centralized Ticket Data Processing Solution for airlines

N/A
N/A
Protected

Academic year: 2021

Share "A potential Centralized Ticket Data Processing Solution for airlines"

Copied!
38
0
0

Loading.... (view fulltext now)

Full text

(1)

 

A potential

Centralized Ticket Data

Processing Solution

for airlines

(2)

Table of Contents

1.  Executive Summary - Centralized Ticket Data Processing Solution ... 3 

2.  Revenue Accounting Background ... 6 

Traditional Passenger Revenue Accounting Processing ... 7 

3.  Industry Centralization Opportunity ... 8 

4.  Concept for a Future of Revenue Accounting ... 10 

Overall Process Map ... 11 

5.  Sales Process... 12 

5.1.  Sales Processing General ... 12 

5.2.  Sales Processing – Original Sales ... 14 

5.3.  Sales Processing – Exchanges (Other Airlines (OA) and Own sales) ... 14 

5.4.  Sales Processing – Refunds (OA and Own sales) ... 15 

5.5.  Sales Processing – Miscellaneous Carrier Documents (non-transport)... 15 

5.6.  Sales Processing – Duplicate Sales ... 15 

6.  Usage Process ... 16 

6.1.  Lift Usage ... 16 

6.2.  Payable Usage ... 17 

6.3.  Unearned Revenue (Spoilage / Aged Usage / Outdating) ... 17 

6.4.  Unmatched Usage ... 17 

6.5.  Valuation ... 18 

7.  Interline Process ... 19 

7.1.  Receivables: Prime Billings invoiced by the Billing Carrier ... 19 

7.2.  Payables: Prime Billings invoices received by the Plating Carrier ... 19 

7.3.  Rejections ... 19 

7.4.  Codeshare Commission Handling ... 20 

8.  Data Aggregations for Posting ... 21 

8.1  Accounting Files ... 21 

8.2.  Sales Accounting ... 21 

(3)

 

9.3.  Master Data Tables ... 25 

10.  Non-Functional Processes ... 27 

10.1.  Dashboards and Key Performance Indicators (KPI) ... 27 

10.2.  Management Information Files ... 27 

10.3.  Archive and Purge ... 27 

10.4.  Audit trail ... 27 

10.5.  Disaster Recovery ... 27 

Appendix A - List of FoRA Task Force Participants ... 28 

Appendix B - FoRA Central Process Development List ... 29 

Appendix C - Carrier Development List ... 32 

Appendix D - Open Items ... 33 

Appendix E - Out of Scope Items: ... 35 

Appendix F - Glossary ... 37 

Note: the preliminary work under the Future of Revenue Accounting (FoRA) initiative has led to the description of a potential IATA service based on a central ticket database integrated with existing industry services, now referred to as the Centralized Ticket Data Processing Solution. The term FoRA has been used throughout the document when describing the proposed solution.

(4)

1. Executive Summary - Centralized Ticket Data Processing Solution

The goal of this document is to provide the Revenue Accounting community with a description of the proposed processes for an industry solution as an alternative to current systems, to present potential industry solutions to mitigate current operational challenges and to be used as a foundation for a Request for Information (RFI) document as a next step.

Revenue Accounting is a challenging component of airline accounting because it encompasses an extremely large volume of transactions, and each transaction can include multiple unique reporting requirements for liability, revenue, taxes, fees, commissions etc. There are various types of transactions each associated with special rules on how to handle them that are a result of the way air travel is distributed, sold and reported. Financial standards define the manner in which accounting must be performed for every transaction. As airlines move to unbundle multiple ancillary items from the base fare, the volume of transactions continues to increase. While the industry has constantly worked to improve the way transactions are reported, the current processes and systems are still labor intensive and costly to maintain.

There is a desire among Finance Department executives to evaluate the potential for a centralized and streamlined method of approaching the revenue accounting process in order to achieve reductions in both cost and complexity. The Future of Revenue Accounting Task Force (FoRA) was established to consider currently available technology and industry services as they relate to revenue accounting industry practices, determine the feasibility of managing revenue accounting functions without requiring a dedicated revenue accounting system and to propose how current functions would divide into general data processes running centrally and carrier specific requirements performed in-house.

The Task Force has identified the core functional areas that could be centralized and will be required in order to successfully process transactional data as follows:

Feature Benefits

Centralized Sales Reporting Replace system support costs in multiple systems with one centrally maintained process fed by ARC and BSP data, and by airline ticket data files

Reduce development costs by having a single point for system updates as industry reporting standards change

Industry Proration Engine Remove differences in proration values used for interline billings that are the result of system variations

Facilitate the ability to cleanse the sales data to improve accuracy in valuation for both online revenue and interline settlement

Centralized Ticket Database Reduce the cost of storing copies of the same transaction in multiple databases

Optimize Interline settlement functions

(5)

Facilitate adoption of new industry initiatives

Streamline the implementation of new industry standards such as New Distribution Capability (NDC)

Explore the potential to create the proration values at time of fare filing

Engage industry organizations working with data suppliers to set standards and to improve the quality and consistency of the data

A centralized Sales Reporting process would provide a single point of change to maintain compliance with Airline Reporting Corporation (ARC) and Billing and Settlement Plan (BSP) reporting standards which reduces the cost of updating multiple systems and can streamline testing and implementation timelines. Sales data processing can be improved by providing central cleansing of sales data and by enriching the ticketed data with information from other industry standard data sources. A new industry standard will be established to enable reporting and processing of all airline direct sales e.g. web sales, call centers, airports etc. This will require development or alternatively, enhancement of an existing module from a revenue accounting system provider to fit the purpose.

Proration can be performed by a single utility rather than by separate individual processes maintained by each individual airline, which may yield differing results. This functionality exists today as the industry standard Neutral Fare Proration (NFP) engine used for the First & Final service. It would need to be enhanced to accommodate additional requirements specific to carriers online proration needs (carriers are hesitant to change proration methodologies because of the complexity of explaining year over year changes in market/entity revenue results that will occur). The existing service employs a single method of converting transactions in foreign currencies to the carrier’s home currency and would need to be enhanced to accommodate a multiplicity of methodologies used by carriers today. The scalability of the service will need to be assessed to handle the increased volume of online transactions (interline transactions typically constitute less than 25% of the volume of transactions processed by an airline). Central processing would also reduce the workload for capturing industry standard data that still requires manual data input e.g. the terms of provisos and tax application rules.

A Centralized Ticket Database (CTD) will reduce the costs of multiple copies of a transaction being stored individually in separate data stores. A CTD can be used to optimize billing and settlement activity between airlines, reducing the volume and timeline of disputes. Linking the data via SIS to the Clearing House will enable the expedited settlement of interline billings by linking the billing and clearance processes.

In order to accommodate the needs of multiple carriers that could participate in a single transaction, the use of a single database will require the addition of a number of fields for every transaction. The database must also serve as the foundation for matching all transaction usage to a reported sale in order to comply with revenue recognition requirements. While there is currently a centralized data store provided by ARC to facilitate the First & Final service, it is unclear at this point if that database is appropriate for these new requirements. A technical architecture evaluation will need to be conducted to determine the optimal solution.

Centralized processing of flown ticket data is a service that was developed for use by the Simplified Interline Settlement (SIS) solution and can be engaged for the FoRA service. This functionality is used to process all uplifted coupon usage sent directly by the carriers for both online and interline

(6)

transactions. The service will send the information to the CTD. This is not deemed to be a major enhancement.

The service does not control or perform accounting. It will process data and aggregate it according to specific rules and output the results in data files to enable airlines to do the accounting according to their own requirements. The expectation is that today’s sophisticated Enterprise Resource Planning (ERP) systems, in use at most airlines, can accommodate these requirements.

The Task Force has also identified components that will need to be developed in order to deliver a completely functional infrastructure such as:

 An online ticket viewer,

 A rules engine and master data tables to support carrier preferences,  Processing specifications and data access/security rules,

 An additional data extract to support the airlines need for Management Information Systems (MIS) data to be utilized by their internal systems,

 A disaster recovery solution to ensure business continuity plans,  A migration strategy for transactions in existing systems.

There are processes that are deemed to be out of scope due to a number of reasons that are detailed in the service description. (Refer to Appendix E)

The conclusion is that it is technically feasible to develop a centralized service that would deliver cost savings to the industry at a macro level. This preliminary analysis by the Task Force has also highlighted some areas of complexity that will require further study. In order to proceed with a more detailed assessment, the Task Force participation must be expanded to include a more diverse group of carrier representatives and should also include more technical expertise to advise on the best options for the development required centrally and locally as well as to help establishing the corresponding costs and timelines. An assessment by external auditors should be solicited to ensure the design is deemed acceptable to them.

IATA would like to thank the participants on the Task Force for their valuable time and contributions over the four months during which this project was run. The participants were:

 Air France  Air New Zealand

 China Southern Airlines/ACCA  Delta Airlines  Etihad Airways  Qatar Airways  ACH  ARC  ATPCO

(7)

2. Revenue Accounting Background

Why is airline revenue accounting special? It encompasses a huge volume of sales transactions, each with multiple individual values for travel, taxes and commissions, variable by date and actual usage, requiring specialised rules for processing them. A ticketing transaction is the foundation for all of revenue accounting. In addition to the main passenger tickets, it includes accounting for the sales documents for every type of ancillary service that can be provided from Change Fees and Frequent Flyer Charges to Baggage Fees and Special Seating Charges. The actual ticket data processing for revenue accounting adds no value in itself; the value comes from information derived from the data processing. In order to function effectively, down-line systems require accurate and detailed revenue and sector information for e.g.: revenue management, route profitability, sales tracking and customer relations.

Electronic tickets (eTickets) became universal in 2008, although some paper tickets are still issued by carriers, and while this innovation removed the paper it did not fundamentally improve processing in the revenue accounting environment. It substituted a system generated file of data for the one that was manually captured. The improvements in sales reporting are primarily the result of increasing the rate of automated sales reporting (now available daily) and expanding the number of data elements reported. The current problems are mainly caused by a lack of process controls in the ticketing systems which provide the critical data that a revenue accounting system needs to function effectively. These problems are derived from both agency use (or misuse) of GDS systems and airline ticketing systems which are also a major source of data process errors requiring manual intervention.

This is why the current processes and systems are so labor intensive and costly. Ever-increasing point- of-sale options and the resulting system complexity adds to industry costs. It creates a need to constantly maintain and enhance carriers’ own systems or buy the necessary services from other providers. An example is the failure to deploy the Structured Fare Calculation. Tickets are issued using Fare Rules filed by the carriers that are not specified by segment. This means that the fare calculation portion of a ticket is a critical element required to determine the amounts applicable to each fare component, and from that, the applicable value per segment based on proration rules and carrier-specific bilateral agreements. The Ticketing System Service providers and GDSs are still using free text for this data field and do not have a compelling business reason to make the improvements that would address the problems. The cost is substantial, and most carriers have not been in a position to invest in those improvements. The introduction of Simplified Interline Settlement (SIS) and more recently Electronic Miscellaneous Documents (EMDs) have had direct impacts on airline revenue accounting as those changes have required adaptations in the existing systems. While streamlining parts of the process, particularly in interline, they do not address those upstream challenges.

(8)

Traditional Passenger Revenue Accounting Processing

A standard revenue accounting system must deliver fast accurate passenger revenue and segment data to management and MIS systems. To achieve this, a segment value must be assigned to each coupon using industry standards which are mandated for interline billings. Additionally, on a bilateral basis, carriers may agree, for interline billing purposes, to use values agreed in a Special Prorate Agreement (SPA). For wholly online journeys airlines may use all or part of the industry standard process for valuation, or may apply its own standards. They may also use different segment calculations for non-revenue accounting uses such as yield and cost management.

The system needs to be accurate and flexible, and provide maximum efficiency in processing ticket data, determining and billing accurate values. It should validate all transactions and initiate a correction process for errors and identify circumstances in which fraud may have occurred

Lastly, a core function of a revenue accounting system is to provide accounting files to the company’s General Ledger (G/L) following the airline’s own specific requirements and local government rules. Historically the system serves as the Sub-ledger to the G/L owing to the massive volume of transaction data which it is not practical to store in the G/L. While the actual account postings typically occur at the end of a defined accounting period (usually a calendar month), systems provide daily summary reporting of the accounting for all transactions for both daily and month-to-date time frames. This enables the accountants to monitor activity and take corrective action in the event of any anomalies. Typically the core revenue accounting functions are defined as:

(9)

3. Industry Centralization Opportunity

To reduce the industry cost of the revenue accounting activity airline Finance executives seek to evaluate the potential of a centralized approach that would simplify and standardize this back-office process.

The FoRA Task Force has been set up to drive the successful implementation of such a service and to evaluate the exceptions needing manual intervention that currently prevent full automation. The feedback from the industry to date endorses the approach of the Task Force. The process will be designed to support the New Distribution Capability (NDC) by enabling a simple, industry-wide implementation as well as reducing future investment needs for the industry by leveraging the infrastructure of existing industry solutions and the core strengths of industry organizations. This model will also be adapted to support all future industry changes that impact revenue accounting centrally. There are many opportunities arising from a central solution including:

 A centralized Sales Reporting process provides a single point of change to maintain compliance with Airline Reporting Corporation (ARC) and Billing and Settlement Plan (BSP) reporting standards, along with Simplified Interline Settlement (SIS) and any other industry standard formats that require changes in a revenue accounting system. This reduces the cost of updating multiple systems and can streamline testing and implementation timelines. Sales data processing can be improved by providing central cleansing of the data and by enriching the ticketed data with information from other industry standard data sources. This will also allow more robust identification of industry wide reporting issues and enable industry driven solutions.  Proration and taxes can be performed by a single utility rather than by separate processes

customized for each individual airline which may yield differing results. This can streamline interline processes and reduce workload for processes that can be handled centrally e.g. capturing the terms and conditions of SPAs, provisos and taxes centrally so that all participants are using a common version. Expanding the volume of transactions handled by the NFP engine and increasing the number of carriers using the service will allow the industry to focus on improving the quality of proration engine results for all participants.

 A CTD will reduce the costs of multiple copies of a transaction being stored individually in separate data stores. The use of the reported sale information can enhance the segment valuation for all parties in an interline transaction. If a ticket is re-issued by a different carrier, it can be prorated using the original data from the CTD. A CTD can be used to optimize billing and settlement activity between airlines, reducing disputes and the timeline for managing disputes. Linking the database to the Clearing House via SIS will also enable the expedited settlement of interline billings by linking the billing and clearance processes.

An Industry-owned service will provide cost saving opportunities:

 Lower cost of operation – one central operation will cost a fraction of hundreds of local operations and it can be operated on a cost recovery basis.

 A uniform application of standards will reduce disputes and costs associated with managing them.

 Service standards and quality will be managed by the industry which will provide greater resources and increased market strength.

(10)

 Enable future opportunities to reengineer the revenue accounting business process at the industry level.

Much of the associated business framework already exists in the industry:

 AIA – The First & Final infrastructure created by ARC, IATA and ATPCO includes a Neutral Fare Proration (NFP) engine and centralized data storage for prorated sales data.

 SIS – Auto-Billing provides automatic flown coupon data processing for other airline tickets, revenue recognition postings and corresponding outgoing invoices. SIS also facilitates audit of incoming invoices and coupon data.

 Powerful modern Enterprise Resource Planning (ERP) systems e.g. Oracle and SAP can handle additional inputs and sophisticated processes.

(11)

4. Concept for a Future of Revenue Accounting

The FoRA Task Force proposes the creation of a central service that will provide a framework for automated passenger ticket data processing that can deliver the functions and outputs required for revenue recognition. This service will generate the necessary data to support accounting within ERP systems and provide the detailed data required by carriers MIS systems. This initiative aims to identify a simpler and more cost effective manner for handling ticket data processing in an all-electronic environment so as to manage the revenue accounting process without requiring specialized revenue accounting systems.

The sales reporting function is the first step in determining what accounting will occur as a result of processing the Sales Reports. FoRA will therefore include a processing service for all sales reports that can accommodate reporting from various sources such as ARC and BSP as well as a carrier’s direct sales reporting. Edits will be performed to ensure that all sale transactions are in balance and need no further enhancement. Transactions with errors must be either systematically enhanced or manually corrected either by a centrally sourced service or in-house. While industry standard sales reporting processes have been greatly improved, resulting in more reliable sales reporting, there still exist a number of issues with direct sales reports. The service will also include a sales report receipt tracking function to ensure that all expected reports have been submitted and enable month-end accounting accruals.

The common practice is to complete the proration of transaction prior to determining the accounting values for reported sales. Sale transactions are then matched to prorated ticket data to obtain segment values and coupon level taxes.

The industry NFP engine will be used to provide prorated coupon values for all passenger transactions based on the accepted industry processing rules and any SPA filed by the participants. Additionally it will attribute values to the applicable coupons, including gross fare, surcharges, sales discount, sales commission, ticket taxes, fees and charges including fuel and other surcharges. Data enhancement will provide additional levels of accuracy for processing the transaction data. A module to allow for manual data entry when required will be provided.

There are two main areas that contribute significantly to the population of transactions requiring further enhancement prior to valuation; faulty ticket data in the Fare Calculation field, which is critical to determining how to apply the fare rules to the transaction, and tickets that have been reissued either at the request of the passenger or as a result of changes made by the carrier e.g. irregular operations and schedule changes. While the volume of transactions with errors is not a statistically large percentage of the overall population, it is a material volume for the purposes of revenue recognition and MIS reporting. The Task Force proposal is aimed at addressing these issues as described in the Sales Processing section of the document.

The process will use a CTD e.g. the current AIA First & Final prorated sales data storage infrastructure (if it meets requirements) which will be expanded to allow for other types of passenger sales transactions. Participants will be able to view the transactions in the database based on viewership parameters coded in the system.

Interline processing will be enhanced by incorporating the use of the existing Auto-Billing functionality of SIS. This will enable users to have their billings automatically submitted as a result of providing all of

(12)

their lift data. The use of the NFP throughout the process eliminates rejections from other carriers participating in the service.

Daily and month-to-date accounting aggregation files will be provided to carriers for management monitoring. The system will prepare and provide files containing data for account posting that the carrier will upload into their ERP G/L system based on configurable aggregation levels e.g. by posting period, by sales source, by account type and other attributes that may be deemed essential for the carrier’s business needs. This will need to be further defined by the Task Force. The Task Force suggests having also the option of a file with detail level for those carriers that wish to perform aggregation based on an internally developed module for reporting into their ERP G/L.

Following is a diagram of the proposed process which includes the core functions that are required to produce outputs for carrier ERP systems. A more detailed explanation of the various functions follows in sections 5 through 10.

Overall Process Map

 

(13)

5. Sales Process

The service will include the receipt and tracking of all applicable sales reports for the carrier regardless of the reporting period. Sales reports should include the various control amounts such as:

 Gross Value Amount,  Total Remittance Amount,

 Total Commission Value Amount,  Total Tax/Miscellaneous Fee Amount,  Total Late Reporting Penalty and  Total Tax on Commission Amount.

All documents will be handled, including but not limited to, Passenger Tickets, EMDs, Agency Debit / Credit Memos (ADMs/ ACMs). The Task Force will determine the best practice in regards to the use of carrier specific documents such as Special Service tickets, Vouchers etc. All passenger accountable documents will be registered, validated and reconciled to the reported control amounts.

The outcome of the sales process is the reporting of the data necessary to enable the required accounting entries for all types of sales transaction. These will include determining unearned liability, creating revenue entries for ancillary services, determining commission and credit card fees, creating expense account entries and tax liability entries.

Unprocessed sales at accounting month-end should also be reported to allow for accounting of sales accruals.

5.1. Sales Processing General

The system will support reporting from all sales channels that carriers currently use including ARC, BSP, Carrier Own/Direct Sales including Manual Reports, as well as the Industry Sales Record (ISR).

All sales files containing Credit Card data that is subject to PCI security rules must be masked before reporting to FoRA. ARC and BSP sales reports will be processed using the most current reporting standards. These will be updated as standards are modified, saving costs for all participants. As direct sales reporting is provided in a number of ways, a standard file format will be designed that will accommodate the reporting best practice from the carriers. An optional conversion process can be created by the central service to transform carrier’s files from their own format to the FoRA standard. The process will be designed based on the sequence of the time zone of their head office in order to ensure that all closing periods can be met.

Data enhancement of the transaction detail can be provided from ATPCO sources and services including items such as:

 Codeshare and schedules data – Use of proprietary schedules data, e.g. OAG and Innovata, to more accurately assign codeshare flight information and the addition of schedules information for down-line use. Examples include arrival day/time and equipment type (the inclusion of arrival day/time also improves accuracy when determining applicable taxes).

(14)

 Bulk Tickets and Inclusive Tours (BT/IT) – ATPCO is researching the possibility to use the existing ATPCO fares/rules data to ensure the net fare is accurately populated for BT/IT tickets so that financial data is fit for use. A lifting carrier has no visibility of the values on these tickets when trying to re-accommodate a passenger; this impedes accurate interline billing and leads to rejections.

 ATPCO could use their existing fares/rules data and all of its service fees filed by the carriers to ensure that accurate data is available for reported tickets and be used for coupon level allocation when detailed data is not available on the ticket.

 ATPCO can perform validation of some ticketed fields using edits based on the ATPCO specifications that they have developed. They are also evaluating the possibility to perform systematic cleansing routines to the Fare Calculation data in order to improve automated proration and reduce the need for manual data correction.

Transactions that cannot be automatically corrected will require a solution to enable error corrections either by a centrally sourced service or in-house.

Sales transaction reporting includes accounting for all fare, taxes, fees and charges, commissions, discounts and forms of payment, along with all items reported on a sales report such as Agency Debit/Credit Memos and adjustments. All control totals provided in a sales report should be used to verify proper account totals when provided. Validations will be performed to ensure that all sale transactions are in balance before sales data for accounting is generated for the transaction.

Proration will provide coupon values for all reported sales transactions such as fare, surcharges, taxes, fees and charges YQ/YR fees, commission and discounts, ISC etc. Today the NFP engine uses the IATA Five Day Rate (FDR) of exchange based on the month of issue to convert transactions into USD whereas carriers require that the system provides coupon values in various currencies to meet their reporting requirements. A CTD will require up to four different currency types to be maintained per transaction. These include:

 The currency of the coupon amounts as ticketed.

 The carrier’s host currency e.g. a German carrier would require all transaction values be stored in Euros as their internal accounting currency.

 The lift value currency which is used to recognize revenue and to identify variances.  In the case of an interline coupon, values must also be available in the billing currency

which uses the applicable FDR or Monthly Mean Rate (MMR) for the billing period as per the Revenue Accounting Manual (RAM).

(15)

There are no standard rules to advise which rates of exchange must be used by an airline in their internal processing and so various rates are currently used by carriers. Some may use one of the industry provided rates that are based on tariff and ticketing rules:

 IATA Rate Of Exchange (IROE) which is used for converting different fares to a single currency,

 Banker’s Selling Rate (BSR) used to convert Fares and Taxes to the currency of payment, and

 FDR used for interline billings,

while others prefer to use internal Treasury Rates.

Carriers will expect the conversions for sale and lift transactions to be executed using their preferred rate of exchange. This will necessitate the maintenance of a number of conversion rates and the ability to apply the various rates based on a rules engine that caters to carrier specifications.

EMDs will be prorated where applicable (i.e. based on carrier filings) and accounted for using the appropriate accounting determination based on the Reason For Issuance Sub-codes (RFIS) provided in the transactions. Processing the various non-transport documents that have not been migrated to EMDs (e.g. vouchers, which are still in use and reported by the carriers) will be included. Where the service needs to process a document that was issued manually, the airline will need to capture this data for inclusion in a Sales Report file.

Data will be provided to carriers to enable them to manage their sales accrual process at month-end. The basis will be a comparison of sales reports processed versus the Master Data Sales calendar (see Error! Reference source not found.) for the carrier.

All transactions will be stored in the CTD.

5.2. Sales Processing – Original Sales

Original sales of tickets, EMDs, non-transport documents such as excess baggage, denied boarding compensation and other types of vouchers will be processed by the system, providing tax assignment at the coupon level as applicable. Recognition of reported commission and net fare reporting supplemental amounts, as defined in the BSP Data Interchange Specifications Handbook (DISH), will be accommodated. Carriers will be able to specify their preferred method of accounting for these values e.g. commission expense vs. net revenue.

5.3. Sales Processing – Exchanges (Other Airlines (OA) and Own sales)

When an exchange transaction is reported, the value of the surrendered coupons will be established based on the values previously stored in the CTD. The value of the new coupons will be calculated based on the value of the new ticket less the value of the surrendered coupons plus or minus any fare adjustment. Net calculation for Fare/Tax/Change Fee will be performed. The coupons that were surrendered for the new ticket are closed in the CTD as exchange usage.

(16)

5.4. Sales Processing – Refunds (OA and Own sales)

Refunds issued by sales outlets i.e. received in a sales report, will be processed. Coupons are matched to sales data (use-matched) and are closed-out in the system as refund usage. Data outputs will allow unearned revenue to be relieved and refund usage to be recorded. Appropriate accounting entries are determined for revenue, taxes, penalties and commission. Requests for refund adjustments such as involuntary downgrades, processed internally by the carrier, have been deemed out of scope as they require exception accounting.

5.5. Sales Processing – Miscellaneous Carrier Documents (non-transport)

Most non-flight related sales that are not issued on an EMD are recognized as revenue at time of sales processing. They do not follow the unearned-to-earned concept, e.g. change fees and cancellation penalties, and items such as kennels, oxygen tanks, etc.

5.6. Sales Processing – Duplicate Sales

The system will use the issue date and point of issue in conjunction with the complete ticket number in order to accommodate the recycling of ticket numbers as proposed by the IATA Ticketing Committee. In the unusual event that true duplicate sales reporting occurs (same transaction reported twice), the system will handle these transactions by recording the appropriate sales value in both cases (based on ticket numbers and sales date) and matching any usage to the appropriate transaction by comparing ticketed data to actual flight information for processing bothin the CTD and the accounting files.

(17)

6. Usage Process

Accounting standards typically require a service to be performed before the revenue is recognized. This is referred to as coupon usage. This requires a ticket database to be maintained that allows for the storage and matching of usage to sales records. (See Section 9.2)

There are a number of ways a ticket coupon can be used. Each type is detailed below.  Uplifted by the plating carrier (Lift)

 Uplifted by another carrier and billed to the plating carrier (Payable)  Exchanged for a new ticket (voluntarily or involuntarily)

 Refunded

 Not used (spoiled or aged)

 Usage reported in error (unmatched)

6.1. Lift Usage

This is the primary usage that occurs for a ticket. When it is successfully matched to a sale transaction it enables the correct revenue recognition for the service provided. Lift usage is produced from a carrier’s real-time system, eTicket Database (ETDB), Departure Control System (DCS) or from another area of the Passenger Service System (PSS). Lift files will be transmitted by the carrier to FoRA for processing. A conversion process will be developed in order to handle multiple file format submissions. In order to include any paper ticket lift information (whether originally issued as a manual ticket or as an eTicket that has been printed), the carrier must capture the required data elements and provide them in a lift file. For this a standardized file template will be developed. Lifts of Other Airlines (OA) plated tickets are discussed in Section 7. A standard process for capturing and reporting of Flight Interruption Manifests (FIMs) will also be required.

6.1.1. Carriers will require the ability to correct the detail flight data or to amend it with a pseudo flight number for specialized processing. An interface to enable manual updates to usage by the carrier will be developed to allow for exception processing e.g. reversal of erroneous usage. Processed lifts are matched against sale/ticket data stored in the CTD to retrieve the values to be used for revenue recognition. When online lifts have been matched and valued, the values from the CTD are reported to enable the airline ERP system to relieve the Forward Sales Liability account and recognize revenue.

6.1.2. In addition to ticket and EMD lifts, ancillary services that are sold on traditional non-transport documents and associated with a flight related service e.g. excess baggage, upgrades, services related to a flight (preferred seat assignments, meals, etc.) are usually recognized as revenue when flown. Carriers have developed a number of workarounds to accomplish this that may need to be accommodated. The Task Force will evaluate the options and agree a standard method of reporting.

6.1.3. Some eTicket database providers supply all final usage in a single file, i.e. lifts, blocked space, codeshare, exchange and refund usage etc. while others only provide flown data. The Task Force will determine if the process should only rely on the lift data format or if the solution should be able to process all of usage data as a preferred option when available.

(18)

6.2. Payable Usage

6.2.1. Exchange: If the eTicketing system of the plating carrier provides all final usage as described in 6.1.3 then advance notification of the intended billing will be available for analysis. The billings from other carriers processed through SIS will automatically create the payable exchange usage.

6.2.2. Reissue: Typically the usage related to the surrendered document coupons will be recorded at the time the reissue transaction is processed in sales processing. The Task Force will evaluate the potential to use additional data if the eTicketing system of the plating carrier provides all final usage as described in 6.1.3

6.2.3. Refund: Usually the usage related to the surrendered document coupons will be recorded at the time the refund transaction is processed in sales processing. The Task Force will evaluate the potential to use additional data if the eTicketing system of the plating carrier provides all final usage as described in 6.1.3.

6.3. Unearned Revenue (Spoilage / Aged Usage / Outdating)

Coupons that have not been used within a specified time-frame can be closed out (often referred to as “outdated”, “spoiled”, “spoilage” or “aged”) and accounted for as revenue. The ability to spoil certain coupons may also be dictated by the carrier’s own rules. The carrier’s auditors may advise on criteria to follow for recognition of the aged coupon revenue. Rules around the accounting for all other coupon values, e.g. taxes, must be accommodated. A process to identify tickets that are candidates for outdating will be performed by evaluating the transactions in the CTD based on the carriers’ rules.

6.4. Unmatched Usage

Unmatched usage occurs during the use-match process when a sale record was not found for the reported usage which can include lift, exchange, refund and other airline billings. It also includes usage against void and/or surface coupons and duplicate usage, where more than one usage is reported against a sale coupon. Cases of unmatched usage will be processed in different ways.

6.4.1. All exceptional usage must be corrected to ensure proper accounting. The rules engine should determine the elapsed time between the triggering event and the time when investigative action will commence. This cycle should accommodate the desired result by carrier as some types of usage may need to be handled more quickly than others. For example:

 For an OA billing, the carrier may want to correct the record in a timely fashion as it may require a rejection if there is an incorrect value being billed.

 A case of a lift usage against a ticket issued by a station that only reports periodically will be deferred to allow time for the sale to be processed.

(19)

6.4.2. The system should provide optional calculation of a default value for unmatched lifts based on criteria in the Carrier Profile Table.

6.5. Valuation

To recognize the most accurate accounting value for each event, a Data Use Hierarchy Table will be developed. The recommendation is to use the prorated value based on the source of the data available at time of processing:

1. Value calculated based on reported sale and/or applicable fare for the reported sale 2. Value calculated based on a TCN/ISR record

3. Value calculated based on proration using the lift file 4. System assigned default value

(20)

7. Interline Process

The implementation of SIS provided all carriers with a greatly enhanced process to handle their interline billings, rejections and settlements. It streamlined the existing Interline billing process by ensuring a robust and standardized reporting method for all carriers. The usage of a centralized process ensures that invoices between carriers can be efficiently generated and submitted to the Clearing Houses based on required data elements. Additionally, the Auto-Billing functionality enables a carrier to submit a usage file to SIS that is processed to create the interline billings and invoices to other carriers automatically based on the values stored in the CTD. In order to clarify the various interline processes between a Plating Carrier and a Billing Carrier, it is helpful to identify whether these carriers are on FoRA or not:

Scenario Billing Carrier Plating Carrier

A FoRA FoRA

B Traditional FoRA

C FoRA Traditional

not in scope

D Traditional Traditional

7.1. Receivables: Prime Billings invoiced by the Billing Carrier

A FoRA carrier (scenarios A and C) will transmit their usage files (see section 6) to SIS and the Auto-Billing functionality will automatically process the flown coupons to produce a billing file and an invoice based on values stored in the CTD.

The billing carrier must always have a value to bill, therefore for any missing ticket data the application of a default value as determined in the Carrier Profile Table will be required (see Usage Valuation, section 6.5) in a process to be reviewed by the Task Force

Scenario B is not applicable.

7.2. Payables: Prime Billings invoices received by the Plating Carrier

In Scenario B, the traditional billing carrier submits the invoices via SIS. The FoRA solution routes the transactions through the CTD for matching the coupons and generates an accounting entry to decrease the cash flow for the plating carrier.

In Scenario A, the FoRA billing carrier submits a usage file to SIS that triggers a single valuation and matching process into the CTD. This process will generate simultaneously the revenue recognition data for the billing carrier and the cash flow reduction accounting data for the plating carrier.

Scenario C is not applicable.

7.3. Rejections

(21)

Scenario C is not applicable to first stage rejections.

Any second or third stage rejections and correspondence would be handled via IS-WEB.

7.4. Codeshare Commission Handling

Codeshare Commission Calculation based on identification of codeshare flights and application of rates is not a standard process amongst airlines and will need to be reviewed by the Task Force to determine if manual intervention can be avoided.

(22)

8. Data Aggregations for Posting

Each of the documented processes will generate the data necessary to enable the airline’s ERP system to create individual accounting entries for every transaction. The majority of the resulting accounting entries are aggregated prior to posting to the G/L via upload files. This aggregation is required as the volume of transactions and the very large numbers of entries created during the life of a transaction could overload the ERP systems.

8.1 Accounting Files

Files will be created and made available for carriers to download as needed: daily, weekly or monthly. There will be two options available for airlines to download the data files for accounting:

8.1.1. A centralized module will be provided that will map events and generate data for accounting entries. The service will support a defined level of aggregation to be determined by the Task Force, requiring subscribers to agree to some standardization on the attributes needed to drive the aggregation routines.

8.1.2. Non-aggregated data will also be available as an option, which will require airlines to have their own mapping process to generate the accounting entries for their ERP G/L modules. A standard format will be designed that will include sufficient data elements to enable carriers to identify the types of transactions being reported and create appropriate accounting entries to their own requirements. This will also allow carriers more control over their specific accounting requirements as and when their business needs change.

8.2. Sales Accounting

The accounting feed will include the Sales Report’s control total entries as needed for the purpose of reconciling payment and receivable amounts between sales report and associated accounts in the carrier’s G/L e.g. cash and receivable amounts. At a minimum, accounting information for reported sales will be produced daily based on the receipt and processing of the sales reports. Key features of Sales Accounting should include the following:

 Establish Unearned/Air Transportation Liability (ATL) (Forward Sales Accounts) for tickets and certain ancillary services

 Recognize revenue for defined ancillary services that are not associated with in flight activity e.g. transaction fees.

 Recognize commission expense  Establish tax liabilities

 Create tax reserves for under/un-collected taxes

 Perform appropriate Form of Payment (Cash, Credit, Receivables, Other) data summarization for accounting

(23)

8.3. Usage Accounting

The usage accounting process will include the following features to feed accounting information reported daily to the ERP system:

 Recognize revenue for flown passenger tickets  Recognize revenue for flown ancillary services

 Relieve Unearned/Air Transportation Liabilities (Lifts/Exchanges/Refunds/Payables)  Provide Frequent Flyer revenue reporting

 Codeshare Commission reporting

8.4. Interline Accounting

For the interline accounting portion, the following additional processes will complete the accounting reporting from the central solution:

 Recognize revenue for flown other airline passenger tickets,  Create receivable for flown other airline passenger tickets,

 Relieve Unearned/Air Transportation Liabilities for other airline billed tickets,  Recognize Payable expense for other airline billed tickets,

 Create reserves for rejection liabilities,  Account for valuation adjustments.

(24)

9. Common Modules Used by the Centralized Process

The following are the overall process core components of the FoRA service and are utilized by the previously described processes. These include:

 The Proration module that can be used by the Sales, Lift and Interline processes

 The Central Ticket Database where all transaction data is stored for use by all of the main processes

 The Master Data Tables that will be required to store carrier preferences and rules used in processing

9.1. Proration

Proration is the determination of segment values for a transaction and is required for nearly all transactions. Proration can be performed according to Industry standards which are mandated for interline billings or by bilaterally agreed SPA. For online journeys, each carrier may decide how to apportion the revenue for online sectors. The industry standard NFP engine will be used to provide prorated coupon values for all passenger transactions based on the accepted industry processing rules and SPAs.

In addition it will assign collected values to the applicable coupons, such as:  gross fare,

 surcharges,  sales discount,  sales commission,  ticket taxes,

 fees and charges, including fuel and other surcharges.

A data enhancement module will enable additional levels of accuracy for processing the transaction data. The Task Force will investigate the possibility of defining default rules to automatically process incorrectly ticketed data.

The NFP engine will ensure the application of all appropriate proration rules including but not limited to:

 Straight Rate Proration based on both IATA and A4A rules (currently handled in the NFP engine).

 Application of SPAs (currently handled in the NFP engine). Carriers may update directly or use the services of the NFP provider for coding.

 Application of SPAs (currently handled in the NFP engine). When both carriers are using the FoRA service, the SPA only needs to be coded once.

 Exchange and reissue transactions. These are currently handled in the NFP engine but it will require enhancing to enable the complete evaluation of already flown segments of partially used tickets.

(25)

at a coupon level. The Task Force will need to assess the most effective method of allocating these taxes within the FoRA service.

 Q and YQ/YR surcharges are currently included in the coupon value. This will require sales processing to handle the detailed amounts appropriately. Alliance and Joint Venture needs may drive additional requirements. The Task Force will determine the appropriate treatment.

 Frequent Flyer Program Award valuation, currently available in NFP.  Commission and Discounts included at time of Sales Reporting.

 Recalculation at time of lift for application of correct exchange rate (currently available in NFP).

 Re-proration based on SPA application (currently available in NFP). Other areas of proration to be considered include:

 EMDs will be prorated as per industry specifications that are still in development.

 Develop FIM pricing functionality to handle both industry standards and bilateral Simplified FIM Agreements

 Prorate engine will need to be modified to retrieve coupon values from the CTD when processing exchange transactions for proper evaluation of surrendered coupons.

 The need for access to an online proration tool.

The Task Force will investigate and decide if re-proration should be employed at the time of every lift in order to determine if a change in the rate of exchange may cause a change in proration e.g. the use of the Monthly Mean Rate when exchange rates vary by more than ten percent.

9.2. Central Ticket Database and Transaction Viewer

Airline revenue accounting relies on the process of matching the various ticket/coupon usages to a sale record at a detailed level in order to comply with GAAP (Generally Accepted Accounting Principles) and IFRS (International Financial Reporting Standards) for revenue recognition. The process will use a CTD to store all transactions. This central database ensures that there can be a single version of the document available for use by all parties to the transaction whereas today every carrier creates and stores their own version of the transaction, which causes differences and disputes.

The system should also provide an online interface that allows airline staff to retrieve and display passenger transactions. This is needed in order to perform day-to-day activities such as audits, investigation of system issues, processing of refund requests, and other research-related functions. The transactions can be retrieved by ticket number and possibly other criteria e.g. list of tickets by sales location and period-end date. The display should include all information related to the sale and usage of the transaction. An interface with the CTD to provide drill down capabilities to audit and reconcile G/L entries will be required. The ability to access a transaction will be dependent on security profiles to be created. Viewership of data will be strictly controlled.

All reported sales will be stored in the CTD. The values resulting from data cleansing will be stored. The database will serve as the vehicle for revenue recognition reporting and accounting. A carrier will submit usage files to the central server that will engage the matching process to

(26)

enable the carrier to relieve forward sales liabilities for own revenue and automatically trigger the interline billing process for interline transactions.

Prorated TCN data can also be stored for the cases when usage has been reported but no reported sale is available. These cases can happen either for a ticket issued by an airline for a carrier that is not in FoRA or when lift precedes the sales report for an own sale. In the latter case, the expectation is that both current (sales report) and historical (ISR/TCN) values will be stored for revenue recognition and accounting purposes in the event that activity spans a closure period.

When a record is created by the selling carrier and processed through FoRA, any additional activity such as updates to coupon values is stored for all future accesses. This result will be used for subsequent processing while maintaining the history of the original values.

The CTD will be scalable to accommodate the volume of transactions that will be handled as the service expands to more carriers. While the current AIA prorated sales data storage infrastructure is the primary candidate for the CTD as it is already connected to SIS and the NFP engine, an evaluation is required by technical experts for its suitability to provide the functionality required for FoRA as an operational database. The CTD will need functions such as real time updates and outputs along with an expanded list of required data elements. Throughout the life cycle of a transaction, additional processes will be required such as search for aged coupons, etc.

9.3. Master Data Tables

The Master Data Tables provide the framework that houses the data needed by a central processing rules engine and are critical to the correct application of rules and subsequent reporting. An automated process to update industry standard data will be developed. Also required is an application that enables a carrier to make appropriate and timely updates to their information. This interface will provide the ability to upload the information in a standardized format as well as an online interface for manual updates.

The system will maintain and provide viewership to all applicable audit and regulatory history e.g. date of table modification and record of User ID making the update for a period of time defined by the carrier. Listed below are some of the tables and their functions that have been identified to date. Master data which is already sourced by an industry organization will be leveraged in the solution, rather than being re-developed. This will save cost and ensure alignment as well as consistency of data application.

9.3.1. System processing control tables e.g.:

 Data value hierarchy (used in determining lift valuation)

 Database access controls (data viewership for other airline transactions)  TCN use controls (to comply with GDS requirements)

(27)

9.3.2. Industry standard data e.g.:  Taxes (currently in NFP)

 Fares which include Fares, Rules, Constructed Fares, Fare by Rule, Service Fees etc. (currently in NFP)

 Fare Basis Identification (currently in NFP but should be enhanced to rely on actual fare rules)

 Prorate Factors (currently in NFP)  Mileage Tables (currently in NFP)

 Agency Master Lists (currently in NFP but needs to be enhanced for Sales Processing)

 Codeshare Flight Identification (currently in NFP)

 Other Industry standard data e.g. exchange Rates (FDR, MMR, IROE), City and Airport Codes, etc. (currently in NFP)

9.3.3. Carrier Profile Table for airline specific data including transaction processing rules, e.g.:  G/L accounting aggregation specifications

 Accounting Periods/Month-End/Year-End etc.  Processing Profile based on Head Office location

 Currency Rates of Exchange for Sales Processing, Host Currency

 Commission rules to determine who the data can be shared with i.e. for Alliances or Joint Ventures including the SPAM field (Supplemental Commission Amount) for Net Ticketing.

 Frequent Flyer (FF) processing by partner for carriers that use FF billing within revenue accounting

 Default value determination method for accruals  Identification of revenue vs. non-revenue transactions  Form of Payments accepted by the carrier

 Tour Code use for specialized treatment of transactions

 Accounting treatment for exception processes such as unmatched usage, chargebacks etc.\Station Master to define all direct reporting sales locations

 Codeshare Commission Rates if required by carriers that engage in this practice  SPAs (currently in NFP)

 Reservation Booking Designator (RBD) Mapping Table to allow for proper cabin identification

 Flight Master – used to ensure that this data is received for every flight in the airline’s schedule

 Pseudo flight numbers for exception processing

 Carrier specific use of tax codes that are used for industry discount fees, credit card fees etc.

 Sales Reporting Calendar – As sales reports are received, the calendar is updated, in order to identify missing returns.

 An Agency Master table that is enhanced with specific accounting rules by carrier e.g. assignment of cost centers

(28)

10. Non-Functional

Processes

 

10.1. Dashboards and Key Performance Indicators (KPI)

A dashboard will be available online for carrier personnel to quickly and easily ascertain the status of current and month-to-date processing volumes for each of the main processing areas such as: Sales volumes reported, Ancillary Sales information, Flown Revenue, status of Interline processing etc.

10.2. Management Information Files

An MIS extract will be provided daily to include all data elements available in the system. This will enable carriers to import the data into their own data warehouse to support their specific reporting requirements. Passenger revenue accounting data is commonly fed to up-line/down-line systems for sales and marketing purposes and for forecasting.

It is common practice for Passenger revenue accounting to be subject to government audits and reports. The system must be capable of providing the necessary information to respond to these audits.

10.3. Archive and Purge

Management of revenue accounting data typically includes the archiving of historical data and purging of production data for ticket transactions that have been fully utilized.

It is common for airlines to store only active data in the production environment, but to store fully utilized data in an offline environment where transactions can be retrieved and viewed online for research and analytical purposes. The business rules controlling archiving and purging vary widely across the industry, depending on government retention requirements and/or the size of the airline, etc.

Decisions regarding active data retention will need to be agreed or be configurable by carrier. The recommendation is to keep live data for a period of three years. Carriers that have longer data retention period requirements should plan to store the transaction data and MIS files in-house.

10.4. Audit trail

The application will maintain records of all changes to masters and parameters.

10.5. Disaster Recovery

In order to ensure Business Continuity for this core service to the Carrier, a Disaster Recovery plan along with appropriate infrastructure need to be designed and implemented. The Task Force will define specific requirements of Service Level Agreements.

(29)

Appendix A - List of FoRA Task Force Participants

 

Company Name

Air France Sophie Creusot Air New Zealand Ian Walker Air New Zealand Phil Johnson China Southern Airlines / ACCA Liu Zhiheng Delta Air Lines Harold Schwart

Etihad Airways Karuppuchamy Marimuthu Qatar Airways Andrew Rosser

ACH Lori Tully

ARC Jim Allen

ARC Shelley Younger

ATPCO Cindi Kelly

ATPCO David Smith

ATPCO Michael Clay

ATPCO Thomas Gregorson

ATPCO Melanie Desilac

SAP AG Simon Lescarcelle Oracle Corporation Baljeet Nagi Oracle Corporation Deirdre O'Reilly Oracle Corporation Vijay Anand

IATA Nicholas Coote

IATA Bernard Paul

IATA Terry Delaney

IATA Kirk Pereira

IATA Maureen Blair

IATA Adina Minculescu

IATA Gisele Aways

(30)

Appendix B - FoRA Central Process Development List

 

Sales Report Process (Section 5)

Functionality to enable processing of Sales Reports in order to generate data for accounting will be developed or acquired.

A format converter for various Direct Sales reporting standards will need to be developed. Data Cleansing to improve sale data quality and reduce exception processing will be developed (Section 5.1).

Data will be provided to carriers to enable airlines to manage their sales accrual process at month-end. The basis will be a comparison of sales reports processed versus the Master Data Sales calendar (Section 9.3.3).

Lift Processing (Section 6)

The system will need to accommodate the dual reporting of lifts if the carrier gets a file from their ET database (Section 6.1)

The central system should provide optional calculation of a default value for unmatched lifts based on criteria defined by the carrier in its Profile Table e.g. Yield Rate per O&D and Cabin or RBD or manual valuation input.

A standardized process to accept reported FIMs will be developed.

The CTD will ensure that all data received has been processed and reported. To assist carriers in their reconciliation process, a periodic report will be produced that identifies transactions with intended travel dates that have not been utilized.

A report of the average fare by cabin on each flight could be generated and reported to the carrier to facilitate revenue accruals for missing/extra passengers for its reconciliation process.

Use Match (Section 6)

A process module will be developed to match usage to sales data. Aging and reporting capability will be provided by the central solution.

To ensure timely correction of incorrectly matched accounting entries, an on-line correction screen or file upload to the CTD will be provided.

It would be beneficial if it was possible to obtain interim status from the ET system, such as suspended tickets.

(31)

Accounting Data Files (Section 8)

Accounting Data Files will be created and made available for carriers to receive as needed: daily, weekly or monthly

There are two options available for the accounting data files:

 Aggregated form: a centralized module will map events and generate accounting entries based on the aggregation rules. The Task Force will agree a standard set of attributes to be maintained in the Master Data Tables.

 Non-aggregated form: this will require airlines to have their own mapping process to generate the accounting entries for their ERP G/L modules. A standard non-aggregated format will be designed to enable carriers to identify the types of transactions being reported.

The accounting files being generated will include the sales report’s control total entries as may be needed for audit purposes.

Proration (Section 9.1)

Application of currency conversion rates other than the current use of the IATA FDR will be required for carrier sales reporting that use other rates of exchange for their sales data e.g. BSR or internal Treasury rates.

The proration process will accommodate the ability to assign a value to FIMs based on RAM rules for either traditional or Simplified FIM Agreement methodologies.

Codeshare commission calculation based on identification of codeshare flights and application of rates may be required.

Central Ticket Database (CTD) (Section 9.2)

The database must be fit for purpose to be used as an operational data store with a high level of availability to accommodate round the clock access. The database will need to be scalable to accommodate the volume of transactions to be processed. The database must be able to house all of the transaction data elements required for carriers to have a complete view of the transaction. This will include all of the transaction data elements currently provided in HOT/CAT/ISR, for coupons and EMD records. Additionally the value fields should be available for up to 4 different currencies. The database will also need to maintain all of the usage records that are generated throughout the life of the transaction and to store all of the transaction activity throughout the life cycle of a transaction.

Transaction Viewer -

The display will provide views that include all information related to the sale and usage of the transaction.

An Interface between the CTD and the carrier’s ERP system to provide drill down capabilities to audit and reconcile G/L entries will be required.

(32)

Master Data Tables (Section 9.3)

A set of Master Data Tables will be developed and housed in the central application to accommodate both the industry standard and carrier data.

The development of an application that enables a carrier to make appropriate and timely updates to the information in the tables is also required. This interface should provide the ability to upload the information in a standardized format as well as an online interface for manual updates. The system will maintain and provide viewership to all applicable audit and regulatory history e.g. date of table modification and record of User ID making the update for a period of time defined by the carrier.

MIS Files (Section 10.2)

An MIS extract will be provided that will include all data elements available in the CTD

Disaster Recovery (Section 10.4)

A Disaster Recovery (DR) plan will be required in order to ensure operational continuity for the carriers. The specific requirements of this DR plan will be defined. The recovery point objectives and Service Level Agreement will also be considered.

(33)

Appendix C - Carrier Development List

These are items that will require some development by the carriers in order to interact with the CTD.

Data Files Store (Section 5)

Carriers may wish to continue to receive and store industry files e.g. HOT, CAT, etc. for internal retention requirements.

Calculation of Accruals (Section 5 and Appendix B - FoRA Central Process

Development List)

Carriers will develop a process to determine any outstanding sales data that has not been processed in order to calculate their required sales accruals based on the data.

Format Direct Sales Reporting Files (Section 5.1)

Carriers will provide their Direct Sales Reports in a standardized format to be developed for FoRA that will accommodate the most robust data reporting standards from the carriers or use the optional conversion process.

Flight Reconciliation (Section 6)

Typically, flight data goes through a reconciliation process from the carrier’s departure control system (DCS) to the lift files to ensure that all lifts for all flights have been processed. Exceptions are created for missing flights, unexpected flights, and discrepancies between lift counts and passengers boarded for each flight. Carriers will develop a module to check the lift data processed against their DCS data as the load messages vary between carriers. Match rates can improve over time (as much as 3 days) as personnel at departure control can update the data. Flight reconciliation will be outside the scope of the centralized process.

Lift Reporting (Section 6)

In order to include any paper ticket lift information (whether originally issued as a manual ticket or as an eTicket that has been printed), the carrier must capture the required data elements and provide them in a lift file, following a standardized file template that will be defined. Reporting of FIMs will also be required.

Data Aggregation Process for Carriers receiving Accounting data files at detail level (Section 8)

If the carrier wishes to receive Accounting files in a non-aggregated format, it will need to be able to read the various indicators that will be provided in the non-aggregated file in order to determine the correct level of aggregation.

ERP Version Upgrade (Section 8)

Depending on their ERP system, carriers may need to upgrade their current version of ERP software to support new processes.

Data Warehouse

Carriers will need to have a data warehouse in order to benefit from data import capabilities to support their specific reporting requirements.

As it is only planned to store data for three years in the CTD, carriers that have longer data retention period requirements should plan to store the Accounting and MIS files in-house.

(34)

Appendix D - Open Items

The Task Force will continue to investigate and address the following items:

 Fare Basis Identification – The system should have access to all Fares filed with ATPCO. There may be value in providing a centralized service that can be used to properly categorize fares by type such as Normal vs. Special for standardized application of provisos and determining the fare to use for interline billing of private fares or involuntary reroutes of frequent flyer tickets.

 Ability to handle alliance specific process requirements, e.g. Request and Response.

 If both carriers in a transaction are using FoRA and Carrier B needs to bill Carrier A (selling carrier) for a ticket that is pending correction by Carrier A which causes Carrier B to have the data corrected, which carrier should bear the cost of such corrections?

 Further investigation is needed to determine if the re-proration for every interline billing is a system requirement or is it appropriate to just re-calculate the amount for the proper FDR?

 A situation may arise where there is a need to adjust some coupon value of the previous month. How will a carrier accomplish prior month adjustments in accounting files?

 Late arrival of commercial agreements that have an impact on already processed data.

 Daily revenue recognition could be provided when one carrier uploads a daily lift file. This process could be used to mark the selling carrier’s coupons but it would need to be flagged as “preliminarily billed” but not “settled”, when settlement actually occurs it should be updated to “settled”. It is a receivable for one carrier and payable for the other one. Would this be a carrier development?

 Is there an expectation by the carriers that the system will reconcile usage reported from their ET database with usage reported from other sources?

 How will the service handle other payable usage? e.g. Usage from a carrier that is not reporting via SIS.

 Should there be a standard template input (like pseudo IDEC or SIS manual entry) for updating non-standard usage to mark the coupon as “used”?

References

Related documents

local context, and connect with practitioners, IT experts, activists, unions, workers’ representatives, and victims to start building the research profile that can help us

With all four financing mechanisms, price control results in a price decrease in both the monopolistic and the competitive region due to the incumbent ’s strong market power.. There

Negative attitudes towards people experiencing mental illness in general hospital settings may be attributed to poor mental health literacy, skills and limited exposure,

Cardholder of the Cash Rebate Card will earn 10% Cash Rebate on such finance charges charged and such rebate will be reflected on the billed statement and

Based on the extension of Cobb-Douglas production function model,we used the 1995-2012 time series data of Chinese industrial sector to research the different sources of

Not only does the HDPE expansion socket absorb thermal expansion and contraction due to temperature changes caused by water discharge, but it also makes pipe assembly easier,

CFR: Case fatality rate; CIF: Case investigation forms; COVID-19: Coronavirus disease 2019; DOH: Department of Health; HCW: Healthcare worker; LMIC: Low and middle income;

Ambient dust concentrations and temperature and humidity values will be displayed on the LCD, and the corresponding light alert signals and sound alert signals are