Galileo 360 Fares Booking File Data Validation

Transcription

1 Galileo 360 Fares Booking File Data Validation Automated Plating Carrier Selection General Sales Agent (GSA) Validation Airline Interline Agreement Check Credit Card Validation Functional Overview Booking File Validation Checks Page 1 of 19

2 Table of Content Galileo 360 Fares Booking File Validation Process... 3 Automated Plating Carrier Selection... 4 Automated Plating Carrier Selection & Low Fare Shopping... 8 General Sales Agent (GSA) Processing... 9 Display GSA Tables Airline Interline Agreement Check How The Check Works Check at Fare Quotation Check at Ticketing Manual Check Credit Card Validation Galileo Airline Agreement Record (AAR) APIs and Structured Data Users Credit Card Security Code Validation CSC Response Codes APIs and Structured Data Users End-to-End Process Flow Booking File Validation Checks Page 2 of 19

3 Galileo 360 Fares Booking File Validation Process Some of the benefits associated with booking traditional scheduled air carriers rather than low cost airlines include that a single ticket can be used to travel on the services of more than one airline, and can be paid for with a single credit card at time of booking. However, not all airlines are in a position to accept tickets issued on behalf of another carrier. Reciprocal contracts, known as Interline Agreements are signed between carriers and determine which other airline tickets will be accepted for passenger travel. Failure to validate interline ticket acceptance between carriers can result in denied passenger carriage. Similarly, not all carriers accept all credit cards in all markets. Historically, the Galileo system has not validated credit card acceptance, placing the emphasis on the user to action manual checks. Both interline agreement and credit card acceptance policies will vary depending on the plating carrier designated for ticketing purposes. Recent enhancements to the Galileo system have provided additional validation checks to ensure itinerary and airline compatibility. This document serves as reference material in the context of system processes, but does not explicitly detail all aspects of the product offering. Booking File Validation Checks Page 3 of 19

4 Automated Plating Carrier Selection Plating Carrier selection is a vital component of any fare quote request, and determines how the Galileo system applies carrier specific YQ/YR taxes and North American Passenger Facility Charges (PFCs). The introduction of Automated Plating Carrier selection for Galileo users will enable accurate fare quotations to be returned to the user without the need for manually entering plating carrier details. This enhancement applies to all fare quote and fares shopping commands, including Fare Quote SuperBB. Plating carrier selection is controlled using the PLAT field in the agency AAT. When determining the plating carrier, the Galileo system will analyse the itinerary and make the required selection based on the following rules: A) If the journey is: Wholly within a country (or) Wholly between Canada and the USA (or) Wholly within the area comprising Denmark, Norway and Sweden The validating carrier selected will be the carrier supplying the first sector (first coupon) for transportation. B) If the journey is not one of the above and: Involves transportation between Area 1 and Area 3 via Area 2 The validating carrier selected will be the carrier performing transatlantic transportation Involves transportation between IATA traffic conference (TC) areas The validating carrier selected will be the carrier performing the first transportation between TC areas Involves transportation wholly within a TC area The validating carrier selected will be the carrier that performs the first transportation between IATA sub-areas Involves transportation wholly within a single IATA sub-area The validating carrier selected will be the carrier that performs the first international transportation C) If the sector that determines plating carrier is a surface sector, use the first carrier on the ticket At time of validation, the Galileo system will also ensure that the chosen carrier is present in the authorised plating carrier fields of the requesting agency or ticketing agency, if designated. The system will also verify that the chosen carrier has active interline agreements with all other carriers present in the itinerary as booked. Booking File Validation Checks Page 4 of 19

