YQYR RecS1 Dapp C

DATA APPLICATION
CARRIER-IMPOSED (YQ/YR) FEES RECORD S1
The information contained in this document is the property of ATPCO. No part of this document may be
reproduced, stored in a retrieval system, or transmitted in any form, or by any means; mechanical, photocopying,
recording, or otherwise, without the prior written permission of ATPCO. Under the law, copying includes
translating into another language or format. Legal action will be taken against any infringement
Copyright ©2005 by Airline Tariff Publishing Company

All rights reserved.
DATA APPLICATION – CARRIER-IMPOSED (YQ/YR) FEES RECORD S1
Contents
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 ......................................................................................................................................................................................................................... 6
3.0 DETAILED FIELD PROCESSING ........................................................................................................................................................................................ 7
4.0 PROCESSING......................................................................................................................................................................................................................... 11
4.1 APPLICATION OF DATA FOR RECORD S1 ............................................................................................................................................................................... 13
4.1.1 Carrier Code (bytes 3-5) .......................................................................................................................................................................................... 13
4.1.2 Service Type Code (bytes 6-10) ................................................................................................................................................................................ 14
4.1.3 MCN (bytes 21-29) ................................................................................................................................................................................................... 15
4.1.4 Sequence Number (bytes 29-35) ............................................................................................................................................................................... 16
4.1.5 Travel Dates – Effective/Discontinue (bytes 37-48) ................................................................................................................................................. 17
4.1.6 Ticket Dates (bytes 49-60) ........................................................................................................................................................................................ 18
4.1.7 Carrier Application Table No. 190 (bytes 61-68) .................................................................................................................................................... 19
4.1.8 Return to Origin (byte 69) ........................................................................................................................................................................................ 20
4.1.9 Passenger Type (bytes 70-72) .................................................................................................................................................................................. 21
4.1.10 Point of Sale (bytes 75-96) ....................................................................................................................................................................................... 22
4.1.10.1 Point of Sale – Geographic Specification (bytes 82-90) .............................................................................................................................................................. 22
4.1.10.2 Point of Sale – Code (bytes 91-99) .............................................................................................................................................................................................. 23
4.1.11 Point of Ticketing – Geographic Specification (bytes 100-108) ............................................................................................................................... 24
4.1.12 Journey Geographic Specification (bytes 109-145) ................................................................................................................................................. 25
4.1.12.1 Journey Geo Spec – Indicator (byte 109) ..................................................................................................................................................................................... 25
4.1.12.2 Journey Geo Spec – Loc 1 / Loc 2 (bytes 110-127) .................................................................................................................................................................... 28
4.1.12.3 Journey Geo Spec – Via Loc (bytes 128-136).............................................................................................................................................................................. 31
4.1.12.4 Journey Geo Spec – Travel Wholly Within (bytes 137-145) ....................................................................................................................................................... 32
4.1.13 Sector/Portion of Travel Geographic Specification (bytes 146-181) ....................................................................................................................... 33
4.1.13.1 Sector/Portion Geo Spec – Indicator (byte 146)........................................................................................................................................................................... 34
4.1.13.2 Sector/Portion Geo Spec – Loc 1/Loc 2 (bytes 148-156, 157-165).............................................................................................................................................. 38
4.1.13.3 Sector/Portion Geo Spec – Via Loc (bytes 166-174) ................................................................................................................................................................... 39
4.1.13.4 Sector/Portion Geo Spec – Stopover/Connection (byte 175) ....................................................................................................................................................... 40
4.1.13.5 Sector/Portion Geo Spec – Exception Stopover Time (bytes 176-179)........................................................................................................................................ 42
4.1.13.6 Sector/Portion Geo Spec – International/Domestic (byte 181) .................................................................................................................................................... 46
Revised April 2014

4.1.14 Carrier/Flight Application Table No. 186 (bytes 194-201) ...................................................................................................................................... 49

4.1.15 RBD (bytes 203-208) ................................................................................................................................................................................................ 52
4.1.16 Equipment (bytes 209-211)....................................................................................................................................................................................... 53
4.1.17 Fare Basis Code (bytes 212-226) ............................................................................................................................................................................. 54
4.1.18 Service Fee (bytes 258-277) ..................................................................................................................................................................................... 59
4.1.18.1 Specified Fee (bytes 258-268) ..................................................................................................................................................................................................... 59
4.1.18.2 Percent (bytes 269-275) ............................................................................................................................................................................................................... 60
4.1.18.3 Tax Included (byte 276) ............................................................................................................................................................................................................... 61
4.1.18.4 Fee Application (byte 277)........................................................................................................................................................................................................... 62
4.1.19 Text Table No. 196 (bytes 278-285) ......................................................................................................................................................................... 64
5.0 TRAVEL SEGMENT INDICATORS ................................................................................................................................................................................... 65
6.0 CODING CONVENTIONS.................................................................................................................................................................................................... 66
Revised April 2014

1.0 OVERVIEW
Record S1 provides applicable information for fuel and carrier-imposed fees that are controlled by the marketing carrier, regardless of
fare owner or validating carrier (e.g. YQ/YR fees). It is assumed that all validating carriers concur to their own Record S1 data, but
non-concur to other marketing carriers’ Record S1 data, unless an applicable entry is present in the Concurrence Record S2.
This document details the data application for Carrier-Imposed (YQ/YR) Fees Record S1 only. The 100 Series Tables used in this
record are Record 3s. The data application for these 100 Series Tables is the same as the data application for the corresponding
Automated Rules Record 3, 900 Series Tables (e.g. data application for Zone Table 178 is the same as data application for Zone Table
978). Subscribers should refer to the corresponding 900 Series Table data application documentation for further information.
1.1 Data Requirements

In order to validate Record S1, it is essential to know the following:
• Departure date from the origin of the journey

• Departure date for each sector of the journey
• Ticket issue date
• Validating carrier
• Point of sale
• Point of ticketing
• All ticketed points on the journey
• All stopovers and connection points on the journey
• Marketing carrier on each sector of the journey
• Operating carrier on each sector of the journey
• Marketing carrier’s flight number on each sector of the journey
• RBD and associated cabin for each sector of the journey
• Equipment code on each sector of the journey
• Fare Basis Code
• Passenger Type Code
Page E.03.S1.03 Revised April 2014

1.2 Basic Processing Overview

Validation of Record S1 takes place after pricing is complete.
Record S1 processing will start by determining the Validating Carrier
Process Record S2 (Services Concurrence Record)

for the validating carrier.
Did the S2 Process return any carriers (including

themselves) for whom the validating carrier will collect
Service Fees?
yes no
Process Record S1 (Services Record) for

every sector of the ticket, beginning with Do not process Record S1.
the first sector, provided the validating Do not collect any Service
carrier concurs to collecting fees for the Fees.
marketing carrier on the sector.
For each sector, attempt to match Record S1

(based on the match criteria) for a unique Tax
Code and Sub-Code combination.
Is there a match?
yes no
Apply the Service Fee. For the No Service Fee applies for the Tax
same sector, continue Code and Sub-Code combination. For
processing to another Record the same sector, continue processing
S1 with a different Tax Code to another Record S1 with a different
and/or Sub-Code Tax Code and/or Sub-Code

2.0 DEFINITIONS AND ASSUMPTIONS

2.1 Definitions
Term Definition
Base Fare The amount that appears in the “fare” portion of the Fare Box on the ticket. This amount excludes
amounts in any other boxes on the ticket.
Destination Ultimate stopping place of the journey as shown on the ticket
Fare Basis Code The code that appears in the Fare Basis Box on the ticket.
Journey Turnaround The furthest stopover or fare break point on the journey, measured from journey origin.
NOTE: Determination of whether a point is a stopover or fare break point is based on the designation in the fare
calculation.
Marketing Carrier The carrier code that will appear on the flight coupon of the ticket (different from operating carrier for
code share). The Marketing Carrier may be a primary and/or secondary carrier.
One Way Journey When the journey is wholly domestic (all ticketed points on the journey are in the same country), then a
OW journey is a journey where the destination point of the journey is not in the same point as the
origin point of the journey.
When the journey is international (at least two ticketed points are in different countries), then a OW
journey is a journey where the destination point of the journey is not in the same country as the
origin point of the journey.
Operating Carrier The carrier actually providing flight service (e.g. not necessarily shown on the ticket)
Portion of Travel One or more consecutive sectors with the same marketing carrier.
Round Trip Journey When the journey is wholly domestic (all ticketed points on the journey are in the same country), then a
RT journey is a journey where the destination point of the journey is the same point as the origin
point of the journey.
When the journey is international (at least two ticketed points are in different countries), then a RT
journey is a journey where the destination point of the journey is in the same country as the origin
point of the journey.
S2 Services Concurrence Record – Identifies the marketing carriers (including themselves) on behalf of
whom the validating carrier will collect service fees.
Sector A portion of a journey covered by a single flight coupon.

Term Definition
Service Type Code A code identifying the service for which a fee will be assessed. This code is made up of a generic
“tax” (service) code and a more specific sub-code to further define the service.
Validate Compare. When used in this document to describe how to process the data, the term “validate” means
to compare. For example, “validate the data against the sector being processed” means to compare the
data against the sector being processed.
Validating Carrier The carrier whose ticket stock was used to issue the ticket (plating carrier). This carrier is commonly
the holder of the money for the ticket.
2.2 Assumptions
Processing of the Record S1 takes place when the validating carrier permits the collection of fees for marketing carriers as determined
by the Record S2 or for itself in the absence of Record S2 for the validating carrier.
If processing cannot resolve to an applicable Record S1 for the marketing carrier on the sector/portion of travel being processed, then
there is no fee applicable for that sector/portion of travel for any Service Type Code (Tax Code and Sub-Code).
Once processing resolves to an applicable Record S1, the fee specified in the Record S1 applies to the ticket according to the Fee
Application value in byte 277.

3.0 DETAILED FIELD PROCESSING
Byte Location Match / Action Definition / Processing

