Data Application for Category 15 - Sales Restrictions

DATA APPLICATION CATEGORY 15 – SALES RESTRICTIONS

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.

1.0 OVERVIEW ...... 3 1.1 Data Requirements ...... 3 1.2 Basic Processing Overview ...... 4 2.0 DEFINITIONS AND ASSUMPTIONS ...... 5 2.1 Definitions ...... 5 2.2 Assumptions ...... 5 Public Tariffs: ...... 5 Private Tariffs: ...... 6 3.0 DETAILED FIELD PROCESSING ...... 7 4.0 PROCESSING ...... 13 4.1 Application of Data for Sales Restrictions Processing ...... 15 4.1.1 Sale Dates - ‘Earliest’/’Latest’ Reservation Date, Bytes 14-20/28-34 (YYMMDD format) ...... 15 4.1.2 Sale Dates, ‘Earliest’/’Latest’ Ticketing Dates, Bytes 21-27/35-41 (YYMMDD format) ...... 18 4.1.3 Country Restriction, Byte 42 ...... 21 4.1.4 Resident Restriction, Byte 43 ...... 25 4.1.5 Carrier Restrictions - Bytes 44-49 ...... 27 4.1.5.1 Sale (byte 44) and Other Carrier/GDS (bytes 45-47) ...... 28 Public Tariffs ...... 30 Private Tariffs ...... 35 4.1.5.2 Validating Carrier (Byte 48) ...... 40 4.1.5.3 EXAMPLES: Sale (byte 44), Other Carrier/GDS (bytes 45-47), and Validating Carrier (byte 48) ...... 43 4.1.5.4 Segment (Byte 49) ...... 61 4.1.6 Travel Agency Restrictions - ‘Sale’, Byte 50 ...... 70 4.1.7 Form of Payment, Byte 52-55 ...... 75 4.1.8 Currency - ‘Country Restriction’, Byte 56 ...... 76 4.1.9 ‘Currency’, Bytes 57-59 ...... 79 4.1.10 Ticket Issuance, Bytes 60-61,63-65,67-68 ...... 82 4.1.11 ‘SITI’, ‘SITO’, ‘SOTI’, ‘SOTO,’ Bytes 71-74 ...... 86 4.1.12 ‘Ticket Issuance’, Bytes 60-70, and ‘SITI’, ‘SOTO’, ‘SITO’, ‘SOTI’, Bytes 71-74 ...... 89 4.1.13 ‘Family/Group’, Byte 80 ...... 91 4.1.14 ‘Extension of ticket validity’, Byte 81 ...... 92 4.1.15 Override Date Table Number 994 (Bytes 82-89) ...... 93 4.1.16 Text Table Number 996 (bytes 90-97) and Unavailable Data Tag (byte 98) ...... 93 4.1.17 Segments, bytes 99-101 ...... 97 4.1.18 Locale ‘Appl’, byte 102 ...... 98 4.1.19 Locale ‘Type’, byte 103 Values of ‘A’, ‘Z’, ‘N’, ‘S’, ‘C’, ‘P’, ‘T’, ‘I’, ‘H’, ‘U’, ‘X’, ‘V’ ...... 100 4.1.20 Bytes 103-117 Positive / Negative Applications for Locale Restrictions: ...... 110

Page E.03.15.001 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Private Tariffs ...... 110 Public Tariffs ...... 118 4.2 Reconciliation between Footnote and Rule Levels ...... 125 5.0 TRAVEL SEGMENT INDICATOR (TSI) ...... 130 6.0 CODING CONVENTIONS ...... 130 6.1 Recurring Segment ‘Locales’ (bytes 102 – 117) for Private Tariffs ...... 130 6.2 ‘Multiple Locales’ and ‘overflow conditions’ of Positive Application in the Recurring Segments ...... 131 6.3 ‘Multiple Locales’ and ‘overflow conditions’ of Negative Application in the Recurring Segments ...... 131 Public Tariffs ...... 131 Private Tariffs ...... 133 6.4 Coding conventions for SITI/SITO/SOTI/SOTO ...... 137 6.5 Category 15 as a Footnote Attachment (Fare Record level) ...... 141 6.6 Fare dates as they relate to ticketing footnotes/rules ...... 141

Page E.03.15.002 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

1.0 OVERVIEW

Category 15 is present when the sale of a fare is restricted by various conditions. These conditions include reservations/ticketing dates, countries/currencies of sale, form of payment, method of ticketing, who may sell the fare, and/or locales where the fare may or may not be sold.

1.1 Data Requirements In order to validate this Category it is essential to know:

. The reservation and ticketing dates/times of the fare component being priced; . The carrier issuing the ticket; . The ticket stock or plate the ticket will be issued on; . The carrier flying each segment of the fare; . The form(s) of payment of ticket i.e. CASH, CHECK, CREDIT CARD or GT. (Government Travel Request); . The currency and rate that the fare is being priced at; . Origin country/ Destination country of the fare; . Method of Ticketing allowed for ticket issuance i.e. Mail, electronic ticketing, SATO/CATO, SITI/SITO/SOTO/SOTI, PTA, Auto-ticketing, self - ticketing; . If a fare on the ticket is a family and/or group fare; . The resident status of the passenger using the fare; . The travel agency, to include IATA numbers, CRS code, Home Agency, Locations and Department Numbers. . Date of issue of the ticket. . All information pertaining to how the ticket is sold (i.e. location, currency, form of payment, person purchasing the ticket).

Page E.03.15.003 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

1.2 Basic Processing Overview

Match to the Category 15, Record 2 - as described in Record 2 processing. (Record 2 Processing includes Directionality, Inbound/Outbound, External ‘IF’, etc.).

Is there an applicable Category 15 - Record 2 Based on: - Date Override .

NO YES

Apply system assumption: Validate Category 15 information. Public Tariffs: no sales restrictions Private Tariffs: sales not permitted (fail the fare)

Page E.03.15.004 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

2.0 DEFINITIONS AND ASSUMPTIONS

2.1 Definitions

Destination In Category 15, final fare break point of the fare component based on fare selection. Origin In Category 15, Initial fare break point of the fare component based on fare selection.

2.2 Assumptions

Public Tariffs: When there is no Category 15 information (no Category 15, Record 2 which resolves to the fare including Record 2 match, inbound/outbound directional indicators, geo specs and date overrides), then the fare is available for sale, ticketing, and display at all times, anywhere, and by anyone, within the confines of the other category provisions.

Once there is data present for Category 15 which resolves to a fare, the application of the data on the fare component, pricing unit or journey is defined by Section 4.0 Processing.

Page E.03.15.005 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Private Tariffs: When there is no Category 15 information (no Category 15, Record 2 which resolves to the fare including Record 2 match, inbound/outbound directional indicators, geo specs and date overrides), then the fare is not available for sale, ticketing, and display at anytime, anywhere, and by anyone.

Every private tariff fare must have an associated Category 15 provision detailing who is permitted to sell and display the fare. At least one of the following fields should be addressed; otherwise, the subscriber that receives the data may not know who is eligible to sell and display the fare and the fare may fail processing:

. Byte 44 – Carrier Restriction . Bytes 45-47 – Other Carrier . Byte 50 – Travel Agency . Bytes 102-117 – Locales

Processing will search for a positive statement regarding the sale and display of the fare. If a positive statement is not found, then the fare will fail processing.

Once there is data present for Category 15 which resolves to a fare, the application of the data on the fare component, pricing unit or journey is defined by Section 4.0 Processing. Data in Country (byte 42), Carrier Restriction (byte 44), Other Carrier (bytes 45-47), Travel Agency (byte 50), and/or Locales (bytes 102-117) restricts both the sale and display of the fare.

Example

Tariff ATPCO Category 15 Processing Public No Category 15 information Pass – no sales restrictions Private No Category 15 information Fail

Page E.03.15.006 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

3.0 DETAILED FIELD PROCESSING Byte Location Match/Action Definition/Processing Byte 1 Key Match This field indicates the Record number for which the data is RECORD TYPE formatted. Byte 2 Key Match This field indicates the type of processing to be taken in ACTION connection to the transaction, either new data or changed data. Bytes 3 - 5 Key Match These fields indicate the rule or footnote category that the data CATEGORY NO. applies to. For Sales restrictions it will always be 15. Bytes 6 - 13 Key Match These fields indicate a number which links the Category 15, DATA TABLE NO. Record 3 to the associated Category Control Records (Record 2). Bytes 14 - 20 (SALE DATE RESTRICTIONS) Action The date(s) specified in these fields indicate the first date RESERVATIONS reservations are permitted for the fare component. Bytes 21-27 (SALE DATE RESTRICTIONS) Action The date(s) specified in these fields indicate the first date sales TICKETING are permitted for the fare on the ticket. Bytes 28-34 (SALE DATE RESTRICTIONS) Action The date(s) specified in these fields indicate the latest date RESERVATIONS reservations are permitted for the fare component. Bytes 35-41 (SALE DATE RESTRICTIONS) Action The date(s) specified in these fields indicate the latest date sales TICKETING are permitted for the fare on the ticket. Byte 42 Action For public tariffs, this field indicates that sales are restricted to COUNTRY RESTRICTION country of origin, country of destination or both, and is processed against the fare component. For private tariffs, sale and display are restricted to country of origin, country of destination or both, and is processed against the fare component. Byte 43 Action The data in these fields indicates that sales are restricted to type RESIDENT RESTRICTION of resident specified, and is processed against the fare component.

Page E.03.15.007 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Byte Location Match/Action Definition/Processing Byte 44 (CARRIER RESTRICTIONS) Action Data in this field indicates the fare may only be sold (and SALE displayed for private tariffs) by a specified CRS/GDS or the publishing/owning carrier of the fare and the carrier specified in the following field.

Bytes 45 - 47 (CARRIER RESTRICTIONS) Action For public tariffs, this field indicates the carrier code of the other OTHER CARRIER carrier who may sell the fare and/or the carrier code of the other carrier who may be the validating carrier; or the CRS/GDS who may sell the fare. For private tariffs, this field indicates the carrier code of the other carrier who may sell and display the fare and/or the carrier code of the other carrier who may be the validating carrier; or the CRS/GDS who may sell and display the fare. Byte 48 (CARRIER RESTRICTIONS) Action The data in this field indicates the validating carrier must be the VALIDATING CARRIER publishing/owning carrier of the fare and/or other carrier as specified in bytes 45 - 47. Byte 49 (CARRIER RESTRICTIONS) Action The data in this field indicates that no segment of the ticket or no SEGMENT segment at this fare may be on any other carrier except the publishing carrier, (or other carrier, if specified in bytes 45 - 47). Byte 50 (TRVL AGCY RESTRICTIONS) Action For public tariffs, this field indicates if the ticket may or may not SALE be sold by travel agencies. For private tariffs, this field indicates if the ticket may or may not be sold and displayed by travel agencies. FILLER FILLER Byte 52 (FORM OF PAYMENT) Action Data in this field indicates that cash is not an acceptable form of CASH payment for a ticket. Byte 53 (FORM OF PAYMENT) Action Data in this field indicates that a check is not an acceptable form CHECK of payment for a ticket.

Page E.03.15.008 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Byte Location Match/Action Definition/Processing Byte 54 (FORM OF PAYMENT) Action Data in this field indicates that a credit card or debit card is not CREDIT CARD an acceptable form of payment for a ticket. Byte 55 (FORM OF PAYMENT) Action Data in this field indicates that a Government transportation GOVT. TRANSPORTATION REQ request is not an acceptable form of payment for a ticket. Byte 56 (CURRENCY) Action Data in this field indicates that sale for the entire ticket is only COUNTRY RESTRICTION permitted in currency of the country of origin, currency of the country of destination, or both. Bytes 57-59 (CURRENCY) Action The data in this field indicates if sale of the ticket being priced is CURRENCY restricted to a specific currency. Byte 60 (TICKET ISSUANCE TAGS) Action If this field is tagged, it indicates one of the following ticketing MAIL options: a) The ticket is allowed to be issued by mail, b) The ticket is not allowed to be issued by mail, c) Mail is the required method of ticket issuance. Byte 61 (TICKET ISSUANCE TAGS) Action If this field is tagged, it indicates one of the following ticketing PTA options: a) The ticket is allowed to be issued by PTA, b) The ticket is not allowed to be issued by PTA, c) PTA is the required method of ticket issuance. FILLER FILLER. Byte 63 (TICKET ISSUANCE TAGS) Action If this field is tagged it indicates one of the following ticketing SELF options: a) The ticket is allowed to be issued by self, b) The ticket is not allowed to be issued by self, c) Self is the required method of ticket issuance.

Page E.03.15.009 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Byte Location Match/Action Definition/Processing Byte 64 (TICKET ISSUANCE TAGS) Action If this field is tagged it indicates one of the following ticketing PTA = TKT options: a) PTA constitutes ticketing, b) PTA does not constitute ticketing, c) PTA is required and constitutes ticketing. Byte 65 (TICKET ISSUANCE TAGS) Action If this field is tagged it indicates one of the following ticketing AUTOMATIC TICKETING MACHINES options: a) The tkt is allowed to be issued by automatic tkt machines, b) The tkt is not allowed to be issued by automatic tkt machines c) Automatic tkt machines is the required method of tkt issuance. FILLER FILLER. Byte 67 (TICKET ISSUANCE TAGS) Action If this field is tagged it indicates one of the following ticketing SATO (Scheduled Airline Ticket Office) / options: CATO (Consolidated Airline Ticket Office) a) The ticket is allowed to be issued by SATO/CATO, b) The ticket is not allowed to be issued by SATO/CATO, c) SATO/CATO is the required method of ticketing. Byte 68 (TICKET ISSUANCE TAGS) Action If this field is tagged it indicates one of the following ticketing ELECTRONIC TICKETING options: a) The ticket is allowed to be issued by electronic ticketing, b) The ticket is not allowed to be issued by electronic ticketing, c) Electronic Ticketing is the required method of ticketing. Byte 69 - 70 (TICKET ISSUANCE TAGS) Action (FILLER) RESERVED FOR FUTURE USE. Byte 71 (TICKET ISSUANCE TAGS) Action If this field is tagged it indicates one of the following ticketing SITI options: a) Sale and ticketing is allowed in country of origin, b) Sale and ticketing is not allowed in the country of origin, c) Sale and ticketing in the country of origin is required.

Page E.03.15.010 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Byte Location Match/Action Definition/Processing Byte 72 (TICKET ISSUANCE TAGS) Action If this field is tagged it indicates one of the following ticketing SOTO options: a) Sale and ticketing outside origin country is allowed, b) Sale and ticketing outside origin country is not allowed, c) Sale and ticketing outside origin country is required. Byte 73 (TICKET ISSUANCE TAGS) Action If this field is tagged it indicates one of the following ticketing SITO options: a) Sale inside and ticketing outside of origin country is allowed, b) Sale inside and ticketing outside of origin country is not allowed, c) Sale inside and ticketing outside origin country is required. Byte 74 (TICKET ISSUANCE TAGS) Action If this field is tagged it indicates that one of the following SOTI ticketing options: a) Sale outside and ticketing inside country of origin is allowed, b) Sale outside and ticketing inside country of origin is not allowed, c) Sale outside and ticketing inside country of origin is the required. Byte 75-79 (TICKET ISSUANCE TAGS) Action FILLER (RESERVED FOR FUTURE USE) Byte 80 Action If this field is tagged it indicates that for family/group, tickets (FAMILY/GROUP TAG) must be issued at the same time. Byte 81 Action If this field is tagged it indicates one of the following extension EXTENSION TAG of ticket validity options: a) Ticket validity may be extended, b) Ticket validity may not be extended. Bytes 82 - 89 Match This table further defines reservation, ticketing and/or travel OVERRIDE DATE TABLE NO. 994 dates that to which the Sales Restrictions apply. The Override Data Table must match the travel dates of the itinerary being priced in order for the sales restrictions to apply.

Page E.03.15.011 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Byte Location Match/Action Definition/Processing Byte 90 - 97 Action This table refers to a table containing free form text regarding TEXT TABLE NO. 996 Category 15. The information within this table is not automated. Byte 98 Action If the unavailable tag is set to value ‘X’ in Record 3 of Category UNAVAILABLE DATA TAG 15, the fare would fail. Byte 99-101 Action When this field is populated it is referring to the number of SEGMENTS occurrences for Locale (bytes 102-103) segments that are in the (NUMBER OF SEGMENTS) Record 3. Byte 102 Action For public tariffs, the data in this field indicates the positive or LOCALE negative application of ticket sale location, with the option of APPLICATION OF GEO SPEC 1 AND 2 two geographic locales where tickets may/or may not be sold. For private tariffs, the data in this field indicates the positive or negative application of ticket sale and display location, with the option of two geographic locales where tickets may/or may not be sold and displayed. Bytes 103 Action A code indicating the type of geographic specification data to be LOCALE found in the following bytes 104-117. TYPE Bytes 104 - 117 Action Area, zone, country, country/state, city, airport, travel agency, LOCALE IATA travel agency no., home IATA agency no., home travel agency code, department/identifier, CRS/CXR department code.

Page E.03.15.012 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

4.0 PROCESSING

Prior to processing the Sales Restriction Category, a Record 2 for Category 15 must be matched in order to determine the correct provisions and restrictions for the applicable fare being assessed. The next step is to compare the Category 15, Record 3, based on the Override Date Table. When the fare being validated does match to the Override Date Table, and the sales restrictions specified within the Category 15 have been validated, continue processing to an AND table. If no AND tables, then the fare passes processing. When the fare being validated does match to the Override Date Table and the sales restrictions specified within the Category 15 have not been validated, continue processing to an OR Table or to the next Set. If no Table or next Set is found, or the provisions do not match based on the Override Date Table, then the fare must fail pricing.

When the fare being validated does not match to the Override Date Table, this table is considered a no-match and processing should continue to an OR table, AND table, or the next set. If another table was not found, or did not match, then apply the system assumption i.e. no sales and display restrictions for public tariffs and sales and display not permitted for private tariffs.

The processing relationship among the various groups of fields in Category 15 is AND. Following is a list of groups within Category 15 related by AND: • Sale Dates (Bytes 14-41) • Family/Group (Byte 80) • Country (Byte 42) • Extension of Ticket Validity (Byte 81) • Residency (Byte 43) • Override Date Table Number 994 (Bytes 82- • Carrier (Bytes 44-49) 89) • Travel Agency (Byte 50) • Text Table Number 996 (Bytes 90-97) • Form of Payment (Bytes 52-55) • Recurring Segments (Bytes 99-117) • Currency (bytes 56-59) • Unavailable Data Tag (Byte 98) • Ticket Issuance (Bytes 60-74)

Page E.03.15.013 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

The relationship among the various bytes within each group of fields may be AND, OR, or AND-OR depending upon the group and the values entered. This relationship within each group is detailed in section 4.1 Application of Data for Sales Restrictions Processing.

Processing within a single group of fields is sometimes dependent upon whether data resides in a Public or Private Tariff. The Public or Private application of the data for applicable fields is detailed in section 4.1 Application of Data for Sales Restrictions Processing. In some instances, Public Tariff data is processed using the Private Tariff application. Public Tariffs that require Private Tariff Category 15 processing are specifically communicated as such to the industry.