5 Note: Galileo subscribers will be unable to modify selected plating carrier information using ticketing modifier commands once stored. A new fare quote is required. Example Fare Quote (no plating carrier supplied): Focalpoint: >FQ PSGR FARE TAXES TOTAL PSG DES FQG 1 GBP AD GUARANTEED GRAND TOTAL INCLUDING TAXES **** GBP AD RATE USED IN EQU TOTAL IS BSR 1USD GBP AD LAST DATE TO PURCHASE TICKET: 23SEP06 AD TICKETING AGENCY E9G AD DEFAULT PLATING CARRIER UA FQ1 - S1 AP 13JUN06 XX/AG P1 TEST/GALILEO G 19JUN06 * GBP SFO UA LON M Y NUC END ROE1.0 XF 2.40SFO 4.5 FARE USD EQU GBP TAX 1.40AY TAX 7.70US TAX 2.40XF TAX 34.50YQ TOT GBP S1 FB-Y B-2PC T S1/CUA/TAE9G Viewpoint: Booking File Validation Checks Page 5 of 19

6 Example Fare Quote Best Buy (no plating carrier supplied): Focalpoint: >FQBB *** BEST BUY QUOTATION *** LOWEST FARE AVAILABLE FOR THIS ITINERARY *** REBOOK BF SEGMENTS 1H *** PSGR QUOTE BASIS FARE TAXES TOTAL PSG DES FQG 1 HHWPXO GBP AD GUARANTEED GRAND TOTAL INCLUDING TAXES **** GBP AD SUM IDENTIFIED AS UB IS A PASSENGER SERVICE CHARGE AD LAST DATE TO PURCHASE TICKET: 16JUN06 AD FARE HAS A PLATING CARRIER RESTRICTION AD TICKETING AGENCY E9G AD DEFAULT PLATING CARRIER CX TO REBOOK ENTER >FQBBK Viewpoint: Booking File Validation Checks Page 6 of 19

7 Example Fare Quote (no plating carrier supplied): 1.1TEST/GALILEO 1. UA 954 Y 23SEP SFOLHR HK #1330 O* E SA 2. VG 158 Y 25SEP LCYBRU HK O* E MO Focalpoint: >FQ NO PLATING CARRIER FOUND-INTERLINE AGREEMENT Viewpoint: The above error responses are returned as no interline agreements exist between UA and VG. During the itinerary analysis process, the Galileo system will selected UA as the plating carrier the transatlantic journey is operated by United. UA and VG do not have active interline agreements and as a result of the system automatically selecting UA as the plating carrier the error message is returned to advise the end user that plating carrier selection has failed. Similarly if the ticketing agency does not have plating authority for the carrier selected by the Galileo system at time of request a separate error message will be displayed: >FQ NO PLATING CARRIER FOUND Booking File Validation Checks Page 7 of 19

8 Automated Plating Carrier Selection & Low Fare Shopping Automated Plating Carrier functionality is compatible with SuperBB Low Fare Shopping transactions for structured data users, and Viewpoint Low Fare Shopping for offline terminal users. When activated, all results returned to screen will be inclusive of taxes and accurate carrier surcharges (Q charges, YQ, YR and XF tax values). No further manual intervention is required to ascertain accurate tax or surcharge application. In line with regular plating carrier selection processing, the results set returned by SuperBB will be dependant on the following: Valid interline agreements in existence for all carriers present in the itinerary Plating carrier authority held by the ticketing agency for each selected plating carrier Should either of these checks fail the solution will not be returned to screen. The screen extracts below highlight the price differences for identical requests with plating carrier activated. In the case of NZ between LHR and AKL, the price differential of GBP70.00 is a result of accurate application of YQ/YR surcharges for Air New Zealand following automated plating carrier selection. Without automated plating carrier selection: With automated plating carrier selection activated: Booking File Validation Checks Page 8 of 19

