DATA APPLICATION CATEGORY 31 – VOLUNTARY CHANGES

The information contained in this document is the property of ATPCO. No part of this document may be reproduced, stored in a retrieval system, or transmitted in any form, or by any means; mechanical, photocopying, recording, or otherwise, without the prior written permission of ATPCO. Under the law, copying includes translating into another language or format. Legal action will be taken against any infringement.

Copyright © 2002 by Airline Tariff Publishing Company All rights reserved

DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Table of Contents 1.0. OVERVIEW ...... 1 1.1. DATA REQUIREMENTS...... 2 1.2. DESIGN OVERVIEW...... 2 1.2.1. Four Separate Categories ...... 2 1.2.2. Special Record Processing Flow ...... 3 1.2.3. Continued Existence of Category 16 ...... 5 2.0. DEFINITIONS AND ASSUMPTIONS ...... 7 2.1. DEFINITIONS ...... 7 2.2. ASSUMPTIONS ...... 9 2.2.1. Record Matching ...... 9 2.2.2. Partially or Fully Flown Fare Components ...... 13 2.2.2.1. No Change to Fare Break Points ...... 14 2.2.2.2. Change to Fare Break Points ...... 16 3.0. DETAILED FIELD PROCESSING ...... 17 3.1. CATEGORY 31 ...... 17 3.2. WAIVER TABLE 987 ...... 20 3.3. REISSUE TABLE 988 ...... 21 3.4. MAJOR SECTIONS OF THE OUTPUT RECORD ...... 24 4.0. PROCESSING ...... 26 4.1. ITINERARY ANALYSIS FOR HISTORICAL RECORD 2 RETRIEVAL ...... 30 4.1.1. Determine previously ticketed itinerary ...... 30 4.1.2. New Itinerary ...... 30 4.1.3. Identify all points of change ...... 31 4.1.4. Retrieve the Record 2 - Category 31 & Category 5 ...... 32 4.2. MATCH THE APPLICABLE CATEGORY 31 RECORD 3 TABLE ...... 36 4.2.1. Matching the Who fields (bytes 14-16, 51-54) ...... 37 4.2.1.1. Passenger Type Code (bytes 14-16) ...... 37

Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.2.1.2. Passenger Occurrence – First/Last (bytes 51-54) ...... 40 4.2.2. Waiver Table 987 (bytes 17-24) ...... 44 4.2.3. Matching the When fields (bytes 25-30, 44-48, 137-144) ...... 46 4.2.3.1. Ticket Validity (Byte 25) ...... 47 4.2.3.2. Departure of Journey/Pricing Unit/Fare Component (Bytes 26-28) ...... 51 4.2.3.3. Advance Reservation (Bytes 29, 30, 44-46, 47-48) ...... 69 4.2.3.4. Override Date Table No. 994 (bytes 137-144) ...... 77 4.3. DETERMINE WHETHER CHANGE IS PERMITTED ...... 78 4.3.1. Change Indicator (Byte 50) ...... 78 4.4. MATCH THE APPLICABLE TABLE 988 ...... 88 4.4.1. Travel Limit (bytes 23, 24) ...... 88 4.4.1.1. Stopover/Connection (byte 23) ...... 89 4.4.1.2. Portion (bytes 24, 25-40) ...... 96 4.4.2. Outbound Portion of Travel (byte 41) ...... 103 4.4.3. Originally Scheduled Flight (bytes 56, 209-213) – When fields ...... 107 4.4.4. Date (byte 89) ...... 132 4.4.5. Flight Number (byte 42) ...... 136 4.5. RE-PRICE THE NEW ITINERARY USING TABLE 988 ...... 145 4.5.1 Stop (Table 988 byte 206)...... 146 4.5.2. Process Tag (bytes 21-22) ...... 153 4.5.2.1. Reissue to a Lower Fare – Byte 207 ...... 218 4.5.3. Fare Break Limitations (bytes 43-46 and 48-55) ...... 219 4.5.3.1. Term (byte 43) ...... 220 4.5.3.2. 1st Break (byte 44) ...... 229 4.5.3.3. Coupon (byte 45) ...... 233 4.5.3.4. Fully Flown (byte 46) ...... 236 4.5.3.5. Same Point Table No. 993 (bytes 48-55) ...... 240 4.5.4. Fares (Table 988 bytes 57-88, 111-112, 138-145, and 214-221)...... 243 4.5.4.1. Rule Indicator (byte 57) ...... 245 4.5.4.2. Carrier Application Table 990 (bytes 58-65) ...... 247 4.5.4.3. Tariff Number (bytes 66-68) and Exclude Public/Private Indicator (byte 111) ...... 251

Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.4.4. Rule Number (bytes 69-72) ...... 258 4.5.4.5. Fare Type/Fare Class (bytes 73-85 and bytes 214-221) ...... 260 4.5.4.6. Fare Amount (byte 86) ...... 274 4.5.4.7. Normal/Special (byte 87) ...... 276 4.5.4.8. OW/RT (byte 88) ...... 276 4.5.4.9. Expand Keep (byte 112) and Seasonality/Day of Week Indicator Table 966 (bytes 138-145) ...... 279 4.5.5. Revalidate Rules/ RBDs (bytes 90-110, 121) ...... 289 4.5.5.1. Measure Advance Reservation (bytes 90-91) ...... 291 4.5.5.2. Revalidate Rules (bytes 92-110) ...... 299 4.5.5.3. Revalidate RBD (byte121) ...... 304 4.5.6. New Ticket Must Have an Equal or Higher Value – byte 208 ...... 304 4.6. CALCULATE THE APPLICABLE CHARGES ...... 311 4.6.1. Charges – Category 31 Amount (bytes 63-103) ...... 311 4.6.2. Fee Application (bytes 104-105) ...... 318 4.6.3. Discount – Category 31 Amount (bytes 108-111) ...... 339 4.7. REISSUE/REVALIDATE THE TICKET AS DIRECTED BY THE TICKET TRANSACTION FIELDS ...... 341 4.7.1. Advance Ticketing – Table 988 Ticket Reissue/revalidation (bytes 122-137) ...... 342 4.7.2. Reissue Restrictions – Table 988 Ticket TRANSACTION (bytes 165-173) ...... 343 4.7.3. Type of Ticket Transaction – Category 31 Ticket Reissue (byte 107) ...... 344 4.7.4. Residual/Penalty – Category 31 Ticket Reissue (byte 112) ...... 344 4.7.5. Residual/Penalty Hierarchy (byte 127) ...... 351 4.7.6. Form of Refund – Category 31 Ticket Reissue (byte 113) ...... 355 4.7.7. Endorsement Requirements – Category 31 Ticket Reissue (byte 114) ...... 356 4.7.8. Domestic-International Combinations– Category 31 Ticket Reissue (bytes 116-124) ...... 357 4.8. TEXT TABLE NUMBER 996 – BYTES 129-136 AND UNAVAILABLE DATA TAG – BYTE 145 ...... 389 4.9. BUILDING A DYNAMIC HIERARCHY AND RBD HIERARCHY PROCESSING ...... 393 4.9.1. Building a Dynamic Hierarchy ...... 393 4.9.2. RBD Hierarchy Processing ...... 400 4.10. FARE BREAK/JOURNEY VALIDATION...... 447 4.10.1. Fare Component Mapping ...... 448 4.10.2. Application of “Fares” fields when Fare Break Points Change ...... 450

Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.10.3. Application of Expanded Keep (Table 988 byte 112) and Seasonality/Day of Week Indicator Table 966 (Table 988 bytes 138-145) when Fare Break Points Change ...... 458 5.0. TRAVEL SEGMENT INDICATORS (TSIS) ...... 459 6.0. CODING CONVENTIONS ...... 460

Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

1.0. OVERVIEW

The Penalty category is being redesigned into four separate Categories (31-34) to provide the capability to develop automatic reissuing functionality and to better support industry developments such as Electronic Ticketing. The design goal is to enable the automation of Reissue and/or Refund transactions. To accomplish this goal, it is necessary to provide data elements for the current Category 16 Penalty statements that are located in free-form text tables. In addition, it is necessary to incorporate general rule information such as Guaranteed Air Fare Principle, Reissue & Refund handling procedures, and the methods allowed when re-pricing the itinerary (use of historical or current fares). With the inclusion of this data it is possible to process the reissue transaction programmatically, ensuring that the proper additional collection/refund amount is calculated. Today the additional collection/refund amount is generally calculated manually by each carrier, which is a very time consuming and a labor-intensive process, resulting in possible incorrect calculations.

The Category 31 – Voluntary Changes design was created by addressing all elements that are necessary for an electronic ticketing machine to process a refund or reissue transaction. The fields are grouped into the following sections, and this document is organized in these sections in order to illustrate the processing flow for applying Category 31 data: • WHO (to whom does the voluntary change data apply) • WHEN (when is the reissue transaction taking place) • NUMBER OF CHANGES PERMITTED (is the change permitted) • PROVIDED (apply the data provided that specified change conditions are met) • ITINERARY RE-PRICING RULES (provisions for re-pricing the fares and revalidating the rules) • AMOUNT (penalty amount/application) • TICKET REISSUE (reissue provisions)

Page E.03.31.001 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

1.1. DATA REQUIREMENTS

To automate the re-issuance of tickets as designed in this category, the following data requirements/capabilities are necessary:

• Historical Fares database. • Historical Rules database. • Ability to determine the previous ticketed itinerary Passenger Type • Ability to auto-price itineraries using Current Fares, Historical Fares or a combination of Historical and Current Fares. • Ability to auto-price itineraries using current or historical fare construction/pricing logic • Ability to access data relevant to the previous ticketed itinerary: TCN data, Electronic Ticket data, etc.

1.2. DESIGN OVERVIEW

1.2.1. Four Separate Categories

Automated change/cancel information will be separated into the following four categories: Category 31 – Voluntary Changes Category 32 – Involuntary Changes Category 33 – Voluntary Cancel (pending development) Category 34 – Involuntary Cancel (pending development) Separate categories are necessary because the conditions and processing of these transactions are significantly different. This design better provides the carrier with the ability to code the Involuntary Changes/Refunds information at a General Rule level, and code Voluntary Change and Refund information at the Fare Rule level, which is consistent with current filing of such provisions. Each category will contain the data elements needed to determine the changes/cancellations that are allowed, the required processing for the change/cancellation, and the associated change fee for the transaction.

Page E.03.31.002 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

1.2.2. Special Record Processing Flow

No General Rule: • Record 0 for Category 31 is not permitted. • Alternate General Rule (ALT GEN) is permitted. • When an ALT GEN is invoked, the coding of a Record 3 string in addition to the ALT GEN is not permitted.

Not Permitted for Footnotes: • Categories 31- 34 are not permitted for Footnotes.

Multiple Table Matching: • The standard Record 2 stringing elements apply, except that relational indicator AND is not valid. Any set containing AND should be ignored, and processing should continue to the next Set. • Unlike other categories, matching and validating multiple tables is possible and should be attempted for each fare component. A detailed description of matching and validating multiple tables is found in Section 4.2 of this document.

Page E.03.31.003 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Special Record Processing Flow Chart

Original Fare (Published & Constructed)

GENERAL RULE NOT PERMITTED RECORD 1 FOOTNOTE Match to fare and retrieve the indicators NOT PERMITTED that will be used to match to Record 2. Alternate General Rule

When Present, No Fare Rule data permitted. RECORD 2 Match to fare using the indicators ALTERNATE GENERAL RULE retrieved from Record 1. RECORD 2 For the Tariff, Rule, Category 31. RECORD 3 Data string referenced by the Record 2. Attempt multiple table matching for each fare component.

RESULTING PROVISIONS Resulting provisions either from Fare Rule OR (Alt) General Rule

Page E.03.31.004 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

1.2.3. Continued Existence of Category 16

ATPCO still maintains Category 16 (Penalties) in its existing format, enabling subscribers to continue using Category 16. Category 31 and its related data are provided in addition to the existing penalties category. (The design overview and the interaction between these categories are illustrated in Section 1.3 of this document.)

Page E.03.31.005 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Basic Processing Overview

Determine/ Retrieve the Determine/ Retrieve the original ticketed itinerary new (desired) itinerary

Does a new itinerary exist?

YES NO

Transaction is CHANGE (Category 31, 32*) Transaction is a REFUND (Category 33, 34*)

Is this transaction requested by the Passenger? Is this transaction requested by the Passenger?

YES NO YES NO

Process Category 31 Process Category 32 Process Category 33 Process Category 34 (Voluntary Change) (Involuntary Change) (Voluntary Cancel) (Involuntary Cancel) Quote passenger Quote passenger lowest additional lowest additional collection/ greatest collection/ greatest Assume Cancel and Assume Cancel and refund amount refund amount Startover as an option Startover as an option

NOTE: Categories 32, 33, and 34 are not yet developed. Reference to these categories reflects intended processing upon completion of development.

Page E.03.31.006 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

2.0. DEFINITIONS AND ASSUMPTIONS

2.1. DEFINITIONS

Term Definition Base Fare The fare amount excluding taxes and other charges. Any charge resulting from Category 8 (Stopover), Category 9 (Transfers), and/or Category 12 (Surcharges) processing is included in the base fare.

Current Fares Fare and applicable rule information valid for sale at the time of reissue or refund. Current fares are not mutually exclusive with historical fares. Same fares and rules may possibly still be in effect.

Domestic Fare A fare component whose origin and destination are in the same ATPCO country code or in Canada and the Component United States Historical Fares Fares and applicable rule information valid for sale at the time of the original ticketing date

International Fare A fare component that is not a domestic fare component. Component Keeping Fares Any attempt to re-price the itinerary using the same owning carrier’s fare and rule information as previously ticketed.

Original Ticket The first ticketed itinerary. If reissues have already occurred, the latest reissued ticket is not the “original ticket”.

Previous Ticket The current ticketed itinerary (latest ticketed itinerary). If reissues have already occurred, then the latest reissued ticket is the “previous ticket”. When processing the first reissue, the original ticket and previous ticket are the same.

Process Tag A number indicating the method of how to process the reissue transaction.

Page E.03.31.007 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Term Definition Second and Second and subsequent reissues are defined as tickets that are presented for reissue that contain both an original Subsequent ticketing date AND a reissued ticketing date Reissues

Terminal Points Fare break point; the ends of a fare component. Typically used when a fare has not yet been assessed for the fare component.

Ticketed Points Locations that will be reflected within the FROM/TO points of the passenger’s coupon of the ticket (connection, fare break points, stopovers).

Voluntary Change A change in the ticketed itinerary: • that the passenger requested; • where there is a replacement itinerary; and • where the ticket is reissued/revalidated. NOTE: Passengers who wish to standby for a flight will not be included in this phase of the design, as there is no ticket re-issuance/revalidation. This information will continue to be coded in Category 5 or in free-from text in Category 31 (Category 16 for Phase I) as instructed by the carrier.

Page E.03.31.008 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

2.2. ASSUMPTIONS

2.2.1. Record Matching

The system assumption differs depending upon whether an applicable (previous) Record 2 is matched and whether an applicable Record 3 is matched and passed.

Record 2: Processing will check all fare components for a matched Record 2 Category 31. If there is no matched Record 2 Category 31 for any fare component, then automated changes are not permitted. The change transaction must be processed manually. Record 3: When a Record 2 Category 31 is matched for all fare components, if there is no matched or no Record 3 is passed, the change is not permitted. Processing should treat the transaction as a cancellation (when Category 33 – Voluntary Cancel is developed, then processing should continue directly to Category 33).

Processing will take the following steps: 1) Check all fare components within the pricing unit encompassing the fare component(s) being changed: a) If there is a matched Record 2 and a matched and passed Record 3, then proceed to Step 2. b) If there is not a matched Record 2 or not a matched and passed Record 3, then apply the Record 2 system assumption above for un-matched Record 2s or the Record 3 system assumption above for un-matched Record 3s. 2) Check all other fare components within the journey (all fare components on other pricing units): a) If there is a matched Record 2 and a matched and passed Record 3, then automated changes are permitted. b) If there is not a matched Record 2 or not a matched and passed Record 3, then proceed to Step 3. 3) Determine if all travel is complete on the other fare components without a matched Record 2 or without a matched and passed Record 3. a) If all travel is complete, then automated changes are permitted. b) If all travel is not complete, then apply the Record 2 system assumption above for un-matched Record 2s or the Record 3 system assumption above for un-matched Record 3s. NOTE: If all travel is complete on the other fare components and a Record 2 is matched and a Record 3 matched and passed, then processing will re-price the itinerary as specified by the Record 3.

Page E.03.31.009 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1 – Record 2 No Match The OLD ticketed itinerary: MSP FAR travel on 01JAN97 on a Y fare of 250.00 The NEW desired itinerary: MSP FAR travel on 02JAN97

When processing Category 31 for the Y fare on the MSP-FAR fare component: • Check all fare components within the pricing unit encompassing the fare component being validated: check MSP-FAR fare component on the MSP-FAR OW pricing unit. • For the purpose of this example, processing cannot match a Category 31 Record 2 for the Y fare on the MSP-FAR fare component. • Automated reissues are not permitted. The change transaction must be processed manually.

Example 2 – Record 3 No Match The OLD ticketed itinerary: MSP FAR travel on 01JAN97 on a YSPCL fare The NEW desired itinerary: MSP FAR travel on 02JAN97 (change in date)

When processing Category 31 for the YSPCL fare on the MSP-FAR fare component: • Check all fare components within the pricing unit encompassing the fare component being validated: check MSP-FAR fare component on the MSP-FAR OW pricing unit. • For the purpose of this example, processing matches a Record 2 for the YSPCL fare, but processing cannot match any Record 3 table. The change is not permitted. The transaction must be treated as a cancellation and purchase of a new ticket. (Continue processing to Category 33 – Voluntary Cancel when developed). The previous ticketed value, less any cancellation fee, may be applied toward a new current level fare, validating all rule conditions of the new fare using the reissue date as the ticketing date.

Page E.03.31.010 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3 – Record 3 Fails The OLD ticketed itinerary: MSP FAR travel on 01JAN97 on a YSPCL fare The NEW desired itinerary: MSP FAR travel on 02JAN97 (change in date)

When processing Category 31 for the YSPCL fare on the MSP-FAR fare component: • Check all fare components within the pricing unit encompassing the fare component being validated: check MSP-FAR fare component on the MSP-FAR OW pricing unit. • For the purpose of this example, processing matches a Record 2 and Record 3 for the YSPCL fare, but processing fails the Record 3 table (and no further tables exist). • The change is not permitted. The transaction must be treated as a cancellation and purchase of a new ticket. (Continue processing to Category 33 – Voluntary Cancel when developed). The previous ticketed value, less any cancellation fee, may be applied toward a new current level fare, validating all rule conditions of the new fare using the reissue date as the ticketing date.

Page E.03.31.011 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 4 – No Match Traveled Fare Component on the Journey

The OLD ticketed itinerary: NYC-MSP RT End-on-End with MSP-FAR RT Y2 fare YSPCL fare Dept 02Jan00 Dept 10Jan00 NYC MSP FAR Dept 22Jan00 Dept 15Jan00 YAP fare YSPCL fare

On 06Jan00, passenger requests the following NEW itinerary (NYC-MSP has already been traveled): Y2 fare YSPCL fare Dept 02Jan00 Dept 10Jan00 NYC MSP FAR Dept 22Jan00 Dept 20Jan00 (change in date) YAP fare YSPCL fare

When processing Category 31 for the YSPCL fare on the MSP-FAR fare component: • Check all fare components within the pricing unit encompassing the fare component being validated: check MSP-FAR and FAR- MSP fare components on the MSP-FAR-MSP RT pricing unit. • For the purpose of the example, processing matches a Record 2 and Record 3 for the MSP-FAR and FAR-MSP fare components. • Check all other fare components within the journey (all fare components on other pricing units): check NYC-MSP and MSP-NYC fare components on the NYC-MSP-NYC RT pricing unit. • For the purpose of this example, processing matches a Record 2 and Record 3 for the YAP MSP-NYC fare component, but processing does not match any Record 2 for the Y2 NYC-MSP fare component. • All travel is already complete on the Y2 NYC-MSP fare component; therefore, automated changes are permitted.

Page E.03.31.012 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

2.2.2. Partially or Fully Flown Fare Components

This section makes reference to the RBD Answer Table record. The RBD Answer Table record is used to determine the cabin associated with specific RBDs. If processing does not match a RBD Answer Table record, the repricing engine may use whatever source is available to determine the cabin.

The following hierarchy applies to the cabins indicated in the RBD Answer Table record: (Highest to Lowest)

1. Premium First Class (Value R) 2. First Class (Value F) 3. Premium Business Class (Value J) 4. Business Class (Value C) 5. Premium Economy Class (Value W) 6. Economy Class (Value Y)

Page E.03.31.013 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

2.2.2.1. No Change to Fare Break Points

For any partially or fully flown fare component on a potential reprice solution whose fare break points have not changed:

• When the previous fare is a Normal Fare being replaced by a Normal Fare, standard fare construction processing applies including RBD validation on the replacing fare. RBD Answer Table not required.

• When the previous fare is a Normal Fare being replaced by a Special Fare, the replacing fare amount must be equal to or higher than the previous fare amount. RBD validation is not required for flown portions of the fare component. RBD validation is required for unflown portions of the fare component. RBD Answer Table not required.

• When the previous fare is a Special Fare being replaced by either a Normal or Special Fare, match the RBD Answer Table for the previous fare component (See Match Process B) and match the RBD Answer Table for the new fare component (See Match Process A). RBD validation is not required for the flown portion, however the amount and cabin of the prime RBD of the replacing fare must be equal to or higher than those of the previous fares. RBD validation is required for unflown portions of the fare component.

NOTE 1: When standard fare construction applies, the booked RBD of each sector being validated must be a valid RBD for the replacing fare. Standard Record 1 and Record 6 processing applies without validation the availability requirements indicated in Restriction Tag (byte 114) of the RBD (Reservation Booking Designator) Table Number 999. NOTE 2: When multiple prime RBDs are listed on the replacing fare’s Record 1/Category 25 Record 3, at least one of those prime RBDs must be equal to or higher than all of the previous fare’s prime RBDs and cabins.

Page E.03.31.014 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

RBD Answer Table Processing

Match Process A – (Replacing Fare Component Match Based on Prime RBD)

RBD Answer Table Data Element Matching Criteria Carrier Fare owning carrier of the replacing fare. (Bytes 4-6) Travel Effective/Discontinue Dates Travel date of the replacing fare component being validated. (Bytes 22-27/Bytes 28-33) Loc 1/Loc 2 Origin and destination of the replacing fare component. (Bytes 36-47) Global Indicator Global indicator of the replacing fare component. (Bytes 34-35) First/Last Ticketing Dates Ticketing date of the original ticket. (Bytes 48-53/Bytes 54-59)

Match Process B – (Previous Fare Component Match Based on Prime RBD)

RBD Answer Table Data Element Matching Criteria Carrier Fare owning carrier of the previous fare. (Bytes 4-6) Travel Effective/Discontinue Dates Travel date of the previous fare component being validated. (Bytes 22-27/Bytes 28-33) Loc 1/Loc 2 Origin and destination of the previous fare component. (Bytes 36-47) Global Indicator Global indicator of the previous fare component. (Bytes 34-35) First/Last Ticketing Dates Ticketing date of the original ticket. (Bytes 48-53/Bytes 54-59)

Page E.03.31.015 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

2.2.2.2. Change to Fare Break Points

For any partially or fully flown fare component on a reprice solution whose fare break points have changed, RBD Hierarchy processing applies. RBD validation is required for unflown portions of the fare component.

(See Section 4.9, Building A Dynamic Hierarchy and RBD Hierarchy Processing.)

Page E.03.31.016 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

3.0. DETAILED FIELD PROCESSING

3.1. CATEGORY 31

Byte Location Match/Action Definition/Processing Byte 1 Key Match Indicates the Record number for which the data is formatted. Record Type Byte 2 Key Match Indicates the type of processing when loading the data - either new data (add to Action Code the database) or canceled data (purge from the database). Bytes 3-5 Key Match Indicates what type of data this table contains. For Voluntary Changes, it will Category Number always be 031. Bytes 6-13 Key Match Indicates a number linking the Category 31 Record 3 to the associated Category Table Number Control Record (Record 2). Byte 14-16 Match Identifies the passenger type for which the Record 3 table is applicable. Matches PTC- Passenger Type Code to the passenger at the time of previous ticket issuance. Byte 17-24 Match A number associated with a type of waiver code. The table is applied only when a Waiver Table Number 987 waiver condition applies. If processing a reissue without a waiver, a match to this field only occurs when the table is value ‘0000000’. Byte 25 Match Indicates that the Record 3 table only applies for changes made prior to the ticket Ticket Validity validity of the previous ticket. Byte 26-28 Match Indicates that the Record 3 table applies only for changes made prior to or after Departure of Journey/Pricing departure of the previous ticketed Journey, Pricing Unit, or Fare Component. unit/Fare Component Byte 29-30 and 44-48 Match Indicates that the Record 3 table applies only for changes being made within the Advance Reservations specified advance reservation requirements. Included in these fields are the measurement points (from point to point) of where the advance reservation requirements are to be calculated and the advance reservation period for the reissue transaction.

Page E.03.31.017 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Byte Location Match/Action Definition/Processing Bytes 31-43 and 49 Reserved for future use. Reserved Byte 50 Action Indicates that the change is not permitted or limits the number of times the ticket Change Indicator may be reissued. Bytes 51-54 Match Indicates that the Record 3 table applies for the specified number of passengers Passenger Occurrence traveling together. If the number of passengers traveling together that wish to reissue exceeds the number specified, processing must find another table that may be applied. Bytes 55-62 Action Identifies a table number containing specific information regarding how to re- Reissue Table Number 988 price the itinerary. Byte 63-103 Action Identifies the change fee/service charge applicable to any change which matched Amounts this table and was re-priced using the Table 988. The change fee/service charge may be stated as an amount or percent. Included in these fields is a minimum amount and indicator to apply either the higher or lower of the two, when both an amount and percent are coded. Bytes 104-105 Action Identifies how the penalty fee/service charge is to be assessed. Fee Application Bytes 106 Reserved for future use. Reserved Byte 107 Action Indicates whether the ticket must be reissued or revalidated. Type Ticket Byte 108-111 Action Indicates up to four types of discounts that apply to the change fee/service charge. Discount The discount level (percent) for Infant, Child, Youth and Senior Discounts will be conveyed in Category 19 and/or Category 22 of the previous fare.

Page E.03.31.018 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Byte Location Match/Action Definition/Processing Byte 112 Action Indicates how the difference in fare amount and the change fee/service charge are Residual/Penalty to be resolved when the ticket is reissued. Always add collect the difference in fares plus any applicable change fee/service charge, if the new itinerary is greater than the remaining value of the existing ticket. If the new itinerary is less, either: 1. Ignore the residual value and add collect that change fee, 2. Refund the residual and add collect the change fee, or 3. Subtract the change fee from residual and refund as specified in byte 113. Byte 113 Action Indicates that any calculated refund amount must be given back to the passenger Form of Refund as a Credit Voucher, Scrip, MCO, or as a refund in the previous form of payment. Byte 114 Action Indicates whether the endorsement box of the reissued ticket should include the Endorsement Requirements higher non-refundable amount in lieu of, or in addition to, the previous Category 18 provisions. Bytes 115 Reserved for future use. Reserved Bytes 116-124 Action Indicates whether reissue provisions of the fare component may be overridden by Domestic-International those of a international fare component on the ticket. Has no impact when filed Combinations with an international fare. Bytes 125-126 Reserved for future use. Reserved

Byte 127 Action Indicates how to resolve conflicting values of Residual/Penalty (byte 112) Residual/Penalty Hierarchy Bytes 128 Reserved for future use. Reserved Bytes 129-136 Action Refers to a table number that contains free-form text regarding Category 31. The Text Table Number 996 information within this table is not automated. NOTE: Text Table 996 is not available at this time.

Page E.03.31.019 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Byte Location Match/Action Definition/Processing Bytes 137-144 Match Refers to a table number that defines reservations, ticketing, and/or travel dates to Override Date Table Number which the voluntary changes apply. The Override Date Table data must match 994 the reservation, ticketing, and/or travel dates of the new itinerary for the Category 31 and Table 988 data to apply. Bytes 145 Action Indicates that this fare cannot be used for auto-pricing purposes or that the Record Unavailable Data Tag 3 contains free-form text information only. NOTE: Text Table 996 is not available for input as part of Phase I

3.2. WAIVER TABLE 987

Byte Location Match/Action Definition/Processing Byte 1 Key Match Indicates the Record number for which the data is formatted. Record Type Byte 2 Key Match Indicates the type of processing to be taken in connection to the transaction; Action either new data or canceled data. Bytes 3-5 Key Match A number indicating what type of data this table contains. (Always 987) Table Identification Number Bytes 6-12 Key Match Indicates a number that links the Table 987 Record 3 to the associated Category Table Number Record (Record 3). Bytes 13-14 Action Identifies the number of occurrences of bytes 15-16 occur. Number of Segments Bytes 15-16 Action Identifies the waiver condition. Waiver Value NOTE: Table 987 is a Match field for Category 31 Record 3 validation; however, data fields within Table 987 are action fields.

Page E.03.31.020 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

3.3. REISSUE TABLE 988

Byte Location Match/Action Definition/Processing Byte 1 Key Match Indicates the Record number for which the data is formatted. Record Type Byte 2 Key Match Indicates the type of processing when loading the data - either new data (add to Action Code the database) or deleted data (purge from the database). Bytes 3-5 Key Match A number indicating what type of data this table contains (always 988). Table Identification Number Bytes 6-13 Key Match Indicates a number linking the Reissue Table 988 to the associated Category 31 Table Number Record 3. Bytes 14-20 Action Identifies the order in which entries for the same Process Tag within a table Sequence Number number are to be processed. Sequence number between Process Tags has no application. Bytes 21-22 Action Indicates the method of how to process the reissue transaction. Process Tag Bytes 23-40 Match/Action Indicates the portion of travel that may or may not be changed in order to apply Travel Limitations the associated Table 988 entry. Byte 41 Match Indicates if changes to the outbound portion of travel, as defined by this byte, are Outbound portion of Travel allowed in order to apply associated Table 988 entry. Byte 42 Match Specifies whether change to flight number(s) is permitted. Flight Number Bytes 43-46 and 48-55 Action A series of indicators which state the limitation on the fares and fare breaks that Fare Break Limitations may be used when re-pricing according to this Table 988 entry. Byte 47 Reserved for future use. Reserved Byte 56 Match Indicates that the change must be requested before/after the previously scheduled Originally Scheduled Flight flight for any unused flights being re-priced in order to use the associated Table 988 entry.

Page E.03.31.021 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Byte Location Match/Action Definition/Processing Bytes 57-88 Action Indicates the type or amount of replacement fares that may be used when re- Fares pricing per this 988 entry. Byte 89 Match Indicates that that the new travel date must be the same or different date as the Date previously ticketed travel date. Bytes 90-110 Action Indicates the fare rules that must be revalidated when re-pricing the itinerary. Revalidating Rules Bytes 92-110 apply only when keeping the same fare as ticketed. Byte 111 Action Indicates whether qualifying private tariff fares may be used when re-pricing per Exclude Private this 988 entry. Byte 112 Action Defines the meaning of “Keep the Fare” for Process Tag (bytes 21-22) value 01. Expand Keep Bytes 113-120 Reserved for future use. Reserved Byte 121 Action Indicates that the RBD does or does not need to be revalidated when re-pricing RBD the itinerary. Bytes 122-137 Action Indicates advance ticketing requirements that must be met for the new Advance Ticketing transaction. Bytes 138-145 Action Indicates the Seasonality and/or Day of Week indicators with the Fare Basis Code Seasonality/Day of Week for the purposes of Expand Keep (byte 112). Indicator Table 966 Bytes 146-164 Reserved for future use. Reserved Bytes 165-173 Action Indicates the sales restrictions for the new transaction. Sales Restrictions Bytes 174-205 Reserved for future use. Reserved Byte 206 Action Indicates to stop processing within the same Process Tag and continue to the next Stop sequence for the next Process Tag or to discard all permutations in which every fare component does not contain Stop field value Y.

Page E.03.31.022 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Byte Location Match/Action Definition/Processing Byte 207 Action Indicates provisions to be used when Process Tag 7 is selected. Reissued to a Lower Fare Byte 208 Action Indicates that the total value of the new ticket or total nonrefundable value of the New Ticket Equal or Higher new ticket must be equal to or higher than the previous ticket. Bytes 209-213 Match Specifies whether the change request for the first un-flown sector of the fare Originally Scheduled Flight component being validated must be a specified Period/Unit before or after Period/Unit (depending upon the value in byte 56) the scheduled departure of the flight. Bytes 214-221 Action Indicates the Fare Type of replacement fares that may be used when re-pricing Fare Type Table 974 per this 988 entry Bytes 222 Reserved for future use. Reserved

Page E.03.31.023 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

3.4. MAJOR SECTIONS OF THE OUTPUT RECORD

Voluntary change information can be divided into major sections as detailed on the chart below:

SECTION SOURCE FIELDS Location Field Name Match/Action WHO Category 31 Bytes 14-16 Passenger Type Code Match Bytes 51-54 Passenger Occurrence – First/Last Match

WHEN Category 31 Byte 25 Ticket Validity Match

Bytes 26-28 Journey/Pricing Unit/Fare Component Match Bytes 29-30 and 44- Advance Res (note bytes 31-43 are reserved) Match 48 Bytes 137-144 Override Date Table 994 Match

NUMBER OF CHANGES PERMITTED Category 31 Byte 50 Change Indicator Action

PROVIDED Table 988 Byte 23, 24-40 Travel Limit (Stop/Cnx, Portion) Match/Action

Byte 41 Outbound Portion of Travel Match

Byte 56 Originally Scheduled Flight Match

Byte 89 Date Match

ITINERARY RE-PRICING RULES Table 988 Bytes 21-22 Process Tag Action

Byte 43-46 Fare Break Limitations Action and 48-55 Byte 57-88 Fares Action Bytes 90-91 Measure Advance Res Action Bytes 92-110 Revalidate Rules Action Byte 111 Exclude Public/Private Indicator Action Byte 112 Expand Keep Action Byte 121 Revalidate Booking Codes Action Bytes 138-145 Seasonality/Day of Week Indicator Table 966 Action ITINERARY RE-PRICING RULES CONT. Table 988 Bytes 214-221 Fare Type Table 974 Action

Page E.03.31.024 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

SECTION SOURCE FIELDS Location Field Name Match/Action Byte 206 Stop Action Byte 207 Reissue to a Lower Fare Action

Byte 208 New Ticket Equal or Higher Action

AMOUNT Category 31 Bytes 63-103 Charges – Amount/Percent/High/Low/Min Action

Bytes 104-105 Fee Application Action Bytes 108-111 Discount Action

TICKET REISSUE Category 31 Byte 107 Type of Ticket Transaction Action Byte 112 Residual Penalty Action Byte 113 Form of Refund Action Byte 114 Endorsement Requirements Action Byte 127 Residual/Penalty Hierarchy Action Table 988 Bytes 122-137 Advance Ticketing Action

Byte 165-173 Transaction Restrictions Action

These sections reflect the organization of the data and the general flow of how text will appear. They do not necessarily reflect the method or order for data processing. Processing explanation for these sections is covered in Section 4.0 of this document.

Page E.03.31.025 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.0. PROCESSING

When a voluntary change transaction is requested, processing will attempt to match a Record 2 in order to determine the applicable Category 31 provisions that apply to the fare component being validated. After a Record 2 is matched, the next step is to compare the itinerary to a Category 31 Record 3 Table based on the Category 31 match fields. Once a match is made to the Category 31 match fields, processing will next compare the itinerary to the Table 988 match fields. When a match is made to Table 988, processing will apply the re-pricing, charge amounts, and reissue restrictions contained within Category 31 and Table 988 entry.

When the fare component being validated does match to the Category 31 Record 3: • Processing will attempt to match the first Table 988 sequence. ⇒ If the first Table 988 sequence is matched, then apply the re-pricing, charge amounts, and reissue restrictions contained within the Category 31 Record 3 and Table 988 sequence. Continue processing to the next table 988 sequence number attempting to match and apply the provisions. ⇒ If the first Table 988 sequence is not matched, then continue processing to the next table 988 sequence attempting to match and apply the provisions. ⇒ Processing will attempt to match all Table 988 sequences. The re-pricing, charge amounts, and reissue restrictions that produce the best result for the passenger will be applied. • When Table 988 Stop field byte 206 is value X, then processing will continue to the next Table 988 sequence that contains a different Process Tag value in Table 988 bytes 21-22. Processing may still continue to another Category 31 Record 3 table and process any Table 988 sequences. • When Table 988 Stop field byte 206 is value Y in every fare component in a reprice solution and Process Tag bytes 21-22 is value 1, then processing will discard all permutations in which every fare component does not contain Stop field byte 206 value Y or in which Process Tag bytes 21-22 is not value 7. • Once all Table 988 sequences have been processed, continue processing to the next Category 31 record 3 table in the string. NOTE: Relational indicator AND is not valid for Category 31. If a record table is received with relational indicator AND, then processing should ignore the entire Category 31 set containing the AND table and continue processing to the next set.

When the fare component being validated does not match to the Category 31 Record 3: • Processing will continue to the next Category 31 record 3 table in the string.

Page E.03.31.026 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

NOTE: Relational indicator AND is not valid for Category 31. If a record table is received with relational indicator AND, then processing should ignore the entire Category 31 set containing the AND table and continue processing to the next set.

The processing flowcharts on the following page illustrate the intended application of Category 31. This chart does not necessarily reflect the processing of any specific CRS/GDS.

Page E.03.31.027 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Matching the Voluntary Change Data

4.1 Itinerary Analysis for Historical Record 2 Retrieval:

• Determine the previously ticketed itinerary. (fare components, fare combinations, ticket issuance date, and ticketed fare

classes)

• Determine the new (desired) itinerary.

• Identify all points of change (e.g. carrier code, class of service, ticketed travel points, travel dates, flights). • Retrieve the Record 2(s) for Categories 31 & 5 for each fare component on the previous ticket. EXCEPTION: For second and subsequent reissues -- If the historical Category 31 data cannot be determined, before proceeding follow the steps for second and subsequent reissues detailed in section 4.1.4.

4.2 Match the applicable Category 31, Record 3 Table (based on WHO, WAIVER, and WHEN fields): • Passenger Type Code (bytes 14-16) • Waiver Table 987 (bytes 17-24) • Ticket Validity (byte 25) • Departure of J/PU/FC (bytes 26-28)

• Advance Reservations (bytes 29-48)

• Passenger Occurrence (bytes 51-54)

• Override Date Table 994 (bytes 137-144)

4.3 Determine Whether Changes Permitted (ACTION Validation): • Change Indicator (byte 50)

4.4 Match the applicable Table 988 based on PROVIDED fields: • Travel Limitations (bytes 23-40) • Originally Scheduled Flight (byte 56) • Date (byte 89)

Page E.03.31.028 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Applying the Voluntary Change Data

4.5 Re-price the new itinerary as directed by the Table 988 ITINERARY RE-PRICING RULES fields. • Process Tag (bytes 21-22) • Fare Break Limitations (bytes 43-46 and 48-55) • Fares (bytes 57-88) • Revalidating Rule/RBD Conditions (bytes 90-110, 121)

• Stop (byte 206)

4.6 Calculate the Applicable Charges • Table 988 ITINERARY RE-PRICING AMOUNT fields • Category 31 AMOUNT fields

4.7 Reissue the ticket as directed by the TICKET REISSUE fields Use the method that provides the passenger with the smallest additional collection/largest refund as determined from the processing steps above.

The following pages detail the processing for all of the fields in Category 31 and Table 988. Data is organized according to the order of the above flow chart rather than the order of the bytes in the record layout.

Page E.03.31.029 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.1. ITINERARY ANALYSIS FOR HISTORICAL RECORD 2 RETRIEVAL

4.1.1. Determine previously ticketed itinerary

Determine the previously ticketed itinerary (includes identifying the fare components, fare combinations, ticket issuance date, ticketed fare class codes, carriers, flight numbers, stopovers, connections, travel dates, travel times, and RBDs). This information is used to: • Identify all points of change (refer to Section 4.1.3 below). • Retrieve the Record 2s for Categories 5 and 31 for each fare component on the previous ticket (refer to Section 4.1.4 below). • Match to the WHEN fields in Category 31 (refer to Section 4.2 below). • Re-price the itinerary (refer to Section 4.5 below)

4.1.2. New Itinerary

The new itinerary must be determined. This information is used to: • Identify points of change (refer to Section 4.1.3 below) • Match to the WHEN fields in Category 31 (refer to Section 4.2 below). • Match to the PROVIDED fields in Table 988 (refer to Section 4.4 below). • Re-price the itinerary (refer to Section 4.5 below).

Page E.03.31.030 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.1.3. Identify all points of change

Determine all points of change within the itinerary. This information is used to determine what fare component and pricing units are affected by the change. Determination of all points of change is achieved by comparing each flight segment (defined as carrier code, flight number, ticketed travel points, travel dates, and travel times) on the previously (most recently) ticketed itinerary to each flight segment on the new itinerary. The transaction is considered a change once a flight segment on the new itinerary does not match the previous itinerary. Exception: the confirmation/wait listing of an open segment is not considered a change to that flight segment’s carrier code, flight number, departure date or departure time. The determined point(s) of change will be used for processing data in Table 988.

Example Carrier Class of Sac Fare Component Travel Date Original NW Y MSP LON 01JAN 01 Itinerary NW Y LON MSP 20JAN 01 New NW Y MSP LON 01JAN 01 Itinerary NW Y LON MSP 31JAN 01 change

Point of change = LON-MSP (travel date)

Page E.03.31.031 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.1.4. Retrieve the Record 2 - Category 31 & Category 5

Processing will retrieve the historical Record 2s for Category 31 and Category 5 for each of the fare components on the previously ticketed itinerary (each fare component on the currently ticketed journey). This Record 2 data will be used to determine the applicable Voluntary Change and Ticketing Time Limit information for each fare component (refer to Section 4.2 in this document for an explanation of validation of Ticketing Time Limit based on Category 5 data).

All data from the previously ticketed itinerary (including but not limited to ticketed fare class code, fare break points, and travel dates) should be used to determine the Category 31 Record 2 that was in effect on the date the previous ticket was issued (the historical Record 2 for Category 31) and the Category 5 Record 2 that was in effect on the date the previous ticket was issued (the historical Record 2 for Category 5). Any IF condition in Category 31 to another category will also be validated using all data from the previously ticketed itinerary (for example, THEN Cat 31 IF Cat 3 – conditions in Category 3 will be validated using travel dates on the previously ticketed itinerary). If no Category 31 Record 2 exists for all fare components within the pricing unit on the previous ticket, or if travel within the pricing unit has been partially completed and any untraveled fare components have no Category 31 Record 2, then apply the system assumption – ticket must be manually reissued. If a Category 31 Record 2 is found, processing will attempt to match the Record 3 table and begin the voluntary change process specified.

Multiple Reissues Processing must retain any non-refundable data from fares on the original ticket. When multiple reissues occur, processing will validate Category 31 data for the fares on the previous ticket, processing must also consider any non-refundable restrictions from the original ticket. NOTE: Determination of how to maintain data from the originally ticketed itinerary is at the discretion of each subscriber.

Page E.03.31.032 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example (Category 31 Record 2 Match) Category 31 Record 2 Bytes 24-30 Bytes 31-36 Bytes 37-42 Bytes 43-50 Bytes 73-79 Bytes 80-86 Bytes 103- Byte Bytes 107-117 Seq # Loc 1 Loc 2 Fare Class Eff Date Dis Date 105 106 Cat/Tbl # # Segs RI 0001000 Blank Blank YNR 01OCT99 01NOV00 001 T 031-1234 02NOV00 999999 001 T 031-2345 0002000 Blank Blank Y 15NOV99 999999 001 T 031-3333

Original Ticketed Itinerary: NYC-LON OW fare component Ticket Issue Date: 01Aug99 Fare Class Code: YNR (non-refundable/change fee applies)

Dept 31Oct00 NYC LON

Passenger requests ticket reissue on 20Nov 00 for the following new itinerary: NYC-LON OW fare component Ticket Reissue Date: 20Nov00 Fare Class Code: Y (fully refundable/no change fee)

Dept 01Dec00 NYC LON

Based on the Category 31 Record 2 data above: • Processing will match the applicable Record 2 based on the original ticketed itinerary: original fare class code – YNR, and original travel date from departure of journey origin – 31Oct00. • Match Sequence 1000 effective 01Oct99 through 01Nov00 for the YNR fare class code, and apply Category 31 table 1234.

Page E.03.31.033 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Passenger requests another ticket reissue on 21Nov 00 for the following new itinerary: NYC-LON OW fare component Ticket Reissue Date: 21Nov00 Fare Class Code: Y (fully refundable/no change fee)

Dept 02Dec00 NYC LON

Based on the Category 31 Record 2 data above: • Processing will match the applicable Record 2 based on the previously ticketed itinerary: previous fare class code – Y, and previous travel date from departure of journey origin – 01Dec00. Match Sequence 2000 effective for the Y fare class code, and apply Category 31 table 3333.

Page E.03.31.034 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Exception for Second and Subsequent Reissues – Category 31 & Category 5

When processing a second or subsequent reissue, if processing cannot determine the historical Cat 31 data that was used to create the first or subsequent reissued ticket then the following steps apply (second and subsequent reissues are defined as tickets that are presented for reissue that contain both an original ticketing date AND a reissued ticketing date):

1. For the fare component being validated, attempt to match same fare basis code and amount for fares valid at the time of original ticket issue date. • If the match is found and a Category 31 is present, process the category. • If the match is not possible or if a match is possible and a Category 31 is not present – attempt to match fares valid at the time of the original ticket dates as follows: • Using the Ticket Designator find fares with the same fare basis code, and/or • Adjusting for Mileage find fares with the same fare basis code and amount, and/or • Adjusting for ZP/PFC find fares with the same fare basis code and amount. o If the fare is matched and a Category 31 is present, process the category. o If the fare is matched and a Category 31 is not present – Go to Step 2, or if fare is not matched Go to Step 2 2. For the fare component being validated, attempt to match same fare basis code and amount for fares valid at the time of reissue ticket issue date. • If the match is found, process the category accordingly • If the match is not possible or if a match is possible and a Category 31 is not present – attempt to match fares valid at the time of the reissue ticket date as follows: • Using the Ticket Designator find fares with the same fare basis code, and/or • Adjusting for Mileage find fares with the same fare basis code and amount, and/or • Adjusting for ZP/PFC find fares with the same fare basis code and amount. o If the fare is matched and a Category 31 is present, process the category. o If the fare is matched and no Category 31 is present – Go to Step 3, or if fare is not matched Go to Step 3. 3. Manually reissue the ticket.

Page E.03.31.035 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.2. MATCH THE APPLICABLE CATEGORY 31 RECORD 3 TABLE

The match fields for Category 31 are: 4.2.1 WHO Fields (bytes 14-16, 51-54) 4.2.2 Waiver Table 987 (bytes 17-24) 4.2.3 WHEN fields (bytes 25-48, 137-144).

Unlike other categories, matching to multiple tables should be attempted for each fare component. Processing will attempt to match an applicable Category 31 Record 3 for each fare component on the original itinerary. A blank in any of the match fields is considered a match to any data. The relationship between the match fields is AND; processing must match all match fields in order to apply the Category 31 Record 3 table. If a match is made to all match fields within the table, then apply the voluntary change information contained within the Category 31 and Table 988 (provided processing also matches all match fields within at least one Table 988 sequence). Processing will still read on to the next table, attempting to match and apply the change information. If a match is not made to all match fields within the Category 31 Record 3 table, continue processing to the next Category 31 Record 3 table in the String. If another table is not found or matched, apply the system assumption (the change is not permitted, must cancel and purchase a new ticket). A detailed description of how to match each of the Category 31 match fields is provided below (matching to Table 988 is described in Section 4.4 of this document).

Page E.03.31.036 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.2.1. Matching the Who fields (bytes 14-16, 51-54)

The WHO fields indicate the Passenger Type Code (bytes 14-16) and Passenger Occurrence (bytes 51-54) for which the change data in the Record 3 table applies.

4.2.1.1. Passenger Type Code (bytes 14-16)

The Passenger Type Code on the Record 3 validates against the passenger on the previously ticketed itinerary. The passenger status at the time of previous ticket issuance is used to match bytes 14-16, regardless of the passenger status at the time of reissue. NOTE: That when re-pricing the itinerary, a check may be required to determine the passenger status at the time of reissue in order to determine what type of fares may be applied in the re-price process.

Page E.03.31.037 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1

THEN Record 3 Bytes 14-16 Bytes 55-62 PTC Reissue Table 988 MIL 333122 OR Record 3 Bytes 14-16 Bytes 55-62 PTC Reissue Table 988 BLANK 123456 The data indicates that the conditions in Table 988 #333122 (and any other applicable change information within the Category 31 table) apply when the passenger status at the time of previous ticket issuance was MIL; or the conditions in Table 988 #123456 (and any other applicable change information within the Category 31 table) apply for any passenger status at the time of previous ticket issuance.

Passenger purchases a Y fare on 01Jan00. • Passenger qualifies for the fare as an ADT passenger.

Passenger requests a change to the fare on 01Nov00. • Passenger qualifies as a military passenger at the time of change request. • Processing resolves to the above Category 31 Record 3s for the previous fare. • Passenger status was ADT at the time of previous ticket issuance; therefore, processing will no match the first Category 31 Record 3 table and read on to the next table. Processing will match the second Category 31 Record 3 and apply Table 988 #123456 and any other applicable change information within the Category 31 table.

Page E.03.31.038 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2

THEN Record 3 Bytes 14-16 Bytes 55-62 PTC Reissue Table 988 YTH 123456 The data indicates that the conditions in Table 988 #123456 (and any other applicable change information within the Category 31 table) apply when the passenger status at the time of previous issuance was YTH.

Passenger purchases a Youth fare on 01Jan00. • The Youth fare applies to YTH passengers age 18-24. • Passenger is 24 years of age at the time of purchase and qualifies for the fare as a YTH passenger.

Passenger requests a change to the fare on 01Nov00. • Passenger is now 25 years of age at the time of change request. • Processing resolves to the above Category 31 Record 3 for the previous fare. Passenger status was YTH at the time of previous ticket issuance; therefore, processing will match the above Category 31 Record 3 and apply Table 988 #123456 and any other applicable change information within the Category 31 table.

Page E.03.31.039 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.2.1.2. Passenger Occurrence – First/Last (bytes 51-54)

The Passenger Occurrence data specifies the number of passengers traveling together (per PNR) that may make changes to the ticketed itinerary at the change fee specified within the Record 3 table. Bytes 51-54 provide the ability to specify a first through last occurrence of passengers traveling together. When data is present in these fields, processing must compare the specified occurrence to the number of passengers per PNR requesting changes. If the number of passengers requesting a change is within the specified occurrence, then processing will match the Record 3 table (provided that a match is also made to all other match fields). If the number of passengers requesting a change is less than the specified occurrence, then processing will no match the Record 3 table and continue processing, attempting to match another Record 3 table. (Example: specified occurrence is 03 through 06, and two passengers traveling together are requesting a change. Processing will no match this Record 3 table.) If the number of passengers requesting a change is greater than the specified occurrence, then processing may match the Record 3 table for the number specified in the occurrence fields (provided that a match is also made to all other match fields) and continue processing to another Record 3 table for the remainder of the passengers. (Example: specified occurrence is 01 through 03, and five passengers traveling together are requesting a change. Processing may match the Record 3 table for the first through third passenger and attempt to match another table for the fourth and fifth passengers.)

When bytes 51-54 are Blank, there are no restrictions on the number of passengers traveling together that may make changes to the ticketed itinerary at the specified change fee.

Page E.03.31.040 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1

THEN Record 3 Bytes 51-52 Bytes 53-54 Bytes 55-62 Bytes 63-73 First Occurrence Last Occurrence Reissue Table 988 Amount/Currency 01 01 333122 100.00 USD The data indicates that for passengers traveling together in the same PNR, the conditions in Table 988 #333122 and a penalty charge of USD 100.00 apply for the first passenger. If no further Category 31 tables exist or are matched for the second through last passengers, then the change is not permitted for those passengers.

Passengers requesting a change: Change restriction/fee application: 1 passenger traveling alone: Change permitted as specified by Table 988 for USD 100.00. 2 passengers traveling together (same PNR): Change permitted for the first passenger as specified by Table 988 for USD 100.00. Change not permitted for the second passenger unless another Category 31 table exists and is matched.

Page E.03.31.041 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2

THEN Record 3 Bytes 51-52 Bytes 53-54 Bytes 55-62 Bytes 63-73 First Occurrence Last Occurrence Reissue Table 988 Amount/Currency 01 03 333122 100.00 USD OR Record 3 Bytes 51-52 Bytes 53-54 Bytes 55-62 Bytes 63-73 First Occurrence Last Occurrence Reissue Table 988 Amount/Currency 04 06 123456 150.00 USD The data indicates that for passengers traveling together in the same PNR, the conditions in Table 988 #333122 and a penalty charge of USD 100.00 apply for the first through third passengers. The conditions in Table 988 #123456 and a penalty charge of USD 150.00 apply for the fourth through sixth passengers. If no further Category 31 tables exist or are matched for the seventh through last passengers, then the change is not permitted for those passengers.

Passengers requesting a change: Change restriction/fee application: 1 passenger traveling alone: Change permitted as specified by Table 988 #333122 for USD 100.00. 2 passengers traveling together (same PNR): Change permitted for both as specified by Table 988 #333122 for USD 100.00 each. 3 passengers traveling together (same PNR): Change permitted for all as specified by Table 988 #33122 for USD 100.00 each. 4 passengers traveling together (same PNR): Change permitted for the first three passengers as specified by Table 988 #333122 for USD 100.00 each. Change permitted for the fourth passenger as specified by Table 988 #123456 for USD 150.00 6 passengers traveling together (same PNR): Change permitted for the first three passengers as specified by Table 988 #333122 for USD 100.00 each. Change permitted for the fourth through sixth passengers as specified by Table 988 #123456 for USD 150.00 each. 8 passengers traveling together (same PNR): Change permitted for the first three passengers as specified by Table 988 #333122 for USD 100.00 each. Change permitted for the fourth through sixth passengers as specified by Table 988 #123456 for USD 150.00 each.

Page E.03.31.042 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Change not permitted for the seventh through eighth passengers unless another Category 31 table exists and is matched.

Page E.03.31.043 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.2.2. Waiver Table 987 (bytes 17-24)

The waiver values are maintained in a separate waiver table that is referenced from the Category 31 Record 3. The following waiver values are available in Waiver Table 987:

Value Explanation 01 Death 02 Illness 03 Acts of God (application of this value is at the discretion of the subscriber) 04 Court Appearance 05 Military 06 Tour Package 07 Lack of Proper Travel Documentation 08-20 Reserved for future use

Table 987 provides the ability to enter a single waiver value per segment, and up to 20 recurring segments are available (note that since only seven waiver values are currently defined, no more than 7recurring segments should be entered). The relationship among the recurring segments is OR; therefore, only one recurring segment in Table 997 must be validated in order to match the table. Once a match is made, processing must still match the remaining Category 31 match fields in order to match the Record 3 table. The inclusion of a waiver value in Category 31 provides the ability to indicate that the data contained within the Category 31 Record 3 table only applies for a specific waiver condition/s (provided that a match is also made to all other match fields). NOTE: The application of Waiver information differs in Category 31 from Category 16 (Penalties). In Category 16, the waiver fields are used to indicate that when specified waiver conditions apply, then the penalty charge is not applicable. In Category 31, the waiver table is used to indicate that when specified waiver conditions apply, then the change conditions and applicable charges apply.

The actual carrier requirements defining each waiver condition are not defined for Voluntary Changes at this time. The exact definition of each waiver condition is left to agent determination. Validation of the waiver value(s) is done by comparing agent input to the specified waiver value.

Page E.03.31.044 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example

THEN Record 3 Bytes 17-24 Bytes 55-62 Waiver Table 987 Reissue Table 988 01 123456 02 The data indicates that the conditions in Table 988 (and any other applicable change information within the Category 31 table) apply when the change is requested due to death or illness.

Passenger requests a change due to illness: • Agent indicates that the change is being request due to an illness. • Processing resolves to the above Category 31 Record 3 for the previous fare.

Processing will match the above Category 31 Record 3 table based on waiver value 02. Apply Table 988 #123456 and any other applicable change information within the Category 31 table.

Page E.03.31.045 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.2.3. Matching the When fields (bytes 25-30, 44-48, 137-144)

To match the WHEN fields, processing must determine when the passenger is requesting the change in relation to the previously ticketed itinerary or the new itinerary, depending upon the field being validated.

Following is a list of WHEN fields and a brief explanation of their validation: WHEN Condition Validation Ticket Validity (byte 25) Is travel on the new itinerary prior to the expiration of the previous ticket validity? Departure of Journey (byte 26) Is the change request before or after the date of departure from the origin of the Journey on the previous ticket? Departure of Pricing Unit (byte 27) Is the change request before or after the date of departure from the origin of the Pricing Unit on the previous ticket? Departure of Fare Component (byte 28) Is the change request before or after the date of departure from the origin of the Fare Component on the previous ticket? Advance Reservation (bytes 29-30 and Is the reissue request being made in accordance with the advance reservation period 44-48) specified in Category 31? Override Date Table 994 (bytes 137-144) Are the travel, ticketing, and reservation dates of the new itinerary before or after the specified travel, ticketing, and reservation override dates?

Page E.03.31.046 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.2.3.1. Ticket Validity (Byte 25)

The Ticket Validity field is used to specify whether the Voluntary Change data applies based on the ticket validity date of the previous itinerary.

When byte 25 is value X, processing must determine the last date of ticket validity of the original itinerary. Determination of ticket validity is based on the carrier’s general rule (tickets are usually valid one year from original ticket issuance date). Ticket Validity must be determined regardless of whether an actual ticket is being presented for change or if original ticketing data is only available in a PNR. Once the ticket validity date is identified, processing must determine whether all travel on all fare components of the new itinerary commences before this date. If all travel on the new itinerary commences prior to the ticket validity date, then processing will match the Category 31 Record 3 table (provided that a match is also made to all other match fields). If any travel on the new itinerary commences on/after the ticket validity date, then processing will no match the Category 31 Record 3 table.

When byte 25 is value BLANK, then processing will match byte 25 regardless of the ticket validity of the previous itinerary. The ticket validity date of the previous itinerary has no impact the requested change. All travel on the new itinerary may occur before or after the previous ticket validity date.

Page E.03.31.047 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1 – Value X

THEN Record 3 Byte 25 Bytes 55-62 Tkt Validity Reissue Table 988 X 123456 The data indicates that when all travel on the new itinerary commences before the previous ticket validity date, then the conditions in Table 988 #123456 (and any other applicable change information within the Category 31 table) apply.

Original Itinerary: FAR-MSP OW Pricing Unit End-on-End with MSP-SEA RT Pricing Unit (inbound via DTT) Ticket Issue Date = 01Jan00 Dept 01Oct00 Dept 02Oct00 FAR MSP SEA DTT Dept 30Oct00 Dept 30Oct00

New itinerary requested on 01Sep00: Ticket (Re) Issue Date = 01Sep00 Dept 01Oct00 Dept 02Oct00 FAR MSP SEA SFO Dept 28Dec00 (change in Date) Dept 28Dec00 (change in Loc and Date)

When validating the MSP-SEA and SEA-MSP fare components that resolve to the above Category 31 Record 3: • Processing must determine the previous ticket validity date: 01Jan01 (assume carrier’s general rules states ticket is valid one year from date of ticket issuance). • All travel on the new itinerary commences before 01Jan01; therefore, processing will match the table (provided that a match is also made to all other match fields). NOTE: Processing must also validate Category 31 data for the FAR-MSP fare component.

Page E.03.31.048 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

New itinerary requested on 15Sep00: Dept 31Dec00 (change Date) Dept 10Mar01 (change in Date) FAR MSP SEA SFO Dept 02Aug01 (change in Date) Dept 20Sep01 (change in Date)

When validating the MSP-SEA and SEA-MSP fare components that resolve to the above Category 31 Record 3: • Processing must determine the previous ticket validity date: 01Sep01 (assume carrier’s general rules states ticket is valid one year from date of issue). • All travel on the new itinerary is not before 01Sep01; therefore, processing will no match the table, and read on to another table. NOTE: Processing must also validate Category 31 data for the FAR-MSP fare component.

Page E.03.31.049 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2 – Value BLANK

THEN Record 3 Byte 25 Bytes 55-62 Tkt Validity Reissue Table 988 BLANK 123456 The data indicates that the conditions in Table 988 #123456 (and any other applicable change information within the Category 31 table) apply, regardless of the previous ticket validity date.

Original Itinerary: FAR-MSP OW Pricing Unit End-on-End with MSP-SEA RT Pricing Unit (inbound via DTT) Ticket Issue Date = 01Jan00 Dept 01Oct00 Dept 02Oct00 FAR MSP SEA DTT Dept 30Oct00 Dept 30Oct00

New itinerary requested on 15Sep00: Dept 20Nov00 (change in Date) Dept 01Jan01 (change in Date) FAR MSP SEA SFO Dept 08Jan01 (change in Date) Dept 08Jan01 (change in Loc and Date)

When validating the MSP-SEA and SEA-MSP fare components that resolve to the above Category 31 Record 3: • Processing will match the table (provided that a match is also made to all other match fields). NOTE: Processing must also validate Category 31 data for the FAR-MSP fare component.

Page E.03.31.050 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.2.3.2. Departure of Journey/Pricing Unit/Fare Component (Bytes 26-28)

These fields specify whether the Voluntary Change data applies for changes made before or after the passenger’s actual departure date from the origin of the journey, pricing unit, or fare component on the previous ticket, as follows: • Journey: Byte 26 provides the ability to specify that the date of change must be before (value B) or after (value A) the passenger’s departure date from the origin of the Journey on the previous ticket. When byte 26 is Blank, there is no restriction on whether the change request is made before or after the passenger’s departure date of the Journey on the previous ticket. • Pricing Unit: Byte 27 provides the ability to specify that the date of change must be before (value B) or after (value A) the passenger’s departure date from the origin of the Pricing Unit on the previous ticket. When byte 27 is Blank, there is no restriction on whether the change request is made before or after the passenger’s departure date of the Pricing Unit on the previous ticket. • Fare Component: Byte 28 provides the ability to specify that the date of change must be before (value B) or after (value A) the passenger’s departure date from the origin of the Fare Component on the previous ticket. When byte 28 is Blank, there is no restriction on whether the change request is made before or after the passenger’s departure date of the Fare Component on the previous ticket. NOTE: Passenger’s departure may differ from the scheduled departure time. For example, flight may be scheduled to depart at 8:00, but passenger did not travel on this flight. Passenger presents ticket for change at 9:00. Validation would be before departure because passenger has not actually departed on the flight. Flight may be scheduled to depart at 8:00, but flight is delayed and actually departs at 9:00. If passenger traveled on the flight at 9:00 and presents the ticket for change at 11:00, then validation would be after departure because passenger has actually departed on the flight.

Within the same Category 31 Record 3 table, data may be present in bytes 26, 27, and 28; however, edits prevent entering an invalid combination of values. For example, byte 26 (Journey) cannot be value B (before departure) with byte 27 (Pricing Unit) value A (after departure). Likewise, byte 28 (Fare Component) cannot be value A (after departure) with byte 26 (Journey) value B (before departure).

Page E.03.31.051 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Examples 1 through 7 on the Following Pages Use the Original and New Itineraries Below:

Original Itinerary: NYC-CHI-NYC RT Pricing Unit End-on-End with CHI-LAX-CHI RT Pricing Unit (inbound via DEN) Ticket Issue Date = 01Jan 01 Dept 25Jan01 Dept 03Feb01 NYC CHI LAX Dept 28Feb01 DEN Dept 15Feb01 Dept 15Feb01 Ticketing Information: Carrier Flight Date Sector UA 100 25JAN 01 NYC-CHI UA 200 03FEB 01 CHI-LAX UA 300 15FEB 01 LAX-DEN UA 400 15FEB 01 DEN-CHI UA 500 28FEB 01 CHI-NYC

New itinerary A – requested on 15Jan 01 (passenger has not traveled on any portion of the journey): Dept 28Jan01 (change) Dept 10Feb01 (change) NYC CHI LAX Dept 28Feb01 DEN Dept 15Feb01 Dept 15Feb01 Ticketing Information: Carrier Flight Date Sector UA 101 28JAN 01 NYC-CHI CHANGE UA 210 10FEB 01 CHI-LAX CHANGE UA 300 15FEB 01 LAX-DEN No change UA 400 15FEB 01 DEN-CHI No change UA 500 28FEB 01 CHI-NYC No change

Page E.03.31.052 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

New itinerary B – requested on 05Feb 01 (passenger has traveled NYC-CHI only) Dept 28Jan01 Dept 10Feb01 NYC CHI LAX Dept 28Feb01 DEN Dept 20Feb01 (change) Dept 20Feb01 (change) Ticketing Information: Carrier Flight Date Sector UA 101 28JAN 01 NYC-CHI No change UA 210 10FEB 01 CHI-LAX No change UA 320 20FEB 01 LAX-DEN CHANGE UA 430 20FEB 01 DEN-CHI CHANGE UA 500 28FEB 01 CHI-NYC No change

Page E.03.31.053 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1 (Journey – Before Departure)

THEN Record 3 Byte 26 Byte 27 Byte 28 Bytes 55-62 Journey Pricing Unit Fare Reissue Table 988 Component B BLANK BLANK 123456 The data indicates that when the change is requested before the departure date from the origin of the journey on the previous ticket, then the conditions in Table 988 #123456 (and any other applicable change information within the Category 31 table) apply.

The NYC-CHI, CHI-NYC, CHI-LAX, and LAX-CHI fare components in the original itinerary resolve to the above Category 31 Record 3.

Processing New Itinerary A requested on 15Jan01: When validating the NYC-CHI fare component: Match • Change is requested on 15Jan 01 which is before the date of departure from the origin of the journey on the previous ticket (NYC depart 25Jan 01). • Processing will match the table (provided that a match is also made to all other match fields). NOTE: The same processing and results apply for the CHI-NYC, CHI-LAX, and LAX-CHI fares components.

Processing New Itinerary B requested on 05Feb01: When validating the NYC-CHI fare component: No Match • Change is requested on 05Feb 01 which is after the date of departure from the origin of the journey on the previous ticket (NYC depart 28Jan 01). • Processing will no match the table. NOTE: The same processing and results apply for the CHI-NYC, CHI-LAX, and LAX-CHI fares components.

Page E.03.31.054 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2 (Journey – After Departure)

THEN Record 3 Byte 26 Byte 27 Byte 28 Bytes 55-62 Journey Pricing Unit Fare Reissue Table 988 Component A BLANK BLANK 123456 The data indicates that when the change is requested after the departure date from the origin of the journey on the previous ticket, then the conditions in Table 988 #123456 (and any other applicable change information within the Category 31 table) apply.

The NYC-CHI, CHI-NYC, CHI-LAX, and LAX-CHI fare components in the original itinerary resolve to the above Category 31 Record 3.

Processing New Itinerary A requested on 15Jan01: When validating the NYC-CHI fare component: No Match • Change is requested on 15Jan 01 which is before the date of departure from the origin of the journey on the previous ticket (NYC depart 25Jan 01). • Processing will no match the table. NOTE: The same processing and results apply for the CHI-NYC, CHI-LAX, and LAX-CHI fares components.

Processing New Itinerary B requested on 05Feb01: When validating the NYC-CHI fare component: Match • Change is requested on 05Feb 01 which is after the date of departure from the origin of the journey on the previous ticket (NYC depart 28Jan 01). • Processing will match the table (provided that a match is also made to all other match fields). NOTE: The same processing and results apply for the CHI-NYC, CHI-LAX, and LAX-CHI fares components.

Page E.03.31.055 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3 (Pricing unit – Before Departure)

THEN Record 3 Byte 26 Byte 27 Byte 28 Bytes 55-62 Journey Pricing Unit Fare Reissue Table 988 Component BLANK B BLANK 123456 The data indicates that when the change is requested before the departure date from the origin of the pricing unit on the previous ticket, then the conditions in Table 988 #123456 (and any other applicable change information within the Category 31 table) apply.

The NYC-CHI, CHI-NYC, CHI-LAX, and LAX-CHI fare components in the original itinerary resolve to the above Category 31 Record 3.

Processing New Itinerary A requested on 15Jan01: When validating the NYC-CHI and CHI-NYC fare components: Match • Change is requested on 15Jan 01 which is before the date of departure from the origin of the pricing unit on the previous ticket (NYC depart 25Jan 01). • Processing will match the table (provided that a match is also made to all other match fields).

When validating the CHI-LAX and LAX-CHI fare components: Match • Change is requested on 15Jan 01 which is before the date of departure from the origin of the pricing unit on the previous ticket (CHI depart 03Feb 01). • Processing will match the table (provided that a match is also made to all other match fields).

Processing New Itinerary B requested on 05Feb01: When validating the NYC-CHI and CHI-NYC fare components: No Match • Change is requested on 05Feb 01 which is after the date of departure from the origin of the pricing unit on the previous ticket (NYC depart 28Jan 01). • Processing will no match the table.

Page E.03.31.056 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

When validating the CHI-LAX and LAX-CHI fare components: Match • Change is requested on 05Feb 01 which is before the date of departure from the origin of the pricing unit on the previous ticket (CHI depart 10Feb 01). • Processing will match the table (provided that a match is also made to all other match fields).

Page E.03.31.057 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 4 (Pricing unit – After Departure)

THEN Record 3 Byte 26 Byte 27 Byte 28 Bytes 55-62 Journey Pricing Unit Fare Reissue Table 988 Component BLANK A BLANK 123456 The data indicates that when the change is requested after the departure date from the origin of the pricing unit on the previous ticket, then the conditions in Table 988 #123456 (and any other applicable change information within the Category 31 table) apply.

The NYC-CHI, CHI-NYC, CHI-LAX, and LAX-CHI fare components in the original itinerary resolve to the above Category 31 Record 3.

Processing New Itinerary A requested on 15Jan01: When validating the NYC-CHI and CHI-NYC fare components: No Match • Change is requested on 15Jan 01 which is before the date of departure from the origin of the pricing unit on the previous ticket (NYC depart 25Jan 01). • Processing will no match the table.

When validating the CHI-LAX and LAX-CHI fare components: No Match • Change is requested on 15Jan 01 which is before the date of departure from the origin of the pricing unit on the previous ticket (CHI depart 03Feb 01). • Processing will no match the table.

Processing New Itinerary B requested on 05Feb01: When validating the NYC-CHI and CHI-NYC fare components: Match • Change is requested on 05Feb 01 which is after the date of departure from the origin of the pricing unit on the previous ticket (NYC depart 28Jan 01). • Processing will match the table (provided that a match is also made to all other match fields).

Page E.03.31.058 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

When validating the CHI-LAX and LAX-CHI fare components: Match • Change is requested on 05Feb 01 which is before the date of departure from the origin of the pricing unit on the previous ticket (CHI depart 10Feb 01). • Processing will no match the table.

Example 5 (Fare Component – Before Departure)

THEN Record 3 Byte 26 Byte 27 Byte 28 Bytes 55-62 Journey Pricing Unit Fare Reissue Table 988 Component BLANK BLANK B 123456 The data indicates that when the change is requested before the departure date from the origin of the fare component on the previous ticket, then the conditions in Table 988 #123456 (and any other applicable change information within the Category 31 table) apply.

The NYC-CHI, CHI-NYC, CHI-LAX, and LAX-CHI fare components in the original itinerary resolve to the above Category 31 Record 3.

Processing New Itinerary A requested on 15Jan01: When validating the NYC-CHI fare component: Match • Change is requested on 15Jan 01 which is before the date of departure from the origin of the fare component on the previous ticket (NYC depart 25Jan 01). • Processing will match the table (provided that a match is also made to all other match fields).

When validating the CHI-NYC fare component: Match • Change is requested on 15Jan 01 which is before the date of departure from the origin of the fare component on the previous ticket (CHI depart 28Feb 01). • Processing will match the table (provided that a match is also made to all other match fields).

Page E.03.31.059 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

When validating the CHI-LAX fare component: Match • Change is requested on 15Jan 01 which is before the date of departure from the origin of the fare component on the previous ticket (CHI depart 03Feb 01). • Processing will match the table (provided that a match is also made to all other match fields).

When validating the LAX-CHI fare component: Match • Change is requested on 15Jan 01 which is before the date of departure from the origin of the fare component on the previous ticket (LAX depart 15Feb 01). • Processing will match the table (provided that a match is also made to all other match fields).

Processing New Itinerary B requested on 05Feb01: When validating the NYC-CHI fare component: No Match • Change is requested on 05Feb 01 which is after the date of departure from the origin of the fare component on the previous ticket (NYC depart 28Jan 01). • Processing will no match the table.

When validating the CHI-NYC fare component: Match • Change is requested on 05Feb 01 which is before the date of departure from the origin of the fare component on the previous ticket (CHI depart 28Feb 01). • Processing will match the table (provided that a match is also made to all other match fields).

When validating the CHI-LAX fare components: Match • Change is requested on 05Feb 01 which is before the date of departure from the origin of the fare component on the previous ticket (CHI depart 10Feb 01). • Processing will match the table (provided that a match is also made to all other match fields). When validating the LAX-CHI fare components: Match • Change is requested on 05Feb 01 which is before the date of departure from the origin of the fare component on the previous ticket (LAX depart 15Feb 01). • Processing will match the table (provided that a match is also made to all other match fields).

Page E.03.31.060 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 6 (Fare Component – After Departure)

THEN Record 3 Byte 26 Byte 27 Byte 28 Bytes 55-62 Journey Pricing Unit Fare Reissue Table 988 Component BLANK BLANK A 123456 The data indicates that when the change is requested after the departure date from the origin of the fare component on the previous ticket, then the conditions in Table 988 #123456 (and any other applicable change information within the Category 31 table) apply.

The NYC-CHI, CHI-NYC, CHI-LAX, and LAX-CHI fare components in the original itinerary resolve to the above Category 31 Record 3.

Processing New Itinerary A requested on 15Jan01: When validating the NYC-CHI fare component: No Match • Change is requested on 15Jan 01 which is before the date of departure from the origin of the fare component on the previous ticket (NYC depart 25Jan 01). • Processing will no match the table.

When validating the CHI-NYC fare component: No Match • Change is requested on 15Jan 01 which is before the date of departure from the origin of the fare component on the previous ticket (CHI depart 28Feb 01). • Processing will no match the table.

When validating the CHI-LAX fare component: No Match • Change is requested on 15Jan 01 which is before the date of departure from the origin of the fare component on the previous ticket (CHI depart 03Feb 01). • Processing will no match the table.

Page E.03.31.061 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

When validating the LAX-CHI fare component: No Match • Change is requested on 15Jan 01 which is before the date of departure from the origin of the fare component on the previous ticket (LAX depart 15Feb 01). • Processing will no match the table.

Processing New Itinerary B requested on 05Feb01: When validating the NYC-CHI fare component: Match • Change is requested on 05Feb 01 which is after the date of departure from the origin of the fare component on the previous ticket (NYC depart 28Jan 01). • Processing will match the table (provided that a match is also made to all other match fields).

When validating the CHI-NYC fare component: No Match • Change is requested on 05Feb 01 which is before the date of departure from the origin of the fare component on the previous ticket (CHI depart 28Feb 01). • Processing will no match the table.

When validating the CHI-LAX fare component: No Match • Change is requested on 05Feb 01 which is before the date of departure from the origin of the fare component on the previous ticket (CHI depart 10Feb 01). • Processing will no match the table.

When validating the LAX-CHI fare component: No Match • Change is requested on 05Feb 01 which is before the date of departure from the origin of the fare component on the previous ticket (LAX depart 15Feb 01). • Processing will no match the table.

Page E.03.31.062 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 7 (Mixture of Journey/Pricing Unit/Fare Component)

THEN Record 3 Byte 26 Byte 27 Byte 28 Bytes 55-62 Journey Pricing Unit Fare Reissue Table 988 Component A BLANK B 123456 The data indicates that when the change is requested after the departure date from the origin of the journey on the previous ticket and before departure from the origin of the fare component on the previous ticket, then the conditions in Table 988 #123456 (and any other applicable change information within the Category 31 table) apply.

The NYC-CHI, CHI-NYC, CHI-LAX, and LAX-CHI fare components in the original itinerary resolve to the above Category 31 Record 3.

Processing New Itinerary A requested on 15Jan01: When validating the NYC-CHI fare component: No Match • Change is requested on 15Jan 01 which is before the date of departure from the origin of the journey on the previous ticket (NYC depart 25Jan 01) and before the date of departure from the origin of the fare component on the previous ticket (NYC depart 25Jan 01). • Processing will no match the table.

When validating the CHI-NYC fare component: No Match • Change is requested on 15Jan 01 which is before the date of departure from the origin of the journey on the previous ticket (NYC depart 25Jan 01) and before the date of departure from the origin of the fare component on the previous ticket (CHI depart 28Feb 01) • Processing will no match the table.

Page E.03.31.063 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

When validating the CHI-LAX fare component: No Match • Change is requested on 15Jan 01 which is before the date of departure from the origin of the journey on the previous ticket (NYC depart 25Jan 01) and before the date of departure from the origin of the fare component on the previous ticket (CHI depart 03Feb 01). • Processing will no match the table.

When validating the LAX-CHI fare component: No Match • Change is requested on 15Jan 01 which is before the date of departure from the origin of the journey on the previous ticket (NYC depart 25Jan 01), and before the date of departure from the origin of the fare component on the previous ticket (LAX depart 15Feb 01). • Processing will no match the table.

Processing New Itinerary B requested on 05Feb01: When validating the NYC-CHI fare component: No Match • Change is requested on 05Feb 01 which is after the date of departure from the origin of the journey on the previous ticket (NYC depart 28Jan 01) and after the date of departure from the origin of the fare component on the previous ticket (NYC depart 28Jan 01). • Processing will no match the table.

When validating the CHI-NYC fare component: Match • Change is requested on 05Feb 01 which is after the date of departure from the origin of the journey on the previous ticket (NYC depart 28Jan 01) and before the date of departure from the origin of the fare component on the previous ticket (CHI depart 28Feb 01). • Processing will match the table (provided that a match is also made to all other match fields).

When validating the CHI-LAX fare components: Match • Change is requested on 05Feb 01 which is after the date of departure from the origin of the journey on the previous ticket (NYC depart 28Jan 01) and before the date of departure from the origin of the fare component on the previous ticket (CHI depart 10Feb 01). • Processing will match the table (provided that a match is also made to all other match fields).

Page E.03.31.064 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

When validating the LAX-CHI fare components: Match • Change is requested on 05Feb 01 which is after the date of departure from the origin of the journey on the previous ticket (NYC depart 28Jan 01) and before the date of departure from the origin of the fare component on the previous ticket (LAX depart 15Feb 01). • Processing will match the table (provided that a match is also made to all other match fields).

Page E.03.31.065 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 8 (Matching Multiple Record 3 Tables)

Original Itinerary: FAR-MSP OW Pricing Unit End-on-End with MSP-DTT-MSP RT Pricing Unit Dept 01Jan01 Dept 04Jan01 FAR MSP DTT Dept 10Jan01

Ticketing Information: Carrier Flight Date Sector Fare Class NW 100 01JAN 01 FAR-MSP Y26 NW 140 04JAN 01 MSP-DTT BE70 NW 280 10JAN 01 DTT-MSP BE70

New itinerary – requested on 05Jan 01 (passenger has traveled FAR-MSP and MSP-DTT): Dept 01Jan01 Dept 04Jan01 FAR MSP DTT Dept 11Jan01 (change) Ticketing Information: Carrier Flight Date Sector NW 100 01JAN 01 FAR-MSP NW 140 04JAN 01 MSP-DTT NW 240 11JAN 01 DTT-MSP

Page E.03.31.066 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Category 31 Record 2 = Y26 fare THEN Record 3 Table 123 = Byte 26 Byte 27 Byte 28 Bytes 55-62 Journey Pricing Unit Fare Reissue Table 988 Component B BLANK BLANK 123456 OR Record 3 Table 456 = Byte 26 Byte 27 Byte 28 Bytes 55-62 Journey Pricing Unit Fare Reissue Table 988 Component A BLANK BLANK 234567 The data indicates that for Y26 fare class: • When the change is requested before the departure date from the origin of the journey on the previous ticket, then the conditions in Table 988 #123456 (and any other applicable change information within the Category 31 table) apply. • When the change is requested after the departure date from the origin of the journey on the previous ticket, then the conditions in Table 988 #234567 (and any other applicable change information within the Category 31 table) apply.

When validating the Y26 FAR-MSP fare component that resolves to the Category 31 data above: Match Table 456 • Change is requested on 05Jan 01 which is after the date of departure from the origin of the journey on the previous ticket (FAR depart 01Jan 01). • Processing will no match Table 123 and will match Table 456 (provided that a match is also made to all other match fields).

Page E.03.31.067 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Category 31 Record 2 = BE70 fare THEN Record 3 Table 111 = Byte 26 Byte 27 Byte 28 Bytes 55-62 Journey Pricing Unit Fare Reissue Table 988 Component B BLANK BLANK 111111 OR Record 3 Table 222 = Byte 26 Byte 27 Byte 28 Bytes 55-62 Journey Pricing Unit Fare Reissue Table 988 Component A A BLANK 222222 OR Record 3 Table 333 = Byte 26 Byte 27 Byte 28 Bytes 55-62 Journey Pricing Unit Fare Reissue Table 988 Component BLANK BLANK B 333333 The data indicates that for BE70 fare class: • When the change is requested before the departure date from the origin of the journey on the previous ticket, then the conditions in Table 988 #111111 (and any other applicable change information within the Category 31 table) apply. • When the change is requested after the departure date from the origin of the journey on the previous ticket and after the departure date from the origin of the pricing unit on the previous ticket, then the conditions in Table 988 #222222 (and any other applicable change information within the Category 31 table) apply. • When the change is requested before the departure date from the origin of the fare component on the previous ticket, then the conditions in Table 988 #333333 (and any other applicable change information within the Category 31 table) apply.

When validating the BE70 MSP-DTT fare component that resolves to the Category 31 data above: Match Table 222 • Change is requested on 05Jan 01 which is after the date of departure from the origin of the journey on the previous ticket (FAR depart 01Jan 01), after the date of departure from the origin of the pricing unit on the previous ticket (MSP depart 04Jan 01), and after the date of departure from the origin of the fare component on the previous ticket (MSP depart 04Jan 01). • Processing will no match Tables 111 and 333 and will match Table 222 (provided that a match is also made to all other match fields).

Page E.03.31.068 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

When validating the BE70 DTT-MSP fare component that resolves to the Category 31 data above: Match Tables 222 and 333 • Change is requested on 05Jan 01 which is after the date of departure from the origin of the journey on the previous ticket (FAR depart 01Jan 01), after the date of departure from the origin of the pricing unit on the previous ticket (MSP depart 04Jan 01), and before the date of departure from the origin of the fare component on the previous ticket (DTT depart 10Jan 01). • Processing will no match Tables 111 and will match Tables 222 and 333 (provided that a match is also made to all other match fields).

4.2.3.3. Advance Reservation (Bytes 29, 30, 44-46, 47-48)

These fields are used to specify Advance Reservation requirements that must be met in order to apply the Voluntary Change data in the table. Carriers may specify an advance reservation period as well as measurement points for the specified period.

Bytes 29 and 30 indicate the From and To Points used to measure the specified advance reservation requirements (bytes 44-48) as follows: • From Point (byte 29) indicates that the requirements should be measured from either the previous ticketing date (value O) or the reissue ticketing date (value R). • To Point (byte 30) indicates that the requirements should be measured to the date of departure from the origin of the previous journey (value J), pricing unit (value P), or fare component (value F). Edits require that when data is present in one of these fields, then data must also be present in the other field (and applicable advance reservation requirements must be in bytes 44-48). When bytes 29 and 30 are BLANK, all other advance reservation fields must also be blank, indicating there are no restrictions on advance reservations relative to Voluntary Changes.

Bytes 44-48 specify the advance reservation requirements as follows: • Period of elapsed time or day of week occurrence (bytes 44-46). • Unit defining the preceding Period (bytes 47-48) Processing validates the advance reservation requirements based on the From and To measurements specified in bytes 29 and 30. Edits require that when data is present in bytes 44-48, then data must also be present in bytes 29 and 30. When these fields are blank, there are no restrictions on advance reservations relative to Voluntary Changes.

Page E.03.31.069 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Although data in bytes 44-48 is advance reservation data, the elapsed time specified in these bytes will actually be validated against ticketing dates as specified by From Point byte 29. Processing will not validate the elapsed time based on any reservation dates.

Examples on the Following Pages Use the Original and New Itineraries Below:

Original Itinerary: FAR-MSP-FAR RT Pricing Unit End-on-End with MSP-SEA-MSP RT Pricing Unit (inbound via DTT) Ticket Issue Date = 25Sep 00 Dept 01Oct00 Dept 04Oct00 FAR MSP SEA Dept 31Oct00 DTT Dept 30Oct00 Dept 30Oct00 Ticketing Information: Carrier Flight Date Sector Bkg Code Fare Class NW 100 01OCT 00 FAR-MSP Y Y26 NW 200 04OCT00 MSP-SEA B BE70 NW 300 30OCT 00 SEA-DTT K KE14NR NW 400 30OCT 00 DTT-MSP K KE14NR NW 500 31OCT00 MSP-FAR Y Y26

New itinerary requested on 27Sep 00: Proposed New Ticket Issue Date = 27Sep 00 Dept 10Oct00 (change) Dept 15Oct 00 (change) FAR MSP SEA Dept 31Oct00 DTT Dept 30Oct00 Dept 30Oct00 Ticketing Information: Carrier Flight Date Sector Bkg Code NW 120 10OCT 00 FAR-MSP Y CHANGE NW 250 15OCT 00 MSP-SEA B CHANGE NW 300 30OCT 00 SEA-DTT K No change NW 400 30OCT 00 DTT-MSP K No change NW 500 31OCT00 MSP-FAR Y No change

Page E.03.31.070 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1 (Previous Ticketing Date/Journey Origin)

THEN Record 3 Byte 29 Byte 30 Bytes 44-46 Bytes 47-48 Bytes 55-62 From Point To Point Period Unit Reissue Table 988 O J 007 Db 123456 The data indicates that when the previous ticketing date is at least 7 days before departure from the origin of the previous journey, then the conditions in Table 988 #123456 (and any other applicable change information within the Category 31 table) apply.

The FAR-MSP, MSP-FAR, MSP-SEA, and SEA-MSP fare components all resolve to the above Category 31 Record 3.

When validating the FAR-MSP fare component: No Match • Determine the previous ticketing date: 25Sep 00. • Determine date of departure from the origin of the previous journey: FAR depart 01Oct 00. • Previous ticketing date (25Sep 00) is less than 7 days before departure from the origin of the previous journey (01Oct 00). Processing will no match the table. NOTE: The same processing and results apply for the MSP-FAR, MSP-SEA, and SEA-MSP fares components.

Page E.03.31.071 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2 (Previous Ticketing Date/Pricing Unit Origin)

THEN Record 3 Byte 29 Byte 30 Bytes 44-46 Bytes 47-48 Bytes 55-62 From Point To Point Period Unit Reissue Table 988 O P 007 Db 123456 The data indicates that when the previous ticketing date is at least 7 days before departure from the origin of the previous pricing unit, then the conditions in Table 988 #123456 (and any other applicable change information within the Category 31 table) apply.

The FAR-MSP, MSP-FAR, MSP-SEA, and SEA-MSP fare components all resolve to the above Category 31 Record 3.

When validating the FAR-MSP and MSP-FAR fare components: No Match • Determine the previous ticketing date: 25Sep 00. • Determine date of departure from the origin of the previous pricing unit encompassing the fare component being validated: FAR depart 01Oct 00. • Previous ticketing date (25Sep 00) is less than 7 days before departure from the origin of the previous pricing unit (01Oct 00). Processing will no match the table.

When validating the MSP-SEA and SEA-MSP fare components: Match • Determine the previous ticketing date: 25Sep 00. • Determine date of departure from the origin of the previous pricing unit encompassing the fare component being validated: MSP depart 04Oct 00. • Previous ticketing date (25Sep 00) is more than 7 days before departure from the origin of the previous pricing unit (04Oct 00). Processing will match the table (provided that a match is also made to all other match fields).

Page E.03.31.072 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3 (Previous Ticketing Date/Fare Component Origin)

THEN Record 3 Byte 29 Byte 30 Bytes 44-46 Bytes 47-48 Bytes 55-62 From Point To Point Period Unit Reissue Table 988 O F 007 Db 123456 The data indicates that when the previous ticketing date is at least 7 days before departure from the origin of the previous fare component, then the conditions in Table 988 #123456 (and any other applicable change information within the Category 31 table) apply.

The FAR-MSP, MSP-FAR, MSP-SEA, and SEA-MSP fare components all resolve to the above Category 31 Record 3.

When validating the FAR-MSP fare component: No Match • Determine the previous ticketing date: 25Sep 00. • Determine date of departure from the origin of the previous fare component being validated: FAR depart 01Oct 00. • Previous ticketing date (25Sep 00) is less than 7 days before departure from the origin of the previous fare component (01Oct 00). Processing will no match the table.

When validating the MSP-FAR fare component: Match • Determine the previous ticketing date: 25Sep 00. • Determine date of departure from the origin of the previous fare component being validated: MSP depart 31Oct 00. • Previous ticketing date (25Sep 00) is more than 7 days before departure from the origin of the previous fare component (31Oct 00). Processing will match the table (provided that a match is also made to all other match fields).

When validating the MSP-SEA fare component: Match • Determine the previous ticketing date: 25Sep 00. • Determine date of departure from the origin of the previous fare component being validated: MSP depart 04Oct 00. • Previous ticketing date (25Sep 00) is more than 7 days before departure from the origin of the previous fare component (04Oct 00). Processing will match the table (provided that a match is also made to all other match fields).

Page E.03.31.073 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

When validating the SEA-MSP fare component: Match • Determine the previous ticketing date: 25Sep 00. • Determine date of departure from the origin of the previous fare component being validated: SEA depart 30Oct 00. • Previous ticketing date (25Sep 00) is more than 7 days before departure from the origin of the previous fare component (30Oct 00). Processing will match the table (provided that a match is also made to all other match fields).

Example 4 (Reissued Ticket Date/Journey Origin)

THEN Record 3 Byte 29 Byte 30 Bytes 44-46 Bytes 47-48 Bytes 55-62 From Point To Point Period Unit Reissue Table 988 R J 007 Db 123456 The data indicates that when the reissued ticket date is at least 7 days before departure from the origin of the previous journey, then the conditions in Table 988 #123456 (and any other applicable change information within the Category 31 table) apply.

The FAR-MSP, MSP-FAR, MSP-SEA, and SEA-MSP fare components all resolve to the above Category 31 Record 3.

When validating the FAR-MSP fare component: No Match • Determine the reissued ticket date: 27Sep 00. • Determine date of departure from the origin of the previous journey: FAR depart 01Oct 00. • Reissued ticket date (27Sep 00) is less than 7 days before departure from the origin of the previous journey (01Oct 00). Processing will no match the table. NOTE: The same processing and results apply for the MSP-FAR, MSP-SEA, and SEA-MSP fares components.

Page E.03.31.074 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 5 (Reissued Ticket Date/Pricing Unit Origin)

THEN Record 3 Byte 29 Byte 30 Bytes 44-46 Bytes 47-48 Bytes 55-62 From Point To Point Period Unit Reissue Table 988 R P 007 Db 123456 The data indicates that when the reissued ticket date is at least 7 days before departure from the origin of the previous pricing unit, then the conditions in Table 988 #123456 (and any other applicable change information within the Category 31 table) apply.

The FAR-MSP, MSP-FAR, MSP-SEA, and SEA-MSP fare components all resolve to the above Category 31 Record 3.

When validating the FAR-MSP and MSP-FAR fare components: No Match • Determine the reissued ticket date: 27Sep 00. • Determine date of departure from the origin of the previous pricing unit encompassing the fare component being validated: FAR depart 01Oct 00. • Reissued ticket date (27Sep 00) is less than 7 days before departure from the origin of the previous pricing unit (01Oct 00). Processing will no match the table.

When validating the MSP-SEA and SEA-MSP fare components: Match • Determine the reissued ticket date: 27Sep 00. • Determine date of departure from the origin of the previous pricing unit encompassing the fare component being validated: MSP depart 04Oct 00. • Reissued ticket date (27Sep 00) is more than 7 days before departure from the origin of the previous pricing unit (04Oct 00). Processing will match the table (provided that a match is also made to all other match fields).

Page E.03.31.075 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 6 (Reissued Ticket Date/Fare Component Origin)

THEN Record 3 Byte 29 Byte 30 Bytes 44-46 Bytes 47-48 Bytes 55-62 From Point To Point Period Unit Reissue Table 988 R F 007 Db 123456 The data indicates that when the reissued ticket date is at least 7 days before departure from the origin of the previous fare component, then the conditions in Table 988 #123456 (and any other applicable change information within the Category 31 table) apply.

The FAR-MSP, MSP-FAR, MSP-SEA, and SEA-MSP fare components all resolve to the above Category 31 Record 3.

When validating the FAR-MSP fare component: No Match • Determine the reissued ticket date: 27Sep 00. • Determine date of departure from the origin of the previous fare component being validated: FAR depart 01Oct 00. • Reissued ticket date (27Sep 00) is less than 7 days before departure from the origin of the previous fare component (01Oct 00). Processing will no match the table.

When validating the MSP-FAR fare component: Match • Determine the reissued ticket date: 27Sep 00. • Determine date of departure from the origin of the previous fare component being validated: MSP depart 31Oct 00. • Reissued ticket date (27Sep 00) is more than 7 days before departure from the origin of the previous fare component (31Oct 00). Processing will match the table (provided that a match is also made to all other match fields).

When validating the MSP-SEA fare component: Match • Determine the reissued ticket date: 27Sep 00. • Determine date of departure from the origin of the previous fare component being validated: MSP depart 04Oct 00. • Reissued ticket date (27Sep 00) is more than 7 days before departure from the origin of the previous fare component (04Oct 00). Processing will match the table (provided that a match is also made to all other match fields).

Page E.03.31.076 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

When validating the SEA-MSP fare component: Match • Determine the reissued ticket date: 27Sep 00. • Determine date of departure from the origin of the previous fare component being validated: SEA depart 30Oct 00. • Reissued ticket date (27Sep 00) is more than 7 days before departure from the origin of the previous fare component (30Oct 00). Processing will match the table (provided that a match is also made to all other match fields).

4.2.3.4. Override Date Table No. 994 (bytes 137-144)

A number referring to a table containing dates on which travel, ticketing and/or reservations are valid for the data in this category. Processing will validate against the travel, ticketing, and/or reservation dates of the new journey (new ticket): • Travel dates validate against the travel dates from the departure from origin of the new journey. NOTE: This differs from validation in other categories. Category 31 Table 994 travel dates do not further define the specific date range within Effective/Discontinue dates of the Record 2. Data within Category 31 Table 994 is a journey validation based on the new itinerary, while Effective/Discontinue dates on the Record 2 are a journey validation based on the original itinerary dates. • Ticketing dates validate against the ticket issue date of the new journey. • Reservation dates validate against the latest reservation date on any sector of the new fare component. If the reservation, ticketing and/or travel dates of the new ticket are not within the dates specified in the Override Date Table, no- match and continue processing. If no further tables or all other tables contain 994 tables that do not match, apply the system assumption for this category. Refer to 994 Data Application for further details. Determine Whether Change is Permitted

Page E.03.31.077 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.3. DETERMINE WHETHER CHANGE IS PERMITTED

4.3.1. Change Indicator (Byte 50)

The Change Indicator field (byte 50) may be used to indicate whether a change is or is not permitted to the Fare Component, Pricing Unit, or Journey being validated or it may be used to specify the number (1-9) of times a ticket may be reissued regardless of whether the portion specified is flown or un-flown. Prior to validating the data in Table 988, processing must validate the Category 31 Change Indicator field (byte50) in order to determine if a change to the travel being validated is permitted. When a match is made to a Category 31 with byte 50 populated, processing may continue to read on, attempting to match another Category 31 table. If processing determines that changes are not permitted for all fare components in the journey, the transaction will be treated as a cancellation (continue processing to Category 33 – Voluntary Refunds).

Valid values for byte 50 are as follows:

Value N Indicates no changes are permitted to marketing carrier, departure date, flight number, ticketed points, fare break points, fare basis code, ticket designator, and fare amount of the fare component being validated. Changes to the RBD and/or cabin are permitted provided they adhere to the restrictions indicated above. No restrictions on changes to other fare components.

Value P Indicates no changes are permitted to marketing carrier(s), departure date(s), flight number(s), ticketed points, fare break points, fare basis code(s), ticket designator(s), and fare amount(s) of the fare component(s) which are part of the pricing unit being validated. Changes to the RBD and/or cabin are permitted to the fare component(s) which are part of the pricing unit being validated provided they adhere to the restrictions indicated above. No restrictions on changes to other fare components that are part of other pricing units. Process tags associated with fare components which are part of the pricing unit being validated will have no role in determining the type of fares to be applied (Current, Historical) during the re-price.

Value J Indicates that when all fare components on the ticket are owned by the same carrier, no changes are permitted to marketing carrier(s), departure date(s), flight number(s), ticketed points, fare break points, fare basis code(s), ticket designator(s), and fare amount(s) of all fare component(s) in the journey. Changes to the RBD and/or cabin are permitted provided they adhere to the restrictions indicated above. When all of the fare components on the ticket are not owned by the same carrier, value J will be processed as value P. Process

Page E.03.31.078 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

tags associated with fare components which are part of the journey will have no role in determining the type of fares to be applied (Current, Historical) during the re-price.

Value Indicates the number of times the ticket may be reissued is limited to the numeric value in this field. If the number of times the ticket is 1 - 9 being reissued is less than the number in byte 50, this table may be applied. If the number of times the ticket is being reissued exceeds the number in byte 50, then processing will “fail” this Category 31 table and continue processing to another table.

Value No restrictions Blank

Page E.03.31.079 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

When a fare component contains Change Indicator (Category 31 byte 50) value N, P, or J, and there is no other fare component to direct how to re-price the new itinerary, processing will use historical ticket issue date fares.

Example 1 – Value N

Previous Ticketed Itinerary Pricing Unit #1: UA CHI-NYC (SP30NR) UA NYC-CHI (VE7NR) Pricing Unit #2: UA NYC-LON (MX7NR) UA LON-NYC (MX7NR)

(Flown)

CHI NYC LON

CHI-NYC SP30NR fare component matches the following Category 31 Record 3: Byte 26 Byte 50 Bytes 55-62 Dept of Journey Change Indicator Reissue Table 988 A N 000000

NYC-CHI VE7NR fare component matches the following Category 31 Record 3: Byte 26 Byte 50 Bytes 55-62 Dept of Journey Change Indicator Reissue Table 988 A Blank 123456 (Process Tag = 2)

NYC-LON and LON-NYC MX7NR fare components match the following Category 31 Record 3: Byte 26 Byte 50 Bytes 55-62 Dept of Journey Change Indicator Reissue Table 988 A Blank 987654 (Process Tag = 2

Page E.03.31.080 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

The passenger has traveled CHI-NYC and request to change the NYC-LON-NYC portion of travel. The change is permitted using historical fares as long as the marketing carrier, departure date, flight number, ticketed points, fare break points, fare basis code, ticket designator, and fare amount of the CHI-NYC fare component is not changed.

Page E.03.31.081 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2 – Value P

Previous Ticketed Itinerary Pricing Unit #1: AA WAS-LON (SP45NR) AA LON-WAS (MLXUS) Pricing Unit #2: AF LON-PAR (MFLEX) AF PAR-LON (MFLEX)

WAS LON PAR

WAS-LON SP45NR fare component matches the following Category 31 Record 3: Byte 26 Byte 50 Bytes 55-62 Dept of Journey Change Indicator Reissue Table 988 B P 000000

LON-WAS MLXUS fare component matches the following Category 31 Record 3: Byte 26 Byte 50 Bytes 55-62 Dept of Journey Change Indicator Reissue Table 988 B Blank 123456 (Process Tag = 5)

LON-PAR and PAR-LON MFLEX fare components match the following Category 31 Record 3: Byte 26 Byte 50 Bytes 55-62 Dept of Journey Change Indicator Reissue Table 988 B Blank 987654 (Process Tag = 5)

Travel has yet to begin and the passenger request to change the LON-PAR-LON portion of travel. The change is permitted using current fares as long as the marketing carriers, departure dates, flight numbers, ticketed points, fare break points, fare basis codes, ticket designators, and fare amounts of the fare components within Pricing Unit #1 (WAS-LON and LON-WAS fare components) are not changed.

Page E.03.31.082 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3 – Value P

Previous Ticketed Itinerary Pricing Unit #1: AA WAS-LON (SP45NR) AA LON-WAS (MLXUS) Pricing Unit #2: AF LON-PAR (MFLEX) AF PAR-LON (MFLEX)

WAS LON PAR

WAS-LON SP45NR fare component matches the following Category 31 Record 3: Byte 26 Byte 50 Bytes 55-62 Dept of Journey Change Indicator Reissue Table 988 B P 000000

LON-WAS MLXUS fare component matches the following Category 31 Record 3: Byte 26 Byte 50 Bytes 55-62 Dept of Journey Change Indicator Reissue Table 988 B Blank 123456 (Process Tag = 2)

LON-PAR and PAR-LON MFLEX fare components match the following Category 31 Record 3: Byte 26 Byte 50 Bytes 55-62 Dept of Journey Change Indicator Reissue Table 988 B Blank 987654 (Process Tag = 5)

Travel has yet to begin and the passenger request to change the LON-PAR-LON portion of travel. The change is permitted using current fares as long as the marketing carrier, departure date, flight number, ticketed points, fare break points, fare basis code, ticket designators, and fare amounts of the fare components within Pricing Unit #1 (WAS-LON and LON-WAS fare components) are not changed.

Page E.03.31.083 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Note: The process tag for the LON-WAS MLXUS fare component play’s no role when determining the type of fares to be used (Current, Historical) during the re-price.

Page E.03.31.084 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 4 – Value J

Previous Ticketed Itinerary Pricing Unit #1: AA DFW-NYC (SPCL) AA NYC-DFW (SPCL) Pricing Unit #2: AA NYC-PAR (MFLEX) AA PAR-NYC (MFLEX)

DFW NYC PAR

DFW-NYC and NYC-DFW SPCL fare components match the following Category 31 Record 3: Byte 26 Byte 50 Bytes 55-62 Dept of Journey Change Indicator Reissue Table 988 B J 000000

NYC-PAR and PAR-NYC MFLEX fare components match the following Category 31 Record 3: Byte 26 Byte 50 Bytes 55-62 Dept of Journey Change Indicator Reissue Table 988 B Blank 987654 (Process Tag = 5)

Travel has yet to begin and the passenger request to change the NYC-PAR-NYC portion of travel. Changes are permitted using current fares as long as the marketing carrier, departure date, flight number, ticketed points, fare break points, fare basis code, ticket designators, and fare amounts of the fare components in the journey are not changed as Category 31 byte50 for the SPCL fare component is coded as value J and the owning carrier of all fare components, AA, is the same. Processing will treat the transaction as a cancellation (continue processing to Category 33 – Voluntary Refunds).

Page E.03.31.085 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 5 – Value J

Previous Ticketed Itinerary Pricing Unit #1: AA DFW-LON (S45PCL) AA LON-DFW (S45PCL) Pricing Unit #2: AF LON-PAR (M7AP) AF PAR-LON (M7AP)

DFW LON PAR

DFW-LON and LON-DFW S45PCL fare components match the following Category 31 Record 3: Byte 26 Byte 50 Bytes 55-62 Dept of Journey Change Indicator Reissue Table 988 B J 000000

LON-PAR and PAR-LON M7AP fare components match the following Category 31 Record 3: Byte 26 Byte 50 Bytes 55-62 Dept of Journey Change Indicator Reissue Table 988 B Blank 987654 (Process Tag = 5)

Travel has yet to begin and the passenger request to change the LON-PAR-LON portion of travel. Since all fare components within the journey are not owned by the same carrier, the DFW-LON LON-DFW fare component’s Category 31byte 50 (value J) is processed as value P. Therefore, the change is permitted using current fares as long as the marketing carrier, departure date, flight number, ticketed points, fare break points, fare basis code, ticket designator, and fare amounts of the fare components within Pricing Unit #1 (DFW-LON and LON-DFW fare components) are not changed.

Page E.03.31.086 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 6 (Numerical Value)

Previous Ticketed Itinerary Pricing Unit #1: AA DFW-LON (S45PCL) AA LON-DFW (S45PCL) Pricing Unit #2: AF LON-PAR (M7AP) AF PAR-LON (M7AP)

Flown

DFW LON PAR

DFW-LON and LON-DFW S45PCL fare components match the following Category 31 Record 3: Byte 26 Byte 50 Bytes 55-62 Dept of Journey Change Indicator Reissue Table 988 A Blank 654321 (Process Tag = 2) LON-PAR and PAR-LON fare components match the following Category 31 Record 3: Byte 26 Byte 50 Bytes 55-62 Dept of Journey Change Indicator Reissue Table 988 A 1 123456 (Process Tag = 2)

The passenger has traveled DFW-LON and request to change the LON-PAR-LON portion of travel. The change is permitted using historical fares as long as no previous ticket reissues have been done.

Page E.03.31.087 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.4. MATCH THE APPLICABLE TABLE 988

The Table 988 information includes the method on how to re-price the new itinerary (Process Tag) and the conditions that must be validated and revalidated. Table 988 information for all fare components in the previous itinerary are used to determine the lowest fare result for the new itinerary. Once the lowest fare result is determined for the new itinerary, the change fee to be applied is determined in Category 31 for each fare component. Refer to Section 4.6 for specific data application on calculating the change fee.

The Table 988 may have multiple entries for the same Table ID and Table Number. Multiple entries for the same Process Tag value should be reviewed in ascending order by Sequence Number (Bytes 14-20). The fare component being validated must match at least one Table 988 entry for a single Record 2 Category 31 to allow a voluntary change (apply no matched Record 3 assumption). Once an entry has matched, validate the ‘how to re-price’ and the ‘conditions that must be validated and revalidated’.

The match fields for Table 988 are the PROVIDED fields: 4.4.1 Travel Limit (bytes 23,24) 4.4.2 Outbound Portion of Travel (byte 41) 4.4.3 Originally Scheduled Flight (byte 56) 4.4.4 Date (byte 89) 4.4.5 Flight Number (byte 42) The relationship among the match fields is AND. All match fields for a given entry must be matched before validating the remaining data within the entry. A blank in any of the match fields is considered a match to any fare component. The specific match fields are defined below.

4.4.1. Travel Limit (bytes 23, 24)

The Travel Limit fields specify points or portions of travel on the itinerary that may or may not be changed in order to match the Table 988 entry. These fields consist of the Stopover/Connection field (byte 23) and the Portion fields (bytes 24-40). Data in these fields requires a Match/Action validation. Processing must determine if the specified point/portion of travel has or has not changed in order to match the Table 988 entry. When re-pricing, processing may make changes to points/portions of travel within the confines of the restrictions specified in the Travel Limit fields.

Page E.03.31.088 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.4.1.1. Stopover/Connection (byte 23)

This field identifies whether stopovers and/or connection points are allowed to be changed. • Value S indicates that stopover points may not change. • Value C indicates that connection points may not change. • Value B indicates that both stopover and connection points may not change. • Value Blank indicates there are no restrictions on changes to stopover and connection points when matching Table 988 and when re-pricing the itinerary.

When byte 23 is value S, C, or B, processing matches to the stopover and/or connection points within the fare component being validated. Processing must identify all ticketed stopover and/or connections within the fare component on the previous itinerary and determine whether there are any changes to these points within the fare component on the new itinerary. Processing may not include any new stopover and/or connection points or remove any existing stopover and/or connection points from the previous itinerary. Additionally, processing may not re-price the itinerary in such a way that creates any new stopover and/or connection point or removes an existing stopover/and or connection point. Note that changes to departure dates, times, carrier, flight number, and class of service are still permitted at the stopover and/or connection points. If any stopovers and/or connections have changed, then processing will no match this Table 988 entry and continue processing to the next applicable entry NOTE: A change to an airport code in a multi-airport city does not constitute a change. For example changing LGA to JFK will not be considered a change to stopover/connection points.

Page E.03.31.089 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1

Original Itinerary: CHI-PAR OW (via NYC/LON) Dept 01Jan01 Dept 01Jan01 Dept 12Jan01 CHI NYC (connection) LON (stopover) PAR Ticketing Information: Carrier Flight Date Sector Bkg Code UA 100 01JAN 01 CHI-NYC Y UA 200 01JAN 01 NYC-LON Y UA 300 12JAN 01 LON-PAR Y

The CHI-PAR fare component resolves to Category 31 Record 3 with the following Table 988: Bytes 14-20 Bytes 21-22 Byte 23 Bytes 57-88 , 111-112, 138-145, and 214-221 Seq Number Process Tag Stop/Conn Re-price Fare/Rule 1 01 S Re-price Data 2 01 C Re-price Data 3 01 B Re-price Data The data indicates that when stopover points are not changed, processing will match sequence 1 and apply the applicable re-pricing data. When connections are not changed, processing will match sequence 2 and apply the applicable re-pricing data. When both stopover and connection points are not changed, processing will match sequence 3 and apply the applicable re-pricing data. Note that multiple matches to Table 988 sequences are possible.

Page E.03.31.090 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

A. Change to Connection Point

If the original itinerary is changed to the following: Dept 01Jan01 Dept 01Jan01 Dept 12Jan01 CHI BOS (connection) LON (stopover) PAR Ticketing Information: Carrier Flight Date Sector Bkg Code UA 100 01JAN 01 CHI-BOS Y CHANGE UA 200 01JAN 01 BOS-LON Y CHANGE UA 300 12JAN 01 LON-PAR Y No change

When validating the CHI-PAR fare component that resolves to the Table 988 data above: • Identify all stopovers and connections on the previous itinerary: NYC connection, LON stopover. • Determine if these stopovers and connections exist on the new itinerary: connection point NYC does not exist (changed to BOS). • Processing will match Table 988 sequence 1 and no match sequences 2 and 3.

Page E.03.31.091 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

B. Addition of Stopover Point

If the original itinerary is changed to the following: Dept 01Jan01 Dept 01Feb01 Dept 15Feb01 Dept 20Feb 01 CHI NYC (connection) LON (stopover) AMS (stopover) PAR Ticketing Information: Carrier Flight Date Sector Bkg Code UA 100 01JAN 01 CHI-NYC Y No Change UA 200 01FEB 01 NYC-LON Y No change UA 300 15FEB 01 LON-AMS Y CHANGE UA 400 20FEB 01 AMS-PAR Y CHANGE

When validating the CHI-PAR fare component that resolves to the Table 988 data above: • Identify all stopovers and connections on the previous itinerary: NYC connection, LON stopover. • Determine if these stopovers and connections exist on the new itinerary: NYC connection and LON stopover exist. • Determine if any new stopovers and/or connections exist: additional stopover is added in AMS. • Processing will match Table 988 sequence 2. Processing no matches sequences 1 and 3 because the change was made to stopover points.

Page E.03.31.092 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

C. Change of Fare Break

If the original itinerary is changed to the following: Dept 01Jan01 Dept 01Jan01 Dept 15Jan01 Dept 20Jan 01 CHI NYC (connection) LON (stopover) PAR (Fare Break/Stopover) FRA Ticketing Information: Carrier Flight Date Sector Bkg Code UA 100 01JAN 01 CHI-NYC Y No change UA 200 01JAN 01 NYC-LON Y No change UA 300 15Jan 01 LON-PAR Y CHANGE

When validating the CHI-PAR fare component that resolves to the Table 988 data above: • Identify all stopovers and connections on the previous itinerary: NYC connection, LON stopover. • Determine if these stopovers and connections exist on the new itinerary: NYC connection and LON stopover exists: • Determine if any new stopovers and/or connections exist: no new stopovers or connections. Change is made to destination point (PAR changed to FRA), but no changes/additions are made to any stopover points. (PAR is still considered a fare break point, and processing will revalidate data in byte 23 when re-pricing the itinerary.) • Processing will match Table 988 sequences 1, 2, and 3. • When re-pricing, in order to pass sequence 1 or 3, processing cannot re-price as a CHI-FRA fare component with a stopover in PAR. Processing must re-price as a CHI-PAR fare component end-on-end with a PAR-FRA fare component in order to pass these sequences.

Page E.03.31.093 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2

Original Itinerary: CHI-PAR RT (via NYC) Dept 01Jan01 Dept 01Jan01 CHI NYC (connection) PAR Dept 20Jan01 Dept20Jan01 Ticketing Information: Carrier Flight Date Sector Bkg Code UA 100 01JAN 01 CHI-NYC Y UA 200 01JAN 01 NYC-PAR Y UA 201 20JAN 01 PAR-NYC Y UA 101 20JAN 01 NYC-CHI Y

The CHI-PAR and PAR-CHI fare components resolves to Category 31 Record 3 with the following Table 988: Bytes 14-20 Bytes 21-22 Byte 23 Bytes 57-88 , 111-112, 138-145, and 214-221 Seq Number Process Tag Stop/Conn Re-price Fare/Rule 1 01 C Re-price Data The data indicates that when connections are not changed, processing will match sequence 1 and apply the applicable re-pricing data.

Page E.03.31.094 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

If the original itinerary is changed to the following: Dept 01Jan01 Dept 05Jan01 Dept 05Jan01 (connection) CHI WAS NYC PAR Dept 31Jan01

MSP NYC LON Dept 03Feb01 (connection) Dept 03Feb01 Ticketing Information: Carrier Flight Date Sector Bkg Code UA 100 01JAN 01 CHI-WAS Y UA 150 05JAN 01 WAS-NYC Y UA 200 05JAN 01 NYC-PAR Y UA 333 31JAN 01 PAR-LON Y UA 302 03FEB 01 LON-NYC Y UA 1122 03FEB 01 NYC-MSP Y When validating the CHI-PAR fare component that resolves to the Table 988 data above: • Identify all stopovers and connections on the previous itinerary: connection in NYC. • Determine if the same connection point from the previous itinerary exists on the new itinerary: connection still exists in NYC • Determine if any new stopovers and/or connections exist: no new connection points exist; new stopover in WAS • Processing will match Table 988 sequence 1.

When validating the PAR-CHI fare component that resolves to the Table 988 data above: • Identify all stopovers and connections on the previous itinerary: connection in NYC. • Determine if the same connection point from the previous itinerary exists on the new itinerary: connection still exists in NYC • Determine if any new stopovers and/or connections exist: no new connection points exist; new stopover in LON • Processing will match Table 988 sequence 1.

Page E.03.31.095 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.4.1.2. Portion (bytes 24, 25-40)

These fields identify a point/portion of the itinerary which may not be changed. Data consist of a Portion field (byte 24) and From and To Geo Spec Tables (bytes 25-32, 33-40). The fields require a journey validation. Processing must identify all points/portions of travel on the previous journey and determine whether there are any changes to these points/portions of travel on the new journey. Determination of points of change is achieved by comparing each flight segment (defined as carrier code, flight number, ticketed travel points, travel dates, and travel times) on the previous ticketed itinerary to each flight segment on the new itinerary. When a flight segment on the previous itinerary does not match the new itinerary, or a flight segment on the new itinerary does not match the previous itinerary, it is considered a change. Adding a new segment before the beginning of the new journey constitutes changing both the first fare component and first flight coupon. If the specified point/portion of travel is changed, then processing will no match this Table 988 entry and continue processing to the next applicable entry. If the specified point/portion of travel is not changed, then processing will match this Table 988 entry. The outcome of the re-pricing cannot result in any changes to the specified point/portion of travel.

The Portion field (byte 24) provides the ability to specify:

Value F Changes not permitted to the 1st flight coupon on the ticket. Value S Changes not permitted to the 1st fare component on the ticket. Value Blank No restrictions on the portion of the itinerary that may be changed.

The From and To Geo Spec Tables (bytes 25-32, 33-40) provide the ability to specify a point or portion of travel on the journey where changes are not permitted. Data in each Geo Spec Table may consist of a TSI and/or up to two geographic locales of the same type. The TSI further modifies any geographic location data. Processing must validate the specified point/portion of travel on the journey and determine that changes are not being made. If processing cannot validate the specified point/portion of travel, then no match the 988 sequence. If processing can validate the specified point/portion of travel, but changes are being made to this point/portion of travel, then no match the 988 sequence. If processing can validate the specified point/portion of travel, and changes are not being made to this point/portion of travel, then match the 988 sequence.

The From Geo Spec Table indicates a departure validation, and the To Geo Spec Table indicates an arrival validation. When validating data in the From Geo Spec Table, processing will attempt to validate departure from the specified point on the journey.

Page E.03.31.096 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

When validating data in the To Geo Spec Table, processing will attempt to validate arrival at the specified point on the journey. When data is present in both Geo Spec Tables, then changes are not permitted at the point specified by the From Geo Spec Table, at the point specified by the To Geo Spec table, and on the portion of travel from the point specified by the From Geo Spec Table to the point specified by the To Geo Spec Table. When data is present in the From Geo Spec Table and the To Geo Spec Table is blank, then processing will attempt to validate departure from the specified point on the journey; changes are not permitted to this point. When data is present in the To Geo Spec Table and the From Geo Spec Table is blank, then processing will attempt to validate arrival at the specified point on the journey; changes are not permitted to this point.

TSIs When a Fare Component TSI is entered, processing will validate all fare components on the journey, attempting to match the point/portion of travel specified by the TSI. When a Pricing Unit TSI or combination Fare Component/Pricing Unit TSI is entered, processing will validate all pricing units on the journey, attempting to match the point/portion of travel specified by the TSI. When a Journey TSI is entered, processing will validate the journey, attempting to match the point/portion of travel specified by the TSI. A departure TSI used in the To Geo Spec Table will override the arrival application of the Geo Spec Table. An arrival TSI used in the From Geo Spec Table will override the departure application of the Geo Spec Table. (Note: ATPCO’s coding convention holds that a departure TSI should not be used in the To Geo Spec Table and an arrival TSI should not be used in the From Geo Spec Table.) If a TSI is entered that does not specify a departure or arrival validation, then there is no departure or arrival application of either Geo Spec Table. Processing will attempt to validate the specified portion of travel, and changes are not permitted to this portion of travel.

Example 1 From Geo Spec = TSI 42 To Geo Spec Table = BLANK Processing must validate departure of each transatlantic sector (validation is against the journey). Changes are not permitted to the departure of each transatlantic sector.

Example 2 From Geo Spec = BLANK

Page E.03.31.097 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

To Geo Spec Table = TSI 40 Processing must validate departure of the outbound transatlantic sector (validation is against all pricing units on the journey). Changes are not permitted to the departure of the outbound transatlantic sector.

Example 3 From Geo Spec = TSI 18 To Geo Spec Table = BLANK Processing must validate all international sectors (validation is against the journey). Changes are not permitted to any international sectors.

When TSI data is present in both Geo Spec Tables, processing will validate the points of travel on the journey where travel is from the point specified by the From Geo Spec Table and to the point specified by the To Geo Spec Table. No changes are permitted between and including the specified points. If TSI data is present in both Geo Spec Tables, and one or both of the TSIs do not specify a departure or arrival validation, then this is considered “bad” data, and processing should ignore the data.

Example From Geo Spec = TSI 42 To Geo Spec Table = TSI 44 Processing must validate departure of each transatlantic sector and arrival of each transatlantic sector (validation is against the journey). Changes are not permitted to this portion of travel.

Geographic Locales The relationship between the locales within each Geo Spec Table is OR. When data is present in both Geo Spec Tables, processing will validate the points of travel on the journey where travel is from the point specified by the From Geo Spec Table and to the point specified by the To Geo Spec Table. No changes are permitted between and including the specified points. When the geographic specification is a nation, zone, or area, then the application of the location is last point out/first point in. Changes are not permitted from the last point out of the location specified in the From Geo Spec Table to the first point into the location specified in the To Geo Spec Table

Example 1 From Geo Spec = N DE

Page E.03.31.098 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

To Geo Spec Table = Z 000 Processing must validate a portion of travel from the last point out of Germany to the first point into North America. Changes are not permitted to this portion of travel.

Example 2 From Geo Spec = TSI 40 To Geo Spec Table = Z 220 Processing must validate a portion of travel from departure of the outbound transatlantic sector to the first point into the Middle East. Changes are not permitted to this portion of travel.

When byte 24 is value F (1st coupon) and data is present in the Geo Spec Table(s), processing will validate the specified geographic point/portion of travel against the first coupon of the journey. When byte 24 is value S (1st fare component), processing will validate the specified geographic point/portion of travel against the first fare component of the journey.

Page E.03.31.099 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1 (Byte 24 coded)

ORIGINAL Itinerary: LAX-BOS RT Dept 01Mar07 NW352 LAX BOS Dept 28Mar07 NW353

NEW Itinerary: SAN-LAX RT End-on-End with LAX-BOS RT Dept 01Mar07 NW2929 Dept 01Mar07 NW352 SAN LAX BOS Dept 28Mar07 NW2928 Dept 28Mar07 NW353

The LAX-BOS and BOS-LAX fare components resolve to Category 31 Record 3 with the following Table 988 data: Bytes 14-20 Byte 24 Bytes 57-88, 111-112, 138-145, and 214-221 Seq # Portion Re-price Fare/Rule 1 S Re-price Data 2 BLANK Re-price Data The data indicates that when the first fare component of the ticket is not changed, processing will match sequence 1 and 2 and apply the applicable re-pricing data. When the first fare component of the ticket is changed, processing will match sequence 2 and apply the applicable re-pricing date.

When validating the LAX-BOS and BOS-LAX fare components: • Determine first fare component of the previous itinerary: LAX-BOS. • Determine first fare component of the new itinerary: SAN-LAX. • The first fare component of the previous itinerary and the first fare component of the new itinerary do not match. • Processing will no match Table 988 sequence 1 and match sequence 2.

Page E.03.31.100 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Examples on the Following Pages Use the Original and New Itineraries Below:

ORIGINAL Itinerary: CHI-LON RT (via NYC) End-on-End with LON-PAR RT Dept 01Jan01 Dept 03Jan01 Dept 12Jan01 CHI NYC LON PAR Dept 01Feb01 Dept 28Jan01 Dept 25Jan01 Ticketing Information: Carrier Flight Date Sector Bkg Code UA 100 01JAN 01 CHI-NYC Y UA 400 03JAN 01 NYC-LON Y AF 1100 12JAN 01 LON-PAR Y AF 1200 25JAN 01 PAR-LON Y UA 401 28JAN 01 LON-NYC Y UA 101 01FEB 01 NYC-CHI Y

NEW Itinerary: Dept 01Jan01 Dept 04Jan01 Dept 12Jan01 CHI NYC LON PAR Dept 26Jan01 Dept 27Jan01 Dept 25Jan01 Ticketing Information: Carrier Flight Date Sector Bkg Code UA 100 01JAN 01 CHI-NYC Y No change UA 400 04JAN 01 NYC-LON Y CHANGE AF 1100 12JAN 01 LON-PAR Y No change AF 1200 25JAN 01 PAR-LON Y No change UA 401 27JAN 01 LON-NYC Y CHANGE UA 101 26JAN 01 NYC-CHI Y No change

Page E.03.31.101 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1 (Byte 24 coded – Geo Specs Blank) The CHI-LON and LON-CHI fare components resolve to Category 31 Record 3 with the following Table 988 data: Bytes 14-20 Byte 24 Bytes 57-88, 111-112, 138-145, and 214-221 Seq # Portion Re-price Fare/Rule 1 F Re-price Data The data indicates that when the first flight coupon of the ticket is not changed, processing will match sequence 1 and apply the applicable re-pricing data.

When validating the CHI-LON and LON-CHI fare components: MATCH • Determine first coupon of the ticket: CHI-NYC. • No changes are made to the first flight coupon. • Processing will match Table 988 sequence 1 and apply the re-price data.

The LON-PAR and PAR-LON fare components resolve to Category 31 Record 3 with the following Table 988 data: Bytes 14-20 Byte 24 Bytes 57-88, 111-112, 138-145, and 214-221 Seq # Portion Re-price Fare/Rule 1 S Re-price Data The data indicates that when the first fare component of the ticket is not changed, processing will match sequence 1 and apply the applicable re-pricing data.

When validating the CHI-LON and LON-CHI fare components: NO MATCH • Determine first fare component of the ticket: CHI-LON. • Change is made to the first fare component (change to departure date from NYC). • Processing will no match Table 988 sequence 1.

Page E.03.31.102 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.4.2. Outbound Portion of Travel (byte 41)

This field identifies a portion of the itinerary which may not be changed in order to match the Table 988 entry. Data consist of Outbound Portion of Travel field (byte 41) and three possible values. This field requires a pricing unit validation. Processing must identify all portions of travel on the previous pricing unit and determine whether there are any changes to the portions of travel (specified in byte 41) on the new pricing unit. Determination of points of change is achieved by comparing each flight segment (defined as carrier code, flight number, ticketed travel points, travel dates, class of service and travel times) on the previous ticketed itinerary to each flight segment on the new itinerary. When a flight segment on the previous itinerary does not match the new itinerary, it is considered a change. If the specified portion of travel is changed, then processing will no match this Table 988 entry and continue processing to the next applicable entry. If the specified portion of travel is not changed, then processing will match this Table 988 entry. When this field is Blank, there is no restriction on the portion of the itinerary that may be changed.

The Outbound Portion of Travel field (byte 41) provides the ability to specify no changes allowed to:

Value O From origin to first stopover or fare break whichever comes first of the pricing unit.

Value F First fare component of pricing unit.

Value Blank No restrictions on changes to the outbound portion of travel when matching Table 988 and when re-pricing the itinerary.

Page E.03.31.103 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1:

Original Itinerary – 2 pricing units PU1 CXR 1 = LON-NYC-LON PU2 CXR 2 = NYC-CHI-LAX-NYC

CXR 1 CXR 2 LON NYC CHI CXR 2 CXR 2

LAX

Result for each fare component with the following byte 41 values: Fare Component Byte 41 Result value LON-NYC O May not change LON-NYC NYC-LON O May not change LON-NYC NYC-CHI F May not change NYC-CHI CHI-LAX F May not change NYC-CHI LAX-NYC F May not change NYC-CHI

⇒ Result for LON-NYC-LON pricing unit dictates that you may not change the LON-NYC portion of travel. Changes allowed to NYC-LON in PU1. ⇒ Results for the NYC-CHI-LAX-NYC pricing unit dictates that you may not make changes to the NYC-CHI portion of travel. Changes allowed to all other portions of travel within PU2.

Page E.03.31.104 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2:

Original Itinerary – 1 pricing unit (3 component CT) CXR 1 ATL-WAS (stopover)-BOS CXR 2 BOS-LAX CXR 3 LAX-ATL

CXR 1 ATL WAS BOS

CXR 3 CXR 2 LAX

Result for each fare component with the following byte 41 values: Fare Component Byte 41 Result value ATL-BOS F May not change ATL-BOS BOS-LAX O May not change ATL-WAS sector LAX-ATL Blank No application – may change any portion of travel

⇒ All three Table 988’s will have to pass validation for the pricing unit. Therefore no changes will be allowed to the ATL-WAS (stopover)-BOS portion of travel. Changes are allowed to all other portions of travel in the pricing unit.

Page E.03.31.105 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3:

Original Itinerary – 2 pricing units PU1 CXR 1 = LON-NYC-LON PU2 CXR 2 = NYC-CHI-LAX-NYC

CXR 1 CXR 2 LON NYC CHI

CXR 2 CXR 2

LAX

Result for each fare component with the following byte 41 values: Fare Component Byte 41 Result value LON-NYC F May not change LON-NYC NYC-LON Blank No application – may change any portion of travel NYC-CHI O May not change NYC-CHI CHI-LAX O May not change NYC-CHI LAX-NYC Blank No application – may change any portion of travel

⇒ Results for LON-NYC-LON pricing unit dictates that you may not change the LON-NYC portion of travel. Changes allowed to NYC-LON in PU1. Results for the NYC-CHI-LAX-NYC pricing unit dictates that you may not make changes to the NYC-CHI portion of travel. Changes allowed to all other portions of travel within PU2.

Page E.03.31.106 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.4.3. Originally Scheduled Flight (bytes 56, 209-213) – When fields

These fields specify when the change request is permitted to be made in relation to the scheduled departure of the first un-flown, changed sector on the fare component being validated on the ticket presented for change, in order to match the table. Processing uses local time in order to determine if the change request is before scheduled departure.

A sector is considered changed if one or more of the following on the ticketed itinerary does not appear on a sector on the new itinerary: marketing carrier, flight number, origin airport, destination airport, departure date, departure time.

Flown sectors match any data in bytes 56 and 209-213. If the fare component is fully flown (all sectors of the fare component are flown), or contains no changed sectors, then processing will automatically match any data in bytes 56 and 209-213.

Page E.03.31.107 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Following is an explanation of applicable fields:

Originally Scheduled (byte 56): Specifies whether the change request for the first un-flown, changed sector on the fare component being validated must be before or after the scheduled departure of the flight on the ticket being presented for change in order to match the table.

Period/Unit (bytes 209-213): Specifies whether the change request for the first un-flown, changed sector of the fare component being validated must be a specified Period/Unit before or after (depending upon the value in byte 56) the scheduled departure of the flight in order to match the table. Data may be expressed as minutes, hours, days, or months (refer to Section 2.1 Definitions regarding how to count Period/Unit data).

Data in byte 56 specifies where to begin measurement of the Period/Unit. When Period/Unit is present with a “before” value in byte 56 (value B, D, or X), then the change request must be on/before the specified Period/Unit. Measurement starts at the beginning of the permissive time (per value in byte 56) and counts backwards. When Period/Unit is present with an “after” value in byte 56 (value A, O, or L), then the change request must be within (up to or on) the specified Period/Unit. Measurement starts at the end of the permissive time (per value in byte 56) and counts forward. When data is present in bytes 209-213, edits require data in byte56. The first un-flown, changed sector must meet the conditions in bytes 56 and 209-213 in order to match the table. If the first un-flown, changed sector does not meet the conditions in bytes 56 and 209-213, then processing will no match the table.

An explanation of applicable values in byte 56 and the impact of data in bytes 209-213 follow.

Page E.03.31.108 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

“Before” Values

Byte56 = Value B (Anytime Before) Change request must be any time before the scheduled departure time of the flight on the ticket being presented for change.

Processing compares the date and time the change is being requested to the scheduled departure date and time of the first un-flown, changed sector of the fare component being validated on the ticket being presented for change. • If the change request is anytime before the scheduled departure for the first un-flown, changed sector of the fare component being validated, then processing will match the table. • If the change request is anytime after the scheduled departure time for the first un-flown, changed sector of the fare component being validated, then processing will no match the table.

When data is present in Period/Unit (bytes 209-213), the change request must be anytime on/before the specified Period/Unit before the scheduled departure time of the flight. Measurement of applicable Unit (bytes 212-213) values follows:

Minute: Begin counting from one minute before scheduled departure time. Hour: Begin counting from one hour before scheduled departure time. Day: Begin counting from one calendar day before scheduled departure date. Month: Begin counting from the calendar date of scheduled departure to the corresponding date in an earlier month.

Page E.03.31.109 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Byte56 = Value D (Day Before) Change request must be at least 1 day before the scheduled departure time of the flight (measurement of “day” is based on 1 calendar day rather than 24 hours) on the ticket being presented for change.

Processing compares the date the change is being requested to the scheduled departure date of the first un-flown, changed sector of the fare component being validated on the ticket being presented for change. • If the change request date is 1 calendar day or more before the scheduled departure date for the first un-flown, changed sector of the fare component being validated, then processing will match the table. • If the change request date is anytime on the same date as the scheduled departure time for the first un-flown, changed sector of the fare component being validated, then processing will no match the table. • If the change request date is 1 calendar day or more after the scheduled departure time for the first un-flown, changed sector of the fare component being validated, then processing will no match the table.

When data is present in Period/Unit (bytes 209-213), the change request must be anytime on/before 1 day before the scheduled departure date of the flight plus the specified Period/Unit. Measurement of applicable Unit (bytes 212-213) values follows:

Minute: Begin counting from 2359 hours 2 days before the date of scheduled departure (the day before the day before the date of scheduled departure). Hour: Begin counting from 2300 hours 2 days before the date of scheduled departure (the day before the day before the date of scheduled departure). Day: Begin counting from 2 days before the date of scheduled departure (1 calendar day before the day before the date of scheduled departure) Month: Begin counting from the day before the date of scheduled departure to the corresponding date in an earlier month.

Page E.03.31.110 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Byte56 = Value X (Same Day or Earlier) Change request must be made on/before the day of departure of the scheduled flight (day of departure is the actual calendar date of the scheduled flight as shown on the ticket. The time of departure is not pertinent to this value) on the ticket being presented for change.

The change request may be made before or after the scheduled departure time on the ticket being presented for change, as long as it is made on/before the actual calendar date as shown on the ticket. Midnight is considered the beginning of a new date. For example, if the scheduled departure date and time is 1300 01Jan, then anytime 0000 01Jan through 2359 01Jan will match, but 0000 02Jan will no match. The change only needs to be requested on/before the actual calendar date of the scheduled departure.

Processing compares the date the change is being requested to the scheduled departure date of the first un-flown, changed sector of the fare component being validated on the ticket being presented for change. • For the first un-flown, changed sector of the fare component being validated: if the change request date is 1 calendar day or more before the scheduled departure date and/or anytime on the same date (may be before/after the scheduled time) as the scheduled departure, then processing will match the table. • If the change request date is 1 calendar day or more after the scheduled departure time for the first un-flown, changed sector of the fare component being validated, then processing will no match the table.

When data is present in Period/Unit (bytes 209-213), the change request must be anytime on/before the day of the scheduled departure date of the flight plus the specified Period/Unit. Measurement of applicable Unit (bytes 212-213) values follows:

Minute: Begin counting from 2359 hours the day before the date of scheduled departure. Hour: Begin counting from 2300 hours the day before the date of scheduled departure. Day: Begin counting from one calendar day before the date of scheduled departure. Month: Begin counting from the day of scheduled departure to the corresponding date in an earlier month.

Page E.03.31.111 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

“After” Values

Byte 56 = Value A (Anytime After) Change request must be anytime after the scheduled departure time of the flight on the ticket being presented for change.

Processing compares the date and time the change is being requested to the scheduled departure dates and times of the first un-flown, changed sector of the fare component being validated on the ticket being presented for change. If the change request is anytime after the scheduled departure for the first un-flown, changed sector of the fare component being validated, then processing will match the table (provided a match is also made to all other match fields). If the change request is anytime before the scheduled departure time for the first un-flown, changed sector of the fare component being validated, then processing will no match the table (provided a match is also made to all other match fields).

When data is present in Period/Unit (bytes 209-213), the change request must be anytime within the specified Period/Unit after the scheduled departure time of the flight. Measurement of applicable Unit (bytes 212-213) values follows:

Minute: Begin counting from one minute after scheduled departure time. Hour: Begin counting from one hour after scheduled departure time. Day: Begin counting from one calendar day after scheduled departure date. Month: Begin counting from the calendar date of scheduled departure up to the corresponding date in a later month.

Page E.03.31.112 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Byte 56 = Value O (Same Day or Later) Change request must be made on/after the day of departure of the scheduled flight (day of departure is the actual calendar date of the scheduled flight as shown on the ticket. The time of departure is not pertinent to this value) on the ticket being presented for change.

The change request may be made before or after the scheduled departure time, as long as it is made on/after the actual calendar date as shown on the ticket. Midnight is considered the beginning of a new date. For example, if the scheduled departure date and time were 1300 01Jan, then anytime 0000 01Jan through 2359 01Jan will match, but 2359 31Dec will no match. The change only needs to be requested on/after the actual calendar date of the scheduled departure.

Processing compares the date the change is being requested to the scheduled departure dates of the first un-flown, changed sector of the fare component being validated on the ticket being presented for change. • For the first un-flown, changed sector of the fare component being validated: if the change request date is 1 calendar day or more after the scheduled departure date and/or anytime on the same date (may be before/after the scheduled time) as the scheduled departure, then processing will match the table (provided a match is also made to all other match fields). • If the change request date is 1 calendar day or more before the scheduled departure time for the first un-flown, changed sector of the fare component being validated, then processing will no match the table (provided a match is also made to all other match fields).

When data is present in Period/Unit (bytes 209-213), the change request must be anytime within the day of the scheduled departure date of the flight plus the specified Period/Unit. Measurement of applicable Unit (bytes 212-213) values follows:

Minute: Begin counting from 0001 hours the day after the date of scheduled departure. Hour: Begin counting from 0100 hours the day after the date of scheduled departure. Day: Begin counting from one calendar day after the date of scheduled departure. Month: Begin counting from the calendar date of scheduled departure up to the corresponding date in a later month

Page E.03.31.113 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Byte 56 = Value L (Day After) Change request must be at least 1 day after the scheduled departure time of the flight (measurement of “day” is based on 1 calendar day rather than 24 hours) on the ticket being presented for change.

Processing compares the date the change is being requested to the scheduled departure dates of the first un-flown, changed sector of the fare component being validated on the ticket being presented for change. • If the change request date is 1 calendar day or more after the scheduled departure time for the first un-flown, changed sector of the fare component being validated, then processing will match the table (provided a match is also made to all other match fields). • If the change request date is anytime on the same date as the scheduled departure time for the first un-flown, changed sector of the fare component being validated, then processing will no match the table (provided a match is also made to all other match fields). • If the change request date is 1 calendar day or more before the scheduled departure date for the first un-flown, changed sector of the fare component being validated, then processing will no match the table (provided a match is also made to all other match fields).

When data is present in Period/Unit (bytes 209-213), the change request must be anytime within the specified Period/Unit measured from 1 day after the scheduled departure date of the flight. Measurement of applicable Unit (bytes 212-213) values follows:

Minute: Begin counting from 0001 hours the 2 days after the date of scheduled departure (the day after the day after the date of scheduled departure). Hour: Begin counting from 0100 hours 2 days after the date of scheduled departure (the day after the day after the date of scheduled departure). Day: Begin counting from 2 calendar days after the date of scheduled departure (one calendar day after the day after the date of scheduled departure). Month: Begin counting from the day after the date of scheduled departure up to the corresponding date in a later month.

Byte 56 = Value Blank (no restrictions) Change request may be anytime before or after the scheduled departure time of the first un-flown sector of the fare component being validated on the ticket being presented for change. Processing will automatically match byte 56.

Page E.03.31.114 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Timeline/Examples

Timeline The timeline below illustrates the application of Originally Scheduled Flight Values (byte56) for a scheduled departure date/time of 15 February 2004 at 1600 hours.

Value X (same day or earlier)

Value D (day before)

Value B (anytime before)

14 February 2004 15 February 2004 16 February 2004

1600 hours dept time Value A (anytime after)

Value O (same day or later)

Value L (day after)

Day before Departure Day after Departure Day of Departure When scheduled departure is 15 February 2004 at 1600 hours, change request must be (depending upon the value in byte 56): Value B: On/before 1559 hours on 15 February 2004. Value A: On/after 1601 hours on 15 February 2004. Value D: On/before 2359 hours on 14 February 2004. Value O: On/after 0000 hours on 15 February 2004. Value X: On/before 2359 hours on 15 February 2004. Value L: On/after 0000 hours on 16 February 2004.

Page E.03.31.115 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Examples – Period/Unit The examples in the chart below are based on a scheduled departure date/time of 15Feb2004 at 1600 hours (as illustrated in the timeline above):

Orig Skd (byte 56) Period (209- Unit (212- RESULT– Change Request Must Be: 211) 213) 1 B 004 Nb Anytime on/before 1556 hours on 15Feb04 2 B 000 Nb Anytime on/before 1600 hours on 15Feb04 3 B 004 Hb Anytime on/before 1200 hours on 15Feb04 4 B 000 Hb Anytime on/before 1600 hours on 15Feb04 5 B 001 Db Anytime on/before 2359 hours on 14Feb04 6 B 000 Db Anytime on/before 1600 hours on 15Feb04 7 B 001 Mb Anytime on/before 2359 hours on 15Jan04 8 B 000 Mb Anytime on/before 1600 hours on 15Feb04

9 D 004 Nb Anytime on/before 2356 hours on 13Feb04 10 D 000 Nb Anytime on/before 0000 hours on 14Feb04 11 D 004 Hb Anytime on/before 2000 hours on 13Feb04 12 D 000 Hb Anytime on/before 0000 hours on 14Feb04 13 D 001 Db Anytime on/before 2359 hours on 13Feb04 14 D 000 Db Anytime on/before 2359 hours on 14Feb04 15 D 001 Mb Anytime on/before 2359 hours on 14Jan04 16 D 000 Mb Anytime on/before 2359 hours on 14Feb04

17 X 004 Nb Anytime on/before 2356 hours on 14Feb04 18 X 000 Nb Anytime on/before 0000 hours on 15Feb04 19 X 004 Hb Anytime on/before 2000 hours on 14Feb04 20 X 000 Hb Anytime on/before 0000 hours on 15Feb04 21 X 001 Db Anytime on/before 2359 hours on 14Feb04 22 X 000 Db Anytime on/before 2359 hours on 15Feb04

Page E.03.31.116 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Orig Skd (byte 56) Period (209- Unit (212- RESULT– Change Request Must Be: 211) 213) 23 X 001 Mb Anytime on/before 2359 hours on 15Jan04 24 X 000 Mb Anytime on/before 2359 hours on 15Feb04

25 A 004 Nb Anytime between 1601 hours to 1604 hours on 15Feb04 26 A 000 Nb At 1600 hours on 15Feb04 27 A 004 Hb Anytime between 1601 hours to 2000 hours on 15Feb04 28 A 000 Hb Anytime between 1601 hours to 1659 hours on 15Feb04 29 A 001 Db Anytime between 1601 hours on 15Feb04 to 2359 hours on 16Feb04 30 A 000 Db Anytime between 1601 hours to 2359 hours on 15Feb04 31 A 001 Mb Anytime between 1601 hours on 15Feb04 to 2359 hours on 15Mar04 32 A 000 Mb Anytime between 1601 hours on 15Feb04 to 2359 hours on 29Feb04

33 O 004 Nb Anytime between 0000 hours on 15Feb04 to 0004 hours on 16Feb04 34 O 000 Nb Anytime between 0000 hours on 15Feb04 to 0000 hours on 16Feb04 35 O 004 Hb Anytime between 0000 hours on 15Feb04 to 0400 hours on 16Feb04 36 O 000 Hb Anytime between 0000 hours on 15Feb04 to 0059 hours on 16Feb04 37 O 001 Db Anytime between 0000 hours on 15Feb04 to 2359 hours on 16Feb04 38 O 000 Db Anytime between 0000 hours to 2359 hours on 15Feb04 39 O 001 Mb Anytime between 0000 hours on 15Feb04 to 2359 hours on 15Mar04 40 O 000 Mb Anytime between 0000 hours on 15Feb04 to 2359 hours on 29Feb04

41 L 004 Nb Anytime between 0000 hours on 16Feb04 to 0004 hours on 17Feb04 42 L 000 Nb Anytime between 0000 hours on 16Feb04 to 0000 hours on 17Feb04 43 L 004 Hb Anytime between 0000 hours on 16Feb04 to 0400 hours on 17Feb04 44 L 000 Hb Anytime between 0000 hours on16Feb04 to 0059 hours on 17Feb04 45 L 001 Db Anytime between 0000 hours on 16Feb04 to 2359 hours on 17Feb04 46 L 000 Db Anytime between 0000 hours to 2359 hours on 16Feb04 47 L 001 Mb Anytime between 0000 hours on 16Feb04 to 2359 hours on 16Mar04

Page E.03.31.117 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Orig Skd (byte 56) Period (209- Unit (212- RESULT– Change Request Must Be: 211) 213) 48 L 000 Mb Anytime between 0000 hours on 16Feb04 to 2359 hours on 29Feb04

The examples on the following pages further illustrate the application of the Originally Scheduled Flight fields.

Page E.03.31.118 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Examples on the following pages use the itinerary below:

Ticket being presented for change:

Itinerary: NYC-LAX RT (via CHI) Ticket Issue Date = 01Jan 03 Dept 25Jan03at 0900 Dept 12Feb03 at 1425 NYC CHI LAX Dept 28Feb03 at 0800 Dept 15Feb03 at 1300 Ticketing Information: Sector Carrier Flight Time Date Flown? NYC-CHI UA 100 0900 25JAN 03 Flown CHI-LAX UA 200 1425 03FEB 03 Unflown LAX-CHI UA 300 1300 15FEB 03 Unflown CHI-NYC UA 500 0800 28FEB 03 Unflown

Page E.03.31.119 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1 – Value B (Anytime Before)

Example 1A (Value B – Blank Period/Unit)

Category 31 Record 3: Byte 56 Bytes 209-211 Bytes 212-213 Orig Skd Flt Period Unit B Blank Blank The data indicates that when the change is requested anytime before the scheduled departure time of the first unflown flight on the fare component being validated, processing will match the table (provided a match is also made to all other match fields).

When the Change Request Date/Time = 12Feb03 at 1610 hours

When validating the NYC-LAX fare component that resolves to the Cat 31 Rec 3 above: No Match The change request is after the scheduled departure time for the unflown CHI-LAX sector; therefore, processing will no match the table.

When validating the LAX-NYC fare component that resolves to the Cat 31 Rec 3 above: Match The change request is prior to the scheduled departure time for the unflown LAX-CHI sector; therefore, processing will match the table (provided a match is also made to all other match fields). NOTE: Since at least one fare component on the ticket cannot match applicable Category 31 data (and no other Category 31 tables exist), automated changes are not permitted. In such a situation, processing does not need to attempt a match for the other fare components on the ticket, and the above processing is provided for illustrative purposes only.

Page E.03.31.120 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1B (Value B – With Period/Unit in Days)

Category 31 Record 3: Byte 56 Bytes 209-211 Bytes 212-213 Orig Skd Flt Period Unit B 7 Db The data indicates that when the change is requested 7 days or more prior to the scheduled departure time of the first unflown flight on the fare component being validated, processing will match the table (provided a match is also made to all other match fields).

When the Change Request Date/Time = 05Feb03 at 2300 hours

When validating the NYC-LAX fare component that resolves to the Cat 31 Rec 3 above: Match • For the unflown CHI-LAX sector, determine the date/time by which the change must be requested in order to match the table (provided a match is also made to all other match fields): on/before 05Feb03 at 2359 hours. • The change request is before the above date/time; therefore processing will match the table (provided a match is also made to all other match fields).

When validating the LAX-NYC fare component that resolves to the Cat 31 Rec 3 above: Match • For the unflown LAX-CHI sector, determine the date/time by which the change must be requested in order to match the table (provided a match is also made to all other match fields): on/before 08Feb03 at 2359 hours. • The change request is before the above date/time; therefore processing will match the table (provided a match is also made to all other match fields).

Page E.03.31.121 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2 – Value D (Day Before or Earlier)

Example 2A (Value D – Blank Period/Unit)

Category 31 Record 3: Byte 56 Bytes 209-211 Bytes 212-213 Orig Skd Flt Period Unit D Blank Blank The data indicates that when the change is requested 1 day or more prior to scheduled departure date of the first unflown flight on the fare component being validated, processing will match the table (provided a match is also made to all other match fields).

When the Change Request Date/Time = 11Feb03 at 2359 hours

When validating the NYC-LAX fare component that resolves to the Cat 31 Rec 3 above: Match • For the unflown CHI-LAX sector, determine the date/time by which the change must be requested in order to match the table (provided a match is also made to all other match fields): on/before 11Feb03 at 2359 hours. • The change request is before the above date/time; therefore processing will match the table (provided a match is also made to all other match fields).

When validating the LAX-NYC fare component that resolves to the Cat 31 Rec 3 above: Match • For the unflown LAX-CHI sector, determine the date/time by which the change must be requested in order to match the table (provided a match is also made to all other match fields): on/before 14Feb03 at 2359 hours. • The change request is before the above date/time; therefore processing will match the table (provided a match is also made to all other match fields).

Page E.03.31.122 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2B (Value D – With Period/Unit in Days)

Category 31 Record 3: Byte 56 Bytes 209-211 Bytes 212-213 Orig Skd Flt Period Unit D 7 Db The data indicates that when the change is requested at least 7 days prior to one day before the scheduled departure date of the first unflown flight on the fare component being validated, processing will match the table (provided a match is also made to all other match fields).

When the Change Request Date/Time = 05Feb03 at 2300 hours

When validating the NYC-LAX fare component that resolves to the Cat 31 Rec 3 above: No Match • For the unflown CHI-LAX sector, determine the date/time by which the change must be requested in order to match the table (provided a match is also made to all other match fields): on/before 04Feb03 at 2359 hours. • The change request is after the above date/time; therefore processing will no match the table.

When validating the LAX-NYC fare component that resolves to the Cat 31 Rec 3 above: Match • For the unflown LAX-CHI sector, determine the date/time by which the change must be requested in order to match the table (provided a match is also made to all other match fields): on/before 07Feb03 at 2359 hours. • The change request is before the above date/time; therefore processing will match the table (provided a match is also made to all other match fields). NOTE: Since at least one fare component on the ticket cannot match applicable Category 31 data (and no other Category 31 tables exist), automated changes are not permitted. In such a situation, processing does not need to attempt a match for the other fare components on the ticket, and the above processing is provided for illustrative purposes only.

Page E.03.31.123 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3 – Value X (Day Of or Earlier)

Example 3A (Value X – Blank Period/Unit)

Category 31 Record 3: Byte 56 Bytes 209- Bytes 212-213 Orig Skd Flt 211 Unit Period X Blank Blank The data indicates that when the change is requested anytime on/before the scheduled departure date for the first unflown flight on the fare component being validated, processing will match the table (provided a match is also made to all other match fields).

When the Change Request Date/Time = 11Feb03 at 2359 hours

When validating the NYC-LAX fare component that resolves to the Cat 31 Rec 3 above: Match • For the unflown CHI-LAX sector, determine the date/time by which the change must be requested in order to match the table (provided a match is also made to all other match fields): anytime on/before 12Feb03. • The change request is before the above date/time; therefore processing will match the table (provided a match is also made to all other match fields).

When validating the LAX-NYC fare component that resolves to the Cat 31 Rec 3 above: Match • For the unflown LAX-CHI sector, determine the date/time by which the change must be requested in order to match the table: anytime on/before 15Feb03. • The change request is before the above date/time; therefore processing will match the table (provided a match is also made to all other match fields).

Page E.03.31.124 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3B (Value X – With Period/Unit in Days)

Category 31 Record 3: Byte 56 Bytes 209-211 Bytes 212-213 Orig Skd Flt Period Unit X 7 Db The data indicates that when the change is requested at least 7 days before the end of the scheduled departure date for the first unflown flight on the fare component being validated, processing will match the table (provided a match is also made to all other match fields).

When the Change Request Date/Time = 05Feb03 at 2300 hours

When validating the NYC-LAX fare component that resolves to the Cat 31 Rec 3 above: Match • For the unflown CHI-LAX sector, determine the date/time by which the change must be requested in order to match the table: on/before 05Feb03 at 2359 hours. • The change request is before the above date/time; therefore processing will match the table (provided a match is also made to all other match fields).

When validating the LAX-NYC fare component that resolves to the Cat 31 Rec 3 above: Match • For the unflown LAX-CHI sector, determine the date/time by which the change must be requested in order to match the table: on/before 08Feb03 at 2359 hours. • The change request is before the above date/time; therefore processing will match the table (provided a match is also made to all other match fields).

Page E.03.31.125 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 4 – Value A (Anytime After)

Example 4A (Value A – Blank Period/Unit)

Category 31 Record 3: Byte 56 Bytes 209-211 Bytes 212-213 Orig Skd Flt Period Unit A Blank Blank The data indicates that when the change is requested anytime after the scheduled departure time of the first unflown flight on the fare component being validated, processing will match the table (provided a match is also made to all other match fields).

When the Change Request Date/Time = 12Feb03 at 1610 hours

When validating the NYC-LAX fare component that resolves to the Cat 31 Rec 3 above: Match The change request is after the scheduled departure time for the unflown CHI-LAX sector; therefore, processing will match the table (provided a match is also made to all other match fields).

When validating the LAX-NYC fare component that resolves to the Cat 31 Rec 3 above: No Match The change request is prior to the scheduled departure time for the unflown LAX-CHI sector; therefore, processing will no match the table. NOTE: Since at least one fare component on the ticket cannot match applicable Category 31 data (and no other Category 31 tables exist), automated changes are not permitted. In such a situation, processing does not need to attempt a match for the other fare components on the ticket, and the above processing is provided for illustrative purposes only.

Page E.03.31.126 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 4B (Value A – With Period/Unit in Days)

Category 31 Record 3: Byte56 Bytes 209-211 Bytes 212-213 Orig Skd Flt Period Unit A 7 Db The data indicates that when the change is requested within 7 days of the scheduled departure date/time of the first unflown flight on the fare component being validated, processing will match the table (provided a match is also made to all other match fields).

When the Change Request Date/Time = 12Feb03 at 1610 hours

When validating the NYC-LAX fare component that resolves to the Cat 31 Rec 3 above: Match • For the unflown CHI-LAX sector, determine the date/time when the change must be requested in order to match the table: anytime from 12Feb03 at 1426 hours to 19Feb03 at 2359 hours. • The change request is within the above date/time; therefore processing will match the table (provided a match is also made to all other match fields).

When validating the LAX-NYC fare component that resolves to the Cat 31 Rec 3 above: No Match • For the unflown LAX-CHI sector, determine the date/time when the change must be requested in order to match the table: anytime from 15Feb03 at 1301 hours to 22Feb03 at 2359 hours. • The change request is not within the above date/time; therefore processing will no match the table.

Page E.03.31.127 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 5 – Value L (Day After or Later)

Example 5A (Value L – Blank Period/Unit)

Category 31 Record 3: Byte 56 Bytes 209-211 Bytes 212-213 Orig Skd Flt Period Unit L Blank Blank The data indicates that when the change is requested 1 day or more after scheduled departure date of the first unflown flight on the fare component being validated, processing will match the table (provided a match is also made to all other match fields).

When the Change Request Date/Time = 08Mar03 at 1525 hours

When validating the NYC-LAX fare component that resolves to the Cat 31 Rec 3 above: Match • For the unflown CHI-LAX sector, determine the date/time when the change must be requested in order to match the table: anytime on/after 13Feb03. • The change request is after the above date/time; therefore processing will match the table (provided a match is also made to all other match fields).

When validating the LAX-NYC fare component that resolves to the Cat 31 Rec 3 above: No Match • For the unflown LAX-CHI sector, determine the date/time when the change must be requested in order to match the table: anytime on/after 16Feb03 • The change request is before the above date/time; therefore processing will no match the table.

Page E.03.31.128 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 5B (Value L – With Period/Unit in Days)

Category 31 Record 3: Byte 56 Bytes 209-211 Bytes 212-213 Orig Skd Flt Period Unit L 7 Db The data indicates that when the change is requested within 7 days of the day after departure of the scheduled departure date of the first unflown flight on the fare component being validated, processing will match the table (provided a match is also made to all other match fields).

When the Change Request Date/Time = 15Feb03 at 0825 hours

When validating the NYC-LAX fare component that resolves to the Cat 31 Rec 3 above: Match • For the unflown CHI-LAX sector, determine the date/time when the change must be requested in order to match the table: anytime 13Feb03 to 20Feb03. • The change request is within the above date/time; therefore processing will match the table (provided a match is also made to all other match fields).

When validating the LAX-NYC fare component that resolves to the Cat 31 Rec 3 above: No Match • For the unflown LAX-CHI sector, determine the date/time when the change must be requested in order to match the table: anytime 16Feb03 to 23Feb03 • The change request is not within the above date/time; therefore processing will no match the table.

Page E.03.31.129 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 6 – Value O (Day Of or Later)

Example 6A (Value O – Blank Period/Unit)

Category 31 Record 3: Byte 56 Bytes 209-211 Bytes 212-213 Orig Skd Flt Period Unit O Blank Blank The data indicates that when the change is requested anytime on/after the scheduled departure date for the first unflown flight on the fare component being validated, processing will match the table (provided a match is also made to all other match fields).

When the Change Request Date/Time = 12Feb03 at 0800 hours

When validating the NYC-LAX fare component that resolves to the Cat 31 Rec 3 above: Match • For the unflown CHI-LAX sector, determine the date/time by which the change must be requested in order to match the table: anytime on/after 12Feb03. • The change request is within the above date/time; therefore processing will match the table (provided a match is also made to all other match fields).

When validating the LAX-NYC fare component that resolves to the Cat 31 Rec 3 above: No Match • For the unflown LAX-CHI sector, determine the date/time by which the change must be requested in order to match the table: anytime on/after 15Feb03. • The change request is not within the above date/time; therefore processing will no match the table.

Page E.03.31.130 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 6B (Value O – With Period/Unit in Days)

Category 31 Record 3: Byte 56 Bytes 209-211 Bytes 212-213 Orig Skd Flt Period Unit O 7 Db The data indicates that when the change is requested at within 7 days of the scheduled departure date for the first unflown flight on the fare component being validated, processing will match the table (provided a match is also made to all other match fields).

When the Change Request Date/Time = 17Feb03 at 2300 hours

When validating the NYC-LAX fare component that resolves to the Cat 31 Rec 3 above: Match • For the unflown CHI-LAX sector, determine the date/time by which the change must be requested in order to match the table: anytime between 12Feb03 and 19Feb03. • The change request is within the above date/time; therefore processing will match the table (provided a match is also made to all other match fields).

When validating the LAX-NYC fare component that resolves to the Cat 31 Rec 3 above: Match • For the unflown LAX-CHI sector, determine the date/time by which the change must be requested in order to match the table: anytime between 15Feb03 and 22Feb03. • The change request is within the above date/time; therefore processing will match the table.

Page E.03.31.131 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.4.4. Date (byte 89)

This field specifies whether the new departure date from the origin of the fare component must be on the same or different later date than the departure date from the origin of the fare component being validated on the previous itinerary. Applicable values in byte 89 are:

Value X: Departure date from the origin of the fare component on the new itinerary must be on the same date. Value D: Departure date from the origin of the fare component on the new itinerary must be on a different, later date. BLANK: Departure date from the origin of the fare component on the new itinerary may be on the same or different later/earlier date.

When byte 89 is value X or D, processing compares the date of departure for the fare component being validated on the previous ticket to the new date of departure for the fare component on the new ticket. If the new date does not meet the requirements of the value in byte 89, then processing will no match this Table 988 entry and continue processing to the next applicable entry. If any changes are made to the origin and/or destination of the previous fare component, then the value in byte 89 has no application and should be ignored. (ATPCO’s Coding Convention holds that if Changes to fare break points are permitted on the journey and byte 89 data applies, then the reissue information should be entered in multiple Table 988 sequences. Refer to the Coding Convention Section 6.0 for further information.)

If travel has already occurred from the origin of the fare component being validated, then processing may match value X or Blank. Processing will no match value D.

Page E.03.31.132 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Examples on the Following Pages Use the Original and New Itineraries Below:

Original Itinerary: NYC-LAX RT (via CHI) Ticket Issue Date = 01Jan 01 Dept 25Jan01 Dept 03Feb01 NYC CHI LAX Dept 28Feb01 Dept 15Feb01 Ticketing Information: Carrier Flight Time Date Sector UA 100 0900 25JAN 01 NYC-CHI UA 200 1425 03FEB 01 CHI-LAX UA 300 1300 15FEB 01 LAX-CHI UA 500 0800 28FEB 01 CHI-NYC

New Itinerary requested on 15Jan01: Dept 25Jan01 Dept 10Feb01 NYC CHI LAX Dept 28Feb01 Dept 15Feb01 Ticketing Information: Carrier Flight Time Date Sector UA 101 1000 25JAN 01 NYC-CHI CHANGE UA 200 1425 10FEB 01 CHI-LAX CHANGE UA 300 1300 15FEB 01 LAX-CHI No change UA 500 1845 28FEB 01 CHI-NYC CHANGE

Page E.03.31.133 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1 (Value X)

The NYC-LAX and LAX-NYC fare components resolve to Category 31 Record 3 with the following Table 988 data: Bytes 14- Byte 89 Bytes 57-88 , 111-112, 138-145, and 214- 20 Date 221 Seq # Re-price Fare/Rule 1 X Re-price Data The data indicates that when the new departure date from the origin of the fare component is on the same date as the previous departure date from the origin of the fare component being validated; processing will match sequence 1 and apply the applicable re- pricing data.

When validating the NYC-LAX fare component: Match • NYC-LAX fare component has not been flown. New departure date from NYC (25Jan01) is the same as the previous departure date. • Processing will match Table 988 sequence 1 and apply the re-price data.

When validating the LAX-NYC fare component: Match • LAX-NYC fare component has not been flown. New departure date from LAX (15Feb01) is the same as the previous departure date. • Processing will match Table 988 sequence 1 and apply the re-price data.

Page E.03.31.134 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2 (Value D)

The NYC-LAX and LAX-NYC fare components resolve to Category 31 Record 3 with the following Table 988 data: Bytes 14- Byte 89 Bytes 57-88 , 111-112, 138-145, and 214- 20 Date 221 Seq # Re-price Fare/Rule 1 D Re-price Data The data indicates that when the new departure date from the origin of the fare component is on a different, later date than the previous departure date from the origin of the fare component being validated; processing will match sequence 1 and apply the applicable re-pricing data.

When validating the NYC-LAX fare component: No Match • NYC-LAX fare component has not been flown. New departure date from NYC (25Jan01) is not on a different, later date than the previous departure date. • Processing will no match Table 988 sequence 1.

When validating the LAX-NYC fare component: No Match • LAX-NYC fare component has not been flown. New departure date from LAX (15Feb 01) is not on a different, later date than the previous departure date. • Processing will no match Table 988 sequence 1.

Page E.03.31.135 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.4.5. Flight Number (byte 42)

This field specifies whether changes are permitted to the FLTNOs (defined as marketing carrier plus flight number) on the fare component being validated on the previous itinerary. FLTNOs are not considered changed provided: • the new itinerary contains each FLTNO found on the fare component being validated on the previous ticket • there is no change to origin or destination airport of any FLTNO found on the fare component being validated on the previous ticket • there is no change to the order in which the FLTNOs found on the fare component being validated on the previous ticket appear on the new itinerary

The FLTNOs on the fare component being validated need not all be a part of the same fare component on the new itinerary. New flights, without regard to their FLTNOs, may appear on the new itinerary before, after, and/or between the FLTNOs on the fare component being validated on the previous itinerary. The values of this field are:

X Changes to the FLTNOs on the fare component being validated on the previous itinerary are not permitted. Blank No Application.

Page E.03.31.136 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Examples

Assume all previous fare components in the following examples resolve to the following Table 988: Byte 42 Byte 43 Flight Term Number X Y The above data dictates that changes to the FLTNOs on the fare component being validated on the previous itinerary are not permitted. Changes to fare break points are permitted.

Example 1: no changes to FLTNOs, FLTNO order, origin or destination of FLTNOs. Departure dates have changed. A new flight number appears on the new itinerary.

Previous fare component: SYD-BKK

Mkt Cxr XX Flt 675 Mkt Cxr XX Flt 1095 Mkt Cxr XX Flt 2121 Dept 12Feb09 Dept 14Feb09 Dept 18Feb09 SYD SIN KUL BKK

New itinerary: SYD-DXB

Mkt Cxr XX Flt 675 Mkt Cxr XX Flt 1095 Mkt Cxr XX Flt 2121 Mkt Cxr ZZ Flt 123 Dept 03Jun09 Dept 06Jun09 Dept 10Jun09 Dept 10Jun09 SYD SIN KUL BKK DXB

Attempt to match the Table 988: • The new itinerary contains each FLTNO found on the fare component being validated on the previous ticket, in the same order and with no changes to origin or destination airports. • Processing will match the Table 988 sequence, provided a match is made to all other match fields.

Page E.03.31.137 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2: replace a FLTNO with a different FLTNO

Previous fare component: SYD-BKK

Mkt Cxr XX Flt 675 Mkt Cxr XX Flt 1095 Mkt Cxr XX Flt 2121 Dept 12Feb09 Dept 14Feb09 Dept 18Feb09 SYD SIN KUL BKK

New itinerary: SYD-BKK

Mkt Cxr XX Flt 675 Mkt Cxr XX Flt 3 Mkt Cxr XX Flt 2121 Dept 12Feb09 Dept 14Feb09 Dept 18Feb09 SYD SIN KUL BKK

Attempt to match the Table 988: • A FLTNO on the previous fare component has been replaced with a different FLTNO on the new itinerary. • Processing will no-match the Table 988 sequence.

Page E.03.31.138 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3: replace a surface sector with a FLTNO

Previous component: SYD-BKK

Mkt Cxr XX Flt 675 Mkt Cxr XX Flt 2121 Dept 12Feb09 S U R F A C E Dept 18Feb09 SYD SIN KUL BKK

New itinerary: SYD-BKK

Mkt Cxr XX Flt 675 Mkt Cxr ZZ Flt 1095 Mkt Cxr XX Flt 2121 Dept 12Feb09 Dept 14Feb09 Dept 18Feb09 SYD SIN KUL BKK

Attempt to match the Table 988: • The new itinerary contains each FLTNO found on the fare component being validated on the previous ticket, in the same order and with no changes to origin or destination airports. A FLTNO that did not appear on the previous fare component appears on the new itinerary. • Processing will match the Table 988 sequence, provided a match is made to all other match fields.

Page E.03.31.139 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 4: replace a surface sector with an open segment

Previous component: SYD-BKK

Mkt Cxr XX Flt 675 Mkt Cxr XX Flt 2121 Dept 12Feb09 S U R F A C E Dept 18Feb09 SYD SIN KUL BKK

New itinerary: SYD-BKK

Mkt Cxr XX Flt 675 Mkt Cxr YY Flt OPEN Mkt Cxr XX Flt 2121 Dept 12Feb09 Dept 09:50 14Feb09 Dept 18Feb09 SYD SIN KUL BKK

Attempt to match the Table 988: • The new itinerary contains each FLTNO found on the fare component being validated on the previous ticket, in the same order and with no changes to origin or destination airports. • Processing will match the Table 988 sequence, provided a match is made to all other match fields.

Page E.03.31.140 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 5: replace a FLTNO with a surface sector

Previous fare component: SYD-BKK

Mkt Cxr XX Flt 675 Mkt Cxr XX Flt 1095 Mkt Cxr XX Flt 2121 Dept 12Feb09 Dept 14Feb09 Dept 18Feb09 SYD SIN KUL BKK

New itinerary: SYD-BKK

Mkt Cxr XX Flt 675 Mkt Cxr XX Flt 2121 Dept 12Feb09 S U R F A C E Dept 18Feb09 SYD SIN KUL BKK

Attempt to match the Table 988: • A FLTNO on the previous fare component does not appear on the new itinerary. • Processing will no-match the Table 988 sequence.

Page E.03.31.141 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 6: change to the destination of the FLTNO

Previous fare component: ANC-PVR

Mkt Cxr XX Flt 21 Mkt Cxr XX Flt 33 Dept 12Feb09 Dept 18Feb09 ANC LAX PVR

New itinerary: ANC-ZIH

Mkt Cxr XX Flt 21 Mkt Cxr XX Flt 33 Dept 12Feb09 Dept 18Feb09 ANC LAX ZIH

Attempt to match the Table 988: • The new itinerary contains each FLTNO found on the fare component being validated on the previous ticket, in the same order. The destination airport of one of the FLTNOs has changed. • Processing will no-match the Table 988 sequence.

Page E.03.31.142 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 7: replace the marketing carrier of an open segment

Previous fare component: SYD-BKK

Mkt Cxr XX Flt 675 Mkt Cxr XX Flt OPEN Mkt Cxr XX Flt 2121 Dept 12Feb09 Dept 09:50 14Feb09 Dept 18Feb09 SYD SIN KUL BKK

New itinerary: SYD-BKK

Mkt Cxr XX Flt 675 Mkt Cxr ZZ Flt OPEN Mkt Cxr XX Flt 2121 Dept 12Feb09 Mkt Cxr XX Flt OPEN Dept 18Feb09 SYD SIN KUL BKK

Attempt to match the Table 988: • The new itinerary contains the FLTNOs found on the fare component being validated on the previous ticket with no changes to origin or destination airports. The marketing carrier on the open segment has changed. • Processing will no-match the Table 988 sequence.

Page E.03.31.143 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 8: change the marketing carrier of an open segment from “blank” or “YY” to a specific marketing carrier

Previous fare component: SYD-BKK

Mkt Cxr XX Flt 675 Mkt Cxr YY Flt OPEN Mkt Cxr XX Flt 2121 Dept 12Feb09 Dept 14Feb09 Dept 18Feb09 SYD SIN KUL BKK

New itinerary: SYD-BKK

Mkt Cxr XX Flt 675 Mkt Cxr ZZ Flt OPEN Mkt Cxr XX Flt 2121 Dept 12Feb09 Dept 14Feb09xr XX Flt OPEN Dept 18Feb09 SYD SIN KUL BKK

Attempt to match the Table 988: • The new itinerary contains the FLTNOs found on the fare component being validated on the previous ticket with no changes to origin or destination airports. Marketing carrier “YY” on the open segment has been replaced with a specific marketing carrier. • Processing will match the Table 988 sequence, provided a match is made to all other match fields.

Page E.03.31.144 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5. RE-PRICE THE NEW ITINERARY USING TABLE 988

Once a match is made to a Table 988 sequence, processing will validate the information in the sequence regarding how to re- price the new itinerary and what conditions must be validated and revalidated. The Table 988 information for all fare components in the previous itinerary will be used to determine the lowest fare result for the new itinerary. Once the lowest fare result is determined for the new itinerary, the change fee to be applied is determined in Category 31 for each fare component. Refer to Section 4.6 for specific data application on calculating the change fee.

Information in Table 988 regarding how to re-price the itinerary is in the RE-PRICING RULES fields: 4.5.2 Stop (Table 988 byte 206) 4.5.3 Process Tag (Table 988 bytes 21-22) 4.5.4 Fare Break Limitations (Table 988 bytes 43-46 and 48-55) 4.5.5 Fares (Table 988 bytes 57-88, 111-112, 138-145, and 214-221) 4.5.6 Revalidate Rules/ RBDs (Table 988 bytes 90-121) 4.5.7 New Ticket Must Have an Equal or Higher Value (Table 988 byte 208)

Sequence Processing (Table 988 bytes 14-20) A single Table 988 can identify multiple entries for the same Process Tag value (Table 988 bytes 21-22) and/or different Process Tag values (multiple sequences for the same or different Process Tag values). Since there may be several valid re- pricing solutions for a single Process Tag, multiple entries for the same Process Tag value should be reviewed in ascending order by Sequence Number (Table 988 bytes 14-20). Once a match is made to a sequence for a given Process Tag, process the re-price data in that sequence, then continue the review process to the next entry (even if the next entry contains the same Process Tag value).

Page E.03.31.145 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.1 Stop (Table 988 byte 206)

The sequence processing described above may be halted when the Stop field (Table 988 byte 206) is value X or value Y and the permutation results in a re-price solution.

Valid field values are:

Value X When the Stop field is value X and a match is made to the sequence with Stop value X, processing will continue the review process to the next sequence in this Table 988 that contains a different Process Tag value. Processing may still continue to another Category 31 Record 3 table and apply all Table 988 sequences regardless of Process Tag values in this other table.

Value Y If every fare component in any one permutation that results in a reprice solution contains Stop field (Table 988 byte 206) value Y, then processing will discard all permutations in which every fare component does not contain Stop field (Table 988 byte 206) value Y (with the Process Tag 7 exception described below).

Note: Edits require that when the Stop field (Table 988 byte 206) is value Y, then the Process Tag field (Table 988 bytes 21- 22) must be value 01 (Keep the Fares).

Process Tag 7 Exception

Process Tag 7 (Reissue to a Lower Fare) supersedes the processing when the Stop field (Table 988 byte 206) is value Y. If a re-price permutation exists that contains all Process Tag 7’s and results in a re-price solution, this permutation will be processed in addition to the Process Tag 1 re-price permutation which has the Stop field (Table 988 byte 206) coded as value Y for all fare components within the permutation. The permutation which provides the lowest result shall be applied.

Page E.03.31.146 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1 (Single Category 31 Table in the Set)

THEN Category 31 Table 988 Bytes 14-20 Bytes 21-22 Byte 206 SeqNumber Process Tag Stop 1 1 X 2 1 BLANK 3 1 BLANK 4 2 X 5 2 BLANK 6 5 BLANK

Process Tag Retrieval: For the purpose of this example, assume the Category 31 table is a match. • Process Tag 1: • For the purpose of this example, assume Sequence 1 is a no-match; continue the match process to Sequence 2. • For the purpose of this example, assume Sequence 2 is a match and attempt the reissue transaction. Since byte 206 is Blank, continue the match process to Sequence 3 • For the purpose of this example, assume Sequence 3 is a match and attempt the reissue transaction. Continue processing to the next Process Tag. • Process Tag 2: • For the purpose of this example, assume Sequence 4 is a match and attempt the reissue transaction. Since byte 206 is value X, do not process the remainder of the sequences for Process Tag 2. Continue processing to the next Process Tag. • Process Tag 5: • For the purpose of this example, assume Sequence 6 is a match and attempt the reissue transaction.

In this example, Sequences 2, 3, 4, and 6 were calculated and retained. The one which provides the lowest fare result will be applied.

Page E.03.31.147 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2 (Multiple Category 31 Tables in the Set)

THEN Category 31 Table 988: Bytes 14-20 Bytes 21-22 Byte 206 SeqNumber Process Tag Stop 1 2 X 2 2 BLANK 3 5 BLANK OR Category 31 Table 988: Bytes 14-20 Bytes 21-22 Byte 206 SeqNumber Process Tag Stop 1 2 X 2 2 BLANK 3 3 BLANK

Process Tag Retrieval: For the purpose of this example, assume the first Category 31 table is a match. • Process Tag 2: • For the purpose of this example, assume Sequence 1 is a match and attempt the reissue transaction. Since byte 206 is value X, processing will not process the remainder of the sequences in the first Category 31 table for Process Tag 2. Continue to the next Process Tag. • Process Tag 5: • For the purpose of this example, assume Sequence 3 is a match and attempt the reissue transaction. Continue processing to the second Category 31 table. For the purpose of this example, assume the second Category 31 table is a match. • Process Tag 2: • For the purpose of this example, assume Sequence 1 is a no-match, continue processing to sequence 2100. • For the purpose of this example, assume Sequence 2 is a match and attempt the reissue transaction. Continue to the next Process Tag. • Process Tag 3:

Page E.03.31.148 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

• For the purpose of this example, assume Sequence 3 is a match and attempt the reissue transaction.

In this example, sequences 1 and 3 in the first Category 31 table and sequences 2 and 3 in the second Category 31 table were calculated and retained. The one which provides the lowest fare result will be applied.

Page E.03.31.149 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3 (Single Category 31 Table in the Set)

THEN Category 31 Table 988 Bytes 14-20 Bytes 21-22 Byte 206 SeqNumber Process Tag Stop 1 1 BLANK 2 1 Y 3 1 BLANK 4 2 BLANK 5 5 BLANK

For the purpose of this example, assume the Category 31 table each Table 988 sequence are a match. Create all permutations except as follows: • If any permutation that contains Sequence 2 results in a solution and each fare component in such a permutation contains Process Tag 1 and byte 206 value Y, then discard all permutations in which each fare component does not contain Process Tag 1 and byte 206 value Y. The result from the permutation that produces the lowest cost reprice solution will be applied.

Page E.03.31.150 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 4 (Multiple Category 31 Tables in the Set)

THEN Category 31 Table 988: OR Category 31 Table 988: Bytes 14-20 Bytes 21-22 Byte 206 Bytes 14-20 Bytes 21-22 Byte 206 SeqNumber Process Tag Stop SeqNumber Process Tag Stop 1 1 Y 1 2 X 2 2 X 2 2 BLANK 3 2 BLANK 3 3 BLANK 4 5 BLANK

For the purpose of this example, assume both Category 31 tables and each Table 988 sequence are a match. Create all permutations except as follows: • If any permutation that contains Sequence 1 results in a solution and each fare component in such a permutation contains Process Tag 1 and byte 206 value Y, then discard all permutations in which each fare component does not contain Process Tag 1 and byte 206 value Y. • Otherwise, discard all permutations that contain Sequence 3 from the 1st Category 31 table or Sequence 2 from the 2nd Category 31 table. The result from the permutation that produces the lowest cost reprice solution will be applied.

Page E.03.31.151 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 5 (Multiple Category 31 Tables in the Set)

THEN Category 31 Table 988: OR Category 31 Table 988: Bytes 14-20 Bytes 21-22 Byte 206 Bytes 14-20 Bytes 21-22 Byte 206 SeqNumber Process Tag Stop SeqNumber Process Tag Stop 1 2 BLANK 1 1 Y 2 2 BLANK

For the purpose of this example, assume both Category 31 tables and each Table 988 sequence are a match. Create all permutations except as follows: • If any permutation that contains the second Table 988 Sequence 1 results in a solution and each fare component in such a permutation contains Process Tag 1 and byte 206 value Y, then discard all permutations in which each fare component does not contain Process Tag 1 and byte 206 value Y. The result from the permutation that produces the lowest cost reprice solution will be applied.

Example 6 (Single Category 31 Table in the Set)

THEN Category 31 Table 988 Bytes 14-20 Bytes 21-22 Byte 206 SeqNumber Process Tag Stop 1 1 Y 2 2 BLANK 3 7 BLANK

For the purpose of this example, assume the Category 31 table and each Table 988 sequence are a match. Create all permutations except as follows: • If any permutation that contains Sequence 1 results in a solution and each fare component in such a permutation contains Process Tag 1 and byte 206 value Y, then discard all permutations in which each fare component does not contain Process Tag 1 and byte 206 value Y or in which earch fare component does not contain Process Tag 7. The result from the permutation that produces the lowest cost reprice solution will be applied.

Page E.03.31.152 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.2. Process Tag (bytes 21-22)

Since the Table 988 allows for multiple entries for the same Table ID and Table Number, multiple methods to re-price an itinerary may exist. The method to re-price an itinerary is identified by a Process Tag (Bytes 21-22). There are currently 11 different Process Tag values available, each specifying whether to re-price all fare components on the journey by keeping the fares, using historical fares, using current fares, or canceling and starting over. Additionally, each tag is defined with specific restrictions that must be met when re-pricing. These tags are briefly described in the chart on the following page (detailed explanation is provided later in this section):

Page E.03.31.153 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Process Title Application Tag Before After Keep Keep Historical Current Dept Dept Same Fare Fares Fares Fares Break Pts 01 Keep the Fares YES YES YES YES 02 Guaranteed Air Fare YES YES * YES 03 Keep Fares for Traveled Fare ** YES * Fully trvld Not fully trvld Components FC FC 04 Keep Fares for Unchanged Fare YES YES * Unchanged All FCs after Components FCs up to pt pt of change of change 05 No Guaranteed Fares YES YES * YES 06 Travel Commencement Air Fares YES YES * *** *** 07 Reissue Down to a Lower Fare YES NO YES YES 08 Cancel and Start Over YES YES NOT APPL 09 Historical Fares for Traveled Fare ** YES * Full trvld FC Not fully trvld Components FC 10 Keep for Unchanged Fare Components, YES YES * Unchanged Changed FC Current for any Change FCs 11 Keep the fares up to first changed fare YES YES * Unchanged All FCs after component, historical fares for changed FCs up to pt pt of change of change * Keep fare break points as defined by fare break limitation fields in Table 988 (bytes 43-46 and 48-55). ** If before departure, then use current fares. *** Historical travel commencement date fares if travel has commenced; current fares if travel has not yet commenced.

Page E.03.31.154 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

The Process Tag(s) must be determined and retrieved for all fare components in the itinerary prior to beginning the re-price process. The next step is to determine the method of re-pricing allowed by each of the applicable Process Tags and their definitions. The relationship between the Process Tag Definition and the remainder of the RE-PRICING RULES fields is AND. Processing must meet all RE-PRICING RULES conditions (including the Process Tag Definition) in order to re-price the itinerary. Both the definition of the Process Tag and the data in the other RE-PRICING RULES fields will direct how the itinerary can be re-priced. When the same Process Tag(s) does not apply for all fare components in the itinerary (e.g. Table 988 for each fare component does not specify the same process tag), the determination of how to re-price using different Process Tag permutations is explained later in this section.

Keep the Fares/Historical Fares/Current Fares When the process tag indicates to keep the fares, processing will use the same fare level, fare basis and historical rules that were applicable at the time the original ticket was sold. When the process tag indicates to use historical fares, processing will re-price using fares that were in effect on the date of previous ticket issuance. Effective/Discontinue date validation for fare selection is based on the date of departure from the origin of the new journey (which may or may not be the same as the date of departure from the origin of the previous journey). When the process tag indicates to use current fares, processing will re-price using fares that are in effect on the date of new ticket issuance. Effective/Discontinue date validation for fare selection is based on the date of departure from the origin of the new journey (which may or may not be the same as the date of departure from the origin of the previous journey).

When recalculating using historical or current fares, all applicable fare construction checks apply to the recalculation of the new fare.

When the new itinerary consists of all keep or historical fares, carry forward the original ticket date and the new reissue ticket date to the new ticket. When the new itinerary uses all current fares, carry forward the new reissue date onto the new ticket as the original ticket date. For itineraries that consist of a mixture of historical and current fares carry forward the original ticket date and the new reissue ticket date to the new ticket.

NOTE: In the Process Tag definitions the application of keep, historical or current fares is applied on a journey basis. All other portions of the Process Tag definition are applied on a fare component basis.

Page E.03.31.155 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example

Original Ticket Issue Date = 01Nov 00 Fare Records for NYC-LON existing on 01Nov00 Fare RT Amount Effective Date Discontinue Date YAP 200.00 USD 01AUG 00 99999 YAPNR 250.00 USD 01OCT 00 99999 YEE6M 400.00 USD 01NOV 00 15JAN 01

Original Itinerary: Fare Component Date Fare Class Amount NYC-LON 10Jan 01 YAP 100.00 USD (1/2 of YAP RT amt) LON-NYC 29Jan 01 YAP 100.00 USD (1/2 of YAP RT amt)

Page E.03.31.156 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Passenger requests the following change on 31Dec 00 New Itinerary: Fare Component Date NYC-LON 12Jan 01 CHANGE LON-NYC 29Jan 01

Fare Records for NYC-LON existing on 31Dec00 Fare RT Amount Effective Date Discontinue Date YAP 200.00 USD 01AUG 00 30NOV 00 YAP 300.00 USD 01DEC 01 99999 YAPNR 250.00 USD 01OCT 00 01JAN 01 YAPNR 350.00 USD 02JAN 01 999999 YEE6M 400.00 USD 01NOV 00 15JAN 01

Re-price Keeping the Fares: Apply the previously ticketed fare – YAP 200.00 RT fare

Re-price using Historical Fares: Use fares that existed on date of previous ticket issuance Attempt to re-price using YAP 200.00 RT fare, YAPNR 250.00 RT fare and YEE6M 400.00 RT fare

Re-price using Current Fares: Use fares that exist on date of new ticket issuance (31Dec00) – apply YAP 300.00 RT fare. YAPNR 250.00 RT was rejected due to its discontinue date falls before the new travel dates

Page E.03.31.157 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Ticketing Dates

Validation of Category 15 – Sale Dates ‘Earliest/Latest Ticketing Dates’ (bytes 21-27/35-41) is as follows:

• For any fare component that is directed to use historical fares during a re-price, processing will use the original ticket date to validate Category 15 – Sales Dates ‘Earliest/Latest Ticketing Dates’ (bytes 21-27/35-41) requirements.

• For any fare component that is directed to use current fares during a re-price, processing will use the date of the reissue to validate Category 15 – Sales Dates ‘Earliest/Latest Ticketing dates’ (bytes 21-27/35-41) requirements.

• For any fare component that is directed to use historical travel commencement fares during a re-price, processing will use the date of travel commencement of the journey to validate Category 15 – Sales Dates ‘Earliest/Latest Ticketing dates’ (bytes 21- 27/35-41) requirements.

Processing must save ticketing dates according to whether a Process Tag directs fares on the new ticket to be Keep, Historical or Current. The ticketing dates are necessary so that systems subsequently re-pricing another new itinerary will be able to determine where the original fare and fare rules were located within a database. Without the ticketing dates, processing may not be able to determine this information. Until an industry standard ticket record is created to facilitate this needed functionality, systems will need to determine in a proprietary fashion how they will save the dates to carry forward onto the new ticket.

Page E.03.31.158 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Ideally processing could save a record of the ticket issue/reissue date used for every fare on a ticket and carry forward this data with every subsequent reissue. Ticketing dates are required to be saved as follows:

1. If the new ticket was created using only current fares – processing needs to save the reissue date for usage in future re-price 2. If the new ticket was created using only historical/keep fares – processing needs to save the original ticketing date for usage in future re-price 3. If the new ticket was created with Tag 6 generated fares utilizing Historical Travel Commence fares – processing needs to save the travel commencement date for this fare on the ticket being issued/reissued for usage in future re-price. 4. If the ticket was created with a mixture of current and historical fares – there is no agreed upon method of carrying forward the reissue dates. It is suggested that for itineraries that consist of a mixture of historical/keep and current fares -- processing needs to save the original ticketing date for the historical/keep fares and the new reissue ticket date for the current fares to the new ticket. NOTE: There is a risk in using a mixture of current and historical fares on the ticket. It is difficult for processing to reconcile two different ticketing dates and ascertain exactly which date applies to which fares on a ticket. This can become difficult when portions of the itinerary are re-priced as historical/keep fares and others as current fares. As the ticket is subsequently reissued it is possible that the historical/keep fares ticketing date will be ignored and the new reissue date, the date the current fares were available, will be carried forward instead. In this situation it is possible that systems may not be able to find the proper fare rule records for the historical/keep portion of the itinerary as processing will only be using the reissued ticket date. Therefore it is recommend that both the reissue and original ticketing dates be saved for usage in future re-price for any itinerary that contains a mixture of historical/keep and current type fares.

Page E.03.31.159 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Before/After Departure Application When a process tag is identified as only applying before or after departure, the journey, pricing unit, or fare component application of this restriction is based on the values in the associated Category 31 Record 3 bytes 26-28 (Journey/Pricing Unit/Fare Component). If data is present in byte 26 and bytes 27-28 are blank, then the process tag before/after departure application is based on the journey. If data is present in byte 27, byte 26 coded or blank, and byte 28 is blank, then the process tag before/after departure application is based on the pricing unit. If data is present in byte 28, byte 26 is coded or blank, and byte 27 is coded or blank, then the process tag before/after departure application is based on the fare component. When bytes 26-28 are blank, then the process tag before/after departure application is based on the journey.

Page E.03.31.160 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Process Tag 01 - Keep the Fares

Re-price the itinerary using the same fares as previously ticketed. Processing must apply to the following requirements: • Applies before or after departure. • Re-price using fares from the historical database as directed by the Expand Keep field (Table 988 byte 112) and the Seasonality/Day of Week Indicator Table 966 (Table 988 bytes 138-145) • Re-price the itinerary as directed by the Travel Limitation fields (Table 988 bytes 23-40) • Re-price the itinerary as directed by the Fare Break Limitation fields (Table 988 bytes 43-46 and 48-55) • The number of fare components on the new itinerary must be equal to or greater than the number of fare components on the previous itinerary.

Note: An edit requires that Term (Table 988 byte 43) must be value Blank when Process Tag (Table 988 bytes 21-22) is value 01 and Expand Keep (Table 988 byte 112) is value Blank.

Example 1

A ------B ------C ------A (Circle Trip Itinerary - with A, B, C as fare break points) Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Process Tag Portion Term 01 F BLANK The data indicates that when there are no changes to the first flight coupon of the ticket, then re-price using Process Tag 01. Changes to fare break points are not permitted on the fare component. • For the purpose of this example, assume changes are not made to the first flight coupon (A-B). Processing will match the Table 988 sequence. • Apply the Process Tag and Revalidation provisions regardless of whether the change is being made before or after departure from journey origin. • Cannot change any portion of the A-B fare component (change means flights, dates, time, carrier, RBD, travel locations). • Cannot create any new fare break points or eliminate any fare break points (cannot assess as A-B and then B-A charging a through fare over point C).

Page E.03.31.161 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

• Using fare and rule provisions from the previous ticket for all fare components, revalidate all provisions against the new itinerary (unless otherwise specified in bytes 90-110, 121).

Example 2

ORIGINAL ITINERARY NEW – DESIRED ITINERARY Fare Date Fare Fare Change Fee Amt Fare Date Fare Previous Ticketed Fare Component Class Amt Component Class SAN-MSP 08JUL98 QE14NR $100 $50 Highest in PU SAN-MSP 08JUL98 QE14NR $100 MSP-SAN 14JUL98 ME14NR $200 $75 Highest in PU MSP-SAN 25JUL98 ME14NR $200

Scenario: • 1st fare component is QE14NR ($100 value); 2nd fare component is ME14NR ($200 value). • No change to travel on the first fare component (SAN to MSP). • Date of travel has changed on the second fare component (MSP to SAN). Passenger requests to return on 25Jul. • No change to fare break points. • For the purpose of this example, assume that travel is kept as directed in the travel limitation fields. • For the purpose of this example, assume that the previous rule provisions are revalidated as directed by bytes 90-110, 121.

Calculation: Previous ticketed value ($100 + $200) = $300 - Value of desired itinerary ($100 + $200) = $300 - Change fee $75 > $50 $75 Amount of Additional Collection ($75)

Explanation: • For the purpose of this example, the new itinerary meets all of the previously ticketed Cat 31 rule provisions. The change is allowed using the same fares as previously ticketed. Same fare calculation occurred equaling $300. • The $75 change fee is applied because it is the highest change fee on the pricing unit.

Page E.03.31.162 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

• Re-pricing Result: Allow the change and add-collect $75. ($0 difference in fares + $75 change fee).

Page E.03.31.163 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Process Tag 02 - Guaranteed Air Fare

Re-price the itinerary using historical fares. Processing must apply to the following requirements: • Applies before or after departure. • Process the fare component or fare break points as further defined by fare break limitation fields (bytes 43-46 and 48-55). • Re-price the itinerary as directed by the travel limitation fields (bytes 23-40). • Re-price using fares that existed on the date of previous ticket issuance (historical fares).

Example 1

A-----B-----C-----D------A (Circle Trip Itinerary with A, C, D as fare break points; B is a stopover point)

Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Byte 44 Process Tag Portion Term 1st Fare Break 02 BLANK Y Blank The data indicates to re-price using Process Tag 02. Changes to fare break points are permitted on the fare component. • Processing will match the Table 988 sequence. • Apply the Process Tag and Revalidation provisions regardless of whether the change is being made before or after departure from journey origin. • Using fare and rule provisions in existence on the date of previous ticket issuance (historical fares) for all fare components, revalidate all provisions against the new itinerary.

Page E.03.31.164 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2

A-----B-----C-----D------A (Circle Trip Itinerary with A, C, D as fare break points; B is a stopover point)

Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Byte 44 Process Tag Portion Term 1st Fare Break 02 F Y Y The data indicates that when there are no changes to the first flight coupon of the ticket, then re-price using Process Tag 02. Changes to fare break points are permitted on the fare component. Changes not permitted to the previously ticketed fare for the first fare component. • For the purpose of this example, assume changes are not made to the first flight coupon (A-B). Processing will match the Table 988 sequence. • Apply the Process Tag and Revalidation provisions regardless of whether the change is being made before or after departure from journey origin. • The previously ticketed fare for the A-C fare component cannot change (per value Y in byte 44). • Using fare and rule provisions in existence on the date of previous ticket issuance (historical fares) for the other fare components, revalidate all provisions against the new itinerary. Replace any or all fare components (with the exception of the A-C fare component).

Page E.03.31.165 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3

A-----B-----C-----D------A (Circle Trip Itinerary with A, C, D as fare break points; B is a stopover point)

Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Byte 44 Process Tag Portion Term 1st Fare Break 02 F BLANK Y The data indicates that when there are no changes to the first flight coupon of the ticket, then re-price using Process Tag 02. Changes to fare break points are not permitted on the fare component. Changes not permitted to the previously ticketed fare for the first fare component. • For the purpose of this example, assume changes are not made to the first flight coupon (A-B). Processing will match the Table 988 sequence. • Apply the Process Tag and Revalidation provisions regardless of whether the change is being made before or after departure from journey origin. • Fare break points A, C, and D cannot be changed (per value Blank in byte 43); therefore, the itinerary cannot be re-priced by including any new or removing any existing fare break points. • The previously ticketed fare for the A-C fare component cannot change (per value Y in byte 44) • Using fare and rule provisions in existence on the date of previous ticket issuance (historical fares) for the C-D and D-A fare, revalidate all provisions against the new itinerary. Replace any or all fare components (with the exception of the A-C fare component). NOTE: The Same Point Table (bytes 48-55) must be considered when determining whether the Origination/Destination (terminal points) of the fare component have changed.

Page E.03.31.166 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 4

ORIGINAL ITINERARY NEW – DESIRED ITINERARY Fare Date Fare Fare Change Fee Fare Date Fare Historical Fare Component Class Component Class SAN-MSP 08JUL98 B7NR $250 $50 Highest in PU SAN-MSP 08JUL98 B7NR $250 MSP-SAN 14JUL98 ME14NR $200 $75 Highest in PU MSP-SAN 11JUL98 B7NR $250

Scenario: • 1st fare component is B7NR ($250 value); 2nd fare component is ME14NR ($200 value). • Date of travel has changed on the second fare component (MSP to SAN). No change to fare break points. • For the purpose of this example, assume that travel is kept as directed in the travel and fare break limitation fields. • For the purpose of this example, assume that second fare component does not meet the previously ticketed rule provisions. • Entire itinerary is now re-priced using historical fares. (This includes the ability to use previously ticketed fares.)

Calculation: Previous ticketed value ($250 + $200) = $450 - Value of desired itinerary ($250 + $250) = $500 - Change fee $75 > $50 $75 Amount of Additional Collection ($125)

Explanation: • Since the new itinerary did not meet the previously ticketed rule provisions, the itinerary was re-priced using historical fares. • The fare and rule that applied resulted in a B7NR equal to $500 (RT). (The new itinerary met all of the rule provisions of the B7NR.) • The $75 change fee was applied because it was the highest change fee on the pricing unit. • Re-pricing Result: allow the change and add-collect $125 (+$50 difference in fare + $75 change fee).

Page E.03.31.167 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Process Tag 03 – Keep Fares for Traveled Fare Components

Re-price the itinerary using the same fares as previously ticketed for traveled fare components and current fares for un- traveled fare components. Processing must apply to the following requirements: • Applies after departure (see note below regarding before departure). • For fare components that are instructed to Keep the fares, bytes 43-46 and 48-55 have no application except as specified below. For all other fare components process the fare component or fare break points as further defined by fare break limitation fields (bytes 43-46 and 48-55). • Re-price the itinerary as directed by the travel limitation fields (bytes 23-40). • Keep the previously ticketed fare for any fare component that has been fully traveled. Changes not permitted to fare break points for fully traveled fare components. • Use current fares and rules for any fare component that has not been fully traveled. Changes permitted to fare beak points. NOTE: If change is requested before departure, then all fare components are re-priced using current fares.

Page E.03.31.168 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1

A ---- B ----- C ----D ----- A (Circle Trip Itinerary with A, B, D fare break points; C is a connection point.)

Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Process Tag Portion Term 03 BLANK Y The data indicates to re-price using Process Tag 03. Changes to fare break points are permitted on the fare component.

The passenger has traveled up to point C and wishes to reroute. • Processing will match the Table 988 sequence. • Change is made after departure from journey origin; apply the Process Tag and Revalidation provisions. • A-B fare component has been fully traveled; therefore, the previously ticketed fare for the A-B fare component cannot change. • Using current fare and rule provisions in existence on date of new ticket issuance for the other fare components revalidate all provisions against the new itinerary. Replace any or all fare components (with the exception of the A-B fare component).

Page E.03.31.169 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2

A ---- B ----- C ----D ----- A (Circle Trip Itinerary with A, B, D fare break points; C is a connection point.)

Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Process Tag Portion Term 03 BLANK BLANK The data indicates to re-price using Process Tag 03. Changes to fare break points are not permitted on the fare component.

The passenger has traveled up to point C and wishes to reroute. • Processing will match the Table 988 sequence. • Change is made after departure from journey origin; apply the Process Tag and Revalidation provisions. • Fare break points A, B, and D cannot be changed (per value Blank in byte 43); therefore, the itinerary cannot be re-priced by including any new or removing any existing fare break points. • Fare break points A, B, and D cannot be changed (per value Blank in byte 43); therefore, the itinerary cannot be re-priced by including any new or removing any existing fare break points. • A-B fare component has been fully traveled; therefore, the previously ticketed fare for the A-B fare component cannot change. • Using current fare and rule provisions in existence on date of new ticket issuance for the B-D and D-A fare components revalidate all provisions against the new itinerary. NOTE: The Same Point Table (bytes 48-55) must be considered when determining whether the Origination/Destination (terminal points) of the fare component have changed.

Page E.03.31.170 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3

ORIGINAL ITINERARY NEW – DESIRED ITINERARY Fare Date Fare Fare Change Fee Fare Date Fare Fare Component Class Component Class MSP-PIT 08JUL98 KE14NR $120 $50 Highest in PU MSP-PIT 08JUL98 KE14NR $120 (previous tktd fare) PIT-MSP 14JUL98 HE14NR $200 $75 Highest in PU PIT-MSP 09JUL98 Y $700 (current fare)

Scenario: • 1st fare component is KE14NR ($120 value); 2nd fare component is HE14NR ($200 value). • Today is 09Jul. The first fare component has been traveled. Return travel now desired on 09Jul. • For the purpose of this example, assume that travel is kept as directed in the travel and fare break limitation fields. • For the purpose of this example, assume that second fare component does not meet the previously ticketed rule provisions. • Itinerary is re-priced using the previously ticketed fare for the first fare component (KE14NR, $120, traveled), and using current fare and rule information for the second fare component (not traveled).

Calculation: Previous ticketed value ($120 + $200) = $320 - Value of desired itinerary ($120 + $700) = $820 - Change fee $75 > $50 $75 Amount of Additional Collection ($575)

Explanation: • The first fare component was priced keeping the previously ticketed fare because it was already traveled. • The second fare component did not meet the rule provisions in the previously ticketed Category 31. • The second fare component was priced using current fares and rule information. • The fare and rule that applied resulted in a Y fare equal to $700 for the second fare component. • The $75 change fee was applied because it was the highest change fee on the pricing unit. • Re-pricing Result: Allow the change and add-collect $575 (+$500 difference in fare + $75 change fee).

Page E.03.31.171 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Process Tag 04 – Keep Fares for Unchanged Fare Components

Re-price the itinerary using the same fares as previously ticketed up to the first changed fare component and current fares for all subsequent fare components. Processing must apply to the following requirements: • Applies before or after departure. • For fare components that are instructed to Keep the fares, bytes 43-46 and 48-55 have no application. For all other fare components process the fare component or fare break points as further defined by fare break limitation fields (bytes 43-46 and 48- 55). • Re-price the itinerary as directed by the travel limitation fields (bytes 23-40). • Keep the previously ticketed fares and rules for all unchanged fare components up to the point of the change. (Note that determination of “up to the point” is based on sequence of travel.) • Use current fares and rules for all other fare components.

Page E.03.31.172 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1

A ---- B ----- C ----D ----- A (Circle Trip Itinerary with A, B, D fare break points; C is a connection point.)

Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Process Tag Portion Term 04 BLANK Y The data indicates to re-price using Process Tag 04. Changes to fare break points are permitted on the fare component.

The passenger wishes to change from point C. • Processing will match the Table 988 sequence. • Apply the Process Tag and Revalidation provisions regardless of whether the change is being made before or after departure from journey origin. • Cannot change the previously ticketed fare for fare components up to the point of change (C); therefore, previously ticketed fare for the A-B fare component cannot change. • Using current fare and rule provisions in existence on date of new ticket issuance for the other fare components revalidate all provisions against the new itinerary. Replace any or all fare components (with the exception of the A-B fare component).

Page E.03.31.173 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2

A ---- B ----- C ----D ----- A (Circle Trip Itinerary with A, B, D fare break points; C is a connection point.)

Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Process Tag Portion Term 04 BLANK BLANK The data indicates to re-price using Process Tag 04. Changes to fare break points are not permitted on the fare component.

The passenger wishes to change from point C. • Processing will match the Table 988 sequence. • Apply the Process Tag and Revalidation provisions regardless of whether the change is being made before or after departure from journey origin. • Fare break points A, B, and D cannot be changed (per value Blank in byte 43); therefore, the itinerary cannot be re-priced by including any new or removing any existing fare break points. • Cannot change the previously ticketed fare for fare components up to the point of change (C); therefore, previously ticketed fare for the A-B fare component cannot change. • Using current fare and rule provisions in existence on date of new ticket issuance for the B-D and D-A fare components revalidate all provisions against the new itinerary. Replace any or all fare components (with the exception of the A-B fare component). NOTE: The Same Point Table (bytes 48-55) must be considered when determining whether the Origination/Destination (terminal points) of the fare component have changed.

Page E.03.31.174 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3

ORIGINAL ITINERARY NEW – DESIRED ITINERARY Fare Date Fare Fare Change Fee Fare Date Fare Fare Component Class Component Class MSP-PIT 08JUL98 KE14NR $100 $50 Highest in PU MSP-PIT 08JUL98 KE14NR $100 (previous tktd fare) PIT-MSP 14JUL98 HE14NR $200 $75 Highest in PU PIT-MSP 20SEP98 HSPSCL $150 (current fare)

Scenario: • 1st fare component is KE14NR ($100 value); 2nd fare component is HE14NR ($200 value). • The first fare component is not being changed. • The second fare component is being changed. Return travel now desired on September 20th. • For the purpose of this example, assume that travel is kept as directed in the travel and fare break limitation fields. • For the purpose of this example, assume that second fare component does not meet the previously ticketed rule provisions. • Itinerary is re-priced using the previously ticketed fare for the first fare component (KE14NR, $100, unchanged), and using current fare and rule information for the second fare component (HSPSCL, $150, changed).

Calculation: Previous ticketed value ($100 + $200) = $300 - Value of desired itinerary ($100 + $150) = $250 - Change fee $75 > $50 $75 Amount of Additional Collection ($25)

Explanation: • The first fare component was priced keeping the previously ticketed fare because it was unchanged. • The second fare component was priced using current fares and rule information. • New fare in the market for which the passenger qualified is HSPCL equal to $150 for the second fare component. • The $75 change fee was applied because it was the highest change fee on the pricing unit. • Re-pricing Result: Allow the change and add-collect $25 (-$50 difference in fares + $75 change fee).

Page E.03.31.175 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Process Tag 05 - No Guaranteed Fares

Re-price the itinerary using current fares. Processing must apply to the following requirements: • Applies before or after departure. • Process the fare component or fare break points as further defined by fare break limitation fields (bytes 43-46 and 48-55). • Re-price the itinerary as directed by the travel limitation fields (bytes 23-40). • Using current level fares and rules for all fare components.

Example 1

A ---- B ----- C ----D ----- A (Circle Trip Itinerary with A, B, D fare break points; C is a connection point.)

Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Process Tag Portion Term 05 BLANK Y The data indicates to re-price using Process Tag 05. Changes to fare break points are permitted on the fare component.

The passenger wishes to change from point C. • Processing will match the Table 988 sequence. • Apply the Process Tag and Revalidation provisions regardless of whether the change is being made before or after departure from journey origin. • Using current fare and rule provisions in existence on date of new ticket issuance for all fare components revalidate all provisions against the new itinerary. Replace any or all fare components.

Page E.03.31.176 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2

A ---- B ----- C ----D ----- A (Circle Trip Itinerary with A, B, D fare break points; C is a connection point.)

Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Process Tag Portion Term 05 BLANK BLANK The data indicates to re-price using Process Tag 05. Changes to fare break points are not permitted on the fare component.

The passenger wishes to change from point C. • Processing will match the Table 988 sequence. • Apply the Process Tag and Revalidation provisions regardless of whether the change is being made before or after departure from journey origin. • Fare break points A, B, and D cannot be changed (per value Blank in byte 43); therefore, the itinerary cannot be re-priced by including any new or removing any existing fare break points. • Using current fare and rule provisions in existence on date of new ticket issuance for the A-B, B-D, and D-A fare components, revalidate all provisions against the new itinerary. Replace any or all fare components. NOTE: The Same Point Table (bytes 48-55) must be considered when determining whether the Origination/Destination (terminal points) of the fare component have changed.

Page E.03.31.177 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3

ORIGINAL ITINERARY NEW – DESIRED ITINERARY Fare Date Fare Fare Change Fee Fare Date Fare Current Fare Component Class Component Class LAS-PIT 10AUG98 BE14NR $350 $50 Highest in PU LAS-PIT 22JUL98 ME7NR $540 PIT-LAS 17AUG98 VE21NR $250 $75 Highest in PU PIT-LAS 29JUL98 ME7NR $540

Scenario: • 1st fare component is BE14NR ($350 value); 2nd fare component is VE21NR ($250 value). • Entire itinerary is being changed. Travel departs 22Jul and returns 29Jul. • Itinerary is re-priced using current fares and rules. • New itinerary is re-priced using ME7NR $1080 RT ($540 + $540)

Calculation: Previous ticketed value ($350 + $250) = $600 -Value of desired itinerary ($540 + $540) = $1080 -Change fee $75 > $50 $75 Amount refunded or Additional Collection ($555)

Explanation: • The entire itinerary was re-priced using current fare and rule information. • This resulted in a new ME7NR fare of $1080 RT. • The $75 change fee was applied because it was the highest change fee on the pricing unit. • Re-pricing Result: Allow the change and add-collect $555 (+$480 difference in fare + $75 change fee).

Page E.03.31.178 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Process Tag 06 – Travel Commencement Air Fares

Re-price the itinerary using historical or current fares. Processing must apply to the following requirements: Applies anytime. • Process the fare component or fare break points as further defined by fare break limitation fields (bytes 43-46 and 48-55). • Re-price the itinerary as directed by the travel limitation fields (bytes 23-40). • For reissue prior to commencement of travel, re-price using fares that are valid for ticketing at the time of reissue and valid for travel for new ticket travel commencement date (current fares) • For reissue after commencement of travel, re-price using fares that existed for ticketing on original travel commencement date (historical travel commencement fares). Historical travel commencement fares are fares available for sale on the original travel commencement date on the ticket. NOTE: The commencement of travel date refers to the actual date the passenger started travel, not the scheduled travel commencement date on the ticket.

For example – if today is 12Aug, and revised travel commences 01Sep – then look for fares available for sale 12Aug, effective for travel 01Sep. If today is 01Oct, and new travel commenced 01Sep (passenger commenced travel on this day) – then look for fares available for sale and travel on 01Sep.

Page E.03.31.179 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1

Original Itinerary: NYC-LON RT Ticket Issue Date = 01Oct 04

Travel commencement Date = 15Oct04 15Oct04 departure 01Nov04 departure NYC LON

New Itinerary requested on 02Oct 04: Travel dates remain the same.

15Oct04 departure 01Nov04 departure NYC PAR

Assume all fare components match the following Table 988 data: Bytes 21-22 Byte 24 Byte 43 Process Tag Portion Term 06 BLANK Y The data indicates to re-price using Process Tag 06. Changes to fare break points are permitted on the fare component.

The passenger wishes to change LON to PAR • Processing will match the Table 988 sequence. • Apply the Process Tag and Revalidation provisions • Since the reissue is taking place before travel commencement, current fares will be used. • Current fares valid for sale and ticketing on 02Oct04 and valid for travel 15Oct04 will be used for the PAR-NYC fare component.

Page E.03.31.180 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2

Original Itinerary: NYC-LON RT Ticket Issue Date = 01Oct 04 Travel commencement Date = 15Oct04

15Oct04 departure 01Nov04 departure NYC LON

New Itinerary requested on 20Oct 04: Passenger requests a new travel date and destination of WAS

15Oct04 departure 02Nov04 departure NYC LON WAS

Assume all fare components match the following Table 988 data: Bytes 21-22 Byte 24 Byte 43 Process Tag Portion Term 06 BLANK Y The data indicates to re-price using Process Tag 06. Changes to fare break points are permitted on the fare component.

The passenger wishes to change LON-NYC to LON-WAS and leave a day later. • Processing will match the Table 988 sequence. • Apply the Process Tag and Revalidation provisions • Process Tag 6 dictates to use travel commence fares. Since the reissue is taking place after travel commencement, historical fares will be used. • Historical fares valid for ticketing and travel on 15Oct04 will be used for the NYC- LON-WAS fare components.

Page E.03.31.181 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Process Tag 07 - Reissue Down to a Lower Fare

Re-price the itinerary using current fares. Processing must apply to the following requirements: • Applies before departure • Use current fares and rules for all fare components • Booking class may change; however no other flight information changes permitted (e.g. no changes permitted to flights, ticketed points, intermediate points, carrier, times, or dates). • Permutations of Process tags on ticket presented for reissue must consist entirely of Process Tag 7’s to be valid. For all other permutations auto reissuing is not permitted. Transaction will have to be manually processed. • Processing must apply data in Table 988 byte 207 when processing a Tag 7 sequence. NOTE: 1st Break byte 44 should be value Blank and Fully Flown byte 46 and Fare Amount byte 86 should be value Blank. If any other value than blank is present in these fields processing should disregard these values and assume value Blank. Term byte 43 may be value Y but changes to the ticketed points are still NOT permitted. Fare break points may change as long as no changes to flight information are made.

Page E.03.31.182 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1:

Scenario: Passenger bought a 3 component circle trip on 01JAN.

ORIGINAL Itinerary

Fare Date Fare Class Fare RBD Flight No. Change Fee Process Table 988 Component Amount Tags Byte 155 LON- NYC 01FEB YE14NR $400 Y 100 $100 - Highest in jrny 1,5,7 R NYC-LAX 02FEB YE7NR $400 Y 200 $75 – Highest in jrny 1,5,7 F LAX-LON 10FEB YE7NR $800 Y 300 $100 – highest in jrny 1,5,7 Blank

On 15JAN a LON-LAX RT is advertised for $1000. Passenger requests the following change. New itinerary is a two-component RT.

NEW – Desired Itinerary Fare Date Fare Fare Amount Flight RBD Component Class No. LON- NYC 01FEB ME14NR 250.00 (1/2 RT) 100 M NYC-LON 01FEB ME7NR 250.00 200 M LAX-LON 10FEB ME7NR 500.00 (1/2 RT) 300 M

Byte 207 values (see Section 4.5.2.1 for a full description of byte 207): • R = At least one new fare component must be either a new fare that was not in effect at the time of the previous ticket issuance and/or a revised rule provision since the time of the previous ticket issuance • F = At least one new fare component must be a new fare that was not in effect at the time of the previous ticket issuance • Blank – this byte has no application

Page E.03.31.183 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Explanation: ⇒ All fare components had a Tag 7 in their Cat 31 ⇒ Change was before departure ⇒ No changes were made to flight information ⇒ New itinerary contained a new fare – all Table 988 byte 207 values validated ⇒ Desired fare was current.

Calculation: Previous ticketed value ($400 + $400 + $1600 $800) = - Value of desired itinerary ($250 + $250 + $1000 $500) = - Change fee $50 = $50 = $50 $100 Amount of Refund $500

Result: • The entire itinerary was re-priced using current fare and rule information, resulting in a new fare of $1000 RT. • The $100 change fee was applied because it was the highest change fee in the journey. • Refund $500 as directed in Category 31 byte 113. Byte 113 will direct the form of refund (MCO/scrip/voucher/original FOP).

Page E.03.31.184 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2:

Itinerary: 3 component circle.

Each fare component resolved to a Table 988 that contained the following Process Tags: Fare Component Process Tags NYC-LON 1,7 LON-PAR 2,7 PAR-NYC 5,7

Result: The following Process Tag permutations are possible:

1) 1, 2, 5 2) 1, 2, 7 3) 7, 2, 5 4) 7, 2, 7 5) 7, 7, 5 6) 7, 7, 7

Only Permutation #6: 7, 7, 7 is valid for Process Tag 7 – Reissue to a Lower Fare. If. Process Tag 7 is to be used all Process Tag’s in the permutation must be Tag 7. Otherwise the transaction must be manually reissued in order to Reissue to a Lower fare.

Page E.03.31.185 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Process Tag 08- Cancel and Start Over

Processing must apply to the following requirements: • Applies before or after departure. • Cancel the space held, cancel the fare, and start over. • Apply any applicable cancellation fee. • Re-price the entire itinerary from the point of origin of the journey using current level fares and rules. Once a match is made to Category 31 and Table 988, when process Tag 08 is set, then processing will not validate any other data in the category except the amount field in Category 31 for the cancellation penalty amount. NOTE: Once Category 33 – Voluntary Cancellations is developed, then this process tag indicates to process Category 33. Determine the Category 33 fee for each fare component and apply any residual value toward the purchase of new fares.

Example

ORIGINAL ITINERARY NEW – DESIRED ITINERARY Fare Date Fare Fare Change Fee Fare Date Fare Current Fare Component Class Component Class PIT-PHL 10AUG98 B $100 50% Highest in FC PHL-PIT 17AUG98 Y $300 No Change Fee PHL-LAS 21AUG98 Y $900

Scenario: • It is now 15Aug and the first fare component is already traveled (first fare component was a one-way fare). • Second fare component is being changed with a different destination and date. • The PHL-LAS is treated as a new itinerary. • New itinerary is re-priced using current fares and rules: Y fare $900.

Page E.03.31.186 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Calculation: Previous ticketed value ($100 + $300) = $400 - Value of portion used $100 $100 - Change fee ($100 * 50%) $50 - Value of new ticket $900 Amount of Additional Collection $650

New Itinerary Calculation: $900 - $250 = $650

Explanation: • The new itinerary was re-priced using current fare and rule information. • This resulted in a new fare of $900 OW. • The 50% change fee applied to the first fare component. There was no change fee on the second fare component. • The $250 refund from the cancellation was applied towards the purchase of the new ticket. • Re-pricing Result: Allow the change. Treat as a cancellation and purchase new ticket. Collect $650.

Page E.03.31.187 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Process Tag 09 – Historical Fares for Traveled Fare Components

Re-price the itinerary using historical fares for traveled fare components and current fares for un-traveled components. Processing must apply to the following requirements: • Applies after departure (see note below regarding before departure). • Process the fare component or fare break points as further defined by fare break limitation fields (bytes 43-46 and 48-55) and as specified below. • Re-price the itinerary as directed by the travel limitation fields (bytes 23-40). • Use historical fares and rules for any fare component that has been fully traveled. Changes not permitted to fare break points for fully traveled fare components. Processing establishes which fare components are fully traveled by evaluating the previous ticket. • Use current fares and rules for any fare component that has not been fully traveled. Changes permitted to fare beak points. NOTE: If change is requested before departure, then all fare components are re-priced using current fares.

Example 1

A ---- B ----- C ----D ----- A (Circle Trip Itinerary with A, B, D fare break points; C is a connection point.)

Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Process Tag Portion Term 09 BLANK Y The data indicates to re-price using Process Tag 09. Changes to fare break points are permitted on the fare component.

The passenger has traveled up to point C and wishes to reroute. • Processing will match the Table 988 sequence. • Change is made after departure from journey origin; apply the Process Tag and Revalidation provisions. • A-B fare component has been fully traveled; therefore, re-calculate the fare component using historical fare and rule provisions in existence on the date of previous ticket issuance. Changes not permitted to fare break points A and B. • Using current fare and rule provisions in existence on date of new ticket issuance for the other fare components revalidate all provisions against the new itinerary. Replace any or all fare components.

Page E.03.31.188 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2

A ---- B ----- C ----D ----- A (Circle Trip Itinerary with A, B, D fare break points; C is a connection point.)

Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Process Tag Portion Term 09 BLANK BLANK The data indicates to re-price using Process Tag 09. Changes to fare break points are not permitted on the fare component.

The passenger has traveled up to point C and wishes to reroute. • Processing will match the Table 988 sequence. • Change is made after departure from journey origin; apply the Process Tag and Revalidation provisions. • Fare break points A, B, and D cannot be changed (per value Blank in byte 43); therefore, the itinerary cannot be re-priced by including any new or removing any existing fare break points. • A-B fare component has been fully traveled; therefore, re-calculate the fare component using historical fare and rule provisions in existence on the date of previous ticket issuance. Changes not permitted to fare break points A and B. • Using current fare and rule provisions in existence on date of new ticket issuance for the B-D and D-A fare components, revalidate all provisions against the new itinerary. Replace any or all fare components. NOTE: The Same Point Table (bytes 48-55) must be considered when determining whether the Origination/Destination (terminal points) of the fare component have changed.

Page E.03.31.189 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3

ORIGINAL ITINERARY NEW – DESIRED ITINERARY Fare Date Fare Fare Change Fee Fare Date Fare Current Fare Component Class Component Class NYC-LON: BL7 $545 $150 Highest in PU Sectors: NYC-BOS 10AUG98 10AUG98 Y $600 BOS-LON 10AUG98 12AUG98 Y $1200 LON-NYC 17AUG98 BL7 $545 $150 Highest in PU LON-WAS 21AUG98 Y $1500

Scenario: • 1st fare component (NYC-LON) is BL7 ($545 value); 2nd fare component (LON-NYC) is BL7 ($545 value). • 1st segment of the 1st fare component is traveled. 2nd segment of the 1st fare component and the 2nd fare component are being changed (a voluntary rerouting). • For the purpose of this example, assume that travel is kept as directed in the travel and fare break limitation fields. • For the purpose of this example, assume that the fare used on the LON-WAS (selected as WAS-LON) fare component is applicable to the new itinerary. • New itinerary is re-priced using Y fares; NYC-BOS - $600, BOS-LON - $1200, and LON-WAS - $1500. Calculation: Previous ticketed value ($545 + $545) = $1090 - Value of desired itinerary ($600 + $1200 + $1500) = $3300 - Change fee $150 $150 Amount of Additional Collection ($2360)

Explanation: • The first fare component is re-priced using current fares since partially traveled. • The second fare component is re-priced using current fares since the fare component is un-flown. • Re-pricing Result: Allow the change and add-collect $2360 (+$2210 difference in fare + $150 change fee).

Page E.03.31.190 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Process Tag 10 – Keep Fares for Unchanged Fare Components, Current for any Changed

Re-price the itinerary using the same fares and rules as previously ticketed for unchanged fare components and current fares for all changed fare components. Processing must apply to the following requirements: • Applies before or after departure. • For fare components that are instructed to Keep the fares, bytes 43-46 and 48-55 have no application except as specified below. For all other fare components process the fare component or fare break points as further defined by fare break limitation fields (bytes 43-46 and 48-55). • Re-price the itinerary as directed by the travel limitation fields (bytes 23-40). • Re-price all unchanged fare components using the same fares and rules as previously ticketed (Keep fares). • For any fare component that contains a portion that has changed flight information (fare breaks may change), re-price using current level fares and rules.

Example 1

A ---- B ----- C ----D ----- A (Circle Trip Itinerary with A, B, D fare break points; C is a connection point.)

Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Process Tag Portion Term 10 BLANK Y The data indicates to re-price using Process Tag 10. Changes to fare break points are permitted on the fare component.

The passenger wishes to make a change to the D-A fare component. • Processing will match the Table 988 sequence. • Apply the Process Tag and Revalidation provisions regardless of whether the change is being made before or after departure from journey origin. • Using the same fares and rules as previously ticketed (Keep fares) for the A-B and B-D fare components, revalidate all provisions against the new itinerary. Replace any or all fare components.

Page E.03.31.191 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

• Using current fare and rule provisions in existence on date of new ticket issuance for the D-A fare component, revalidate all provisions against the new itinerary. Replace any or all fare components.

Example 2

A ---- B ----- C ----D ----- A (Circle Trip Itinerary with A, B, D fare break points; C is a connection point.)

Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Process Tag Portion Term 10 BLANK BLANK The data indicates to re-price using Process Tag 10. Changes to fare break points are not permitted on the fare component.

The passenger wishes to make a change to the B-D fare component. • Processing will match the Table 988 sequence. • Apply the Process Tag and Revalidation provisions regardless of whether the change is being made before or after departure from journey origin. • Fare break points A, B, and D cannot be changed (per value Blank in byte 43); therefore, the itinerary cannot be re-priced by including any new or removing any existing fare break points. • Using the same fares and rules as previously ticketed (Keep fares) for the A-B and D-A fare components revalidate all provisions against the new itinerary. Replace any or all fare components. • Using current fare and rule provisions in existence on date of new ticket issuance for the B-D fare component revalidate all provisions against the new itinerary. Replace any or all fare components. NOTE: The Same Point Table (bytes 48-55) must be considered when determining whether the Origination/Destination (terminal points) of the fare component have changed.

Page E.03.31.192 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3

ORIGINAL ITINERARY NEW – DESIRED ITINERARY Fare Date Fare Fare Change Fee Fare Date Fare Fare Component Class Component Class MSP-PIT 08JUL98 KE14NR $100 $50 Highest in PU MSP-PIT 08JUL98 KE14NR $100 (Keep fare) PIT-MSP 14JUL98 HE14NR $200 $75 Highest in PU PIT-MSP 20SEP98 HSPSCL $150 (current fare) Scenario: • 1st fare component is KE14NR ($100 value); 2nd fare component is HE14NR ($200 value). • The first fare component is not being changed. • The second fare component is being changed. Return travel now desired on September 20th. • For the purpose of this example, assume that travel is kept as directed in the travel and fare break limitation fields. • For the purpose of this example, assume that the itinerary does not meet the previously ticketed rule provisions. • Itinerary is re-priced using the same fares and rules as previously ticketed (Keep fares) for the first fare component (KE14NR $100), and using current fare and rule information for the second fare component (HSPSC, $150).

Calculation: Previous ticketed value ($100 + $200) = $300 - Value of desired itinerary ($100 + $150) = $250 - Change fee $75 $75 Amount of Additional Collection ($25)

Explanation: • The first fare component was unchanged and was priced using the same fares and rules as previously ticketed (Keep fares). • The second fare component was changed and was priced using current fares and rule information. • KE14NR was kept from the original itinerary ($120) for the first fare component and new fare eligible in the market HSPCL equal to $150 for the second fare component. • The $75 change fee was applied because it was the highest change fee on the pricing unit. • Re-pricing Result: Allow the change and add-collect $25 (-$50 difference in fares + $75 change fee).

Page E.03.31.193 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Process Tag 11 – Keep Fares up to First Changed Fare Component, Historical Fares for Changed

Re-price the itinerary using the same fares as previously ticketed up to the first changed fare component, and historical fares for all subsequent fare components. Processing must apply to the following requirements: • Applies before or after departure. • For fare components that are instructed to Keep the fares, bytes 43-46 and 48-55 have no application. For all other fare components process the fare component or fare break points as further defined by fare break limitation fields (bytes 43-46 and 48- 55). • Re-price the itinerary as directed by the travel limitation fields (bytes 23-40). • Keep the previously ticketed fares and rules for all unchanged fare components up to the point of change. (Note that determination of ‘up to the point of change’ is based on sequence of travel.) • Re-price all other components using fares and rules that existed on the date of previous ticket issuance (historical fares)

Example 1

A ---- B ----- C ----D ----- A (Circle Trip Itinerary with A, B, D fare break points; C is a connection point.)

Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Process Tag Portion Term 11 BLANK Y The data indicates to re-price using Process Tag 11 changes to fare break points are permitted on the fare component.

The passenger wishes to change from point C. • Processing will match the Table 988 sequence. • Apply the Process Tag and Revalidation provisions regardless of whether the change is being made before or after departure from journey origin. • Cannot change the previously ticketed fare for fare components up to the point of change (C); therefore, previously ticketed fare for the A-B fare component cannot change.

Page E.03.31.194 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

• Using historical fares for the other fare components revalidate all provisions against the new itinerary. Replace any or all fare components (with the exception of the A-B fare component).

Example 2

A ---- B ----- C ----D ----- A (Circle Trip Itinerary with A, B, D fare break points; C is a connection point.)

Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Process Tag Portion Term 11 BLANK BLANK The data indicates to re-price using Process Tag 11. Changes to fare break points are not permitted on the fare component.

The passenger wishes to change from point C. • Processing will match the Table 988 sequence. • Apply the Process Tag and Revalidation provisions regardless of whether the change is being made before or after departure from journey origin. • Fare break points A, B, and D cannot be changed (per value Blank in byte 43); therefore, the itinerary cannot be re-priced by including any new or removing any existing fare break points. • Cannot change the previously ticketed fare for fare components up to the point of change (C); therefore, previously ticketed fare for the A-B fare component cannot change. • Using historical fares for the B-D and D-A fare components, revalidate all provisions against the new itinerary. Replace any or all fare components (with the exception of the A-B fare component). NOTE: The Same Point Table (bytes 48-55) must be considered when determining whether the Origination/Destination (terminal points) of the fare component have changed.

Page E.03.31.195 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3

ORIGINAL ITINERARY NEW - DESIRED ITINERARY Fare Date Fare Fare Change Fee Fare Date Fare Class Fare Component Class Component MSP- PIT 08JUL98 KE14NR $100 $50 Highest in PU MSP – PIT 08JUL98 KE14NR $100 (previous tktd fare) PIT - MSP 14JUL98 HE14NR $200 $75 Highest in PU PIT - MSP 20SEP98 HSPSCL $150 (historical fare)

Scenario: • 1st fare component is KE14NR ($100 value); 2nd fare component is HE14NR ($200 value). • The first fare component is not being changed. • The second fare component is being changed. Return travel now desired on September 20th. • For the purpose of this example, assume that travel is kept as directed in the travel and fare break limitation fields. • For the purpose of this example, assume that second fare component does not meet the previously ticketed rule provisions. • Itinerary is re-priced using the previously ticketed fare for the first fare component (KE14NR, $100, unchanged), and using historical fare and rule information for the second fare component (HSPSCL, $150, changed.)

Page E.03.31.196 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Calculation Previous ticketed value ($100 + $200 = $300 Value of desired itinerary ($100 + $150 = $250 Change Fee $75 > $50 $75 ______Amount of Calculation $25

Explanation: • The first fare component was priced keeping the previously ticketed fare because it was unchanged. • The second fare component was priced using historical fares and rules information. • New fare in the market for which the passenger qualified is HSPCL equal to $150 for the second fare component. • The $75 change fee was applied because it was the highest change fee Fare on the pricing unit.

Re-pricing Results: Allow the change and add collect $25 (-$50 difference in fares + $75 change fee)

Page E.03.31.197 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Different Process Tag Values on an Itinerary

When the Process Tag values are not the same for all fare components in the itinerary, all Process Tag permutations for the journey should be determined. A number of Process Tag permutations represent possible re-price methods, depending upon the validation of the remaining Table 988 data. After all Process Tag permutations have been determined, the next step is to determine the fares to be selected for each fare component within the itinerary based on the applicable Process Tag values.

When determining the fares to be selected based on the Process Tag value, if a single fare component is directed to select different fares (keep the fares, use current fares, use historical fares, or cancel and start over), then the most restrictive philosophy applies within the fare component. The most restrictive philosophy causes the selection of the most restrictive fares. It is important to note that the original Table 988 associated with each fare component shall still to be applied to that fare component. The process tag application determines the type of fares to re-price the itinerary with and the method of re-pricing such fares. The original Table 988 still needs to be validated for that fare component after the type of fares has been determined by the Process Tag application described below. The chart below identifies the most restrictive re-pricing philosophy that applies when a given fare component is directed to select different fares based on the Process Tag permutation.

Process Tag 6 directs the reissue to use travel commencement fares. The determination of what type of fares to be used differs from the normal process tag philosophy (see Tag 6 definition). Process Tag 6 will result in the usage of current or historical fares, depending on if travel has commenced when the reissue is requested. For the purposes of the most restrictive hierarchy, Process Tag 6 fares should be treated as either current or historical, depending on which one the Tag’s definition directed the re-price to perform.

Page E.03.31.198 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Most restrictive Process Tag application within a single fare component:

Process Tag Application Process Tag Re-price Process Application Application Keep Fares Historical Fares Keep Fares (either type) Keep Fares Current Fares Current Fares Keep Fares Cancel/Start Over Cancel/Start Over Historical Fares (either type) Current Fares Current Fares Historical Fares (either type) Cancel/Start Over Cancel/Start Over Current Fares Cancel/Start Over Cancel/Start Over Historical Travel Commence Historical Historical NOTE: The most restrictive philosophy does not apply across fare components. NOTE: Process Tag 6 contains a version of historical fares which is measured from the travel commencement date instead of the ticket issue date. This type of historical fares is referred to as Historical Travel Commence fares. The traditional historical fares referencing fares in effect when the itinerary was ticketed will still be referred to generically as Historical fares. The above hierarchy reflects the inclusion of historical travel commencement fares.

The steps in determining the possible re-price method when multiple process tags apply for a single and/or multiple fare components are identified below. These steps are intended to reflect how the ATPCO Automated Rules product should be applied; they do not necessarily reflect the processing of any specific CRS/GDS. The example on the following pages will be used to illustrate the steps.

Page E.03.31.199 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example

• A-B priced round trip • A to B fully traveled The following represents the matched Table 988 data for each fare: TABLE 988 NO SEQ NO PROCESS TAG A-B Fare 123 1 1 5 2 B-A Fare 456 4 1 8 4

1. Based on the ‘matched‘ Table 988 sequences (including the validation of Table 988 STOP field, Byte 206), determine Process Tags for all fare components in the itinerary. If the Process Tag values are not the same for all fare components within the itinerary, determine all possible Process Tag permutations.

Applicable Process Tag Permutations for the example above: ⇒ 1 and 1 ⇒ 1 and 4 ⇒ 2 and 1 ⇒ 2 and 4

Page E.03.31.200 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

2. The following steps should be applied to each dissimilar Process Tag permutation.

a. Determine the fares to be selected by applying the definitions of each Process Tag value.

Process Tag Permutation 1 and 4 above directs the following fares to be selected for each fare component. ⇒ Process Tag 1 Directs the A to B fare component to KEEP fares and B to A fare component to KEEP fares. ⇒ Process Tag 4 Directs the A to B fare component to KEEP fares and B to A fare component to use CURRENT fares.

1 = KEEP/4 = KEEP A B 1 = KEEP/4 = CURRENT

b. Apply the most restrictive philosophy for fare components directed to select different fares.

Permutation: 1 and 4, the most restrictive philosophy should be applied to the B to A fare component. The following fares should be used for selection purposes.

KEEP A B CURRENT

Page E.03.31.201 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

3. Validate the remaining data (how to re-price) in the Table 988 entry corresponding to the applicable Process Tag for each fare component. Each fare component should validate the original Table 988 that was associated with it. The process tag permutation only determines what types of fares to use when re-pricing the itinerary. This validation process should be done for all permutations to determine the applicable re-price solution. The exception to validating the corresponding Table 988 data applies when a fare component is directed to cancel and start over. If a fare component is directed to cancel and start over, then processing should re-price using current fares and rules, applying any applicable cancellation penalty. Note: Refer to later sections in this document to determine how each remaining Table 988 fields should be validated against the itinerary.

Process Tag Permutation 1 and 1: ⇒ A to B Fare will validate Table 988 Number 123, Sequence Number 1. ⇒ B to A Fare will validate Table 988 Number 456, Sequence Number 4.

Process Tag Permutation 1 and 4: ⇒ A to B Fare will validate Table 988 Number 123, Sequence Number 1. ⇒ B to A Fare will validate Table 988 Number 456, Sequence Number 8.

Process Tag Permutation 2 and 1: ⇒ A to B Fare will validate Table 988 Number 123, Sequence Number 5. ⇒ B to A Fare will validate Table 988 Number 456, Sequence Number 4.

Process Tag Permutation 2 and 4: ⇒ A to B Fare will validate Table 988 Number 123, Sequence Number 5. ⇒ B to A Fare will validate Table 988 Number 456, Sequence Number 8.

4. Apply the best pricing solution from the permutations that validated.

Page E.03.31.202 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Examples for Determining the Re-Pricing Methods when Multiple Process Tags Exist NOTE: The examples below represent matched Category 31 and Table 988 data.

Example 1

⇒ Itinerary: ATL-LON priced round trip (single pricing unit) ⇒ ATL to LON Fully Traveled

Record 3 Category 31: Record 3 Category 31 ATL to LON fare LON to ATL fare TBL NO TBL 988 NO TBL NO TBL 988 NO Bytes 6-13 Bytes 55-62 Bytes 6-13 Bytes 55-62 100 20 200 30

Table 988 No. : 20 Table 988 No. 30 TBL NO SEQ NO PROCESS TAG TBL NO SEQ NO PROCESS TAG Bytes 6-13 Bytes 14-20 Bytes 21-22 Bytes 6-13 Bytes 14-20 Bytes 21-22 20 2 1 30 5 3

1. Process Tag values are not the same for all fare components; determine all applicable Process Tag permutations. ⇒ 1 and 3

Page E.03.31.203 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

2. The following steps apply to each dissimilar Process Tag permutation:

a. Determine the fares to be selected by applying the definitions of each Process Tag value.

1= KEEP/3 = KEEP ATL LON

1=KEEP/3 = CURRENT

b. Apply the most restrictive philosophy for each component. The following should be used for selection purposes.

KEEP ATL LON

CURRENT

3. Validate the remaining data (how to re-price) in the Table 988 entry corresponding to the applicable Process Tag for each fare component. This validation process should be done to all permutations to determine all applicable re-price solutions.

⇒ ATL to LON = Table 988 Number 20, Sequence Number 2 ⇒ LON to ATL = Table 988 Number 30, Sequence Number 5

4. Apply the best pricing solution from the permutations that validated.

Page E.03.31.204 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2

⇒ Itinerary: ATL-JAX priced round trip (single pricing unit) ⇒ ATL to JAX Fully Traveled

Record 3 Category 31: Record 3 Category 31 ATL to JAX fare JAX to ATL fare TBL NO TBL 988 NO TBL NO TBL 988 NO Bytes 6-13 Bytes 55-62 Bytes 6-13 Bytes 55-62 222 33 444 55

Table 988 No. 33 Table 988 No. 55 TBL NO SEQ NO PROCESS TAG TBL NO SEQ NO PROCESS TAG Bytes 6-13 Bytes 14-20 Bytes 21-22 Bytes 6-13 Bytes 14-20 Bytes 21-22 33 1 1 55 3 1 2 8 1 4 2 8

1. Process Tag values are not the same for all fare components; determine all applicable Process Tag permutations.

⇒ 1 and 1 ⇒ 1 and 4 ⇒ 1 and 8 ⇒ 8 and 4 ⇒ 8 and 8

Page E.03.31.205 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

2. The following steps should be applied to each dissimilar Process Tag permutation:

a. Determine the fares to be selected by applying the definitions of each Process Tag value.

⇒ 1 and 4 ⇒ 1 and 8 1 = KEEP/4 = KEEP 1 = KEEP/8 = XCL ATL JAX ATL JAX 1 = KEEP/4 = CURRENT 1 = KEEP/8 = XCL

⇒ 8 and 4 8 = XCL/ 4 = KEEP ATL JAX 8 = XCL/4 = CURRENT

b. Apply the most restrictive philosophy for fare components directed to select different fares.

⇒ 1 and 4 ⇒ 1 and 8 KEEP XCL ATL JAX ATL JAX CURRENT XCL

⇒ 8 and 4 XCL ATL JAX XCL

Page E.03.31.206 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

3. Validate the remaining data (how to re-price) in the Table 988 entry corresponding to the applicable Process Tag for each fare component. This validation process should be done for all permutations to determine the applicable re-price solutions.

Process Tag Permutation 1 and 1: ⇒ ATL to JAX Fare will validate Table 988 Number 33, Sequence Number 1. ⇒ JAX to ATL Fare will validate Table 988 Number 55, Sequence Number 3.

Process Tag Permutation 1 and 4: ⇒ ATL to JAX Fare will validate Table 988 Number 33, Sequence Number 1. ⇒ JAX to ATL Fare will validate Table 988 Number 55, Sequence Number 1.

Process Tag Permutation 1 and 8: ⇒ ATL to JAX Fare – Cancel and Start Over ⇒ JAX to ATL Fare – Cancel and Start Over

Process Tag Permutation 8 and 4: ⇒ ATL to JAX Fare – Cancel and Start Over ⇒ JAX to ATL Fare – Cancel and Start Over

Process Tag Permutation 8 and 8: ⇒ ATL to JAX Fare – Cancel and Start Over. ⇒ JAX to ATL Fare – Cancel and Start Over

4. Apply the best pricing solution from the permutations that validated.

Page E.03.31.207 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3

⇒ Itinerary: ATL-JAX priced round trip (PU1) UNCHANGED ⇒ ATL-MSP prices round trip (PU2) CHANGE to Departure Date

Record 3 Category 31 applies to: Record 3 Category 31 applies to: ATL to JAX and JAX to ATL fare ATL to MSP and MSP to ATL fares TBL NO TBL 988 NO TBL NO TBL 988 NO Bytes 6-13 Bytes 55-62 Bytes 6-13 Bytes 55-62 111 88 444 99

Table 988 No. 88 Table 988 No. 99 TBL NO SEQ NO PROCESS TAG TBL NO SEQ NO PROCESS TAG Bytes 6-13 Bytes 14-20 Bytes 21-22 Bytes 6-13 Bytes 14-20 Bytes 21-22 88 5 1 99 2 4 6 8

1. Process Tag values are not the same for all fare components; determine all applicable Process Tag permutations.

⇒ 1 – 1 – 4 – 4 ⇒ 1 – 1 – 8 – 8 ⇒ 1 – 1 – 4 – 8 ⇒ 1 – 1 – 8 – 4

Page E.03.31.208 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

2. The following steps should be applied to each dissimilar Process Tag permutation:

a. Determine the fares to be selected by applying the definitions of each Process Tag value.

⇒ 1 – 1 – 4 – 4

1 = KEEP/4 = KEEP 1 = KEEP/4 = KEEP ATL JAX ATL MSP 1 = KEEP/4 = CURRENT 1 = KEEP/4 = CURRENT

⇒ 1 – 1 – 8 – 8

1 = KEEP/ 8 = XCL 1 = KEEP/8 = XCL ATL JAX ATL MSP 1 = KEEP/8 = XCL 1 = KEEP/8 = XCL

⇒ 1 – 1 – 4 – 8

1 = KEEP/ 4 = KEEP/8 = XCL 1 = KEEP/4 = KEEP/8 = XCL ATL JAX ATL MSP 1 = KEEP/4 = CURRENT/8 = XCL 1 = KEEP/4 = CURRENT/8 = XCL

⇒ 1 – 1 – 8 – 4

1 = KEEP/8 = XCL/4 = KEEP 1 = KEEP/8 = XCL/4 = KEEP ATL JAX ATL MSP 1 = KEEP/8 = XCL/4 = CURRENT 1 = KEEP/8 = XCL/4 = CURRENT

Page E.03.31.209 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

b. Apply the most restrictive philosophy for fare components directed to select different fares.

⇒ 1 – 1 – 4 – 4

KEEP KEEP ATL JAX ATL MSP CURRENT CURRENT

⇒ 1 – 1 – 8 – 8

XCL XCL ATL JAX ATL MSP XCL XCL

⇒ 1 – 1 – 4 – 8

XCL XCL ATL JAX ATL MSP XCL XCL

⇒ 1 – 1 – 8 – 4

XCL XCL ATL JAX ATL MSP XCL XCL

Page E.03.31.210 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

3. Validate the remaining data (how to re-price) in the Table 988 entry corresponding to the applicable Process Tag for each fare component. This validation process should be done to all permutations to determine the applicable re-price solutions.

Process Tag Permutation 1 – 1- 4 – 4: ⇒ ATL to JAX/JAX to ATL Fares will validate Table 988 Number 88, Sequence Number 5. ⇒ ATL to MSP/MSP to ATL Fares will validate Table 988 Number 99, Sequence Number 2.

Process Tag Permutation 1 – 1 – 8 – 8: ⇒ ATL to JAX/JAX to ATL – Cancel and Start Over ⇒ ATL to MSP/MSP to ATL – Cancel and Start Over

Process Tag Permutation 1 – 1 – 4 – 8: ⇒ ATL to JAX/JAX to ATL – Cancel and Start Over ⇒ ATL to MSP/MSP to ATL – Cancel and Start Over

Process Tag Permutation 1 – 1 – 8 – 4: ⇒ ATL to JAX/JAX to ATL – Cancel and Start Over ⇒ ATL to MSP/MSP to ATL – Cancel and Start Over

4. Apply the best pricing solution from the permutations that validated.

Page E.03.31.211 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 4

⇒ Itinerary: NYC-LON priced round trip (single pricing unit) ⇒ NYC to LON Fully Traveled

Record 3 Category 31: Record 3 Category 31 NYC to LON fare LON to NYC fare TBL NO TBL 988 NO TBL NO TBL 988 NO Bytes 6-13 Bytes 55-62 Bytes 6-13 Bytes 55-62 100 20 200 30

Table 988 No. : 20 Table 988 No. 30 TBL NO SEQ NO PROCESS TAG TBL NO SEQ NO PROCESS TAG Bytes 6-13 Bytes 14-20 Bytes 21-22 Bytes 6-13 Bytes 14-20 Bytes 21-22 20 2 1 30 3 2

1. Process Tag values are not the same for all fare components; determine all applicable Process Tag permutations.1 and 2

2. The following steps apply to each dissimilar Process Tag permutation:

a. Determine the fares to be selected by applying the definitions of each Process Tag value.

i. 1= KEEP/2=HIST TRAVEL COMMENCE NYC LON

ii. 1=KEEP/HIST TRAVEL COMMENCE

Page E.03.31.212 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

b. Apply the most restrictive philosophy for each component. The following should be used for selection purposes.

1. KEEP NYC LON

2. KEEP

3. Validate the remaining data (how to re-price) in the Table 988 entry corresponding to the applicable Process Tag for each fare component. This validation process should be done to all permutations to determine all applicable re-price solutions.

NYC to LON = Table 988 Number 20, Sequence Number 2 LON to NYC = Table 988 Number 30, Sequence Number 3

4. Apply the best pricing solution from the permutations that validated.

Page E.03.31.213 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 5

⇒ Itinerary: NYC-LON priced round trip (single pricing unit) ⇒ Travel has not commenced.

Record 3 Category 31: Record 3 Category 31 NYC to LON fare LON to NYC fare TBL NO TBL 988 NO TBL NO TBL 988 NO Bytes 6-13 Bytes 55-62 Bytes 6-13 Bytes 55-62 100 20 200 30

Table 988 No. : 20 Table 988 No. 30 TBL NO SEQ NO PROCESS TAG TBL NO SEQ NO PROCESS TAG Bytes 6-13 Bytes 14-20 Bytes 21-22 Bytes 6-13 Bytes 14-20 Bytes 21-22 20 2 1 30 3 6

2. Process Tag values are not the same for all fare components; determine all applicable Process Tag permutations. 1 and 6 (due to travel has not commenced, process tag 6 refers to fares in effect when the ticket is reissued)

3. The following steps apply to each dissimilar Process Tag permutation:

a. Determine the fares to be selected by applying the definitions of each Process Tag value.

1= KEEP/6= CURRENT NYC LON

i. 1=KEEP/6=CURRENT

NOTE: Since travel has not yet commenced, Process Tag 6 directs the re-price to use fares valid for ticketing at the time of reissue and valid for travel on the new travel commencement date. This would dictate to utilize CURRENT fares that meet these parameters.

Page E.03.31.214 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

b. Apply the most restrictive philosophy for each component. The following should be used for selection purposes.

CURRENT NYC LON

CURRENT

4. Validate the remaining data (how to re-price) in the Table 988 entry corresponding to the applicable Process Tag for each fare component. This validation process should be done to all permutations to determine all applicable re-price solutions.

NYC to LON = Table 988 Number 20, Sequence Number 2 LON to NYC = Table 988 Number 30, Sequence Number 3

5. Apply the best pricing solution from the permutations that validated.

Page E.03.31.215 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 6

⇒ Itinerary: NYC-LON priced round trip (single pricing unit) ⇒ NYC-LON Fully traveled

Record 3 Category 31: Record 3 Category 31 NYC to LON fare LON to NYC fare TBL NO TBL 988 NO TBL NO TBL 988 NO Bytes 6-13 Bytes 55-62 Bytes 6-13 Bytes 55-62 100 20 200 30

Table 988 No. : 20 Table 988 No. 30 TBL NO SEQ NO PROCESS TAG TBL NO SEQ NO PROCESS TAG Bytes 6-13 Bytes 14-20 Bytes 21-22 Bytes 6-13 Bytes 14-20 Bytes 21-22 20 2 1 30 3 6

1. Process Tag values are not the same for all fare components; determine all applicable Process Tag permutations. a. 1 and 6 (due to travel having commenced, process tag 6 refers to fares in effect when travel commenced)

2. The following steps apply to each dissimilar Process Tag permutation:

a. Determine the fares to be selected by applying the definitions of each Process Tag value.

1= KEEP/6= HIST TRAVELCOMMENCE NYC LON

1=KEEP/6=HIST TRAVEL COMMENCE

NOTE: Since travel has commenced, Process Tag 6 directs the re-price to use fares valid that existed for ticketing on the original travel commencement date (historical travel commencement fares).

Page E.03.31.216 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

b. Apply the most restrictive philosophy for each component. The following should be used for selection purposes.

1. KEEP NYC LON

2. KEEP

3. Validate the remaining data (how to re-price) in the Table 988 entry corresponding to the applicable Process Tag for each fare component. This validation process should be done to all permutations to determine all applicable re-price solutions.

NYC to LON = Table 988 Number 20, Sequence Number 2 LON to NYC = Table 988 Number 30, Sequence Number 3

4. Apply the best pricing solution from the permutations that validated.

Page E.03.31.217 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Limits on how to re-price the itinerary Once it has been determined how to re-price the itinerary using the Process Tags, processing will validate the other fields in the Table 988 sequence to determine conditions under which the itinerary may be re-priced as well as how to validate or revalidate the rule conditions. The Process Tag definition and the limitations on re-pricing have an AND relationship; both must be met in order to re- price the itinerary. The following sections detail re-pricing limitations and revalidation of rule conditions.

4.5.2.1. Reissue to a Lower Fare – Byte 207

Byte 207 works in conjunction with Process Tag 7 – reissue to a lower fare. Edits prevent byte 207 from being coded unless Process Tag 7 is selected in Table 988 bytes 21-22. This byte requires a journey validation. If multiple values of byte 207 are found across an itinerary, then the new itinerary must pass validation for every byte 207 value.

Values for Byte 207 are: R One of the following must be true for at least one fare component of the reprice solution: • the fare is the same fare as the ticketed fare (same Fare Class) and the fare amount was reduced after the time of original ticket issuance • the fare has a lower fare amount than the ticketed fare and a rule provision of the fare was revised after the time of original ticket issuance. • the fare has a lower fare amount than the ticketed fare and was not in effect at the time of original ticket issuance F One of the following must be true for at least one fare component of the reprice solution: • the fare is the same fare as the ticketed fare (same Fare Class) and the fare amount was reduced after the time of original ticket issuance • the fare has a lower fare amount than the ticketed fare and was not in effect at the time of original ticket issuance Blank No Application

Page E.03.31.218 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.3. Fare Break Limitations (bytes 43-46 and 48-55)

The data in the Fare Break Limitations fields specifies conditions under which the itinerary may be re-priced. Limitations on re- pricing the itinerary can be included in the Process Tag (bytes 21-22) definition as well as the Fare Break Limitation (bytes 43-46 and 48-55) fields. The relationship among the Fare Break Limitation fields is AND; and the relationship between the Process Tag definition and the Fare Break Limitation fields is AND. Processing must adhere to all limitations in order to re-price the itinerary. If data in one of the fields conflicts with the other, then processing will fail the associated Table 988 sequence and continue processing to the next sequence and/or Record 3 table.

Fare Break Limitations consist of the following fields: 4.5.3.1 Term (byte 43) 4.5.3.2 1st Break (byte 44) 4.5.3.3 Coupon (byte 45) 4.5.3.4 Fully Flown (byte 46) 4.5.3.5 Same Point Table No. 993 (bytes 48-55)

Page E.03.31.219 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.3.1. Term (byte 43)

The Term field specifies whether changes to fare break points (terminal points) are permitted or not permitted. The field requires a fare component validation. When re-pricing, processing must determine the value in byte 43 before attempting to re-price the itinerary using different fare break points. Processing must identify all fare break points on the previous fare component. Processing will compare the terminal points of the fare component being validated against the terminal points of the new fare component. When this field is value Y any previous fare break points may be changed on the new fare component. When the value in byte 43 is value Y, then changes to fare break points are permitted. When the value in byte 43 is value BLANK, then changes to fare break points are not permitted; processing may not re-price the fare component by including any new fare break points or removing or changing the order of any existing fare break points from the previous fare component. Note that changes to departure dates, times, carrier, flight number, and class of service are still permitted at the fare break points. NOTE: Edits require that when Process Tag (bytes 21-22) is value 1 and Table 988 byte 112 is value BLANK, then byte 43 must be value BLANK, and when Fully Flown (byte 46) is value X, Y or B then byte 43 must be value Y.

Page E.03.31.220 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1 (Byte 43 coded)

ORIGINAL Itinerary: LAX-BOS RT Dept 01Mar07 NW352 LAX BOS Dept 28Mar07 NW353

NEW Itinerary: BOS-LAX RT Dept 01Mar07 NW353 BOS LAX Dept 28Mar07 NW352

The LAX-BOS and BOS-LAX fare components resolve to Category 31 Record 3 with the following Table 988 data: Bytes 8-11 Byte 24 Seq # Term 1 blank The data indicates that when fare break points are not changed, processing will match sequence 1 and apply the applicable re-pricing data.

When validating the LAX-BOS and BOS-LAX fare components: NO MATCH • Determine if the fare breaks points of the LAX-BOS fare component on the previous itinerary have been changed or re-ordered. • Determine if the fare breaks points of the BOS-LAX fare component on the previous itinerary have been changed or re-ordered. • The fare break points on both fare components on the previous itinerary have been re-ordered. • Processing will no match Table 988 sequence 1.

Page E.03.31.221 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Examples on the Following Pages Use the Original and New Itineraries Below:

ORIGINAL Itinerary: CHI-LON RT (via NYC) End-on-End with LON-PAR RT Dept 01Jan01 Dept 03Jan01 Dept 04Jan01 CHI NYC LON PAR Dept 01Feb01 Dept 28Jan01 Dept 25Jan01 Ticketing Information: Carrier Flight Date Sector Bkg Code UA 100 01JAN 01 CHI-NYC Y UA 400 03JAN 01 NYC-LON Y AF 1100 04JAN 01 LON-PAR Y AF 1200 25JAN 01 PAR-LON Y UA 401 28JAN 01 LON-NYC Y UA 101 01FEB 01 NYC-CHI Y

NEW Itinerary A – passenger requests to change original itinerary: Dept 01Jan01 Dept 04Jan01 Dept 05Jan01 CHI NYC LON PAR Dept 01Feb01 Dept 25Jan01 Dept 25Jan01 Ticketing Information: Carrier Flight Date Sector Bkg Code UA 100 01JAN 01 CHI-NYC Y No change UA 400 04JAN 01 NYC-LON Y CHANGE AF 1100 05JAN 01 LON-PAR Y CHANGE AF 1200 25JAN 01 PAR-LON Y No change UA 401 25JAN 01 LON-NYC Y CHANGE UA 101 01Feb 01 NYC-CHI Y No change

Page E.03.31.222 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

NEW Itinerary B– passenger requests to change original itinerary: Dept 01Jan01 Dept 03Jan01 Dept 04Jan01 CHI NYC AMS PAR Dept 01Feb01 Dept 28Jan01 Dept 25Jan01 Ticketing Information: Carrier Flight Date Sector Bkg Code UA 100 01JAN 01 CHI-NYC Y No change UA 502 03JAN 01 NYC-AMS Y CHANGE AF 2222 04JAN 01 AMS-PAR Y CHANGE AF 2221 25JAN 01 PAR-AMS Y CHANGE UA 503 28JAN 01 AMS-NYC Y CHANGE UA 101 01Feb 01 NYC-CHI Y No change

Page E.03.31.223 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1 (Value Y)

Assume fare components in the original itinerary resolve to the following Table 988: Bytes 21-22 Byte 43 Process Tag Term 02 Y The data indicates to re-price using Process Tag 02. Changes to fare break points are permitted on the fare component.

When attempting to re-price New Itinerary A: • Processing will match the Table 988 sequence. • Apply the Process Tag and Revalidation provisions regardless of whether the change is being made before or after departure from journey origin. • Changes to fare break points are permitted on the fare component. Processing will re-price using fare and rule provisions in existence on the date of previous ticket issuance (historical fares) for all fare components. Processing may keep the previous fare break points of CHI, LON, and PAR, or may re-price using different fare breaks (e.g. re-price as a round trip CHI-PAR-CHI with stopover in NYC and connection in LON; or as a CHI-NYC-CHI RT with a NYC-PAR-NYC RT with connection in LON).

When attempting to re-price New Itinerary B: • Processing will match the Table 988 sequence. • Apply the Process Tag and Revalidation provisions regardless of whether the change is being made before or after departure from journey origin. • Fare break point LON is changed to AMS, and Changes to fare break points are permitted on the fare component. Processing will re-price using fare and rule provisions in existence on the date of previous ticket issuance (historical fares) for all fare components. Additionally, processing may keep the previous fare break points of CHI and PAR, or may re-price using different fare breaks (e.g. re-price as a round trip CHI-PAR-CHI with stopover in NYC and connection in AMS; or as a CHI-NYC-CHI RT with a NYC- PAR-NYC RT with connection in AMS).

Page E.03.31.224 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2 (Value BLANK)

Assume fare components in the original itinerary resolve to the following Table 988: Bytes 21-22 Byte 43 Process Tag Term 02 BLANK The data indicates to re-price using Process Tag 02. Changes to fare break points are not permitted on the fare component.

When attempting to re-price New Itinerary A: • Processing will match the Table 988 sequence. • Apply the Process Tag and Revalidation provisions regardless of whether the change is being made before or after departure from journey origin. • Changes to fare break points are not permitted on the fare component. Processing will re-price using fare and rule provisions in existence on the date of previous ticket issuance (historical fares) for all fare components. Processing must keep the previous fare break points of CHI, LON, and PAR, and may not re-price using different fare breaks (e.g. cannot re-price as a round trip CHI- PAR-CHI with stopover in NYC and connection in LON; or as a CHI-NYC-CHI RT with a NYC-PAR-NYC RT with connection in LON).

When attempting to re-price New Itinerary B: • Processing will match the Table 988 sequence. • Apply the Process Tag and Revalidation provisions regardless of whether the change is being made before or after departure from journey origin. • Fare break point LON is changed to AMS, and Changes to fare break points are not permitted on the fare component. Processing will fail the Table 988 sequence and continue processing to another sequence and/or Record 3 table.

Page E.03.31.225 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3 (Term Field with Travel Limit Fields)

Assume fare components in the original itinerary resolve to the following Table 988: Bytes 21-22 Byte 24 Bytes 25-32 Bytes 33-40 Byte 43 Process Tag Portion From Geo Spec Table To Geo Spec Table Term 02 S BLANK BLANK Y The data indicates that when the first fare component of the ticket is not changed, then re-price using Process Tag 02. Changes to fare break points are permitted on the fare component.

When attempting to re-price New Itinerary A: • First fare component of the ticket is CHI-LON, and changes are made to departure from NYC. • Processing will no match the Table 988 sequence, and continue processing to another sequence and/or Record 3 table

When attempting to re-price New Itinerary B: • First fare component of the ticket is CHI-LON, and fare break point LON is being changed to AMS. • Processing will no match the Table 988 sequence, and continue processing to another sequence and/or Record 3 table NOTE: Although byte 43 indicates that Changes to fare break points are permitted, processing must first validate match data in byte 24 which states that in order to match the Table 988 sequence, no changes to the first fare component are permitted.

Page E.03.31.226 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 4 Mixed Values

Assume fare components in the original itinerary resolve to the following Table 988 data: Fare Bytes 21-22 Byte 43 component Process Tag Term CHI-LON 02 Y LON-PAR 02 Y PAR-LON 02 Y LON-CHI 02 Blank The data indicates that changes to fare break points are not permitted for the LON-CHI fare component. Fare breaks on all other fare components may change

When attempting to re-price New Itinerary A: • Processing will match the Table 988 sequence • Apply the Process Tag and Revalidation provisions regardless of whether the change is being made before or after departure from journey origin. • Changes to fare break points are not permitted on the fare component. Processing will re-price using fare and rule provisions in existence on the date of previous ticket issuance (historical fares) for all fare components. Processing must keep the previous fare break points of CHI, LON, and PAR, and may not re-price using different fare breaks (e.g. cannot re-price as a round trip CHI- PAR-CHI with stopover in NYC and connection in LON; or as a CHI-NYC-CHI RT with a NYC-PAR-NYC RT with connection in LON).

When attempting to re-price New Itinerary B: • Fare break points changed at LON to AMS. CHI-LON, LON-PAR and PAR-LON fare components allow fare break point changes. LON-CHI does not allow fare break point changes. • The itinerary will FAIL the Table 988 sequence for the LON-CHI fare component. Although processing passed for three of the fare components, since a change was made to the LON-CHI fare component, that fare component did not pass validation. Processing must continue to another Table 988 sequence/Record 3 Table for the LON-CHI fare component.

Page E.03.31.227 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 5 Mixed Values

Assume fare components in the original itinerary resolve to the following Table 988 data: Fare Bytes 21-22 Byte 43 component Process Tag Term CHI-LON 02 Y LON-PAR 02 Blank PAR-LON 02 Blank LON-CHI 02 Y The data indicates that changes to fare break points are not permitted for the CHI-LON-CHI fare components. Fare breaks on all other fare components may change

When attempting to re-price New Itinerary A: • Processing will match the Table 988 sequence • Apply the Process Tag and Revalidation provisions regardless of whether the change is being made before or after departure from journey origin. • Changes to fare break points are not permitted on the fare components LON-PAR-LON. Processing will re-price using fare and rule provisions in existence on the date of previous ticket issuance (historical fares) for all fare components. Processing must keep the previous fare break points of CHI, LON, and PAR, and may not re-price using different fare breaks (e.g. cannot re-price as a round trip CHI-PAR-CHI with stopover in NYC and connection in LON; or as a CHI-NYC-CHI RT with a NYC-PAR-NYC RT with connection in LON).

When attempting to re-price New Itinerary B: • Fare break points changed at LON to AMS. CHI-LON, LON-CHI fare components allow fare break point changes. LON-PAR, PAR-LON does not allow fare break point changes. The itinerary will FAIL the Table 988 sequence for the LON-PAR-LON fare components. Although processing passed for two of the fare components, one pricing unit, since a change was made to the LON-PAR-LON fare component, that fare component did not pass validation. Processing must continue to another Table 988 sequence/Record 3 Table for the LON-PAR-LON fare components.

Page E.03.31.228 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.3.2. 1st Break (byte 44)

This 1st Break field indicates whether the first fare component in the itinerary must be re-priced by keeping the previous fare. When this field is Blank, the first fare component on the new itinerary may be re-priced using the same or different fares than previously ticketed. Whether or not the same or different fare is used is subject to the Process Tag definition. When this field is value Y, the first fare component on the new itinerary must be re-priced using the same fare as previously ticketed. Processing must validate the ticketed fare on the first fare component of the previous journey and use this fare for the first fare component of the new journey. If any change is made to a fare break point of the first fare component of the previous itinerary (provided byte 43 is value Y), then the value in byte 44 has no application, as processing cannot keep the previously ticketed fare when fare break points are changed (note that ATPCO’s coding convention holds that when byte 43 is value Y, then byte 44 should not be value Y). Value Y supplements and may override the Process Tag definition. When the Process Tag indicates to re-price using historical fares or current fares, then the first fare component must keep the previously ticketed fare and all other fare components must be re-priced using historical or current fares as specified by the Process Tag definition.

Page E.03.31.229 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1 (Value Blank with Process Tag 03).

A ---- B ----- C ----D ----- A (Circle Trip Itinerary with A, B, D fare break points; C is a connection point.)

Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Byte 44 Process Tag Portion Term 1st Break 03 BLANK Y Blank The data indicates to re-price using Process Tag 03. Changes to fare break points are permitted on the fare component. The first fare component may be re-priced using the same or different fares as previously ticketed.

Scenario A The passenger has not traveled on any portion of the itinerary and wishes to make a change: • Processing will match the Table 988 sequence. • Change is made before departure from journey origin; therefore Process Tag 03 indicates to use current fares and rules for all fare components. • Processing will re-price using current fare and rule provisions in existence on date of new ticket issuance for all fare components.

Scenario B The passenger has traveled up to point C and wishes to make a change: • Processing will match the Table 988 sequence. • Change is made after departure from journey origin; therefore apply Process Tag 03 definition and remainder of the limitations. • Processing must keep the previously ticketed fare for the A-B fare component (according to the Process Tag 03 definition). • Processing will re-price using current fare and rule provisions in existence on date of new ticket issuance for all fare components.

Page E.03.31.230 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2 (Value Blank with Process Tag 04)

A ---- B ----- C ----D ----- A (Circle Trip Itinerary with A, B, D fare break points; C is a connection point.)

Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Byte 44 Process Tag Portion Term 1st Break 04 S Y Blank The data indicates that when no changes are made to the first fare component of the ticket, then re-price using Process Tag 04. Changes to fare break points are permitted on the fare component. The first fare component may be re-priced using the same or different fares as previously ticketed.

The passenger wishes to change from point C: • No change is made to the first fare component of the ticket (A-B), and processing will match the Table 988 sequence. • Process Tag 04 indicates to keep the previously ticketed fares and rules for all unchanged fare components. • Processing will re-price using the previously ticketed fare and rules provisions for the A-B fare component, and will use current fare and rule provisions for the B-D and D-A fare components. NOTE: If changes were permitted and made to the first fare component, the Process Tag definition would still be applied. Processing would re-price the changed first fare component using current fare and rule provisions.

Page E.03.31.231 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3 (Value Y with Process Tag 03)

A ---- B ----- C ----D ----- A (Circle Trip Itinerary with A, B, D fare break points; C is a connection point.)

Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Byte 44 Process Tag Portion Term 1st Break 03 BLANK BLANK Y The data indicates to re-price using Process Tag 03. Changes to fare break points are not permitted on the fare component. The first fare component must be re-priced using the same fare as previously ticketed.

Scenario A The passenger has not traveled on any portion of the itinerary and wishes to make a change: • Processing will match the Table 988 sequence. • Change is made before departure from journey origin. Process Tag 03 indicates to used current fares and rules for all fare components; however, byte 44 value Y indicates to keep the previously ticketed fare for the first fare component. Byte 44 value Y overrides the Process Tag definition. • Processing will keep the previously ticketed fare for the A-B fare component. • Processing will re-price using current fare and rule provisions in existence on date of new ticket issuance for the B-D and D-A fare components.

Scenario B The passenger has traveled up to point C and wishes to make a change: • Processing will match the Table 988 sequence. • Change is made after departure from journey origin; therefore apply Process Tag 03 definition and remainder of the limitations. • Processing must keep the previously ticketed fare for the A-B fare component (according to the Process Tag 03 definition and byte 44 value Y). • Processing will re-price using fare and rule provisions in existence on date of new ticket issuance for the B-D and D-A fare components.

Page E.03.31.232 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 4 (Value Y with Process Tag 04)

A ---- B ----- C ----D ----- A (Circle Trip Itinerary with A, B, D fare break points; C is a connection point.)

Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Byte 44 Process Tag Portion Term 1st Break 04 BLANK BLANK Y The data indicates to re-price using Process Tag 04. Changes to fare break points are not permitted on the fare component. The first fare component must be re-priced using the same fare as previously ticketed.

The passenger has not traveled on any portion of the itinerary and wishes to make a change on the A-B fare component: • Processing will match the Table 988 sequence. • Process Tag 04 indicates to keep the previously ticketed fares and rules for all unchanged fare components; however byte 44 value Y indicates to keep the previously ticketed fare for the first fare component. Byte 44 value Y overrides the Process Tag definition. • Processing will keep the previously ticketed fare for the A-B fare component. • Processing will re-price using current fare and rule provisions in existence on date of new ticket issuance for the B-D and D-A fare components.

4.5.3.3. Coupon (byte 45)

The Coupon field specifies re-pricing restrictions for unused flight coupons. An unused flight coupon is defined as an unflown sector. Validation of this field is against the journey. Processing will validate unused domestic and international coupons on the previous itinerary and compare to domestic and international sectors on the new itinerary. When this field is value Y, any unused domestic flight coupon on the journey may only be used for domestic travel; any unused international flight coupon may be converted towards a domestic or international flight (no restriction to international unused flight coupons). When this field is blank, no restrictions apply to unused domestic or international flight coupons.

Page E.03.31.233 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example

Itinerary: LAX-LON-LAX RT (via CHI) End-on-End with LON-NCE-LON RT (via PAR)

LAX CHI LON PAR NCE

Assume fare components resolve to the following Table 988: Bytes 21-22 Byte 24 Byte 43 Byte 44 Byte 45 Process Tag Portion Term 1st Break Coupon 03 BLANK Y Blank Y The data indicates to re-price using Process Tag 03. Changes to fare break points are permitted on the fare component. Unused domestic flight coupons may only be used for domestic travel.

Scenario A The passenger has traveled to LON and wishes to travel to MIL rather than NCE: • Processing will match the Table 988 sequence. • Change is made after departure from journey origin. Process Tag 03 indicates to keep the previous ticketed fares and rules for fully traveled fare components and to use current fares and rules for other fare components. • PAR-NCE and NCE-PAR are domestic flight coupons and cannot be used for international travel (cannot be changed to PAR-MIL or MIL-PAR). Changes to fare break points are permitted, and processing may extend travel to MIL (depending upon the type of fare and the value in Fully Flown byte 46). For example, may change the LON-NCE and NCE-LON fare components to be LON- MIL and MIL-LON with travel via PAR and NCE (e.g. LON-PAR-NCE-MIL on the LON-MIL fare component). • Processing must keep the previously ticketed fare for the LAX-LON fare component. • Processing may re-price using current fare and rule provisions in existence on date of new ticket issuance for the other fare components.

Page E.03.31.234 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Scenario B The passenger has traveled to CHI and wishes to travel via NYC instead of via LON: • Processing will match the Table 988 sequence. • Change is made after departure from journey origin. Process Tag 03 indicates to keep the previous ticketed fares and rules for fully traveled fare components and to use current fares and rules for other fare components. No fare component is fully traveled; therefore, apply current fares and rules for all fare components. • CHI-LON, LON-PAR, PAR-LON, and LON-CHI are international flight coupons and may be converted for domestic or international travel (CHI-LON may be converted to CHI-NYC). Changes to fare break points are permitted on the journey, and processing may re-price using any pricing solution provided that unused domestic flight coupons remain domestic. (For example, may re-price as LAX-NYC-LAX RT End-on-End with NYC-NCE-NYC RT, or may re-price as LAX-PAR-LAX RT End-on-End with PAR-NCE-PAR RT, or may re-price as LAX-NCE-LAX RT).

Page E.03.31.235 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.3.4. Fully Flown (byte 46)

The Fully Flown field indicates whether additional travel on a through fare, after the fare component has been fully traveled is permitted. Validation of data in byte 46 is against the fare component. The fare component must have been fully flown for this byte to apply. Processing will compare the terminal points of the fare component being validated against the terminal points of the new fare component. When this field is value Y any previous fare break points may be changed on the new fare component. There is no restriction to what may or may not change. When this field is value X either terminal point of the previous fare component may be extended on the new fare component, provided at least one terminal point from the previous fare component is included as a ticketed point on the new fare component. When this field is value B, the fare component may only be extended beyond the original destination terminal point found on the previous fare component. When this field is value BLANK the fare component may not be re- priced to a further point. When fare component terminal points are changed, this may impact previous and subsequent fare components on the itinerary. Any impact to other fare components must also be permitted according to the Process Tag definitions and the Fare Break Limitations fields. NOTE: Edits require that when byte 43 is value blank, byte 46 must be value BLANK and when byte 46 is value X, Y or B then byte 43 must be value Y.

Values for byte 46 are as follows:

Value X May extend as long as one point on the previous fare component is used as a ticketed point on the new fare component. Value Y May revise any previous fare break points of fare component being validated. Value B May only extend beyond original destination terminal point of fare component being validated. Value Blank Fare component may not be re-priced to a further point.

Page E.03.31.236 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

The following examples use the following 988 data:

Table 988 Data Table 988 Byte 43 Byte 46 No Term Fully Flown 1 Y X 2 Y Y 3 Y B 4 Blank Blank

Example 1

Original Ticket MSP-TYO is fully flown:

Original Itinerary: MSP TYO New Itinerary: MSP TYO SEL

Sequence 1 - The itinerary MAY be re-priced since byte 46 value X states one point on the previous fare component must be included in the new fare component. Sequence 2 – The itinerary MAY be re-priced since byte 46 value Y states any previous fare break points may be revised. Sequence 3 – The itinerary MAY be re-priced since byte 46 value B states you may only extend beyond an original destination terminal point. Sequence 4 – The itinerary MAY NOT be re-priced since byte 46 value Blank states previously ticketed fare cannot be re-priced to a further point.

Page E.03.31.237 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2

Original Ticket MSP-TYO is fully flown:

Original Itinerary: MSP TYO New Itinerary: MSP SEL

Sequence 1 - The itinerary MAY NOT be re-priced since byte 46 value X states one point on the previous fare component must be included in the new fare component. Sequence 2 – The itinerary MAY be re-priced since byte 46 value Y states any previous fare break points may be revised. Sequence 3 – The itinerary MAY NOT be re-priced since byte 46 value B states you may only extend beyond an original destination terminal point. Sequence 4 – The itinerary MAY NOT be re-priced since byte 46 value Blank states previously ticketed fare cannot be re-priced to a further point.

Example 3

Original Ticket MSP-TYO-BKK is fully flown: 2 fare components

Original Itinerary: MSP TYO BKK New Itinerary: MSP BKK SEL

Sequence 1 - The itinerary MAY be re-priced since byte 46 value X states one point on the previous fare component must be included in the new fare component. Sequence 2 – The itinerary MAY be re-priced since byte 46 value Y states any previous fare break points may be revised. Sequence 3 – The itinerary MAY NOT be re-priced since byte 46 value B states you may only extend beyond an original destination terminal point. BKK-SEL is a new fare component. Sequence 4 – The itinerary MAY NOT be re-priced since byte 46 value Blank states previously ticketed fare cannot be re-priced to a further point.

Page E.03.31.238 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 4

Original Ticket MSP-TYO-BKK is fully flown: 2 fare components

Original Itinerary: MSP TYO BKK New Itinerary: SIN MSP TYO BKK SEL

Sequence 1 - The itinerary MAY be re-priced since byte 46 value X states one point on the previous fare component must be included in the new fare component. Sequence 2 – The itinerary MAY be re-priced since byte 46 value Y states any previous fare break points may be revised. Sequence 3 – The itinerary MAY NOT be re-priced since byte 46 value B states you may only extend beyond an original destination terminal point. Sequence 4 – The itinerary MAY NOT be re-priced since byte 46 value Blank states previously ticketed fare cannot be re-priced to a further point.

Page E.03.31.239 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.3.5. Same Point Table No. 993 (bytes 48-55)

The Same Point Table 993 specifies a table number, which refers to a table containing two cities that are considered the same point. The cities specified in Table 993 represent the Origin and/or Destination cities of the fare component being validated. This data is validated when the Origin and/or Destination points of the previous fare component are different than the Origin and/or Destination points of the new fare component. Processing will compare the fare break points of the previous fare component to the fare break points of the new fare component. If either or both fare break points on the previous fare component are different on the new fare component, then processing will retrieve the Table 993 data. Process will attempt to match the previous fare break point to one of the cities in a Table 993 entry. If a match is made to one of the cities, then determine if the corresponding city in the Table 993 entry matches the new fare break point. If the corresponding city matches the new fare break point, then these cities are considered the same point and a change to the fare break point has not occurred. Processing may re-price the fare component to a different city that is considered the same point. If processing cannot match the previous fare break point to any city in the Table 993 entry, or if a match is made to a city but the corresponding city does not match the new fare break point, then a change to the fare break point has occurred. When this field is value 0000000, no same point data applies.

Page E.03.31.240 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example

Table 988 Bytes 21-22 Byte 24 Byte 43 Bytes 48-55 Process Tag Portion Term Same Point Table 993 City 1 City 2 02 BLANK BLANK WAS BWI EWR NYC The data indicates to re-price using Process Tag 02. Changes to fare break points are not permitted on the fare component. WAS and BWI are considered the same point, and NYC and EWR are considered the same point.

Original Itinerary A: NYC LON (NYC-LON-NYC RT)

Passenger has traveled to LON and requests the following new itinerary: NYC LON EWR

Assume the original fare components resolve to above Table 988: • Match the Table 988 sequence. • Changes to fare break points are not permitted. • NYC matches to City 2 in the second Table 993 segment, and EWR matches to City 1 in the second Table 993 segment. NYC and EWR are considered the same point; therefore, no change to fare break point has occurred. • The new itinerary is permitted and will be re-priced using historical fares.

Page E.03.31.241 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Original Itinerary B: NYC LON (NYC-LON-NYC RT)

Passenger has traveled to LON and requests the following new itinerary: NYC LON BOS

Assume the original fare components resolve to above Table 988: • Match the Table 988 sequence. • Changes to fare break points are not permitted. • NYC matches to City 2 in the second Table 993 segment, but BOS does not match to City 1 in the second Table 993 segment. NYC and BOS are not considered the same point; therefore, a change to the fare break point has occurred. • The new itinerary is not permitted according to this Table 988 sequence.

Original Itinerary C: NYC LON (NYC-LON-NYC RT)

Passenger has traveled to LON and requests to change the departure date from LON: NYC LON

Assume the original fare components resolve to above Table 988: • Match the Table 988 sequence. • Changes to fare break points are not permitted. • NYC matches to City 2 in the second Table 993 segment. Processing is permitted to re-price the LON-NYC fare component as a LON-EWR fare component if necessary. NYC and EWR are considered the same point, and this re-price would not result in a change to a fare break point. The new itinerary will be re-priced using historical fares.

Page E.03.31.242 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.4. Fares (Table 988 bytes 57-88, 111-112, 138-145, and 214-221)

The data in the Fares fields (Table 988 bytes 57-88, 111-112, 138-145, and 214-221) specifies restrictions for fares which may or may not be used when re-pricing the itinerary. Processing will apply the Process Tag (Table 988 bytes 21-22) definition, indicating the type of fares to use during the re-price: Keep the Fares, Historical Fares, or Current Fares. The Fares fields (Table 988 bytes 57-88, 111- 112, 138-145, and 214-221) further define what type of fares may be selected for re-pricing.

The application of the Fares fields (Table 988 bytes 57-88, 111-112, 138-145, and 214-221) with the Re-Price Requirements from the Process Tags is as follows:

Re-Price Application of Fares Fields Requirement Keep the Fares Re-price by selecting fares from the historical database that have the same fare owner, rule, and tariff as the previously ticketed fare, within the restrictions specified by the Expand Keep field (Table 988 byte 112) and Seasonality/Day of Week Indicator Table 966 (Table 988 bytes 138-145). All other Fares fields (Table 988 bytes 57-88, 111, and 214-221) will have no application.

Historical Fares Re-price by selecting fares from the historical database, within the restrictions specified by the Fares fields (Table 988 bytes 57-88, 111, and 214-221). The Expand Keep field (Table 988 byte 112) and Seasonality/Day of Week Indicator Table 966 (Table 988 bytes 138-145) will have no application.

Current Fares Re-price by selecting fares from the current database, within the restrictions specified by the Fares fields (Table 988 bytes 57-88, 111, and 214-221). The Expand Keep field (Table 988 byte 112) and Seasonality/Day of Week Indicator Table 966 (Table 988 bytes 138-145) will have no application.

Cancel and Start Over Processing will ignore any data present in the Fares fields (Table 988 bytes 57-88, 111-112, 138-145, and 214- 221).

The Fare section consists of the following fields: 4.5.4.1 Rule Indicator (Table 988 byte 57) 4.5.4.2 Carrier Application Table 990 (Table 988 bytes 58-65)

Page E.03.31.243 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.4.3 Exclude Private/Public Indicator (Table 988 byte 111 4.5.4.4 Rule Number (Table 988 bytes 69-72) 4.5.3.6.1 Indicator and Fare Class Code (Table 988 bytes 73 and 74-81) 4.5.4.5.2 Fare Type Code (Table 988 bytes 82-84) 4.5.3.6.3 Fare Type Table 974 (Table 988 bytes 214-221) 4.5.4.5.4 Same (Table 988 byte 85) 4.5.4.6 Fare Amount (Table 988 byte 86) 4.5.4.7 Normal/Special (Table 988 byte 87) 4.5.4.8 OW/RT (Table 988 byte 88) 4.5.4.9 Expand Keep (Table 988 byte 112) 4.5.4.9 Seasonality /Day of Week Indicator Table 966 (Table 988 bytes 138-145)

The relationship among data in the Fare fields is AND. Validation of these fields is against the fare component, unless otherwise specified in the following sections.

Page E.03.31.244 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.4.1. Rule Indicator (byte 57)

The Rule Indicator field specifies the rule number where the replacement fare must be found. Applicable values in byte 57 follow:

Value R Replacement fare must be in the rule number specified in bytes 69-72. Edits require that Rule Indicator byte 57 be value R when Rule Number bytes 69-72 contain data.

Value S Replacement fare must be in the same rule number as the previous fare on the fare component being validated.

Value N Replacement fare must not be in the same rules number as the previous fare on the fare component being validated.

Value Blank Replacement fare may be in any rule number.

Processing will determine the previous fare for the fare component being validated and re-price the new fare component by selecting fares within the rule number specified by Rule Indicator byte 57 and Rule Number bytes 69-72. When both fare break points on the new fare component are the same as the fare break points on the previous fare component, the repricing restrictions specified by Rule Indicator (byte 57) apply only to the fare component being validated. When one or both fare break points on the new fare component are different from the fare break points on the previous fare component, then the repricing restrictions specified by Rule Indicator (byte 57) apply to the fare component determined using the logic described in Section 4.10, Fare Break/Journey Validation.

Page E.03.31.245 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example

Table 988 Bytes 21-22 Byte 43 Byte 57 Process Tag Term Rule Indicator 02 Y S The data indicates to re-price using Process Tag 02. Changes to fare break points are permitted on the fare component. Replacement fares for the fare component being validated must be in the same rule number as the previous fare.

Original Itinerary: 50% of YAPNR fare (IPRA rule 2100) NYC LON (NYC-LON-NYC RT) 50% of BHAP fare (IPRA rule 3000)

Passenger would like to change the return date from LON: Assume the NYC-LON YAPNR fare component resolves to above Table 988: • Match the Table 988 sequence. • Re-price the NYC-LON fare component using historical fares from the same rule number as the YAPNR fare (rule 2100). NOTE: Processing must still validate Voluntary Change data for the LON-NYC BHAP fare component.

Passenger would like to change turnaround point from LON to PAR: Assume the NYC-LON YAPNR fare component resolves to above Table 988: • Match the Table 988 sequence. • Changing LON to PAR is a change to a fare break point which is permitted per value Y in byte 43. • Price the new NYC-PAR fare component using historical fares from the same rule number as the YAPNR fare (rule 2100). • Because there is a change to a fare break point, processing must also price the new PAR-NYC fare component using historical fares from the same rule number as the YAPNR fare (rule 2100) NOTE: Processing must still validate Voluntary Change data for the LON-NYC BHAP fare component.

Page E.03.31.246 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.4.2. Carrier Application Table 990 (bytes 58-65)

The Carrier Application Table 990 specifies a table number which refers to a table containing carrier code(s). Carrier codes in Table 990 may be expressed as a positive or negative application. These carrier codes specify the governing carrier fares that are or are not permitted to be used when re-pricing the fare component being validated. This data validates against: • The carrier whose code appears on the fare record or • The carrier whose code appears on the Category 25 Record 2 or • IATA/YY fares in which the carrier participates and is the carrier providing transportation on the primary portion of travel. Determination of the primary portion of travel is based on standards set forth in IATA Resolutions. The Resolutions allow for two possible primary portions of travel (based on dual fare selection criteria in the Resolutions). In this scenario, the primary portion of travel will be the portion against which the pricing system was selecting/applying YY fares in lieu of carrier- specific fares.

Example: MEL-TYO fare component Travel is: MEL-XX-JKT-DD-TYO

• When attempting to select XX MEL-TYO through fares, if no carrier-specific fares,then processing will select YY fares. In this scenario, MEL-JKT is considered the primary portion of travel. Carrier XX is the carrier providing transportation on the primary portion of travel. • When attempting to select DD MEL-TYO through fares, if no carrier-specific fares, then processing will select YY fares. In this scenario, JKT-TYO is considered the primary portion of travel. Carrier DD is the carrier providing transportation on the primary portion of travel.

When this field is value 0000000, the new fare must be governed by the carrier whose code appeared on the fare record of the previous fare component being validated as indicated above. NOTE: Re-pricing engines will ignore any instances of YY coded within the Carrier Application Table 990.

When both fare break points on the new fare component are the same as the fare break points on the previous fare component, the repricing restrictions specified by Carrier Application Table 990 (bytes 58-65) apply only to the fare component being validated. When one or both fare break points on the new fare component are different from the fare break points on the previous fare

Page E.03.31.247 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

component, then the repricing restrictions specified by Carrier Application Table 990 (bytes 58-65) apply to the fare component determined using the logic described in Section 4.10, Fare Break/Journey Validation.

Page E.03.31.248 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example

Table 988 Bytes 21-22 Byte 43 Byte 57 Bytes 58-65 Process Tag Term Rule Indicator CXR Appl Table 990 Appl CXR 02 Y S BLANK NW BLANK KL The data indicates to re-price using Process Tag 02. Changes to fare break points are permitted on the fare component. Replacement fares for the fare component being validated must be NW fares in the same rule number as the previous fare or KL fares in the same rule number as the previous fare.

Original Itinerary: 50% of YAPNR fare (IPRA NW rule 2100) NYC LON (NYC-LON-NYC RT) 50% of BHAP fare (IPRA NW rule 3000)

Passenger would like to change the return date from LON: Assume the NYC-LON YAPNR fare component resolves to above Table 988: • Match the Table 988 sequence. • Re-price the NYC-LON fare component using historical fares for NW in rule 2100 or historical fares for KL in rule 2100. NOTE: Processing must still validate Voluntary Change data for the LON-NYC BHAP fare component.

Page E.03.31.249 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Passenger would like to change turnaround point from LON to PAR: Assume the NYC-LON YAPNR fare component resolves to above Table 988: • Match the Table 988 sequence. • Changing LON to PAR is a change to a fare break point which is permitted per value Y in byte 43. • Price the new NYC-PAR fare component using historical fares for NW in rule 2100 or historical fares for KL in rule 2100. • Because there is a change to a fare break point, processing must also price the new PAR-NYC fare component using historical fares from the same rule number as the YAPNR fare (rule 2100) NOTE: Processing must still validate Voluntary Change data for the LON-NYC BHAP fare component.

Page E.03.31.250 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.4.3. Tariff Number (bytes 66-68) and Exclude Public/Private Indicator (byte 111)

The Tariff Number field identifies the rule tariff number under which the replacement fares must be governed. When data is present in bytes 66-68, the replacement fare for the fare component being validated must be governed by a rule in the specified rule tariff. This data validates as an exact match to the Rule Tariff Number on the Record 1 of the new fare or as a match to the Fare Tariff Number on the Fare Record of the new fare using the G16 Tariff Translation product or other means of matching fare tariff to corresponding rule tariff.

When both fare break points on the new fare component are the same as the fare break points on the previous fare component, the repricing restriction specified by Tariff Number (bytes 66-68) applies only to the fare component being validated. When one or both fare break points on the new fare component are different from the fare break points on the previous fare component, then the repricing restriction specified by Tariff Number (bytes 66-68) applies to the fare component determined using the logic described in Section 4.10, Fare Break/Journey Validation.

This field identifies the Rule Tariff Number under which the fares used for re-pricing must be governed. An explanation of applicable values follows:

Value 001-999: Specified Tariff/Same Tariff. The re-price fare must be governed by the specified ATPCO Tariff Number or the same ATPCO Tariff Number as the fare component being validated, as further described below. It is assumed that the re-price fare may always come from the same tariff as the fare for the fare component being validated, as well as the specified tariff.

The re-price fare must be governed by the ATPCO Tariff Number specified in bytes 66-68. Data in bytes 66-68 is an exact match to the ATPCO Rule Tariff Number on the Record 1 or Category 25 Record 2, or the ATPCO Fare Tariff Number on the Fare Record (via the G16 Tariff Translation product) for the re-price fare.

---Or---

Page E.03.31.251 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

The re-price fare must be governed by the Same ATPCO Tariff Number as the fare for the fare component being validated. Processing will match the ATPCO Rule Tariff Number on the Record 1 or Category 25 Record 2, or ATPCO Fare Tariff Number on the Fare Record for the fare component being validated to the ATPCO Rule Tariff Number on the Record 1 or Category 25 Record 2, or the ATPCO Fare Tariff Number on the Fare Record (via the G16 Tariff Translation product) for the re-price fare. If the tariff is an ATPCO Public Tariff Number, then the re- price fare must be governed by the same ATPCO Public Tariff Number. If the tariff is an ATPCO Private Tariff Number, then the re-price fare must be governed by the same ATPCO Private Tariff Number.

Value 000: Any Tariff. Application is dependent upon whether the Tariff Number for the fare component being validated is private or public, as follows: • If the tariff is an ATPCO Public Tariff Number, then the re-price fare must be governed by any ATPCO Public Tariff Number (unless otherwise specified in Indicator byte 111) • If the tariff is an ATPCO Private Tariff Number, then the re-price fare must be governed by any ATPCO Public Tariff Number or any qualified ATPCO Private Tariff Number. (Qualified is defined as a Tariff that the re- pricing system is authorized to receive and use for selling purposes. The passenger must also be authorized to use the fares in the tariff.)

Page E.03.31.252 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Exclude Public/Private Indicator (byte 111)

This field is used to indicate whether fares governed by ATPCO Private or ATPCO Public tariffs should be considered during a re- price. (Note that some type of qualifying data in the pricing entry may be required in order to allow processing to resolve to private tariffs. This may differ among pricing systems.) The Exclude Public/Private field (Category 31 Table 988 byte 111) only applies if the Tariff Number field (Category 31 Table 988 bytes 66-68) is value 000.

Valid values and processing are as follows:

Value X Processing will apply as follows: ● If the previous fare is governed by an ATPCO public tariff, then the replacement fare must be governed by any ATPCO public tariff, even if the passenger otherwise qualifies for private fares. ● If the previous fare is governed by an ATPCO private tariff, then the replacement fare must be governed by any ATPCO private tariff, even if the passenger otherwise qualifies for public fares. Value blank No restriction

When both fare break points on the new fare component are the same as the fare break points on the previous fare component, the repricing restriction specified by Exclude Public/Private (byte 111) applies only to the fare component being validated. When one or both fare break points on the new fare component are different than the fare break points on the previous fare component, then the repricing restriction specified by Exclude Public/Private (byte 111) applies to the fare component determined using the logic described in Section 4.10, Fare Break Changes/Journey Validation.

Page E.03.31.253 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1

Record 2 = US Zone 210 Table 988 Bytes 21-22 Byte 43 Byte 57 Bytes 58-65 Bytes 66-68 Byte 111 Process Tag Term Rule Indicator CXR Appl Table Tariff Nbr Exclude Public/Private 990 Indicator 02 Y BLANK 0000000 001 (IPRA) BLANK The data indicates that for fares between the United States and Europe, re-price the itinerary using Process Tag 02. Changes to fare break points are permitted on the fare component. Replacement fares for the fare component being validated must be published by the same carrier as the previous fare and may be governed by any rule number in tariff 001 (IPRA).

Original Itinerary (CHI-NYC-CHI RT End-on-End with NYC-LON-NYC RT) 50% of YAPNR fare 50% of YEE fare CHI NYC LON 50% of BHAP 50% of QEE6M fare

Fare information: Fare Class Market Publishing Tariff Rule CXR YAPNR CHI-NYC AA 011 (DFR) 4035 BHAP NYC-CHI AA 011 (DFR) 4165 YEE NYC-LON BA 001 (IPRA) 2020 QEE6M LON-NYC BA 001 (IPRA) 3000

Passenger would like to change the departure date from NYC: Assume the NYC-LON YEE fare component resolves to above Table 988: • Match the Table 988 sequence. • Re-price the NYC-LON fare component using historical fares for BA from any rule number in tariff 001 (IPRA). NOTE: Processing must still validate Voluntary Change data for the LON-NYC QEE6M, CHI-NYC YAPNR, and NYC-CHI BHAP fare components.

Page E.03.31.254 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Passenger would like to change NYC to be WAS: Assume the NYC-LON YEE fare component resolves to above Table 988: • Match the Table 988 sequence. • Changing NYC to WAS is a change to a fare break point which is permitted per value Y in byte 43. • Price the new WAS-LON fare component using historical fares for BA from any rule number in tariff 001 (IPRA). • Because there is a change to a fare break point, processing must also price the new LON-WAS, CHI-WAS, and WAS-CHI fare components using historical fares for BA from any rule number in tariff 001 (IPRA). • CHI-WAS and WAS-CHI fares are not published in tariff 001; therefore, processing will not be able to find any fares to re-price these fare components. Processing will fail the Table 988 sequence and continue processing to the next sequence and/or Record 3 Table. NOTE: Processing must still validate Voluntary Change data for the LON-NYC QEE6M, CHI-NYC YAPNR, and NYC-CHI BHAP fare components.

Page E.03.31.255 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2

Record 2 = US Zone 210 Table 988 Bytes 21-22 Byte 43 Byte 57 Bytes 58-65 Bytes 66-68 Byte 111 Process Tag Term Rule Indicator CXR Appl Table Tariff Nbr Exclude Public/Private 990 Indicator 02 Y BLANK 0000000 000 blank The data indicates that for fares between the United States and Europe, re-price the itinerary using Process Tag 02. Changes to fare break points are permitted on the fare component. Replacement fares for the fare component being validated must be published by the same carrier as the previous fare and may be governed by any rule number in any public or qualified private tariff.

Original Itinerary (CHI-NYC-CHI RT End-on-End with NYC-LON-NYC RT) 50% of YAPNR fare 50% of YEE fare CHI NYC LON 50% of BHAP 50% of QEE6M fare

Fare information: Fare Class Market Publishing Tariff Rule CXR YAPNR CHI-NYC AA 011 (DFR) 4035 BHAP NYC-CHI AA 011 (DFR) 4165 YEE NYC-LON BA 001 (IPRA) 2020 QEE6M LON-NYC BA 001 (IPRA) 3000

Passenger would like to change the departure date from NYC: Assume the NYC-LON YEE fare component resolves to above Table 988: • Match the Table 988 sequence. • Re-price the NYC-LON fare component using historical fares for BA from any rule number in any public or qualified private tariff.

Page E.03.31.256 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

NOTE: Processing must still validate Voluntary Change data for the LON-NYC QEE6M, CHI-NYC YAPNR, and NYC-CHI BHAP fare components.

Passenger would like to change NYC to be WAS: Assume the NYC-LON YEE fare component resolves to above Table 988: • Match the Table 988 sequence. • Changing NYC to WAS is a change to a fare break point which is permitted per value Y in byte 43. • Price the new WAS-LON fare component using historical fares for BA from any rule number in any public or qualified private tariff. • Because there is a change to a fare break point, processing must also price the new LON-WAS, CHI-WAS, and WAS-CHI fare components using historical fares for BA from any rule number in any public or qualified private tariff. • CHI-WAS and WAS-CHI fares will match the provisions and the table will pass. NOTE: Processing must still validate Voluntary Change data for the LON-NYC QEE6M, CHI-NYC YAPNR, and NYC-CHI BHAP fare components.

Page E.03.31.257 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.4.4. Rule Number (bytes 69-72)

The Rule Number field identifies the rule number under which the replacement fares must be governed. When data is present in bytes 69-72, the replacement fare for the fare component being validated must be governed the specified rule number. Edits require that Rule Indicator byte 57 be value R when Rule Number bytes 69-72 contain data. The Rule Number validates as an exact match to the Rule Number on the Fare Record of the new fare or to the Rule Number on the Record 1 of the new fare. When the Rule Number field is blank, the new fare may be governed under any rule number.

When both fare break points on the new fare component are the same as the fare break points on the previous fare component, the repricing restriction specified by Rule Number (bytes 69-72) applies only to the fare component being validated. When one or both fare break points on the new fare component are different from the fare break points on the previous fare component, then the repricing restriction specified by Rule Number (bytes 69-72) applies to the fare component determined using the logic described in Section 4.10, Fare Break/Journey Validation.

The presence of a rule range value in bytes 69-72, indicated by a two digit alphanumeric followed by two asterisks (RR**), specifies that the value (tariff number or value 000) contained in bytes 66-68 is a rule-restricted tariff. Therefore the replacement fare must be found in a rule number within the indicated rule range. For example, if the rule number in byte 69-72 was value 20**, the replacement fare must be found within a rule that starts with the digits 20.

Page E.03.31.258 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example

Record 2 = ATL BOS Table 988 Bytes 21-22 Byte 43 Byte 57 Bytes 58-65 Bytes 66-68 Bytes 69-72 Process Tag Term Rule Indicator CXR Appl Table Tariff Nbr Rule Nbr 990 02 Y R 0000000 000 4030 The data indicates that for fares between the ATL and BOS, re-price the itinerary using Process Tag 02. Changes to fare break points are permitted on the fare component. Replacement fares for the fare component being validated must be published by the same carrier as the previous fare and must be governed by rule number 4030 in the same tariff as the previous fare.

Original Itinerary (3 Component Circle Trip) ATL BOS

LAX

New Itinerary ATL LAX

Assume the ATL-BOS fare component resolves to above Table 988: • Match the Table 988 sequence. • Removing BOS is a change to a fare break point which is permitted per value Y in byte 43. • Price the new ATL-LAX fare component using historical fares governed under rule 4030 for the same tariff and carrier as the previous ATL-BOS fare. • Because there is a change to a fare break point, processing must also price the new LAX-ATL fare component using historical fares governed under rule 4030 for the same tariff and carrier as the previous ATL-BOS fare. (Note if ATL to BOS fare break points existed in the new itinerary, the restrictions above would have only been applied to the ATL to BOS fare component NOTE: Processing must still validate Voluntary Change data for the BOS-LAX and LAX-ATL fare components.

Page E.03.31.259 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.4.5. Fare Type/Fare Class (bytes 73-85 and bytes 214-221)

The Fare Type/Fare Class fields identify the fare class code and/or fare type code of the replacement fare. When data is present in these fields, the replacement fare for the fare component being validated must meet the specified fare class/fare type requirements. When these fields are blank, the new fare may be any fare class code and fare type code.

When both fare break points on the new fare component are the same as the fare break points on the previous fare component, the repricing restrictions specified by Fare Type/Fare Class (bytes 73-85 and bytes 214-221) apply only to the fare component being validated. When one or both fare break points on the new fare component are different from the fare break points on the previous fare component, then the repricing restrictions specified by Fare Type/Fare Class (bytes 73-85 and bytes 214-221) apply to the fare component determined using the logic described in Section 4.10, Fare Break/Journey Validation.

4.5.4.5.1. Indicator (byte 73) and Fare Class Code (bytes74-81) The Indicator and Fare Class Code fields identify the fare class (or generic fare class) of the new fare that must be used for re-pricing the fare component being validated. These fields validate against the fare class code on the Fare Record or Record 1 or Category 25 Record 3 of the new fare.

The Indicator field defines type of data entered in Fare Class Bytes 74-81. When the indicator field is value F, the data in bytes 74-81 is a Fare Class Code, consisting of a 1 to 8 digit alphanumeric. When the indicator field is value M, the data in bytes 74-81 is a Fare Family. When the indicator field is value S, the data in bytes 74-81 represents a fare class code beginning with the second position of the fare class code (data consists of a 1 to 7 digit alpha-numeric). When the indicator and fare class fields are value Blank, there is no restriction on the fare class code of the fare to be used for re- pricing.

Page E.03.31.260 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1 (Value F)

Table 988 Bytes 21-22 Byte 43 Byte 57 Bytes 58-65 Bytes 66-68 Bytes 69-72 Byte 73 Bytes 74-81 Process Tag Term Rule Indicator CXR Appl Table Tariff Nbr Rule Nbr Indicator Fare Class 990 02 BLANK R 0000000 000 4030 F YHXAP6M The data indicates to re-price the itinerary using Process Tag 02. Changes to fare break points are not permitted on the fare component. Replacement fares for the fare component being validated must be published by the same carrier as the previous fare, must be governed by rule number 4030 in the same tariff as the previous fare, and must be YHXAP6M fare class.

Original Itinerary: 50% of YAPNR fare (IPRA NW rule 4030) NYC LON (NYC-LON-NYC RT) 50% of BHAP fare (IPRA NW rule 3000)

Passenger would like to change the departure date from NYC: Assume the NYC-LON YAPNR fare component resolves to above Table 988: • Match the Table 988 sequence. • Re-price the NYC-LON fare component using historical YHXAP6M fare for NW in IPRA rule 4030. NOTE: Processing must still validate Voluntary Change data for the LON-NYC BHAP fare component. • Assuming the following fares exist in IPRA-NW-4030: Fare Class Code Fare Type Code BAP XAP YHXAP6M XAP YLXAP6M XAP Processing may re-price using the YHXAP6M fare.

Page E.03.31.261 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2 (Value M)

Table 988 Bytes 21-22 Byte 43 Byte 57 Bytes 58-65 Bytes 66-68 Bytes 69-72 Byte 73 Bytes 74-81 Process Tag Term Rule Indicator CXR Appl Table 990 Tariff Nbr Rule Nbr Indicator Fare Class 02 BLANK R 0000000 000 4030 M – APNR The data indicates to re-price the itinerary using Process Tag 02. Changes to fare break points are not permitted on the fare component. Replacement fares for the fare component being validated must be published by the same carrier as the previous fare, must be governed by rule number 4030 in the same tariff as the previous fare, and must be –APNR fare family.

Original Itinerary: 50% of YAPNR fare (IPRA NW rule 4030) NYC LON (NYC-LON-NYC RT) 50% of BHAP fare (IPRA NW rule 3000)

Passenger would like to change the departure date from NYC: Assume the NYC-LON YAPNR fare component resolves to above Table 988: • Match the Table 988 sequence. • Re-price the NYC-LON fare component using historical –APNR fares for NW in IPRA rule 4030. NOTE: Processing must still validate Voluntary Change data for the LON-NYC BHAP fare component. • Assuming the following fares exist in IPRA-NW-4030: Fare Class Code Fare Type Code BAP XAP BAPNR XAN LKXAPNR XAN YHAP XAP YHAPNR XAN Processing may re-price using the BAPNR, LKXAPNR, and YHAPNR fares.

Page E.03.31.262 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3 (Value S)

Table 988 Bytes 21-22 Byte 43 Byte 57 Bytes 58-65 Bytes 66-68 Bytes 69-72 Byte 73 Bytes 74-81 Process Tag Term Rule Indicator CXR Appl Table 990 Tariff Nbr Rule Nbr Indicator Fare Class 02 BLANK R 0000000 000 4030 S APNR The data indicates to re-price the itinerary using Process Tag 02. Changes to fare break points are not permitted on the fare component. Replacement fares for the fare component being validated must be published by the same carrier as the previous fare, must be governed by rule number 4030 in the same tariff as the previous fare, and must be, and must be a fare class code where the second through last characters are APNR.

Original Itinerary: 50% of YAPNR fare (IPRA NW rule 4030) NYC LON (NYC-LON-NYC RT) 50% of BHAP fare (IPRA NW rule 3000)

Passenger would like to change the departure date from NYC: Assume the NYC-LON YAPNR fare component resolves to above Table 988: • Match the Table 988 sequence. • Re-price the NYC-LON fare component using historical fares for NW in IPRA rule 4030 where the second through last character of the fare class code is APNR. NOTE: Processing must still validate Voluntary Change data for the LON-NYC BHAP fare component.

Page E.03.31.263 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

• Assuming the following fares exist in IPRA-NW-4030: Fare Class Code Fare Type Code BAP XAP BAPNR XAN BAPNR2 XAN BHAPNR XAN KAPNR XAN QAPNR XAN Processing may re-price using the BAPNR, KAPNR, and QAPNR fares.

4.5.4.5.2. Fare Type Code (bytes 82-84) The Fare Type Code field identifies the ATPCO fare type code of the new fare that must be used for re-pricing the fare component being validated. The field validates against the Record 1 Fare Type Code field (Rec 1 bytes 78-80) or Category 25 Record 3 of the new fare.

NOTE: Either the Fare Type Code (bytes 82-84) or Fare Type Table 974 (bytes 214-221) fields may be used to specify the acceptable Fare Type Code(s) of the new fare, but not both. Edits prevent data from appearing in both fields.

Page E.03.31.264 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1 (Fare Class Fields Blank)

Table 988 Bytes 21-22 Byte 43 Byte 57 Bytes 58-65 Bytes 66- Bytes 69-72 Byte 73 Bytes 74-81 Bytes 82-84 Process Tag Term Rule Indicator CXR App Tbl 68 Rule Nbr Ind Fare Class Fare Type 990 Tariff Nbr 02 BLANK R 0000000 000 4030 BLANK BLANK XAP The data indicates to re-price the itinerary using Process Tag 02. Changes to fare break points are not permitted on the fare component. Replacement fares for the fare component being validated must be published by the same carrier as the previous fare, must be governed by rule number 4030 in the same tariff as the previous fare, and must have XAP fare type code.

Original Itinerary: 50% of YAPNR fare (IPRA NW rule 4030) NYC LON (NYC-LON-NYC RT) 50% of BHAP fare (IPRA NW rule 3000)

Passenger would like to change the departure date from NYC: Assume the NYC-LON YAPNR fare component resolves to above Table 988: • Match the Table 988 sequence. • Re-price the NYC-LON fare component using historical fares for NW in IPRA rule 4030 with fare type XAP. NOTE: Processing must still validate Voluntary Change data for the LON-NYC BHAP fare component. • Assuming the following fares exist in IPRA-NW-4030: Fare Class Code Fare Type Code BAP XAP BA21 XAP BAPNR XAN LKXAPNR XAN YHAP XAP Processing may re-price using the BAP, BA21, and YHAP fares.

Page E.03.31.265 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2 (Fare Class Fields coded)

Table 988 Bytes 21-22 Byte 43 Byte 57 Bytes 58-65 Bytes 66- Bytes 69-72 Byte 73 Bytes 74-81 Bytes 82-84 Process Tag Term Rule Indicator CXR App Tbl 68 Rule Nbr Ind Fare Class Fare Type 990 Tariff Nbr 02 BLANK R 0000000 000 4030 M – AP XAP The data indicates to re-price the itinerary using Process Tag 02. Changes to fare break points are not permitted on the fare component. Replacement fares for the fare component being validated must be published by the same carrier as the previous fare, must be governed by rule number 4030 in the same tariff as the previous fare, and must be –AP fare family with XAP fare type code.

Original Itinerary: 50% of YAPNR fare (IPRA NW rule 4030) NYC LON (NYC-LON-NYC RT) 50% of BHAP fare (IPRA NW rule 3000)

Passenger would like to change the departure date from NYC: Assume the NYC-LON YAPNR fare component resolves to above Table 988: • Match the Table 988 sequence. • Re-price the NYC-LON fare component using historical fares for NW in IPRA rule 4030 in –AP fare family with fare type XAP. NOTE: Processing must still validate Voluntary Change data for the LON-NYC BHAP fare component. • Assuming the following fares exist in IPRA-NW-4030: Fare Class Code Fare Type Code BAP XAP BA21 XAP BAPNR XAN LKXAPNR XAN YHAP XAP Processing may re-price using the BAP and YHAP fares.

Page E.03.31.266 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Page E.03.31.267 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.4.5.3. Fare Type Table 974 (Table 988 bytes 214-221)

The Fare Type Table 974 indicates whether the replacement fare must or must not be of a specific Fare Type Code(s). When the Fare Type Table 974 field (Table 988 bytes 214-221) is value 0000000, it places no restrictions on the Fare Type Code of the replacement fare.

NOTE: Either the Fare Type Code (bytes 82-84) or Fare Type Table 974 (bytes 214-221) fields may be used to specify the acceptable Fare Type Code(s) of the new fare, but not both. Edits prevent data from appearing in both fields.

A Fare Type Table 974 may consist of up to twelve recurring segments, and each recurring segment will contain an Application Tag (Fare Type Table 974 byte 16) and a Fare Type Code (Fare Type Table 974 bytes 17-19). The Application Tag (Fare Type Table 974 Byte 16) is used to indicate whether a positive or negative application applies to the Fare Type code(s) specified within the Fare Type Table 974.

Negative Application Tag (Fare Type Table 974 Byte 16 = N) When the Application Tag is negative, the Fare Type Code of the replacement fare may be any fare type other than that specified in the Fare Type Code field (Fare Type Table 974 Bytes 17-19). The Fare Type Code (Fare Type Table 974 Bytes 17-19) is validated against the Fare Type Code on the Record 1 or Category 25 Record 3 of the replacement fare.

When multiple recurring segments are present, the segments share an AND relationship. Processing must validate all recurring segments, and none of the Fare Type Codes specified in the segments are permitted for the replacement fare. All Fare Type Codes that are not specified in any negative recurring segment are permitted.

Positive Application Tag (Fare Type Table 974 Byte 16 = Blank) When the Application Tag is positive, the Fare Type Code of the replacement fare must be the fare type specified in the Fare Type Code field (Fare Type Table 974 Bytes 17-19). The Fare Type Code (Fare Type Table 974 Bytes 17-19) is validated against the Fare Type Code on the Record 1 or Category 25 Record 3 of the replacement fare.

When multiple recurring segments are present, the segments share an OR relationship. The Fare Type Code for the replacement fare must match the Fare Type Code in one of the Fare Type Table 974 segments.

Page E.03.31.268 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

When both fare break points on the new fare component are the same as the fare break points on the previous fare component, the re- pricing restrictions specified by Fare Type Table 974 (bytes 214-221) apply only to the fare component being validated. When one or both fare break points on the new fare component are different from the fare break points on the previous fare component, then the re- pricing restrictions specified by Fare Type Table 974 (bytes 214-221) apply to the fare component determined using the logic described in Section 4.10, Fare Break/Journey Validation. Refer to Data Application for Table 974 - Fare Type Table for further information.

Page E.03.31.269 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1 (Fare Class Fields Blank)

Table 988 Bytes 21-22 Byte 43 Byte 57 Bytes 58-65 Bytes 66- Bytes 69-72 Byte 73 Bytes 74-81 Bytes 214-221 Process Tag Term Rule Indicator CXR App Tbl 990 68 Rule Nbr Ind Fare Class Fare Type Tbl 974 Tariff Nbr 02 BLANK R 0000000 000 4030 BLANK BLANK 0056118

Fare Type Table 974 # 0056118 Application Tag Fare Type Code (byte 16) (bytes 17-19) Blank XAP Blank SAP

The data indicates to re-price the itinerary using Process Tag 02. Changes to fare break points are not permitted on the fare component. Replacement fares for the fare component being validated must be published by the same carrier as the previous fare, must be governed by rule number 4030 in the same tariff as the previous fare, and must have a fare type code of either XAP or SAP.

Original Itinerary: 50% of YAPNR fare (IPRA NW rule 4030) NYC LON (NYC-LON-NYC RT) 50% of BHAP fare (IPRA NW rule 3000)

Passenger would like to change the departure date from NYC: Assume the NYC-LON YAPNR fare component resolves to above Table 988: • Match the Table 988 sequence. • Re-price the NYC-LON fare component using historical fares for NW in IPRA rule 4030 with fare type XAP or SAP. NOTE: Processing must still validate Voluntary Change data for the LON-NYC BHAP fare component. • Assuming the following fares exist in IPRA-NW-4030: Fare Class Code Fare Type Code BAP XAP

Page E.03.31.270 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

BA21 SAP BAPNR XAN LKXAPNR XAN YHAP XAP Processing may re-price using the BAP, BA21, and YHAP fares.

Example 2 (Fare Class Fields coded)

Table 988 Bytes 21-22 Byte 43 Byte 57 Bytes 58-65 Bytes 66- Bytes 69-72 Byte 73 Bytes 74-81 Bytes 214-221 Process Tag Term Rule Indicator CXR App Tbl 990 68 Rule Nbr Ind Fare Class Fare Type Tbl 974 Tariff Nbr 02 BLANK R 0000000 000 4030 M – AP 0098566

Fare Type Table 974 # 0056118 Application Tag Fare Type Code (byte 16) (bytes17-19) N SAP

The data indicates to re-price the itinerary using Process Tag 02. Changes to fare break points are not permitted on the fare component. Replacement fares for the fare component being validated must be published by the same carrier as the previous fare, must be governed by rule number 4030 in the same tariff as the previous fare, and must be from the –AP fare family however they may not have a fare type code of SAP.

Original Itinerary: 50% of YAPNR fare (IPRA NW rule 4030) NYC LON (NYC-LON-NYC RT) 50% of BHAP fare (IPRA NW rule 3000)

Passenger would like to change the departure date from NYC: Assume the NYC-LON YAPNR fare component resolves to above Table 988:

Page E.03.31.271 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

• Match the Table 988 sequence. • Re-price the NYC-LON fare component using historical fares for NW in IPRA rule 4030 in –AP fare family but not with fare type SAP. NOTE: Processing must still validate Voluntary Change data for the LON-NYC BHAP fare component. • Assuming the following fares exist in IPRA-NW-4030: Fare Class Code Fare Type Code BAP XAP BAP21 XAP BAPNR XAN Q14AP SAP Processing may re-price using the BAP, BAP21, and BAPNR fares.

4.5.4.5.4. Same (byte 85) The same field indicates that the fare component being validated must be re-priced using the same fare type code or the same fare class code as the previous fare. When byte 85 is value S, then the fare type code of the new fare must be the same fare type code as the previous fare. Validation is against the fare type code on the Record 1 or Category 25 Record 3. Processing will determine the fare type code of the previous fare and re-price using fares with this same fare type code. When byte 85 is value X, then the fare class code of the new fare must be the same fare class code as the previous fare. Validation is against the fare class code on the Fare Record or Record 1 or Category 25 Record 3. Processing will determine the fare class code of the previous fare and re-price using fares with this same fare class code. Edits require that when data is present in byte 85, then the Fare Class/Type fields (bytes 73-84) must be blank. When this field is blank, the itinerary may be re-priced using any fare class or fare type (within the limitations of the other fields in the Table 988 entry).

Page E.03.31.272 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example

Table 988 Bytes 21-22 Byte 43 Byte 57 Bytes 58-65 Bytes 66- Bytes 69-72 Byte 85 Process Tag Term Rule Indicator CXR App Tbl 68 Rule Nbr Same 990 Tariff Nbr 02 Y R 0000000 000 4030 X The data indicates to re-price the itinerary using Process Tag 02. Changes to fare break points are permitted on the fare component. Replacement fares for the fare component being validated must be published by the same carrier as the previous fare, must be governed by rule number 4030 in the same tariff as the previous fare, and must be the same fare class code as the previous fare.

Original Itinerary: 50% of YAPNR fare (IPRA NW rule 4030) NYC LON (NYC-LON-NYC RT) 50% of BHAP fare (IPRA NW rule 3000)

Passenger would like to change the turnaround point from LON to AMS: Assume the NYC-LON YAPNR fare component resolves to above Table 988: • Match the Table 988 sequence. • Change from LON to AMS is a change to a fare break point which is permitted per value Y in byte 43. • Price the new NYC-AMS fare component using historical fares for NW in IPRA rule 4030 with fare class YAPNR (same fare class code as the previous fare). • Because there is a change to a fare break point, processing must also price the new LON-NYC fare component using historical fares for NW in IPRA rule 4030 with fare class YAPNR (same fare class code as the previous NYC-LON fare). NOTE: Processing must still validate Voluntary Change data for the LON-NYC BHAP fare component.

Page E.03.31.273 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.4.6. Fare Amount (byte 86)

The Fare Amount field indicates that when re-pricing the itinerary, the new fares must be of an equal or higher amount than the previous base fare value of the fare component being validated (excluding all taxes, additional fees, and surcharges). When this field is value X, then new fare must be equal to or higher than the previous fare. When this field is value Y, the new fare must be higher than the previous fare. When fare break points on the new fare component are different than fare break points on the previous fare component, processing cannot compare the previous fare to the new fare; therefore, edits require that Term field byte 43 is value Y (changes to fare break points permitted) then Fare Amount field byte 86 must be blank (note that Term field byte 43 value Blank is permitted with any value in byte 86). When this field is value Blank, the new fare may be any fare amount.

Page E.03.31.274 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example

Table 988 Bytes 21-22 Byte 43 Byte 57 Bytes 58-65 Bytes 66- Bytes 69-72 Byte 73 Bytes 74-81 Bytes 82-84 Byte 86 Process Tag Term Rule Ind CXR App Tbl 68 Rule Nbr Ind Fare Class Fare Type Fare Amt 990 Tariff Nbr 02 BLANK R 0000000 000 BLANK M – AP BLANK X The data indicates to re-price the itinerary using Process Tag 02. Changes to fare break points are not permitted on the fare component. Replacement fares for the fare component being validated must be published by the same carrier as the previous fare, must be governed by any rule number in the same tariff as the previous fare, must be –AP fare family, and must be of an equal or higher fare amount.

Original Itinerary: 50% of YAPNR fare (IPRA NW rule 4030 – fare is 800.00 RT) NYC LON (NYC-LON-NYC RT) 50% of BHAP fare (IPRA NW rule 3000 – fare is 700.00 RT)

Passenger would like to change the departure date from NYC: Assume the NYC-LON YAPNR fare component resolves to above Table 988: • Match the Table 988 sequence. • Re-price the NYC-LON fare component using historical fares governed by any NW rule in IPRA in –AP fare family that is equal to or higher than the based fare for the previous YAPNR fare on the NYC-LON fare component. NOTE: Processing must still validate Voluntary Change data for the LON-NYC BHAP fare component. • Assuming the following historical fares exist in IPRA-NW for NYC-LON: Fare Class Code Rule Nbr Fare Amount BAP 3000 850.00 BAPNR 2020 750.00 YEE6M 2000 1000.00 YAPNR 2100 800.00 YH21NR 3310 900.00 Processing may re-price using the BAP and YAPNR fares.

Page E.03.31.275 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.4.7. Normal/Special (byte 87)

The normal/special field indicates whether the new fare used for re-pricing the fare component being validated should be a normal fare or special fare. This field validates against the Record 1 Pricing Category field (Rec 1 byte 83) of the new fare. When this field is value N, then new fare must be a normal fare. When this field is value S, the new fare must be a special fare. When this field is value Blank, the new fare may be a normal fare or special fare (within the limitations of the other fields in the Table 988 entry).

When both fare break points on the new fare component are the same as the fare break points on the previous fare component, the repricing restriction specified by Normal/Special (byte 87) applies only to the fare component being validated. When one or both fare break points on the new fare component are different from the fare break points on the previous fare component, then the repricing restriction specified by Normal/Special (byte 87) applies to the fare component determined using the logic described in Section 4.10, Fare Break/Journey Validation.

4.5.4.8. OW/RT (byte 88)

The One-way/Round Trip field indicates whether the new fare used for re-pricing the fare component being validated should be a one- way fare or a round trip fare. This field validates against the OW/RT field in the Fare Record or Record 1 for the new fare. Value 1 indicates that the new fare must be one-way and validates against value 1 or 3 on the new Fare Record or value 1 on the new Record 1. Value 2 indicates that the new fare must be round trip and validates against value 2 on the new Fare Record or value 2 on the new Record 1. When this field is blank, the new fare may be one-way or round trip (within the limitations of the other fields in the Table 988 entry).

When both fare break points on the new fare component are the same as the fare break points on the previous fare component, the repricing restriction specified by OW/RT (byte 88) applies only to the fare component being validated. When one or both fare break points on the new fare component are different from the fare break points on the previous fare component, then the repricing restriction specified by OW/RT (byte 88) applies to the fare component determined using the logic described in Section 4.10, Fare Break/Journey Validation.

Page E.03.31.276 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Examples of how to apply the limitation fields:

Example 1:

PORTION FLIGHT NEW FARES Byte 23 Byte 43 Byte 56 Bytes 69-72 Bytes 74-81 Bytes 82-84 Byte 86 Stop/Cnx Term Orig Skd Rule Nbr Fare Class Fare Type Fare Amt B BLANK B 4035 BLANK XEX Y In the above example, to be able to use a fare when re-pricing all of the following must be true: 1. In order to match the sequence, there can be no change to the stopover or connection point. 2. There can be no changes to the fare break points, terminal points, or origin/destination points. 3. The change must be made prior to the departure of the previously scheduled flight. 4. The new fare must be from Rule 4035. It is assumed that it must be Rule 4035 in the same Tariff and Carrier. 5. The new fare must be an ATPCO XEX fare type. 6. The new fare must be of a higher amount than the previous fare. NOTE: If no fare can satisfy this condition, then the next Process Tag in the table should be attempted and re-priced based on these criteria. If no Process Tag can be satisfied, then the system assumption applies.

Page E.03.31.277 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2:

PORTION FLIGHT NEW FARES Byte 23 Byte 44 Byte 56 Bytes 69-72 Bytes 74-81 Bytes 82-84 Byte 86 Stop/Cnx 1st Brk Orig Skd Rule Nbr Fare Class Fare Type Fare Amt BLANK Y D BLANK Y2 BLANK BLANK In the above example, to be able to use a fare when re-pricing all of the following must be true: 1. The first fare component on the ticket may not be re-priced using a different fare than previously ticketed. 2. When re-pricing, the new itinerary must be re-priced using a Y2 fare class code published by the same owning carrier as the previously ticketed fare. It is assumed it may be any rule in the same tariff. NOTE: If no fare can satisfy this condition, then the next Process Tag in the table should be tried and re-priced based on the criteria for that table entry. If no Process Tag can be satisfied, then the system assumption applies (Record 3 matched).

Page E.03.31.278 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.4.9. Expand Keep (byte 112) and Seasonality/Day of Week Indicator Table 966 (bytes 138-145)

The Expand Keep field (Table 988 byte 112) is used to further expand the meaning of “Keep the Fare”. It only applies when the Process Tag field (Table 988 bytes 21-22) is coded as Tag 1 – Keep the Fare.

The valid field values are: Value A “Keep the Fare” means any fare that has the same fare owner, rule, and tariff as the previously ticketed fare; provided the fare basis codes are the same, ignoring the seasonality and day of week indicators. For the purposes of this field, Seasonality/Day of Week Indicators are defined in Seasonality/Day of Week Indicator Table 966 (Table 988 bytes 138-145). If no Seasonality/Day of Week Indicator Table 966 is referenced (that is, if bytes 138-145 = 00000000), then Seasonality/Day of Week Indicators are those defined in IATA Resolution 728.

Value B “Keep the Fare” means any fare that has the same fare owner, rule, and tariff as the previously ticketed fare.

Value Blank “Keep the Fare” means any fare which has the same fare owner, rule, tariff, fare basis code, and amount as the previously ticketed fare.

When both fare break points on the new fare component are the same as the fare break points on the previous fare component, the re- pricing restrictions specified by Expand Keep (Table 988 byte 112) apply only to the fare component being validated. When one or both fare break points on the new fare component are different from the fare break points on the previous fare component, then the re- pricing restrictions specified by Expand Keep (Table 988 byte 112) apply to the fare component determined using the logic described in Section 4.10, Fare Break/Journey Validation.

Page E.03.31.279 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

The Seasonality/Day of Week Indicator Table 966 field (Table 988 bytes 138-145) references a table that contains seasonality and day-of-week indicators the fare owning carrier designates in its fare basis codes for the purposes of Expand Keep value A (Table 988 byte 112). When the Season/Day of Week Table 966 (Table 988 bytes 138-145) is value 00000000, this field has no application.

The Indicator A through Indicator Z fields in this table (bytes 14-39) specify which alpha characters in the fare basis code on the previous fare component and on the new fare component are designated as seasonality indicators and which are designated as day-of- week indicators for the purposes of Expand Keep value A (Table 988 byte 112). Refer to Data Application for Seasonality/Day of Week Indicator Table 966 for details.

IATA Resolution 728

The resolution indicates the following: 1st position of a fare basis code is assumed to be the fares prime RBD o nd o 2 position of a fare basis code is assumed to be either the seasonality or day of week indicator(s) if seasonality is not present rd o 3 position of a fare basis code is assumed to be the day of week indicator

IATA Seasonal indicators are: H, J, K, F, T, Q, Y, L IATA Day of Week indicators are: X, W

When the Expand Keep field (Category 31 Table 988 byte 112) is value A and the Seasonality/Day of Week Indicator Table 966 (Table 988 bytes 138-145) is value 00000000, processing will consider any fare whose seasonality and/or day of week indicator(s) (as defined above) are the only portions of the fare basis code which differ from the previous fare as “keep the fare”.

Note: Subscribers are directed to confirm valid seasonal and day of week indicators as described in IATA Resolution 728.

Examples of Applying IATA Resolution 728

Original fare is MHXAP3M; • The second position “H” matches an IATA Seasonality indicator and therefore is considered the seasonality indicator • The third position “X” matches an IATA Day of Week indicator and therefore is considered the day of week indicator

Page E.03.31.280 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Original fare is MXAP3M; • The second position “X” does not match any IATA Seasonality indicators • The second position “X” matches an IATA Day of Week indicator and therefore is considered the day of week indicator

Page E.03.31.281 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1 (Byte 112 = Value A/Bytes 138-145 = Value 00000000):

Both fare components match to the below Table 988

UA DFR RULE 4035 Bytes 21-22 Byte 43 Byte 57 Byte 73 Bytes 74- Bytes 82-84 Byte 85 Bytes 138-145 Byte 112 Process Tag Term Rule Indicator 81 Fare Type Same Seasonality/DOW Expand Keep Ind Fare Class Indicator Table 966 1 Y 00000000 A The data indicates that “keep the fare” means the new fare must be governed by the same carrier, tariff, and rule as the previous fare and the previous and new fare basis codes may differ only in their seasonality and/or day of week indicator(s) as defined by IATA Resolution 728. Fare break points are permitted to change.

Original Itinerary: Fare Owner: UA

BHXE21 NYC LAX BE21

Passenger requests to change LAX-NYC from a weekend to a midweek flight: • Processing matches to the above Table 988 sequence for both fare components. • Processing will attempt to re-price the NYC-LAX and LAX-NYC fares using Process Tag 1 – Keep the Fare, where “keep the fare” means the new fare may be any fare governed by the same carrier (UA), tariff (DFR), and rule (4035) as the previous fare where the seasonality and/or day of week indicator(s) are the only portions of the fare basis code which differ from the previous fare.

Result: Processing will attempt to re-price with any UA B-E21 fare in Tariff DFR, Rule 4035 which may or may not contain a seasonality indicator or a day of week indicator or both or neither.

Page E.03.31.282 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2 (Byte 112 = Value B/Bytes 138-145 = Value 00000000):

Both fare components match to the below Table 988

UA DFR RULE 4035 Bytes 21-22 Byte 43 Byte 57 Byte 73 Bytes 74-81 Bytes 82-84 Byte 85 Bytes 138-145 Byte 112 Process Tag Term Rule Ind Indicator Fare Class Fare Type Same Seasonality/DOW Expand Keep Indicator Table 966 1 Y 00000000 B The data indicates that “keep the fare” means the new fare must be governed by the same carrier, tariff, and rule as the previous fare. Fare break points are permitted to change.

Original Itinerary: Fare Owner: UA

BHXE21 NYC LAX BHWE21

Passenger requests to change LAX-NYC from a weekend to a midweek flight: • Processing matches to the above Table 988 sequence for both fare components. • Processing will attempt to re-price the NYC-LAX and LAX-NYC fares using Process Tag 1 – Keep the Fare, where “keep the fare” means the new fare may be any fare governed by the same carrier (UA), rule (4035), and tariff (DFR) as the previously ticketed fare.

Result: Processing will attempt to re-price with any UA fare in tariff DFR, Rule 4035.

Page E.03.31.283 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3 (Byte 112 = Value Blank/Bytes 138-145 = Value 00000000):

Both fare components match to the below Table 988

UA DFR RULE 4035 Bytes 21-22 Byte 43 Byte 57 Byte 73 Bytes 74-81 Bytes 82-84 Byte 85 Bytes 138-145 Byte 112 Process Tag Term Rule Ind Indicator Fare Class Fare Type Same Seasonality/DOW Expand Keep Indicator Table 966 1 Blank 00000000 Blank The data indicates that “keep the fare” means the new fare must be governed by the same carrier, tariff, rule, fare basis code, origin and destination points, and amount as the previous fare. Fare break points are not permitted to change.

Original Itinerary: Fare Owner: UA

BHXE21 NYC LAX BHWE21

Passenger requests to change LAX-NYC to another weekend flight: • Processing matches to the above Table 988 sequence for both fare components. • Processing will attempt to re-price both fare components using Process Tag 1 – Keep the Fare, where “keep the fare” means the new fare may be any fare which has the same fare owner (UA), rule (4035), tariff (DFR), fare basis code (BHXE21 and BHWE21), origin and destination points, and amount as the previously ticketed fare.

Result: Processing will attempt to re-price the NYC-LAX fare component using the UA BHXE21 fare and the LAX-NYC fare component using the UA BHWE21 fare. The amounts of the replacement fare must be the same as the amount of the previously ticketed fare.

Page E.03.31.284 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 4 (Byte 112 = Value A/Bytes 138-145 = Value 00000000):

Both fare components match to the below Table 988

UA DFR RULE 4035 Bytes 21-22 Byte 43 Byte 57 Byte 73 Bytes 74-81 Bytes 82-84 Byte 85 Bytes 138-145 Byte 112 Process Tag Term Rule Ind Indicator Fare Class Fare Type Same Seasonality/DOW Expand Keep Indicator Table 966 1 Y 00000000 A The data indicates that “keep the fare” means the new fare must be governed by the same carrier, tariff, and rule as the previous fare and the previous and new fare basis codes may differ only in their seasonality and/or day of week indicator(s) as defined by IATA Resolution 728. Fare break points are permitted to change.

Original Itinerary: Fare Owner: UA

BHXE21 NYC LAX BHWE21

Passenger requests to change the itinerary as follows:

NYC LAX

WAS

• Processing matches to the above Table 988 sequence for both fare components. • Processing will attempt to re-price the itinerary with two fare components, both fare components using Process Tag 1 – Keep the Fare, where “keep the fare” means the new fare may be any fare governed by the same carrier (UA), tariff (DFR), and rule

Page E.03.31.285 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

(4035) as the previous fare where only the seasonality and/or day of week indicator(s) are the only portions of the fare basis code which differ from the previous fare.

Result: Processing will attempt to re-price both fare components with any UA B-E21 fare in Tariff DFR, Rule 4035 that contains a seasonality indicator or a day of week indicator or both or neither.

Page E.03.31.286 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 5 (Byte 112 = Value A/Bytes 138-145 = Value 00056118):

Both fare components below match to this Table 988

UA DFR RULE 4035 Bytes 21-22 Byte 43 Byte 112 Bytes 138-145 Process Tag Term Expand Keep Seasonality/Day of Week Indicator Tbl 966 1 Y A 00056118

Seasonality/Day of Week Indicator Table 966 # 00056118 Tbl Tbl No. Indicator ID A B C D E F G H I J Bytes Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte 3-5 6-13 14 15 16 17 18 19 20 21 22 23 966 00056118 blank blank blank blank blank S blank S blank S

Indicator K L M N O P Q R S T U V W X Y Z Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte Byte 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 S S Blank blank blank blank S blank blank blank blank blank D D S blank

The data indicates that “keep the fare” means the new fare must be governed by the same carrier, tariff, and rule as the previous fare and the previous and new fare basis codes may differ only in their seasonality and/or day-of-week indicator(s). Fare break points are permitted to change. Seasonality indicators are F, H, J, K, L, Q and Y in the second position of the fare basis codes. Day-of-week indicators are W and X in the third position of the fare basis codes if the fare basis code contains a seasonality indicator and in the second position of the fare basis codes if not.

Page E.03.31.287 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Original Itinerary: Fare Owner: UA

BHXE21 NYC LAX BE21

Passenger requests to change LAX-NYC from a weekend to a midweek flight: • Processing matches to the above Table 988 sequence for both fare components. • Processing will attempt to re-price the NYC-LAX and LAX-NYC fares using Process Tag 1 – Keep the Fare, where “keep the fare” means the new fare may be any fare governed by the same carrier (UA), tariff (DFR), and rule (4035) as the previous fare where the seasonality and/or day-of-week indicator(s) are the only portions of the fare basis codes of the new fares which differ from those of the previous fares.

Result: Processing will attempt to re-price each fare component with BE21 or any UA B-E21 fare in Tariff DFR, Rule 4035 which contains a seasonality indicator or a day-of-week indicator or both or neither, as shown here:

BFE21 BFXE21 BFWE21 BXE21 BHE21 BHXE21 BHWE21 BWE21 BJE21 BJXE21 BJWE21 BE21 BKE21 BKXE21 BKWE21 BLE21 BLXE21 BLWE21 BQE21 BQXE21 BQWE21 BYE21 BYXE21 BYWE21

Page E.03.31.288 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.5. Revalidate Rules/ RBDs (bytes 90-110, 121)

The Revalidate Rules fields specify which rule conditions must be revalidated when re-pricing the itinerary. Data in bytes 90-110, 121 apply to all fare components on the journey where the fare remains as previously ticketed (re-price requirement is to Keep the Fare).

When re-pricing using the same fare If a fare component on the journey is re-priced using the same fare as previously ticketed, then processing must revalidate the rule conditions of the previously ticketed fare according to the data in bytes 90-110, 121.

Effective/Discontinue Dates When revalidating the rule conditions of the previously ticketed fares, the effective and discontinue dates on the Record 2 for the category being revalidated are matched to the new date of departure from the origin of the journey.

Override Date Table 994 When revalidating the rule conditions of the previously ticketed fare, any Table 994 data in the Record 3 for the category being revalidated is applied as follows: • Travel override dates are measured against the new date of departure from the origin of the fare component or pricing unit (depending upon the fare component or pricing unit application of the category). • Ticketing override dates are measured against the previous ticket issuance date. • Reservation override dates are measured against the previous reservation date for the fare component being validated. This application of Table 994 data ensures that the rules being revalidated are those that were applicable had the new itinerary been sold in that manner on the previous ticketing date.

Data in the Advance ticketing fields (Bytes 122-137) and/or the Sales Restriction Reissue Fields (Bytes 165-173) override any information in Category 5 and 15, respectively, in the fare rules being validated. The coded values in these specified bytes are the only information for those categories that should be validated. NOTE: Advance Ticketing (bytes 122-137) and Sales Restriction Reissue (bytes 165-173) are discussed in the TICKET REISSUE Section below.

Page E.03.31.289 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

When re-pricing using a different fare If a fare component on the journey is re-priced using a different fare than previously ticketed, then the data in bytes 92-110 and 121 has no application (NOTE: Bytes 90 and 91 still apply). Processing must validate all rule conditions of the new fare.

Effective/Discontinue Dates When validating the rule conditions of the new fare, the effective and discontinue dates on the Record 2 for the category being validated are matched to the new date of departure from the origin of the journey.

Override Date Table 994 When validating the rule conditions of the new fare, any Table 994 data in the Record 3 for the category being validated is applied as follows: • Travel override dates are measured against the new date of departure from the origin of the fare component or pricing unit (depending upon the fare component or pricing unit application of the category). • Ticketing override dates are measured against the previous ticket issuance date when re-pricing using historical fares and the new ticket issuance date when re-pricing using current fares. • Reservation override dates are measured against the previous reservation date when re-pricing using historical fares and the new reservation date when re-pricing using current fares.

Data in the Advance ticketing fields (Bytes 122-137) and/or the Sales Restriction Reissue Fields (Bytes 165-173) overrides any information in Category 5 and 15, respectively, in the fare rules being validated when using either the same fare and revalidating based on Table 988 bytes 97 and 107 or when using new fares and rule conditions. The coded values in these specified bytes are the only information for those categories that should be validated. NOTE: Advance Ticketing (bytes 122-137) and Sales Restriction Reissue (Bytes 165-173) are discussed in the TICKET REISSUE Section below.

Page E.03.31.290 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.5.1. Measure Advance Reservation (bytes 90-91)

Bytes 90 and 91 indicate the FROM and TO Points used to measure the advance reservation requirements. Bytes 90 and 91 have the following values:

Byte 90 – Measure FROM:

Value O Original ticket issue date Value P New ticket issue date if the outbound fare component of the ticketed pricing unit has changed. Validate all provisions of the new Category 5. If only other than outbound fare component of the ticketed pricing unit has changed, use original issue date and ignore ticketing after reservation requirements Value C New ticket issue date if using current fares, validate all provisions of the Category 5 on new fare; original ticket issue date if using historical fares and ignore ticketing after reservation requirements. Value Blank New ticket issue date and validate all provisions of the new Category 5.

Byte 91 – Measure TO departure of (based on new date of departure):

Value J Journey Value F Fare Component Value Blank Pricing Unit

Processing will determine the From Value in byte 90 and the To value in byte 91 in order to measure advance reservation requirements when re-pricing using the same fare (as specified by Table 988 byte 97) or when re-pricing using a different fare (as specified by the Category 5 data for the new fare or Table 988 bytes 122-137). Bytes 90 and 91 have no impact on the application of confirmed sector or advance ticketing requirements in Category 5.

Page E.03.31.291 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

If fare components within a single pricing unit resolve to different byte 90 values, then processing shall apply the following steps:

1. If the pricing unit consists of the same carrier a. Apply the most restrictive byte 90 value for every fare component in the pricing unit. The most restrictive value is determined to be the value that produces the latest FROM date. 2. If the pricing unit consists of different carriers a. If carriers are using the same value byte 90 i. Process -- Else b. If all carriers are using different values in byte 90 i. Go to manual reissue

Page E.03.31.292 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

The following four examples use the original and new itinerary below:

Original Itinerary: NYC-CHI-NYC RT Pricing Unit

Ticket Issue Date = 01Jan 01

Dept 15Jan NYC CHI Dept 01Feb Ticketing Information: Carrier Flight Date Sector Adv Res UA 100 15JAN NYC-CHI 14 day UA 400 01FEB CHI-NYC 14 day

Scenario: On 14 JAN passenger requests to change inbound departure date to 25JAN

New Itinerary: Dept 15Jan NYC CHI Dept 25Jan Ticketing Information: Carrier Flight Date Sector Adv Res UA 100 15JAN NYC-CHI 14 day UA 400 25JAN CHI-NYC 14 day

Page E.03.31.293 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1

The NYC-CHI and CHI-NYC fare components resolve to Category 31 Record 3 with the following Table 988 data: Bytes 21-22 Byte 90 Bytes 91 Process Tag From To 10 C J

⇒ Fares are 14 day AP fares. ⇒ Process Tag 10 instructs to use historical fares for unchanged fare component and current fares for changed fare component ⇒ Byte 90 value C dictates to measure from the new ticket issue date if using current fares and the original ticket issue date if using historical fares ⇒ Byte 91 value J dictates to measure to departure of the new journey ⇒ For the NYC-CHI fare component – Pass validation since 01JAN is 14 days out from 15JAN ⇒ For the CHI-NYC fare component – Fail validation since 14JAN less than 14 days out from 15 JAN

Example 2

The NYC-CHI and CHI-NYC fare components resolve to Category 31 Record 3 with the following Table 988 data: Bytes 21-22 Byte 90 Bytes 91 Process Tag From To 5 P BLANK

⇒ Fares are 14 day AP fares. ⇒ Process Tag 5 instructs to use current fares ⇒ Byte 90 value P dictates to measure from the new ticket issue date if outbound fare component of pricing unit changed. If other than outbound fare component change, use original issue date. ⇒ Byte 91 value BLANK dictates to measure to departure of the pricing unit. ⇒ For the NYC-CHI fare component – Pass validation since 01JAN 14 days out from 15JAN ⇒ For the CHI-NYC fare component – Pass validation since 01JAN 14days out from 15JAN

Page E.03.31.294 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3

The NYC-CHI and CHI-NYC fare components resolve to Category 31 Record 3 with the following Table 988 data: Bytes 21-22 Byte 90 Bytes 91 Process Tag From To 5 BLANK BLANK

⇒ Fares are 14 day AP fares. ⇒ Process Tag 5 instructs to use current fares ⇒ Byte 90 value BLANK dictates to measure from new ticket issue date and validate all provisions of the new Category 5. ⇒ Byte 91 value BLANK dictates to measure to departure of the pricing unit. ⇒ For the NYC-CHI fare component – Fail validation since 14JAN less than 14days from 15JAN ⇒ For the CHI-NYC fare component -- Fail validation since 14JAN less than 14days from 15JAN

Example 4

The NYC-CHI and CHI-NYC fare components resolve to Category 31 Record 3 with the following Table 988 data: Bytes 21-22 Byte 90 Bytes 91 Process Tag From To 5 O F

⇒ Fares are 14 day AP fares. ⇒ Process Tag 5 instructs to use current fares ⇒ Byte 90 value O dictates to measure from original ticket issue date ⇒ Byte 91 value F dictates to measure to departure of the fare component ⇒ For the NYC-CHI fare component – Pass validation since 01JAN 14 days out from 15JAN ⇒ For the CHI-NYC fare component – Pass validation since 01JAN 14 days out from 25JAN

Page E.03.31.295 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Different byte 90 Values in a pricing unit

Example 1

Original Itinerary: ATL-BOS-LAX-ATL

Original Itinerary (3 Component Circle Trip) ATL BOS

LAX

Passenger requests a change to the ATL-BOS fare component Original ticket date = 01JAN New ticket issue date = 15JAN

Fare Carrier Byte 90 value component ATL-BOS 1 O BOS-LAX 1 BLANK LAX-ATL 1 P

Since there is only one carrier in the pricing unit, processing will resolve to the byte 90 value that gives the latest date. Value O = 01JAN Value BLANK = 15JAN Value P = 15JAN since outbound fare component was changed

Processing will use as the date from which to measure the advance res/ticketing requirements.

Page E.03.31.296 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2

Original Itinerary: ATL-BOS-LAX-ATL

Original Itinerary (3 Component Circle Trip) ATL BOS

LAX

Passenger requests a change to the ATL-BOS fare component Original ticket date = 01JAN New ticket issue date = 15JAN

Fare Carrier Byte 90 value component ATL-BOS 1 O BOS-LAX 2 O LAX-ATL 3 O

Since there all three carriers on the pricing unit use the same byte 90 value O (01JAN), processing will use value O to measure the advance ticketing requirements.

Page E.03.31.297 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3

Original Itinerary: ATL-BOS-LAX-ATL

Original Itinerary (3 Component Circle Trip) ATL BOS

LAX

Passenger requests a change to the ATL-BOS fare component Original ticket date = 01JAN New ticket issue date = 15JAN

Fare Carrier Byte 90 value component ATL-BOS 1 O BOS-LAX 2 BLANK LAX-ATL 3 P

Since there are multiple carriers on the pricing unit and each carrier uses a different byte 90 value, automated processing is not possible and the transaction must go to a manual reissue.

Page E.03.31.298 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.5.2. Revalidate Rules (bytes 92-110)

Revalidate Rule data in bytes 92-110 only applies to fare components on the journey that are being re-priced using the same fare as previously ticketed. Application byte 92 specifies how to apply the category data specified in Fare Rule bytes 93-110. When byte 92 is value X, processing will revalidate all categories except the categories specified in bytes 93-110. When byte 92 is value Y, processing will only revalidate the categories specified in bytes 93-110. When byte 92 is Blank, processing will revalidate all categories. Edits require that when byte 92 is value Blank, then bytes 93-110 must also be Blank.

Fare Rule bytes 93-110 may address revalidation of the following categories (as specified by byte 92):

Category 01 – Eligibility Category 10 – Combinability Category 02 – Day/Time Application Category 11 – Blackouts Category 03 – Seasonality Category 12 – Surcharges Category 04 – Flight Application Category 13 – Accompanied Travel Category 05 – Advance Res/Ticketing Category 14 – Travel Restrictions Category 06 – Minimum Stay Category 15 – Sales Restrictions Category 07 – Maximum Stay Category 17 – HIP/Mileage Exceptions Category 08 – Stopovers Category 23 – Miscellaneous Fare Tags Category 09 – Transfers Category 50 – Rule Application and Other Conditions

When any category must be revalidated, processing will validate the footnote, fare rule, and general rule levels for the specified category. (Reconciliation of data between the Footnote and Rule levels is address in Data Application for Record 2.) Application of category data is addressed in data application documentation for each category.

Page E.03.31.299 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example

Original Itinerary (NYC-CHI RT End-on-End with CHI-LAX RT) Ticket Issuance: 01Jan 01 Dept 10Jan 01 (Wed) Dept 20Jan 01 (Sat) NYC CHI LAX Dept 16Feb 01 (Fri) Dept 01Feb 01 (Thu) Ticketing Information: Carrier Flight Date Sector Fare Bkg Code Class NW 1200 10JAN 01 NYC-CHI QE7NR Q NW 250 20JAN 01 CHI-LAX YEE Y NW 300 01FEB 01 LAX-CHI YEE Y NW 426 16FEB 01 CHI-NYC QE7NR Q

New Itinerary requested on 03Jan 01 Ticket (Re) Issuance: 03Jan 01 Dept 12Jan 01 (Fri) Dept 23Jan 01 (Tue) NYC CHI LAX Dept 16Feb 01 (Fri) Dept 01Feb 01 (Thu) Ticketing Information: Carrier Flight Date Sector Bkg Code NW 3320 12JAN 01 NYC-CHI Q CHANGE NW 2216 23JAN 01 CHI-LAX Y CHANGE NW 300 01FEB 01 LAX-CHI Y No change NW 426 16FEB 01 CHI-NYC Q No change

Page E.03.31.300 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

QE7NR fare resolves to the Table 988 below: Bytes 21-22 Byte 43 Byte 90 Byte 91 Byte 92 Byte 93 Byte 94 Byte 95 Byte 96 Byte 97 Process Tag Term Adv Res Adv Res Appl Elig Day/Time Seasonality Flt App Adv Res/Tkt From To 01 BLANK O BLANK Y BLANK X X BLANK X The data indicates to re-price the itinerary using Process Tag 01. Changes to fare break points are not permitted on the fare component. When using the same fare on the new fare component, revalidate Category 2 (Day/Time), Category 3 (Seasonality), and Category 5 (Adv Res/Ticketing) data. Measure Category 5 reservation data from the previous ticketing date to the new date of departure on the pricing unit.

QE7NR fare resolves to the following Category data: Category Effective Date Discontinue Date Data Category 2 01Aug 00 11Jan 01 Permitted Wed-Sat 12Jan 01 9999999 Permitted Mon/Tue Category 3 15Nov 00 9999999 Permitted 01Jan 01 – 10Jan 01 Category 4 02Feb 00 9999999 Must be on NW flight 0001 through 1999 Category 5 22Apr 00 9999999 Res required 7days before departure. Ticketing required 24 hours after res or 7 days before departure, whichever is first

YEE fare resolves to the Table 988 below: Bytes 21-22 Byte 43 Byte 90 Byte 91 Byte 92 Byte 93 Byte 94 Byte 95 Byte 96 Byte 97 Process Tag Term Adv Res Adv Res Appl Elig Day/Time Seasonality Flt App Adv Res/Tkt From To 02 Y O BLANK Y BLANK BLANK BLANK X BLANK The data indicates to re-price the itinerary using Process Tag 02. Changes to fare break points are permitted on the fare component. When using the same fare on the new fare component, revalidate Category 4 (Flight Application).

Page E.03.31.301 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

YEE fare resolves to the following Category data: Category Effective Date Discontinue Date Data Category 2 N/A N/A Processing does not resolve to any Category 2 data. Category 3 N/A N/A Processing does not resolve to any Category 3 data. Category 4 01Aug 00 9999999 Must be on NW flight 300 or 301. Category 5 N/A N/A All sectors of the pricing unit must be confirmed.

When validating the NYC-CHI and CHI-NYC fare components from the original itinerary: • Match the Table 988. • Re-price using Process Tag 01. Changes to fare break points are not permitted. • For the purpose of this example, assume the new itinerary is being re-priced as a NYC-CHI-NYC RT pricing unit End-on-End with a CHI-LAX-CHI RT pricing unit. • Identify fare components on the journey where re-pricing using the same fare (keep the fare): NYC-CHI, CHI-NYC, CHI-LAX, LAX-CHI (process tag 01 specifies to keep the fares; therefore same fare applies on each fare component). • Revalidate Category 2, 3, and 5 for all unchanged fare components on the journey: NYC-CHI ⇒ Resolve to Category 2 effective 12Jan 01 (based on new date of departure from journey origin). Fail Category 2 (travel from fare component origin is not on the specified days). ⇒ Resolve to Category 3. Fail Category 3 (travel from pricing unit origin is not within the specified dates) ⇒ Resolve to Category 5. Measure 14-day advance res data from previous ticketing date (01Jan01) to new date of departure on the pricing unit (12Jan 01). Previous ticketing date is more that 7 days before new date of departure from the origin of the pricing unit. Ticket is being (re)issued within 24 hours of reservations. Pass Category 5. CHI-NYC ⇒ Resolve to Category 2 effective 12Jan 01 (based on new date of departure from journey origin). Fail Category 2 (travel from fare component origin is not on the specified days). ⇒ Resolve to Category 3. Fail Category 3 (travel from pricing unit origin is not within the specified dates) ⇒ Resolve to Category 5. Measure 14-day advance res data from previous ticketing date (01Jan01) to new date of departure on the pricing unit (12Jan 01). Previous ticketing date is more that 7 days before new date of departure from the origin of the pricing unit. Ticket is being (re)issued within 24 hours of reservations. Pass Category 5.

Page E.03.31.302 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

CHI-LAX ⇒ Processing does not resolve to any Category 2 data; apply system assumption of no restrictions. ⇒ Processing does not resolve to any Category 3 data; apply system assumption of no restrictions. ⇒ Processing does not resolve to any Category 5 data; apply system assumption of no restrictions. LAX-CHI ⇒ Processing does not resolve to any Category 2 data; apply system assumption of no restrictions. ⇒ Processing does not resolve to any Category 3 data; apply system assumption of no restrictions. ⇒ Processing does not resolve to any Category 5 data; apply system assumption of no restrictions. • Processing will fail the Table 988 sequence because NYC-CHI and CHI-NYC fare components did not pass all category revalidation. When validating the CHI-LAX and LAX-CHI fare components from the original itinerary: • Match the Table 988. • Re-price using Process Tag 02. Changes to fare break points are permitted. • For the purpose of this example, assume the new itinerary is being re-priced as a NYC-CHI-NYC RT pricing unit End-on-End with a CHI-LAX-CHI RT pricing unit. • Identify fare components on the journey where re-pricing using the same fare (keep the fare): NYC-CHI, CHI-NYC, CHI-LAX, LAX-CHI (although process tag 02 specifies to use historical fares, process tag 01 specifies to Keep the Fares which is a more restrictive re-pricing requirement). • Revalidate Category 4 for all unchanged fare components on the journey: NYC-CHI ⇒ Resolve to Category 4. Fail Category 4 (travel is not on the specified flight number restrictions) CHI-NYC ⇒ Resolve to Category 4. Pass Category 4 (travel is on the specified flight number restrictions) CHI-LAX ⇒ Resolve to Category 4. Fail Category 4 (travel is not on the specified flight number restrictions) LAX-CHI ⇒ Resolve to Category 4. Pass Category 4 (travel is on the specified flight number restrictions) • Processing will fail the Table 988 sequence because NYC-CHI and CHI-LAX fare components did not pass category 4 revalidation.

Page E.03.31.303 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.5.5.3. Revalidate RBD (byte121)

Revalidate RBD data in byte 121 only applies to fare components on the journey that are being re-priced using the same fare as previously ticketed. When byte121 is value X, processing will not revalidate any Prime RBD data on the Record 1 or and RBD Exception Data (Table 999) on the Record 1 or Record 6. When byte 121 is value C, processing will not revalidate any Prime RBD data on the Record 1 or any RBD Exception Data (Table 999) on the Record 1 or Record 1 provided that all fare components in the new journey are booked in the same cabin (e.g. first, business, premium economy, economy) as on the previous journey. When byte 121 is value Blank, processing will revalidate RBD data in the Record 1 Prime RBD, Record 1 Table 999, and Record 6 Convention 1 and 2 Tables 999.

4.5.6. New Ticket Must Have an Equal or Higher Value – byte 208

This field indicates whether the total pricing solution for the new ticket must be equal to or greater than the total pricing solution of the previous ticket. This field requires a journey validation. There are two values in this byte that describe differing ways to measure the total pricing solution Value B dictates to measure the sum of the total base fare amounts in the previous ticket and compare them to the sum of the total base fare amounts in the new ticket. The new ticket must be equal to or higher in value than the previous ticket. Value N dictates that if previous ticket contained non-refundable fares, then the total non-refundable amount of the new ticket must be equal to or higher than the total non-refundable amount of the previous ticket. The non-refundable amount of each fare is determined by retrieving the penalty data from that fares Category 16. For itineraries that include ½ RT fares the non-refundable amount would be ½ of the non-refundable amount of the ½ RT fare. The sum of all non-refundable amounts in the ticket equals the total non-refundable amount for that ticket. A value of blank in this field indicates that the field has no application and no restriction on value of new ticket.

NOTE: When value N is used in conjunction with Category 31 byte 112 value N, do not fail pricing solution if new non-refundable total is less than the original non refundable total on previous ticket.

Values for byte 208: Value B New ticket is of equal or higher value than the previous ticket. Measure base fare to base fare. Value N If the previous ticket contains non-refundable fares on it then the total non-refundable amount on the new ticket (all non-refundable fares) must be equal to or higher than the total non-refundable amount on the previous ticket.

Page E.03.31.304 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

• Use Category 16 data to determine the total nonrefundable amounts. If the equal or higher criteria are not met – fail the solution. Value Blank no application

The examples on the following pages use the following itinerary:

Scenario:

Original Itinerary (NYC-LON-NYC RT)

50% of YAPNR fare $800.00 RT) NYC LON 50% of BHAP fare $700.00 RT)

Total amount of ticket = ½ RT NYC-LON + ½ RT LON-NYC = $750.00

Assume the following fares are available for re-pricing the new itinerary: Sector Fare Class Code ½ RT Amount Cat 16 NR amount NYC-LON BAP $350.00 $50.00 NYC-LON BAPNR $350.00 - NYC-LON KAPNR $300.00 $100.00 LON-NYC KHAP $300.00 LON-NYC BHAPNR $350.00 $75.00 LON-NYC YHAPNR $450.00 $50.00 Passenger would like to change the departure date from NYC:

Page E.03.31.305 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1

If Table 988 for either of the two fares is coded with byte 208 the following applies:

If the 988 contains byte 208 value B: New ticket MUST be $750 or greater. Measured by total sum of base fares of new ticket to total sum of base fares for previous ticket.

From the available fares – the following itineraries are possible BAP ($350.00) and YHAPNR ($450.00) = $800 BAPNR ($350.00) and YHAPNR ($450.00) = $800 KAPNR ($300.00) and YHAPNR ($450.00) = $750

If the 988 contains byte 208 value N: Check the non-refundable amount of previous ticket by accessing that fares Cat 16 data. YAPNR = $150.00 non-refundable amount.

New ticket must include non-refundable amounts greater than $150. This may be a single $150 non-refundable amount on a single fare – or may be a sum of all the non-refundable amounts on both fares of the new itinerary

From the available fares – the following itineraries is possible:

KAPNR ($100 non-refundable amount) and YHAPNR ($50.00 non-refundable amount) = $150.00 non-refundable amount KAPNR ($100 non-refundable amount) and BHAPNR ($75.00 non-refundable amount) = $175.00 non-refundable amount

Page E.03.31.306 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2

Table 988 byte 208 value N in conjunction with Category 31 byte 112 value N

Category 31 byte 112 is value N states do not fail the pricing solution if new non-refundable total is less than the original non- refundable total on the previous ticket

If the 988 contains byte 208 value N and the Category 31 byte 112 is value N: Check the non-refundable amount of previous ticket by accessing that fares Cat 16 data. YAPNR = $150.00 non-refundable amount.

New ticket must include a total non-refundable amount greater than $150. This may be a single $150 non-refundable amount on a single fare – or may be a sum of all the non-refundable amounts on both fares of the new itinerary. Since Category 31 byte 112 is value N, you should not fail a pricing solution that results in a non-refundable amount less than $150.

From the available fares – the following itineraries are possible:

KAPNR ($100 non-refundable amount) and YHAPNR ($50.00 non-refundable amount) = $150.00 non-refundable amount KAPNR ($100 non-refundable amount) and BHAPNR ($75.00 non-refundable amount) = $175.00 non-refundable amount

The following would normally FAIL, but since byte 112 is value N they also PASS validation for byte 208: BAP ($50 non-refundable amount) and BHAPNR ($75.00 non-refundable amount) = $125 non-refundable amount BAP ($50 non-refundable amount) and YHAPNR ($50.00 non-refundable amount) = $100 non-refundable amount

Page E.03.31.307 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3

Table 988 byte 208 in conjunction with Table 988 byte 86

Table 988 byte 86 is applied on a fare component basis and states whether the new fare component must be of a higher value than the previous fare component.

Table 988 byte 86 contains the following values: X = equal or higher than original fare Y = higher than original fare Blank = any fare amount

For this example Table 988 byte 86 resolves to the NYC-LON fare component only.

If the 988 contains byte 208 value B and byte 86 value X: According to byte 208 value B the new ticket MUST be $750 or greater. Measured by total sum of base fares of new ticket to total sum of base fares for previous ticket.

According to byte 86 value X, the new LON-NYC fare must be equal or higher value than $350 (previous fare amount). Measured by comparing the fare amount of the previous fare component to the new fare component amount.

From the available fares – the following itineraries are possible:

BAP ($350.00) and YHAPNR ($450.00 –higher than previous fare amount) = $800 BAPNR ($350.00) and YHAPNR ($450.00 - higher than previous fare amount) = $800 KAPNR ($300.00) and YHAPNR ($450.00 - higher than previous fare amount) = $750

Page E.03.31.308 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

If the 988 contains byte 208 value B and byte 86 value Y: According to byte 208 value B the new ticket MUST be $750 or greater. Measured by total sum of base fares of new ticket to total sum of base fares for previous ticket.

According to byte 86 value Y, the LON-NYC fare component must be higher than $350 (previous fare amount). Measured by comparing the fare amount of the previous fare component to the new fare component.

From the available fares – the following itineraries are possible:

BAP ($350.00) and YHAPNR ($450.00 – higher than previous fare amount) = $800 BAPNR ($350.00) and YHAPNR ($450.00 - higher than previous fare amount) = $800 KAPNR ($300.00) and YHAPNR ($450.00 - higher than previous fare amount) = $750

If the 988 contains byte 208 value N and byte 86 value X: Check the non-refundable amount of previous ticket by accessing that fares Cat 16 data. YAPNR = $150.00 non-refundable amount.

New ticket must include non-refundable amounts greater than $150. This may be a single $150 non-refundable amount on a single fare – or may be a sum of all the non-refundable amounts on both fares of the new itinerary

According to byte 86 value X, the new LON-NYC fare must be equal or higher value than $350 (previous fare amount). Measured by comparing the fare amount of the previous fare component to the new fare component

From the available fares – the following itineraries is possible:

KAPNR ($100 non-refundable amount) and YHAPNR ($50.00 non-refundable amount/ $450.00 fare amount is equal or higher than previous fare amount) = $150.00 non-refundable amount KAPNR ($100 non-refundable amount) and BHAPNR ($75.00 non-refundable amount/ $350.00 fare amount is equal or higher than previous fare amount) = $175.00 non-refundable amount

Page E.03.31.309 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

If the 988 contains byte 208 value N and byte 86 value Y: Check the non-refundable amount of previous ticket by accessing that fares Cat 16 data. YAPNR = $150.00 non-refundable amount.

New ticket must include non-refundable amounts greater than $150. This may be a single $150 non-refundable amount on a single fare – or may be a sum of all the non-refundable amounts on both fares of the new itinerary

According to byte 86 value Y, the new LON-NYC fare must higher value than $350 (previous fare amount). Measured by comparing the fare amount of the previous fare component to the new fare component

From the available fares – the following itinerary is possible:

KAPNR ($100 non-refundable amount) and YHAPNR ($50.00 non-refundable amount/ $450.00 fare amount is equal or higher than previous fare amount) = $150.00 non-refundable amount

Page E.03.31.310 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.6. CALCULATE THE APPLICABLE CHARGES

Charge data is present in the Table 988 ITINERARY RE-PRICING AMOUNT fields and the Category 31 AMOUNT fields.

4.6.1. Charges – Category 31 Amount (bytes 63-103)

After re-pricing the itinerary as directed by Table 988, processing must calculate any applicable change fee. Change fees may be expressed as specified amounts in the Charge 1 (bytes 63-73) and, optionally, Charge 2 (bytes 81-91) Amount/Decimal/Currency fields. Charge 2 fields may only be populated if Charge 1 fields are populated and the Charge 2 Decimal field (bytes 88-90) is populated with a different currency code than the Charge 1 Decimal field (bytes 70-72). Processing will select the Charge data published in the same currency as the fare on the fare component being validated (based on fare selection). If neither Charge 1 nor Charge 2 is in the same currency as the fare on the fare component being validated (based on fare selection), processing will use the change fee coded in the Charge 1 fields (bytes 63-73). Change fees may also be expressed as a percentage of the base fare (bytes 74- 80), as the Higher or Lower amount of the Penalty Amount and Percentage (byte 92), or as a Minimum Amount, Decimal, and Currency (bytes 93-103) that must be collected. The base fare is the previous fare for the fare component being validated. Processing will determine the penalty amount for the ticket based on charges/percent in bytes 63-103 and Fee Application in bytes 104-105. If a Minimum Amount is specified in byte 93-103, then this is the minimum amount that must be collected for the ticket. If the penalty amount for the ticket as determined by Charges/Percent bytes 63-103 and Fee Application in bytes 104-105 is lower than the Minimum Amount in bytes 93-103, then collect the amount specified in bytes 93-103 (collect the higher amount). If the penalty amount for the ticket as determined by Charges/Percent bytes 63-103 and Fee Application in bytes 104-105 is higher than the Minimum Amount in bytes 93-103, then collect the amount determined from bytes 63-103 and bytes 104-105 (collect the higher amount).

Page E.03.31.311 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Bytes 63-103 have no application and no change fee is assessed when the only change to the previous ticket is that one or more open segments are confirmed/waitlisted provided: . No changes are made to the origin and/or destination of the fare component on the previous ticket that contains the open segment. No changes are made to the marketing carrier, flight number, departure date/time, RBD and/or origin and destination of any booked segments on the previous ticket. . Fare break points have not changed and all replacement fares on the new ticket are the same as those on the previous ticket, with “the same” defined as: o For fare components that include an open segment that is confirmed/waitlisted in this transaction, “same fare” is any fare obtained from Tag 1 or obtained from the historical database and is the same fare class code and amount as the previous fare. o For fare components that do not include an open segment that is confirmed/waitlisted in this transaction, “same fare” is the same fare class code and amount as the previous fare, obtained from the historical database. When confirming/wait listing an open segment and any of these conditions are not met, change fees are assessed following normal application of bytes 63-103.

Page E.03.31.312 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Examples

Assume the following is filed for all fare components on each example:

Category 31 JNY Reissue Charge 1 Percent Charge 2 Fee Appl Form of Dom/Intl Carrier Byte 26 Table 988 Bytes 63-73 Bytes 74-80 Bytes 81-91 Bytes 104- Refund Comb Table Bytes 55-62 105 Byte 113 Byte 116 Bytes 89-91 B 9191919 50.00 GBP J,1 V Y 0000000 Table 988 #9191919 Process Tag Orig Carrier Appl Fare Normal/ OW/RT MEA ADV Skd Table 990 Amt Special RES Bytes 21-22 Flight Bytes 58-65 Byte 86 Byte 87 Byte 88 Byte 90-91 Byte 56 2 Blank 0000000 Blank Blank Blank Blank, J The data indicates that before the passenger’s departure from the origin of the journey and anytime before or after scheduled departure of the first unflown flight: • the change fee is GBP50.00 • the highest fee of all changed fare components within the journey is charged • any residual amount is ignored • any refund on the ticket is to a voucher • replacement fares are historical ticket issue date fares • replacement fare must have the same fare owner as the ticketed fare • replacement fare amount may be higher than, lower than, or the same as the level of the ticketed fare • replacement fare may be normal or special • replacement fare may be one-way or half round-trip • advanced reservation requirements of the replacement fare are measured from the reissue date to the departure of the new journey

Page E.03.31.313 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1. Current Ticket: Mkt Cxr XX Flt 3000 Mkt Cxr XX Flt OPEN Dept 30Mar08 LIS MAD MOW |– FC1: VHXEUOW EUR444.00–––| |––––––––––––––––––––FC2: COW EUR4411.00––––––––––––––––––|

New Itinerary: Mkt Cxr XX Flt 3000 Mkt Cxr XX Flt 1234 Dept 30Mar08 Dept 10Apr08 LIS MAD MOW |– FC1: VHXEUOW EUR444.00–––| |––––––––––––––––––––FC2: COW EUR4411.00––––––––––––––––––|

Result: The Charges fields (bytes 63-103) of all fare components on the previous ticket have no application and no change fee is assessed.

Current Ticket (wholly unflown) for Examples 2-4

Mkt Cxr XX Flt 3000 Mkt Cxr XX Flt 3100 Mkt Cxr XX Flt OPEN Dept 30Mar08 Dept 01Apr08 HEL FRA PAR (stopover) NCE |– FC1: VHXEUOW EUR444.00––| |––––––––––––––––––––FC2: COW EUR4411.00––––––––––––––––––|

Page E.03.31.314 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2. New Itinerary: Mkt Cxr XX Flt 3000 Mkt Cxr XX Flt 3100 Mkt Cxr XX Flt 1212 Dept 30Mar08 Dept 01Apr08 Dept 15Apr08 HEL FRA PAR (stopover) LYS

Result: Because there has been a change to the destination of the fare component that contains the open segment, the Charges fields (bytes 63-103) are applied normally.

Example 3. New Itinerary: Mkt Cxr XX Flt 3000 Mkt Cxr XX Flt 3100 Mkt Cxr XX Flt 1212 Dept 30Mar08 Dept 01Apr08 Dept 15Apr08 HEL FRA PAR NCE |–– FC1: VHXEUOW EUR444.00 –| |––– FC2: COW1 EUR437.00 ––| |–––– FC3: MHOX1 EUR853.00 –––|

Result: Because there has been a change to a fare break point, the Charges fields (bytes 63-103) are applied normally.

Example 4. New Itinerary: Mkt Cxr XX Flt 3000 Mkt Cxr XX Flt 3100 Mkt Cxr XX Flt 1212 Dept 30Mar08 Dept 01Apr08 Dept 15Apr08 HEL FRA PAR (stopover) NCE |– FC1: XHXEUOW EUR144.00–––| |––––––––––––––––––––FC2: COW EUR4411.00––––––––––––––––––|

Result: Because there has been a change to the fare on the confirmed segment, the Charges fields (bytes 63-103) are applied normally.

Page E.03.31.315 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 5 (change to connection or stopover point). Current Ticket (wholly unflown): Mkt Cxr XX Flt 3000 Mkt Cxr XX Flt OPEN Mkt Cxr XX Flt OPEN Dept 30Mar08 LIS MAD MUC MOW |– FC1: VHXEUOW EUR444.00–––| |––––––––––––––––––––FC2: COW EUR4411.00––––––––––––––––––|

New Itinerary: Mkt Cxr XX Flt 3000 Mkt Cxr XX Flt 3100 Mkt Cxr XX Flt 1212 Dept 30Mar08 Dept 01Apr08 Dept 01Apr08 LIS MAD FRA (connection) MOW |– FC1: VHXEUOW EUR444.00–––| |––––––––––––––––––––FC2: COW EUR4411.00––––––––––––––––––|

Result: The Charges fields (bytes 63-103) of all fare components on the previous ticket have no application and no change fee is assessed.

Page E.03.31.316 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 6. Current Ticket: Mkt Cxr XX Flt 3000 Mkt Cxr XX Flt OPEN Dept 30Mar08 LIS MAD MOW |– FC1: VHXEUOW EUR444.00–––| |––––––––––––––––––––FC2: KW3NR24 EUR990–––––––––––––––––|

New Itinerary: Mkt Cxr XX Flt 3000 Mkt Cxr XX Flt 1234 Dept 30Mar08 Dept 10Apr08 LIS MAD MOW |– FC1: VHXEUOW EUR444.00–––| |––––––––––––––––––––FC2: KX3NR24 EUR970––––––––––––––––––|

Result: Because the replacement fare on the fare component that contains the previously open segment is not the same fare as on the previous ticket (that is, it is neither obtained from Tag 1 nor is the same fare class code) the Charges fields (bytes 63-103) are applied normally.

Page E.03.31.317 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.6.2. Fee Application (bytes 104-105) Once processing has determined the change fee amount as specified by the Charges field (bytes 63-103) for each fare component on the itinerary, the data in the Fee Application field (bytes 104-105) will specify how to assess the change fee.

For the purposes of this field, a fare component is considered changed if one or more TKT FLTs* and/or the TKTD PRICING† of the fare component have changed. A pricing unit is considered changed if one or more of its fare components is changed.

The valid values of this field are: Byte Byte Definition 104 105

J 1 From among all changed fare components, apply the highest change fee Blank 1

J 2 From among all fare components, changed and unchanged, apply the highest change fee Blank 2 Blank 3 Apply the sum of the change fees of all changed fare components

P 2 From among all fare components within changed pricing units, apply the highest change fee Blank 4 From among all fare components within 1) changed pricing units and 2) pricing units to Blank 5 which a fare component has been added, apply the highest change fee

If no changes per the definition above are made to any ticketed fare components and one or more new flights appear on the new itinerary:

* TKTD FLT = marketing carrier, flight number, departure airport and date, and arrival airport and date. † TKTD PRICING = fare amount, fare break points, fare basis code, and ticket designator.

Page E.03.31.318 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

then bytes 104-105 has no application and no change fee all new flight are priced in their own pricing unit(s)  applies and then apply the values of bytes 104-105 of the ticketed fare any new flights are not priced in their own pricing unit(s)  components to determine the change fee, if any

NOTE: Fee Application

NOTE: All Category 31 Record 3 tables with an effective date equal to or later than July 11, 2010 will contain only value Blank in byte 104. When the Charges fields (bytes 63-103) have no application, Fee Application bytes 104-105 have no application.

The following processing logic applies when all fare components on the ticket do not have the same values in the Fee Application field (bytes 104-105). 1. Is the validating carrier (reissuing carrier) the fare owner of one or more fare components on the previous ticket? a. If yes: i. Determine the highest Fee Application (bytes 104-105) value of all fare components on the previous ticket that are owned by the validating carrier according to this hierarchy, reading from top to bottom: Bytes 104,105 Blank,3 Blank,2 or J,2 Blank,5 Blank,4 or P,2 Blank,1 or J,1 P,1* Blank,Blank* ii. Process all fare components on the previous itinerary as if each contained the value of Fee Application (bytes 104-105) found in Step 1.a.i. b. If no:

* These values exist only in Category 31 Record 3 tables with an effective date earlier than the implementation date of this document. Refer to the 29 June 2008 version of this data application document.

Page E.03.31.319 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

i. Determine the highest Fee Application (bytes 104-105) value of all fare components on the previous ticket according to this hierarchy, reading from top to bottom: Bytes 104,105 Blank,2 or J,2 Blank,5 Blank,4 or P,2 Blank,1 or J,1 Blank,3 P,1* Blank,Blank*

ii. Process all fare components on the previous itinerary as if each contained the value of Fee Application (bytes 104-105) found in Step 1.b.i.

In Examples 1-16, assume byte 104 = blank. Refer to the chart on page 319 for the corresponding byte 105 value when byte 104 = J or P.

Examples 1 through 8 illustrate scenarios in which changes are made to one or more fare components on the previous ticket.

Example 1: 1 PU, byte 105 values 1 and 2, validating carrier is a fare owner Fare PU Change Carrier Byte Validating Application Component Fee 105 Carrier 1 1 $50.00 AA 2 Value 2: From among all fare 2 1 $25.00 BB 1 AA components, changed and unchanged, 3 1 $25.00 AA 1 apply the highest change fee

* These values exist only in Category 31 Record 3 tables with an effective date earlier than the implementation date of this document. Refer to the 29 June 2008 version of this data application document.

Page E.03.31.320 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

All Fare Components 1. The validating carrier (AA) is a fare owner on the previous ticket Changed 2. AA’s fares on the previous ticket have differing byte 105 values (values 1 and 2) a. The most restrictive value of byte 105 for AA’s fares is 2 3. Process change fee application as if all fares contained byte 105 value 2 a. The highest change fee among all fare components is $50.00 4. Change fee to be assessed is $50.00

Fare Components 2 and 3 Same processing as above. It does not matter which fare components are changed. Changed

Page E.03.31.321 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2: 1 PU, byte 105 values 1 and 2, validating carrier is a fare owner Fare PU Change Carrier Byte Validating Application Component Fee 105 Carrier 1 1 $50.00 AA 2 Value 1: From among all changed fare 2 1 $25.00 BB 1 BB components, apply the highest change fee 3 1 $25.00 AA 1

All Fare Components 1. The validating carrier (BB) is a fare owner on the previous ticket Changed 2. BB has only a single byte 105 value on the previous ticket (value 1) 3. Process fee application as if all fares contained byte 105 value 1 a. All fare components have changed b. The highest change fee among all fare components is $50.00 4. Change fee to be assessed is $50.00

Fare Components 2 and 3 1. The validating carrier (BB) is a fare owner on the previous ticket Changed 2. BB has only a single byte 105 value on the previous ticket (value 1) 3. Process fee application as if all fares contained byte 105 value 1 a. Fare components 2 and 3 have changed b. The highest change fee among fare components 2 and 3 is $25.00 4. Change fee to be assessed is $25.00

Page E.03.31.322 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3: 1 PU, byte 105 values 1, 2 and 4 (or 1, 2 and 5), validating carrier is a fare owner Fare PU Change Carrier Byte Validating Application Component Fee 105 Carrier 1 1 $50.00 AA 2 Value 4: From among all fare 2 1 $25.00 BB 4* BB components within changed pricing 3 1 $25.00 AA 1 units, apply the highest change fee

All Fare Components 1. The validating carrier (BB) is a fare owner on the previous ticket Changed 2. BB has only a single byte 105 value on the previous ticket (value 4*) 3. Process fee application as if all contained byte 105 value 4* a. There is only one pricing unit on the ticket b. The highest change fee within the pricing unit is $50.00 4. Change fee to be assessed is $50.00

Fare Components 2 and 3 1. The validating carrier (BB) is a fare owner on the previous ticket Changed 2. BB has only a single byte 105 value on the previous ticket (value 4*) 3. Process fee application as if all fares contained byte 105 value 4* a. There is only one pricing unit on the ticket b. The highest change fee within the pricing unit is $50.00 4. Change fee to be assessed is $50.00

* Note: the outcome would be the same if Fare Component 2 contained byte 77 = 5.

Page E.03.31.323 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 4: 2 PUs, byte 105 values 1, 2 and 4 (or 1, 2 and 5); validating carrier is a fare owner Fare PU Change Carrier Byte Validating Application Component Fee 105 Carrier 1 1 $50.00 AA 2 Value 4: From among all fare 2 2 $25.00 BB 4* BB components within changed pricing 3 2 $25.00 AA 1 units, apply the highest change fee

All Fare Components 1. The validating carrier (BB) is a fare owner on the previous ticket Changed 2. BB has only a single byte 105 value on the previous ticket (value 4*) 3. Process fee application as if all fares contained byte 105 value 4* a. All pricing units have changed b. The highest change fee among all fare components within all pricing units is $50.00 4. Change fee to be assessed is $50.00

Fare Components 2 and 3 1. The validating carrier (BB) is a fare owner on the previous ticket Changed 2. BB has only a single byte 105 value on the previous ticket (value 4*) 3. Process fee application as if all fares contained byte 105 value 4* a. Only the second pricing unit has changed b. The highest change fee among all fare components within the second pricing unit is $25.00 4. Change fee to be assessed is $25.00

* Note: the outcome would be the same if Fare Component 2 contained byte 77 = 5.

Page E.03.31.324 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 5: 1 PU, byte 105 values 1 and 2, validating carrier is not a fare owner Fare PU Change Carrier Byte Validating Application Component Fee 105 Carrier 1 1 $50.00 AA 2 Value 2: From among all fare 2 1 $25.00 BB 1 CC components, changed and unchanged, 3 1 $25.00 AA 1 apply the highest change fee

All Fare Components 1. The validating carrier (CC) is not a fare owner on the previous ticket Changed 2. The most restrictive byte 105 value on the previous ticket is value 2 3. Process change fee application as if all fares contained byte 105 value 2 a. The highest change fee on the ticket is $50.00 4. Change fee to be assessed is $50.00

Fare Components 2 and 3 Same processing as above. It does not matter which fare components are changed. Changed

Page E.03.31.325 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 6: 1 PU, byte 105 values 1, 2 and 3, validating carrier is not a fare owner Fare PU Change Carrier Byte 105 Validating Application Component Fee Carrier 1 1 $50.00 AA 2 Value 2: From among all fare 2 1 $25.00 BB 3 CC components, changed and unchanged, 3 1 $25.00 AA 1 apply the highest change fee

All Fare Components 1. The validating carrier (CC) is not a fare owner on the previous ticket Changed 2. The most restrictive byte 105 value on the previous ticket is value 2 3. Process change fee application as if all fares contained byte 105 value 2 a. The highest change fee on the ticket is $50.00 4. Change fee to be assessed is $50.00

Fare Components 2 and 3 Same processing as above. It does not matter which fare components are changed. Changed

Page E.03.31.326 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 7: 2 PU, byte 105 values 1, 2 and 3, validating carrier is a fare owner Fare PU Change Carrier Byte 105 Validating Application Component Fee Carrier 1 1 $50.00 AA 2 Value 3: Apply the sum of the 2 2 $25.00 BB 3 BB change fees of all changed fare 3 2 $25.00 AA 1 components

All Fare Components 1. The validating carrier (BB) is a fare owner on the previous ticket Changed 2. BB has only a single value in byte 105 on the previous ticket 3. Process change fee application as if all fares contained byte 105 value 3 a. All fare components have changed b. Calculate the sum of the change fees of all changed fare components ($50+$25+$25) 4. Change fee to be assessed is $100.00 Fare Components 2 and 3 1. The validating carrier (BB) is a fare owner on the previous ticket Changed 2. BB has only a single value in byte 105 on the previous ticket 3. Process change fee application as if all fares contained byte 105 value 3 a. Fare components 2 and 3 have changed b. Calculate the sum of the change fees of all changed fare components (25+$25) 4. Change fee to be assessed is $50.00

Page E.03.31.327 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 8: 2 PU, byte 105 values 1 and 4 (or 1 and 5), validating carrier is not a fare owner Fare PU Change Carrier Byte Validating Application Component Fee 105 Carrier 1 1 $50.00 AA 4* Value 4: From among all fare components 2 2 $25.00 BB 1 CC within changed pricing units, apply the 3 2 $75.00 AA 1 highest change fee

All Fare Components 1. The validating carrier (CC) is not a fare owner on the previous ticket Changed 2. Most restrictive byte 105 value on the previous ticket is value 4* 3. Process change fee application as if all fares contained byte 105 value 4* a. PU1 has changed; the highest change fee of all fare components in PU1 is $50.00 b. PU2 has changed; the highest change fee of all fare components in PU1 is $75.00 c. The highest change fee among all fare components within PU1 and PU2 is $75.00 4. Change fee to be assessed is $75.00 Fare Component 1 1. The validating carrier (CC) is not a fare owner on the previous ticket Changed 2. Most restrictive byte 105 value on the previous ticket is value 4* 3. Process change fee application as if all fares contained byte 105 value 4* a. PU1 has changed; the highest change fee of all fare components in PU1 is $50.00 b. PU2 has not changed c. The highest change fee among all fare components within PU1 is $50.00 4. Change fee to be assessed is $50.00 Fare Component 2 1. The validating carrier (CC) is not a fare owner on the previous ticket Changed 2. Most restrictive byte 105 value on the previous ticket is value 4* or 3. Process change fee application as if all fares contained byte 105 value 4* Fare Component 3 a. PU1 has not changed Changed b. PU2 has changed; the highest change fee of all fare components in PU1 is $75.00 or c. The highest change fee among all fare components within PU1 and PU2 is $75.00 Fare Components 2 & 3 4. Change fee to be assessed is $75.00 Changed

* Note: the outcome would be the same if Fare Component 1 contained byte 77 = 5.

Page E.03.31.328 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Examples 9 through 16 illustrate scenarios in which new flight(s) are added to the ticketed itinerary.

Examples 9-13 use the following original ticket and cat31 data

Ticketed Itinerary: JNB-CAI-JNB PU1: JNB-CAI-JNB Dept 01Jan 08 Flt XX140 FBC MEE3MZA; RBD M FARE ZAR9000.00 JNB CAI Dept 31Jan 08 Flt XX280 FBC QEE1MZA; RBD Q FARE ZAR7000.00

JNB-CAI Category 31 Record 3 data: CAI-JNB Category 31 Record 3 data: Bytes 63-73 Byte 105 Bytes 63-73 Byte 105 Charge 1 Fee Application Charge 1 Fee Application 800.00ZAR 3 600.00ZAR 3 The data indicates that the change fee for the fare The data indicates that the change fee for the fare component being validated is ZAR800.00 and that the component being validated is ZAR600.00 and that the sum of change fees of all changed fare components in sum of change fees of all changed fare components in the journey is to be assessed. the journey is to be assessed.

Page E.03.31.329 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 9: no change to TKTD FLTs; change to TKTD PRICING (change to fare amount)

New Itinerary JNB-CAI-ROM-CAI-JNB

Dept 01Jan 08 Dept 15Jan 08 Flt XX140 Flt XX88 FBC MEE3MZA FBC HPXEG2 FARE ZAR9000.00 JNB CAI ROM Dept 31Jan 08 Dept 200Jan 08 Flt XX280 Flt XX99 FBC QEE1MZA FBC HPXEG2 FARE ZAR8000.00

When pricing the new itinerary in this manner: • New flights have been added to the journey. There is no change to the TKTD FLTs. There is a change to TKTD PRICING (CAI- JNB fare amount). • ZAR600.00 change fee applies (the sum of change fees of all changed fare components)

Page E.03.31.330 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 10: no change to TKTD FLTs or TKTD PRICING; change to RBD

New Itinerary JNB-CAI-ROM-CAI-JNB PU1: JNB-CAI-JNB PU2: CAI-ROM-CAI Dept 01Jan 08 Dept 15Jan 08 Flt XX140 Flt XX88 FBC MEE3MZA; RBD J FBC HPXEG2 JNB CAI ROM Dept 31Jan 08 Dept 20Jan 08 Flt XX280 Flt XX99 FBC QEE1MZA; RBD H FBC HPXEG2

When pricing the new itinerary in this manner: • New flights have been added to the journey. There is no change to the TKTD FLTs or TKTD PRICING. • The new flights (CAI-ROM and ROM-CAI) are priced in their own pricing unit, no change fee applies.

Page E.03.31.331 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 11: no change to TKTD FLTs; change to TKTD PRICING (fare break points)

New Itinerary JNB-CAI-ROM-CAI-JNB

Dept 01Jan 08 Dept 15Jan 08 Flt XX140 Flt XX88 |------FBC MEE3MZA ------| JNB CAI ROM Dept 31Jan 08 Dept 20Jan 08 Flt XX280 Flt XX99 |------FBC QEE3MZA ------|

When pricing the new itinerary in this manner: • New flights have been added to the journey. There is no change to the TKTD FLTs. There is a change to TKTD PRICING (fare break points of JNB-CAI and CAI-JNB fare components). • ZAR1400.00 change fee applies (the sum of change fees of all changed fare components).

Page E.03.31.332 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 12: no change to TKTD FLTs; change to TKTD PRICING (fare basis code)

New Itinerary JNB-CAI-ROM-CAI-JNB

Dept 01Jan 08 Dept 15Jan 08 Flt XX140 Flt XX88 FBC MEE3MZA FBC HPXEG2 JNB CAI ROM Dept 31Jan 08 Dept 20Jan 08 Flt XX280 Flt XX99 FBC YRT FBC HPXEG2

When pricing the new itinerary in this manner: • New flights have been added to the journey. There is no change to the TKTD FLTs. There is a change to TKTD PRICING (fare basis code of the CAI-JNB fare component). • ZAR600.00 change fee applies (the sum of change fees of all changed fare components).

Page E.03.31.333 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 13: change to TKTD FLTs; no change to TKTD PRICING

New Itinerary JNB-CAI-ROM-CAI-JNB

Dept 01Jan 08 Dept 15Jan 08 Flt XX70 Flt XX88 FBC MEE3MZA FBC HPXEG2 JNB CAI ROM Dept 01Feb 08 Dept 20Jan 08 Flt XX280 Flt XX99 FBC QEE1MZA FBC HPXEG2

When pricing the new itinerary in this manner: • New flights have been added to the journey. There are changes to TKTD FLTs of the JNB-CAI and CAI-JNB fare components. There is no change to TKTD PRICING. • ZAR1400.00 change fee applies (the sum of change fees for all changed fare components).

Page E.03.31.334 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 14: no change to TKTD FLTs or TKTD PRICING; one flight added; US/CA and international itineraries

Ticketed Itinerary and Pricing New Itinerary and Reprice Solution

BBB BBB Dept 15Jan 09 FC1 FC1 Flt VV333 Dept 01Jan 09 Dept 01Jan 09 FBC=YFBC2 Flt XX555 Flt XX555 FBC=YFBC1 FBC=YFBC1 CF=$75 CF=$75 AAA AAA FC3

FC2 FC2 CCC CCC Dept 01Feb 09 Dept 01Feb 09 Flt ZZ444 Flt ZZ444 FBC=YFBC3 FBC=YFBC3 CF=$50 CF=$50

The change fee application is dependent on the pricing unit construction of the reprice solution and the applicable value Of Byte 105, as shown here: and the applicable Byte 105* value is: when the reprice solution 1 2 3 4 5 includes a PU that contains FC3 and: then the change fee assessed shall be: no other FCs none none none none none FC1 and, optionally, FC2 none $75 none none $75 FC2 only none $75 none none $50

* When byte 105 values of YFBC1 and YFBC3 differ, this is the value determined using the logic on page 382.

Page E.03.31.335 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 15: no change to TKTD FLTs or TKTD PRICING; two consecutive flights added; US/CA and international itineraries

Ticketed Itinerary and Pricing w Itinerary and Reprice Solution

Dept 01Jan 09 Dept 01Jan 09 Flt XX555 Flt XX555 Dept 01Feb 09 FBC=YFBC1 FBC=YFBC1 Flt SS222 CF=$40 FC1 CF=$40 FC1 FBC=YFBC3 FC3 AAA BBB AAA BBB CCC Dept 01Apr 09 Dept 01Apr 09 Dept 01Mar 09 FC2 Flt VV777 FC2 Flt VV777 FC4 Flt ZZ999 FBC=YFBC2 FBC=YFBC2 FBC=YFBC4 CF=$60 CF=$60

The change fee application is dependent on the pricing unit construction of the reprice solution and the applicable value of Byte 105, as shown here: and the applicable Byte 105* value is: when the reprice solution includes a PU that contains: 1 2 3 4 5 then the change fee assessed shall be: FC3 and/or FC4 and FC2 and, optionally, FC1 none $60 none none $60 FC3 and/or FC4 and FC1 none $60 none none $40 FC3 and/or FC4 and no others none none none none none FC3 alone and a PU that contains FC4 alone

* When byte 105 values of YFBC1 and YFBC2, differ, this is the value determined using the logic on page 382.

Page E.03.31.336 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 16: no change to TKTD FLTs or TKTD PRICING; two nonconsecutive flights added, including one added to start of itinerary; US/CA and international itineraries Ticketed Itinerary and Pricing New Itinerary and Reprice Solution Dept 01Jan 09 Dept 01Jan 09 Flt XX555 Flt XX555 Dept 20Jan 09 FBC=YFBC1 FBC=YFBC1 Flt SS222 CF=$50 CF=$50 FBC=YFBC6 AAA Dept 15Jan 09 CCC AAA Dept 15Jan 09 CCC FC1 Flt ZZ444 FC1 Flt ZZ444 FBC=YFBC3 FC3 FBC=YFBC3 FC3 CF=$75 FC 0 CF=$75 FC5 BBB BBB FC2 Dept 15Feb 09 FC2 Dept 15Feb 09 Flt RR777 FC4 Flt RR777 FC4 FBC=YFBC2 FBC=YFBC2 EEE CF=$125 DDD EEE CF=$125 DDD Dept 01Feb 09 Dept 01Dec 08 Dept 01Feb 09 Flt VV999 Flt QQ111 Flt VV999 FBC=YFBC4 FBC=YFBC5 FBC=YFBC4 CF=$150 CF=$150

The change fee application is dependent on the pricing unit construction of the reprice solution and the applicable value of Byte 105, as shown here: and the applicable Byte 105* value is: when the reprice solution includes a PU that contains: 1 2 3 4 5 then the change fee assessed shall be†: FC0 and/or FC5 and FC4 and, optionally, FC1 and/or FC2 and/or FC3 none $150 none none $150 FC0 and/or FC5 and FC2 and, optionally, FC1 and/or FC3 none $150 none none $125 FC0 and/or FC5 and FC3 and, optionally, FC1 none $150 none none $75 FC0 and/or FC5 and FC1 and no others none $150 none none $50 FC0 and FC5 and no others none none none none none FC0 alone and a PU that contains FC5 alone

* When byte 105 values of YFBC1, YFBC2, YFBC3, and YFBC4 differ, this is the value determined using the logic on page 382. † When the conditions of two rows in this table are met, the change fee assessed shall be the higher of the two.

Page E.03.31.337 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Page E.03.31.338 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.6.3. Discount – Category 31 Amount (bytes 108-111)

Discount data in bytes 108-111 specifies whether any discount applies to the charge amount. Discounts are based on the passenger status at the time of previous ticket issuance. Valid values and their application are: • Value 1: discount applies to the penalty charge for a passenger who was an infant with or without a seat (any infant PTC) at the time of previous ticket issuance. • Value 2: discount applies to the penalty charge for a passenger who was a child (PTC = any child PTC) at the time of previous ticket issuance. • Value 3: discount applies to the penalty charge for a passenger who was a youth (PTC = any youth PTC) at the time of previous ticket issuance. • Value 4: discount applies to the penalty charge for a passenger who was a senior citizen (PTC = any senior citizen PTC) at the time of previous ticket issuance. • Value 5: discounts apply to the penalty charge for the passengers specified in the Category 19 provision from the previous fare. • Value 6: discounts apply to the penalty charge for the passengers specified in the Category 22 provision from the previous fare. • Value 7: discount applies to the penalty charge for a passenger who was an infant with a seat (PTC = INS) at the time of previous ticket issuance • Value 8: discount applies to the penalty charge for a passenger who was an infant without a seat (PTC = INF) at the time of previous ticket issuance • Value 9: No Penalty applies to a passenger who was an infant without a seat (PTC=INF) at the time of previous ticket issuance (penalty charge = 0.00), regardless of the presence/absence of data in Category 19. • Value 0: Discount applies to the penalty charge for a passenger who was an infant with a seat (PTC=INS) at the time of previous ticket issuance. A passenger who was an infant without a seat (PTC = INF) at the time of previous ticket issuance (penalty charge = 0.00), regardless of presence/absence of data in Category 19. • Value Blank: No application.

Page E.03.31.339 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Up to four discount values may be entered in the Discounts field (bytes 108-111). When the Discount field Processing will apply the percentage of discount to the applicable charge as specified in (bytes 108-111) includes these provision of this Category for the fare component being validated on the ticket being values: presented for change: 0, 1, 2, 5, 7, and/or 8 Category 19 3, 4, and/or 6 Category 22 Exception: When the Discount field (bytes 108-111) include values 0 or 9, infants without a seat (PTC=INF) pay no penalty, regardless of the presence/absence of data in Category 19.

When applying the percentage of discount specified in Category 19 or Category 22 to the penalty amount, if the data in Category 19 or 22 specifies an amount other than 0.00 and does not specify any percentage (e.g. specified fare), then there is no discount of the penalty charge. If the data in Categories 19 or 22 specifies 0.00 as the amount and does not specify any percentage, indicating the discounted fare for the applicable passenger is free, then the penalty charge is also free.

Discount data only applies to the penalty amount for the fare component being validated and does not apply to penalty amounts for other fare components on the ticket.

In the example, assume byte 104 = blank. Refer to the chart on page 318 for the corresponding byte 105 value when byte 104 = J or P.

Example 1 (assume all fares are published by the same carrier, passenger is a Child) PU Change Fee Byte Bytes 108-111 Application 105 Fare 1 1 50.00 1 2 (Cat 19=50%) Highest of all changed fare components Fare 2 1 40.00 1 1 (Cat 19=10%) within the Journey Fare 3 1 30.00 1 BLANK

All Fares Changed $40.00 Fare 1 and Fare 3 Changed $30.00 Only Fare 2 Changed $40.00

Page E.03.31.340 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.7. REISSUE/REVALIDATE THE TICKET AS DIRECTED BY THE TICKET TRANSACTION FIELDS

Once the change fee has been determined, the result is then used in connection with the lowest re-pricing solution obtained from the Table 988 to determine the additional collection/refund. The final calculation of the new transaction is then retained for comparison against any other tables which may be present in the string. If other tables are present in the string as OR, the process begins all over again until all tables have been exhausted. If results are obtained from multiple tables, then compare these results and quote the passenger the lowest additional collection amount, reissuing/revalidating the ticket according to the data in the TICKET TRANSACTION fields, using the new fare class obtained from the re-pricing and updating the endorsement box accordingly. If, after all tables have been exhausted, no re-pricing solution could be created (no match to a Record 3 or match and fail a Record 3), apply system assumption.

Ticket transaction data is present in Table 988 Advance Ticketing (bytes 122-137) and Transaction Restrictions (bytes 165-173) fields as well as Category 31 Type of Transaction (byte 107), Residual Penalty (byte 112), Residual/Penalty Hierarchy (byte 127), Form of Refund (byte 113), and Endorsement Requirements (byte 114) fields. The relationship among the TICKET TRANSACTION fields is AND; all restrictions must be validated in order to reissue/revalidate the ticket.

Page E.03.31.341 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.7.1. Advance Ticketing – Table 988 Ticket Reissue/revalidation (bytes 122-137)

The Advance Ticketing data in bytes 122-137 specifies ticketing requirements for the new transaction. This data applies whether the transaction is occurring using the same fare or new fares. Any data present in these bytes overrides any advance reservation and ticketing data as specified in Table 988 byte 97 or in the Category 5 for the new fare.

Ticketing/Reservation Requirement (byte 122) Byte 122 specifies when the ticket transaction must occur. When byte 122 is value X, the new transaction must occur at the same time as the change is requested. When byte 122 is value Y, the new transaction must occur any time prior to the date of departure of the new flight. Processing will determine the departure date of all new flights on the itinerary, and the new ticket must be issued prior to the departure of these flights. When byte 122 is value blank, processing will apply the advance ticketing information specified in bytes 123-137 (or if bytes 123-137 are blank, then apply Category 5 data being validated based on Table 988 byte 97 or the Category 5 of the new fare).

Ticket after Reservations/Ticket before Departure (bytes 123-137) The transaction requirement may be based on the date the new reservations are being made or the date of departure of the new pricing unit. • Time of day (bytes 123-126) after the new reservations are made (e.g. by 1430 hours after reservations are made); and/or • Period of elapsed time or day of week (bytes 127-131) after the new reservations are made (e.g. 24 hours after reservations are made). • Period of elapsed time before departure (bytes 133-136) (e.g. 7 days before departure). ⇒ Validation of the data in bytes 133-136 is against the departure from the origin of each pricing unit on the new itinerary. ⇒ Option byte 132 will specify whether the data in bytes 133-136 expresses the earliest time that ticketing is permitted or the latest time by which ticketing is required.

When data is present in both the ticket after reservations fields (bytes 123-131) and the ticket before departure fields (bytes 133-136), then byte 137 will indicate whether the earlier or the later of these restrictions applies to the new ticket transaction.

If data is present in both the Ticketing/Reservation Requirement (byte 122) and the Ticket after Reservations/Ticket before Departure (bytes 133-137) fields, then processing must meet the conditions in both.

Page E.03.31.342 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.7.2. Reissue Restrictions – Table 988 Ticket TRANSACTION (bytes 165-173)

The Transaction Restriction fields specify limitations on how the new ticket may be processed and who is permitted to reissue or revalidate the new ticket. The relationship among the Transaction Restriction fields is AND; all restrictions must be validated in order to reissue or revalidate the ticket. Data is these fields’ overrides any Sales Restriction date being revalidated based on Table 988 byte 107 or being validated for a new fares.

Who may reissue or revalidate the ticket?

Carrier Restriction (byte 165), Carrier Application Table 990 (bytes 166-173) Carrier Restriction (byte 165) and Carrier Application Table 990 (bytes 166-173) provide the ability to specify carriers that are or are not permitted to reissue the ticket. When byte 165 is value X, only the publishing or validating carrier of the previous fare on the fare component being validated may reissue or revalidate the ticket. When byte 165 is value Y, only the publishing or validating carrier of the previous fare on the fare component being validated or the carriers specified in Carrier Application Table 990 (bytes 166-173) may reissue or revalidate the ticket. Carrier Application Table 990 (bytes 166-173) specifies carriers that may or may not reissue the ticket, in addition to publishing or validating carrier as specified in Carrier Restriction byte 165. When bytes 165 and 166-173 are blank, then there are no restrictions on the carrier that may reissue or revalidate the ticket. Example

Table 988 Byte 165 Bytes 166-173 CXR Rest CXR Appl Table 990 Appl CXR Y X NW X AA $$ The data indicates that the ticket may only be reissued or revalidated by the publishing or validating carrier of the previous fare on the fare component being validated, or by any carrier other than NW or AA.

Page E.03.31.343 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.7.3. Type of Ticket Transaction – Category 31 Ticket Reissue (byte 107)

This field specifies whether the transaction must be a reissue (value A) or a revalidation (value B) transaction. When byte 107 is value Blank, then the transaction may be either a reissue or a revalidation.

4.7.4. Residual/Penalty – Category 31 Ticket Reissue (byte 112)

Once the change fee has been determined based on the AMOUNT fields, the result is then used in connection with the lowest re-pricing solution obtained from the Table 988 to determine the additional collection/refund. When a ticket is re-priced and results in a residual amount (residual amount is defined as when the value of the previous ticket that is to be used towards the purchase of the new ticket amount is greater than the new ticket amount), the Residual/Penalty field byte 112 indicates how to resolve the residual amount for the fare and the change fee. Byte 112 only applies if the fare component being validated contains a portion of travel which has been identified as changed, per Section 4.1.3. Identify all points of change. If the fare component being validated does not contain a portion of travel which has been identified as changed, then its byte 112 will not apply. When differing values of Residual/Penalty (byte 112) apply, refer to Residual/Penalty Hierarchy (byte 127) to determine which value to apply.

NOTE: When no changes have been made to the TKTD FLTS (marketing carrier, flight number, departure airport and date, and arrival airport and date) of any fare component on the previous ticket, then each fare component’s byte 112 will be considered, without regard to the process tags used.

Page E.03.31.344 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Valid values of this field are as follows: Value I Ignore the residual amount and add collect the penalty fee.

Value R Refund the residual amount and add collect the penalty.

Value S Subtract ⇒ If the residual amount is greater than the penalty, then subtract the penalty from the residual and refund the residual. ⇒ If the residual amount is less than the penalty, then subtract the residual amount from the penalty and add/collect the difference in penalty. ⇒ If residual equals penalty amount, then apply residual towards penalty.

Value N Subtract for Non-Refundable ⇒ If non-refundable fare is used in an itinerary with refundable fares; if residual is greater than penalty then subtract the penalty from the residual and ignore the difference. ⇒ If non-refundable fare is used in an itinerary with refundable fares; if penalty is greater than residual then subtract the residual from the penalty and add/collect the difference in penalty. ⇒ If residual equals penalty amount, then apply residual towards penalty

Blank Application of any residual amount is at the discretion of the subscriber.

Note: When value N is used and a non-refundable fare is NOT used in an itinerary with a refundable fare, then value N will have the same application as value Blank.

Page E.03.31.345 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1 (Value I)

Byte 112 = I Previous Fare = 1000.00 New Fare = 700.00 Penalty = 50.00

Previous 1000.00 - New 700.00 Residual Amount 300.00

• Value I indicates that the residual amount (300.00) should be ignored and the penalty (50.00) collected. • Processing will collect 50.00

Example 2 (Value R)

Byte 112 = R Previous Fare = 1000.00 New Fare = 700.00 Penalty = 50.00

Previous 1000.00 - New 700.00 Residual Amount 300.00

• Value R that the residual amount (300.00) should be refunded and the penalty (50.00) collected. • Processing will collect 50.00 and refund 300.00 as specified by byte 113.

Page E.03.31.346 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3 (Value S)

Byte 112 = S Previous Fare = 1000.00 New Fare = 700.00 Penalty = 50.00

Previous 1000.00 - New 700.00 Residual Amount 300.00

• Value S indicates to subtract. Residual Amount is greater than the Penalty Amount (300.00 > 50.00): Residual Amount 300.00 - Penalty Amount 50.00 Refund 250.00

• Processing will refund 250.00 as specified by byte 113.

Example 4 (Value S)

Byte 112 = S Previous Fare = 1000.00 New Fare = 980.00 Penalty = 50.00

Previous 1000.00 - New 980.00 Residual Amount 20.00

• Value S indicates to subtract. Residual Amount is less than the Penalty Amount (20.00 < 50.00):

Page E.03.31.347 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Penalty Amount 50.00 - Residual Amount 20.00 Difference 30.00

• Processing will collect 30.00.

Page E.03.31.348 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 5 (Value N)

Byte 112 = N There are non-refundable and refundable fares on the itinerary Previous Fare = 1000.00 New Fare = 700.00 Penalty = 50.00

Previous 1000.00 - New 700.00 Residual Amount 300.00

• Value N indicates to subtract. Residual Amount is greater than the Penalty Amount (300.00 > 50.00): Residual Amount 300.00 - Penalty Amount 50.00 Refund 250.00

• 250.00 difference is ignored.

Page E.03.31.349 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 6 (Value N)

Byte 112 = N There are non-refundable and refundable fares on the itinerary Previous Fare = 1000.00 New Fare = 980.00 Penalty = 50.00

Previous 1000.00 - New 980.00 Residual Amount 20.00

• Value N indicates to subtract. Residual Amount is less than the Penalty Amount (20.00 < 50.00): Penalty Amount 50.00 - Residual Amount 20.00 Difference 30.00

• Value N indicates that the difference in penalty amount (30.00) should be collected. • Processing will collect 30.00

Page E.03.31.350 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.7.5. Residual/Penalty Hierarchy (byte 127) The Residual/Penalty Hierarchy field (byte 127 indicates whether the most restrictive or least restrictive hierarchy should be applied when the Residual/Penalty field (byte 112) values are not the same for all fare components on the previous ticket. Byte 127 only applies if the fare component being validated contains a portion of travel which has been identified as changed, per Section 4.1.3. Identify all points of change. If the fare component being validated does not contain a portion of travel which has been identified as changed, then its byte 127 will not apply.

Valid values for this field are: Value blank Apply the Most Restrictive Hierarchy Value X Apply the Least Restrictive Hierarchy

When the fare components that contain a portion of travel which has been identified as changed, have differing values in the Residual/Penalty Hierarchy field (byte 127), process as if it was coded as value blank – Apply the Most Restrictive Hierarchy.

In the event the Residual/Penalty field (byte 112) values are not the same for all fare components on the previous ticket, the following steps will be used to determine which Residual/Penalty field (byte 112) value applies based upon the values coded within the Residual/Penalty Hierarchy field (byte 127).

Most Restrictive Hierarchy (byte 127 = Value blank – Most Restrictive)

For all fare components on the previous ticket that contain a portion of travel that has been identified as changed: 1. Are any fare components coded with byte 112 = I? a. If yes, value I will be applied. b. If no, continue to the next step. 2. Are any fare components coded with byte 112 = N? a. If yes, value N will be applied. b. If no, continue to the next step. 3. Are any fare components coded with byte 112 = R? a. If yes, value R will be applied. b. If no, value S will be applied.

Page E.03.31.351 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Least Restrictive Hierarchy (byte 127= Value X – Least Restrictive)

For all fare components on the previous ticket that contain a portion of travel that has been identified as changed: 1. Are any fare components coded with byte 112 = S? b. If yes, value S will be applied. c. If no, continue to the next step. 2. Are any fare components coded with byte 112 = R? b. If yes, value R will be applied. c. If no, continue to the next step. 3. Are any fare components coded with byte 112 = N? b. If yes, value N will be applied. c. If no, value I will be applied.

Page E.03.31.352 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

The following examples show how to apply the Residual/Penalty Hierarchy field (byte 127) values when multiple Residual/Penalty field (byte 112) values exist on a ticket being presented for a change.

Example 1 (byte 127 = Value blank)

Previous Ticket Fare Component Byte 112 Value Byte 127 Value Changed/Unchanged* WAS – NYC Value = R Value = blank Unchanged NYC – BOS Value = R Value = blank Changed BOS – WAS Value = N Value = blank Changed * Indicates whether the fare component being validated contains a portion of travel which has been identified as changed.

For all fare components on the previous ticket that contain a portion of travel which has been identified as changed: 1. Are any fare components coded with byte 112 = I? • No, continue to the next step. 2. Are any fare components coded with byte 112 = N? • Yes, the BOS-WAS fare component is coded with Value N. Value N will be applied.

Example 2 (byte 127 = Value X)

Previous Ticket Fare Component Byte 112 Value Byte 127 Value Changed/Unchanged* WAS – LON Value = N Value = X Changed LON – PAR Value = I Value = X Changed PAR – WAS Value = R Value = X Unchanged * Indicates whether the fare component being validated contains a portion of travel which has been identified as changed.

For all fare components on the previous ticket that contain a portion of travel that has been identified as changed: 1. Are any fare components coded with byte 112 = S? • No, continue to the next step. 2. Are any fare components coded with byte 112 = R?

Page E.03.31.353 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

• No, continue to the next step. 3. Are any fare components coded with byte 112 = N? • Yes, the WAS-LON fare component is coded with Value N. Value N will be applied.

Example 3 (Differing byte 127 values)

Previous Ticket Fare Component Byte 112 Value Byte 127 Value Changed/Unchanged* WAS – LON Value = R Value = X Unchanged LON – MAN Value = Blank Value = X Unchanged MAN – LON Value = Blank Value = X Changed LON – WAS Value = N Value = blank Changed * Indicates whether the fare component being validated contains a portion of travel which has been identified as changed.

As there are differing Residual/Penalty Hierarchy field (byte 112) values for fare components that contain a portion of travel which has been identified as changed, process as if it was coded as value blank – Apply the Most Restrictive Hierarchy.

For all fare components on the previous ticket that contain a portion of travel that has been identified as changed: 1. Are any fare components coded with byte 112 = I? • No, continue to the next step. 2. Are any fare components coded with byte 112 = N? • Yes, the LON-WAS fare component is coded with Value N. Value N will be applied.

Page E.03.31.354 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.7.6. Form of Refund – Category 31 Ticket Reissue (byte 113)

The Form of Refund field specifies the method in which any applicable refund amount will be returned to the passenger. Values for byte 113 are as follows:

Value S Scrip Value V Voucher Value M Miscellaneous Charge Order (MCO) Value Blank Original Form of Payment (OFOP)

Byte 113 should only be considered if after comparing the value of the old ticket and the new ticket and after processing the Charges (bytes 63-103) and Residual/Penalty (byte 112) fields, a refund is due to the passenger. If a refund is due, byte 113 values of all fare components will be considered. If a refund is not due, byte 113 has no application.

In the event byte 113 values are not the same for all fare components on the previous ticket, the following steps determine which byte 113 value applies.

For all fare components on the previous ticket: 1. Are any fare components coded with byte 113 = S? a. If yes; value S will be applied. b. If no; continue to the next step. 2. Are any fare components coded with byte 113 = V? a. If yes; value V will be applied. b. If no; continue to the next step. 3. Are any fare components coded with byte 113 = M? a. If yes; value M will be applied. b. If no; value Blank will be applied

Page E.03.31.355 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.7.7. Endorsement Requirements – Category 31 Ticket Reissue (byte 114)

The Endorsement fields specify any endorsement text that must appear on the reissued ticket. Valid values are as follows.

Value W Include the non-refundable amount of the new ticket in the endorsement box of the reissued ticket. This overrides any Category 18 provisions from the revalidated or new fare. Value X Include the higher non-refundable amount from either the previous or new ticket in the endorsement box of the reissued ticket. This overrides any Category 18 provisions from the revalidated or new fare. Value Y Include only Category 18 endorsement provisions from the new ticket. Value Blank Include the higher non-refundable amount from either the previous or new ticket in the endorsement box of the reissued ticket, in addition to any Category 18 endorsement provisions from the revalidated or new fare.

In the event byte 114 values are not the same for all fare components on the previous ticket, the following steps determine which byte 114 value applies.

For all fare components on the previous ticket: 1. Are any fare components coded with byte 114 = Blank? a. If yes, value Blank will be applied. b. If no, continue to the next step. 2. Are any fare components coded with byte 114 = X? a. If yes, value X will be applied. b. If no, continue to the next step 3. Are any fare components coded with byte 114 = W? a. If yes, value W will be applied. b. If no, value Y will be applied.

Page E.03.31.356 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.7.8. Domestic-International Combinations– Category 31 Ticket Reissue (bytes 116-124)

The Domestic-International Combinations fields specify whether the owning carrier of a domestic fare component on the itinerary allows override-eligible reissue provisions of its Category 31 and Table 988 to be overridden by those of an international fare component. The DOM/INTL COMB field (Category 31 byte 116) specifies whether permission is granted by the fare owner of the domestic fare component. Category 31 Bytes 117-124 contain a reference to a Carrier Table 990 which, when used, specifies the international fare owning carriers whose override-eligible reissue provision values may replace those of the domestic fare component. These fields only apply to domestic fare components. Processing will ignore these fields populated in an international fare component.

The valid values of Category 31 bytes 116 (DOM/INTL COMB) and 117-124 (Carrier Table 990) are as follows:

• Value Blank indicates that the values of override-eligible reissue provisions of a domestic fare component’s Record 3 may be replaced by those of an international fare component’s Record 3 only if both fare components are owned by the same carrier. • Value Y with no Carrier Table 990 coded (bytes 117-124 = 0000000) indicates that the values of override-eligible reissue provisions of a domestic fare component’s Record 3 may be replaced by those of a Record 3 of an international fare component owned by any carrier. • Value Y with a Table Carrier Table 990 coded (bytes 117-124 = 0000001 to 9999999) indicates that the values of override- eligible reissue provisions of a domestic fare component’s Record 3 may be replaced by those of a Record 3 of an international fare component owned by the owner of the domestic fare component or by any carrier found in the specified 990 Carrier Table. • Value N indicates that the values of override-eligible reissue provisions of a domestic fare component’s Record 3 may not be replaced by those of a Record 3 of an international fare component owned by any carrier

Edits prevent value "X" from being entered in byte 16 (Application Tag) of a Table 990 referenced in Category 31 bytes 117-124. All carriers found in a Table 990 referenced in bytes 117-124 may be selected to override.

Page E.03.31.357 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

When a Record 3 has been identified as subject to override, the values of all Category 31 and Table 988 action fields except the following are overridden: • Category 31 bytes 63-103 Penalty Amount Fields, with the following exceptions: o When processing does not match the domestic Record 3’s Table 988 byte 56 (Originally Scheduled Flight) and/or bytes 209-213 (Period/Unit), but does match them when their values are replaced by those of the selected-to-override international Record 3. o When Category 31 byte 50 (Change Indicator) of either the subject-to-override domestic Record 3 or the selected-to-override international Record 3 but not both is value N or P or J. • Category 31 bytes 116-124 Domestic-International Combinations • Table 988 Bytes 48-55 Same Point Table • Table 988 Bytes 58-65 Carrier Table. A domestic carrier can always use its own fares to replace itself, in addition to fares owned by carriers permitted by the international carrier’s Table 990. If the Table 990 referenced in the selected international fare component’s Table 988 contains the domestic fare owning carrier, with either negative or positive application, then that value is not processed. If the selected international carrier’s Table 988 contains 0000000 in bytes 58- 65 (indicating that itself – and no other carrier – may be the fare owner of the replacing fare), then the values of the domestic fare component’s override-eligible reissue provisions may be replaced by a fare owned by the domestic fare owning carrier or by the selected international fare owning carrier – and no other carrier. The domestic carrier’s Table 990 referenced in bytes 58-65 of its Table 988 is ignored. • Table 988 Byte 121 RBDs • Table 988 Byte 206 Stop values X and blank (Table 988 Byte 206 value Y is subject to override)

The values of Table 988 match/action fields are not overridden.

All match fields are validated normally, except Table 988 bytes 56 (Originally Scheduled Flight) and 209-213 (Period/Unit). These fields are validated normally and, if no-matched, their values are replaced with those of the selected-to-override international Record 3 and then validated a second time.

Page E.03.31.358 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Processing Steps

The following steps apply if the previous ticket contains both domestic and international fare components. These steps are provided for illustrative purposes only and in no way reflect how or in what order any subscriber must process the data, provided the results concur to the logic.

Page E.03.31.359 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Step 1. For each Category 31 Record 3 of each domestic fare component on the previous ticket, determine whether an override scenario exists and, if so, which international fare component(s) will be involved: A. Does Category 31 byte 116 (DOM/INTL) = value N? I. If yes, the Record 3 is not subject to override. Apply standard match processing to all Category 31 and Table 988 match fields and continue to Step 3. II. If no (that is, byte 116 (DOM/INTL) = Y or Blank), does the previous ticket contain any international FCs with the same fare owner as the domestic fare component being validated? a. If yes, the Record 3 of the domestic fare component is subject to override and each of the Category 31 Record 3s of the international fare component owned by the same carrier as the domestic fare component that is closest to the domestic fare component being validated are nominated to override that domestic Category 31 Record 3’s override- eligible reissue provisions. Continue to Step 1.B. b. If no, does Category 31 byte 116 (DOM/INTL) = value Y? i. If yes, do bytes 117-124 (Carrier Table 990) = value 0000000? 01. If yes, the Record 3 of the domestic fare component is subject to override and each of the Category 31 Record 3’s of the international fare component that is closest to the domestic fare component being validated are nominated to override the domestic Category 31 Record 3. Continue to Step 1.B. 02. If no, does the previous ticket contain any international FCs owned by a carrier named in Category 31 bytes 117-124 (Carrier Table 990)? x. If yes, the Record 3 of the domestic fare component is subject to override and each of the Category 31 Record 3’s of the international fare component owned by a carrier named in Category 31 bytes 117- 124 (Carrier Table 990) that is closest to the domestic fare component being validated are nominated to override the domestic Category 31 Record 3’s override-eligible reissue provisions. Continue to Step 1.B. y. If no, the Record 3 is not subject to override. Apply standard match processing to all Category 31 and Table 988 match fields and continue to Step 3. ii. If no, the Record 3 is not subject to override. Apply standard match processing to all Category 31 and Table 988 match fields and continue to Step 3.

Page E.03.31.360 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

B. Are the Category 31 Record 3s of two international FCs nominated to override (this may occur when two international FCs are equidistant from the domestic fare component)? I. If yes, each of the Category 31 Record 3s of the nominated fare component that precedes the domestic fare component (direction of travel) are selected to override the override-eligible reissue provisions of the subject-to-override Record 3. Continue to Step 2. II. If no, each of the Category 31 Record 3s of the single nominated fare component are selected to override the override- eligible reissue provisions of the subject-to-override Record 3. Continue to Step 2. Step 2. For each subject-to-override Record 3: A. Apply standard match processing to all Category 31 and Table 988 match fields. Is there a match? I. If yes, consider this a valid match. Continue to Step 3. II. If no, were any match fields no-matched other than Table 988 bytes 56 (Originally Scheduled Flight) and 209-213 (Period/Unit)? a. If yes, discard the Record 3. Continue to Step 3. b. If no, ignore Table 988 bytes 56 (Originally Scheduled Flight) and 209-213 (Period/Unit) and consider the Record 3 matched, pending completion of Step 4. Continue to Step 3. Step 3. Create permutations. Step 4. For each permutation:

IN STEP 4, “DOMESTIC RECORD 3” REFERS TO THE SUBJECT-TO-OVERRIDE RECORD 3 AND “ITS INTERNATIONAL RECORD 3” REFERS TO THE RECORD 3 WITHIN THE PERMUTATION THAT WAS SELECTED TO OVERRIDE THE DOMESTIC RECORD 3.

Page E.03.31.361 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

A. Is the domestic Record 3’s Category 31 byte 50 (Change Indicator) = N or P or J and its international Record 3’s Category 31 byte 50 = N or P or J? I. If yes, replace the values of all override-eligible action fields of the domestic Record 3 excluding the Penalty Amount Fields (Category 31 bytes 63-103) with those of its international Record 3. Continue to Step 5. II. If no, is the domestic Record 3’s Category 31 byte 50 = N or P or J and is its international Record 3’s Category 31 byte 50 ≠ N or P or J? a. If yes: i. Replace the values of all override-eligible action fields of the domestic Record 3 with those of its international Record 3 including the Penalty Amount Fields (Category 31 bytes 63-103). ii. Create a Table 988 sequence for the domestic Record 3 in which the values of all action fields are those of its international Record 3’s Table 988. iii. Continue to Step 5. b. If no, is the domestic Record 3’s Category 31 byte 50 ≠ N or P or J and is its international Record 3’s Category 31 byte 50 = N or P or J? i. If yes: 01. Replace the values of all override-eligible action fields of the domestic Record 3 with those of its international Record 3 including the Penalty Amount Fields (Category 31 bytes 63-103). 02. Ignore all Table 988 action fields of the domestic Record 3. 03. Continue to Step 5. ii. If no, were Table 988 bytes 56 (Originally Scheduled Flight) and 209-213 (Period/Unit) matched (that is, was the answer to Step 2.A “yes”)? 01. If yes, replace the values of all override-eligible action fields of the domestic Record 3 with those of its international Record 3 excluding the Penalty Amount Fields (Category 31 bytes 63-103). Continue to Step 5. 02. If no, replace the values of Table 988 byte 56 and bytes 209-213 of the domestic Record 3 with those of its international Record 3’s Table 988 and attempt to match. Is there a match? x. If yes, replace the values of all override-eligible action fields of the domestic Record 3 with those of its international Record 3 including the Penalty Amount Fields (Category 31 bytes 63-103). Continue to Step 5. y. If no, discard the permutation. Continue to Step 5. Step 5. Process action fields normally.

Page E.03.31.362 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Examples 1-9 – Step 1: Determine if subject to override and identify overriding fare component

Example 1: byte 116 = Blank, bytes 117-124 = 0000000

FPO —— FLL —— LAX —— YTO —— PAR CO AA CO AF

Assume fare breaks at all ticketed points.

AA FLL-LAX Cat31 Record 3 Bytes 6-13 Byte 116 Bytes 117-124 Table Number DOM/INTL COMB Carrier Table 990 1234567 Blank 0000000 The data indicates that only Record 3s of international FCs owned by carrier AA may be selected to override the override-eligible reissue provisions of this Record 3.

CO LAX-YTO Cat31 Record 3 Bytes 6-13 Byte 116 Bytes 117-124 Table Number DOM/INTL COMB Carrier Table 990 7654321 Blank 0000000 The data indicates that only Record 3s of international FCs owned by carrier CO may be selected to override the override-eligible reissue provisions of this Record 3.

Page E.03.31.363 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

• Apply Step 1 to AA FLL-LAX Record 3 1234567: Step 1. A. Category 31 byte 116 (DOM/INTL COMB) ≠ N. II. The previous ticket does not contain any international FCs with the same fare owner as the AA FLL-LAX fare component. b. Category 31 byte 116 (DOM/INTL COMB) ≠ Y. ii. The Record 3 is not subject to override.

• Apply Step 1 to CO LAX-YTO Record 3 7654321: Step 1. A. Category 31 byte 116 (DOM/INTL COMB) ≠ N. II. The previous ticket does contain an international FC with the same fare owner as the CO LAX-YTO fare component. a. The Record 3 of the CO LAX-YTO fare component is subject to override and each of the Category 31 Record 3s of the international fare component owned by the same carrier as the CO LAX-YTO fare component that is closest to the CO LAX-YTO fare component (that is, CO FPO-FLL) are nominated to override the subject-to-override Category 31 Record 3’s override-eligible reissue provisions. B. The Category 31 Record 3s of two international FCs are not nominated to override. II. Each of the Category 31 Record 3s of the single nominated fare component (CO FPO-FLL) are selected to override the override-eligible reissue provisions of the subject-to-override Record 3.

Page E.03.31.364 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2: byte 116 = Y, bytes 117-124 = 0000000, with same owner

LON AA AA AA TYO LAX NYC AF NH AA AF

PAR

Assume fare breaks at all ticketed points.

AA LAX-NYC and NYC-LAX Cat31 Record 3 Bytes 6-13 Byte 116 Bytes 117-124 Table Number DOM/INTL COMB Carrier Table 990 1111111 Y 0000000 The data indicates that Record 3s of international FCs owned by any carrier may be selected to override the override-eligible reissue provisions of this Record 3.

Page E.03.31.365 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

• Apply Step 1 to AA LAX-NYC Record 3 1111111: Step 1. A. Category 31 byte 116 (DOM/INTL COMB) ≠ N. II. The previous ticket does contain international FCs with the same fare owner as the AA LAX-NYC fare component. a. The Record 3 of the LAX-NYC fare component is subject to override and each of the Category 31 Record 3s of the international fare components owned by the same carrier as the AA LAX-NYC fare component that is closest to the AA LAX-NYC fare component (that is, AA TYO-LAX and AA NYC-LON) are nominated to override the subject-to-override Category 31 Record 3’s override-eligible reissue provisions. B. The Category 31 Record 3s of two international FCs are nominated to override. I. Each of the Category 31 Record 3s of the nominated fare component that precedes the AA LAX-NYC fare component (direction of travel) – that is, AA TYO-LAX – are selected to override the override-eligible reissue provisions of the subject-to-override Record 3.

• Apply Step 1 to AA NYC-LAX Record 3 1111111: Step 1. A. Category 31 byte 116 (DOM/INTL COMB) ≠ N. II. The previous ticket does contain international FCs with the same fare owner as the AA NYC-LAX fare component. a. The Record 3 of the AA NYC-LAX fare component is subject to override and each of the Category 31 Record 3s of the international fare component owned by the same carrier as the AA NYC-LAX fare component that is closest to the AA NYC-LAX fare component (that is, AA NYC-LON) are nominated to override the subject-to-override Category 31 Record 3’s override-eligible reissue provisions. B. The Category 31 Record 3s of two international FCs are not nominated to override. II. Each of the Category 31 Record 3s of the single nominated fare component (AA NYC-LON) are selected to override the override-eligible reissue provisions of the subject-to-override Record 3.

Page E.03.31.366 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3: byte 116 = Y, bytes 117-124 = 0000000, without same owner

LON VS NH AA TYO LAX NYC AF NH AA AF

PAR

Assume fare breaks at all ticketed points.

AA LAX-NYC and NYC-LAX Cat31 Record 3 Bytes 6-13 Byte 116 Bytes 117-124 Table Number DOM/INTL COMB Carrier Table 990 1111111 Y 0000000 The data indicates that Record 3s of international FCs owned by any carrier may be selected to override the override-eligible reissue provisions of this Record 3.

Page E.03.31.367 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

• Apply Step 1 to AA LAX-NYC Record 3 1111111: Step 1. A. Category 31 byte 116 (DOM/INTL COMB) ≠ N. II. The previous ticket does not contain any international FCs with the same fare owner as the AA LAX-NYC fare component. b. Category 31 byte 116 (DOM/INTL COMB) = Y. i. bytes 117-124 (Carrier Table 990) = 0000000. 01. The Record 3 of the AA LAX-NYC fare component is subject to override and each of the Category 31 Record 3’s of the international fare components that are closest to the AA LAX-NYC fare component (NH TYO-LAX and VS NYC-LON) are nominated to override the subject-to-override Category 31 Record 3. B. The Category 31 Record 3s of two international FCs are nominated to override. I. Each of the Category 31 Record 3s of the nominated fare component that precedes the AA LAX-NYC fare component (direction of travel) – that is, NH TYO-LAX – are selected to override the override-eligible reissue provisions of the subject-to-override Record 3.

Page E.03.31.368 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

• Apply Step 1 to AA NYC-LAX Record 3 1111111: Step 1. A. Category 31 byte 116 (DOM/INTL COMB) ≠ N. II. The previous ticket does not contain any international FCs with the same fare owner as the AA NYC-LAX fare component. b. Category 31 byte 116 (DOM/INTL COMB) = Y. i. bytes 117-124 (Carrier Table 990) = 0000000. 01. The Record 3 of the AA NYC-LAX fare component is subject to override and each of the Category 31 Record 3’s of the international fare components that are closest to the AA NYC-LAX fare component (NH LAX-TYO and AF PAR-NYC) are nominated to override the subject-to-override Category 31 Record 3. B. The Category 31 Record 3s of two international FCs are nominated to override. I. Each of the Category 31 Record 3s of the nominated fare component that precedes the AA NYC-LAX fare component (direction of travel) – that is, AF PAR-NYC – are selected to override the override-eligible reissue provisions of the subject-to-override Record 3.

Page E.03.31.369 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 4: byte 116 = Y, bytes 117-124 ≠ 0000000, with same owner

LON AA AA AA TYO LAX NYC BA NH AA AF

PAR

Assume fare breaks at all ticketed points.

AA LAX-NYC and NYC-LAX Cat31 Record 3 Bytes 6-13 Byte 116 Bytes 117-124 Table Number DOM/INTL COMB Carrier Table 990 3333333 Y 2424242 Carrier Table 990 #2424242 APPL CXR Byte 16 Bytes 17-19 Blank BA The data indicates that only Record 3s of international FCs owned by carriers AA and BA may be selected to override the override- eligible reissue provisions of this Record 3.

Page E.03.31.370 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

• Apply Step 1 to AA LAX-NYC Record 3 3333333: Step 1. A. Category 31 byte 116 (DOM/INTL COMB) ≠ N. II. The previous ticket does contain international FCs with the same fare owner as the AA LAX-NYC fare component. a. The Record 3 of the LAX-NYC fare component is subject to override and each of the Category 31 Record 3s of the international fare components owned by the same carrier as the AA LAX-NYC fare component that is closest to the AA LAX-NYC fare component (that is, AA TYO-LAX and AA NYC-LON) are nominated to override the subject-to-override Category 31 Record 3’s override-eligible reissue provisions. B. The Category 31 Record 3s of two international FCs are nominated to override. I. Each of the Category 31 Record 3s of the nominated fare component that precedes the AA LAX-NYC fare component (direction of travel) – that is, AA TYO-LAX – are selected to override the override-eligible reissue provisions of the subject-to-override Record 3.

• Apply Step 1 to AA NYC-LAX Record 3 3333333: Step 1. A. Category 31 byte 116 (DOM/INTL COMB) ≠ N. II. The previous ticket does contain international FCs with the same fare owner as the AA NYC-LAX fare component. a. The Record 3 of the AA NYC-LAX fare component is subject to override and each of the Category 31 Record 3s of the international fare component owned by the same carrier as the AA NYC-LAX fare component that is closest to the AA NYC-LAX fare component (that is, AA NYC-LON) are nominated to override the subject-to-override Category 31 Record 3’s override-eligible reissue provisions. B. The Category 31 Record 3s of two international FCs are not nominated to override. II. Each of the Category 31 Record 3s of the single nominated fare component (AA NYC-LON) are selected to override the override-eligible reissue provisions of the subject-to-override Record 3.

Page E.03.31.371 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 5: byte 116 = Y, bytes 117-124 ≠ 0000000, without same owner

LON VS NH AA TYO LAX NYC BA NH AA AF

PAR

Assume fare breaks at all ticketed points.

AA LAX-NYC and NYC-LAX Cat31 Record 3 Bytes 6-13 Byte 116 Bytes 117-124 Table Number DOM/INTL COMB Carrier Table 990 3333333 Y 2424242 Carrier Table 990 #2424242 APPL CXR Byte 16 Bytes 17-19 Blank BA The data indicates that only Record 3s of international FCs owned by carriers AA and BA may be selected to override the override- eligible reissue provisions of this Record 3.

Page E.03.31.372 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

• Apply Step 1 to AA LAX-NYC Record 3 2424242: Step 1. A. Category 31 byte 116 (DOM/INTL COMB) ≠ N. II. The previous ticket does not contain any international FCs with the same fare owner as the AA LAX-NYC fare component. b. Category 31 byte 116 (DOM/INTL COMB) = Y. i. Bytes 117-124 (Carrier Table 990) ≠ 0000000. 02. The previous ticket contains an international FC owned by a carrier named in Category 31 bytes 117-124 (Carrier Table 990) – that is, BA. x. The Record 3 of the AA LAX-NYC fare component is subject to override and each of the Category 31 Record 3’s of the international fare component owned by a carrier named in Category 31 bytes 117-124 (Carrier Table 990) that is closest to the AA LAX-NYC fare component (that is, BA LON-PAR) are nominated to override the subject-to-override Category 31 Record 3’s override-eligible reissue provisions B. The Category 31 Record 3s of two international FCs are not nominated to override. II. Each of the Category 31 Record 3s of the single nominated fare component (BA LON-PAR) are selected to override the override-eligible reissue provisions of the subject-to-override Record 3.

Page E.03.31.373 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

• Apply Step 1 to AA NYC-LAX Record 3 2424242: Step 1. A. Category 31 byte 116 (DOM/INTL COMB) ≠ N. II. The previous ticket does not contain any international FCs with the same fare owner as the AA NYC-LAX fare component. b. Category 31 byte 116 (DOM/INTL COMB) = Y. i. Bytes 117-124 (Carrier Table 990) ≠ 0000000. 02. The previous ticket contains an international FC owned by a carrier named in Category 31 bytes 117-124 (Carrier Table 990) – that is, BA. x. The Record 3 of the AA NYC-LAX fare component is subject to override and each of the Category 31 Record 3’s of the international fare component owned by a carrier named in Category 31 bytes 117-124 (Carrier Table 990) that is closest to the AA NYC-LAX fare component (that is, BA LON-PAR) are nominated to override the subject-to-override Category 31 Record 3’s override-eligible reissue provisions B. The Category 31 Record 3s of two international FCs are not nominated to override. II. Each of the Category 31 Record 3s of the single nominated fare component (BA LON-PAR) are selected to override the override-eligible reissue provisions of the subject-to-override Record 3.

Page E.03.31.374 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 6: byte 116 = Y, bytes 117-124 ≠ 0000000, without same owner, without 990 owners

LON VS NH AA TYO LAX NYC AF NH UA AF

PAR

Assume fare breaks at all ticketed points.

AA LAX-NYC Cat31 Record 3 Bytes 6-13 Byte 116 Bytes 117-124 Table Number DOM/INTL COMB Carrier Table 990 7777777 Y 5656565 Carrier Table 990 #5656565 APPL CXR Byte 16 Bytes 17-19 Blank BA Blank IB Blank JL Blank QF The data indicates that only Record 3s of international FCs owned by carriers AA, BA, IB, JL, and QF may be selected to override the override-eligible reissue provisions of this Record 3.

Page E.03.31.375 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

UA LAX-NYC Cat31 Record 3 Bytes 6-13 Byte 116 Bytes 117-124 Table Number DOM/INTL COMB Carrier Table 990 9999999 Y 8787878 Carrier Table 990 #8787878 APPL CXR Byte 16 Bytes 17-19 Blank AC Blank BD Blank LH Blank SQ Blank TG The data indicates that only Record 3s of international FCs owned by carriers UA, AC, BD, LH, SQ, and TG may be selected to override the override-eligible reissue provisions of this Record 3.

• Apply Step 1 to AA LAX-NYC Record 3 5656565: Step 1. A. Category 31 byte 116 (DOM/INTL COMB) ≠ N. II. The previous ticket does not contain any international FCs with the same fare owner as the AA LAX-NYC fare component. b. Category 31 byte 116 (DOM/INTL COMB) = Y. i. Bytes 117-124 (Carrier Table 990) ≠ 0000000. 02. The previous ticket does not contain an international FC owned by a carrier named in Category 31 bytes 117-124 (Carrier Table 990). y. The Record 3 of the AA LAX-NYC fare component is not subject to override.

Page E.03.31.376 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

• Apply Step 1 to UA NYC-LAX Record 3 8787878: Step 1. A. Category 31 byte 116 (DOM/INTL COMB) ≠ N. II. The previous ticket does not contain any international FCs with the same fare owner as the UA NYC-LAX fare component. b. Category 31 byte 116 (DOM/INTL COMB) = Y. i. Bytes 117-124 (Carrier Table 990) ≠ 0000000. 02. The previous ticket does not contain an international FC owned by a carrier named in Category 31 bytes 117-124 (Carrier Table 990). y. The Record 3 of the UA NYC-LAX fare component is not subject to override.

Page E.03.31.377 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 8: side trip

FC 1 (owner=AZ) FC2

BA AZ OA LON —– MIL —–—– ATH —– LON

AZ AP SIDE TRIP (MIL VCE R/T) VCE

Assume fare breaks at all ticketed points.

AZ MIL-VCE Cat31 Record 3 Bytes 6-13 Byte 116 Bytes 117-124 Table Number DOM/INTL COMB Carrier Table 990 1111111 Y 0000000 The data indicates that Record 3s of international FCs owned by any carrier may be selected to override the override-eligible reissue provisions of this Record 3.

AP VCE-MIL Cat31 Record 3 Bytes 6-13 Byte 116 Bytes 117-124 Table Number DOM/INTL COMB Carrier Table 990 4444444 Y 2552552 Carrier Table 990 #2552552 APPL CXR Byte 16 Bytes 17-19 Blank OA The data indicates that only Record 3s of international FCs owned by carriers AP and OA may be selected to override the override- eligible reissue provisions of this Record 3.

Page E.03.31.378 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

• Apply Step 1 to AZ MIL-VCE Record 3 1111111: Step 1. A. Category 31 byte 116 (DOM/INTL COMB) ≠ N. II. The previous ticket contains an international FC with the same fare owner as AZ MIL-VCE fare component. a. The Record 3 of the MIL-VCE fare component is subject to override and each of the Category 31 Record 3s of the international fare components owned by the same carrier as the MIL-VCE fare component that is closest to the MIL-VCE fare component (that is, AZ MIL-ATH) are nominated to override the subject-to-override Category 31 Record 3’s override-eligible reissue provisions. B. The Category 31 Record 3s of two international FCs are not nominated to override. II. Each of the Category 31 Record 3s of the single nominated fare component (AZ MIL-VCE) are selected to override the override-eligible reissue provisions of the subject-to-override Record 3.

• Apply Step 1 to AP VCE-MIL Record 3 4444444: Step 1. A. Category 31 byte 116 (DOM/INTL COMB) ≠ N. II. The previous ticket does not contain any international FCs with the same fare owner as the AP VCE-MIL fare component. b. Category 31 byte 116 (DOM/INTL COMB) = Y. i. Bytes 117-124 (Carrier Table 990) ≠ 0000000. 02. The previous ticket contains an international FC owned by a carrier named in Category 31 bytes 117-124 (Carrier Table 990) – that is, OA. x. The Record 3 of the AP VCE-MIL fare component is subject to override and each of the Category 31 Record 3’s of the international fare component owned by a carrier named in Category 31 bytes 117-124 (Carrier Table 990) that is closest to the AP VCE-MIL fare component (that is, OA ATH-LON) are nominated to override the subject-to-override Category 31 Record 3’s override-eligible reissue provisions B. The Category 31 Record 3s of two international FCs are not nominated to override. II. Each of the Category 31 Record 3s of the single nominated fare component (OA ATH-LON) are selected to override the override-eligible reissue provisions of the subject-to-override Record 3.

Page E.03.31.379 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 9: byte 116 = N

FPO —— FLL —— LAX —— YTO —— PAR CO AA CO AF

Assume fare breaks at all ticketed points.

AA FLL-LAX Cat31 Record 3 Bytes 6-13 Byte 116 Bytes 117-124 Table Number DOM/INTL COMB Carrier Table 990 1234567 N 0000000 The data indicates the override-eligible reissue provisions of this Record 3 may not be overridden.

CO LAX-YTO Cat31 Record 3 Bytes 6-13 Byte 116 Bytes 117-124 Table Number DOM/INTL COMB Carrier Table 990 7654321 N 0000000 The data indicates the override-eligible reissue provisions of this Record 3 may not be overridden.

• Apply Step 1 to AA FLL-LAX Record 3 1234567: Step 1. A. Category 31 byte 116 (DOM/INTL COMB) = N. I. Record 3 is not subject to override.

• Apply Step 1 to CO LAX-YTO Record 3 7654321: Step 1. A. Category 31 byte 116 (DOM/INTL COMB) = N. I. Record 3 is not subject to override.

Page E.03.31.380 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Examples 10A-10C – Step 2: Match processing for subject-to-override Record 3s

Examples 10A through 10C use the original itinerary, new itinerary, and Record 3 shown below. Assume fare breaks at all ticketed points.

Original Itinerary:

flown flown FPO —— FLL —— LAX —— YTO —— PAR CO AA CO AF flt#129 flt#353 15May08 20may08 01Jun08 01aug08

New Itinerary:

flown flown FPO —— FLL —— LAX —— YTO —— PAR CO AA CO AF flt#129 flt#999 15May08 20may08 02Jun08 15aug08

Page E.03.31.381 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

CO LAX-YTO Cat31 Record 3 PTC JNY Reissue Table Dom/Intl Carrier Bytes 14- Byte 26 988 Comb Table 16 Bytes 55-62 Byte 116 Bytes 117- 124 MIL A 9191919 Blank 0000000 Table 988 #9191919 Process Tag Orig Sked Period Unit Flight Bytes 209-211 Bytes 212-213 Bytes 21-22 Byte 56 2 B 2 Db

The data indicates that in order to match this Record 3, the following must be true: • Passenger status at the time of previous ticket issuance was MIL • The itinerary change request must be made after the passenger’s departure from origination of the journey • The itinerary change request must be made at least two days before scheduled departure of the LAX-YTO flight on the previous ticket.

Example 10A – all match fields match

• reissue date: 30May08 • passenger status on 01May08: MIL • all Category 31 and Table 988 match fields are matched

Apply Step 2 to the CO LAX-YTO Record 3:

Step 2. A. Apply standard match processing to all Category 31 and Table 988 match fields. There is a match. I. Consider this a valid match. Continue to Step 3.

Page E.03.31.382 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 10B – all match fields except PTC (Category 31 bytes 14-16) match

• reissue date: 30May08 • passenger status on 01May08: ADT • All Category 31 and Table 988 fields are matched except PTC (Category 31 bytes 14-16)

Apply Step 2 to the CO LAX-YTO Record 3:

Step 2. A. Apply standard match processing to all Category 31 and Table 988 match fields. There is not a match. II. A match field (Category 31 bytes 14-16 PTC) other than Table 988 bytes 56 (Originally Scheduled Flight) and 209-213 (Period/Unit) was no-matched. a. Discard the Record 3. Continue to Step 3.

Example 10C – all match fields match except Period/Unit (Table 988 bytes 209-213) match

• reissue date: 31May08 • passenger status on 01May08: MIL • All Category 31 and Table 988 fields are matched except Table 988 bytes 209-213 (Period/Unit)

Apply Step 2 to the CO LAX-YTO Record 3:

Step 2. A. Apply standard match processing to all Category 31 and Table 988 match fields. There is not a match. II. No match fields other than Table 988 bytes 209-213 (Period/Unit) were no-matched. b. Ignore Table 988 bytes 56 (Originally Scheduled Flight) and 209-213 (Period/Unit) and consider the Record 3 matched. Continue to Step 3.

Page E.03.31.383 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 11 – Steps 3-4: Create permutations and replace action field values This example illustrates the building of permutations and the replacement of override-eligible reissue provisions (action fields) in an itinerary comprised of one domestic fare component and one international fare component. The domestic fare component has five Category 31 Record 3s, some of which are matched normally (as in Example 10A), some of which are matched with the exception processing of Step 2.A.II.b as in Example 10C (shown below with an asterisk), and one of which is not matched (as in Example 10B). Three of the domestic fare component’s matched Category 31 Record 3s are subject to override and in each case the Category 31 Record 3s of the single international fare component are selected to override. The selected-to-override international fare component has four Category 31 Record 3s, one of which is no-matched. Category 31 Record 3s and Table 988s that were discarded in Step 2 are shown with strikethrough.

Cat31 Tbl# THEN 0001000 OR 0002000 OR 0003000 OR 0004000 OR 0005000 byte 116=Y byte 116=Y byte 116=Y byte 116=N byte 116=Y byte 50=blank byte 50=blank byte 50=blank byte 50=blank byte 50=N 988 Tbl# 1000000 2000000 3000000 4000000 0000000 988 Seq# 1 1 1* 1 2* 2 byte 56=B 2 byte 56=B 3 bytes 209-213=3,Db 3 bytes 209-213=3,Db 2 byte 56=B 3 3 bytes 209-213=blank byte 56=B bytes 209-213=blank International Record 3s Cat31 Tbl# THEN 0006000 OR 0007000 OR 0007000 OR 0009000 byte 50=blank byte 50=blank byte 50=blank byte 50=N 988 Tbl# 6000000 7000000 8000000 0000000 988 Seq# 1 1 1 byte 56=B 2 2 bytes 209-213=7,Db byte 56=B 3 2 bytes 209-213=2,Db 3 3 byte 32=B bytes 157-162=7,Db *Bytes 56 and/or 209-213 not matched.

Page E.03.31.384 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Apply Step 3 to all matched Record 3s:

Step 3. Create permutations. Note that the domestic permutations 12-14 are not subject to override because the Category 31 byte 116 = N in the domestic fares’ Record 3s.

Permutation Domestic Record 3 International Record 3 Domestic Record 3 CAT31 . T988 . T988SEQ CAT31 . T988 . T988SEQ Subject to Override? 1 = 0001000.1000000.2* & 0006000.60000000.1 yes 2 = 0001000.1000000.2* & 0006000.60000000.3 yes 3 = 0001000.1000000.2* & 0007000.70000000.2 yes 4 = 0001000.1000000.2* & 0009000 yes 5 = 0003000.3000000.1* & 0006000.60000000.1 yes 6 = 0003000.3000000.1* & 0006000.60000000.3 yes 7 = 0003000.3000000.1* & 0007000.70000000.2 yes 8 = 0003000.3000000.3 & 0006000.60000000.1 yes 9 = 0003000.3000000.3 & 0006000.60000000.3 yes 10 = 0003000.3000000.3 & 0007000.70000000.2 yes 11 = 0003000.3000000.1* & 0009000 yes 12 = 0003000.3000000.3 & 0009000 yes 13 = 0004000.4000000.3 & 0006000.60000000.1 no 14 = 0004000.4000000.3 & 0006000.60000000.3 no 15 = 0004000.4000000.3 & 0007000.70000000.2 no 16 = 0004000.4000000.3 & 0009000 no 17 = 0005000 & 0006000.60000000.1 yes 18 = 0005000 & 0006000.60000000.3 yes 19 = 0005000 & 0007000.70000000.2 yes 20 = 0005000 & 0009000 yes *Bytes 56 and/or 209-213 not matched.

Page E.03.31.385 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Apply Step 4 to all permutations:

Step 4. Permutation 1 A. Is the domestic Record 3’s Category 31 byte 50 (Change Indicator) = N or P or J and its international Record 3’s Category 31 byte 50 = N or P or J? No. II. Is a domestic Record 3’s Category 31 byte 50 = N or P or J and is its international Record 3’s Category 31 byte 50 ≠ N or P or J? No. b. Is the domestic Record 3’s Category 31 byte 50 ≠ N or P or J and is its international Record 3’s Category 31 byte 50 = N or P or J? No. ii. Were Table 988 bytes 56 (Originally Scheduled Flight) and 209-213 (Period/Unit) matched? No. 02. Replace the values of Table 988 byte 56 and bytes 209-213 of the domestic Record 3 withithose of its international Record 3’s Table 988 and attempt to match. There is not a match. y. Discard the permutation. Continue to Step 5.

Step 4. Permutation 2 A. Is the domestic Record 3’s Category 31 byte 50 (Change Indicator) = N or P or J and its international Record 3’s Category 31 byte 50 = N or P or J? No. II. Is a domestic Record 3’s Category 31 byte 50 = N or P or J and is its international Record 3’s Category 31 byte 50 ≠ N or P or J? No. b. Is the domestic Record 3’s Category 31 byte 50 ≠ N or P or J and is its international Record 3’s Category 31 byte 50 = N or P or J? No. ii. Were Table 988 bytes 56 (Originally Scheduled Flight) and 209-213 (Period/Unit) matched? No. 02. Replace the values of Table 988 byte 56 and bytes 209-213 of the domestic Record 3 with those of its international Record 3’s Table 988 and attempt to match. There is a match. x. Replace the values of all override-eligible action fields of the domestic Record 3 with those of its international Record 3 including the Penalty Amount Fields (Category 31 bytes 63-103). Continue to Step 5.

Step 4. Permutation 3 – identical to Permutation 2

Page E.03.31.386 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Step 4. Permutation 4 A. Is the domestic Record 3’s Category 31 byte 50 (Change Indicator) = N or P or J and its international Record 3’s Category 31 byte 50 = N or P or J? No. II. Is a domestic Record 3’s Category 31 byte 50 = N or P or J and is its international Record 3’s Category 31 byte 50 ≠ N or P or J? No. b. Is the domestic Record 3’s Category 31 byte 50 ≠ N or P or J and is its international Record 3’s Category 31 byte 50 = N or P or J? Yes. i. Do the following: 01. Replace the values of all override-eligible action fields of the domestic Record 3 with those of its Record 3 including the Penalty Amount Fields (Category 31 bytes 63-103). 02. Ignore all Table 988 action fields of the domestic Record 3. 03. Continue to Step 5. Step 4. Permutation 5 – identical to Permutation 1. Step 4. Permutation 6 and 7 – identical to Permutation 2.

Step 4. Permutation 8 A. Is the domestic Record 3’s Category 31 byte 50 (Change Indicator) = N or P or J and its international Record 3’s Category 31 byte 50 = N or P or J? No. II. Is a domestic Record 3’s Category 31 byte 50 = N or P or J and is its international Record 3’s Category 31 byte 50 ≠ N or P or J? No. b. Is the domestic Record 3’s Category 31 byte 50 ≠ N or P or J and is its international Record 3’s Category 31 byte 50 = N or P or J? No. ii. Were Table 988 bytes 56 (Originally Scheduled Flight) and 209-213 (Period/Unit) matched? Yes. 01. Replace the values of all override-eligible action fields of the domestic Record 3 with those of its international Record 3 excluding the Penalty Amount Fields (Category 31 bytes 63-103). 02. Continue to Step 5.

Step 4. Permutation 9 and 10 – identical to Permutation 8. Step 4. Permutations 11 and 12 – identical to Permutation 4. Step 4. Permutation 13, 14, 15, 16 – Step 4 not performed because no Record 3 in the permutation is subject to override.

Page E.03.31.387 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Step 4. Permutation 17 A. Is the domestic Record 3’s Category 31 byte 50 (Change Indicator) = N or P or J and its international Record 3’s Category 31 byte 50 = N or P or J? No. II. Is the domestic Record 3’s Category 31 byte 50 = N or P or J and is its international Record 3’s Category 31 byte 50 ≠ N or P or J? a. Yes. i. Replace the values of all override-eligible action fields of the domestic Record 3 with those of its international Record 3 including the Penalty Amount Fields (Category 31 bytes 63-103). ii. Create a Table 988 sequence for the domestic Record 3 in which the values of all action fields are those of its international Record 3’s Table 988. iii. Continue to Step 5

Step 4. Permutation 18 and 19 – identical to Permutation 17

Step 4. Permutation 20 A. Is the domestic Record 3’s Category 31 byte 50 (Change Indicator) = N or P or J and its international Record 3’s Category 31 byte 50 = N or P or J? Yes. I. Replace the values of all override-eligible action fields of the domestic Record 3 with those of its international Record 3. Continue to Step 5.

Page E.03.31.388 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.8. TEXT TABLE NUMBER 996 – BYTES 129-136 AND UNAVAILABLE DATA TAG – BYTE 145

When the Unavailable Data Tag field has a value of ‘X’ (unavailable data), the fare being re-priced should fail. When the Unavailable Data Tag field has a value of ‘Y’ (text data only), retrieve the referenced Text Table Number 996 for text display. Table Number 996 has no impact on itinerary pricing; therefore, treat the table as not applicable and continue processing. If a single table is coded with an Unavailable Data Tag field set to ‘Y’, the table would not be applicable. Manual reissue process applies. If a THEN, AND set is coded and the Unavailable Data Tag field has a value of ‘Y’ for the THEN table, only the AND table must be validated.

NOTE: Text Table Number 996 is not available at this time.

Page E.03.31.389 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1 (value X)

Record 3 THEN Bytes 55-62 Byte 145 Table 988 Unavailable Data Tag 222 X Processing will fail the table as a result of the presence of value X in Byte 145.

Example 2 (value X)

Record 3 THEN Bytes 55-62 Byte 145 Table 988 Unavailable Data Tag 222 X Record 3 OR Bytes 55-62 Byte 145 Table 988 Unavailable Data Tag 333 BLANK For the first table, processing will fail the table as a result of the presence of value X in byte 145; processing will read on to the next table and validate the reissue restrictions in the second table.

Page E.03.31.390 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3 (value X)

Record 3 THEN Bytes 55-62 Byte 145 Table 988 Unavailable Data Tag 222 X Record 3 AND Bytes 55-62 Byte 145 Table 988 Unavailable Data Tag 333 BLANK For the first table, processing will fail the table as a result of the presence of value X in byte 145; processing will read on to the next table and validate the reissue restrictions in the second table. (Note that relational indicator AND is not valid in Category 31 and causes processing to automatically read on to the next set, even if the first table were passed.)

Example 4 (value Y)

Record 3 THEN Bytes 14-16 Bytes 55-62 Bytes 129-136 BYTE 145 PTC Table 988 Text Tbl No. 996 Unavailable Data Tag BLANK BLANK 123 Y Text Table Number 123 = Waiver applies in the event of death of traveling companion. Record 3 AND Bytes 14-16 Bytes 55-62 Bytes 129-136 BYTE 145 PTC Table 988 Text Tbl No. 996 Unavailable Data Tag SRC 222 BLANK BLANK The data in the first table shows that the table contains text data only and is not applicable. The data in the second table indicates the Category 31 applies for senior citizen passenger types and reissue data applies. Processing will not apply data in the first table and will read the second table. Conditions in the AND Table must be satisfied to re-price the fare.

Page E.03.31.391 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 5 (value Y)

Record 3 THEN Bytes 14-16 Bytes 55-62 Bytes 129-136 BYTE 145 PTC Table 988 Text Tbl No. 996 Unavailable Data Tag BLANK BLANK 123 Y Text Table Number 123 = Waiver applies in the event of death of traveling companion. Record 3 AND Bytes 14-16 Bytes 55-62 Bytes 129-136 BYTE 145 PTC Table 988 Text Tbl No. 996 Unavailable Data Tag SRC 222 BLANK BLANK The data in the first table shows that the table contains text data only and is not applicable. The data in the second table indicates the Category 31 applies for senior citizen passenger types and reissue data applies. Processing will not apply data in the first table and will read the second table. Conditions in the OR Table must be satisfied to re-price the fare.

Page E.03.31.392 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.9. BUILDING A DYNAMIC HIERARCHY AND RBD HIERARCHY PROCESSING

The processing steps detailed in this section are applied to each partially or fully flown fare component on a reprice solution whose fare break points have changed. For the purpose of this section, “previous fares” refers to any fully or partially flown fare component that is replaced by the new fare.

4.9.1. Building a Dynamic Hierarchy

A dynamic hierarchy is built by the repricing system. One Way, Roundtrip, Public, and Private Fares will be merged into a single list sorted from highest to lowest amount to form the hierarchy. Roundtrip fares will be halved. All Private Fares that are available to both the passenger and reissuing agent or repricing system will be merged with all applicable Public Fares to create a single fare list.

The processing steps for building a dynamic hierarchy are:

1. Interrogate the fares database using the Origin and Destination of the replacing fare component. Find fares (Public and Private) that are valid for ticketing on the date the process tag indicates, and valid for travel on the new fare component. Include only those fares with the appropriate directionality and global indicator. 2. Filter the resulting list by validating footnote and rule Categories 1, 3, 13, 14, 15, 19-22, 25, and 35 (Security Table 983 only in Category 35). 3. Halve the roundtrip fare amounts. 4. Sort the resulting list by fare amount, highest to lowest. When multiple currencies exist, convert all to NUCs and sort the resulting list by NUC amount, highest to lowest. 5. Find the entry point into the hierarchy using the RBD hierarchy processing steps detailed in section 4.9.2.

Page E.03.31.393 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1: Building a Dynamic Hierarchy

Previous Ticketed Itinerary Fare component: BA LON-FRA MFLEX11 Ticketing date: 14OCT05 Travel date: 01NOV05

BA BA LON PAR FRA M M (FLOWN)

New Itinerary Replacing Fare: BA LON-BER New Travel date: 01NOV05 Date of Reissue: 01NOV05 Reprice Solution Indicates to use Tag 2 (Historical Ticket Issue Date fares).

BA BA LON PAR BER (FLOWN)

Processing Steps for Building a Dynamic Hierarchy

1. Find BA LON-BER fares (Public and Private) in effect for ticketing on 14OCT05, valid for travel 01NOV05. 2. Filter the list by validating only footnote and rule Categories 1, 3, 13, 14, 15, 19-22, 25 and 35 (Security Table 983 only in Category 35). 3. Halve the roundtrip fare amounts.

Page E.03.31.394 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4. Sort the resulting list by fare amount, highest to lowest.

Resulting Fare List

Public/ FARE OW Effective Prime Private CLASS /RT AMOUNT CUR Date RBD Public F 1 1100.00 GBP 17-Jan-05 F Public C 1 800.00 GBP 17-Jan-05 C Public Y 1 600.00 GBP 17-Jan-05 Y Public YRT 2 450.00 GBP 17-Jan-05 Y Public S14NRP 1 426.00 GBP 17-Jan-05 S Public KH21NR 2 350.00 GBP 17-Jan-05 K Public KL21NR 2 275.00 GBP 17-Jan-05 K Public K45SPC 1 260.00 GBP 17-Jan-05 K Public K60SPC 1 230.00 GBP 17-Jan-05 K Private MEE14NR 1 220.00 GBP 17-Jan-05 M Public KE14NR 2 201.00 GBP 17-Jan-05 K Public WEEKND 2 199.00 GBP 17-Jan-05 W Public ZSPCL 2 150.00 GBP 17-Jan-05 Z Public ZAP30 2 100.00 GBP 31-Mar-05 Z Note: Roundtrip fares have been halved.

5. Determine the entry point into the hierarchy using the RBD hierarchy processing steps detailed in section 4.9.2.

Page E.03.31.395 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2: Building a Dynamic Hierarchy

Previous Ticketed Itinerary Fare component: US WAS-PHL M14NR US PHL-NYC W14NR Ticketing date: 01NOV06 Travel date: 01FEB07 (WAS-PHL) 15FEB07 (PHL-NYC)

US US WAS PHL NYC M W (FLOWN)

New Itinerary Replacing Fare: US WAS-BOS New Travel date: 01FEB07 Date of Reissue: 01FEB07 Reprice Solution Indicates to use Tag 5 (Current fares)

US US WAS PHL BOS (FLOWN)

Processing Steps for Building a Dynamic Hierarchy

1. Find US WAS-BOS fares (Public and Private) in effect for ticketing on 01FEB07, valid for travel 01FEB07. 2. Filter the list by validating only footnote and rule Categories 1, 3, 13, 14, 15, 19-22, 25 and 35 (Security Table 983 only in Category 35). 3. Halve the roundtrip fare amounts.

Page E.03.31.396 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4. Sort the resulting list by fare amount, highest to lowest.

Resulting Fare List

Public/ FARE OW Effective Prime Private CLASS /RT AMOUNT CUR Date RBD Public F 1 1100.00 USD 17-Jan-05 F Public C 1 800.00 USD 17-Jan-05 C Public Y 1 600.00 USD 17-Jan-05 Y Public YOW 1 550.00 USD 17-Jan-05 Y Public BOW 1 426.00 USD 17-Jan-05 B Public BRT 2 350.00 USD 17-Jan-05 B Public KE14NR 2 275.00 USD 17-Jan-05 K Public KE21NR 2 260.00 USD 17-Jan-05 K Private WEAMX 2 230.00 USD 17-Jan-05 W Private VEAMS 2 220.00 USD 17-Jan-05 V Public QE14NR 2 201.00 USD 17-Jan-05 Q Public QE21NR 2 199.00 USD 17-Jan-05 Q Public VHE7NR 2 150.00 USD 17-Jan-05 V Public VLE7NR 2 100.00 USD 31-Mar-05 V Note: Roundtrip fares have been halved.

5. Determine the entry point into the hierarchy using the RBD hierarchy processing steps detailed in section 4.9.2.

Page E.03.31.397 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3: Building a Dynamic Hierarchy

Previous Ticketed Itinerary Fare component: AA WAS-DFW M14NR AM DFW-MEX H7MX Ticketing date: 01NOV06 Travel date: 29JAN07 (WAS-DFW) 15FEB07 (DFW-MEX)

AA AM WAS DFW MEX M H (FLOWN)

New Itinerary Replacing Fare: AM WAS-CUN New Travel date: 07FEB07 Date of Reissue: 03FEB07 Reprice Solution Indicates to use Tag 6 (Travel Commencement fares)

AA AM WAS DFW CUN (FLOWN)

Processing Steps for Building a Dynamic Hierarchy

1. Find AM WAS-CUN fares (Public and Private) in effect for ticketing on 29JAN07, valid for travel 29JAN07. 2. Filter the list by validating only footnote and rule Categories 1, 3, 13, 14, 15, 19-22, 25 and 35 (Security Table 983 only in Category 35). 3. Halve the roundtrip fare amounts.

Page E.03.31.398 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4. Sort the resulting list by fare amount, highest to lowest.

Resulting Fare List

Public/ FARE OW Effective Prime Private CLASS /RT AMOUNT CUR Date RBD Public F 1 2300.00 USD 17-Jan-05 F Public J 1 1313.00 USD 17-Jan-05 J Public Y 1 1024.00 USD 17-Jan-05 Y Public YRT 2 550.00 USD 17-Jan-05 Y Public BRT 1 526.00 USD 17-Jan-05 B Public KWO 2 144.50 USD 17-Jan-05 K Public KXO 2 134.50 USD 17-Jan-05 K Private WEAMX 2 133.00 USD 17-Jan-05 W Private VEAMX 2 125.00 USD 17-Jan-05 V Public QWONR 2 124.50 USD 17-Jan-05 Q Public QXONR 2 114.50 USD 17-Jan-05 Q Public TWONR 2 94.50 USD 17-Jan-05 T Public TXONR 2 74.50 USD 31-Mar-05 T Note: Roundtrip fares have been halved.

5. Determine the entry point into the hierarchy using the RBD hierarchy processing steps detailed in section 4.9.2.

Page E.03.31.399 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.9.2. RBD Hierarchy Processing

For each partially or fully flown fare component on a reprice solution:

I. Is all travel on the ticket being repriced wholly within US/CA? A. If yes, are all of the previous fares Normal Fares? i. If yes, do normal RBD validation on the replacing fare. RBD Hierarchy Processing is not required. ii. If no, build a dynamic hierarchy. Match the RBD Answer Table for the replacing fare component (See Match Process A). Match the RBD Answer Table for the previous fare component(s) (See Match Process B). All of the prime RBDs of the previous Special Fare(s) are entry points into the hierarchy. 1. If the amount of the replacing fare is equal to or higher than the amount of all entry points and the cabin of the replacing fare’s prime RBD is equal to or higher than the cabin of all of the previous fare’s prime RBDs PASS RBD Hierarchy processing for the replacing fare. 2. If the amount of the replacing fare is lower than any of the entry points and/or if the cabin of the replacing fare’s prime RBD, is lower than the cabin of any of the previous fare’s prime RBDs, FAIL the replacing fare. B. If no, are all of the previous fares Normal Fares? i. If yes, standard fare construction processing applies including normal RBD validation on the replacing fare. RBD Hierarchy processing is not required. ii. If no, are any of the previous fares being replaced by a Normal Fare? 1. If yes, match the RBD Answer Table for each flown sector (See Match Process C) and match the RBD Answer Table for the replacing fare component (See Match Process A). a. If the cabin of the replacing fare’s prime RBD is equal to or higher than the cabin of the booked RBD of each flown sector, PASS RBD Hierarchy processing for the replacing fare. b. If the cabin of the replacing fare’s prime RBD is lower than the cabin of the booked RBD for any flown sector, standard fare construction processing applies including normal RBD validation on the replacing fare.

Page E.03.31.400 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

2. If no, previous fares are being replaced by a Special Fare. a. If a primary and/or secondary sector on the primary carrier is flown, build a dynamic hierarchy. Match the RBD Answer Table for the replacing fare component (See Match Process A). Match the RBD Answer Table for the previous fare component(s) in which the owning carrier is the same as that of the replacing fare (See Match Process B). All of the prime RBDs of the previous Special Fare(s) in which the owning carrier is the same as that of the replacing fare are the entry points into the hierarchy. i. If the amount of the replacing fare is equal to or higher than the amount of all entry points and the cabin of the replacing fare’s prime RBD is equal to or higher than the cabin of the previous fare’s prime RBD, PASS RBD Hierarchy processing for the replacing fare. ii. If the amount of the replacing fare is lower than any of the entry points and/or if the cabin of the replacing fare’s prime RBD is lower than the cabin of any of the previous fare’s prime RBDs, FAIL the replacing fare. b. For each flown secondary carriers sector, match the RBD Answer Table for the flown secondary carrier’s sector (See Match Process C) and match the RBD Answer Table for the replacing fare component (See Match Process A) i. If the prime RBD of the replacing fare is in an equal or higher cabin than the booked RBD of each flown secondary carriers sector, PASS RBD Hierarchy processing for the replacing fare. ii. If the prime RBD of the replacing fare is in a lower cabin than the booked RBD of any flown secondary carriers sector, FAIL the replacing fare.

NOTE 1: When normal RBD validation applies, the booked RBD of each sector being validated must be a valid RBD for the replacing fare. Standard Record 1 and Record 6 processing applies without validating the availability requirements indicated in Restriction Tag (byte 114) of the RBD (Reservation Booking Designator) Table Number 999. NOTE 2: When multiple prime RBDs are listed on the replacing fare’s Record 1/Category 25 Record 3, at least one of those prime RBDs must be equal to or higher than all of the previous fares’ prime RBDs and cabins. NOTE 3: In the event an entry point into the hierarchy cannot be found, the cabin of the replacing fare must be equal to or higher than the cabin of the previous fare(s). NOTE 4: It is possible that when determining the entry point into the dynamic hierarchy, multiple fares with the same prime RBD may be present at two different levels. When this occurs, processing should consider the lowest of the fare amounts to be the entry point into the hierarchy.

Page E.03.31.401 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

RBD Answer Table Processing

Match Process A – (Replacing Fare Component Match Based on Prime RBD)

RBD Answer Table Data Element Matching Criteria Carrier Fare owning carrier of the replacing fare. (Bytes 4-6) Travel Effective/Discontinue Dates Travel date of the replacing fare component. (Bytes 22-27/Bytes 28-33) Loc 1/Loc 2 Origin and destination of the replacing fare component. (Bytes 36-47) Global Indicator Global indicator of the replacing fare component. (Bytes 34-35) First/Last Ticketing Dates Ticketing date of the original ticket. (Bytes 48-53/Bytes 54-59)

Match Process B – (Previous Fare Component Match Based on Prime RBD)

RBD Answer Table Data Element Matching Criteria Carrier Fare owning carrier of the previous fare. (Bytes 4-6) Travel Effective/Discontinue Dates Travel date of the previous fare component being validated. (Bytes 22-27/Bytes 28-33) Loc 1/Loc 2 Origin and destination of the previous fare component being (Bytes 36-47) validated. Global Indicator Global indicator of the previous fare component being validated. (Bytes 34-35) First/Last Ticketing Dates Ticketing date of the original ticket. (Bytes 48-53/Bytes 54-59)

Page E.03.31.402 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Match Process C – (Sector Match Based on Booked RBD)

RBD Answer Table Data Element Matching Criteria Carrier Marketing carrier of the flown sector being validated. (Bytes 4-6) Travel Effective/Discontinue Dates Travel date of the flown sector being validated. (Bytes 22-27/Bytes 28-33) Loc 1/Loc 2 Origin and destination of the flown sector being validated. (Bytes 36-47) Global Indicator Global indicator of the fare component of which the flown sector (Bytes 34-35) being validated is part. First/Last Ticketing Dates Ticketing date of the original ticket. (Bytes 48-53/Bytes 54-59)

The steps detailed in the following examples are numbered to correspond to the processing step that is being performed as outlined within the previous pages.

Page E.03.31.403 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 1: All travel wholly within US/CA – Normal Fare being replaced by a Normal Fare

Previous Ticketed Itinerary Fare Component: DL MCN-HNL YOW (Normal Fare) Prime RBD: Y

DL DL MCN ATL HNL Y Y (FLOWN)

New Itinerary Replacing Fare: DL MCN-OGG YOW 1200.00 USD (Normal Fare) Prime RBD: Y

DL DL MCN ATL OGG Y Y (FLOWN)

Processing

I. All travel on the ticket being repriced is wholly within US/CA A. The previous fare is a Normal Fare i. Do normal RBD validation on the replacing DL MCN-OGG YOW fare. RBD Hierarchy processing is not required.

Conclusion: All travel on the ticket being repriced is within US/CA and the previous fare was a Normal Fare. Do normal RBD validation on the replacing fare. RBD Hierarchy processing is not required.

Page E.03.31.404 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 2: All travel wholly within US/CA – Special Fare being replaced by a Normal Fare

Previous Ticketed Itinerary Fare Component: DL MCN-HNL BSPL (Special Fare) Prime RBD: B

DL DL MCN ATL HNL B B (FLOWN)

New Itinerary Replacing Fare: DL MCN-OGG YOW 1700.00 USD (Normal Fare) Prime RBD: Y

DL DL MCN ATL OGG B Y (FLOWN)

Page E.03.31.405 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Processing Steps

I. All travel on the ticket being repriced is wholly within US/CA A. The previous fare was a Special Fare ii. Build a dynamic hierarchy for the replacing DL MCN-OGG fare component.

Public/ FARE OW Effective Prime Private CLASS /RT AMOUNT CUR Date RBD Public F 1 3200.00 USD 17-Jan-05 F Public C 1 2700.00 USD 17-Jan-05 C Public YOW 1 1700.00 USD 17-Jan-05 Y Public YRT 2 1100.00 USD 17-Jan-05 Y Public BSPL 1 800.00 USD 17-Jan-05 B Public KH21NR 2 797.00 USD 17-Jan-05 K Public KL21NR 2 750.00 USD 17-Jan-05 K Public K60SPC 1 727.00 USD 17-Jan-05 K Public ME14RT 2 711.00 USD 17-Jan-05 M Public WEEKND 2 499.00 USD 17-Jan-05 W Public QE14NR 2 460.00 USD 17-Jan-05 Q Public ZAP30 2 379.00 USD 31-Mar-05 Z The prime RBD of the previous Special Fare, B, is the entry point into the hierarchy. (highlighted above)

Match the RBD Answer Table for the replacing DL MCN-OGG fare component (Match Process A) and match the RBD Answer Table for the previous DL MCN-HNL fare component (Match Process B).

RBD Answer Table Record Data (MCN-OGG) RBD Answer Table Record Data (MCN-HNL) Premium First Class Cabin F Premium First Class Cabin F First Class Cabin D First Class Cabin D Premium Business Class Cabin C Premium Business Class Cabin C Business Class Cabin A Business Class Cabin Premium Economy Class Cabin Y Premium Economy Class Cabin Y Economy Class Cabin B M V S Q Economy Class Cabin B M S Q

Page E.03.31.406 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

1. The amount of the replacing fare, YOW (1700.00), is higher than the amount of the entry point, B (800.00) and the cabin of the replacing fare’s prime RBD, Premium Economy Class, is higher than the cabin of the previous fare’s prime RBD, Economy Class. Pass RBD Hierarchy Processing for the replacing fare.

Conclusion: All travel on the ticket being repriced is within US/CA and the previous fare is a Special fare. The amount of the replacing fare is higher than the entry point into the hierarchy and the cabin of the replacing fare’s prime RBD is higher than the cabin of the previous fare’s prime RBD. The replacing fare passes RBD Hierarchy Processing.

Page E.03.31.407 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 3: All travel wholly within US/CA – Special Fare being replaced by a Special Fare

Previous Ticketed Itinerary Fare Component: UA CHI-LAX QUANR (Special Fare) Prime RBD: Q

UA UA CHI DEN LAX Q Q (FLOWN)

New Itinerary Replacing Fare: UA CHI-SFO M14NR 221.00 USD (Special Fare) Prime RBD: M

UA UA CHI DEN SFO Q M (FLOWN)

Page E.03.31.408 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Processing Steps

I. All travel on the ticket being repriced is wholly within US/CA A. The previous fare was a Special Fare ii. Build a dynamic hierarchy for the replacing UA CHI-SFO fare component.

Public/ FARE OW Effective Prime Private CLASS /RT AMOUNT CUR Date RBD Public F 1 3200.00 USD 17-Jan-05 F Public C 1 2700.00 USD 17-Jan-05 C Public Y 1 1700.00 USD 17-Jan-05 Y Public YUA 1 1100.00 USD 17-Jan-05 Y Public BUA 1 800.00 USD 17-Jan-05 B Public HUA 1 622.00 USD 17-Jan-05 H Public MUA 1 500.00 USD 17-Jan-05 M Public HE21NR 1 315.00 USD 17-Jan-05 H Public M14NR 1 221.00 USD 17-Jan-05 M Public WEEKND 2 129.00 USD 17-Jan-05 W Public QE14NR 2 127.00 USD 17-Jan-05 Q Private ZSPCL 2 98.00 USD 31-Mar-05 Z The prime RBD of the previous Special Fare, Q, is the entry point into the hierarchy. (highlighted above)

Match the RBD Answer Table for the replacing UA CHI-SFO fare component (Match Process A) and match the RBD Answer Table for the previous UA CHI-LAX fare component (Match Process B).

RBD Answer Table Record Data (CHI-SFO) RBD Answer Table Record Data (CHI-LAX)

Premium First Class Cabin F Premium First Class Cabin F

First Class Cabin D First Class Cabin D Premium Business Class Cabin C Premium Business Class Cabin C Business Class Cabin A Business Class Cabin A Premium Economy Class Cabin Y B Premium Economy Class Cabin Y Economy Class Cabin H M Q V S W Economy Class Cabin B M V S Q

Page E.03.31.409 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

1. The amount of the replacing fare, M14NR (221.00) is higher than the amount of the entry point, Q (127.00), and the cabin of the replacing fare’s prime RBD, Economy Class, is equal to the cabin of the previous fare’s prime RBD, Economy Class. Pass RBD Hierarchy Processing for the replacing fare.

Conclusion: All travel on the ticket being repriced is within US/CA and the previous fare is a Special Fare. The amount of the replacing fare is higher than the entry point into the hierarchy and the cabin of the replacing fare’s prime RBD is equal to the cabin of the previous fare’s prime RBD. The replacing fare passes RBD Hierarchy Processing.

Page E.03.31.410 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 4: All travel wholly within US/CA – Three Special Fares being replaced by a through Special Fare

Previous Ticketed Itinerary Fare Component: UA NYC-CHI VE7AP (Special Fare) UA CHI-DEN W14NR (Special Fare) UA DEN-SNA Q14NR (Special Fare) Prime RBD: NYC-CHI = V CHI-DEN = W DEN-SNA = Q

UA UA UA NYC CHI DEN SNA V W Q (FLOWN) (FLOWN)

New Itinerary Replacing Fare: UA NYC-SEA MUA 330.00 USD (Special Fare) Prime RBD: M

UA UA UA NYC CHI DEN SEA V W M (FLOWN) (FLOWN)

Page E.03.31.411 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Processing Steps

I. All travel on the ticket being repriced is wholly within US/CA A. The previous fare’s are Special Fares ii. Build a dynamic hierarchy for the replacing UA NYC-SEA fare component

Public/ FARE OW Effective Prime Private CLASS /RT AMOUNT CUR Date RBD Public F 1 2600.00 USD 17-Jan-05 F Public C 1 2100.00 USD 17-Jan-05 C Public Y 1 1700.00 USD 17-Jan-05 Y Public YRT 2 1100.00 USD 17-Jan-05 Y Public BRT 2 900.00 USD 17-Jan-05 B Public B14SPCL 2 762.00 USD 17-Jan-05 B Public H14NR 1 415.00 USD 17-Jan-05 H Public VE14NR 2 360.00 USD 17-Jan-05 V Public MUA 1 330.00 USD 17-Jan-05 M Public WE21NR 2 315.00 USD 17-Jan-05 W Private SPCL 2 300.00 USD 17-Jan-05 S Public QE45NR 2 297.00 USD 31-Mar-05 Q The prime RBDs of the previous Special Fares, V and W, are the entry points into the hierarchy. (highlighted above)

Page E.03.31.412 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Match the RBD Answer table for the replacing UA NYC-SEA fare component (Match Process A) and match the RBD Answer Table for the previous UA NYC-CHI and UA CHI-DEN fare component’s (Match Process B).

RBD Answer Table Record Data (NYC-SEA) Premium First Class Cabin F First Class Cabin D Premium Business Class Cabin A J C Business Class Cabin Premium Economy Class Cabin Y M Economy Class Cabin B H Q V W S

RBD Answer Table Record Data (NYC-CHI) RBD Answer Table Record Data (CHI-DEN) Premium First Class Cabin F Premium First Class Cabin F First Class Cabin D First Class Cabin D Premium Business Class Cabin C Premium Business Class Cabin C Business Class Cabin A Business Class Cabin A Premium Economy Class Cabin Y B Premium Economy Class Cabin Y Economy Class Cabin H M Q V Economy Class Cabin B M V S Q W

2. The amount of the replacing fare, MUA (330.00), is higher than the amount of one of the entry point’s, W (315.00), but is lower than the other entry point, V (360.00). Fail the replacing fare.

Conclusion: All travel on the ticket being repriced is within US/CA and the previous fares are Special Fares. The amount of the replacing fare is higher than one of the entry points into the hierarchy however it is lower than the other entry point into the hierarchy. The replacing fare fails RBD Hierarchy Processing.

Page E.03.31.413 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 5: All travel is not wholly within US/CA – Normal Fare being replaced by a Normal Fare – Primary and secondary sectors of the fare owning carrier are flown

Previous Ticketed Itinerary Fare Component: UA WAS-FRA COW (Normal Fare) Prime RBD: C UA is the fare owning carrier.

UA UA LH WAS NYC LON FRA Y C Y (FLOWN) (FLOWN)

New Itinerary Replacing Fare: UA WAS-SIN YOW 2200.00 USD (Normal Fare) Prime RBD: Y

UA UA LH WAS NYC LON SIN Y C Y (FLOWN) (FLOWN)

Page E.03.31.414 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Processing Steps

I. All travel on the ticket being repriced is not wholly within US/CA B. The previous fare is a Normal Fare being replaced by a Normal Fare i. Standard fare construction processing applies including normal RBD validation for all sectors of the replacing UA WAS-SIN YOW fare. RBD Hierarchy Processing is not required.

Conclusion: All travel on the ticket being repriced is not wholly within US/CA and the previous fare was a Normal Fare being replaced by a Normal Fare. Standard fare construction processing applies including normal RBD validation for all sectors on the replacing fare. RBD Hierarchy Processing is not required.

Page E.03.31.415 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 6: All travel is not wholly within US/CA – Special Fare being replaced by a Normal Fare – Primary and secondary sectors of the fare owning carrier are flown

Previous Ticketed Itinerary Fare Component: UA WAS-FRA C1 (Special Fare) Prime RBD: C UA is the fare owning carrier.

UA UA LH WAS NYC LON FRA F C C (FLOWN) (FLOWN)

New Itinerary Replacing Fare: UA WAS- SIN YOW 2200.00 USD (Normal Fare) Prime RBD: Y

UA UA LH WAS NYC LON SIN F C Y (FLOWN) (FLOWN)

Page E.03.31.416 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Processing Steps

I. All travel on the ticket being repriced is not wholly within US/CA B. The previous fare is not a Normal Fare ii. The previous fare is a Special fare being replaced by a Normal Fare 1. Match the RBD Answer Table for each flown sector, UA WAS-NYC and UA NYC-LON (Match Process C), and match the RBD Answer Table for the replacing UA WAS-SIN fare component (Match Process A).

RBD Answer Table Record Data (WAS-NYC) RBD Answer Table Record Data (NYC-LON) Premium First Class Cabin F Premium First Class Cabin F First Class Cabin D First Class Cabin Premium Business Class Cabin A J C Premium Business Class Cabin A J C Business Class Cabin Business Class Cabin Premium Economy Class Cabin Y Premium Economy Class Cabin Y Economy Class Cabin B M V Economy Class Cabin B M V W Q

RBD Answer Table Record Data (WAS-SIN) Premium First Class Cabin F First Class Cabin Premium Business Class Cabin A J C Business Class Cabin Premium Economy Class Cabin Y Economy Class Cabin B M V b. The cabin of the replacing fare’s prime RBD, Premium Economy Class, is lower than the cabin of the booked RBD for the flown WAS-NYC sector, Premium First Class. Standard fare construction processing applies including normal RBD validation on the replacing fare.

Conclusion: All travel on the ticket being repriced is not wholly within US/CA and the previous fare is a Special Fare being replaced by a Normal Fare. The cabin of the replacing fare’s prime RBD is lower than the cabin of the booked RBD for the flown WAS-NYC sector. Standard fare construction processing applies including normal RBD validation on the replacing fare.

Page E.03.31.417 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 7: All travel is not wholly within US/CA – Special Fare being replaced by a Special Fare – Only the secondary sector on the fare owning carrier is flown

Previous Ticketed Itinerary Fare Component: UA WAS-FRA Y1 (Special Fare) Prime RBD: Y UA is the fare owning carrier.

UA UA LH WAS NYC LON FRA C Y Y (FLOWN)

New Itinerary Replacing Fare: UA WAS-PAR MOW 333.00 USD (Special Fare) Prime RBD: M

UA UA LH WAS NYC LON PAR C M M (FLOWN)

Page E.03.31.418 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Processing Steps

I. All travel on the ticket being repriced is not wholly within US/CA B. The previous fare is not a Normal Fare ii. The previous fare is a Special Fare but is not being replaced by a Normal Fare 2. The previous fare is a Special Fare being replaced by a Special Fare a. The secondary sector on the primary carrier is flown:

Build a dynamic hierarchy for the replacing UA WAS-PAR fare component.

Public/ FARE OW Effective Prime Private CLASS /RT AMOUNT CUR Date RBD Public F 1 7475.00 USD 17-Jan-05 F Public C 1 4800.00 USD 17-Jan-05 C Public Y 1 1737.00 USD 17-Jan-05 Y Public YRT 2 790.00 USD 17-Jan-05 Y Public KH21NR 2 500.00 USD 17-Jan-05 K Public KL21NR 2 487.00 USD 17-Jan-05 K Public K45SPC 1 400.00 USD 17-Jan-05 K Public K60SPC 1 360.00 USD 17-Jan-05 K Public MOW 1 333.00 USD 17-Jan-05 M Public WEEKND 2 320.00 USD 17-Jan-05 W Private ZSPCL 2 300.00 USD 17-Jan-05 Z Public ZAP30 2 279.00 USD 31-Mar-05 Z

The prime RBD of the previous Special Fare, Y, is the entry point into the hierarchy. (highlighted above)

Page E.03.31.419 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Match the RBD Answer Table for the replacing UA WAS-PAR fare component (Match Process A) and match the RBD Answer Table for the previous UA WAS-FRA fare component (Match Process B).

RBD Answer Table Record Data (WAS-PAR) RBD Answer Table Record Data (WAS-FRA) Premium First Class Cabin F Premium First Class Cabin F First Class Cabin D First Class Cabin Premium Business Class Cabin C J Premium Business Class Cabin C Business Class Cabin A Business Class Cabin Premium Economy Class Cabin Y Premium Economy Class Cabin Y Economy Class Cabin B M V S Q Economy Class Cabin B M V Q

ii. The amount of the replacing fare, MOW (333.00), is lower than the entry point, Y (790.00). Fail the replacing fare.

Conclusion: All travel on the ticket being repriced is not wholly within US/CA and the previous fare is a Special Fare being replaced by a Special fare. The amount of the replacing fare is lower than the entry point into the hierarchy. The replacing fare fails RBD Hierarchy Processing.

Page E.03.31.420 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 8: All travel is not wholly within US/CA – Special Fare being replaced by a Special Fare – Only the secondary sector on the fare owning carrier is flown

Previous Ticketed Itinerary Fare Component: UA WAS-FRA Q14NR (Special Fare) Prime RBD: Q UA is the fare owning carrier.

UA UA LH WAS NYC LON FRA Q Q Q (FLOWN)

New Itinerary Replacing Fare: UA WAS-PAR M14OW 333.00 USD (Special Fare) Prime RBD: M

UA UA LH WAS NYC LON PAR Q M M (FLOWN)

Page E.03.31.421 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Processing Steps

I. All travel on the ticket being repriced is not wholly within US/CA B. The previous fare is not a Normal Fare ii. The previous fare is a Special Fare but is not being replaced by a Normal Fare 2. The previous fare is a Special Fare being replaced by a Special Fare a. The secondary sector on the primary carrier is flown:

Build a dynamic hierarchy for the replacing UA WAS-PAR fare component.

Public/ FARE OW Effective Prime Private CLASS /RT AMOUNT CUR Date RBD Public F 1 7475.00 USD 17-Jan-05 F Public C 1 4800.00 USD 17-Jan-05 C Public Y 1 1737.00 USD 17-Jan-05 Y Public YRT 2 790.00 USD 17-Jan-05 Y Public KH21NR 2 500.00 USD 17-Jan-05 K Public KL21NR 2 487.00 USD 17-Jan-05 K Public K45SPC 1 400.00 USD 17-Jan-05 K Public K60SPC 1 360.00 USD 17-Jan-05 K Public M14OW 1 333.00 USD 17-Jan-05 M Public WEEKND 2 320.00 USD 17-Jan-05 W Public QE14NR 2 300.00 USD 17-Jan-05 Q Public ZAP30 2 279.00 USD 31-Mar-05 Z

The prime RBD of the previous Special Fare, Q, is the entry point into the hierarchy. (highlighted above)

Page E.03.31.422 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Match the RBD Answer Table for the replacing UA WAS-PAR fare component (Match Process A) and match the RBD Answer Table for the previous UA WAS-FRA fare component (Match Process B).

RBD Answer Table Record Data (WAS-PAR) RBD Answer Table Record Data (WAS-FRA) Premium First Class Cabin F Premium First Class Cabin F First Class Cabin D First Class Cabin Premium Business Class Cabin C J Premium Business Class Cabin C Business Class Cabin A Business Class Cabin Premium Economy Class Cabin Y Premium Economy Class Cabin Y Economy Class Cabin B M V S Q Economy Class Cabin B M V Q

i. The amount of the replacing fare, M14OW (333.00), is higher than the amount of the entry point, Q (300.00), and the cabin of the replacing fare’s prime RBD, Economy Class, is equal to the cabin of the previous fare’s prime RBD, Economy Class. Pass RBD Hierarchy Processing for the replacing fare.

Conclusion: All travel on the ticket being repriced is not wholly within US/CA and the previous fare is a Special Fare being replaced by a Special Fare. The amount of the replacing fare is higher than the entry point into the hierarchy and the cabin of the replacing fare’s prime RBD is equal to the cabin of the previous fare’s prime RBD. The replacing fare passes RBD Hierarchy Processing.

Page E.03.31.423 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 9: All travel is not wholly within US/CA – Special Fare being replaced by a Special Fare – Primary sector of the fare owning carrier is flown, secondary sector on a secondary carrier is flown

Previous Ticketed Itinerary Fare Component: BA WAS-FRA M14NR (Special Fare) Prime RBD: M BA is the fare owning carrier.

AA BA BA WAS NYC LON FRA Q M M (FLOWN) (FLOWN)

New Itinerary Replacing Fare: BA WAS-SIN B14SPCL 762.00 USD (Special Fare) Prime RBD: B

AA BA BA WAS NYC LON SIN Q M B (FLOWN) (FLOWN)

Page E.03.31.424 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Processing Steps

I. All travel on the ticket being repriced is not wholly within US/CA B. The previous fare is not a Normal Fare ii. The previous fare is a Special Fare but is not being replaced by a Normal Fare 2. The previous fare is a Special Fare being replaced by a Special Fare a. The primary sector on the primary carrier is flown.

Build a dynamic hierarchy for the replacing BA WAS-SIN fare component.

Public/ FARE OW Effective Prime Private CLASS /RT AMOUNT CUR Date RBD Public F 1 9215.00 USD 17-Jan-05 F Public C 1 7216.00 USD 17-Jan-05 C Public Y 1 2300.00 USD 17-Jan-05 Y Public YRT 2 1100.00 USD 17-Jan-05 Y Public BRT 2 900.00 USD 17-Jan-05 B Public B14SPCL 2 762.00 USD 17-Jan-05 B Public MRT 1 723.00 USD 17-Jan-05 M Public VH21NR 1 700.00 USD 17-Jan-05 V USD Public ME14NR 1 650.00 17-Jan-05 M USD Public VL21NR 2 647.00 17-Jan-05 V USD Public QE14NR 2 630.00 17-Jan-05 Q Public ZAP30 2 599.00 USD 31-Mar-05 Z

The prime RBD of the previous Special Fare, M, is the entry point into the hierarchy. (highlighted above)

Page E.03.31.425 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Match the RBD Answer Table for the replacing BA WAS-SIN fare component (Match Process A) and match the RBD Answer Table for the previous BA WAS-FRA fare component (Match Process B).

RBD Answer Table Record Data (WAS-SIN) RBD Answer Table Record Data (WAS-FRA) Premium First Class Cabin F Premium First Class Cabin F First Class Cabin D First Class Cabin Premium Business Class Cabin C J Premium Business Class Cabin C Business Class Cabin A Business Class Cabin Premium Economy Class Cabin Y Premium Economy Class Cabin Y Economy Class Cabin B M V S Q Economy Class Cabin B M V Q

i. The amount of the replacing fare, B14SPCL (762.00), is higher than the amount of the entry point, M (650.00), and the cabin of the replacing fare’s prime RBD, Economy Class, is equal to the cabin of the previous fare’s prime RBD, Economy Class.

b. For the flown secondary carriers sector, match the RBD Answer Table for the AA WAS-NYC sector (Match Process C) and match the RBD Answer Table for the replacing BA WAS-SIN fare component (Match Process A).

RBD Answer Table Record Data (WAS-NYC) RBD Answer Table Record Data (WAS-SIN)

Premium First Class Cabin F Premium First Class Cabin F

First Class Cabin D First Class Cabin D

Premium Business Class Cabin A J C Premium Business Class Cabin C J

Business Class Cabin Business Class Cabin A Premium Economy Class Cabin Y Q Premium Economy Class Cabin Y Economy Class Cabin B M V Economy Class Cabin B M V S Q ii. The cabin of the replacing fare’s prime RBD, Economy Class, is lower than the cabin of the flown secondary carrier sectors booked RBD, Premium Economy Class. Fail the replacing fare.

Page E.03.31.426 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Conclusion: All travel on the ticket being repriced is not wholly within US/CA and the previous fare is a Special Fare being replaced by a Special Fare. The amount of the replacing fare is higher than the entry point into the hierarchy and the cabin of the replacing fare’s prime RBD is equal to the cabin of the previous fare’s prime RBD, however the cabin of the replacing fare’s prime RBD is in a lower cabin than the booked RBD of the flown secondary carrier sector. The replacing fare fails RBD Hierarchy Processing.

Page E.03.31.427 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 10: All travel is not wholly within US/CA – Special Fare being replaced by a Special Fare – Primary sector of the fare owning carrier is flown, secondary sector on a secondary carrier is flown

Previous Ticketed Itinerary Fare Component: BA WAS-FRA Q7SPL (Special Fare) Prime RBD: Q BA is the fare owning carrier.

AA BA BA WAS NYC LON FRA V Q Q (FLOWN) (FLOWN)

New Itinerary Replacing Fare: BA WAS-SIN M14NR 650.00 USD (Special Fare) Prime RBD: M

AA BA BA WAS NYC LON SIN V Q M (FLOWN) (FLOWN)

Page E.03.31.428 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Processing Steps

I. All travel on the ticket being repriced is not wholly within US/CA B. The previous fare is not a Normal Fare ii. The previous fare is a Special Fare but is not being replaced by a Normal Fare 2. The previous fare is a Special Fare being replaced by a Special Fare a. The primary sector on the primary carrier is flown.

Build a dynamic hierarchy for the replacing BA WAS-SIN fare component.

Public/ FARE OW Effective Prime Private CLASS /RT AMOUNT CUR Date RBD Public F 1 9215.00 USD 17-Jan-05 F Public C 1 7216.00 USD 17-Jan-05 C Public Y 1 2300.00 USD 17-Jan-05 Y Public YRT 2 1100.00 USD 17-Jan-05 Y Public BRT 2 900.00 USD 17-Jan-05 B Public B14SPCL 2 762.00 USD 17-Jan-05 B Public MRT 1 723.00 USD 17-Jan-05 M Public VH21NR 1 700.00 USD 17-Jan-05 V USD Public M14NR 1 650.00 17-Jan-05 M USD Public VL21NR 2 647.00 17-Jan-05 V USD Public QE14NR 2 630.00 17-Jan-05 Q Public ZAP30 2 599.00 USD 31-Mar-05 Z

The prime RBD of the previous special fare, Q, is the entry point into the hierarchy. (highlighted above)

Page E.03.31.429 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Match the RBD Answer Table for the replacing BA WAS-SIN fare component (Match Process A) and match the RBD Answer Table for the previous BA WAS-FRA fare component (Match Process B).

RBD Answer Table Record Data (WAS-SIN) RBD Answer Table Record Data (WAS-FRA) Premium First Class Cabin F Premium First Class Cabin F First Class Cabin D First Class Cabin Premium Business Class Cabin C J Premium Business Class Cabin C Business Class Cabin A Business Class Cabin Premium Economy Class Cabin Y Premium Economy Class Cabin Y Economy Class Cabin B M V S Q Economy Class Cabin B M V Q

i. The amount of the replacing fare, M14NR (650.00), is higher than the amount of the entry point, Q (630.00), and the cabin of the replacing fare’s prime RBD, Economy Class, is equal to the cabin of the previous fare’s prime RBD, Economy Class.

b. For the flown secondary carriers sector, match the RBD Answer Table for the flown AA WAS-NYC sector (Match Process C) and match the RBD Answer Table for the replacing BA WAS-SIN fare component (Match Process A).

RBD Answer Table Record Data (WAS-NYC) RBD Answer Table Record Data (WAS-SIN) Premium First Class Cabin F Premium First Class Cabin F First Class Cabin D First Class Cabin D Premium Business Class Cabin A J C Premium Business Class Cabin C J Business Class Cabin Business Class Cabin A Premium Economy Class Cabin Y Premium Economy Class Cabin Y Economy Class Cabin B Q M V Economy Class Cabin B M V S Q

i. The cabin of the replacing fare’s prime RBD, Economy Class, is equal to the cabin of the flown secondary carrier sectors booked RBD, Economy Class. Pass RBD Hierarchy Processing for the replacing fare.

Page E.03.31.430 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Conclusion: All travel on the ticket being repriced is not wholly within US/CA and the previous fare is a Special Fare being replaced by a Special Fare. The amount of the replacing fare is higher than the entry point into the hierarchy and the cabin of the replacing fare’s prime RBD is equal to the cabin of the previous fare’s prime RBD and it is equal to the cabin of the booked RBD of the flown secondary carriers sector. The replacing fare passes RBD Hierarchy Processing.

Page E.03.31.431 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 11: All travel is not wholly within US/CA – Two Normal Fares being replaced by a through Normal Fare

Previous Ticketed Itinerary Fare Components: AI BOM-PAR YOW (Normal Fare) BA PAR-MAN COW (Normal Fare) Prime RBD: BOM-PAR = Y PAR-MAN = C AI is the fare owning carrier for the BOM-PAR fare component and BA is the fare owning carrier for the PAR-MAN fare component.

AI BA BA BOM PAR LON MAN Y C C (FLOWN) (FLOWN)

New Itinerary Replacing Fare: AI BOM-MAN YOW 34000. INR (Normal fare) Prime RBD: Y

AI BA BA BOM PAR LON MAN Y C Y (FLOWN) (FLOWN)

Page E.03.31.432 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Processing Steps

I. All travel on the ticket being repriced is not wholly within US/CA B. All of the previous fares are Normal Fares being replaced by a through Normal Fare i. Standard fare construction processing applies, including normal RBD validation for all sectors on the replacing AI BOM- MAN YOW fare. RBD Hierarchy Processing is not required.

Conclusion: All travel on the ticket being repriced is not wholly within US/CA and all of the previous fares are Normal Fares being replaced by a through Normal Fare, standard fare construction processing applies including normal RBD validation for all sectors on the replacing fare. RBD Hierarchy Processing is not required.

Page E.03.31.433 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 12: All travel is not wholly within US/CA – Special Fare and a Normal Fare being replaced by a through Normal Fare

Previous Ticketed Itinerary Fare Component: AA WAS-LON M14NR (Special Fare) BA LON-FRA YOW (Normal Fare) Prime RBD: WAS-LON = M LON-FRA = Y AA is the fare owning carrier for the WAS-LON fare component and BA is the fare owning carrier for the LON-FRA fare component.

AA AA BA WAS NYC LON FRA M M Y (FLOWN) (FLOWN)

New Itinerary Replacing Fare: AA WAS-SIN YOW 2200.00 USD (Normal Fare) Prime RBD: Y

AA AA BA WAS NYC LON SIN M M Y (FLOWN) (FLOWN)

Page E.03.31.434 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Processing Steps

I. All travel on the ticket being repriced is not wholly within US/CA B. One of the previous fares is a Normal Fare however one is a Special Fare ii. One of the previous fares is a Special Fare and one is a Normal Fare being replaced by a through Normal Fare 1. Match the RBD Answer Table for each flown sector, AA WAS-NYC and AA NYC-LON (Match Process C) and match the RBD Answer Table for the replacing AA WAS-SIN fare component (Match Process A).

RBD Answer Table Record Data (WAS-NYC) RBD Answer Table Record Data (NCY-LON) Premium First Class Cabin F Premium First Class Cabin F First Class Cabin D First Class Cabin Premium Business Class Cabin A J C Premium Business Class Cabin A J C Business Class Cabin Business Class Cabin Premium Economy Class Cabin Y Premium Economy Class Cabin Y Economy Class Cabin B M V Economy Class Cabin B M V W Q RBD Answer Table Record Data (WAS-SIN) Premium First Class Cabin F First Class Cabin Premium Business Class Cabin A J C Business Class Cabin Premium Economy Class Cabin Y Economy Class Cabin B M V

a. The cabin of the replacing fare’s prime RBD, Premium Economy Class, is higher than the cabin of the flown WAS- NYC and NYC-LON sectors booked RBD, Economy Class. Pass RBD Hierarchy Processing for the replacing fare.

Conclusion: All travel on the ticket being repriced is not wholly within US/CA and one of the previous fares is a Special Fare and one is a Normal Fare being replaced by a through Normal Fare. The cabin of the replacing fare’s prime RBD is in a higher cabin than the booked RBDs for all of the flown sectors. The replacing fare passes RBD Hierarchy Processing.

Page E.03.31.435 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 13: All travel is not wholly within US/CA – Two Special Fares being replaced by a through Special Fare

Previous Ticketed Itinerary Fare Component: UA WAS-NYC V7AP (Special Fare) LH NYC-FRA QLXANE (Special Fare) Prime RBD: WAS-NYC = V NYC-FRA = Q UA is the fare owning carrier for the WAS-NYC fare component and LH is the fare owning carrier for the NYC-FRA fare component.

UA LH LH WAS NYC LON FRA V Q Q (FLOWN) (FLOWN)

New Itinerary Replacing Fare: LH WAS-MUC HLXANE 330.00 USD (Special Fare) Prime RBD: H

UA LH LH WAS NYC LON MUC V Q H (FLOWN) (FLOWN)

Page E.03.31.436 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Processing Steps

I. All travel on the ticket being repriced is not wholly within US/CA B. The previous fare is not a Normal Fare ii. The previous fare’s are Special Fares but are not being replaced by a through Normal Fare 2. The previous fare’s are Special Fares and are being replaced by a through Special Fare a. The primary sector on the primary carrier is flown.

Build a dynamic hierarchy for the replacing LH WAS-MUC fare component.

Public/ FARE OW Effective Prime Private CLASS /RT AMOUNT CUR Date RBD Public F 1 9215.00 USD 17-Jan-05 F Public C 1 7216.00 USD 17-Jan-05 C Public Y 1 2300.00 USD 17-Jan-05 Y Public YRT 2 1100.00 USD 17-Jan-05 Y Public B14SPCL 2 762.00 USD 17-Jan-05 B Public HHXANE 1 415.00 USD 17-Jan-05 H Public HHWANE 1 360.00 USD 17-Jan-05 H Public HLXANE 1 330.00 USD 17-Jan-05 H USD Public HLWANE 1 315.00 17-Jan-05 H USD Public QHANE 1 300.00 17-Jan-05 Q USD Public QLANE 1 297.00 31-Mar-05 Q The prime RBD of the previous LH Special Fare, Q, is the entry point into the hierarchy. (highlighted above)

Page E.03.31.437 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Match the RBD Answer Table for the replacing LH WAS-MUC fare component (Match Process A) and match the RBD Answer Table for the previous LH NYC-FRA fare component (Match Process B).

RBD Answer Table Record Data (WAS-MUC) RBD Answer Table Record Data (NYC-FRA) Premium First Class Cabin F Premium First Class Cabin F First Class Cabin D First Class Cabin Premium Business Class Cabin C J Premium Business Class Cabin C Business Class Cabin A Business Class Cabin Premium Economy Class Cabin Y Premium Economy Class Cabin Y Economy Class Cabin B H M V S Q Economy Class Cabin B M V Q

i. The amount of the replacing fare, HLXANE (330.00), is higher than the amount of the entry point, Q (297.00) and the cabin of the replacing fare’s prime RBD, Economy Class, is equal to the cabin of the previous fare’s prime RBD, Economy Class.

b. For the flown secondary carriers sector, match the RBD Answer Table for the UA WAS-NYC sector (Match Process C) and match the RBD Answer Table for the replacing LH WAS-MUC fare component (Match Process A).

RBD Answer Table Record Data (WAS-NYC) RBD Answer Table Record Data (WAS-MUC) Premium First Class Cabin F Premium First Class Cabin F First Class Cabin D First Class Cabin D Premium Business Class Cabin A J C Premium Business Class Cabin C J Business Class Cabin Business Class Cabin A Premium Economy Class Cabin Y Premium Economy Class Cabin Y Economy Class Cabin B M Q V Economy Class Cabin B H M V S Q

i. The cabin of the replacing fare’s prime RBD, Economy Class, is equal to the cabin of the flown secondary carrier sectors booked RBD, Economy Class. Pass RBD Hierarchy Processing for the replacing fare.

Page E.03.31.438 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Conclusion: All travel on the ticket being repriced is not wholly within US/CA and the previous fares are Special Fares being replaced by a through Special Fare. The amount of the replacing fare is higher than the entry point into the hierarchy and the cabin of the replacing fare’s prime RBD is equal to the cabin of the previous fare’s prime RBD and it is equal to the cabin of the booked RBD of the flown secondary carriers sector. The replacing fare passes RBD Hierarchy Processing.

Page E.03.31.439 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 14: All travel is not wholly within US/CA – Three Special Fares replaced by a through Special Fare

Previous Ticketed Itinerary Fare Component: UA RIC-WAS V7AP (Special Fare) UA WAS-LON W14NR (Special Fare) LH LON-FRA QFLX (Special Fare) Prime RBD: RIC-WAS = V WAS-LON = W LON-FRA = Q UA is the fare owning carrier for the RIC-WAS and WAS-LON fare components and LH is the fare owning carrier for the LON-FRA fare component.

UA UA UA LH RIC WAS NYC LON FRA V W W Q (FLOWN) (FLOWN) (FLOWN)

New Itinerary Replacing Fare: UA RIC-MUC B14SPCL 762.00 USD (Special Fare) Prime RBD: B

UA UA UA UA RIC WAS NYC LON MUC V W W B (FLOWN) (FLOWN) (FLOWN)

Page E.03.31.440 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Processing Steps

I. All travel on the ticket being repriced is not wholly within US/CA B. All of the previous fare’s are not Normal Fares ii. The previous fare’s are Special Fares but are not being replaced by a through Normal Fare 2. The previous fare’s are Special Fares being replaced by a through Special Fare a. The primary and secondary sectors on the primary carrier are flown.

Build a dynamic hierarchy for the replacing UA RIC-MUC fare component.

Public/ FARE OW Effective Prime Private CLASS /RT AMOUNT CUR Date RBD Public F 1 9215.00 USD 17-Jan-05 F Public C 1 7216.00 USD 17-Jan-05 C Public Y 1 2300.00 USD 17-Jan-05 Y Public YRT 2 1100.00 USD 17-Jan-05 Y Public BRT 2 900.00 USD 17-Jan-05 B Public B14SPCL 2 762.00 USD 17-Jan-05 B Public VE7NR 2 415.00 USD 17-Jan-05 V Public HE14NR 2 360.00 USD 17-Jan-05 H USD Public VE21NR 2 330.00 17-Jan-05 V USD Public WE21NR 2 315.00 17-Jan-05 W USD Private SPCL 2 300.00 17-Jan-05 S Public QE45NR 2 297.00 USD 31-Mar-05 Q

The prime RBDs of the previous UA Special Fares, V and W, are the entry points into the hierarchy. (highlighted above)

Page E.03.31.441 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Match the RBD Answer Table for the replacing UA RIC-MUC fare component (Match Process A) and match the RBD Answer Table for the previous UA RIC-WAS and UA WAS-LON fare components (Match Process B).

RBD Answer Table Record Data (RIC-MUC) Premium First Class Cabin F First Class Cabin D Premium Business Class Cabin A J C Business Class Cabin Premium Economy Class Cabin Y M Economy Class Cabin B H Q V W S

RBD Answer Table Record Data (RIC-WAS) RBD Answer Table Record Data (WAS-LON)

Premium First Class Cabin F Premium First Class Cabin F

First Class Cabin D First Class Cabin

Premium Business Class Cabin C J Premium Business Class Cabin C Business Class Cabin A Business Class Cabin Premium Economy Class Cabin Y Premium Economy Class Cabin Y Economy Class Cabin B M V S Q Economy Class Cabin B M V W Q i. The amount of the replacing fare, B14SPCL (762.00), is higher than the amount of the entry points, V (330.00) and W (315.00), and the cabin of the replacing fares prime RBD, Economy Class, is equal to the cabins of the previous fare’s prime RBDs, Economy Class. Pass RBD Hierarchy Processing for the replacing fare.

Conclusion: All travel on the ticket being repriced is not wholly within US/CA and the previous fares are Special Fares being replaced by a through Special Fare. The amount of the replacing fare is higher than the entry points into the hierarchy and the cabin of the replacing fare’s prime RBD is equal to the cabins of the previous fare’s prime RBDs. The replacing fare passes RBD Hierarchy Processing.

Page E.03.31.442 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example 15: All travel is not wholly within US/CA – Two Special Fares replaced by a through Special Fare

Previous Ticketed Itinerary Fare Component: TG BKK-DEN CSPL (Special Fare) UA DEN-CHI QUA (Special Fare) Prime RBD: BKK-DEN = C DEN-CHI = Q TG is the fare owning carrier for the BKK-DEN fare component and UA is the fare owning carrier for the DEN-CHI fare component.

TG UA UA BKK LAX DEN CHI C F Q (FLOWN) (FLOWN)

New Itinerary Replacing Fare: TG BKK-NYC CSPL 111100. THB (Special Fare) Prime RBD: C

TG UA UA BKK LAX DEN NYC C F F (FLOWN) (FLOWN)

Page E.03.31.443 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Processing Steps

I. All travel on the ticket being repriced is not wholly within US/CA B. All of the previous fare’s are not Normal Fares ii. The previous fare’s are Special Fares but are not being replaced by a through Normal Fare 2. The previous fare’s are Special Fares being replaced by a through Special Fare a. The primary sector on the primary carrier is flown.

Build a dynamic hierarchy for the replacing TG BKK-NYC fare component.

Public/ FARE OW Effective Prime Private CLASS /RT AMOUNT CUR Date RBD Public F 1 219215. THB 17-Jan-05 F Public C 1 217216. THB 17-Jan-05 C Public Y 1 214300. THB 17-Jan-05 Y Public CSPL 1 111100. THB 17-Jan-05 C Public BRT 2 80900. THB 17-Jan-05 B Public B14SPCL 2 70762. THB 17-Jan-05 B Public MAPOD 1 60415. THB 17-Jan-05 M Public MAP6MD 2 60160. THB 17-Jan-05 M THB Public HAPOD 1 51030. 17-Jan-05 H THB Public HAP6MD 2 51000. 17-Jan-05 H THB Private QAPOD 1 43000. 17-Jan-05 Q Public QAP6MD 2 42900. THB 31-Mar-05 Q

The prime RBDs of the previous TG Special Fare, C, is the entry point into the hierarchy. (highlighted above)

Page E.03.31.444 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Match the RBD Answer Table for the replacing TG BKK-NYC fare component (Match Process A) and match the RBD Answer Table for the previous TG BKK-DEN fare component (Match Process B).

RBD Answer Table Record Data (BKK-NYC) RBD Answer Table Record Data (BKK-DEN)

Premium First Class Cabin F Premium First Class Cabin F

First Class Cabin D First Class Cabin

Premium Business Class Cabin J Premium Business Class Cabin Business Class Cabin C Business Class Cabin C Premium Economy Class Cabin Y Premium Economy Class Cabin Y Economy Class Cabin B M H Q Economy Class Cabin B M H Q V i. The amount of the replacing fare, CSPL (111100.), is equal to the amount of the entry point, C (111100.), and the cabin of the replacing fares prime RBD, Business Class, is equal to the cabin of the previous fare’s prime RBD, Business Class.

b. For the flown secondary carriers sector, match the RBD Answer Table for the UA LAX-DEN sector (Match Process C) and match the RBD Answer Table for the replacing TG BKK-NYC fare component (Match Process A).

RBD Answer Table Record Data (LAX-DEN) RBD Answer Table Record Data (BKK-NYC)

Premium First Class Cabin F Premium First Class Cabin F

First Class Cabin D First Class Cabin D

Premium Business Class Cabin C Premium Business Class Cabin J Business Class Cabin J A P Business Class Cabin C Premium Economy Class Cabin Y B Premium Economy Class Cabin Y Economy Class Cabin B M H Q V S W Economy Class Cabin B M H Q

ii. The cabin of the replacing fare’s prime RBD, Business Class, is lower than the cabin of the flown secondary carrier sector’s booked RBD, Premium First Class. Fail the replacing fare.

Page E.03.31.445 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Conclusion: All travel on the ticket being repriced is not wholly within US/CA and the previous fares are Special Fares being replaced by a through Special Fare. The amount of the replacing fare is equal to the entry point into the hierarchy and the cabin of the replacing fare’s prime RBD is equal to the cabin of the previous fare’s prime RBD, however the cabin of the replacing fare’s prime RBD is in a lower cabin than the booked RBD of the flown secondary carrier’s sector. The replacing fare fails RBD Hierarchy Processing.

Page E.03.31.446 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.10. FARE BREAK/JOURNEY VALIDATION

This section defines the application of the following Table 988 Fares fields when fare break points differ between the previous ticket and the re-price solution:

Rule Indicator byte 57 Carrier Application Table990 bytes 58-65 Tariff Number bytes 66-68 Rule Number bytes 69-72 Indicator and Fare Class Code (bytes 73 and 74-81) Fare Type Code bytes 82-84 Fare Type Table 974 byte 214-221 Same byte 85 Normal/Special byte 87 OW/RT byte 88 Exclude Public/Private byte 111 Expand Keep byte 112 Seasonality/Day of Week Indicator Tbl 966 bytes 138-145

Page E.03.31.447 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.10.1. Fare Component Mapping

When fare break points change, the mapping logic described below is used to determine the fare components on the re-price solution, if any, to which Table 988 Fares field listed above apply.

Note: that all geographic criteria in this logic must match in both direction of travel and direction of fare selection.

International Tickets

For the purposes of this processing, international tickets are those in which all ticketed points are not in the same country (USA and Canada are considered one country). Processing of international tickets is as follows. Note: that all geographic criteria in this logic must match in both direction of travel and direction of fare selection.

1. For each fare component on the previous ticket, determine if the fare component has the same origin and destination cities as any as yet un-mapped fare component on the re-price solution (city/city mapping). a. If yes, the fare component on the previous ticket is mapped to the first such fare component on the re-price solution. b. If no, the fare component on the previous ticket remains as yet unmapped. 2. For each as yet unmapped fare component on the previous ticket, determine if there is any as yet un-mapped fare component on the re-price solution that has the same origination city and the same destination country as the fare component on the previous ticket (city/country mapping). a. If yes, the fare component on the previous ticket is mapped to the first such fare component on the re-price solution. b. If no, the fare component on the previous ticket remains as yet unmapped 3. For each as yet unmapped fare component on the previous ticket, determine if there is any as yet un-mapped fare component on the re-price solution that has the same origination and destination countries as the fare component on the previous ticket (country/country mapping). a. If yes, the fare component on the previous ticket is mapped to the first such fare component on the re-price solution. b. If no, the fare component on the previous ticket remains as yet unmapped. 4. For each as yet unmapped fare component on the previous ticket, determine if there is any as yet un-mapped fare component on the re-price solution that has the same origination country and the same destination ATPCO Zone as the fare component on the previous ticket (country/sub-area mapping). a. If yes, the fare component on the previous ticket is mapped to the first such fare component on the re-price solution.

Page E.03.31.448 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

b. If no, the fare component on the previous ticket remains as yet unmapped. 5. For each as yet unmapped fare component on the previous ticket, determine if there is any as yet un-mapped fare component on the re-price solution that has the same origination and destination ATPCO Zones as the fare component on the previous ticket (sub-area/sub-area mapping). a. If yes, the fare component on the previous ticket is mapped to the first such fare component on the re-price solution. b. If no, the fare component on the previous ticket remains unmapped.

Domestic Tickets

For the purposes of this processing, domestic tickets are those in which all ticketed points are in the same country (USA and Canada are considered one country). Processing of domestic tickets is as follows:

1. For each fare component on the previous ticket: a. Determine if the fare component has the same origin and destination cities as any as yet un-mapped fare component on the re-price solution (city/city mapping). NOTE: both direction of travel and direction of fare selection must be matched. i. If yes, the two fare components are mapped to each other. ii. If no, the fare component on the previous ticket is not mapped to any fare component on the re-price solution.

Page E.03.31.449 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

4.10.2. Application of “Fares” fields when Fare Break Points Change

The following Fares fields (listed below) are referred to in this section as the “Targeted Table 988 re-price restrictions”.

Rule Indicator byte 57 Carrier Application Tbl 990 bytes 58-65 Tariff Number bytes 66-68 Rule Number bytes 69-72 Indicator and Fare Class Code (bytes 73 and 74-81) Fare Type Code bytes 82-84 Fare Type Table 974 byte 214-221 Same byte 85 Normal/Special byte 87 OW/RT byte 88 Exclude Public/Private byte 111

These fields have no application when the fare component on the re-price solution is directed to “keep the fare.” This section describes the application of these fields when fare break points have changed and the fare component on the re-price solution is directed to re- price using current or historical fares.

Page E.03.31.450 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

International Tickets

1. Determine if at least one international fare component on the previous ticket is mapped to one on the re-price solution. a. If yes: i. The targeted Table 988 reissue provisions of each domestic and international fare component on the previous ticket that is mapped to a fare component on the re-price solution must be met by the mapped fare component. ii. The targeted Table 988 reissue provisions of any un-mapped fare components on the previous ticket need not be met by any fare component on the re-price solution. b. If no (no international fare components mapped): i. The targeted Table 988 reissue provisions of each international fare component on the previous ticket must be met by at least one international or domestic fare component on the re-price solution. ii. The targeted Table 988 reissue provisions of each domestic fare component on the previous ticket that is mapped to a fare component on the re-price solution must be met by the mapped fare component. iii. The targeted Table 988 reissue provisions of any un-mapped domestic fare components on the previous ticket need not be met by any fare component on the re-price solution. 2. If any targeted Table 988 reissue provisions from the previous ticket are not met by the re-price solution as specified in Step 1, the re-price solution may not be retained.

Domestic Tickets

1. All targeted Table 988 reissue provisions of each mapped fare component on the previous ticket must be met by the fare component on the re-price solution to which it is mapped. 2. Determine if there are any un-mapped fare components on the previous ticket. a. If yes, determine if there are any fare components on the re-price solution that have the same fare owner as the un-mapped fare component on the previous ticket. i. If yes, all targeted Table 988 reissue provisions of the un-mapped fare components on the previous ticket must be met by any fare component on the re-price solution that has the same fare owner. ii. If no, all targeted Table 988 reissue provisions of the un-mapped fare components on the previous ticket must be met by any fare component on the re-price solution.

Page E.03.31.451 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

3. If any targeted Table 988 reissue provisions from the previous ticket are not met by the re-price solution as specified in Steps 1-2, the re-price solution may not be retained.

International Example 1: international fare component on the previous ticket maps to one on the reprice solution Previous ticket: LAX-JFK-LHR-CDG Reprice solution: LAX-LGA-CDG prev. tkt FC maps to reprice solution FC targeted Table 988 reprice restrictions of prev. tkt FC LAX-JFK LAX-LGA (city/city mapping) must be met by LAX-LGA , the mapped FC on the reprice solution JFK-LHR LGA-CDG (country/sub-area mapping) must be met by LGA-CDG, the mapped FC on the reprice solution LHR-CDG none need not be met by any FC on the reprice solution If the targeted Table 988 reprice restrictions are all met as specified above, the reprice solution passes (assuming all other data passes validation). Otherwise, the reprice solution fails.

International Example 2: international fare component on the previous ticket maps to one on the reprice solution Previous ticket: JFK-FCO-MXP Reprice solution: JFK-FCO prev. tkt FC maps to reprice solution FC targeted Table 988 reprice restrictions of prev. tkt FC JFK-FCO JFK-FCO (city/city mapping) must be met by JFK-FCO, the mapped FC on the reprice solution FCO-MXP none need not be met by any fare component on the reprice solution If the targeted Table 988 reprice restrictions are all met as specified above, the reprice solution passes (assuming all other data passes validation). Otherwise, the reprice solution fails.

Page E.03.31.452 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

International Example 3: international fare component on the previous ticket maps to one on the reprice solution and unmapped fare component on reprice solution Previous ticket: JFK-FCO Reprice solution: JFK-FCO-MXP prev. tkt FC maps to reprice solution FC targeted Table 988 reprice restrictions of prev. tkt FC JFK-FCO JFK-FCO (city/city mapping) must be met by JFK-FCO, the mapped FC on the reprice solution No FC on the previous ticket maps to FCO-MXP on the reprice solution; therefore no targeted Table 988 reprice restrictions apply to FCO-MXP. If the targeted Table 988 reprice restrictions are all met as specified above, the reprice solution passes (assuming all other data passes validation). Otherwise, the reprice solution fails.

International Example 4: no international fare components on the previous ticket map to one on the reprice solution Previous ticket: ORD-NRT Reprice solution: ORD-LGW prev. tkt FC maps to reprice solution FC targeted Table 988 reprice restrictions of prev. tkt FC ORD-NRT none must be met by any fare component on the reprice solution (must be ORD-LGW because it is the only fare component on the reprice solution) If the targeted Table 988 reprice restrictions are all met as specified above, the reprice solution passes (assuming all other data passes validation). Otherwise, the reprice solution fails.

Page E.03.31.453 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

International Example 5: no international fare components on the previous ticket map to one on the reprice solution and domestic fare components all mapped Previous ticket: DFW-ORD-LHR-ORD-DFW Reprice solution: DFW-ORD-IAH prev. tkt FC maps to reprice solution FC targeted Table 988 reprice restrictions of prev. tkt FC DFW-ORD DFW-ORD (city/city mapping) must be met by DFW-ORD, the mapped FC on the reprice solution ORD-LHR none must be met by any FC on the reprice solution (DFW-ORD or ORD-IAH) LHR-ORD none must be met by any FC on the reprice solution (DFW-ORD or ORD- IAH) ORD-DFW ORD-IAH (city/country mapping) must be met by ORD-DFW, the mapped FC on the reprice solution If the targeted Table 988 reprice restrictions are all met as specified above, the reprice solution passes (assuming all other data passes validation). Otherwise, the reprice solution fails.

Page E.03.31.454 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

International Example 6: no international fare components on the previous ticket map to one on the reprice solution Previous ticket: DFW-ORD-LHR-ORD-DFW Reprice solution: DFW-ORD prev. tkt FC maps to reprice solution FC targeted Table 988 reprice restrictions of prev. tkt FC DFW-ORD DFW-ORD (city/city mapping) must be met by DFW-ORD, the mapped FC on the reprice solution ORD-LHR none must be met by any fare component on the reprice solution (must be DFW-ORD because it is the only fare component on the reprice solution) LHR-ORD none must be met by any fare component on the reprice solution (must be DFW-ORD because it is the only fare component on the reprice solution) ORD-DFW none need not be met by any FC on the reprice solution If the targeted Table 988 reprice restrictions are all met as specified above, the reprice solution is retained (assuming all other data passes validation). If the targeted Table 988 reprice restrictions are not all met as specified above, the reprice solution is eliminated

International Example 7: all international fare components on the previous ticket maps to those on the reprice solution Previous ticket: ICN-NRT-DEL-MXP-FCO Reprice solution: PUS-KIX-ISB-MXP-VCE prev. tkt FC maps to reprice solution FC targeted Table 988 reprice restrictions of prev. tkt FC ICN-NRT PUS-KIX (country/country) must be met by PUS-KIX, the mapped FC on the reprice solution NRT-DEL KIX- ISB (country/sub-area) must be met by KIX- ISB, the mapped FC on the reprice solution DEL-MXP ISB-MXP (sub-area/sub-area) must be met by ISB-MXP, the mapped FC on the reprice solution MXP-FCO MXP-VCE (city/country) must be met by MXP-VCE, the mapped FC on the reprice solution If the targeted Table 988 reprice restrictions are all met as specified above, the reprice solution passes (assuming all other data passes validation). Otherwise, the reprice solution fails.

Page E.03.31.455 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

International Example 8: international fare component on the previous ticket maps to one on the reprice solution, one domestic fare component on the previous ticket maps to one on the reprice solution, one does not Previous ticket: ELP-DFW-ORD-LHR Reprice solution: DFW-ORD-LHR prev. tkt FC maps to reprice solution FC targeted Table 988 reprice restrictions of prev. tkt FC ELP-DFW none need not be met by any FC on the reprice solution DFW-ORD DFW-ORD (city/city mapping) must be met by DFW-ORD, the mapped FC on the reprice solution ORD-LHR ORD-LHR (city/city mapping) must be met by ORD-LHR, the mapped FC on the reprice solution If the targeted Table 988 reprice restrictions are all met as specified above, the reprice solution passes (assuming all other data passes validation). Otherwise, the reprice solution fails.

Domestic Example 1: all fare components on the previous ticket maps to those on the reprice solution Previous ticket: SFO-AA-ORD-UA-MIA Reprice solution: SFO-UA-ORD-AA-MIA (airline codes indicate fare owners) prev. tkt FC maps to reprice solution FC targeted Table 988 reprice restrictions of prev. tkt FC SFO-AA-ORD SFO-UA-ORD (city/city mapping) must be met by the SFO-UA-ORD, the mapped FC on the reprice solution ORD-UA-MIA ORD-AA-MIA (city/city mapping) must be met by the ORD-AA-MIA, the mapped FC on the reprice solution If the targeted Table 988 reprice restrictions are all met as specified above, the reprice solution passes (assuming all other data passes validation). Otherwise, the reprice solution fails.

Page E.03.31.456 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Domestic Example 2: one fare component on the previous ticket maps to one on the reprice solution, other does not; same fare owner on previous ticket and reprice solution Previous ticket: SFO-AA-ORD-UA-LGA Reprice solution: SFO-UA-ORD-VS-LHR (airline codes indicate fare owners) prev. tkt FC maps to reprice solution FC targeted Table 988 reprice restrictions of prev. tkt FC SFO-AA-ORD SFO-UA-ORD (city/city mapping) must be met by the SFO-UA-ORD, the mapped FC on the reprice solution ORD-UA-LGA no geo mapping but a FC exists on must be met by any FC on the reprice solution that has the same reprice solution with same fare owner fare owner (therefore, must be met by SFO-UA-ORD) No FC on the previous ticket maps to ORD-VS-LHR on the reprice solution; therefore no targeted Table 988 reprice restrictions apply to ORD-VS-LHR. If the targeted Table 988 reprice restrictions are all met as specified above, the reprice solution passes (assuming all other data passes validation). Otherwise, the reprice solution fails.

Domestic Example 3: one fare component on the previous ticket maps to one on the reprice solution, one does not and has the same fare owner on as one found on the reprice solution; one does not and does not have the same fare owner as any found on the reprice solution Previous ticket: ORD-AA-JFK-F9-DEN-UA-LAX Reprice solution: ORD-B6-JFK-DL-ATL-UA-LAX (airline codes indicate fare owners) prev. tkt FC maps to reprice solution FC targeted Table 988 reprice restrictions of prev. tkt FC ORD-AA-JFK ORD-B6-JFK (city/city mapping) must be met by ORD-B6-JFK, the mapped FC on the reprice solution JFK-F9-DEN no geo mapping and no FC on reprice must be met by any FC on the reprice solution solution with same fare owner (ORD-B6-JFK or JFK-DL-ATL or ATL-UA-LAX) DEN-UA-LAX no geo mapping but FC exists on must be met by any FC on the reprice solution that has the same fare reprice solution w/ same fare owner owner (therefore, must be met by ATL-UA-LAX) If the targeted Table 988 reprice restrictions are all met as specified above, the reprice solution passes (assuming all other data passes validation). Otherwise, the reprice solution fails.

Page E.03.31.457 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Domestic Example 4: through pricing on previous ticket, point-to-point pricing on reprice solution Previous ticket: SXB-AF-NCE-AF-SXB Reprice solution: SXB-AF-CDG-AF-NCE-AF-SXB (airline codes indicate fare owners) prev. tkt FC maps to reprice solution FC targeted Table 988 reprice restrictions of prev. tkt FC SXB-AF-NCE no geo mapping but FC exists on must be met by any FC on the reprice solution that has the same fare reprice solution w/ same fare owner owner (SXB-AF-CDG or CDG-AF-NCE or NCE-AF-SXB) NCE-AF-SXB NCE-AF-SXB must be met by NCE-AF-SXB, the mapped FC on the reprice solution If the targeted Table 988 reprice restrictions are all met as specified above, the reprice solution passes (assuming all other data passes validation). Otherwise, the reprice solution fails.

4.10.3. Application of Expanded Keep (Table 988 byte 112) and Seasonality/Day of Week Indicator Table 966 (Table 988 bytes 138-145) when Fare Break Points Change

The Expanded Keep field (Table 988 byte 112) and Seasonality/Day of Week Indicator Table 966 (Table 988 bytes 138-145) has no application when the fare component on the re-price solution is directed to re-price using current or historical fares. This section describes the application of this field when fare break points have changed and the fare component on the re-price solution is directed to “keep the fare.”

All Tickets

1. If there are any un-mapped Tag 1 fare components on the previous ticket, the re-price solution may not be retained. 2. Each mapped fare component on the re-price solution that is directed to keep the fare must be re-priced using the fare (as defined by Table 988 bytes 138-145 and byte 112) of its mapped fare component on the previous ticket. 3. Each un-mapped fare component on the re-price solution that is directed to keep the fare must be re-priced using historical ticket-issue-date fares.

Page E.03.31.458 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

5.0. TRAVEL SEGMENT INDICATORS (TSIs)

TSIs may be present in the Table 988 Travel Limitations From Geo Spec Table (bytes 25-32) and To Geo Spec Table (bytes 33-40). All TSIs are valid for use in these fields. Most commonly used TSIs are still to be determined.

Page E.03.31.459 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

6.0. CODING CONVENTIONS

The following coding represents ‘at no change fee/service charge (free)’:

RECORD BYTE VALUE Cat. 31 63-69 0 Cat. 31 70-72 USD Cat. 31 73 2

Carriers may instruct multiple rule numbers, fare types, or fare classes that may be used for re-price and all other Category 31 data is the same. Multiple Table 988 sequences (with the same Process Tag value) will be used to accommodate this instruction. Each Table 988 sequence will contain the same data except for the different rule number, fare type, or fare class. In addition, the STOP field (Byte 206) will be blank to allow multiple sequences sharing the same Process Tag value to be processed.

Page E.03.31.460 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 31 – VOLUNTARY CHANGES

Example

Table 988: SEQ NO PROCESS TAG TERM FARE CLASS CODE STOP Bytes 14-20 Bytes 21-22 Byte 43 Bytes 74-81 Byte 206 1 01 Y 2 01 J 3 01 F X The data above indicates to apply Process Tag 01 (Terminal Points may not be changed) and re-price using Y, J, or F fare allowed. Since the STOP field is blank, for sequence 1 and 2, allowed to process all sequences for that same Process Tag value.

Carriers may instruct: ‘Changes to fare break points are permitted on the fare component’ (Table 988 Byte 43 = Y) and ‘the new travel for the fare component must be on the same date’ (Table 988 Byte 89 = X) or ‘the new travel for the fare component must be on a different later date’ (Table 988 Byte 89 = D). For new itineraries that include different fare break points, it is impossible to compare the travel dates from the new fare component to the previous fare component; therefore, two sequences will be required. One to identify terminal points may be changed and no date restrictions (Byte 43 = Y and Byte 89 = blank). The next sequence would identify changes to terminal points not permitted and the date restriction (Byte 43 = N and Byte 89 = X or D).

Page E.03.31.461 Revised January 2016 Effective 30 June 2016