When open sectors or surface sectors are permitted, the validation of any open or surface sectors is optimistic, but not unrealistic. Validation will be against the booked sectors, passing the open or surface sectors until such time that they are booked. Processing will validate all known information pertaining to the fare and may fail processing if there is enough information to ascertain that the open or surface sectors would fail when booked. (The allowance of open sectors is addressed in Category 5 confirmed sector field byte 37).

Page E.03.15.014 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

4.1 Application of Data for Sales Restrictions Processing

4.1.1 Sale Dates - ‘Earliest’/’Latest’ Reservation Date, Bytes 14-20/28-34 (YYMMDD format)

The earliest date is the first date reservations are permitted for all sectors of the fare component. If multiple fare components exist on a ticket all sale reservation conditions for each fare must be met, (but there is no validation across fare components). The latest date is the last date reservations are allowed for the fare. If reservations were made outside of the latest date indicated for the fare component being validated, then the ticket could not be issued with that fare.

For open sectors or surface sectors, processing will only check the booked sector against the first and last reservation dates. Only the confirmed sectors must be reserved within the reservation date restrictions. Note: processing must validate all known information pertaining to the fare and may fail the fare if there is enough information to ascertain that the open or surface sectors would fail when booked.

Example 1: Multiple fare components with Earliest/Latest Reservation requirements

Record 3 for LAB fare component: Res First Res Last Bytes 14-20 Bytes 28-34 26Jan 98’ 26Mar 98’

Record 3 for HAP fare component : Res First Res Last Bytes 14-20 Bytes 28-34 01Mar 98’ 30Jun 98’

The data represents that for the LAB fare component the earliest date reservations are allowed is 26 Jan, 98’, and the latest date reservations are allowed for the LAB fare component is 26Mar, 98’

Page E.03.15.015 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

For the HAP fare component the earliest date reservations are allowed is 01Mar 98’, and the latest date reservations are allowed is 30Jun 98’.

Example 2: Open Sectors

Record 3 for Y fare component PAR - BKK: Res First Res Last Bytes 14-20 Bytes 28-34 01Jan 99 31Jan 99

Record 3 for YAP fare component BKK - PAR: Res First Res Last Bytes 14-20 Bytes 28-34 10Jan 99 20Jan 99

The data represents that for the Y fare component the earliest date reservations are allowed is 01Jan 99, and the latest date reservations are allowed for the Y fare component is 31Jan 99.

For the YAP fare component, the earliest date reservations are allowed is 10Jan 99,and the latest date reservations are allowed for the YAP fare component is 20Jan 99.

Itinerary A for Y PAR-BKK fare component and YAP BKK-PAR fare component is:

PAR DXB BKK Segment Reservation Date Fare Class PAR - DXB 12Jan 99 Y DXB – BKK OPEN Y BKK – DXB OPEN YAP

Page E.03.15.016 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

DXB – PAR 15Jan 99 YAP

When pricing the PAR - BKK fare component which resolves to a single Record 3: PASS: Only the confirmed sectors must meet the First/Last Reservation Requirement. The PAR-DXB sector of the PAR-BKK fare component being validated meets the first reservation date requirement i.e. the reservation date for the PAR-DXB sector is after the first reservation date requirement and before the last reservation date for the Y fare component.

When pricing the BKK - PAR fare component which resolves to a single Record 3: PASS: Only the confirmed sectors must meet the First/Last Reservation Requirement. The DXB-PAR sector of the BKK-PAR fare component being validated meets the first reservation date requirement i.e. the reservation date for the DXB-PAR sector is after the first reservation date requirement and before the last reservation date for the Y fare component.

Itinerary B for Y PAR-BKK fare component and YAP BKK-PAR fare component is:

PAR DXB BKK

Segment Reservation Date Fare Class PAR - DXB 30Jan 99 Y DXB – BKK OPEN Y BKK – DXB OPEN YAP DXB – PAR OPEN YAP

Page E.03.15.017 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

When pricing the BKK - PAR fare component which resolves to a single Record 3: FAIL: The PAR-DXB sector of the outbound fare component is booked after the last reservation date for the BKK- PAR fare component.

4.1.2 Sale Dates, ‘Earliest’/’Latest’ Ticketing Dates, Bytes 21-27/35-41 (YYMMDD format)

The earliest date is the first date that the ticket may be issued for the fare. The latest date is the last date that the ticket may be issued for the fare. If multiple fare components exist on a ticket all ticketing requirements for each fare must be met, (but there is no validation across fare components). If a ticket is issued outside of the latest date indicated for the fare component being validated, then the fare should fail pricing.

If a PTA does not constitute ticketing, then the earliest/latest ticketing dates indicate the first and last dates that the ticket may be issued. If a PTA does constitute ticketing, then the earliest/latest ticketing dates indicate the first and last dates that the PTA may be purchased/issued.

PTA/Ticket Issue Example 1

Tktg First PTA PTA=TKT Bytes 21-27 Byte 61 Byte 64 01 Jan 99 Y Y

The data represents that earliest date the ticket or PTA may be purchased/issued is 01Jan 99. PTA/Ticket Issue Example 2

Page E.03.15.018 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Tktg First PTA PTA=TKT Bytes 21-27 Byte 61 Byte 64 01 Jan 99 Y N

The data represents that earliest date the ticket may be issued is 01Jan 99. If the PTA is purchased/issued, the ticket must still be issued on/after 01Jan 99.

Example 1: Multiple fare components with Earliest/Latest Ticketing requirements

Record 3 for YAB fare component: Tktg First Tktg Last Bytes 21-27 Bytes 35-41 24Jan 98’ 30Mar 98’

Record 3 for YEX fare component : Tktg First Tktg Last Bytes 21-27 Bytes 35-41 28Jan 98’ 01Apr 98’

The data represents that for the YAB fare component the earliest date tickets may be issued is 24 January 98’, the latest date tickets may be issued for the YAB fare is 30Mar 98’.

For the YEX fare component the earliest date tickets may be issued is the 28 January 98’, and the last date tickets may be issued for the YEX fare is 01Apr 98’.

Itinerary with two fare components NYC - PAR - FRA:

Origin-Destination Ticketing Date: Fare Class NYC - PAR Jan. 25, 1998 YAB PAR - FRA Jan. 25, 1998 YEX

Page E.03.15.019 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

When pricing the NYC - PAR fare component which resolves to a single Record 3: PASS: The NYC-PAR fare component being validated meets the first ticketing date requirement i.e. the ticketing date for the fare component NYC - PAR is on/after the first date the ticket may be issued and on/before the last date the ticket may be issued for the YAB fare component.

When pricing the PAR - FRA fare component which resolves to a single Record 3: FAIL: The PAR - FRA fare component being validated does not meet the first ticketing date requirement i.e. the ticketing date for the YEX fare component does not allow ticketing until on or after the 28Jan 98’, therefore the entire ticket could not be issued until on or after 28Jan 98’ to satisfy both of the fare components being validated.

Example 2: Combination of Latest Reservation/Ticketing requirements using multiple fare components

Record 3 for MEB fare component: Tktg Last Res Last Bytes 35-41 Bytes 28-34 30Apr 98’ 30Mar 98’

The data represents that the last ticketing date for the MEB fare component is 30Apr 98’ and the last date reservations are allowed for the MEB fare component is 30Mar 98’

Record 3 for LBA fare component: Tktg Last Res Last Bytes 35-41 Bytes 28-34 15Apr 98’ 20Mar 98’

The data represents that the last ticketing date for the LBA fare component is 15Apr 98’ and the last date reservations are allowed for the LBA fare component is 20Mar 98’

Itinerary with two fare components MSP - NYC - LON:

Page E.03.15.020 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Origin-Destination Ticketing Date: Reservation Date: Fare Class MSP - NYC 02 Apr, 1998 29Feb 98’ MEB NYC - LON 02 Apr, 1998 29Feb 98’ LBA

When pricing the MSP - NYC fare component which resolves to a single Record 3: PASS: The MSP - NYC fare component being validated meets the last ticketing date requirement i.e. the ticketing date for the fare component MSP - NYC is prior to the last date ticketing is allowed and the reservations were made prior to the last reservation date indicated for the MEB fare.

When pricing the NYC-LON fare component which resolves to a single Record 3: PASS: The NYC - LON fare component being validated satisfies the last ticketing date requirement and last reservation date requirements of the fare component provisions, being prior to the dates specified for both last ticketing date and last reservation date required.

4.1.3 Country Restriction, Byte 42

Public Tariffs: When this field is populated, it can restrict the sale of a ticket to the Country of Origin (O), the Country of Destination (D) or Both (B). If this field is received Blank this indicates that the ticket may be sold in any country. If there are country restriction(s) present in byte 42, the restriction(s) will apply to the fare component being priced based on fare selection.

Private Tariffs: When this field is populated, it can restrict the sale and display of a ticket to the Country of Origin (O), the Country of Destination (D) or Both (B). If this field is received Blank this indicates that the ticket may be sold or displayed in any country. If there are country restriction(s) present in byte 42, the restriction(s) will apply to the fare component being priced based on fare selection.

Country of origin refers to the country of fare selection origin and is determined by the origin country of how the fare was selected. Country of destination refers to the country of fare selection destination and is the other terminal point of the fare component.

Page E.03.15.021 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Country restriction(s), when present in Category 15, do not restrict the itinerary, they only restrict the actual point of sale (public tariffs) of the ticket or point of sale and display (private tariffs) of the ticket to the country specified.

Example 1 (Origin) – Public Tariff

Record 3 applicable to PAR - FRA fare component: Country Restriction Byte 42 O

This data represents that the sale of the fare component being validated is restricted to the country of fare selection origin, measured against the origin of the fare selected (which is not necessarily the country of origin of the fare component being validated). NOTE: Country of fare selection origin is determined by the origin country of how the fare was selected, and country of fare selection destination is the other terminal point of the fare component.

Three Fare Component Itinerary - (NYC-PAR, PAR-FRA, FRA-HKG). The ticket is sold and ticketed in the U.S.

NYC PAR FRA HKG

When pricing NYC to PAR: PASS: There are no sales restrictions applicable for this fare component.

When pricing PAR - FRA: FAIL: The fare component PAR - FRA sale is restricted to country of origin, (the country of origin of the fare component selected). In this case the country of origin of the fare component selected is France. The ticket is being issued in the U.S.; therefore, the fare component will fail.

When pricing FRA - HKG: PASS: There are no sales restrictions applicable for this fare component.

Example 2 (Destination) – Public Tariff

Page E.03.15.022 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Record 3 applicable to PAR - SIN fare component: Country Restriction Byte 42 D

This data represents that the sale of the fare component being validated is restricted to the country of fare selection destination, measured against the destination of the fare selected (which is not necessarily the country of destination of the fare component being validated). NOTE: Country of fare selection origin is determined by the origin country of how the fare was selected, and country of fare selection destination is the other terminal point of the fare component.

Round Trip Itinerary - (SIN-PAR-SIN). The ticket is sold and ticketed in France. Direction of travel SIN PAR Direction of fare selection

When pricing SIN to PAR: PASS: There are no sales restrictions applicable for this fare component.

When pricing PAR - SIN: PASS: The fare component PAR - SIN sale is restricted to country of destination, (the country of destination of the fare component selected). In this case the country of destination of the fare component selected is France. The ticket is being issued in France; therefore, the fare component will pass.

Example 3 (Origin) – Private Tariff

Record 3 applicable to PAR - FRA fare component: Country Restriction Byte 42 O

Page E.03.15.023 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

This data represents that the sale and display of the fare component being validated is restricted to the country of fare selection origin, measured against the origin of the fare selected (which is not necessarily the country of origin of the fare component being validated). NOTE: Country of fare selection origin is determined by the origin country of how the fare was selected, and country of fare selection destination is the other terminal point of the fare component.

Three Fare Component Itinerary - (NYC-PAR, PAR-FRA, FRA-HKG). The ticket is displayed, sold, and ticketed in the U.S.

NYC PAR FRA HKG

When pricing NYC to PAR: PASS: There are no sales restrictions applicable for this fare component.

When pricing PAR - FRA: FAIL: The fare component PAR - FRA sale and display is restricted to country of origin, (the country of origin of the fare component selected). In this case the country of origin of the fare component selected is France. The ticket is being issued in the U.S.; therefore, the fare component will fail.

When pricing FRA - HKG: PASS: There are no sales restrictions for FRA - HKG.

Example 4 (Destination) – Private Tariff

Record 3 applicable to PAR - SIN fare component: Country Restriction Byte 42 D

This data represents that the sale and display of the fare component being validated is restricted to the country of fare selection destination, measured against the destination of the fare selected (which is not necessarily the country of destination of the fare component being validated).

Page E.03.15.024 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

NOTE: Country of fare selection origin is determined by the origin country of how the fare was selected, and country of fare selection destination is the other terminal point of the fare component.

Round Trip Itinerary - (SIN-PAR-SIN). The ticket is displayed, sold, and ticketed in France. Direction of travel SIN PAR Direction of fare selection

When pricing SIN to PAR: PASS: There are no sales restrictions applicable for this fare component.

4.1.4 Resident Restriction, Byte 43

When this field is populated it can restrict the sale of a ticket to a purchaser who is a Permanent Resident (P), a Non- Resident (N), or Citizen (C) of the origin country. When this field is received Blank it indicates that this ticket has no Resident type restriction for the sale of a ticket. If there are resident restriction(s) present in Category 15 the restriction(s) will apply to the origin of the fare component based on fare selection.

NOTE: Resident restriction(s), when present in Category 15, do not identify the traveling passenger’s restriction, they only restrict the sale of the ticket to a specific resident type (when byte 43 is present).

Example – Sale Restricted to Permanent Resident

Record 2: N GB C HKG

Record 3 applicable to LON - HKG fare component:

Page E.03.15.025 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Resident Restriction Byte 43 P

This data represents that the sale of the fare component being validated is restricted to a Permanent Resident of the origin country of the fare component based on fare selection. A person wishing to purchase a ticket with this provision attached to the fare rule in Category 15, would have to possess positive identification, proving their status as a Permanent Resident of that country, in order to purchase the fare.

A three fare component itinerary, each fare component priced NYC - LON/ LON - HKG/ HKG - JKT: (The purchaser is a Permanent Resident of the United Kingdom)

NYC LON HKG JKT

When pricing NYC to LON: PASS: There are no sales restrictions applicable for this fare component.

When pricing LON - HKG: PASS: The sale of the LON-HKG fare component has a permanent resident restriction. As Category 15 resident restriction applies to the fare component based on fare selection, this restriction will apply to the origin of the fare component – United Kingdom.

When pricing HKG - JKT: PASS: There are no sales restrictions applicable for this fare component.

Page E.03.15.026 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

4.1.5 Carrier Restrictions - Bytes 44-49 SALE (Byte (44) OTHER CARRIER/GDS (Bytes 45-47) VALIDATING CARRIER (Byte 48) SEGMENT (Byte 49)

When any or all of bytes 44-49 are received Blank then they have no application, subject to the Category 15 tariff assumption.

A detailed explanation of each of these fields is provided below.

Page E.03.15.027 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

4.1.5.1 Sale (byte 44) and Other Carrier/GDS (bytes 45-47) The Sale field (byte 44) and the Other Carrier/GDS field (bytes 45-47) may be used in conjunction to specify sales restrictions (and display restrictions for private tariffs) applicable to the publishing/owning carrier, another specifed carrier (as specified by Other Carrier/GDS bytes 45-47), and/or a Global Distribution System (GDS)/Computer Reservation System (CRS) (as specified by Other Carrier/GDS bytes 45-47).

Following is an explanation of applicable Sale (byte 44) values:

Value X: Must be sold (and for private tariffs may only be displayed) by the publishing/owning carrier or another specified carrier. The application is dependent upon whether or not data is present in Other Carrier/GDS (bytes 45-47) as follows: • When Sale (byte 44) is value X and data is not present in Other Carrier/GDS (bytes 45-47), then the fare must be sold (and for private tariffs may only be displayed) by the publishing /owning carrier. • When Sale (byte 44) is value X and data is present in Other Carrier/GDS (bytes 45-47), then the fare must be sold (and for private tariffs may only be displayed) by the publishing /owning carrier or the carrier specified in Other Carrier/GDS (bytes 45-47).

For carrier fares, the publishing/owning carrier is the carrier specified in the carrier code field on the Fare Record or Category 25 Record 2 for the fare component being validated.

For YY (industry) fares, the publishing/owning carrier 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 Resolution). In this scenario, the primary portion of travel will be the portion against which the pricing system is attempting to select YY fares in lieu of carrier-specific fares.

Example: MEL-TYO fare component Travel is: MEL-XX-JKT-DD-TYO

Page E.03.15.028 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

• 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.

Value C: Must be sold (and for private tariffs may only be displayed) via the GDS/CRS specified in bytes 45-47. Any location using the specified GDS/CRS can sell the fare.

Value Blank: No application. Sales restrictions are based on the other data in the record and the Category 15 tariff assumption.

The Other Carrier/GDS (bytes 45-47) field may contain a carrier code, a generic alliance carrier code (such as *A signifying Star Alliance, *O signifying One World, or *S signifying Sky Team), or a CRS/GDS code. The application is dependent upon the presence or absence of data in the Sale (byte 44) field as follows: • When data is present in Other Carrier/GDS in conjunction with Sale (byte 44) value X or C, the data indicates a sales (and display for private tariffs) application as defined above. It is possible Validating Carrier requirements also apply depending upon the data in Validating Carrier (byte 48). This is defined in detail in Section 4.1.5.2 Validating Carrier further below. • When carrier data is present in Other Carrier/GDS and Sale (byte 44) is value Blank, then Other Carrier/GDS indicates a validating carrier requirement (and not a sales requirement) as defined by Validating Carrier (byte 48). This is defined in detail in Section 4.1.5.2 Validating Carrier further below. Carrier code YY is not applicable in the Other Carrier/GDS field. If this field contains carrier code YY, then processing ignores the field (process as if the field is blank).

Refer to Appendix M for a list of applicable generic alliance codes and the participating carriers in each code .

The application of sales restriction data in the Sale and Other Carrier/GDS fields is dependent upon whether the fare (applicable to the fare component being validated) is governed by a Public or Private Tariff, as specified below.

Page E.03.15.029 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Public Tariffs

When byte 44 (Sale) is populated with a “X”, this indicates that the fare may only be sold by the publishing/owning carrier. When byte 44 is “X” in a YY fare, only the carrier providing transportation on the primary portion of travel may sell the fare (Note: ATPCO Coding Conventions dictate that value “X” is not appropriate to be used on a YY fare.) If byte 44 is populated with “X” and bytes 45- 47 (Other Carrier/GDS) are populated with a carrier code, then the fare may only be sold by the publishing/owning carrier or the carrier indicated in bytes 45-47. If byte 44 is populated with “X” and bytes 45-47 (Other Carrier/GDS) are populated with a generic alliance carrier code, then the fare may only be sold by the publishing/owning carrier or a carrier participating in the alliance code indicated in bytes 45-47.

When byte 44 is populated with a ‘C’ this indicates that the fare must be sold via the CRS/GDS defined in bytes 45-47 (Other Carrier/GDS).