9 General Sales Agent (GSA) Processing As previously highlighted, the Galileo system follows a predefined list of rules when attempting to make plating carrier selection for an itinerary. In some circumstances an airline can issue a permanent instruction advising that in particular areas, ticketing for that carrier should be conducted on the plating stock of another carrier. This arrangement overrides the standard selection guideline. The most widespread and best known example of such an arrangement is the current agreement between KLM Royal Dutch Airlines and Northwest Airlines: Within IATA Area 1 all KL tickets are issued on the stock of NW For the rest of the world all NW tickets are issued on the stock of KL In France all tickets for KL and NW are issued on the stock of AF GSA tables will enable the Galileo system to store information about these agreements at three levels. Data can be used for processing at an IATA area level, ATPCO zone level and finally at country level. Example GSA processing for NW in Europe: 1.1TEST/GALILEO 1. NW 31 Y 10SEP LGWDTW HS O E SU >FQ PSGR FARE TAXES TOTAL PSG DES FQG 1 GBP AD GUARANTEED GRAND TOTAL INCLUDING TAXES **** GBP AD SUM IDENTIFIED AS UB IS A PASSENGER SERVICE CHARGE AD LAST DATE TO PURCHASE TICKET: 10SEP06 AD AD TICKETING AGENCY E9G DEFAULT PLATING CARRIER KL US PASSENGER FACILITY CHARGE NOT APPLICABLE FQ1 - S1 AP 13JUN06 83/AG P1 TEST/GALILEO G 19JUN06 * GBP LON NW DTT M Y NUC END ROE FARE GBP TAX 20.00GB TAX 7.40UB TAX 7.70US TAX 2.70XA TAX 3.80XY TAX 2.70YC TAX 29.00YR TOT GBP S1 FB-Y B-2PC T S1/CKL/TAE9G Ordinarily, the system would select NW as the plating carrier for this itinerary as they are providing transatlantic transportation. In line with GSA processing, the Galileo system automatically selects KL as the plating carrier in Europe even though KL does not form any part of the itinerary. Booking File Validation Checks Page 9 of 19