Bytes 1-2 Key Match Indicates the Record Number for which the data is formatted.
Record Type
Bytes 3-5 Key Match Specifies the marketing carrier on the sector. This is the carrier that owns and
Carrier Code controls the record.
Bytes 6-10 Key Match/ Specifies the Tax Code and Sub-Code applicable to this record.
Service Type Code Action
Bytes 11-20 N/A
Filler
Bytes 21-28 Action Indicates the subscription unit of work. This is used for data base maintenance
MCN only.
Bytes 29-35 Key Match/ Specifies the order in which the records must be processed within each unique
Sequence Number Action Tax Code and Sub-Code combination
Byte 36 N/A
Filler
Bytes 37-48 Match Specify the first and last travel dates for which this record is effective.
Travel Dates (Eff/Disc)
Bytes 49-60 Match Specify the first and last ticketing dates for which the data in this record applies.
Ticket Dates
Bytes 61-68 Match A number referring to a table containing a list of carriers. The data in this record
Carrier Application Table No. only applies if one of these carriers is the validating carrier.
190
Byte 69 Match Specifies whether the data in this record only applies when travel on the journey
Return to Origin does or does not return to the journey origin.
Bytes 70-72 Match Indicates that the data in this record only applies for the specified passenger type.
Passenger Type Code


Bytes 73-77 N/A
Passenger Type Code –
FILLER
Bytes 78-81 N/A
Point of Sale - FILLER
Bytes 82-90 Match Specifies that the data in this record only applies when the ticket is sold in a
Point of Sale – specific geographic location.
Geographic Specification
Bytes 91-99 Match Specifies that the data in this record only applies when the ticket is sold by a
Point of Sale – Code specific agency/department/ERSP/LNIATA address.
Bytes 100-108 Match Specifies that the data in this record only applies when the ticket is issued in a
Point of Ticketing – specific geographic location.
Geographic Specification
Byte 109 Match/Action Specifies whether the data in the following Loc 1 field identifies a journey origin
Journey Geo Spec – Indicator or turnaround point.
Bytes 110-127 Match Indicates that the data in this record only applies when the journey origin and/or
Journey Geo Spec – turnaround points are in the specified locale(s).
Loc 1/Loc 2
Bytes 128-136 Match Indicates that the data in this record only applies when the journey contains travel
Journey Geo Spec – via the specified locale(s).
Via Loc
Bytes 137-145 Match Indicates that the data in this record only applies all ticketed points on the
Journey Geo Spec – journey are wholly within the specified locale(s).
Travel Wholly Within
Byte 146 Match/Action Specifies whether the data in the following location fields identifies a sector or
Sector/Portion Geo Spec – portion of travel.
Indicator
Byte 147 Match/Action Specifies from/to directional application of the data in the following Loc fields.
Sector/Portion Geo Spec –
From/To

Bytes 148-165 Match Indicates that the data in this record only applies to a sector/portion of travel
Sector/Portion Geo Spec – from/to/between the specified point(s).
Loc 1/Loc 2
Bytes 166-174 Match Indicates that the data in this record only applies to a portion of travel via the
Sector/Portion Geo Spec – specified point(s).
Via Loc
Byte 175 Match Indicates that the data in this record only applies to a portion of travel via a
Sector/Portion Geo Spec – stopover or connection point.
Stopover/Connection
Byte 176-179 Match/Action Indicates the minimum amount of elapsed time at a point at which the point
Sector/Portion Geo Spec – becomes a stopover.
Exception Stopover Time/Unit
Byte 180 Action Indicates that if the portion of travel contains a connection point, then the sectors
Sector/Portion Geo Spec – into and out of the Via Loc constitute a single sector
Via Connection Exempt
Byte 181 Match Indicates that the data in this record only applies to an international or domestic
Sector/Portion Geo Spec – sector/portion of travel.
International/Domestic
Bytes 182-193 N/A
Filler
Bytes 194-201 Match A number referring to a table containing carriers and flights. The data in this
Carrier/Flight Table No. 186 record only applies when travel on the sector/portion of travel being validated is
on the specified carrier(s)/flight(s).
Byte 202 N/A
Filler
Bytes 203-208 Match Indicates that the data in this record only applies when travel on the sector/portion
RBD of travel being validated is booked in the specified RBD(s).
Bytes 209-211 Match Indicates that the data in this record only applies when travel on the sector/portion
Equipment Code of travel being validated is on the specified equipment


Bytes 212-226 Match Indicates that the data in this record only applies for the specified fare basis code.
Fare Basis Code
Bytes 227-246 N/A
Filler
Bytes 247-253 N/A Identifies the user that submitted the batch for processing and the associated batch
Batch ID/Number number.
Bytes 254-257 N/A
Filler
Bytes 258-268 Action Identifies a specified Service Fee applicable to the sector/portion of travel that
Service Fee – matches this record.
Amount/Currency/Decimal
Bytes 269-275 Match/Action Identifies that when all travel on the ticket is wholly online, then Service Fee that
Service Fee – Percent is applicable to the sector/portion of travel that matches this record is a percentage
of the base fare.
Bytes 276 Action Specifies whether or not the Service Fee includes tax.
Service Fee – Tax Included
Byte 277 Action Specifies whether the Service Fee applies per sector, per direction, or per journey.
Service Fee – Fee Application
Bytes 278-285 Action A number referring to a table containing free-form text regarding this record. The
Text Table No. 196 information within this table is not priceable data.
Bytes 286-295 N/A
Filler