The application of ‘C’ does not include the publishing/owning carrier of the Record 2 by assumption, instead if it is the intent to include the publishing/owning carrier, a subsequent Record 3 table for Category 15 must be entered. “C” indicates that anyone identified to use that CRS/GDS can sell the fare. This may include publishing carrier, other carriers or agents if they are identified to use the specified CRS/GDS. If the intent is that only the publishing carrier may sell the fare using the specified CRS/GDS, then a second Record 3 table must be entered specifying publishing carrier and linked with the AND relational indicator.

‘C’ can be used in conjunction with bytes 103-117 (Locales). When both byte 44 (Sale) and bytes 103-117 are populated, it restricts the sale to the information in bytes 45-47 and the locations specified in bytes 103-117.

When byte 44 is Blank, the data in Sale (byte 44) and Other Carrier/GDS (bytes 45-47) in this Record 3 does not restrict the selling location. Any carrier data in Other Carrier/GDS (bytes 45-47) only specifes a validating carrier restriction (as defined in Section 4.1.5.2 Validating Carrier further below). It is possible other data elements in the record may restrict the selling location.

Page E.03.15.030 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

1. Example of byte 44 (Sale) used in conjunction with bytes 45-47 (Other Carrier/GDS)

Public Tariff rule 2000 for carrier KL Record 2 for Y fares Record 3 Sale Other Carrier Byte 44 Bytes 45-47 X DL

This data indicates that Y fares for KL may only be sold by the publishing/owning carrier of the associated fares (KL) or by the carrier specified in bytes 45-47 (DL). This sales restriction applies to the organization transacting the sale.

2. Example of byte 44 (Sale) used in conjunction with bytes 45-47 (Other Carrier/GDS)

Public Tariff rule 2000 for carrier KL Record 2 for Y fares

Record 3 Sale Other Carrier Byte 44 bytes 45-47 C 1G

This data indicates Y fares for KL may only be sold via the CRS/GDS code entered in bytes 45-47 (Galileo). This sales restriction applies to the organization transacting the sale.

Page E.03.15.031 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

3. Example of two tables linked with AND, both tables containing byte 44 (Sale) and bytes 45-47 (Other Carrier/GDS)

Public Tariff rule 2000 for carrier KL Record 2 for Y fares

‘THEN ‘Record 3 Sale Other Carrier Byte 44 Bytes 45-47 X DL ‘AND ‘Record 3 Sale Other Carrier Byte 44 Bytes 45-47 C 1G

This data indicates that Y fares for KL may only be sold by the publishing/owning carrier of the associated fares (KL) or the carrier specified in bytes 45-47 (DL) AND only via the CRS/GDS specified in bytes 45-47 of the second table (Galileo). The sales restriction applies to the organization transacting the sale. Both restrictions of carrier and CRS must be satisfied to sell this fare. (i.e. a DL city ticket agent using a Galileo set can sell the fare).

Page E.03.15.032 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

4. Example of two tables linked with OR, both tables containing byte 44 (Sale) and bytes 45-47 (Other Carrier/GDS)

Public Tariff rule 2000 for carrier KL Record 2 for Y fares

THEN Record 3 Sale Other Carrier Byte 44 Bytes 45-47 X DL

OR Record 3 Sale Other Carrier Byte 44 Bytes 45-47 C 1G

This data indicates that Y fares for KL may only be sold by the publishing/owning carrier of the associated fares (KL), the carrier specified in bytes 45-47 (DL) OR via the CRS specified in bytes 45-47 of the second table (Galileo). One of the restrictions must be satisfied. The sale restrictions apply to the organization transacting the sale.

Page E.03.15.033 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

5. Example of byte 44 (Sale) used in conjunction with Generic Alliance Carrier Code in bytes 45-47 (Other Carrier/GDS)

Public Tariff rule 2000 for carrier XX Record 2 for Y fares Record 3 Sale Other Carrier Byte 44 Bytes 45-47 X *S NOTE: Assume *S = XX, BB, CC, DD

This data indicates that Y fares for XX may only be sold by the publishing/owning carrier of the associated fares (XX) or by a carrier partipating in *S (XX, BB, CC, or DD). This sales restriction applies to the organization transacting the sale.

Page E.03.15.034 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Private Tariffs

When byte 44 (Sale) is populated with a “X”, this indicates that the fare may only be sold and displayed by the publishing/owning carrier. When byte 44 is “X” in a YY fare, only the carrier providing transportation on the primary portion of travel may sell and display the fare (Note: ATPCO Coding Conventions dictate that value “X” is not appropriate to be used on a YY fare). If byte 44 is populated with “X” and bytes 45-47 (Other Carrier/GDS) are populated with a carrier code, then the fare may only be sold and displayed by the publishing/owning carrier or the carrier indicated in bytes 45-47. If byte 44 is populated with “X” and bytes 45-47 (Other Carrier/GDS) are populated with a generic alliance carrier code, then the fare may only be sold and displayed by the publishing/owning carrier or a carrier participating in the alliance code indicated in bytes 45-47.

When byte 44 is populated with a ‘C’ this indicates that the fare must be sold and displayed via the CRS/GDS defined in bytes 45-47 (Other Carrier/GDS).

The application of ‘C’ does not include the publishing/owning carrier of the Record 2 by assumption, instead if it is the intent to include the publishing/owning carrier, a subsequent Record 3 table for Category 15 must be entered. “C” indicates that anyone identified to use that CRS/GDS can sell and display the fare. This may include publishing carrier, other carriers, or agents if they are identified to use the specified CRS. If the intent is that only the publishing carrier may sell and display the fare using the specified CRS/GDS, then a second Record 3 table must be entered specifying publishing carrier and linked with the AND relational indicator.

‘C’ can be used in conjunction with bytes 103-117 . When both byte 44 (Sale) and bytes 103-115 are populated, it restricts the sale to the information in bytes 45-47 and the locations specified in bytes 103-117.

When byte 44 is Blank, the data in Sale (byte 44) and Other Carrier/GDS (bytes 45-47) in this Record 3 does not restrict the selling and display location. Any carrier data in Other Carrier/GDS (bytes 45-47) only specifes a validating carrier restriction (as defined in Section 4.1.5.2 Validating Carrier further below). It is possible other data elements in the record may restrict the selling and display location.

Page E.03.15.035 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

1. Example of byte 44 (Sale) used in conjunction with bytes 45-47 (Other Carrier/GDS)

Private Tariff rule 2000 for carrier KL Record 2 for Y fares Record 3 Sale Other Carrier Byte 44 Bytes 45-47 ‘X’ DL

This data indicates that Y fares for KL may only be sold and displayed by the publishing/owning carrier of the associated fares (KL) or by the carrier specified in bytes 45-47 (DL). This sales restriction applies to the organization transacting the sale.

2. Example of byte 44 (Sale) used in conjunction with bytes 45-47 (Other Carrier/GDS)

Private Tariff rule 2000 for carrier KL Record 2 for Y fares

Record 3 Sale Other Carrier Byte 44 Bytes 45-47 ‘C’ 1G

This data indicates Y fares for KL may only be sold and displayed via the CRS/GDS code entered in bytes 45-47 (Galileo). This sales restriction applies to the organization transacting the sale.

Page E.03.15.036 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

3. Example of two tables linked with AND, both tables containing byte 44 (Sale) and bytes 45-47 (Other Carrier/GDS)

Private Tariff rule 2000 for carrier KL Record 2 for Y fares

‘THEN ‘Record 3 Sale Other Carrier Byte 44 Bytes 45-47 ‘X’ DL ‘AND ‘Record 3 Sale Other Carrier Byte 44 Bytes 45-47 ‘C’ 1G

This data indicates that Y fares for KL may only be sold and displayed by the publishing/owning carrier of the associated fares (KL) or the carrier specified in bytes 45-47 (DL) AND only via the CRS/GDS specified in bytes 45-47 of the second table (Galileo). The sales restriction applies to the organization transacting the sale. Both restrictions of carrier and CRS/GDS must be satisfied to sell and display this fare. (i.e. a DL city ticket agent using a Galileo set can sell and display the fare).

Page E.03.15.037 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

4. Example of two tables linked with OR, both tables containing byte 44 (Sale) and bytes 45-47 (Other Carrier/GDS)

Private Tariff rule 2000 for carrier KL Record 2 for Y fares

THEN Record 3 Sale Other Carrier Byte 44 Bytes 45-47 ‘X’ DL

OR Record 3 Sale Other Carrier Byte 44 Bytes 45-47 ‘C’ 1G

This data indicates that Y fares for KL may only be sold and displayed by the publishing/owning carrier of the associated fares (KL), the carrier specified in bytes 45-47 (DL) OR via the CRS/GDS specified in bytes 45-47 of the second table (Galileo). One of the restrictions must be satisfied. The sale restrictions apply to the organization transacting the sale.

Page E.03.15.038 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

5. Example of byte 44 (Sale) used in conjunction with Generic Alliance Carrier Code in bytes 45-47 (Other Carrier/GDS)

Private Tariff rule 2000 for carrier XX Record 2 for Y fares Record 3 Sale Other Carrier Byte 44 Bytes 45-47 X *S NOTE: Assume *S = XX, BB, CC, DD

This data indicates that Y fares for XX may only be sold and displayed by the publishing/owning carrier of the associated fares (XX) or by a carrier partipating in *S (XX, BB, CC, or DD). This sales restriction applies to the organization transacting the sale.

Page E.03.15.039 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

4.1.5.2 Validating Carrier (Byte 48)

This field specifies validating carrier requirements applicable to the fare being priced. Following is an explanation of applicable values:

Value S: When byte 48 is value S, validating carrier restrictions are defined based on data in the Sale (byte 44) and Other Carrier/GDS (bytes 45-47) fields as defined below: • When Sale (byte 44) is value X and: o Other Carrier/GDS contains a carrier code, then the validating carrier must be the owning/publishing carrier of the fare or the carrier specified in Other Carrier/GDS. [Additionally, the fare must be sold (and for private tariffs may only be displayed) by the publishing /owning carrier or the carrier specified in Other Carrier/GDS. Refer to Section 4.1.5.1 above for further information.] o Other Carrier/GDS contains a generic alliance carrier code, then the validating carrier must be the owning/publishing carrier of the fare or a carrier participating in the alliance code specified in Other Carrier/GDS. [Additionally, the fare must be sold (and for private tariffs may only be displayed) by the publishing /owning carrier or a carrier participating in the alliance code specified in Other Carrier/GDS. Refer to Section 4.1.5.1 above for further information.] • When Sale (byte 44) is value Blank and: o Other Carrier/GDS contains a carrier code, then the validating carrier must be the owning/publishing carrier of the fare or the carrier specified in Other Carrier/GDS. (There are no sales restrictions based on the Sale and Other Carrier/GDS fields.) o Other Carrier/GDS contains a generic alliance carrier code, then the validating carrier must be the owning/publishing carrier of the fare or a carrier participating in the alliance code specified in Other Carrier/GDS. (There are no sales restrictions based on the Sale and Other Carrier/GDS fields.) • When Sale (byte 44) is value C and Other Carrier/GDS contains a CRS/GDS code, then the validating carrier must be the owning/publishing carrier of the fare. [Additionally, the fare must be sold (and for private tariffs may only be displayed) by the CRS/GDS specified in Other Carrier/GDS. Refer to Section 4.1.5.1 above for further information.] NOTE: Carrier code YY is not applicable in the Other Carrier/GDS field. If this field contains carrier code YY, then processing ignores the field (process as if the field is blank).

Page E.03.15.040 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

For carrier fares, the publishing/owning carrier is the carrier specified in the carrier code field on the Fare Record or Category 25 Record 2 for the fare component being validated.

For YY (industry) fares, the publishing/owning carrier is the carrier providing transportation on the primary portion of travel. (Note: ATPCO Coding Conventions dictate that byte 48 is not appropriate to be used on a YY fare). 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 is attempting to select YY fares in lieu of carrier-specific fares.

Example: MEL-TYO fare component Travel is: MEL-XX-JKT-DD-TYO

Value O: When byte 48 is value O, validating carrier restrictions are defined based on data in the Sale (byte 44) and Other Carrier/GDS (bytes 45-47) fields as defined below: • When Sales (byte 44) is value X and Other Carrier /GDS contains a carrier code, then the validating carrier can only be the carrier specified in the Other Carrier/GDS (bytes 45-47) field. The publishing/owning carrier cannot be the validating carrier. [Additionally, the fare must be sold (and for Private tariff may only be displayed) by the publishing/owning carrier or the carrier specified in Other carrier/GDS. Refer to Section 4.1.5.1 above for the further information.]

Additionally, if bytes 45-47 (Other Carrier/GDS) are populated with a generic alliance carrier code, the publishing/owning carrier of the fare cannot be the validating carrier regardless of participation in the Alliance.

Page E.03.15.041 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

• When Sale (byte 44) is value Blank and Other Carrier/GDS contains a carrier code, then the validating carrier must be the carrier specified in the Other Carrier/GDS (bytes 45-47) field. The publishing/owning carrier cannot be the validating carrier. (There are no sales restrictions based on the Sale and Other Carrier/GDS fields.)

• When Sale (byte 44) is value C then edits prohibit value O in the Validating carrier (byte 48) field.

NOTE: When byte 48 is value O, then edits required Other Carrier/GDS field (bytes 45-47) must have Carrier code other than the Carrier code in the Record 2 (Cannot be the same as owning carrier).

Value Blank: There are no restrictions on the validating carrier (subject to the remainder of the data in the record).

NOTE: Values P, E, and B are not valid for use in any new Category 15 Record 3 tables. It is possible current Record 3s may contain value P, E, or B. In this case, value P, E, and B have the same application as value S as defined above.

If the validating carrier meets the requirements specified by Validating Carrier Value S or O (in conjunction with the data in the Sale and Other Carrier/GDS fields as defined above), then pass the validating carrier requirements for byte 48 in this Category 15 Record 3. If the validating carrier does not meet the requirements specified by Validating Carrier Value S or O (in conjunction with the data in the Sale and Other Carrier/GDS fields as defined above), then fail the Category 15 Record 3.

Page E.03.15.042 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

4.1.5.3 EXAMPLES: Sale (byte 44), Other Carrier/GDS (bytes 45-47), and Validating Carrier (byte 48)

The following charts illustrates the application of data when the Sale (byte 44), Other Carrier/GDS (bytes 45-47), and Validating Carrier (byte 48) fields are used in conjunction.

Example 1: Public Fares

The following assumptions apply: • Publishing Carrier of the Fare (carrier on the Fare Record) = BB • *A = BB/CC/DD/EE

Sale Other Carrier/GDS Validating Carrier Application Byte 44 Bytes 45-47 Byte 48 X ZZ Blank The fare must be sold by carrier BB or carrier ZZ. There are no restrictions on the validating carrier. X *A Blank The fare must be sold by carrier BB, CC, DD, or EE. There are no restrictions on the validating carrier. X ZZ S The fare must be sold by carrier BB or carrier ZZ. and The validating carrier must be carrier BB or carrier ZZ. X ZZ O The fare must be sold by carrier BB or carrier ZZ. The validating carrier must be ZZ .Carrier BB cannot be the validating carrier. X *A S The fare must be sold by carrier BB, CC, DD, or EE. and The validating carrier must be carrier BB, CC, DD, or EE X *A O The fare must be sold by carrier BB or any carrier from Alliance *A and

Page E.03.15.043 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Sale Other Carrier/GDS Validating Carrier Application Byte 44 Bytes 45-47 Byte 48 The validating carrier must be any carrier from the *A Alliance, excluding BB (the owning/publishing carrier cannot be the validating carrier) X Blank S The fare must be sold by carrier BB. and The validating carrier must be carrier BB. Blank ZZ S The validating carrier must be carrier BB or carrier ZZ. There are no restrictions on the selling location based on these fields. (It is possible other fields in the record will restrict the sales location). Blank ZZ O The validating carrier must be carrier ZZ. Carrier BB cannot be the validating carrier. There are no restrictions on the selling location based on these fields. (It is possible other fields in the record will restrict the sales location) Blank *A S The validating carrier must be carrier BB, CC, DD, or EE. There are no restrictions on the selling location based on these fields. (It is possible other fields in the record will restrict the sales location). Blank *A O The validating carrier must be any carrier from Alliance *A, excluding BB (the owning/publishing carrier cannot be the validating carrier). There are no restrictions on the selling location based on these fields. (It is possible other fields in the record will restrict the sales location) C 1S Blank The fare must be sold by GDS 1S. There are no Category 15 restrictions on the validating carrier. C 1S S The fare must be sold by GDS 1S.

Page E.03.15.044 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Sale Other Carrier/GDS Validating Carrier Application Byte 44 Bytes 45-47 Byte 48 and The validating carrier must be carrier BB.

Page E.03.15.045 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 2: Private Fares

The following assumptions apply • Publishing Carrier of the Fare (carrier on the Fare Record) = BB • *A = BB/CC/DD/EE

Sale Other Carrier/GDS Validating Carrier Application Byte 44 Bytes 45-47 Byte 48 X ZZ Blank The fare must be sold by carrier BB or carrier ZZ. Only carrier BB and carrier ZZ can display the fare.

There are no Category 15 restrictions on the validating carrier. X *A Blank The fare must be sold by carrier BB, CC, DD, or EE. Only carrier BB, CC, DD, and EE can display the fare. There are no restrictions on the validating carrier. X ZZ S The fare must be sold by carrier BB or carrier ZZ. Only carrier BB and carrier ZZ can display the fare. and The validating carrier must be carrier BB or carrier ZZ. X ZZ O The fare must be sold by carrier BB or carrier ZZ. Only carrier BB and ZZ can display the fare. and The validating carrier must be ZZ. Carrier BB cannot be the validating carrier. X *A S The fare must be sold by carrier BB, CC, DD, or EE. Only carrier BB, CC, DD, and EE can display the fare. and The validating carrier must be carrier BB, CC, DD, or EE.

Page E.03.15.046 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Sale Other Carrier/GDS Validating Carrier Application Byte 44 Bytes 45-47 Byte 48 X *A O The fare must be sold by carrier BB or any carrier from Alliance *A. Only carrier BB and any carrier from Alliance *A can display the fare. and The validating carrier must be any carrier from the *A Alliance, excluding BB (the owning/publishing carrier cannot be the validating carrier) X Blank S The fare must be sold by carrier BB. Only carrier BB can display the fare. and The validating carrier must be carrier BB. Blank ZZ S The validating carrier must be carrier BB or carrier ZZ. There are no restrictions on the selling or display location based on these fields. (It is possible other fields in the record will restrict the sales and display location). Blank ZZ O The validating carrier must be carrier ZZ. Carrier BB cannot be the validating carrier. There are no restrictions on the selling or display location based on these fields. (It is possible other fields in the record will restrict the sales and display location) Blank *A S The validating carrier must be carrier BB, CC, DD, or EE. There are no restrictions on the selling or display location based on these fields. (It is possible other fields in the record will restrict the sales and display location). Blank *A O The validating carrier must be any carrier from Alliance *A, excluding BB (the owning/publishing carrier cannot be the validating carrier).