10 Displaying GSA Tables Galileo subscribers operating with an agent (AG) duty code have the ability to display the GSA tables for their country or area. For example, a user in Spain is able to view the GSA information for country Spain along with details stored for IATA Area 2. Table display may also be requested by carrier. To display by Country: T*GSA*/country code/* (eg. T*GSA*/ES/* to display tables for Spain) To display by Area: T*GSA*/area code/* (eg. T*GSA*/A2/* to display tables for AR2) To display by Country and Carrier: T*GSA*/country code/gsa carrier code (eg. T*GSA*/ES/*IB to display for IB in Spain) >T*GSA*/ES/IB SPAIN GSA AIRLINE AIRLINES REPRESENTED REG IND IB IBERIA AIRLINES OF SPAIN AH AIR ALGERIE *** *** AI AIR INDIA *** *** CU CUBANA AIRLINES *** *** EU ECUATORIANA DE AVIACION *** *** GH GHANA AIRWAYS *** *** IA IRAQI AIRWAYS *** *** JU JAT-YUGOSLAV AIRLINES *** *** ME MIDDLE EAST AIRLINES *** *** MR AIR MAURITANIE *** *** NT BINTER CANARIAS *** *** OU CROATIA AIRLINES *** *** TM LAM *** *** UM AIR ZIMBABWE (PVT) LTD *** *** NT BINTER CANARIAS *** DRY In the above example, IB has signed agreements with the 14 carriers listed for ticketing representation in the Spanish market. The function indicator field can be populated as follows: D : Domestic Itinerary Agreement R : Replace Plating (validate GSA record without checking for plating carrier) Y : Check first carrier (validate GSA record for the first carrier in the itinerary) * : Validate GSA record for all carriers in the itinerary Booking File Validation Checks Page 10 of 19

11 Airline Interline Agreement Check Paper Ticket Interline Agreement functionality provides the ability for agencies to have the Galileo system perform automated validation that the booked itinerary fits within known ticket interline agreements for the carriers concerned. Electronic Ticketing interline acceptance is validated by the carrier at time of ticketing. If the originating request from Galileo does not fall within active carrier interline agreements, the plating carrier will return an error response that prevents electronic document production. No vendor validation currently takes place for issuance of paper tickets. With these enhancements, the Galileo system is able to perform such checks at time of fare quote (including FQBB), ticketing and on demand without the need for fare quote or ticket issuance. No single industry source exists for notification of active interline agreement data. Whilst some airlines formally distribute this information using the IATA MITA service, other agreement details are obtained directly from the carrier. As a result, all checks and screen responses are advisory in nature and will not prevent the end user from issuing a ticket outside of known existing interline agreements. Interline agreement information will be held in the Galileo Airline Agreement Record (AAR). This table can be viewed at an agency level: To display: DT/IAT/AAR-DISXX (where XX is a 2 character airline code) >DT/AAR/DIS-MK AIRLINE AGREEMENT RECORD FOR: MK NAME: AIR MAURITIUS ACCT CODE: 239 CREDIT CARD ACCEPTANCE: AGREEMENTS WITH: AC AE AF AH AI AM AP AR AT AV AY AZ A3 BA BD BE BG BI BP BR BT BU BW B8 CA CE CI CO CS CU CX CY CZ DI DL DM D6 EI EK ET EY FG FI FJ FV GA GF GH GT G7 HM HP ME MH MI MK MN MS MU MX NF NH NW NX NZ OA OK OS OV OZ PG PH PK PR PS QF QM RA RB RJ R3 SA SB SK SN SQ SU SV SW S2 TC TE TG TK TM TP T4 T6 UA UL US UU UX UY VB VS WB WF ZC ZS Z2 Z9 2A 5J 9W In the sample response above, Air Mauritius has active interline agreements with 115 different airlines. Booking File Validation Checks Page 11 of 19

12 How The Check Works When the interline check is invoked the Galileo system will analyse the plating carrier present in the filed fare before determining the marketing carrier of each flight being ticketed by that fare. This information is then cross-referenced against the interline agreement list held for the plating carrier to ensure that each marketing carrier is included. In addition, the Galileo system will also validate that the ticketing agency holds plating authority for the designated plating carrier. If a marketing carrier is not present in the acceptance list of the chosen plating carrier, an onscreen warning is issued. If all interline agreement checks pass, the transaction will be completed in the normal manner. Check At Fare Quotation Interline agreement check at time of fare quote is controlled by the AAT field PCAF and when set to Y the Galileo system will perform paper ticket interline checks at time of fare quote. In order to perform accurate validation the user must include a plating carrier in the fare quotation command, or have automated plating carrier selection activated. The system will not check electronic agreements at this time. Example Interline agreement check failed: >FQ/CUA PSGR FARE TAXES TOTAL PSG DES FQG 1 GBP AD GUARANTEED GRAND TOTAL INCLUDING TAXES **** GBP AD SUM IDENTIFIED AS UB IS A PASSENGER SERVICE CHARGE AD RATE USED IN EQU TOTAL IS BSR 1USD GBP AD LAST DATE TO PURCHASE TICKET: 23SEP06 PAPER TICKET INTERLINE CHECK FAILED. UA DOES NOT ACCEPT VG > Example Plating carrier authority check failed (fare will still be filed): >FQ/CUA PSGR FARE TAXES TOTAL PSG DES FQG 1 GBP AD GUARANTEED GRAND TOTAL INCLUDING TAXES **** GBP AD SUM IDENTIFIED AS UB IS A PASSENGER SERVICE CHARGE AD RATE USED IN EQU TOTAL IS BSR 1USD GBP AD LAST DATE TO PURCHASE TICKET: 23SEP06 PLATING CARRIER AUTHORITY FOR UA NOT HELD Booking File Validation Checks Page 12 of 19

13 Check At Ticketing Interline agreement check at time of fare quote is controlled by the AAT field PCAT and when set to Y the Galileo system will perform such checks at time of ticketing. In the event of failure, the system will stop the ticketing process and return an error response. Manual ticketing override can be performed using an OV modifier (TKPOV). Interline agreement checks are invoked on TKP only. Automated checks are not performed when TMU, MCOB or MCOP commands are used. Example Interline agreement check failed: >TKP ERROR PAPER TICKET INTERLINE CHECK FAILED. UA DOES NOT ACCEPT VG Manual Check In addition to automated check at time of fare quote and ticketing, the Galileo system is also able to perform validation tasks on demand, without the need for fare quote or ticketing. Manual checks are invoked using ticketing modifier VI for Validate Interline: Example - Manual interline check with plating carrier UA (TKPVI/CUA): >TKPVI/CUA AUTH CHECK OK ELECTRONIC TICKET INTERLINE CHECK FAILED PAPER TICKET INTERLINE CHECK FAILED. UA DOES NOT ACCEPT VG Booking File Validation Checks Page 13 of 19

14 Credit Card Validation The Galileo system has not traditionally offered credit card validation functionality and as a result would complete any credit card transaction for any carrier regardless of the airline credit card acceptance policy. In some cases, the issuing agency would receive an agency debit memo from the airline to recover lost revenues. With this new enhancement, the Galileo system will reference data tables that indicate which credit card(s) are accepted for each airline. At time of ticket issuance using credit card as payment the system will cross-reference these tables to determine credit card acceptance. Should the credit card not be accepted, an error response will be returned to screen. Please note that Galileo is dependant on accurate and updated information from airlines in order to accurately reflect and enforce credit card acceptance policies. Upon initial launch the credit card acceptance tables will be set in such a way that all carriers accept all credit cards in all markets, as is the case today. As new information is received, system tables will be updated to remove acceptance for those cards that do not form part of the airline payment schemes. Credit card validation processing will be invoked using the following commands: Document Issuance (TKP) Filed Fare Update (eg: TMU1F /D0612*A12345) Manual Credit Card Authorisation (eg: JVAX /D1206/V1/MBA) Automated MCO Issuance (MCOP) Galileo currently accepts transactions for the following card types: American Express (AX) MasterCard (CA) Diners Club (DC) Japanese Credit Bureau (JC) UATP including AirPlus (TP) Visa (VI) No credit cards are accepted (XX) All credit cards are accepted (blank) Credit card validation is designed to perform checks that ensure that specific card types are accepted by a designated air carrier, and can be excepted at a local market level. Further restrictions that carriers may apply such as at least 50% of the ticket value must be held against segments operated by the plating carrier... are not validated at this time. Booking File Validation Checks Page 14 of 19

15 Galileo Airline Agreement Record (AAR) Airlines can elect to store details of their credit card acceptance policy in the Galileo Airline Agreement Record (AAR). This record also houses information regarding active interline ticketing agreements. AAR information can be displayed using DT/AAR/DIS-XX where XX is the carrier code Example Sample display for carrier BW: AIRLINE AGREEMENT RECORD FOR: BW NAME: BWIA WEST INDIES AIRWAYS ACCT CODE: 106 CREDIT CARD ACCEPTANCE: AX CA DC JC TP VI AGREEMENTS WITH: AA AC AF AH AI AM AQ AT AU AV AY AZ BA BD BE BG BP BR BU BW CI CM CO CU CY DL DM DT D6 EG EK EN ET EY FI FJ F9 GA GF GH GU HA HM HP IB IC IG IR IZ JJ JL JM KA KE KL KM KQ KU KX K9 LA LG LH LI LN LO LR LT LX LY MA MD ME MH MK MM MN MS MX NH NW NZ OA OK OS OZ PH PK PR PU PX PY PZ QF QR RG RJ SA SB SD SK SN SQ SV TA TC TF TG TK TM TP TU TZ UA UC UL UM UP US UX UY VG VS WF WM WR WT YX ZW 8B In this scenario, BWIA West Indies Airways accepts AX, CA, DC, JC, TP and VI and has active interline agreements with 130 carriers. The new processing will also be invoked in the following circumstances: Credit Verification & Authorisation JV transactions will support card acceptance functionality when the airline merchant is included in the command Ticketing Modifier Update TMU will support card acceptance and provide real time validation at time of input (TMU1F /D1206*A12345) The following transactions will not automatically invoke credit card acceptance checks: Booking File addition of credit card details in the form of payment field (F.) will not automatically invoke acceptance processing. Validation will occur at time of ticketing. Booking File Override - inclusion of F.CC in the form of payment field is not supported by the card acceptance functionality. Booking File Validation Checks Page 15 of 19

16 With the introduction of credit card acceptance checks, the following new error responses may be received in the event of failure: CARD TYPE NOT VALID FOR USE BY AIRLINE (for JV and TMU commands) FOP SELECTED NOT AUTHORIZED WITH XX (for TKP and MCOP commands) INVALID TA PSUEDO CITY CODE (used with DT/AAR display commands) APIs and Structured Data Users Credit Card acceptance functionality is available to structured data users (XML/GWS/Edifact) and can be deployed in the following transaction: Credit Authorisation <CreditCardVerification_2_0> and DPR02CRDAUT will support credit card acceptance when the airline merchant is present in the originating message. A new response message has been added: 2 CARD TYPE NOT VALID FOR USE BY AIRLINE Booking File Validation Checks Page 16 of 19

17 Credit Card Security Code Validation The credit card security code (CSC) is an important security feature for agencies that accept credit cards as form of payment. Located either on the signature strip on the reverse of the card, or above the card number, the CSC consists of 3-4 digits and varies by card type. In a customer not present environment, the CSC is an excellent tool to assist with verification that the customer does indeed have possession of the card being solicited as form of payment. The credit card association rules prohibit storage of cardholder CSC details in profiles, booking files or databases. The storage of CSC data is strictly prohibited once authorisation is complete. As a result, Galileo will not accept CSC information in any form of payment (TMU1F / F. / TKPF) entry. Each credit card company has their own brand name associated to CSC: American Express CID Diners Club CVV2 MasterCard CVC2 Visa CVV2 Using this enhancement, Galileo subscribers will be able to send a message to the issuing credit card company to request authorisation and CSC verification. The usage of CSC is optional, yet highly recommended. Should a CSC request be rejected, the issuing card company should be contacted immediately for further investigation and manual approval. CSC validation processing will be invoked using an enhanced version of existing credit authorisation formats. A new optional sub-modifier of I can be appended to the JV command for manual credit authorisation. This sub-modifier can be 3 or 4 characters in length: JVAX /D1205/T30.00/MBA/I1234 For Diners Club, MasterCard and Visa requests the screen response for this enhanced transaction will differ from that returned today. In the example response below, the first line of numeric characters represents the credit authorisation code. The second line of data indicates that the card security code has passed validation: OK M - CARD SECURITY CODE MATCHED > American Express responses remain unchanged: OK > Booking File Validation Checks Page 17 of 19

18 CSC Response Codes The following CSC response codes are used by Diners Club, MasterCard and Visa. The user response will include the actual response code returned from the vendor, part of the authorisation message and also a plain English explanation of the vendor code: M card security code matched N card security code not matched P card security code not processed S card security code should be on card U card security code not supported by issuer X card issuer system unavailable These responses will not be returned for American Express transactions as AX do not currently support unique message responses for CSC processing. Instead, AX chooses to approve or decline on a complete request basis. APIs and Structured Data Users Credit Card Security Code validation functionality is available to users of structured data (XML/GWS/Edifact) and can be deployed in the following transaction: Credit Authorisation <CreditCardVerification_2_0> and DPR02CRDAUT both support CSC validation logic. Value 4 from the card additional data indicator list is used for CSC processing. The response process will also support the additional CSC response code data based on card type used. Booking File Validation Checks Page 18 of 19

19 End-to-End Process Flow Each of the enhancements described in this document assist the travel agency subscriber with validation of booking file information. Individually they are useful tools, but combined can provide an end-to-end process that helps to eliminate fare, tax and payment errors. The workflow process outlined below is designed to highlight where each of these functions are best performed, both for traditional travel agency and online travel agent sales environments. It is recommended subject to local market notification, that both automated interline agreement check and default plating carrier selection functionality is activated Creation of Booking File Itinerary Request Automated Fare Quote Validate Passenger Credit Card Add Validated Card Details to Stored Fare Booking File Prepared for Ticketing Low Fare Shopping using SuperBB creates itineraries and prices simultaneously Default plating carrier selection results in accurate application of taxes and surcharges JV commands used to obtain approval codes for both credit limit and card security code features Input of card and approval details* as TMU real time check of plating carrier acceptance policy * CSC information must not be stored anywhere in the booking file and cannot be entered as part of a ticket modifier update (TMU) command Booking File Validation Checks Page 19 of 19