In order to validate the Flight Application Category, it is essential to know the following:

• The direction of travel on the fare being validated
• All flight numbers
• All points on the ticket
• All points within the line of flight (hidden or unticketed points)
• All types of equipment being used for the travel.
• Marketing and Operating carriers on each sector
• Tariff applicable to the fare component being processed (for RTW/CT fares)

ATPCO has defined how to validate Operating Carrier for the purposes of ATPCO Automated Rules Flight Table 986, which in turn is used to define eligible carriers in Category 4 – Flight Application, and in Record 8 –Fare By Rule Application.

The Operating Carrier is:

The carrier who owns the schedule record (SSIM file) unless that record contains a value in the DEI050 field which identifies the operating carrier of the segment. DEI050 [Duplicate Leg Reference – Operational Leg ID] is a data element found in a SSIM file (Standard Schedules and Information Manual). In order to use this product, carriers should file the operating carrier (and operating carrier flight number) in the DEI050 of the schedules record (as opposed to the DEI027). (ATPCO will add this recommended practice to the reference manual for this product.) If carriers do not file a value in DEI050, systems will assume the marketing carrier and flight number are the same as the operating carrier and flight number.

Travelport 360 Fares relies on DEI050 and the Airline Designator to determine the Operating Carrier for validation of ATPCO Table 986 in Category 4 and Record 8.

• If the flight schedule contains a DEI050, then the carrier shown in that data element is considered to be the Operating Carrier.
• If the flight schedule does not contain a DEI050, then the carrier shown as the Airline Designator is considered the Operating Carrier.

This category can be validated per fare component or per pricing unit. If validated as a fare component, each portion between fare breaks is validated. If validated as a pricing unit, the whole journey is validated.

Assumptions

In the absence of Category 4 (Record 2 for Category 4 does not exist or no Category 4 Record 3 is applicable within the string), the system assumption for Category 4 – Flight Application is that there are no flight restrictions other than those specified within the routing or transfer category.

The assumption for applying the Flight Application conditions is by fare component. The fare component is dependent upon itself to validate the provisions, except when Byte 60 (Outbound/Inbound Indicator) contains a value of 3, 4, or 5. When Byte 60 contains a value 3, 4, or 5, Flight Application conditions apply by pricing unit; to validate a fare component, it may be necessary to know information about the other fare component(s) within the pricing unit.

Category 4 Flight Application provides the capability to state flights operated by one carrier but marketed by another carrier. Category 4 also provides the ability to identify all carriers that may or may not participate on a given fare component. Pricing Analysts should always discuss with their Scheduling Analysts how a codeshare flight was filed prior to coding any Category 4 data that may be specific to the operating carrier.

Recommended Filing

Analysts should review each fare with Category 4 provisions to ensure the flight application restricting the use of a fare meets with the carrier’s intent. If the category is not coded carefully, the fare may be used for flight applications that the carrier does not intend to permit. Pricing Analysts should always discuss with their Scheduling Analysts how a codeshare flight was filed prior to coding any Category 4 data that may be specific to the operating carrier. If the scheduling department has opted to not file the operating carrier’s two letter carrier code in the DEI050 field of the flight’s SSIM file, the pricing analyst is not able to use the two letter operating carrier code in Category 4 Flight Application.

CODING CONVENTIONS

• When multiple Record 3 tables are identified with a relational indicator of AND:
• For all tables that match based on the Application/Via Indicator value ‘2” (bytes 61 or 79), all information for only those matched tables within the set must apply for the fare component being validated.
• When multiple Record 3 tables are identified with a relational indicator of OR or THEN, each table is independent of the other(s). That is, only one table applies for the fare component being validated.
• When a flight number restriction is instructed without a carrier code, enter the Record 2 owning carrier code in the carrier field. For example, BA instructs that all travel must be on flight 200 or 201. ATPCO will enter that all travel must be on BA flight 200 or BA flight 201.
• When an operating carrier is instructed and the marketing carrier is not instructed, enter the Record 2 owning carrier in the corresponding marketing carrier field in Carrier/Flight Table No. 986.
• Nonstop (byte 89) service restriction should not be entered in the same Record 3 table as a Geo Spec Table with a Via application (e.g. do not enter “must be via NYC on nonstop flights”).
• TSIs should not be used to indicate a last point out/first point in application for the geographic locales. The application of the geographic locales is already defined as last point out/first point in, and use of a TSI may cause the data to pass or fail incorrectly. For example: the fare component must contain a portion of travel between US and Europe. Processing will validate the portion of travel between the last point out of the US and the first point into Europe, and vice versa. TSIs are not needed to reflect this application.
• Edits prevent entering a negative Geo Spec Table (value 0 in Byte 61 or 79) with negative flight application (negative flight number, carrier, type of service, equipment code) within the same table. If necessary to enter this type data, it must be coded in two tables.