Page E.03.15.047 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Sale Other Carrier/GDS Validating Carrier Application Byte 44 Bytes 45-47 Byte 48 There are no restrictions on the selling or display location based on these fields. (It is possible other fields in the record will restrict the sales and display location) C 1S Blank The fare must be sold by GDS 1S. Only GDS 1S can display the fare. There are no Category 15 restrictions on the validating carrier. C 1S S The fare must be sold by GDS 1S. Only GDS 1S can display the fare. and The validating carrier must be carrier BB.

Page E.03.15.048 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 3: Multiple Validating Carriers and GDS Sales Restriction (Value S)

Carrier XX Private Fare Carrier intent: Must be sold by GDS 1A. Validating carrier must be XX, BB, or CC.

Below are 2 possible coding examples: A. Coding that supports the carrier’s intent B. Coding that does not support the carrier’s intent (provided for illustrative processing purposes)

Coding Example A: Category 15 data coding that supports the intent THEN Record 3 Sale Other Carrier/GDS Validating Carrier Byte 44 Bytes 45-47 Byte 48 C 1A Blank AND Record 3 Sale Other Carrier/GDS Validating Carrier Byte 44 Bytes 45-47 Byte 48 Blank BB S

THEN Record 3 Sale Other Carrier/GDS Validating Carrier Byte 44 Bytes 45-47 Byte 48 C 1A Blank AND Record 3 Sale Other Carrier/GDS Validating Carrier Byte 44 Bytes 45-47 Byte 48 Blank CC S

The data in the first Set indicates the fare must be sold and displayed via GDS 1A. Additionally, the validating carrier must be XX (publishing/owning carrier) or BB.

Page E.03.15.049 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Then data in the second Set indicates the fare must be sold and displayed via GDS 1A. Additionally, the validating carrier must be XX (publishing/owning carrier) or CC. When validating a fare that resolves to the above Category 15 data, the table below indicates the pass/fail application depending upon the specified scenario: Scenario Application Selling and Display Location Validating Carrier Agency ABC via GDS 1A XX Pass the first Set Agency 123 via GDS 1A BB Pass the first Set Agency ABC via GDS 1A CC • Fail the first Set and continue to the next set. • Pass the second Set. Agency ABC via GDS 1S XX • Fail the first Set and continue to the next set. • Fail the second Set. • As no further sets exist, fail the fare. Agency ABC via GDS 1A DD • Fail the first Set and continue to the next set. • Fail the second Set. • As no further sets exist, fail the fare.

Page E.03.15.050 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

NOTE: It is not possible to be both validating carrier BB and CC. Therefore, with the data coded in this example, only validating carrier XX will pass. If validating carrier is BB, then processing will fail the last Record 3 table. If validating carrier is CC, then processing will fail the second Record 3 table. Carriers should refer to the Category 15 Reference Manual (for users) for further examples on coding the data to achieve their intent.

Page E.03.15.051 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

When validating a fare that resolves to the above Category 15 data, the table below indicates the pass/fail application depending upon the specified scenario: Scenario Application Selling and Display Location Validating Carrier Agency ABC via GDS 1A XX Pass the Set Agency 123 via GDS 1A BB • Fail 3rd Table (because it requires the validating carrier to be XX or CC). Therefore, fail the set. • As no further sets exist, fail the fare. * Agency ABC via GDS 1A CC • Fail 2nd Table (because it requires the validating carrier to be XX or BB). Therefore, fail the Set. • As no further sets exist, fail the fare. * Agency ABC via GDS 1S XX • Fail the 1st Table (because it requires sales and display via GDS 1A. Therefore, fail the set. • As no further sets exist, fail the fare. * * Refer to data application for Record 2 (Category Control) string processing (e.g. THEN/AND processing).

Example 4: Multiple Validating Carriers and GDS Sales Restriction (value O)

Below are some possible coding examples: A. Coding that supports the carrier’s intent B. Coding that does not support the carrier’s intent (provided for illustrative processing purposes)

A. Carrier XX Private Fare Carrier intent: Must be sold by GDS 1A. Only GDS 1A can display the fare. Validating carrier must be BB or CC and owning/publishing carrier (XX) cannot be the validating carrier.

Page E.03.15.052 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

THEN Record 3 Sale Other Carrier/GDS Validating Carrier Byte 44 Bytes 45-47 Byte 48 C 1A Blank AND Record 3 Sale Other Carrier/GDS Validating Carrier Byte 44 Bytes 45-47 Byte 48 Blank CC O

The data in the first Set indicates the fare must be sold and displayed via GDS 1A. Additionally, the validating carrier can only be BB. Then data in the second Set indicates the fare must be sold and displayed via GDS 1A . Additionally, the validating carrier can only be CC. When validating a fare that resolves to the above Category 15 data, the table below indicates the pass/fail application depending upon the specified scenario:

Page E.03.15.053 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Scenario Application Selling and Display Location Validating Carrier Agency ABC via GDS 1A CC • Fail the first Set ( because it requires BB to be the validating carrier) and continue to the next set • Pass the Second Set. Agency ABC via GDS 1A BB Pass the first Set Agency ABC via GDS 1A XX • Fail the first Set (because it requires BB to be the validating carrier) and continue to the next set. • Fail the second Set (because it requires CC to be the validating carrier). • As no further sets exist, fail the fare. Agency ABC via GDS 1S XX • Fail the first Set (because it requires 1A to be the selling GDS and BB the validating carrier). Continue to the next set. • Fail the second Set (same as above). • As no further sets exist, fail the fare.

Page E.03.15.054 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

B. Carrier XX Private Fare Carrier intent: Must be sold by GDS 1A. Validating carrier must be BB or CC and owning/publishing carrier must be excluded as validating carrier.

Coding Example B: Category 15 data coding that does NOT support the intent THEN Record 3 Sale Other Carrier/GDS Validating Carrier Byte 44 Bytes 45-47 Byte 48 C 1A Blank AND Record 3 Sale Other Carrier/GDS Validating Carrier Byte 44 Bytes 45-47 Byte 48 Blank BB O AND Record 3 Sale Other Carrier/GDS Validating Carrier Byte 44 Bytes 45-47 Byte 48 Blank CC O The data indicates the fare must be sold and displayed via GDS 1A. Additionally, the validating carier must be BB AND the validating carrier must be CC. NOTE: It is not possible to be both validating carrier BB and CC. Therefore, with the data coded in this example, no single validating carrier will pass, and the fare will fail validation. If validating carrier is BB, then processing will fail the last Record 3 table. If validating carrier is CC, then processing will fail the second Record 3 table. Carriers should refer to the Category 15 Reference Manual (for users) for further examples on coding the data to achieve their intent.

Page E.03.15.055 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

When validating a fare that resolves to the above Category 15 data, the table below indicates the pass/fail application depending upon the specified scenario: Scenario Application Selling and Display Location Validating Carrier Agency ABC via GDS 1A XX • Fail 2nd Record 3 table (because it requires the validating carrier to be BB). Therefore, fail the set • As no further Record 3 table exist, fail the fare Agency 123 via GDS 1A BB • Fail 3rd Record 3 Table (because it requires the validating carrier to be CC). Therefore, fail the set • As no further Record 3 tables exist, fail the fare.* Agency ABC via GDS 1A CC • Fail 2nd Record 3 Table (because it requires the validating carrier to be BB). Therefore, fail the set. • As no further Record 3 tables exist, fail the fare.* * Refer to data application for Record 2 (Category Control) string processing (e.g. THEN/AND/OR processing).

Page E.03.15.056 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 5: Coding examples for Generic Alliance carrier code Carrier XX Private Fare; Generic carrier code *A has the members AA, BB, CC and XX that participate within this Alliance.

Coding Example A Carrier intent: Must only be sold and displayed by any carrier within *A Alliance. Validating carrier must be any carrier within *A Alliance, including owning carrier.

THEN Record 3 Sale Other Carrier/GDS Validating Carrier Byte 44 Bytes 45-47 Byte 48 X *A S

The data in the Record 3 table indicates the fare must be sold and displayed by owning/publishing carrier or by any member from *A Alliance . Additionally, the validating carrier must be any carrier in the *A Alliance, including the owning/publishing carrier (Carrier XX).

When validating a fare that resolves to the above Category 15 data, the table below indicates the pass/fail application depending upon the specified scenario: Scenario Application Selling and Display Location Validating Carrier XX XX • Pass the table Agency 123 via GDS 1A XX • Fail the fare (because fare must only be sold and display by any carrier within *A Alliance). XX CC • Pass the table

Page E.03.15.057 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Coding Example B Carrier intent: Must only be sold and display by any carrier within *A Alliance. Validating carrier must be any carrier within *A Alliance, owning/publishing carrier (XX) cannot be the validating carrier.

THEN Record 3 Sale Other Carrier/GDS Validating Carrier Byte 44 Bytes 45-47 Byte 48 X *A O

The data in the Record 3 table indicates the fare must be sold and displayed by owning/publishing carrier or by any member from *A Alliance . Additionally, the validating carrier must be any carrier in the *A Alliance, except the owning/publishing carrier of the fare (carrier XX cannot be the validating carrier).

When validating a fare that resolves to the above Category 15 data, the table below indicates the pass/fail application depending upon the specified scenario: Scenario Application Selling and Display Location Validating Carrier XX XX • Fail the fare ( because Carrier XX cannot be the validating carrier) Agency 123 via GDS 1A XX • Fail the fare (because fare must only be sold and display by any carrier within *A Alliance, and carrier XX cannot be the validating carrier). BB CC • Pass the table

Page E.03.15.058 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Coding Example C Carrier intent: Validating carrier must be any carrier within *A Alliance, including owning/publishing carrier. There are no restrictions on the selling and display location of the fare.

THEN Record 3 Sale Other Carrier/GDS Validating Carrier Byte 44 Bytes 45-47 Byte 48 Blank *A S The data in the Record 3 table indicates the validating carrier any carrier in the *A Alliance, including the owning/publishing carrier (carrier XX). Additionally, there are no restrictions on the sale and display of the fare based on these fields.

When validating a fare that resolves to the above Category 15 data, the table below indicates the pass/fail application depending upon the specified scenario: Scenario Application Selling and Display Location Validating Carrier XX XX • Pass, provided sales restriction data also exists in the table, since sales data is required in a private tariff to pass the fare. Agency 123 via GDS 1A XX • Pass, provided sales restriction data also exists in the table, since sales data is required in a private tariff to pass the fare. XX DD • Fail the fare (because it requires the validating carrier to be any carrier within *A Alliance, carrier DD is not a part of the *A Alliance).

Page E.03.15.059 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Coding Example D Carrier intent: Validating carrier must be any carrier within *A Alliance, excluding owning/publishing carrier (the owning/publishing carrier cannot be the validating carrier). There are no restrictions on the selling and display location of the fare based on these fields.

THEN Record 3 Sale Other Carrier/GDS Validating Carrier Byte 44 Bytes 45-47 Byte 48 Blank *A O The data in the Record 3 table indicates the fare must be validated by any carrier in the *A Alliance excluding the owning/publishing carrier (carrier XX cannot be the validating carrier). Additionally, there are no restrictions on the sale and display location of the fare based on these fields.

When validating a fare that resolves to the above Category 15 data, the table below indicates the pass/fail application depending upon the specified scenario: Scenario Application Selling and Display Location Validating Carrier XX XX • Fail the fare (because it requires the validating carrier to be any carrier within *A Alliance, excluding XX). Agency 123 via GDS 1A BB • Pass, provided sales restriction data also exists in the table, since sales data is required in a private tariff to pass the fare. CC DD • Fail the fare (because it requires the validating carrier to be any carrier within *A Alliance, carrier DD is not a part of the *A Alliance).

Page E.03.15.060 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

4.1.5.4 Segment (Byte 49)

If this field is populated, it indicates that all flown segments of travel on the ticket (value N – all flight coupons, if more than one flight coupon issued for the entire ticket), or all flown segments of the fare (value F – all flown segments of the fare component being validated) must be on the publishing carrier, and/ or other carrier, if bytes 45-47 (Other Carrier/GDS) are coded in conjunction with Byte 49.

When Byte 49 is populated for a YY fare, this indicates that all flown segments of travel on the ticket or all flown segments of the fare must be on the carrier providing transportation on the primary portion of travel and/or other carrier if bytes 45-47 are populated. (Note: ATPCO Coding Conventions hold that byte 49 is not appropriate to be used on a YY fare). 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 is attempting to select YY fares in lieu of carrier-specific fares.

Example: MEL-TYO fare component Travel is: MEL-XX-JKT-DD-TYO

Page E.03.15.061 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 1 – Ticket (same carrier round trip)

IPREUAS rule 2000 for carrier LH Record 2 YTKT fare class Record 3 Sale Other Carrier Validation Segment Byte 44 Bytes 45-47 Byte 48 Byte 49 BLANK BLANK BLANK N The data indicates that for the YTKT fare, all flown segments of travel on the entire ticket (all flight coupons) must be on LH.

Itinerary (BRU-BKK round trip using LH YTKT fare BRU-BKK and LH Y fare BKK-BRU)

½ of LH YTKT fare LH LH LH BRU FRA DEL BKK LH LH LH ½ of LH Y fare

When pricing the BRU-BKK fare component that resolves to the single Record 3 as coded above: PASS - all flown segments of travel on the entire ticket are on LH.

When pricing the BKK-BRU fare component: PASS - no category 15 data exists; apply system assumption (no sales restrictions).

Page E.03.15.062 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 2 – Ticket (different carriers)

IPREUAS rule 2000 for carrier QF Record 2 YAP fare class Record 3 Sale Other Carrier Validation Segment Byte 44 Bytes 45-47 Byte 48 Byte 49 BLANK BLANK BLANK N The data indicates that for the YAP fare, all flown segments of travel on the entire ticket (all flight coupons) must be on QF.

IPREURP rule 4000 for carrier LH F fare class (no applicable Category 15)

Itinerary (SYD-FRA round trip using QF YAP fare and FRA-MUC one way using LH F fare)

½ of QF YAP fare LH F fare QF LH SYD FRA MUC QF ½ of QF YAP fare

When pricing the QF SYD-FRA and FRA-SYD fare components that each resolve to the single Record 3 as coded above: FAIL - all flown segments of travel on the entire ticket are not on QF.

Page E.03.15.063 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 3 – Ticket with bytes 45-47 coded (Public Tariff)

IPRA rule 2000 for carrier LH Record 2 Y2 fare class Record 3 Sale Other Carrier Validation Segment Byte 44 Bytes 45-47 Byte 48 Byte 49 X UA BLANK N The data indicates that the Y2 fare for LH may only be sold by LH or UA and all flown segments of travel on the entire ticket (all flight coupons) must be on LH or UA.

Itinerary (FRA-DEN round trip using LH Y2 fare FRA-DEN and LH Y fare DEN-FRA)

½ of LH Y2 fare LH UA FRA NYC DEN LH UA ½ of LH Y fare

When pricing the FRA-DEN fare component that resolves to the single Record 3 as coded above: PASS - all flown segments of travel on the entire ticket are on LH or UA (assume fare was sold by LH or UA).

When pricing the DEN-FRA fare component: PASS - no category 15 data exists; apply system assumption (no sales restrictions).

Page E.03.15.064 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 4 – Ticket with bytes 45-47 coded (Private Tariff)

Private Tariff rule 2000 for carrier LH Record 2 Y2 fare class Record 3 Sale Other Carrier Validation Segment Byte 44 Bytes 45-47 Byte 48 Byte 49 X UA BLANK N The data indicates that the Y2 fare for LH may only be sold and displayed by LH or UA and all flown segments of travel on the entire ticket (all flight coupons) must be on LH or UA.

Itinerary (FRA-DEN round trip using LH Y2 fare FRA-DEN and LH Y fare DEN-FRA)

½ of LH Y2 fare LH UA FRA NYC DEN LH UA ½ of LH Y fare

When pricing the DEN-FRA fare component: PASS - no category 15 data exists; apply system assumption (no sales restrictions).

Page E.03.15.065 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 5 – Fare

IPRA rule 2000 for carrier LH Record 2 Y2 fare class Record 3 Sale Other Carrier Validation Segment Byte 44 Bytes 45-47 Byte 48 Byte 49 BLANK BLANK BLANK F The data indicates that for the Y2 fare, all flown segments of travel on the fare component being validated must be on LH.

Itinerary (MUC-CHI round trip using LH Y2 fare MUC-CHI and LH Y fare CHI-MUC)

½ of LH Y2 fare LH LH MUC FRA CHI DE LH ½ of LH Y fare

When pricing the MUC-CHI fare component that resolves to the single Record 3 as coded above: PASS - all flown segments of travel on the fare component being validated (MUC-CHI) are on LH.

When pricing the CHI-MUC fare component: PASS - no category 15 data exists; apply system assumption (no sales restrictions).

Page E.03.15.066 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 6 – Fare with bytes 45-47 coded (Public Tariff)

IPRA rule 2000 for carrier DL Record 2 YXAP fare class Record 3 Sale Other Carrier Validation Segment Byte 44 Bytes 45-47 Byte 48 Byte 49 X KL BLANK F The data indicates that the YXAP fare for DL may only be sold by DL or KL and all flown segments of travel on the fare component being validated must be on DL or KL.

Itinerary (MSP-IST round trip using KL Y fare MSP-IST and DL YXAP fare IST-MSP)

½ of KL Y fare KL KL MSP AMS IST DL KL ½ of DL YXAP fare

When pricing the KL MSP-IST fare component that resolves to the single Record 3 as coded above: PASS - no category 15 data exists; apply system assumption (no sales restrictions).

When pricing the DL IST-MSP fare component: PASS - all flown segments of travel on the fare component being validated (IST-MSP) are on DL or KL (assume fare was sold by DL or KL).

Page E.03.15.067 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 7 – Fare with bytes 45-47 coded (Private Tariff)

Private Tariff rule 2000 for carrier DL Record 2 YXAP fare class Record 3 Sale Other Carrier Validation Segment Byte 44 Bytes 45-47 Byte 48 Byte 49 X KL BLANK F The data indicates that the YXAP fare for DL may only be sold and displayed by DL or KL and all flown segments of travel on the fare component being validated must be on DL or KL.

Itinerary (MSP-IST round trip using KL Y fare MSP-IST and DL YXAP fare IST-MSP)

½ of KL Y fare KL KL MSP AMS IST DL KL ½ of DL YXAP fare

When pricing the KL MSP-IST fare component that resolves to the single Record 3 as coded above: PASS - no category 15 data exists; apply system assumption (no sales restrictions).

When pricing the DL IST-MSP fare component: PASS - all flown segments of travel on the fare component being validated (IST-MSP) are on DL or KL (assume fare was sold and displayed by DL or KL).

Page E.03.15.068 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 8 – Fare with bytes 45-47 coded (Private Tariff)

Private Tariff rule 8000 for carrier XX Record 2 YXAP fare class Record 3 Sale Other Carrier Validation Segment Byte 44 Bytes 45-47 Byte 48 Byte 49 Blank ZZ O F The data indicates that for XX’s YXAP fare, the validating carrier must be ZZ ( XX cannot be the validating carrier); and all flown segments of travel on the fare component being validated must be on XX and/or ZZ.

Itinerary (MSP-IST round trip using ZZ Y fare MSP-IST and XX YXAP fare IST-MSP) Validating Carrier = ZZ

½ of ZZ Y fare ZZ ZZ MSP AMS IST XX ZZ ½ of XX YXAP fare

When pricing the ZZ MSP-IST fare component: PASS - no category 15 data exists; apply system assumption (no sales restrictions for public fares).

When pricing the XX IST-MSP fare component: PASS - all flown segments of travel on the fare component being validated (IST-MSP) are ZZ and/or XX, and the validating carrier is ZZ.

Page E.03.15.069 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 9 – Fare with bytes 44-48 coded (Public Tariff)

IPRA rule 2000 for carrier XX Record 2 YXAP fare class Record 3 Sale Other Carrier Validation Segment Byte 44 Bytes 45-47 Byte 48 Byte 49 X ZZ O F The data indicates that for XX’s YXAP fare: only XX and/or ZZ may sell the fare, the validating carrier must be ZZ ( XX cannot be the validating carrier), and all flown segments of travel on the fare component being validated must be on XX and/or ZZ.

Itinerary (MSP-IST round trip using XX YXAP fare MSP-IST and DL Y fare IST-MSP) Validating carrier = ZZ

½ of XX YXAP fare XX ZZ MSP AMS IST XX ZZ ½ of ZZ YXAP fare

When pricing the XX MSP- IST fare component that resolves to the Record 3 as coded above: PASS - all flown segments of travel on the fare component being validated (MSP - IST) are on XX and/or ZZ, and the validating carrier is ZZ (assume fare was sold by XX or ZZ).

When pricing the ZZ IST - MSP fare component: PASS - no category 15 data exists; apply system assumption (no sales restrictions).

4.1.6 Travel Agency Restrictions - ‘Sale’, Byte 50

Page E.03.15.070 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Public Tariffs: When this field is populated it indicates that the ticket may only (Y), or may not (N) be sold by travel agencies.

Private Tariffs: When this field is populated it indicates that the ticket may only (Y), or may not (N) be sold and displayed by travel agencies.

When bytes 44-47 (Sale, Other Carriers/CRS) are coded in conjunction with Byte 50, the relationship between the two is AND. If the intent is that the relationship be OR, then the data must be coded in two Record 3 data tables.

Public Tariff Examples

Example 1 IPRA rule 2000 for carrier AA Record 3 Byte 44 Byte 50 Sale (Carrier Restriction) Sale (Travel Agency Restriction X Blank

Byte 44 indicates that only the publishing carrier (AA) may sell the fare, and Byte 50 is not applicable (no statement is made regarding travel agencies). Therefore, the data represents that only AA may sell the fare.

Example 2 IPRA rule 2000 for carrier AA Record 3 Byte 44 Byte 45-47 Byte 50 Sale (Carrier Restriction) Other Carrier Sale (Travel Agency Restriction) C 1G Blank

Bytes 45-47 indicate that only CRS 1G may sell the fare, and byte 50 is not applicable (no statement is made regarding travel agencies). Therefore, the data represents that any carrier or travel agent in 1G may sell the fare. (In this example, bytes 45-47 identify the pricing system permitted to sell the fare, not the specific carrier or travel agency).

Page E.03.15.071 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 3 IPRA rule 2000 for carrier AA Record 3 Byte 44 Bytes 45-47 Byte 50 Sale (Carrier Restriction) Other Carrier Sale (Travel Agency Restriction) C 1G N

Bytes 45-47 indicate that only CRS 1G may sell the fare, and Byte 50 indicates that travel agencies may not sell the fare. Therefore, the data represents that any carrier in 1G may sell the fare; however, travel agencies in 1G may not sell the fare.

Example 4 IPRA rule 2000 for carrier AA THEN Record 3 Byte 44 Bytes 45-47 Byte 50 Sale (Carrier Restriction) Other Carrier Sale (Travel Agency Restriction) C 1G Y OR Record 3 Byte 44 Bytes 45-47 Byte 50 Sale (Carrier Restriction) Other Carrier Sale (Travel Agency Restriction) X BLANK BLANK

In the first table, bytes 45-47 indicate that only CRS 1G may sell the fare, and Byte 50 indicates that only travel agencies may sell the fare. Therefore, the data in the first table represents that only travel agencies in 1G may sell the fare. In the second table, byte 44 indicates that only the publishing carrier (AA) may sell the fare, and Byte 50 is not applicable (no statement is made regarding travel agencies). Therefore, the data in the second table represents that only AA may sell the fare. Together, the tables represent that only travel agencies in 1G or AA may sell the fare.

Example 5 IPRA rule 2000 for carrier AA Record 3

Page E.03.15.072 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Byte 44 Bytes 45-47 Byte 50 Sale (Carrier Restriction) Other Carrier Sale (Travel Agency Restriction) X BLANK Y

Byte 44 indicates that only the publishing carrier (AA) may sell the fare, and Byte 50 indicates that sales are restricted to travel agencies. Because there is an AND relationship, the data represents that only AA and only travel agencies may sell the fare. In this instance, the fare would fail pricing as both restrictions cannot be satisfied. If the intent is that only the publishing carrier or travel agencies may sell the fare, then the data would need to be entered in two tables linked with relational indicator OR.

Private Tariff Examples

Example 1 Private Tariff rule 2000 for carrier AA Record 3 Byte 44 Byte 50 Sale (Carrier Restriction) Sale (Travel Agency Restriction X Blank

Byte 44 indicates that only the publishing carrier (AA) may sell and display the fare, and Byte 50 is not applicable (no statement is made regarding travel agencies). Therefore, the data represents that only AA may sell and display the fare.

Page E.03.15.073 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 2 Private Tariff rule 2000 for carrier AA Record 3 Byte 44 Bytes 45-47 Byte 50 Sale (Carrier Restriction) Other Carrier Sale (Travel Agency Restriction) C 1G Blank

Bytes 45-47 indicate that only CRS 1G may sell and display the fare, and Byte 50 is not applicable (no statement is made regarding travel agencies). Therefore, the data represents that any carrier or travel agent in 1G may sell and display the fare. (In this example, bytes 45-47 identify the pricing system permitted to sell and display the fare, not the specific carrier or travel agency).

Example 3 Private Tariff rule 2000 for carrier AA Record 3 Byte 44 Bytes 45-47 Byte 50 Sale (Carrier Restriction) Other Carrier Sale (Travel Agency Restriction) C 1G N

Bytes 45-47 indicate that only CRS 1G may sell and display the fare, and Byte 50 indicates that travel agencies may not sell and display the fare. Therefore, the data represents that any carrier in 1G may sell and display the fare; however, travel agencies in 1G may not sell the fare.

Example 4 Private Tariff rule 2000 for carrier AA THEN Record 3 Byte 44 Bytes 45-47 Byte 50 Sale (Carrier Restriction) Other Carrier Sale (Travel Agency Restriction) C 1G Y OR Record 3 Byte 44 Bytes 45-47 Byte 50

Page E.03.15.074 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Sale (Carrier Restriction) Other Carrier Sale (Travel Agency Restriction) X BLANK BLANK

In the first table, bytes 45-47 indicate that only CRS 1G may sell and display the fare, and Byte 50 indicates that only travel agencies may sell and display the fare. Therefore, the data in the first table represents that only travel agencies in 1G may sell and display the fare. In the second table, byte 44 indicates that only the publishing carrier (AA) may sell and display the fare, and Byte 50 is not applicable (no statement is made regarding travel agencies). Therefore, the data in the second table represents that only AA may sell and display the fare. Together, the tables represent that only travel agencies in 1G or AA may sell and display the fare.

Example 5 Private Tariff rule 2000 for carrier AA Record 3 Byte 44 Bytes 45-47 Byte 50 Sale (Carrier Restriction) Other Carrier Sale (Travel Agency Restriction) X BLANK Y

Byte 44 indicates that only the publishing carrier (AA) may sell and display the fare, and Byte 50 indicates that sales and display are restricted to travel agencies. Because there is an AND relationship, the data represents that only AA and only travel agencies may sell and display the fare. In this instance, the fare would fail pricing as both restrictions cannot be satisfied. If the intent is that only the publishing carrier or travel agencies may sell and display the fare, then the data would need to be entered in two tables linked with relational indicator OR.

4.1.7 Form of Payment, Byte 52-55

The following Forms of Payment are addressed in fields 52-55: Cash - byte 52, Check - byte 53, Credit Card (or Debit Card) - byte 54 and Government Transportation Request - byte 55. When any of these fields are populated, the ‘Form (s) of Payment’ indicated are not acceptable Forms of Payment for a ticket. If any of Byte 52-55 are present then these are not acceptable Forms of

Page E.03.15.075 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Payment for the ticket being purchased. If any payment fields are received Blank that form of payment is permitted when purchasing a ticket. If all of the form of payment fields are received blank then there is no form of payment restriction.

Processing will determine the type of payment being used and match that to the corresponding byte. If the byte is blank then that form of payment is permitted. If the byte is “X” than that form of payment is not permitted and the fare will fail processing.

Example of non - acceptable Forms of Payment in conjunction with acceptable Forms of Payment:

Record 3: Cash Check Credit Card (Debit Card) Government Transportation Request Byte 52 Byte 53 Byte 54 Byte 55 X X

The data represents that Cash and Government Transportation Request are not acceptable forms of payment for the fare component being validated. However, Checks and Credit Cards (or Debit Cards) are permitted.

4.1.8 Currency - ‘Country Restriction’, Byte 56

When this field is populated it indicates that the fare may only be sold in the currency of the country of origin (O), the currency of the country of destination (‘D’ destination for the fare component) or the currency of either (E) country of origin or country of destination. The currency does not restrict the sale location or actual itinerary. If this field is received Blank sales are not restricted to the currency of the country of origin, the country of destination and/or both. When byte 56 and bytes 57-59 are coded, the relationship between these fields is OR.

Currency of country of origin is determined by the origin country of how the fare was selected (see Record 2 Data Application for definition of Origin) and by that country’s resolution of the currency that is published (see IATA Resolutions 024E and 010H). Currency of country of destination is the other terminal point of the fare component, determined by that country’s resolution of the currency that is published (see IATA Resolutions 024E and 010H).

Page E.03.15.076 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 1 Currency of Country Restriction (Origin)

Record 2 - GB - US Record 3 Currency Country Restriction Byte 56 O

The data represents that the fare may only be sold in the currency of the origin country based on how the fare was selected and that country’s resolution of the currency that is published (see IATA Resolutions 024E and 010H). Round Trip Itinerary priced NYC-LON, LON-NYC. Passenger is in the United Kingdom, paying in USD.

NYC LON direction of travel direction of fare selection

When pricing NYC- LON and LON-NYC fare components that each resolve to a single Record 3 as coded above: NYC-LON PASS: Origin Country is US based on fare selection and payment is in USD. LON-NYC PASS: Origin Country is US based on fare selection and payment is in USD.

Example 2 Currency of Country Restriction (Origin)

Record 2 - FR - US Record 3 Currency Country Restriction Byte 56 O

Page E.03.15.077 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

The data represents that the fare may only be sold in the currency of the origin country based on how the fare was selected and that country’s resolution of the currency that is published (see IATA Resolutions 024E and 010H). Round Trip Itinerary priced PAR-NYC, NYC-PAR. Passenger is in France, paying in FRF. Origin country is France and fares are published in EUR.

PAR NYC direction of travel direction of fare selection

When pricing PAR-NYC and NYC-PAR fare components that each resolve to a single Record 3 as coded above: PAR-NYC PASS: Origin Country is FR based on fare selection and payment is in FRF (resolution of currency published for France is EUR or FRF). NYC-PAR PASS: Origin Country is FR based on fare selection and payment is in FRF (resolution of currency published for France is EUR or FRF).

Example 3 of Currency of Country Restriction (Destination)

Record 2 - GB - US Record 3 Currency Country Restriction Byte 56 D

The data represents that the fare may only be sold in the currency of the destination country based on how the fare was selected and that country’s resolution of the currency that is published (see IATA Resolutions 024E and 010H).

Round Trip Itinerary priced NYC-LON, LON-NYC. Passenger is in the United Kingdom, paying in USD.

Page E.03.15.078 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

NYC LON direction of travel direction of fare selection

When pricing NYC- LON and LON-NYC fare components that each resolve to a single Record 3 as coded above: NYC-LON – FAIL: Destination country is GB based on fare selection and payment is in USD. (Currency must be GBP to pass). LON-NYC – FAIL: Destination country is GB based on fare selection and payment is in USD. (Currency must be GBP to pass).

4.1.9 ‘Currency’, Bytes 57-59

If this field is populated, it restricts the sale of the fare to a specific currency. Again, it does not restrict the sale location or the actual itinerary, it only restricts the payment of the ticket to a specific currency. If this field is received Blank the sale of the ticket is not limited to any specific currency. When byte 56 and bytes 57-59 are coded, the relationship between these fields is OR.

Example of Only in Currency Code Restriction:

Record 2 - FR - CA Record 3 Currency Bytes 57-59 CAD

The data represents that the fare may only be sold in CAD. Three component Circle Trip priced YTO-LON, LON-PAR, PAR-YTO. Passenger is in France, paying in CAD. YTO LON

PAR

Page E.03.15.079 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

When pricing YTO-LON fare component: PASS: There are no sales restrictions applicable to this fare component.

When pricing LON-PAR fare component: PASS: There are no sales restrictions applicable to this fare component.

When pricing PAR-YTO fare component that resolves to a single Record 3 above: PASS: The passenger wished to purchase the ticket in France and pay for the ticket in Canadian dollars, thus meeting the currency sales restriction.

Example 2 of ‘Currency of Origin Country’ (Byte 56) and ‘Only in currency code’ (Bytes 57-59) within the same table:

Record 2 - N US N FR Record 3 Currency Country Restriction Currency Byte 56 Bytes 57-59 O FRF

The data represents that the fare may only be sold in the currency of the country of origin based on fare selection, OR that the fare may only be sold in FRF.

Three component Circle Trip priced NYC-LON, LON - PAR, PAR - NYC. Passenger is in France purchasing the ticket in USD.

NYC LON direction of travel direction of fare selection

PAR

Page E.03.15.080 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

When pricing NYC-LON fare component: PASS: There are no sales restrictions applicable to this fare component.

When pricing LON-PAR fare component: PASS: There are no sales restrictions applicable to this fare component.

When pricing the PAR-NYC fare component that resolves to a single Record 3 as coded above: PASS: The origin country of the PAR-NYC fare component based on fare selection is US. The passenger is in France but is purchasing the ticket in USD which meets the currency of country of origin restriction.

Page E.03.15.081 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

4.1.10 Ticket Issuance, Bytes 60-61,63-65,67-68 Mail, PTA, Self, PTA=TKT, Automatic Ticketing Machines, SATO/CATO, Electronic Ticketing.

Bytes 60-61, 63-65, 67-68 are information fields only unless any byte is set to an R (required) or N (not permitted). The presence of a value of ‘Y’ is used to create Text and has no processing application.

When processing Bytes 60-61,63-65, 67-68 the following processing rules are to be applied:

1) Stringing laws as described in Record 2 Data Application will apply.

2) Check Bytes 60-61, 63-65, 67-68. When the value in all bytes is Blank , then there is no restriction on the type of ticketing transaction.

3) Passing one of the coded values is done by determining the type of the ticketing transaction being created. When the corresponding value is “R”, then that ticketing transaction is required, and all other transactions are not permitted.