4.0 PROCESSING
Prior to processing Record S1, processing must first process Concurrence Record S2 for the validating carrier. Record S2 will specify
whether the validating carrier concurs to collecting Service Fees on their ticket. If an applicable Record S2 is not present or not
matched, then it is assumed that the validating carrier only concurs to collecting Service Fees on sectors where they
are the marketing carrier. Refer to Data Application for Carrier-Imposed (YQ/YR) Fees; Concurrence Record S2 for further
information.
Processing will validate Record S1 for each sector of the ticket (provided that the validating carrier concurs to collecting Service Fees
for the marketing carrier on the sector), beginning with the first sector. Processing will attempt to match the record based on the
match fields identified in the previous section. The relationship among all match fields is AND. Processing must match all match
criteria in order to match the record.
The following processing applies for each sector of the journey, beginning with the first sector (see below regarding sector vs.
portion of travel):
1. Process Record S1s in sequential order within each unique Service Type Code (defined as both the tax code and sub-code)
a. If the sector being validated matches a Record S1 for Service Type Code:
i. Apply the service fee data in the matched record. Do not continue processing to any other records with the same Service
Type Code.
ii. Continue processing other Record S1s with a different Service Type Code.
b. If the sector being validated does not match a Record S1 for the Service Type Code:
i. No service fee applies for that Service Type Code.
ii. Continue processing other Record S1s with a different Service Type Code.
2. Once processing has attempted to match Record S1s for every unique Service Type Code for the marketing carrier on the sector,
apply all applicable service fees to the sector being validated (according to the value in Fee Application byte 277.
Sector vs. Portion of Travel

One or more consecutive sectors for the same marketing carrier constitute a portion of travel. As a group, these consecutive sector(s)
can be matched against a single Record S1 when Sector/Portion of Travel Geographic Specification data is present and validates as a
portion of travel according to the Sector/Portion of Travel Indicator (byte 146) value P. A detailed explanation is provided later in this
document in the section for Sector/Portion of Travel Geographic Specification.

Open/Surface Sectors
When open sectors are permitted, the open sector(s) will be validated against Record S1. Validation of any open sectors is optimistic,
but not unrealistic. Processing will validate all known information pertaining to the fare and may apply a fee if there is enough
information to ascertain that the fee would apply when booked. (The allowance of open sectors is addressed in Category 5 Confirmed
Sector field byte 31.)
Surface sectors are not validated against Record S1

4.1 Application of Data for Record S1

This section provides a detailed explanation of the data application for each field in Record S1. Refer to the Data Application
Examples; Carrier- Imposed (YQ/YR) Fees Record S1document for examples illustrating the data application.
The section numbers for the fields below match the corresponding section numbers for the fields in the Data Application Examples;
Carrier- Imposed (YQ/YR) Fees Record S1document.
4.1.1 Carrier Code (bytes 3-5)

This field specifies the marketing carrier on the sector being validated. If the marketing carrier on the sector being validated matches
the carrier code in bytes 3-5, then processing matches the record (provided a match is also made to all other match fields). If the
marketing carrier on the sector being validated does not match the carrier code in bytes 3-5, then processing no matches the record and
continues to the next record.
Refer to the example(s) under this same section number in the Data Application Examples; Carrier- Imposed (YQ/YR) Fees Record
S1document.

4.1.2 Service Type Code (bytes 6-10)

The Service Type fields consist of the following:
Field Explanation Applicable Values

Service “Tax” Code High-level identification of the type of service YQ = YQ service fee
YR = YR service fee
NOTE: At a future date, “OC” will be the only valid

Service “Tax” Code in this field.
Sub-code Specific identification of the type of fee applicable to this YQ-F = Fuel Fees
record YQ-I = Carrier-Imposed Miscellaneous Fees
YR-F = Fuel Fees
YR-I = Carrier-Imposed Miscellaneous Fees
The definition of the Service “Tax” Code and Sub-Code are carrier defined (not industry defined). Whether the fee applicable to the
record is a YQ or YR fee, fuel or a carrier-imposed fee, is determined by the data record owner (marketing carrier). It is possible that
carrier XX will have a YQ fuel fee, while carrier ZZ will have a YQ carrier-imposed fee.
The Service “Tax” Code and/or Sub-code will be used on the associated ticket/documentation to identify the type of fee.
S1document.

4.1.3 MCN (bytes 21-29)

The Maintenance Control Number (MCN) indicates the subscription unit of work and is used for database maintenance only.

4.1.4 Sequence Number (bytes 29-35)

This field specifies the order in which the records should be read within each unique Service Type Code (defined as both the tax code
and sub-code). Once a match is made to a sequence, processing will apply the data in the sequence and will not read on to another
sequence for the same unique Service Type Code for the sector being validated. Processing will continue to other sequences with a
different Service Type Code for the sector being validated.
S1document.

4.1.5 Travel Dates – Effective/Discontinue (bytes 37-48)

These fields specify the First and/or Last Travel Dates (Effective and Discontinue Dates) for the record. Validation of these dates is
against the departure date from the origin of the journey encompassing the sector being validated. If the departure date from the origin
of the journey is within the specified dates, then processing matches the record (provided a match is also made to all other match
fields). If the departure date from the origin of the journey is not within the specified dates, then processing no matches the record and
continues to the next record.
A date will always be present in the First Travel (Effective) Date field (bytes 38-44). The Last Travel (Discontinue) Date field (bytes
45-51) may contain a specific date or may contain 999999 signifying there is no restriction on the Last Travel (Discontinue) date
(subject to the remaining data within the record).
S1document.

4.1.6 Ticket Dates (bytes 49-60)

These fields specify the First and/or Last Ticket Dates for the record. Validation of these dates is against the ticket issue date for the
current ticket (ticket being issued/reissued). If the ticket issue date within the specified dates, then processing matches the record
(provided a match is also made to all other match fields). If the ticket issue date is not within the specified dates, then processing no
matches the record and continues to the next record.
Value 999999 may be present in either or both of these fields and signifies there is no restriction on the First and/or Last Ticket date
respectively, (subject to the remaining data within the record).
S1document.

4.1.7 Carrier Application Table No. 190 (bytes 61-68)

This field identifies one or more carriers that must be the validating carrier in order to match the record. Carrier data within Table 190
may be expressed positively (must be the validating carrier) or negatively (must not be the validating carrier). Edits require that when
a negative entry is present, there must be a positive entry with carrier code $$ signifying “any carrier except the negative carrier(s).”
If the validating carrier validates against a positive entry in Table 190, then processing matches Record S1 (provided a match is also
made to all other match fields). If the validating carrier does not validate against any entry in Table 190 or validates against a negative
entry in Table 190, then processing no matches Record S1.
When Table 190 is value 00000000 (e.g. does not contain data), there is no restriction on the validating carrier (subject to the
remainder of the data in the record).
S1document. Additionally, refer to Data Application for Carrier Application Table No. 190.

4.1.8 Return to Origin (byte 69)

This field specifies whether travel on the journey must or must not return to the journey origin in order to match the record.
Following is an explanation of the applicable values:
Value Y: Specifies that travel on the journey must return to the journey origin in order to match the record.
• When the journey is wholly domestic (all ticketed points of the journey are in the same country), then the
destination point of the journey must be the same point (same city) as the origin point (origin city) of the journey in
order to match the record.
• When the journey is international (at least two ticketed points are in different countries), then the destination point
of the journey must be in the same country as the origin point of the journey in order to match the record.
Value N: Specifies that travel on the journey must not return to the journey origin in order to match the record.
• When the journey is wholly domestic (all ticketed points of the journey are in the same country), then the
destination point of the journey must not be the same point (same city) as the origin point (origin city) of the
journey in order to match the record.
• When the journey is international (at least two ticketed points are in different countries), then the destination point
of the journey must not be in the same country as the origin point of the journey in order to match the record.
Value Blank: There is no restriction regarding whether or not travel must return to the journey origin (subject to the remainder of the
data in the record).
S1document.

4.1.9 Passenger Type (bytes 70-72)

This field specifies the Passenger Type Code (PTC) to which the service fee applies. Validation of this field is against the passenger
in the input command that drove the ticket. If the data in this field matches the ticketed passenger, then processing matches the record
(provided a match is also made to all other match fields). If data in this field does not match the ticketed passenger, then processing
no matches the record and continues to the next record..
PTC mapping applies. The PTC of the entry must exactly match the PTC of the Record S1 being processed (when present) or map up
to the Record S1 PTC using hierarchy. For example, Record S1 value CNN matches to any child/infant passenger type in the input
command. Edits prevent PTC ADT in this field.
When this field is value Blank, there are no passenger type restrictions for the sector/portion of travel being validated (subject to the
remaining data within the record). All PTCs match (map up to) value Blank in Record S1.
S1document.

4.1.10 Point of Sale (bytes 75-96)

The Point of Sale fields consist of the following fields:
• Geographic Specification (bytes 82-90)
• Code (bytes 91-99)
These fields identify any sales location requirements for Service Fee collection. The actual point of sale is defined as the location
(point) determined by the CRS/GDS that is actually collecting the money for the ticket. The relationship among the Point of Sale
fields is AND. Processing must match all point of sale conditions in order to match the record.
4.1.10.1 Point of Sale – Geographic Specification (bytes 82-90)

This field specifies that in order for the Services Fee to be applicable, the ticket must be sold in a specific geographic location.
Anyone selling the ticket within the specified geographic location will match the record (e.g. any carrier, any travel agent, etc.). The
geographic location may be defined as an Area, Zone, Country, State, City, Airport, or via use of User Zone Table No. 178 which
permits the specification of multiple locations to create a user defined zone.
When this field is blank, there are no collection restrictions on the geographic location of the sale. The Service Fee will be collected
regardless of point of sale (subject to the remainder of the data in the record).
S1document.

4.1.10.2 Point of Sale – Code (bytes 91-99)

This field specifies that the Service Fee applies when the ticket is sold by a specific travel agency. The Code specified in bytes 91-99
must be reported as the entity selling the ticket. Following is an explanation of the applicable values:
Value T: Pseudo City Code – Travel Agency
Value I: IATA Travel Agency Number
When this field is blank, there are no Service Fee collection restrictions based upon the pseudo city code/travel agency selling the
ticket. The Service Fee will be collected regardless of location of sale ticket (subject to the remainder of the data in the record).
S1document.

4.1.11 Point of Ticketing – Geographic Specification (bytes 100-108)

This field specifies that the Service Fee applies when the ticket is issued in a specific geographic location. The actual point of ticket is
defined as the geographic location (point) determined by the CRS/GDS that is actually generating a ticket for the fare. Anyone
issuing the ticket within the specified geographic location will match the record (e.g. any carrier, any travel agent, etc.). The
geographic location may be defined as an Area, Zone, Country, State, City, Airport, or via use of User Zone Table No. 178 which
permits the specification of multiple locations to create a user defined zone.
When this field is blank, there are no Service Fee collection restrictions based upon the geographic location where the ticket is issued.
The Service Fee will be collected regardless of point of ticketing (subject to the remainder of the data in the record).
S1document.

4.1.12 Journey Geographic Specification (bytes 109-145)

The Journey Geographic Specification fields consist of the following fields:
• Indicator (byte 109)
• Loc 1 – Journey Origin or Journey Turnaround/Destination Point (bytes 120-128)
• Loc 2 – Journey Origin or Journey Turnaround/Destination Point (bytes 129-137)
• Via Loc (bytes 128-136)
• Travel Wholly Within (bytes 137-145)
These fields identify the geographic restrictions for the journey. Validation of these fields is against the entire journey. The
relationship among the Journey Geographic Specification fields is AND. Processing must match all conditions in order to match the
record.
4.1.12.1 Journey Geo Spec – Indicator (byte 109)

This field specifies the journey origin or journey turnaround/destination application of the location specified in the following Loc 1
field (bytes 120-128). Following is an explanation of the applicable values:
Value A: Indicates that Loc 1 specifies the journey origin point.
When Loc 1 and Loc 2 are present, then Loc 1 validates against the journey origin point and Loc 2 validates as
follows:
• For RT journeys (see definition), Loc 2 validates against the journey turnaround point
• For OW journeys (see definition), Loc 2 validates against the journey destination (last point on the ticket).
When Loc 1 is present and Loc 2 is blank, then Loc 1 validates against the journey origin point. For RT journeys (see
definition), there is no restriction on the journey turnaround point (subject to the remainder of the data in the record).
For OW journeys (see definition), there is no restriction on journey destination (last point on the ticket).

Value Blank: Indicates that Loc 1 specifies either the journey origin or journey turnaround/destination point.
When Loc 1 and Loc 2 are present and the journey is RT (see definition):
• When Loc 1 validates against the journey origin point, then Loc 2 must validate against the journey turnaround
point.
• When Loc 1 validates against the journey turnaround point, then Loc 2 must validate against the journey origin
point.
When Loc 1 and Loc 2 are present and the journey is OW (see definition):
• When Loc 1 validates against the journey origin point, then Loc 2 must validate against the journey destination
(last point on the ticket).
• When Loc 1 validates against the journey destination (last point on the ticket), then Loc 2 must validate against
the journey origin point.
When Loc 1 is present and Loc 2 is Blank and the journey is RT (see definition):
• When Loc 1 validates against the journey origin point, then there is no restriction on the journey turnaround
point, subject to the remainder of the data in the record.
• When Loc 1 validates against the journey turnaround point, then there is no restriction on the journey origin
point, subject to the remainder of the data in the record.
When Loc 1 is present and Loc 2 is Blank and the journey is OW (see definition):
• When Loc 1 validates against the journey origin point, then there is no restriction on the journey destination (last
point on the ticket), subject to the remainder of the data in the record.
• When Loc 1 validates against the journey destination (last point on the ticket), then there is no restriction on the
journey origin point, subject to the remainder of the data in the record.
When Loc 1 and Loc 2 are Blank, there is no restriction on the journey origin and journey turnaround points (subject
to the remainder of the data in the record).
S1document.


4.1.12.2 Journey Geo Spec – Loc 1 / Loc 2 (bytes 110-127)

These fields specify the journey origin and turnaround/destination points (depending upon whether the journey is RT or OW). Data
in the Indicator field (byte 109) specifies whether Loc 1 is a journey origin point or either a journey origin or turnaround/destination
point (refer to the previous section).
The journey turnaround point is defined as the furthest stopover or fare break point, measured from the origin of the journey.
Processing should measure using the following steps:
• Measure using the non-stop TPM (Ticketed Point Mileage) between the origin of the journey and the stopover/fare break point.
o When a single TPM exists between the points being measured, use the TPM regardless of the global.
o When multiple TPMs exist between the points being measured, apply Global direction in determining the correct TPM
to use.
o When more than one global direction applies to the points being measured, use the highest TPM that applies for one of
the global directions.
• If there are no TPMs, calculate TPMs as MPM (Maximum Permitted Mileage) divided by 1.2 (MPM/1.2).
o When a single MPM exists between the points being measured, use the MPM regardless of the global.
o When multiple MPMs exist between the points being measured, apply Global direction in determining the correct
MPM to use.
o When more than one global direction applies to the points being measured, use the highest MPM that applies for one
of the global directions.
• If MPMs do not exist, use GCM (Great Circle Mileage).
The geographic location data in Loc 1 and Loc 2 may be defined as an Area, Zone, Country, State, City, Airport, or via use of User
Zone Table No. 178 which permits the specification of multiple locations to create a user defined zone.
When these fields are blank, there are no restrictions on the journey origin and turnaround/destination points, subject to the remainder
of the data in the record.
The following charts provide an explanation of the relationship among the values in the Indicator, Loc 1, and Loc 2 fields based on RT
and OW Journeys:
For RT Journeys (see definition)

Ind Loc 1 data Loc 2 data Loc 1 Validation Loc 2 Validation
A Present Present Validate against Journey Origin Validate against Journey Turnaround
A Present Blank Validate against Journey Origin No application. (No restriction on Journey
Turnaround point)
Blank Present Present Validate against Journey Origin or Journey Validate against Journey Origin or Journey
Turnaround Point as follows: Turnaround Point as follows:
a. Validate against Journey Origin a. Validate against Journey Turnaround
b. Validate against Journey Turnaround b. Validate against Journey Origin
NOTE: If Loc 1 validates against Journey Origin, then Loc 2 must validate against Journey Turnaround.
Likewise, if Loc 1 validates against Journey Turnaround, then Loc 2 must validate against Journey
Origin.
Blank Present Blank Validate against Journey Origin or Journey No application.
Turnaround Point as follows:
a. Validate against Journey Origin a. No restriction on Journey Turnaround
point
b. Validate against Journey Turnaround b. No restriction on Journey Origin
Blank Blank Blank No application. (No restriction on Journey No application. (No restriction on Journey
Origin or Journey Turnaround point, subject to Origin or Journey Turnaround point, subject to
the remainder of the data in the record) the remainder of the data in the record)

For OW Journeys (see definition)

Ind Loc 1 data Loc 2 data Loc 1 Validation Loc 2 Validation
A Present Present Validate against Journey Origin Validate against Journey Destination
A Present Blank Validate against Journey Origin No application. (No restriction on Journey
Destination point)
Blank Present Present Validate against Journey Origin or Journey Validate against Journey Origin or Journey
Destination Point as follows: Destination Point as follows:
a. Validate against Journey Origin a. Validate against Journey Destination
b. Validate against Journey Destination b. Validate against Journey Origin
NOTE: If Loc 1 validates against Journey Origin, then Loc 2 must validate against Journey Destination.
Likewise, if Loc 1 validates against Journey Destination, then Loc 2 must validate against Journey
Origin.
Blank Present Blank Validate against Journey Origin or Journey No application.
Destination Point as follows:
a. Validate against Journey Origin a. No restriction on Journey Destination
point
b. Validate against Journey Destination b. No restriction on Journey Origin
Blank Blank Blank No application. (No restriction on Journey No application. (No restriction on Journey
Origin or Journey Destination point, subject to Origin or Journey Destination point, subject to
the remainder of the data in the record) the remainder of the data in the record)
S1document.

4.1.12.3 Journey Geo Spec – Via Loc (bytes 128-136)

This field specifies a point that must be on the journey in order to match the record. Validation is against any ticketed point on the
journey, with the exception of the journey origin, journey turnaround, and journey destination points. If at least one ticketed point on
the journey (other than the journey origin, turnaround, and destination points) matches the Via Loc data, then processing matches the
record (provided a match is also made to all other match criteria). If no ticketed point on the journey (other than the journey origin,
turnaround, and destination points) matches the Via Loc data, then processing no matches the record and continues to the next record.
The geographic location data may be defined as an Area, Zone, Country, State, City, Airport, or via use of User Zone Table No. 178
which permits the specification of multiple locations to create a user defined zone.
When this field is blank, there are no Via Loc restrictions on the journey (subject to the remainder of the data in the record.)
S1document.

4.1.12.4 Journey Geo Spec – Travel Wholly Within (bytes 137-145)

This field specifies that all ticketed points on the journey must be within a specified location in order to match the record. Validation
is against all ticketed point on the journey, including the journey origin, journey turnaround, and journey destination points. If all
ticketed points on the journey match the Travel Wholly Within data, then processing matches the record (provided a match is also
made to all other match criteria). If at least one ticketed point on the journey does not match the Travel Wholly Within data, then
processing no matches the record and continues to the next record.
The geographic location data may be defined as an Area, Zone, Country, State, City, Airport, or via use of User Zone Table No. 178
When this field is blank, there are no Travel Wholly Within restrictions on the journey (subject to the remainder of the data in the
record.)
S1document.

4.1.13 Sector/Portion of Travel Geographic Specification (bytes 146-181)

The Sector/Portion of Travel Geographic Specification fields consist of the following fields:
• Sector/Portion Indicator (byte 146)
• From/To (byte 147)
• Loc 1 (bytes 148-156)
• Loc 2 (bytes 157-165)
• Via Loc (bytes 166-174)
• Stopover/Connection (byte 175)
• Exception Stopover Time (bytes 176-179)
• Connection Exempt (bytes 180)
• International/Domestic (byte 181)
These fields identify the geographic restrictions for the sector/portion of travel being validated. Validation of these fields is against
ticketed points. When processing Record S1, processing will attempt to validate each sector of the journey against Record S1 data for
the marketing carrier on the sector. It is possible that one or more consecutive sectors with the same marketing carrier (portion of
travel) may be validated against a single Record S1, depending upon the data in the Indicator field (byte 146).
The relationship among the Sector/Portion of Travel Geo Spec fields is AND. Processing must match all conditions in order to match
the record.

4.1.13.1 Sector/Portion Geo Spec – Indicator (byte 146)

This field specifies whether the data in the Sector/Portion of Travel Geo Spec fields (bytes 147-181) validates against a single sector
or against a portion of travel. Following is an explanation of the applicable values:
Value P: Portion of Travel. Data in the Sector/Portion Geo Spec fields must validate against a portion of travel encompassing
the sector being processed in order to match the record. The portion of travel must consist of the sector being
processed and may consist of the following adjacent sectors on the same marketing carrier.
When a attempting to match a portion the travel, processing will take the following steps:
1. Determine the portion of travel by identifying all consecutive sectors, starting with the sector being validated, that
have the same marketing carrier and that do not cross the turnaround point of the journey and does not include a
surface sector. (The portion of travel may consist only of the sector being validated or may consist of multiple
consecutive sectors including the sector being validated all on the same marketing carrier. The sector being
validated must be included in this portion of travel.)
a. If the sector being validated or multiple consecutive sectors including the sector being validated meet the
above criteria, this portion of travel is eligible to be used to validate the Sector/Portion of Travel fields.
Processing should identify the largest portion of travel possible (e.g. if 1 sector meets the portion of travel
requirements, 2 sectors meet the portion of travel requirements, and 3 sectors also meet the portion of travel
requirements, then attempt to validate the 3 sectors first. If processing cannot match the 3 sectors, then
attempt to validate the 2 sectors. If processing cannot match the 2 sectors, then attempt to validate the 1
sector). Proceed to the next step.
b. If the sector being validated and consecutive sectors including the sector being validated do not meet the
above criteria, no match the record.
NOTE: A sector that has already matched a Record S1 for the Service Type Code (Service “Tax” Code and Sub Code) in the record
being processed cannot be included in the portion of travel because a single sector cannot accumulate multiple fees for the same
Service Type Code.
2. Process the Portion of Travel identified in Step 1 against the Sector/Portion of Travel fields.
3. The portion that matches the data in the Sector/Portion of Travel fields (Step 2) is the matched portion of travel
and will be used to validate the data in the International/Domestic(byte 181), Carrier/Flight Table No. 186(bytes
194-201), RBD (bytes 203-208), Equipment (bytes 209-211), and Fare Basis Code (bytes 212-226) fields.

Example
Itinerary = A-B-C-D-E on the same marketing carrier.
When validating the A-B sector, if the Indicator field is value P (portion of travel) the following portions of
travel are eligible to be used to validate the data in the record:
A-B
A-C
A-D
A-E
When validating the B-C sector, if the Indicator field is value P (portion of travel) the following portions of
travel are eligible to be used to validate the data in the record:
B-C
B-D
B-E
Processing validates Record S1 for each sector of the journey starting from the first sector. When validating the
B-C sector above, processing would have already attempted to match A-B (and any applicable portion of travel)
against any applicable Record S1. Therefore, A-B is not considered when validating B-C.
If the data in bytes 147-181 matches a portion of travel encompassing the sector being validated, processing matches
the record for all sectors within the portion of travel (provided a match is also made to all other match criteria). If the
data in bytes 147-181 does not match a portion of travel encompassing the sector being validated, processing no
matches the record and continues to the next record.
When the remaining Sector/Portion Geo Spec Fields (bytes 147-181) are value “blank.”, edits prevent value P
Value Blank: Sector. Data in the Sector/Portion Geo Spec fields must validate against the sector being processed in order to match
the record. If the data in bytes 147-181 matches the sector being validated, processing matches the record (provided
a match is also made to all other match criteria). If the data in bytes 147-181 does not match the sector being
validated, processing no matches the record and continues to the next record.
The sector being validated that matches the data in the Sector/Portion of Travel fields will be used to validate the data
in the Carrier/Flight Table No. 186 (bytes 194-201), RBD (bytes 203-208), and Equipment (bytes 209-211) fields
When the Sector/Portion Geo Spec fields do not contain any data (they are value “blank”), there are no geographic
restrictions on the sector being validated (subject to the remainder of the data in the record). Processing only
validates a single sector against the record being processed; processing does not validate a portion of travel against
the record.
S1document.

Sector/Portion Geo Spec – From/To (byte 147)

This field specifies the directional application of the data in the following Loc 1 and Loc 2 fields (bytes 158-175). Validation of this
field is based on the direction of travel and not the direction of fare selection. Following is an explanation of the applicable values:
Value 1: From Loc 1. Indicates processing must match a sector/portion of travel (depending upon the value in Indicator byte
146) that is From Loc 1.
When both Loc 1 and Loc 2 are present, processing must match a sector/portion of travel where travel is From
Loc 1 to Loc 2.
When Loc 1 is present and Loc 2 is blank, processing must match a sector/portion of travel where travel is From
Loc 1 to any point.
Value 2: To Loc 1. Indicates processing must match a sector/portion of travel (depending upon the value in Indicator byte
146) that is To Loc 1.
When both Loc 1 and Loc 2 are present, processing must match a sector/portion of travel where travel is from
Loc 2 to Loc 1.
When Loc 1 is present and Loc 2 is blank, processing must match a sector/portion of travel where travel is from
any point to Loc 1.
Value Blank: No application (Loc 1 and Loc 2 are between/and).
When both Loc 1 and Loc 2 are present, they have a between/and application. Processing must match a
sector/portion of travel where travel is between Loc 1 and Loc 2.
When Loc 1 is present and Loc 2 is blank, processing must match a sector/portion of travel where travel is
From/To Loc 1.
S1document.
4.1.13.2 Sector/Portion Geo Spec – Loc 1/Loc 2 (bytes 148-156, 157-165)

These fields specify the end points of the sector/portion of travel being validated. Data in the Indicator field (byte 146) specifies
whether validation is against a sector or portion of travel, as follows:
• When Indicator is value P, Loc 1 and Loc 2 validate against the end points of the portion of travel being processed. (Loc 1 and
Loc 2 do not necessarily have to match against the end points of each sector within the portion of travel. Only the origin point of
the first sector and the destination point of the last sector have to match.) The portion of travel may include all points within Loc
1, all points between Loc 1 and Loc 2, and all points within Loc 2.
• When Indicator is value Blank, Loc 1 and Loc 2 validate against the end points of the sector being processed.
Data in the From/To field (byte 147) specifies whether Loc 1 and Loc 2 have a From/To or Between/And relationship (refer to the
previous section).
When Loc 1 and Loc 2 contain data, the sector/portion of travel (depending upon the Indicator value in byte 146) being validated must
be from/to/between Loc 1 and Loc 2 (depending upon the From/To value in byte 147) in order to match the record. If the
sector/portion of travel does not meet the specified geographic criteria, processing no matches the record and continues to the next
record.
When Loc 1 contains data and Loc 2 is blank, the sector/portion of travel (depending upon the Indicator value in byte 146) being
validated must be from/to Loc 1 (depending upon the From/To value in byte 147) in order to match the record. If the sector/portion of
travel does not meet the specified geographic criteria, processing no matches the record and continues to the next record
When Loc 1 and Loc 2 are blank, there are no restriction on the end points of the sector/portion of travel being validated, subject to the
remaining data in the record.
The geographic location data in Loc 1 and Loc 2 may be defined as an Area, Zone, Country, State, City, Airport, or via use of User
Zone Table No. 178 which permits the specification of multiple locations to create a user defined zone.
S1document.

4.1.13.3 Sector/Portion Geo Spec – Via Loc (bytes 166-174)

These field specify a ‘Via’ point that must be on the portion of travel being validated. Via Loc has no application on a sector. When
Via Loc contains data, edits require that Indicator (byte 146) be value P (portion of travel).
When Via Loc is present and data is also present in Loc 1 (bytes 148-156):
Edits require data in Loc 2 (bytes 157-165). The Via Loc must be a ticketed point (connection, stopover, or fare break point)
between Loc 1 and Loc 2 in order to match the record. The Via Loc cannot be the same point as matches Loc 1 and/or Loc 2.
(For example, if the data states between GB and FR via LYS, a LON-LYS-PAR portion will match, but a LON-AMS-LYS
portion will not match). If the portion of travel being validated is between Loc 1 and Loc 2 via the specified Via Loc
processing matches the record (provided a match is also made to all other match criteria). If the portion of travel being
validated is not between Loc 1 and Loc 2 via the specified Via Loc, processing no matches the record and continues to the next
record.
When Via Loc is present and Loc 1 (bytes 148-156) and Loc 2 (bytes 157-165) are blank:
The Via Loc must be a ticketed point (connection, stopover, or fare break point) between two sectors where the owning carrier
of the Record S1 is the marketing carrier on both sectors. Only the sectors into and out of the Via Loc are validated as the
portion of travel.
The Via Loc may be further defined as a stopover or connection point (based on elapsed time at the point), depending upon the data in
the following Stopover/Connection field (byte 175)
The geographic location may be defined as an Area, Zone, Country, State, City, Airport, or with the User Zone Table Number 178
When Via Loc is value blank, there are no via loc requirements, subject to the remainder of the data in the record.
S1document.

4.1.13.4 Sector/Portion Geo Spec – Stopover/Connection (byte 175)

This field specifies whether via points on the portion of travel being validated must be connection or stopover points.
Stopover/connection points have no application on a sector. When Stopover/Connection byte 175 contains data, edits require that
Indicator (byte 146) be value P (portion of travel).
Following is an explanation of the applicable values:
Value C: Connection. Indicates that the Via points on the portion of travel being validated must be connection points.
Value S: Stopover. Indicates that the Via points on the portion of travel being validated must be stopover points.
Value Blank: No Restriction. Indicates that the Via points on the portion of travel being validated may be connection and/or
stopover points.
When data is present in Loc 1 (bytes 148-156):

Edits require data in Loc 2 (bytes 157-165).
When Via Loc is present, the Stopover/Connection data in byte 175 only applies to the specified Via Loc(s). All Via Locs that
match the data in bytes 166-174 must be a stopover/connection point as specified by the data in byte 175. If the portion of
travel being validated is between Loc 1 and Loc 2 via the specified stopover/connection Via Loc, processing matches the
record (provided a match is also made to all other match criteria). If the portion of travel being validated is not between Loc 1
and Loc 2 via the specified stopover/connection Via Loc, processing no matches the record and continues to the next record.
When Via Loc is not present, the Stopover/Connection data in byte 175 applies to all Via Locs (ticketed points) within the
portion of travel being validated. All Via Locs must be stopover/connection points as specified by the data in byte 175. If the
portion of travel being validated is between Loc 1 and Loc 2 via stopover/connection points as specified, processing matches
the record (provided a match is also made to all other match criteria). If the portion of travel being validated is not between
Loc 1 and Loc via stopover/connection points as specified, processing no matches the record and continues to the next record

When Loc 1 (bytes 148-156) and Loc 2 (bytes 157-165) are blank:
When Via Loc is present, the Via Loc must be a stopover/connection point (as specified by the data in byte 175) between two
sectors where the owning carrier of the Record S1 is the marketing carrier on both sectors. Only the sectors into and out of the
Via Loc are validated as the portion of travel.
When Via Loc is not present, there must be a stopover/connection point (as specified by the data in byte 175) between two
sectors where the owning carrier of the Record S1 is the marketing carrier on both sectors. Only the sectors into and out of the
stopover/connection point are validated as the portion of travel.
Unless otherwise specified in the Exception Stopover Time fields (bytes 176-179), a stopover is defined as an arrival at a ticketed
point (including fare break points) that is scheduled to depart later than 24 hours after the arrival time (local time). A connection is
defined as an arrival at a ticketed point (including fare break points) that is scheduled to depart 24 hours or earlier after the arrival time
(local time).
S1document.

4.1.13.5 Sector/Portion Geo Spec – Exception Stopover Time (bytes 176-179)

These fields defines the maximum amount of time at a ticketed point (including fare break points) before that point is considered a
stopover. Stopover/connection points have no application on a sector; therefore, when Exception Stopover Time contains data, edits
require that Indicator (byte 146) be value P (portion of travel).
Following is an explanation of the applicable fields/values:
Time (bytes 176-178): Specifies the maximum amount of time at a point (including fare break points) before the point becomes a
stopover.
Unit (byte 179): Specifies the unit in which the Time data in bytes 176-178 is expressed, as follows:
Value N = Minutes
Value H = Hours
Value D = Days
Value M = Months
When data is present in Time, edits require data in Unit. A stopover occurs when there is an arrival at a ticketed point (including fare
break points) that is scheduled to depart later than the specified Time and Unit after the arrival time (local time). A connection occurs
when there is an arrival at a ticketed point (including fare break points) that is scheduled to depart in the specified Time and Unit or
earlier after the arrival time (local time).
Example:
Time (bytes 176-178) = 010
Unit (byte 179) = H
Result: If departure from a ticketed point is scheduled more than 10 hours after arrival (local time) at the point, then the point
is a stopover. If departure from a ticketed point is scheduled 10 hours or less after arrival (local time) at the point,
then the point is a connection.
When Time is value 000 and Unit is value D, this signifies “same day.” A stopover occurs when there is an arrival at a ticketed point
(including fare break points) that is scheduled to depart later than the day of arrival. A connection occurs when there is an arrival at a

ticketed point (including fare break points) that is scheduled to depart on the same day as the arrival (local time). When Time is Value
000, edits only permit value D in the Unit field.
When Time and Unit are value Blank, these fields have no application. A stopover occurs when there is an arrival at a ticketed point
(including fare break points) that is scheduled to depart later than 24 hours after the arrival time (local time). A connection occurs
when there is an arrival at a ticketed point (including fare break points) that is scheduled to depart 24 hours our earlier after the arrival
time (local time).
The Exception Stopover Time only applies when determining if a point is a stopover or connection in order to process the data in
Stopover/Connection (byte 175) and/or Connection Exempt (byte 180). Processing will only use the Exception Stopover Time in
conjunction with the data in bytes 175 and 180; therefore, when Exception Stopover Time contains data, edits require data in
Stopover/Connection (byte 175) and/or Connection Exempt (byte 180).
S1document.

Sector/Portion Geo Spec – Connection Exempt (byte 180)

This field specifies that determination of sectors for the purposes of applying data in Fee Application byte 277 is impacted by the
presence of connections (including connections at fare break points). Connection points have no application on a sector; therefore,
when the Connection Exempt field contains data, edits require that Indicator (byte 146) be value P (portion of travel).
Following is an explanation of the applicable fields/values:
Value X: If the portion of travel contains a connection point, then the sector into the connection point and the sector out of the
connection point constitute a single sector for the purpose of applying data in Fee Application byte 277. When multiple
consecutive connections exist on the portion of travel being validated, travel starting with the sector into the first
connection and ending with the sector out of the last connection constitute a single sector for the purpose of applying
data in Fee Application byte 277. For example: if the portion of travel is A-B-C-D-E and B, C, and D are connections,
then travel from A-E constitutes a single sector for fee application.
When data is present in Loc 1 (bytes 148-156):

Edits require data in Loc 2 (bytes 157-165).
When Via Loc (bytes 166-174) is present, the Connection Exempt data in byte 180 only applies to the specified Via
Loc(s) between Loc 1 and Loc 2. For all matched Via Locs between Loc 1 and Loc 2, the sector into the Via Loc and
the sector out of the Via Loc constitute a single sector for the purposes of applying data in Fee Application byte 277.
When multiple consecutive matched Via Locs exist between Loc 1 and Loc 2, travel from the sector into the first via
loc to the sector out of the last via loc constitute a single sector for the purpose of applying data in Fee Application byte
277.
When Via Loc (bytes 166-174) is not present, the Connection Exempt data in byte 180 applies to all connections
between Loc 1 and Loc 2. For all connections between Loc 1 and Loc 2, the sector into the connection and the sector
out of the connection constitute a single sector for the purposes of applying data in Fee Application byte 277. When
multiple consecutive connections exist between Loc 1 and Loc 2, travel from the sector into the first connection to the
sector out of the last connection constitute a single sector for the purpose of applying data in Fee Application byte 277.

When Loc 1 (bytes 148-156) and Loc 2 (bytes 157-165) are blank:
When Via Loc (bytes 166-174) is present, the Connection Exempt data in byte 180 only applies to the specified Via
Loc(s). For all matched Via Locs, the sector into the Via Loc and the sector out of the Via Loc constitute a single
sector for the purposes of applying data in Fee Application byte 277. When multiple consecutive matched Via Locs
exist, travel from the sector into the first Via Loc to the sector out of the last Via Loc constitute a single sector for the
purpose of applying data in Fee Application byte 277.
When Via Loc (bytes 166-174) is not present, the Connection Exempt data in byte 180 applies to all connections on the
matched portion of travel being validated against this record. For all connections, the sector into the connection and the
sector out of the connection constitute a single sector for the purposes of applying data in Fee Application byte 277.
When multiple consecutive connections exist on the matched portion of travel, travel from the sector into the first
connection to the sector out of the last connection constitute a single sector for the purpose of applying data in Fee
Application byte 277.
Unless otherwise specified in the Exception Stopover Time fields (bytes 176-179), a stopover is defined as an arrival at
a ticketed point (including fare break points) that is scheduled to depart later than 24 hours after the arrival time (local
time). A connection is defined as an arrival at a ticketed point (including fare break points) that is scheduled to depart
24 hours or earlier after the arrival time (local time).
Value Blank: No application - Each sector counts as a single sector.

4.1.13.6 Sector/Portion Geo Spec – International/Domestic (byte 181)

This field specifies whether the sector/portion of travel being validated (depending upon the value in Indicator byte 146) must be
international or domestic. Following is an explanation of the applicable values:
Value I: International. Indicates that the sector/portion of travel being validated (depending upon the value in Indicator byte
146) must be international.
When validating a sector (Indicator value Blank), the end points of the sector must be in different ATPCO Country
Codes.
Example: a LON-PAR sector is international.
When validating a portion of travel (Indicator value P), every sector in the portion of travel must be an international
sector. For every sector, the end points of the sector on the portion of travel must be in different ATPCO Country
Codes (all sectors within the portion have to be international).
Example: a CHI-LON portion of travel where travel is CHI-NYC-LON does not match value I because every sector
in the portion of travel is not international (CHI-NYC sector is not international).
Note the following exception:

• Travel between countries XU/RU is not international.
Note for clarification:

• Travel between a country with its own ATPCO Country Code and a country that does not have its own ATPCO
Country Code is international (e.g. between DE and Gaza is international).
• Travel between US and Canada is international.
• Travel between countries in Scandinavia is international.
• Travel between a nation and its territory possessing its own ATPCO Country Code is international (cabotage
travel is international).
• Travel between a nation and its territory not possessing its own ATPCO Country Code is considered part of the
sovereign state and not international

Value D: Domestic. Indicates that the sector/portion of travel being validated (depending upon the value in Indicator byte
146) must be domestic.
When validating a sector (Indicator value Blank), the end points of the sector must be in the same ATPCO Country
Code.
Example: a PAR-NCE sector is domestic.
When validating a portion of travel (Indicator value P), every sector in the portion of travel must be a domestic
sector. For every sector, the end points of the sector on the portion of travel must be in the same ATPCO Country
Codes (all sectors within the portion have to be domestic).
Example: a CHI-SEA portion of travel where travel is CHI-YVR-SEA does not match value D because every sector
in the portion of travel is not domestic (CHI-YVR and YVR-SEA sectors are not domestic).
Note the following exception:

• Travel between countries XU/RU is domestic.
Note for clarification:

• Travel between US and Canada is not domestic.
• Travel between countries in Scandinavia is not domestic.
• Travel between a nation and its territory possessing its own ATPCO Country Code is not domestic travel
(cabotage travel is not domestic).
• Travel between a nation and its territory not possessing its own ATPCO Country Code is considered part of the
sovereign state and is domestic
Value Blank: No restriction - Indicates that the sector/portion of travel being validated (depending upon the value in Indicator byte
146) may be domestic or international.
If the sector/portion of travel being validated meets the international/domestic requirement of byte 181, then processing matches the
record (provided a match is also made to all other match criteria). If the sector/portion of travel being validated does not meet the
international/domestic requirement, then processing no matches the record and continues to the next record.

S1document.

4.1.14 Carrier/Flight Application Table No. 186 (bytes 194-201)

These fields specify the carrier/flight requirements for the sector/portion of travel being validated. When the Sector/Portion of Travel
Geographic Specification fields (bytes 146-181) contain data, these fields validate against the sector/portion of travel that matches the
data in the Sector/Portion of Travel Geographic Specification fields. When the Sector/Portion of Travel Geographic Specification
fields is “blank”, these fields validate against the sector being processed.
When validating a sector (based on Sector/Portion Indicator byte 146 value Blank):
The carrier/flight requirements validate against the sector. If the carrier/flight on the sector matches the data in Table 186,
processing matches the record (provided a match is also made to all other match fields). If the carrier/flight on the sector does
not match the data in Table 186, processing no matches the record and continues to the next record.
When validating a portion of travel (based on Sector/Portion Indicator byte 146 value P):
The carrier/flight requirements validate against the portion of travel. All sectors within the portion of travel must match the
data in Table 186. If the carriers/flights on all sectors of the portion of travel match the data in Table 186, processing matches
the record (provided a match is also made to all other match fields). If the carrier/flights on all sectors do not match the data in
Table 186, processing no matches the record and continues to the next record.
Table 186 designates carriers and/or flight numbers/ranges that must be on the sector/portion of travel being validated. The table
consists of up to 50 recurring segments. The relationship amongst the fields, within a single segment, is AND. The relationship
amongst the segments is AND/OR. Processing must match at least one segment. A match of any one segment within the table is a
match for the sector/portion of travel being validated (provided a match is also made to all other match fields in the Record S1).
Additionally, a match to multiple segments within the table is a match for the portion of travel being validated (provided a match is
also made to all other match fields in the Record S1).
The following fields exist within each recurring segment in Carrier/Flight Table 186:
• Marketing Carrier (Table 186 bytes 10-12)
• Operating Carrier (Table 186 bytes 13-15)
• Flight No. 1 (Table 186 bytes 16-19)
• Flight No. 2 (Table 186 bytes 20-23)

Marketing/Operating Carrier Fields

The carrier code in the Marketing Carrier validates against the carrier code on the flight coupon(s) for the sector/portion of travel
being validated. As processing matches the Record S1 owning carrier against the marketing carrier on the sector/portion of travel
being validated, the only valid entry in the Marketing Carrier fields is the Record S1 owning carrier, carrier code, being validated.
Therefore, ATPCO’s coding convention holds that the Record S1 owning carrier will be entered as the marketing carrier. Edits
require that the marketing carrier must always be entered whenever a Table 186 segment is entered.
The carrier code in the Operating Carrier field validates against the carrier that provides flight service for the sector/portion of travel
being validated. The operating carrier for a specified portion of travel may be the same or different from the marketing carrier for
that same portion of travel. For example, in a schedule that shows a flight published under an ‘LH’ code from FRA to WAS, LH will
appear on the flight coupon; however, UA may actually provide the flight service from FRA to WAS, in this case LH is the marketing
carrier, and UA is the operating carrier. There is a hierarchy in scheduling that will allow pricing systems to determine the operating
carrier using Data Element Identifiers. When operating carrier is Blank, processing will assume that any operating carrier is
permitted.
Flight No. 1/Flight No. 2 Fields

Flight No. 1 may be a specific flight number or value ‘****’ indicating “any flight number.” Flight No. 2 may be a specific flight
number or blank.
When data is present in both flight number fields, the relationship between the two fields is THROUGH (apply as a range of flights
between Flight No. 1 and Flight No. 2).
Example: Flight No. 1 = 1000
Flight No. 2 = 1999
The data indicates that the sector/portion of travel must be on flight number 1000 through 1999.
When data is present in Flight No. 1 and Flight No. 2 is blank, Flight No. 1 applies as a single flight.
Example: Flight No. 1 = 1000
Flight No. 2 = blank
The data indicates that the sector/portion of travel must be on flight number 1000.

When Table 186 is value 000000 (blank), there are no restrictions on the carriers and flights on the sector/portion of travel being
validated (subject to the remaining data within the record).
S1document.

4.1.15 RBD (bytes 203-208)

These fields specify the RBD requirement for the sector/portion of travel being validated. When the Sector/Portion of Travel
Geographic Specification fields (bytes 146-181) contain data, these fields validate against the sector/portion of travel that matches the
data in the Sector/Portion of Travel Geographic Specification fields. When the Sector/Portion of Travel Geographic Specification
fields is “blank”, these fields validate against the sector being processed.
The RBD requirement validates against the sector. When one RBD is specified, the sector must be booked in the specified
RBD. When more than one RBD is specified, the sector must be booked in one of the specified RBDs. If the sector is booked
in the specified RBD(s), processing matches the record (provided a match is also made to all other match fields). If the sector
is not booked in the specified RBD(s), processing no matches the record and continues to the next record.
The RBD requirement validates against the portion of travel. When one RBD is specified, all sectors within the portion of
travel must be booked in the specified RBD. When more than one RBD is specified, all sectors within the portion of travel
must be booked in one of the specified RBDs. All sectors do not have to be reference the same RBD, rather they each must be
in one of the specified RBDs. If the portion of travel is booked in the specified RBD(s), processing matches the record
(provided a match is also made to all other match fields). If the portion of travel is not booked in the specified RBD(s),
processing no matches the record and continues to the next record.
When these fields are value Blank, there are no RBD restrictions for the sector/portion of travel being validated (subject to the
remaining data within the record).
S1document.

4.1.16 Equipment (bytes 209-211)

This field specifies the equipment requirement for the sector/portion of travel being validated. Data in this field can consist of an
ATPCO Equipment Code (refer to Automated Rules Appendix F – Equipment Codes) or blank (where “blank” signifies no restriction
on the equipment for the sector/portion of travel being validated).
When the Sector/Portion of Travel Geographic Specification fields (bytes 146-181) contain data, this field validates against the
sector/portion of travel that matches the data in the Sector/Portion of Travel Geographic Specification fields. When the
Sector/Portion of Travel Geographic Specification fields is “blank”, this field validates against the sector being processed.
The equipment requirement validates against the sector. Travel on the sector must be in the specified equipment type. If travel
on the sector is in the specified equipment type, processing matches the record (provided a match is also made to all other
match fields). If travel on the sector is not in the specified equipment type, processing no matches the record and continues to
the next record.
The equipment requirement validates against the portion of travel. Travel on all sectors within the portion of travel must be in
the specified equipment type. If travel on all sectors of the portion of travel is in the specified equipment type, processing
matches the record (provided a match is also made to all other match fields). If travel on all sectors of the portion of travel is
not in the specified equipment type, processing no matches the record and continues to the next record.
When this field is value Blank, there are no equipment restrictions for the sector/portion of travel being validated (subject to the
remaining data within the record).
S1document.

4.1.17 Fare Basis Code (bytes 212-226)

This field specifies the Fare Basis Code. Validation of this field is against the code that appears in the Fare Basis Box on the ticket.
If the data in this field matches the code in the Fare Basis Box on the ticket, processing matches the record (provided a match is also
made to all other match fields). If data in this field does not match the code in the Fare Basis Box on the ticket, processing no matches
the record and continues to the next record.
When validating a sector (Indicator value blank), the sector must match the specified fare basis code.
When validating a portion of travel (Indicator value P), every sector in the portion of travel must match the specified fare basis code.
In addition to alphanumeric, the following characters can also be present in bytes 212-226:
Slash (‘/’) Up to two slashes (‘/’) may be present in this field in order to identify ticket designator(s). When a single slash is
present, the slash and any alphanumeric following the slash match against the last ticket designator in the Fare Basis
Code (refer to Wildcards below). Match processing for a slash in bytes 212-226 against the Fare Basis Code is the
same as the match processing for an alphanumeric in bytes 212-226 against the Fare Basis Code. For example,
QHXAP/CH in bytes 212-226 matches QHXAP/CH in the Fare Basis Box, but does not match QHXAPCH in the Fare
Basis Box. QHXAP/ID/CH in bytes 212-226 matches QHXAP/ID/CH in the Fare Basis Box, but does not match
QHXAPID/CH or QHXAP/CH in the Fare Basis Box. Edits prohibit a slash as the first or last character in the field.
NOTE: The presence of two ticket designators may not be supported by all subscribers. Carriers should contact subscribers directly to
determine if this is supported.
Hyphen (‘-’) A hyphen is a wildcard value and represents any alphanumeric characters in the fare class portion of the Fare Basis
Code. Processing of the hyphen against the fare class portion is the same as processing the hyphen for the fare family
match against Automated Rules Record 2. The hyphen can never be used to match a slash (never used to match the
ticket designator/s).
Asterisk (‘*’) An asterisk is a wildcard value that represents any alphanumeric characters in the ticket designator. Up to 2 asterisks
are permitted. Edits only permit an Asterisk wildcard in bytes 212-226 when preceded (directly or indirectly) by a
Slash.
Refer to the rules on the following pages for applying the wildcard match process.
Rules for Applying the Wildcard (Hyphen/Asterisk) Match
• The hyphen will not be used to replace a number when the immediately following or preceding character in the Fare Basis Code
on the ticket is also a number
Examples: B-E70 does not match BE701, BE710 or BE170
BE-70 matches BEX70, BE1X70, but does not match BEX170
B-E70/CH does not match BE701/CH, BE710/CH, or BE170/CH
• When a hyphen is present with no slash, processing will only match Fare Basis Codes that have no ticket designator.
Examples: -E70 matches BE70, YNWE70 and Q123E70NR, but does not match BE70/CH, BAP/E70 or BAP/E70/CH
Q-CH matches QAPCH, but does not match Q/CH, QAPCH/ID90, and QAP/CH
Q- matches QAP7 but does not match QAP7/ID90, Q/CH, and QAP/CH
• The hyphen represents any single or consecutive alphanumeric string, except a slash
Examples: -CH matches QEECH, but does not match YAPCH/ABC or QEE/CH
-E70/CH matches BE70/CH and Q123E70/CH, but does not match YAP/E70/CH or YAP/BE70/CH
-/CH matches QEE7M/CH, but does not match QEE, QEE//CH, QEE/ABC/CH, or QEECH
Q-/CH matches QAP7/CH, but does not match QAP/ID90/CH or QAPCH
B-AP/CH matches BXAP/CH and BH123AP/CH, but does not match BXNR/AP/CH
In addition to the above rules, the following rules apply for hyphens:
• When the hyphen is in the beginning of an alphanumeric string:

If there is no slash:
o There is an assumed hyphen at the end.
Example: –E70 matches BE70NR and BE70NR50, but does not match BAP/E70NR or BE70NR/CH
o The hyphen must be replaced with at least one character and cannot be left blank
Example: –HE70 does not match HE70NR

If there is at least one slash:

o There is an assumed hyphen at the end, but prior to the slash.
Example: –E70/CH matches BE70NR/CH but does not match BE70/CH33, BE70NR//CH, or BE70N4/ABC/CH
o The hyphen must be replaced with at least one character and cannot be left blank
Example: –HE70/CH does not match HE70NR/CH
• When the hyphen is in the middle of an alphanumeric string:

o There is an assumed hyphen at the end.
Example: Q-AP matches QHXAP and QHXAPCH, but does not match QHEE/AP, QHAP/CH, or QEE/AP/CH
o The hyphen does not have to be replaced by any characters.
Example: Y-AP matches YAP and YHXAP
If there is a slash:
o There is an assumed hyphen at the end, but prior to the slash.
Example: Q-AP/CH matches QHXAP7M/CH but does not match QHAP/ID/CH or QAPNR/CH33
Example: Y-AP/CH matches YAP/CH and YHXAP/CH
• When the hyphen is at the end of an alphanumeric string:

Example: Y- matches Y and YR
If there is a slash:
Example: Y-/CH matches Y/CH and YR/CH
• When a single slash is present with no asterisk, the slash and all characters after the last slash are an exact match to the ticket
designator. There is no implied wildcard at the end.
Example: –AP/CH matches QAPNR/CH but does not match QAPNR/CH33 or QAPNR/ID/CH
• When two slashes are present, the last slash and all characters after the last slash are an exact match to the last ticket designator.
There is no implied wildcard at the end of a slash or at the end of the ticket designator.
Examples: Y–//CH matches YAP//CH and Y//CH, but does not match YAPNR/CH33 or YAP/ID/CH
Y-/ID/CH matches Y/ID/CH and YAP/ID/CH, but does not match YAP/ID90/CH or YAP/ID90/CH33
• When an asterisk is present, the asterisk may be replaced by any single or string of alphanumeric characters in the ticket
designator, including a slash. If the asterisk is preceded by at least one alphanumeric character, it can be but does not have to be
replaced. If the asterisk directly follows the slash, it must be replaced.
Examples: –AP/CH* matches QAPNR/CH, QAPNR/CH33, QAP/CH/ABC but does not match QAP/ID/CH or QAP//CH
Y/* matches Y/CH, Y//CH and Y/ID/CH, but does not match Y
Y//* matches Y//CH33, but does not match Y, Y/CH, or Y/ID/CH.
Y/*/* matches Y/ID/CH, but does not match Y, C/CH, OR Y//CH
Y–//CH* matches YAP//CH and YAP//CH33, but does not match YAP/CH33 or YAP/ID/CH
Y-/ID/CH* matches Y/ID/CH, YAP/ID/CH, and YAP/ID/CH33, but does not match YAP//CH or YAP/ID90/CH33
Y-/ID*/CH* matches Y/ID/CH, YAP/ID90/CH, YAP/ID90/CH33, and YAP/ID/CH33, but does not match YAP//CH
• The asterisk will not be used to replace a number when the immediately following or preceding character in the ticket designator is
also a number
Example: B-/AB3* matches BAP/AB3X, but does not match BEE/AB35
• Generic wildcard matching:

o -//* matches all Fare Basis Codes with ‘//’ (slashes must be adjacent).
Example: matches YAP//CH, but does not match YAP, YAP/CH, and Y/ID/CH
o -/* matches all Fare Basis Codes with one or more ticket designators.
Example: matches YAP/CH, YAP//CH, and YAP/ID/CH, but does not match YAP

When this field is value Blank, there are no restrictions on the Fare Basis Code (subject to the remaining data within the record).
S1document.

4.1.18 Service Fee (bytes 258-277)

The Service Fee fields consist of the following fields:
• Specified Fee (bytes 258-268)
• Percent (bytes 269-275)
• Tax Included (byte 276)
• Fee Application (byte 277)
Once processing matches all match criteria in the Record S1 being processed, these fields identify any applicable Service Fee.
4.1.18.1 Specified Fee (bytes 258-268)

These fields indicate a specific fee amount, decimal, and currency. If there is no fee (e.g. the Service Type Code is free), the data will
be expressed as Amount 0000000 with currency USD and the applicable decimal (e.g. 0.00 USD indicates “free’).
The fee data may be expressed in any currency (that is, it does not have to be in the currency of sale). Processing will attempt to
retrieve the currency of sale. If this currency is not present, processing will convert the specified amount/currency to the currency of
sale using the Bankers Selling Rate (BSR). Rounding procedures dictated by IATA Resolution 024d apply.
Edits require that when Fee Currency (bytes 265-267) is value Blank, then Percent (bytes 269-275) must be value 000.0001-999.9999.
Whether the fee applies per sector, per direction, or per journey (ticket) is dependent upon the data in the Fee Application field (byte
277).
S1document.

4.1.18.2 Percent (bytes 269-275)

This field indicates that when all travel on the ticket is wholly online, then the fee is a percentage of the Base Fare. This field is a
match/action field, requiring processing to first match the field, and then apply the percentage, as follows:
When Percent is value 000.0001-999.9999

In order to match the record, processing must first determine the marketing carrier on all sectors of the ticket.
• If the marketing carrier is the same on all sectors of the ticket, then processing matches the record (provided a match is also made
to all other match fields), and applies the percentage to the base fare (see definition). This is a simple calculation of multiplying
the percent by the Base Fare (no subtraction is implied).
• If the marketing carrier is not the same on all sectors of the ticket, processing no matches the record and continues to the next
record.
When Percent is value 000.0000

This field has no application. Any fee amount is found in the Fee field (bytes 258-268). Edits require that when Percent (bytes 269-
275) is value 000.0000, then Fee Currency (bytes 265-267) must contain data.
Whether the fee applies per sector, per direction, or per journey (ticket) is dependent upon the data in the Fee Application field (byte
277).
S1document.

4.1.18.3 Tax Included (byte 276)

This field specifies whether or not the tax is included in the fee (either specified or percentage). Following is an explanation of
applicable values:
Value X: The fee amount includes tax. Processing will not add further tax to the fee.
Value Blank: The fee amount does not include tax. Subscribers should apply any applicable tax information in their tax database to
the fee.
S1document.

4.1.18.4 Fee Application (byte 277)

This field dictates the application of Fee 1/Fee 2 (bytes 258-268) data. The following is an explanation of the applicable values:
Value Blank: Per Sector - Indicates that the fee applies per sector.
• When validating a sector (based on Sector/Portion Indicator byte 146 value Blank), the fee applies to the sector
being validated.
• When validating a portion of travel (based on Sector/Portion Indicator byte 146, value P), the fee applies per each
sector on the portion of travel being validated, as defined by the data in the Connection Exempt field (byte 179).
For example, if the fee is 7.00 EUR and the portion of travel contains 3 sectors, then the total fee for the portion of
travel is 21.00 EUR.
Value 1: Per Direction. Indicates that the fee applies once for each direction of travel on the journey for the identical
marketing carrier (owning carrier of the Record S1), Service Type Code (Tax Code and Sub-code), and Fee
Application value. Apply the highest amount per marketing carrier for the identical Service Type Code and Fee
Application value. Processing compares amount data in Record S1 (after converting to currency of sale as necessary)
in order to determine the highest amount.
Determination of outbound/inbound is based on whether the journey is a OW or RT journey (see definition), as

follows:
• For OW journeys, all travel on the journey is outbound.
• For RT journeys, all travel prior to the Journey Turnaround (see definition) is outbound. All travel after the
Journey Turnaround is inbound.
Processing takes the following steps:

1. After processing Record S1 for all sectors on the journey, determine all outbound and inbound sectors of the
journey.
2. For all outbound sectors:
(a) Group all fees for the identical marketing carrier, Service Type Code, and Fee Application value 1.
(b) Apply the highest fee from the group above once for all outbound sectors of the journey for each marketing
carrier.
3. For all inbound sectors:
(a) Group all fees for the identical marketing carrier, Service Type Code, and Fee Application value 1.
(b) Apply the highest fee from the group above once for all inbound sectors of the journey for each marketing
carrier. (Determination of the highest amount is based on amount and currency).
Value 2: Per Journey. Indicates that the fee applies once for the journey (ticket) for the identical marketing carrier (owning
carrier of the Record S1), Service Type Code (Tax Code and Sub-code), and Fee Application value. Apply the highest
amount per marketing carrier for the identical Service Type Code and Fee Application value. Processing compares
amount data in Record S1 (after converting to currency of sale as necessary) in order to determine the highest amount.
Processing takes the following steps:

1. Group all fees on the journey for the identical marketing carrier, Service Type Code, and Fee Application value 2.
2. Apply the highest fee from the group above once for the entire journey for each marketing carrier
S1document.

4.1.19 Text Table No. 196 (bytes 278-285)

Data in this Table is provided for text purposes only and has no impact on automated processing.

5.0 TRAVEL SEGMENT INDICATORS

Travel Segment Indicators (TSIs) are not applicable in Record S1.

6.0 CODING CONVENTIONS
• Record S1 sequences should be entered in order of the most specific data to the least specific data (where the more specific data
has a lower sequence number than less specific data). Following are some guidelines:
• When entering data in Carrier/Flight Table No. 186, the Marketing Carrier field must contain the owning carrier code for the
Record S1.
• If the carrier instructs a per OW and per RT fee, enter the data as follows
Per OW Fee - Create a Record S1 with all applicable match criteria and include the following information:
o Return to Origin byte 69 value N (travel must not return to the journey origin)
o Fee Application byte 277 value 2 (per journey)
Per RT Fee - Create a Record S1 with all applicable match criteria and include the following information:
o Return to Origin byte 69 value Y (travel must return to the journey origin)
o Fee Application byte 277 value 2 (per journey)

YQYR RecS1 Dapp C

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

YQYR RecS1 Dapp C

Uploaded by

Copyright:

Available Formats

DATA APPLICATION

CARRIER-IMPOSED (YQ/YR) FEES RECORD S1

Copyright ©2005 by Airline Tariff Publishing Company

1.0 OVERVIEW .............................................................................................................................................................................................................................. 3

Revised April 2014

4.1.14 Carrier/Flight Application Table No. 186 (bytes 194-201) ...................................................................................................................................... 49

Revised April 2014

1.1 Data Requirements

• Departure date from the origin of the journey

Page E.03.S1.03 Revised April 2014

1.2 Basic Processing Overview

Process Record S2 (Services Concurrence Record)

Did the S2 Process return any carriers (including

Process Record S1 (Services Record) for

For each sector, attempt to match Record S1

Page E.03.S1.04 Revised April 2014

2.0 DEFINITIONS AND ASSUMPTIONS

Page E.03.S1.05 Revised April 2014

Page E.03.S1.06 Revised April 2014

3.0 DETAILED FIELD PROCESSING

Byte Location Match / Action Definition / Processing

Page E.03.S1.07 Revised April 2014

Byte Location Match / Action Definition / Processing

Byte Location Match / Action Definition / Processing

Page E.03.S1.09 Revised April 2014

Byte Location Match / Action Definition / Processing

Page E.03.S1.010 Revised April 2014

Sector vs. Portion of Travel

Page E.03.S1.011 Revised April 2014

Surface sectors are not validated against Record S1

Page E.03.S1.012 Revised April 2014

4.1 Application of Data for Record S1

4.1.1 Carrier Code (bytes 3-5)

Page E.03.S1.013 Revised April 2014

4.1.2 Service Type Code (bytes 6-10)

Field Explanation Applicable Values

NOTE: At a future date, “OC” will be the only valid

Page E.03.S1.014 Revised April 2014

4.1.3 MCN (bytes 21-29)

Page E.03.S1.015 Revised April 2014

4.1.4 Sequence Number (bytes 29-35)

Page E.03.S1.016 Revised April 2014

4.1.5 Travel Dates – Effective/Discontinue (bytes 37-48)

Page E.03.S1.017 Revised April 2014

4.1.6 Ticket Dates (bytes 49-60)

Page E.03.S1.018 Revised April 2014

4.1.7 Carrier Application Table No. 190 (bytes 61-68)

Page E.03.S1.019 Revised April 2014

4.1.8 Return to Origin (byte 69)

Page E.03.S1.020 Revised April 2014

4.1.9 Passenger Type (bytes 70-72)

Page E.03.S1.021 Revised April 2014

4.1.10 Point of Sale (bytes 75-96)

4.1.10.1 Point of Sale – Geographic Specification (bytes 82-90)

Page E.03.S1.022 Revised April 2014

4.1.10.2 Point of Sale – Code (bytes 91-99)

Value T: Pseudo City Code – Travel Agency

Value I: IATA Travel Agency Number

Page E.03.S1.023 Revised April 2014

4.1.11 Point of Ticketing – Geographic Specification (bytes 100-108)

Page E.03.S1.024 Revised April 2014

4.1.12 Journey Geographic Specification (bytes 109-145)

4.1.12.1 Journey Geo Spec – Indicator (byte 109)