4) When the corresponding value is “N”, then that ticketing transaction is not permitted.

5) When the corresponding value is “Y” or blank, then that type of ticketing transaction is permitted. (provided there are no “R” values in the table).

6) If the conditions of the table are satisfied, then pass the table. Read on to an AND table. If no AND table or if the data satisfies the conditions of the AND table, then pass the fare.

7) If the conditions of the table are not satisfied, then read on to the next OR table or Set. If no further Or tables or Sets or if the conditions of the other OR tables or Sets are not satisfied, then fail the fare.

Page E.03.15.082 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example of Ticket issuance data strings and the application of ‘Y’ ‘N’ ‘R’ : a) Record 3 Mail PTA Self PTA=TKT ATM SATO/CATO Elec. Tktg. Byte 60 Byte 61 Byte 63 Byte 64 Byte 65 Byte 67 Byte 68 Y Y

The data represents that all types of ticketing transactions are permitted (Mail tickets/PTA produces text).

b) Record 3 Mail PTA Self PTA=TKT ATM SATO/CATO Elec. Tktg. Byte 60 Byte 61 Byte 63 Byte 64 Byte 65 Byte 67 Byte 68 Y N

The data represents that PTA’s are not allowed, all others are permitted (“Y” in Mail Ticket produces text, and “N” in PTA produces text).

c) Record 3 Mail PTA Self PTA=TKT ATM SATO/CATO Elec. Tktg. Byte 60 Byte 61 Byte 63 Byte 64 Byte 65 Byte 67 Byte 68 R

The data represents that Mail ticket is required, all others are not permitted. (If not MAIL ticketing, then processing will read on to another OR table or SET).

Page E.03.15.083 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

d) Example of two data tables strung with OR both tables containing value ‘R’

Record 3 THEN Mail PTA Self PTA=TKT ATM SATO/CATO Elec. Tktg. Byte 60 Byte 61 Byte 63 Byte 64 Byte 65 Byte 67 Byte 68 R

Record 3 OR Mail PTA Self PTA=TKT ATM SATO/CATO Elec. Tktg. Byte 60 Byte 61 Byte 63 Byte 64 Byte 65 Byte 67 Byte 68 R

The data represents that either Mail ticket or PTA is required - any other type of ticketing is not permitted. If PTA, then processing would fail the first table and read the second table. Processing would pass the second table.

e) Example of two data tables strung with OR containing values ‘R’ and ‘Y’

Record 3 THEN Mail PTA Self PTA=TKT ATM SATO/CATO Elec. Tktg. Byte 60 Byte 61 Byte 63 Byte 64 Byte 65 Byte 67 Byte 68 R

Record 3 OR Mail PTA Self PTA=TKT ATM SATO/CATO Elec. Tktg. Byte 60 Byte 61 Byte 63 Byte 64 Byte 65 Byte 67 Byte 68 Y N

Page E.03.15.084 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

The data on the first table represents that PTA is required and all other types of ticketing transactions are not permitted. On the second table, PTA is not permitted, and all other types of ticketing transactions are permitted (Mail/PTA produce text). If ET, then fail the first table. Read on to the second table and pass on the second table.

f) Example of two data tables strung with AND both tables containing value ‘R’

Record 3 THEN Mail PTA Self PTA=TKT ATM SATO/CATO Elec. Tktg. Byte 60 Byte 61 Byte 63 Byte 64 Byte 65 Byte 67 Byte 68 R

Record 3 AND Mail PTA Self PTA=TKT ATM SATO/CATO Elec. Tktg. Byte 60 Byte 61 Byte 63 Byte 64 Byte 65 Byte 67 Byte 68 R

The data represents that both Mail ticket and PTA are required. As it is not possible to satisfy both, processing would fail and read on to the next set.

Page E.03.15.085 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

4.1.11 ‘SITI’, ‘SITO’, ‘SOTI’, ‘SOTO,’ Bytes 71-74

The SITI, SOTO, SITO, SOTI applicable tags ‘Y’ (Allowed), ‘N’ (Not Allowed), ‘R’ (Required) apply to the ticket.

Bytes 71-74 are considered as a group, and when processing these bytes, the following processing rules are to be applied:

1) Stringing laws as described in Record 2 Data Application will apply. 2) Check all bytes 71-74 within the group. When all bytes in the group are blank then there is no restriction on the type of ticketing/sales transaction.

3) Check all bytes 71-74 within the group. When any of the bytes within the group are coded then you must pass at least one of these coded values.

4) Passing one of the coded values is done by determining the type of the transaction being created. When the type of transaction is determined and the corresponding byte is “N”, then that type of transaction is not permitted. Processing will fail the table and read the next subset.

5) When the corresponding value is “R” or “Y” then that type of transaction is allowed.

6) When the corresponding value is blank (except when all values in bytes 71-74 are blank as described in step 1), then that type of transaction is not permitted.

7) If the conditions of the table are satisfied, then pass the table. Read on to an AND table. If no AND table or if satisfy the conditions of the AND table, then pass the fare. 8) If the conditions of the table are not satisfied, then read on to the next OR table or Set. If no further Or tables or Sets or if the conditions of the other OR tables or Sets are not satisfied, then fail the fare.

Page E.03.15.086 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Examples of data strings: a) Record 3 SITI SOTO SITO SOTI Byte 71 Byte 72 Byte 73 Byte 74 Y The data represents that a SITI transaction is permitted, if no further tables then other types not permitted.

b) Record 3 SITI SOTO SITO SOTI Y Y The data represents that a SITI or a SOTO transaction is permitted, if no further tables then other types not permitted.

c) Record 3 SITI SOTO SITO SOTI R The data represents that a SITI transaction is required, if no further tables then other types not permitted.

d) Record 3 THEN SITI SOTO SITO SOTI R Record 3 OR SITI SOTO SITO SOTI R The data represents that a SITI or a SOTO transaction is required, if no further tables then other types are not permitted. e) Record 3 THEN

Page E.03.15.087 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

SITI SOTO SITO SOTI R Record 3 OR SITI SOTO SITO SOTI Y The data in the first table represents that a SITI transaction is required. If not a SITI transaction, processing will read on to the next table which represents that a SOTO transaction is permitted. If no further tables, then other types are not permitted. NOTE: Other data would be present to warrant multiple Record 3 data tables.

f) Record 3 SITI SOTO SITO SOTI N The data represented is invalid, a SITI transaction is not permitted, but no other value was present with a Y to allow any type of ticketing transaction.

g) Record 3 SITI SOTO SITO SOTI N Y Y Y The data represents that SITI transactions are not permitted, and that SOTO, SITO, and SOTI transactions are permitted.

Page E.03.15.088 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

4.1.12 ‘Ticket Issuance’, Bytes 60-70, and ‘SITI’, ‘SOTO’, ‘SITO’, ‘SOTI’, Bytes 71-74

SITI, SOTO, SITO, SOTI values apply to the ticket and may affect the types of ticketing permitted for multiple fares used on the same ticket. Results: for fares on the same ticket with different values in bytes 60-74 are shown below.

NOTE: It is possible to have a value of ‘R’ (Required) present in both byte 68 (Electronic Ticketing), and Bytes 71-74 (SITI/SOTO/SITO/SOTI).

Example 1: Two different fares on the same ticket:

Record 3 (Applicable to Fareclass 1) Electronic Ticketing Byte 68 R

Record 3 (Applicable to Fareclass 2) Electronic Ticketing Byte 68 Y

The data represents that Electronic ticketing is required.

Page E.03.15.089 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 2 Record 3 (Applicable to Fareclass 1) SOTO Byte 72 Y

Record 3 (Applicable to Fareclass 2) SOTO Byte 72 N

The data represents that ‘Sale and Ticketing Outside Origin Country’ is not permitted.

Example 3

Record 3 (Applicable to Fareclass 1)

SOTO Byte 72 R

Record 3 (Applicable to Fareclass 2) SOTO Byte 72 N

The data represents that these two fares may not be ticketed on the same ticket using any of the above ticket issuance options.

Page E.03.15.090 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

4.1.13 ‘Family/Group’, Byte 80

This field indicates that all passengers that are traveling together in order to qualify for the fare must be ticketed at the same time.

Example

Record 1 Y fare YCOMP fare

CATEGORY 13 Record 2 YCOMP fare Record 3 Byte 14 Byte 63 Bytes 64-66 Bytes 67-74 All F/B No. of Segments Fare Class X F 01 YCMA

CATEGORY 15 Record 2 YCOMP fare Record 3 Byte 80 Family/Group X

According to Category 13, the YCOMP passenger must be accompanied on all sectors of the fare component by a passenger traveling in fare class Y in order to qualify for the fare. Therefore, the data in Category 15 Byte 80 is applicable, and both passengers must be ticketed at the same time. (If the Y passenger were traveling alone, then Byte 80 would not apply as there are no accompanied travel requirements for the Y fare).

Page E.03.15.091 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

4.1.14 ‘Extension of ticket validity’, Byte 81

Ticket validity is referring to the actual life of the ticket. This field can indicate if ticket validity may be extended (X) or may not be extended (N). If this field is received Blank then the following information will apply. The normal validity of a published round trip ticket is one year from the date travel commences from the point of origin, or for open tickets one year from the date of issue.

NOTE: Certain tickets in addition to maximum validity are also restricted to a maximum stay.

Once the validity of a ticket is defined by the date of commencement of travel, such validity will be maintained for any subsequent reissue or rerouting,

Exception for Refund: When a totally unused or partly used ticket is refunded (not reissued) and a new ticket is issued with a fare that has no connection to the original transportation already undertaken, a new validity will be determined using the date of travel commencement from the point of origin for the new ticket being issued.

NOTE: Individual carriers may deviate from this standard, if so this should be noted in their general rules. In this case it may be necessary to interrogate the general rule (if any) of the carrier providing carriage for the fare component being validated. Example:

Using the normal ticket validity definition when pricing a ticket with the following travel dates and value ‘N’ in Byte 81.

01Jan 98 FAR FRA 01Feb 99

This would fail pricing as return travel was beyond the ticket validity date of 01Jan 99 (one year from the commencement of travel 1/1/98).

Page E.03.15.092 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

4.1.15 Override Date Table Number 994 (Bytes 82-89)

A number referring to a table containing dates on which travel, ticketing and/or reservations are valid for the data in this category. When present, it further defines the specific date range within Effective/Discontinue dates of the Record 2. If the reservation, ticketing and/or travel dates of the fare being processed are not within the dates specified by the override date table, no-match and continue processing. If no further tables/sets 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.

4.1.16 Text Table Number 996 (bytes 90-97) and Unavailable Data Tag (byte 98)

When the Unavailable Data Tag is set to value ‘X’ (unavailable data), the fare being priced should fail. When the Unavailable Data Tag is set to value ‘Y’(text data only), retrieve the referenced 996 Text Table for text display. The 996 table 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 set to ‘Y’, the table would not be applicable as ‘Y’ refers to text data only, and the system assumption would apply for this category. If a ‘Then, And’ set is coded and the ‘Then’ table has an Unavailable Data Tag set to ‘Y’ , then the ‘Then’ table is not applicable as ‘Y’ refers to text data only. Only the ‘And’ table would need to be satisfied.

Example 1 (Value X) Record 3 THEN Tktg First Tktg Last Text Table Number 996 Unavailable Data Tag Bytes 21-27 bytes 35-41 Bytes 90-97 Byte 98 01Jan 99 Blank Blank X Processing will fail the fare as a result of the presence of value “X” in byte 98.

Page E.03.15.093 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 2 (Value X) Record 3 THEN Tktg First Tktg Last Text Table Number 996 Unavailable Data Tag Bytes 21-27 bytes 35-41 Bytes 90-97 Byte 98 01Jan 99 Blank Blank X Record 3 OR Tktg First Tktg Last Text Table Number 996 Unavailable Data Tag Bytes 21-27 bytes 35-41 Bytes 90-97 Byte 98 02Feb99 Blank Blank X For the first table, processing will fail the table as a result of the presence of value “X” in byte 98; processing will read on to the next table. The data in the second table indicates the earliest date ticketing is permitted is 02Feb 99.

Example 3 (Value X) Record 3 THEN Tktg First Tktg Last Text Table Number 996 Unavailable Data Tag Bytes 21-27 bytes 35-41 Bytes 90-97 Byte 98 01Jan 99 Blank Blank X Record 3 AND Tktg First Tktg Last Text Table Number 996 Unavailable Data Tag Bytes 21-27 bytes 35-41 Bytes 90-97 Byte 98 02Feb99 Blank Blank X For the first table, processing will fail the table as a result of the presence of value “X” in byte 98; processing will not read on to the next table and will fail the set.

Page E.03.15.094 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 4 (Value Y) Record 3 THEN Tktg First Tktg Last Text Table Number 996 Unavailable Data Tag Bytes 21-27 bytes 35-41 Bytes 90-97 Byte 98 Blank Blank 123 Y Table Number 123 = Extension of ticket validity for medical reasons is not permitted. Record 3 AND Tktg First Tktg Last Text Table Number 996 Unavailable Data Tag Bytes 21-27 bytes 35-41 Bytes 90-97 Byte 98 24Jan 98 30Mar 98 Blank Blank The data in the first table indicates that the table contains text data only and is not applicable for autopricing. The data in the second table indicates that the earliest date ticketing is permitted is 24 Jan 98 and the latest date ticketing is permitted is 30Mar 98. Processing will not apply data in the first table and will read the second table. Conditions in the AND table must be satisfied in order to pass category validation.

Example 5 (Value Y) Record 3 THEN Tktg First Tktg Last Text Table Number 996 Unavailable Data Tag Bytes 21-27 bytes 35-41 Bytes 90-97 Byte 98 Blank Blank 123 Y Table Number 123 = Extension of ticket validity for medical reasons is not permitted. Record 3 OR Tktg First Tktg Last Text Table Number 996 Unavailable Data Tag Bytes 21-27 bytes 35-41 Bytes 90-97 Byte 98 24Jan 98 30Mar 98 Blank Blank The data in the first table indicates that the table contains text data only and is not applicable for autopricing. The data in the second table indicates that the earliest date ticketing is permitted is 24 Jan 98 and the latest date ticketing is permitted is 30Mar 98. Processing will not apply data in the first table and will read the second table. Conditions in the OR table must be satisfied in order to pass category validation.

Page E.03.15.095 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 6 (Value Y in IF Condition) Record 3 Category 15 THEN Tktg First Tktg Last Text Table Number 996 Unavailable Data Tag Bytes 21-27 bytes 35-41 Bytes 90-97 Byte 98 24Jan 98 30Mar 98 Blank Blank Record 3 Category 3 IF Bytes 44-51 Byte 52 Text Table No. 996 Unavailable Data Tag 123 Y Table Number 123 = Seasonal restrictions apply. Record 3 Category 15 ELSE Tktg First Tktg Last Text Table Number 996 Unavailable Data Tag Bytes 21-27 bytes 35-41 Bytes 90-97 Byte 98 01Apr 98 Blank Blank Blank The IF table contains text data only and is not applicable for autopricing; therefore, the data in the THEN table is also not applicable for autopricing. The data in the ELSE table indicates that the earliest date ticketing is permitted is 01Apr 98. Processing will apply data in the ELSE table, and conditions in this table must be satisfied in order to pass the category validation. NOTE: This example is considered invalid coding. ATPCO coding convention holds that unavailable data tag Y (free form text only) should not be present in an IF condition.

Page E.03.15.096 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 7 (Value Y in THEN Condition of THEN/IF Set) Record 3 THEN Tktg First Tktg Last Text Table Number 996 Unavailable Data Tag Bytes 21-27 bytes 35-41 Bytes 90-97 Byte 98 Blank Blank 123 Y Table Number 123 = Extension of ticket validity for medical reasons is not permitted. Record 3 Category 3 IF Byte 14 Bytes 15-20 Bytes 21-26 Byte 27 Seasonal Tag Start Stop Assumption Override Tag X 991202 991215 BLANK Record 3 Category 15 ELSE Tktg First Tktg Last Text Table Number 996 Unavailable Data Tag Bytes 21-27 bytes 35-41 Bytes 90-97 Byte 98 01Apr 99 Blank Blank Blank The data indicates that when the first flight from the origin of the pricing unit is 01Dec 99 through 15Dec 99, then the data in the THEN table applies. The THEN table contains text data only and is not applicable for autopricing; therefore, when conditions in the IF table are met, processing will not apply the data in the THEN table, and the system assumption will apply. When conditions of the IF table are not met, processing will apply the data in the ELSE table.

4.1.17 Segments, bytes 99-101

Indicates the number of occurrences of the Locale Fields (bytes 102-117). There may be up to 15 occurrences with 2 locales in each occurrence. Further explanation of the application of data in the recurring segments can be found in sections 4.1.22 and 4.1.23 of this document.

Page E.03.15.097 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

4.1.18 Locale ‘Appl’, byte 102

This field indicates whether the data coded in bytes 103-117 has a positive or negative application.

Public Tariffs When the value in this field is “Y” then the information found in bytes 103-117 represents who is permitted to sell the fare. When the value in this field is “N”, then the information found in bytes 103-117 represents who is not permitted to sell the fare.

For public tariffs, when only a negative value is found in byte 102 in the data table, anyone other than the negative data is permitted to sell the fare.

Private Tariffs When the value in this field is “Y” then the information found in bytes 103-117 represents who is permitted to sell and display the fare. When the value in this field is “N”, then the information found in bytes 103-117 represents who is not permitted to sell and display the fare.

For private tariffs, processing must find at least one positive value “Y” in the table in order to sell and display the fare. If a “Y” is not found, then the fare will fail processing.

Example 1 (Public Tariff) Record 3 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale N N US BLANK Note: No other recurring data exist in this table.

The data represents that sales are permitted anywhere except the US.

Example 2 (Private Tariff)

Page E.03.15.098 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Record 3 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale N N US BLANK Note: No other recurring data exist in this table.

The data represents that sales and display are not permitted in the US. There are no other recurring segments for bytes 102-115; therefore, the fare will fail processing as there is no positive data indicating who may sell the fare.

Example 3 (Private Tariff) Record 3 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale N N US BLANK Y A 01 02 Y A 03 BLANK Note: No other recurring data exist in this table.

The data represents that sales and display are permitted anywhere except the US.

Further explanation and examples of the application of positive and negative data in bytes 102-117 can be found in section 4.1.20 of this document.

Page E.03.15.099 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

4.1.19 Locale ‘Type’, byte 103 Values of ‘A’, ‘Z’, ‘N’, ‘S’, ‘C’, ‘P’, ‘T’, ‘I’, ‘H’, ‘U’, ‘X’, ‘V’

For public tariffs, these fields can be used to further define who can sell the fare. For private tariffs, these fields can be used to further define who can sell and display the fare. The definition of the values that may be used in these fields is as follows:

Byte 103 Definition Associated Bytes 104-117 Value A Area 1 digit IATA numeric area designator, left justified. Z Zone Numeric value assigned to a non-standard geographic description of cities, states, countries, subcontinents and/or traffic conferences, left justified. N Country Standard 2 letter IATA country code, left justified. S State Standard postal state code preceded by a country code, left justified. C City Standard industry 3 letter city code, left justified P Airport Standard industry 3 letter airport code, left justified. T Travel Agency Travel agency code. Up to 5 alpha-numeric characters left justified. I IATA Travel Agency Number 7 digit IATA assigned travel agency code right justified. H Home IATA Agency Number Up to 7 numerics right justified with leading zeroes. (similar to value ‘I’ except for home agency) U Home Travel agency Code Up to 5 alpha-numerics left justified with leading zeroes. (similar to value ‘T’ except for home agency) X Department/Identifier Up to 7 numerics right justified with leading zeroes. V CRS/CXR Department Code Up to 5 alpha-numerics left justified with leading zeroes. (Dept of the entry in bytes 44-47).

Page E.03.15.100 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Public Tariff Each airline or CRS may specify the “authorized locations” regarding who may sell a fare. If a carrier or CRS entry is designated in bytes 44-47, this, in conjunction with bytes 103-117 (Locales), further restricts the sale of the fare, allowing only the addressee in bytes 103-117 to sell and only via the CRS/Carrier defined in bytes 45-47 or the publishing/owning carrier, as described above. The relationship between bytes 44-47 and bytes 103-117 is AND.

Values T, U, I, H define travel agencies or IATA travel agencies that may sell the fare and whether or not those agencies may redistribute the fare for sales. Values T (Travel Agency Code) and I (IATA Travel Agency Number) define specific agents that may sell the fare. Values U (Home Travel Agency Code) and H (Home IATA Agency Number) define specific agents that may sell or redistribute the fare. A Home agency is permitted to redistribute the fares. When values T(Travel Agency Code) and U (Home Travel Agency Code) are used, edits require that a valid GDS that is able to process the field is provided in the Other Carrier/GDS (bytes 45- 47). The relationship between the GDS and the Agency(s) is AND.

Private Tariff Each airline or CRS may specify the “authorized locations” regarding who may sell and display a fare. If a carrier or CRS entry is designated in bytes 44-47, this, in conjunction with bytes 103-117 (Locales), further restricts the sale and display of the fare, allowing only the addressee in bytes 103-117 to sell and display and only via the CRS/Carrier defined in bytes 45-47 or the publishing/owning carrier, as described above. The relationship between bytes 44-47 and bytes 103-117 is AND.

Values T, U, I, H define travel agencies or IATA travel agencies that may sell and display the fare and whether or not those agencies may redistribute the fare for sales and display. Values T (Travel Agency Code) and I (IATA Travel Agency Number) define specific agents that may sell and display the fare. Values U (Home Travel Agency Code) and H (Home IATA Agency Number) define specific agents that may sell, display, or redistribute the fare. A Home agency is permitted to redistribute the fares. When values T(Travel Agency Code) and U (Home Travel Agency Code) are used, edits require that a valid GDS that is able to process the field is provided in the Other Carrier/GDS (bytes 45-47). The relationship between the GDS and the Agency(s) is AND.

Example 1 (Value T) – Private Tariff Record 3 Byte 102 Byte 103 Bytes 104-117

Page E.03.15.101 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Appl Type Locale Y T AM100 NOTE: No other recurring data exist in this table.

The data represents that only travel agency AM100 may sell and display the fares associated to the above Record 3.

Example 2 (Value U) – Private Tariff Record 3 Byte 102 Byte 103 Bytes 104-117 Appl Type Locale Y U AM100 NOTE: No other recurring data exist in this table.

The data represents that only travel agency AM100 and all subsidiaries of AM100 may sell and display the fares associated to the above Record 3. (AM100 may sell, display, and redistribute the fares).

Example 3 (Value I) – Private Tariff Record 3 Byte 102 Byte 103 Bytes 104-117 Appl Type Locale Y I 1234567 NOTE: No other recurring data exist in this table.

The data represents that only IATA travel agency number 1234567 may sell and display the fares associated to the above Record 3.

Example 4 (Value H) – Private Tariff Record 3 Byte 102 Byte 103 Bytes 104-117 Appl Type Locale Y H 3333333

Page E.03.15.102 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

NOTE: No other recurring data exist in this table.

The data represents that only Home IATA agency number 3333333 and all subsidiaries of 3333333 may sell and display the fares associated to the above Record 3. (3333333 may sell, display, and redistribute the fares).

Byte 103 Public Tariff Examples a) Byte 103 used with an Agency Number Byte 103 = H Bytes 104-117 = 1234567 Agency Number 123456 = Travel One

Indicates the fare may only be sold or redistributed by Travel One. b) Byte 103 used with a Agency Code Byte 103 = U Bytes 104-117 = Q2B Bytes 44-47 = 1X Agency Q2B = Travel One

Indicates the fare may only be sold or redistributed by Travel One using GDS 1X

Note: Both examples a and b create the same result but illustrate the different methods of expressing Travel Agency locations. c) Byte 103 used with a Department Number Byte 103 = X Bytes 104-117 = 1230001 Dept Number 1230001 Indicates the fare may only be sold via department/identifier 1230001. d) Byte 103 used with a CRS/Carrier Department Code Byte 44 = C Bytes 45-47 = PP Byte 103 = V Bytes 104-117 = ZZ123 PP = CRS One ZZ123=Department ZZ123

Page E.03.15.103 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Indicates the fare may only be sold by CRS One via department code ZZ123.

Byte 103 Private Tariff Examples a) Byte 103 used with an Agency Number Byte 103 = H Bytes 104-117 = 1234567 Agency Number 123456 = Travel One

Indicates the fare may only be sold, displayed, or redistributed by Travel One. b) Byte 103 used with a Agency Code Byte 103 = U Bytes 104-117 = Q2B Bytes 44-47 = 1X Agency Q2B = Travel One

Indicates the fare may only be sold, displayed, or redistributed by Travel One using GDS 1X

Indicates the fare may only be sold and displayed via department/identifier 1230001. d) Byte 103 used with a CRS/Carrier Department Code Byte 44 = C Bytes 45-47 = PP Byte 103 = V Bytes 104-117 = ZZ123 PP = CRS One ZZ123=Department ZZ123

Page E.03.15.104 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Indicates the fare may only be sold and displayed by CRS One via department code ZZ123.

By using the values in byte 103 and the values in bytes 44-47, the user can be further selective in identifying who may sell the fare (public tariffs) or who may sell and display the fare (private tariffs). As each CRS/Carrier can assign their own “Agency Number/Agency Code/CRS Dept/CXR Dept” as identification criteria within their system, it is possible that the same number or code can identify different departments or agencies than intended in other systems.

Example (Private Tariff): Byte 44 Bytes 45-47 Byte 103 Byte 104-117 C 1X U Q2B = Travel One Agency C 2X U Q2B = Travel Two Agency

The use of Bytes 44-47 in conjunction with 103-115 will indicate who can actually sell and display the fare. For CRS 1X the fare must be sold, displayed, or redistributed by Travel One Agency, whereas for CRS 2X the fare must be sold, displayed, or redistributed by Travel Two Agency. This example illustrates that the same data in bytes 103-117 can identify different selling or authorized locations and that the data in these fields needs to be applied in conjunction with the data in bytes 44-47 when present.

In the case of values ‘H’, ‘U’ and ‘X’ the presence of data in bytes 44-47 is optional however, in the case of value ‘V’ ‘T’ and ‘U’ data must be present in bytes 44-47 to fully provide the information regarding who may sell the fare and for values ‘T’ and ‘U’ bytes 44-47 must indicate a GDS.

Following are further Public Tariff examples using both bytes 44-47 and 103-117:

a) Byte 44 Bytes 45-47 Byte 103 Byte 104-117 X ZZ I 0001234 Indicates that fares may be sold by the publishing/owning carrier or carrier ZZ and only by IATA Travel Agency Number 0001234. As both conditions may not be satisfied, the fare will fail processing.

Page E.03.15.105 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

b) Byte 44 Bytes 45-47 Byte 103 Byte 104-117 C 2X I 0001234 Indicates that fares may be sold by CRS 2X and only through IATA Travel Agencies numbered 0001234.

c) Byte 44 Bytes 45-47 Byte 103 Byte 104-117 C 1X H 0009876 Indicates that the fares may be sold or redistributed by CRS 1X and only through Home IATA Agencies numbered 0009876.

d) Byte 44 Bytes 45-47 Byte 103 Byte 104-117 C 2X U ABCDE Indicates that the fares may be sold or redistributed CRS 2X and only through Home Travel Agencies Code ABCDE applicable to 2X GDS. e) Byte 44 Bytes 45-47 Byte 103 Byte 104-117 C 1X V QQQQQ Indicates that the fares may be sold by CRS 1X and only through department QQQQQ. f) Byte 44 Bytes 45-47 Byte 103 Byte 104-117 Record 3 THEN X ZZ Record 3 OR X V 1234567 Indicates that the fares may be sold by the publishing/owning carrier or carrier ZZ OR via Carrier department 1234567. g) Byte 44 Bytes 45-47 Byte 103 Byte 104-117 Record 3 THEN X ZZ Record 3 AND C 1X V AAA12 Indicates that the fares may be sold by the publishing/owning carrier or carrier ZZ and must be via CRS 1X and department AAA12.

Page E.03.15.106 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

h) Byte 44 Bytes 45-47 Byte 103 Byte 104-117 C 1X T ABCDE Indicates that the fare may be sold by GDS 1X and only through Travel Agency Code ABCDE applicable to 1X GDS

Page E.03.15.107 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Following are further Private Tariff examples using both bytes 44-47 and 103-117: a) Byte 44 Bytes 45-47 Byte 103 Byte 104-117 X ZZ I 0001234 Indicates that fares may be sold and displayed by the publishing/owning carrier or carrier ZZ and only by IATA Travel Agency Number 0001234. As both conditions may not be satisfied, the fare will fail processing.

b) Byte 44 Bytes 45-47 Byte 103 Byte 104-117 C 2X I 0001234 Indicates that fares may be sold and displayed by CRS 2X and only through IATA Travel Agencies numbered 0001234. c) Byte 44 Bytes 45-47 Byte 103 Bytes 104-117 C 1X H 0009876 Indicates that the fares may be sold, displayed, or redistributed by CRS 1X and only through Home IATA Agencies numbered 0009876. d) Byte 44 Bytes 45-47 Byte 103 Bytes 104-117 C 2X U ABCDE Indicates that the fares may be sold, displayed, or redistributed CRS 2X and only through Home Travel Agencies Code ABCDE applicable to GDS 2X. e) Byte 44 Bytes 45-47 Byte 103 Bytes 104-117 C 1X V QQQQQ Indicates that the fares may be sold and displayed by CRS 1X and only through department QQQQQ.

Page E.03.15.108 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

f) Byte 44 Bytes 45-47 Byte 103 Bytes 104-117 Record 3 THEN X ZZ Record 3 OR X V 1234567 Indicates that the fares may be sold and displayed by the publishing/owning carrier or carrier ZZ OR via Carrier department 1234567. g) Byte 44 Bytes 45-47 Byte 103 Bytes 104-117 Record 3 THEN X ZZ Record 3 AND C 1X V AAA12 Indicates that the fares may be sold and displayed by the publishing/owning carrier or carrier ZZ and must be via CRS 1X and department AAA12.

Page E.03.15.109 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

4.1.20 Bytes 103-117 Positive / Negative Applications for Locale Restrictions: Multiple entries may be coded in the locale field of Category 15. There are two locale entries per field, and as this field occurs from 0 to 15 times, up to 30 entries of a like appl/type/locale can exist in a single Record 3 table.

Private Tariffs

When processing these fields the process is to compare the location of display and ticket sale to the location field (bytes 103-117). If the data equals the sales and display location, interrogate the application field to see if sale and display is allowed or not allowed. Locale entries can have either positive (Y) or negative (N) applications per the value set in byte 102 APPL field. In the event negative and positive applications are present in the locale field(s) within the same Record 3 table, the more restrictive condition will precede the less restrictive. For example, ‘Y’ NYC will precede ‘N’ Area 1. Once a recurring segment is matched, processing should not read any further in that table but may read on to the next subset.

When multiple entries are coded, processing must pass one of the entries. If multiple conditions must be met (i.e. Sales and display are restricted to Agency 1234 in France), then this data must be coded in separate tables having an “AND” relationship. These rules apply to Category 15 tables when used in “IF” conditions as well (i.e. THEN CAT 5 /IF CAT 15 AND CAT 15/ ELSE CAT 5).

When processing these fields, the following rules are to be applied:

1) Stringing laws as described in Record 2 Data Application will apply.

2) Interrogate all values for byte 102 (Appl) within a table to determine if the values are all “Y” or “N” or a mixture of “Y” and “N”.

3) If all values for byte 102 within a table are “Y”, processing must pass one “Y” entry to pass the table. If one “Y” entry is not passed, then read on to the next subset.

4) If all values for byte 102 within a table are “N”, the fare is not permitted to be sold and displayed anywhere and will result in failing the table. Processing must find at least one positive value to match in order to pass the table. Processing would read on to other subsets; if no other subsets then fail the fare. (Note: ATPCO coding convention is to enter at least one positive statement in a table that contains negative statements).

Page E.03.15.110 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

5) If values for byte 102 within a table are a mixture of “Y” and “N”, first match the selling and display location to the data in bytes 103-117, then apply the Appl tag in byte 102. If byte 102 is "N", then that sale and display is not permitted and continue reading to the next subset. Processing must pass one "Y" entry to pass the table. If one "Y" entry is not passed, then read on to the next subset.

6) If all values for byte 102 within a string are "Y", apply rule number 3 above. When tables are connected by AND, processing must satisfy one "Y" entry in each table.

7) If all values for byte 102 within a string are "N", apply rule number 4 above. (Note: ATPCO coding convention is that negative data restricts the string to containing only one table).

8) If values for byte 102 within a string are a mixture of "Y" and "N", apply rule number 5 above. Apply table logic from rules 1, 2, 3 for each table. (Note: ATPCO coding convention is that negative data restricts the string to containing only one table).

Private Tariff Examples

Example 1 (all values within the table are "Y")

Record 3 Bytes 44-47 Bytes 99-101 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS # segs Appl Type Locale Locale 1X 2 Y T 123 456 Y T 789 BLANK Note: No other recurring data exist in this table.

The data represents that sales and display are only permitted by travel agency 123, 456 or 789 using GDX 1X. If sold or displayed in any other location, processing will fail the table and read on to the next subset.

Example 2 (all values within the table are "N")

Page E.03.15.111 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Record 3 Bytes 44-47 Bytes 99-101 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS # segs Appl Type Locale Locale 1X 2 N T 123 456 N T 789 BLANK NOTE: No other recurring data exist in this table.

The data represents that sales and display are not permitted by travel agency 123, 456 and 789 using GDS 1X. As there is no positive statement regarding who is permitted to sell and display the fare, processing will fail the table and read on to the next subset.

Note: ATPCO coding convention for Private Tariffs is to always follow negative recurring segments with a positive recurring segment. Additionally, when negative recurring segments are coded, the string is limited to only one Category 15 data table.

Example 3 (values within the table are a mixture of "Y" and "N")

Record 3 Bytes 44-47 Bytes 99-101 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS # segs Appl Type Locale Locale 1X 4 N T 123 456 N T 789 BLANK Y A 01 02 Y A 03 NOTE: No other recurring data exist in this table.

The data represents that sales and display are permitted anywhere in Areas 1, 2, or 3 except by travel agents 123, 456 and 789 using GDS 1X.

Example 4 (all values within the string are "Y")

Page E.03.15.112 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

THEN Record 3 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale Y H 1234567 2222222 NOTE: No other recurring data exist in this table. OR Record 3 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale Y N GB BLANK NOTE: No other recurring data exist in this table.

Then data in the first table indicates that the fare can be sold, displayed, or redistributed home IATA agencies 1234567 or 2222222. The data in the second table indicates that the fare can be sold and display by anyone, but only in the United Kingdom. (If conditions of both tables are to be validated , then relational indicator AND should be used).

. If home IATA agent 33333333 in GB: processing will fail the first table and read the second table. Processing will pass the second table. . If home IATA agent 1234567 in Canada: processing will pass the first table (processing will not read the second table). . If home IATA agent 3333333 in Canada: processing will fail the first table and read the second table. Processing will fail the second table.

Example 5 (all values within the string are "N")

THEN Record 3 Bytes 44-47 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS Appl Type Locale Locale 1X N T 123 456 NOTE: No other recurring data exist in this table.

Page E.03.15.113 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

AND Record 3 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale Y N US BLANK NOTE: No other recurring data exist in this table.

The data in the first table indicates that sales and display are not permitted by travel agents 123 and 456 using GDS 1X. The data in the second table indicates that sales and display are not permitted in the U.S. As there is no positive data present in the first table, processing will fail the set.

Example 6 (values within the string are a mixture of "Y and "N")

THEN Record 3 Bytes 44-47 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS Appl Type Locale Locale 1X N T 123 456 NOTE: No other recurring data exist in this table. AND Record 3 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale Y N US BLANK NOTE: No other recurring data exist in this table.

The data in the first table indicates that sales and display are not permitted by travel agents 123 and 456 using GDX 1X. The data in the second table indicates that sales and display are only permitted in the U.S. As there is no positive data present in the first table, processing will fail the set.

Page E.03.15.114 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Note: If the relational indicator were OR: processing would fail the first table as there is no positive statement and read the second table. Processing would pass the second table provided sales were in the U.S.

ATPCO coding convention for Private Tariffs is to always follow negative recurring segments with a positive recurring segment. Additionally, when negative recurring segments are coded, the string is limited to only one Category 15 data table.

Example 7 (values within the string are a mixture of "Y and "N")

THEN Record 3 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale N N US BLANK Y A 01 02 Y A 03 BLANK NOTE: No other recurring data exist in this table. AND Record 3 Bytes 44-47 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS Appl Type Locale Locale 1X Y T 123 BLANK NOTE: No other recurring data exist in this table.

The data in the first table indicates that sales and display are permitted anywhere except the U.S. The data in the second table indicates that sales and display are only permitted by travel agent 123 using GDS 1X. As the relational indicator is AND, sales and display are permitted anywhere by travel agent 123 using GDS 1X, except in the U.S. . If agent 123 in France, processing will pass the first table and read the second table. Processing will pass the second table. . If agent 123 in the U.S., processing will fail the first table (processing will not read the second table). . If agent 456 in France, processing will pass the first table and read the second table. Processing will fail the second table.

Page E.03.15.115 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Note: ATPCO coding convention for Private Tariffs holds that when negative recurring segments are coded, the string is limited to only one Category 15 data table.

Example 8 (values within the string are a mixture of "Y and "N")

THEN Record 3 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale N N US BLANK Y A 01 02 Y A 03 BLANK NOTE: No other recurring data exist in this table. OR Record 3 Bytes 44-47 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS Appl Type Locale Locale 1X Y T 123 BLANK NOTE: No other recurring data exist in this table.

The data in the first table indicates that sales and display are permitted anywhere except the U.S. The data in the second table indicates that sales and display are only permitted by travel agent 123 using GDX 1X. As the relational indicator is OR, the data represents that if sales and display are in the U.S., they are only permitted by travel agent 123. . If agent 123 in U.S., processing will fail the first table and read the second table. Processing will pass the second table. . If agent 456 in the U.S., processing will fail the first table and read the second table. Processing will fail the second table. . If agent 456 in France, processing will pass the first table (processing will not read the second table).

Note: ATPCO coding convention for Private Tariffs holds that when negative recurring segments are coded, the string is limited to only one Category 15 data table.

Page E.03.15.116 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 9 (values within the string are a mixture of "Y and "N")

THEN Record 3 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale Y S FL US BLANK N N US BLANK Y A 01 BLANK NOTE: No other recurring data exist in this table. AND Record 3 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale Y I 1234567 BLANK NOTE: No other recurring data exist in this table.

The data in the first table indicates that sales and display are permitted anywhere in Area 1, excluding the U.S; however, sales and display are permitted in Florida. The data in the second table indicates that sales and display are only permitted by IATA Travel Agency 1234567. As the relational indicator is AND, sales and display are only permitted by IATA Travel Agency 1234567 anywhere in Area 1, excluding the U.S.; except sales and display are permitted by IATA Travel Agency 1234567 in Florida. . If agent 1234567 in France, processing will fail the first table (processing will not read the second table). . If agent 1234567 in the U.S., processing will fail the first table (processing will not read the second table). . If agent 3456789 in Canada, processing will pass the first table and read the second table. Processing will fail the second table. . If agent 1234567 in Florida, processing will pass the first table and read the second table. Processing will pass the second table.

Note: ATPCO coding convention for Private Tariffs holds that when negative recurring segments are coded, the string is limited to only one Category 15 data table.

Page E.03.15.117 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Public Tariffs

When processing these fields the process is to compare the location of ticket sale to the location field (bytes 103-117). If the data equals the sales location, interrogate the application field to see if sale is allowed or not allowed. Locale entries can have either positive (Y) or negative (N) applications per the value set in byte 102 APPL field. In the event negative and positive applications are present in the locale field(s) within the same Record 3 table, the more restrictive condition will precede the less restrictive. For example, ‘Y’ NYC will precede ‘N’ Area 1. Once a recurring segment is matched, processing should not read any further in that table but may read on to the next subset.

When multiple entries are coded, processing must pass one of the entries. If multiple conditions must be met (i.e. Sales are restricted to Agency 1234 in France), then this data must be coded in separate tables having an “AND” relationship. These rules apply to Category 15 tables when used in “IF” conditions as well (i.e. THEN CAT 5 /IF CAT 15 AND CAT 15/ ELSE CAT 5).

When processing these fields, the following rules are to be applied:

1) Stringing laws as described in Record 2 Data Application will apply.

2) Interrogate all values for byte 102 (Appl) within a table to determine if the values are all “Y” or “N” or a mixture of “Y” and “N”.

3) If all values for byte 102 within a table are “Y”, processing must pass one “Y” entry to pass the table. If one “Y” entry is not passed, then read on to the next subset. If no further subsets, then the fare will fail processing.

4) If all values for byte 102 within a table are “N”, the fare is permitted to be sold in any location except the negative.

5) If values for byte 102 within a table are a mixture of “Y” and “N”, first match the selling location to the data in bytes 103- 115, the apply the Appl tag in byte 102. If byte 102 is "N", then that sale is not permitted and processing will read on to the next subset. If no further subsets, then the fare will fail processing. Processing must pass one "Y" entry to pass the table. If one "Y" entry is not passed, then read on to the next subset. If no further subsets, then the fare will fail processing.

Page E.03.15.118 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

6) If all values for byte 102 within a string are "Y", apply rule number 3 above. When tables are connected by AND, processing must satisfy one "Y" entry in each table.

7) If all values for byte 102 within a string are "N", apply rule number 4 above.

8) If values for byte 102 within a string are a mixture of "Y" and "N", apply rule number 5 above. Apply the table logic from rules 1, 2, 3 for each table.

Page E.03.15.119 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Public Tariff Examples

Example 1 (all values within the table are "Y")

The data represents that sales are only permitted travel agency 123, 456 or 789 using GDS 1X. If sold in any other location, processing will fail the table and read on to the next subset.

Example 2 (all values within the table are "N")

Record 3 Bytes 44-47 Bytes 99-101 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS # segs Appl Type Locale Locale 1X 2 N T 123 456 N T 789 BLANK Note: No other recurring data exist in this table.

The data represents that sales are permitted anywhere, except by travel agencies 123, 456 and 789 using GDS 1X.

Page E.03.15.120 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 3 (values within the table are a mixture of "Y" and "N")

Record 3 Bytes 44-47 Bytes 99-101 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS # segs Appl Type Locale Locale 1Z 3 N T 123 456 N T 789 BLANK Y N US CA Note: No other recurring data exist in this table.

The data represents that sales are permitted anywhere in the U.S. or Canada except by travel agencies 123, 456 and 789 using GDS 1Z.

Example 4 (all values within the string are "Y")

THEN Record 3 Bytes 44-47 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS Appl Type Locale Locale 1X Y T 123 456 Note: No other recurring data exist in this table. AND Record 3 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale Y N US BLANK Note: No other recurring data exist in this table.

As the relational indicator is AND, the set indicates that the fare can only be sold by travel agents 123 or 456 using GDS 1X in the U.S. . If agent 789 in the US: processing will fail the first table. Processing will not read the second table.

Page E.03.15.121 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

. If agent 123 in Canada: processing will pass the first table, and read the second table. Processing will fail the second table. . If agent 456 in the U.S.: processing will pass the first table and read the second table. Processing will pass the second table.

Example 5 (all values within the string are "N")

THEN Record 3 Bytes 44-47 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS Appl Type Locale Locale 1Z N T 123 456 Note: No other recurring data exist in this table. AND Record 3 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale N N US BLANK Note: No other recurring data exist in this table.

As the relational indicator is AND, the set indicates that sales are permitted by anyone, except travel agents 123 and 456 using GDS 1Z and in any location, except the U.S. . If agent 123 in Canada: processing will fail the first table. Processing will not read the second table. . If agent 789 in Canada.: processing will pass the first table and read the second table. Processing will pass the second table. . If agent 456 in the U.S.: processing will fail the first table. Processing will not read the second table. . If agent 789 in the U.S.: processing will pass the first table and read the second table. Processing will fail the second table.

Page E.03.15.122 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 6 (values within the string are a mixture of "Y and "N")

THEN Record 3 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale N N US CA Note: No other recurring data exist in this table.

OR Record 3 Bytes 44-47 Bytes 99-101 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS # segs Appl Type Locale Locale 1Z 2 Y T 123 456 Y T 789 BLANK Note: No other recurring data exist in this table.

The data in the first table indicates that sales are permitted anywhere, except the U.S. and Canada. The data in the second table indicates that sales are permitted in any location by travel agents 123, 456, 789 using GDS 1Z. As the relational indicator is OR, the set indicates that if sales are in the U.S./Canada, they are only permitted by travel agents 123, 456, or 789. Anyone in any other location is permitted to sell the fare.

. If agent 222 in Canada, processing will fail the first table and read the second table. Processing will fail the second table. . If agent 789 in Canada, processing will fail the first table and read the second table. Processing will pass the second table. . If agent 222 in France, processing will pass the first table. Processing will not read the second table.

Page E.03.15.123 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 7 (values within the string are a mixture of "Y and "N")

THEN Record 3 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale N N US CA Note: No other recurring data exist in this table.

AND Record 3 Bytes 44-47 Bytes 99-101 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS # segs Appl Type Locale Locale 1X 2 Y T 123 456 Y T 789 BLANK Note: No other recurring data exist in this table.

The data in the first table indicates that sales are permitted anywhere, except the U.S. and Canada. The data in the second table indicates that sales are permitted in any location by travel agents 123, 456, 789 using GDS 1X. As the relational indicator is AND, the set indicates that fares must be sold by travel agents 123, 456 or 789 using GDS 1X in any location, except the U.S. and Canada.

. If agent 222 in Canada, processing will fail the first table. Processing will not read the second table. . If agent 222 in France, processing will pass the first table and read the second table. Processing will fail the second table. . If agent 123 in Germany, processing will pass the first table and read the second table. Processing will pass the second table.

Page E.03.15.124 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

4.2 Reconciliation between Footnote and Rule Levels When Category 15 data is present in a fare rule and general rule, the data from both the fare rule and general rule will apply (unless byte 102 General Rule Application is coded ‘X’). When a footnote is also present, the data from the combined fare rule information will apply in addition to the footnote data. Processing must validate and pass each level as there is an AND relationship among the footnote, fare rule and general rule levels.

Example 1 (Public Tariff)

FOOTNOTE - Record 3 Bytes 21-27 Bytes 35-41 First Tkt Last Tkt 01Jan 99 01Feb 99 The data indicates that the earliest sale date is 01Jan 99 and the latest sale date is 01Feb 99.

FARE RULE – Record 2: Byte 102 Blank FARE RULE - Record 3 Byte 61 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 PTA Appl Type Locale Locale Y Y N US CA The data indicates that PTAs are permitted; sales are only permitted in the U.S. or Canada.

GENERAL RULE - Record 3 Byte 81 Ext Tkt Validity N The data indicates that extension of ticket validity is not permitted.

Page E.03.15.125 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

COMBINED RULE – data from all 3 levels must be satisfied The combined rule data indicates that the earliest sale date is 01Jan 99 and the latest sale date is 01Feb 99, PTAs are permitted, extension of ticket validity is not permitted, and sales are only permitted in the U.S. or Canada.

In order for the fare to pass processing, all three levels must be passed.

Example 2 (Public Tariff)

FOOTNOTE - Record 3 Bytes 21-27 Bytes 35-41 First Tkt Last Tkt 01Jan 99 01Feb 99 The data indicates that the earliest sale date is 01Jan 99 and the latest sale date is 01Feb 99.

FARE RULE – Record 2: Byte 102 Blank FARE RULE - Record 3 Bytes 21-27 Bytes 35-41 Byte 61 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 First Tkt Last Tkt PTA Appl Type Locale Locale 15Jan 99 31Mar 99 Y Y N US CA The data indicates that the earliest sale date is 15Jan 99, the latest sale date is 31Mar 99, that PTAs are permitted, and that sales are only permitted in the U.S. or Canada.

GENERAL RULE - Record 3 Byte 81 Ext Tkt Validity N The data indicates that extension of ticket validity is not permitted.

Page E.03.15.126 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

COMBINED RULE – data from all 3 levels must be satisfied The combined rule data indicates that the earliest sale date is 15Jan 99 and the latest sale date is 01Feb 99 (sale dates from both the footnote and fare rule levels must be satisfied), PTAs are permitted, extension of ticket validity is not permitted, and sales are only permitted in the U.S. or Canada.

In order for the fare to pass processing, all three levels must be passed.

Example 3 (Public Tariff)

FOOTNOTE - Record 3 Bytes 21-27 Bytes 35-41 First Tkt Last Tkt 01Jan 99 01Feb 99

The data indicates that the earliest sale date is 01Jan 99 and the latest sale date is 01Feb 99.

FARE RULE – Record 2: Byte 102“X” FARE RULE – Record 3 “THEN” Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale N N US BLANK “AND” Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale N N CA BLANK The data indicates that sales are permitted anywhere except the U.S. and CA.

GENERAL RULE - Record 3 Byte 81

Page E.03.15.127 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Ext Tkt Validity N The data indicates that extension of ticket validity is not permitted.

COMBINED RULE – data from all 3 levels must be satisfied The combined rule data indicates that the earliest sale date is 01Jan 99, the latest sale date is 01Feb 99, and sales are permitted anywhere except the U.S. and CA.

In order for the fare to pass processing, both footnote and fare rule levels must be passed (General Rules is not applicable according to byte 102 in the Fare Rule).

NOTE: In order to ensure accurate processing, ATPCO recommends that carriers instruct all recurring segment location data in only one level.

Example 4 (Private Tariff)

FOOTNOTE - Record 3 Bytes 21-27 Bytes 35-41 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 First Tkt Last Tkt Appl Type Locale Locale 01Jan 99 01Feb 99 N N US BLANK Y A 01 02 Y A 03 BLANK The data indicates that the earliest sale date is 01Jan 99 and the latest sale date is 01Feb 99. Fares may be sold and displayed anywhere, except in the U.S.

Page E.03.15.128 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

FARE RULE – Record 2: Byte 102 blank FARE RULE – Record 3 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale Y N US BLANK The data indicates that sales and display are only permitted in the U.S.

GENERAL RULE - Record 3 Bytes 44-47 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS Appl Type Locale Locale 1Z Y T 123 BLANK The data indicates that sales and display are only permitted by travel agent 123 with GDS 1Z

COMBINED RULE – data from all 3 levels must be satisfied The combined rule data indicates that the earliest sale date is 01Jan 99 and the latest sale date is 01Feb 99. Sales and display are only permitted by travel agent 123 using GDS 1Z, and the location information in the footnote (not permitted in the U.S.) and the fare rule (only permitted in the U.S.) are in conflict.

In order for the fare to pass processing, all three levels must be passed. As the data in the fare rule and footnote are in conflict, the fare will fail processing.

NOTE: In order to ensure accurate processing, ATPCO recommends that carriers instruct all recurring segment location data in only one level.

Page E.03.15.129 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

5.0 TRAVEL SEGMENT INDICATOR (TSI)

Travel segment indicators are not applicable in Category 15.

6.0 CODING CONVENTIONS

6.1 Recurring Segment ‘Locales’ (bytes 102 – 117) for Private Tariffs A no match to a Record 2, Category 15 for Private Tariffs would result in ‘Sales and Display Not Permitted’ assumption. If a match is made to a Record 2 for Category 15 Private Tariffs and there is negative recurring segment data with no positive data coded, then the subscriber that receives the data may not know who is valid to sell and display the fare, and any private tariff fares received by a subscriber without an associated Category 15 provision may fail processing. Therefore, for private tariffs a negative application in the recurring segments will always be followed by a positive application. ATPCO will always code a positive condition for Locales in private tariffs. In other words, when a Locale is coded as Negative, ATPCO will always follow with Positive application of Locales.

Example

Private tariff instruction states: Sales and display not permitted in US / CA. ATPCO will code: THEN Record 3 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale N N US CA Y A 01 02 Y A 03 BLANK

If ATPCO did not enter a positive application (permitted in Area 1, 2, 3), then the fare may fail processing.

Page E.03.15.130 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

6.2 ‘Multiple Locales’ and ‘overflow conditions’ of Positive Application in the Recurring Segments Positive conditions that were not/cannot be coded on a single table must be connected with OR. For Category 15, the positive overflow conditions are coded with OR, as the relationship between multiple locales in a single table is OR.

Example of Multiple locales within one table (Public Tariff): Record 3 Locale APPL Type Locals Byte 102 Byte 103 Bytse 104-117 Y N FR Y N ES Y N PL Y N EI Y N IT Y N DE

The data represents that the ticket may be sold in the above-mentioned countries, the relationship between each country is OR.

6.3 ‘Multiple Locales’ and ‘overflow conditions’ of Negative Application in the Recurring Segments

Public Tariffs Negative conditions (or negative + positive conditions) in the recurring segments that were not/cannot be coded on a single table must be connected with AND. For Category 15, the negative (or negative + positive) overflow conditions are coded with AND as the relationship between multiple negative (or negative + positive) locales in a single table is AND.

Page E.03.15.131 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 1 (Public Tariffs)

THEN Record 3 Bytes 44-47 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS Appl Type Locale Locale 1X N T 123 456 AND Record 3 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale N N US BLANK

Negative conditions in 2 tables should be strung with relational indicator AND.

Example 2 (Public Tariffs)

A mixture of negative and positive conditions in 2 tables should be strung with relational indicator AND.

Page E.03.15.132 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Private Tariffs Negative conditions limit Category 15 to only 1 data table in the string. When all values in byte 102 (Appl) in the recurring segments are “N” or when the values in byte 102 are a mixture of “N” and “Y”, then ATPCO’s coding convention is to only enter a single data table in the string. This convention applies when Category 15 is used as a main category or as a qualifying category.

As there are 15 locale segments, with 2 entries per field, a total of 30 locale entries are permitted in a single data table. Negative locales are limited to only 26 entries in order to allow space to enter a positive coding reflecting permitted in Area 1, 2, or 3 (see section 6.1 of this document regarding negative statements followed by positive statements in Private Tariffs). If the carrier instructs negative conditions that cannot be coded in a single table, then ATPCO must code the positive conditions instead.

Example 1 (Private Tariff – Invalid Coding)

THEN Record 3 Bytes 44-47 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS Appl Type Locale Locale 1X N T 123 456 AND Record 3 Bytes 44-47 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS Appl Type Locale Locale 1X N T 789 BLANK

The above coding is not valid as negative conditions limit Category 15 to only 1 data table in the string for Private Tariffs. Additionally, in Private Tariffs, any negative data must be followed by a positive application (see section 6.1 of this document).

Page E.03.15.133 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 2 (Private Tariff – Invalid Coding)

THEN Record 3 Category 15 Bytes 44-47 Bytes 99-101 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS # segs Appl Type Locale Locale 1X 3 N T 123 456 N T 789 BLANK Y A 02 BLANK

IF Record 3 Category 1 Bytes 14-16 Bytes 18-19 Psgr Min Age SRC 65

ELSE Record 3 Category 15 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale Y A 02 BLANK

The above coding is not valid as negative conditions limit Category 15 to only 1 data table in the string for Private Tariffs.

Page E.03.15.134 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 3 (Private Tariff – Invalid Coding)

THEN Record 3 Category 2 Byte 22 Bytes 23-28 Time of Day (Appl) Day of Week D 1, 2

IF Record 3 Category 15 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale N N US BLANK AND Record 3 Category 15 Bytes 44-47 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS Appl Type Locale Locale 1Z Y T 123 BLANK

Example 4 (Private Tariff –Valid Coding) THEN Record 3 Bytes 44-47 Bytes 99-101 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS # segs Appl Type Locale Locale 1Z 4 N T 123 456 N T 789 BLANK Y A 01 02 Y A 03 BLANK

The above coding is valid provided this is the only Category 15 data table in the string.

Page E.03.15.135 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 5 (Private Tariff –Valid Coding)

THEN Record 3 Category 15 Bytes 44-47 Bytes 99-101 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 OAL/GDS # segs Appl Type Locale Locale 1Z 3 N T 123 456 N T 789 BLANK Y A 02 BLANK

IF Record 3 Category 1 Bytes 14-16 Bytes 18-19 Psgr Min Age SRC 65

The above coding is valid provided this is the only Category 15 data table in the string.

Example 6 (Private Tariff –Valid Coding)

THEN Record 3 Category 2 Byte 22 Bytes 23-28 Time of Day (Appl) Day of Week D 1, 2

IF Record 3 Category 15 Byte 102 Byte 103 Bytes 104-110 Bytes 111-117 Appl Type Locale Locale N N US BLANK

The above coding is valid provided this is the only Category 15 data table in the string.

Page E.03.15.136 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

6.4 Coding conventions for SITI/SITO/SOTI/SOTO

The SITI/SOTI/SITO/SOTO fields are to be considered a “set” or “group” of fields. When one or more of the fields in the set are tagged ’Y’ = Allowed, ‘N’ = Not permitted, ‘R’ = Required the Blank fields are to be considered “not permitted”. If all of the fields are received Blank then these fields will be considered “permitted”. As no text will be produced for blank values and no consolidation will occur between tables, the following coding conventions must be adhered to:

Example 1: Instruction states “SITI transactions are permitted”:

If a carrier instructs “permitted”, all fields not addressed should be tagged with an ‘N’.

Record 3 THEN SITI SOTO SITO SOTI Byte 71 Byte 72 Byte 73 Byte 74 Y N N N

The data represents that SITI transactions permitted, SOTI/SITO/SOTO transactions not permitted.

Example 2: Instruction states “SITI are not permitted”:

If a carrier instructs “not permitted”, all fields not addressed should be tagged with an ‘Y’

Record 3 THEN SITI SOTO SITO SOTI Byte 71 Byte 72 Byte 73 Byte 74 N Y Y Y

The data represents that SITI transactions are not permitted. SOTO/SITO/SOTI transactions are permitted.

Page E.03.15.137 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Example 3: Instruction states: “Within Europe, SITI transactions are permitted” “From Europe, SOTI/SOTO transactions are permitted”

(Multiple “permitted/not permitted” fields may be coded in multiple tables that differ by geography).

Record 3 THEN SITI SOTO SITO SOTI Byte 71 Byte 72 Byte 73 Byte 74 Y N N N

Record 3 OR SITI SOTO SITO SOTI Byte 71 Byte 72 Byte 73 Byte 74 N Y N Y

The data represents that Within Europe - SITI transactions are permitted. SOTI/SITO/SOTO transactions are not permitted. OR - From Europe - SOTI/SOTO transactions are permitted. SITI/SITO transactions are not permitted.

Example 4: Instruction states “SITI transactions are required” (If one field is addressed as “required”, all remaining fields not addressed will remain blank via a system edit).

Record 3 THEN SITI SOTO SITO SOTI Byte 71 Byte 72 Byte 73 Byte 74 R

Page E.03.15.138 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

The data represents that SITI transactions are required.

Example 5: Instruction states “SITI/SOTI transactions are required” (Multiple “required” fields must be coded in multiple tables).

Record 3 THEN SITI SOTO SITO SOTI Byte 71 Byte 72 Byte 73 Byte 74 R

Record 3 OR SITI SOTO SITO SOTI Byte 71 Byte 72 Byte 73 Byte 74 R

The data represents that SITI are transactions required, OR - SOTI transactions are required.

Example 6: Instruction states “SITI transactions are required, SOTI transactions are permitted”. (Multiple “required/permitted” fields should not be mixed across tables). These should both be treated as either ‘Required’ OR ‘Permitted’

Record 3 THEN SITI SOTO SITO SOTI Byte 71 Byte 72 Byte 73 Byte 74 R

Page E.03.15.139 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

Record 3 OR SITI SOTO SITO SOTI Byte 71 Byte 72 Byte 73 Byte 74 R

The data represents that SITI transactions are required, OR - SOTI transactions are required.

OR Permitted:

Record 3 THEN SITI SOTO SITO SOTI Byte 71 Byte 72 Byte 73 Byte 74 Y N N Y

The data represents that that SITI/SOTI transactions are permitted, and SITO/SOTO transactions are not permitted.

Page E.03.15.140 Revised January 2016 Effective 30 June 2016 DATA APPLICATION FOR CATEGORY 15 - SALES RESTRICTIONS

6.5 Category 15 as a Footnote Attachment (Fare Record level)

Industry Assumptions: All fares have dates governing the ticketing periods of that fare, in the absence of a carrier actually filing specific dates, the implication is that the fare is available for sale immediately. See Date Processing document for details.

6.6 Fare dates as they relate to ticketing footnotes/rules

Altering the Ticketing assumptions can be accomplished by either Footnote or Rule. The provision can modify the First or Last Ticketing Date by closing down the window of sale provided for by the ticketing assumptions. It is not possible to increase the sale window via footnote or rule provisions. Should a carrier have the need to expand the sale window provided for by the ticketing assumptions, the actual dates of the fare will have to be modified via ATPCO. See Date Processing document for details.

Page E.03.15.141 Revised January 2016 Effective 30 June 2016