Cat25 - Fare By Rule

Carriers may use ATPCO automated Category 25 to create public or private world wide Fare by Rule fares for distribution, sales, and ticketing.

Customers can create selling fares based upon airline net fares. The net fares can be specified fares or net fares created using Category 25. The base fares referenced on the 989 Base Fare Table or the resulting Category 25 display must be C

Record 8

Record 8 is the starting point for the Fare by Rule process. It is the necessary link between a passenger’s itinerary and the matching Category 25 data. The data coded in the Record 8 MUST match the associated data coded in Category 25.

Each Record 8 ID must include:

Primary Passenger Type Code of resulting fares being created
Specific geography of resulting Category 25 fares being created
Directional indicator of resulting Category 25 fares (if applicable)
Account code of resulting Category 25 fares (if applicable)

Add the Cat19-22 Discounted PTC in the Fare By Rule Index (Record 8)

Cat19

Record8

Stringing Logic

Fare by Rule string processing differs from other categories in the Automated Rules Product as follows:

Record 3 for Category 25 can only be used as a main category. This Category can never be used as an IF condition, nor can it be used with AND or OR in the IF portion of a set.
Edits prevent AND tables for Category 25.
When processing matches a Record 3 with No Discount (Byte 59) value X, a fare by rule cannot be created according to the table. Processing will not continue to another Record 3.
When processing matches a Record 3, processing will create the fare(s) according to the table, and processing will continue to another table (including OR tables) attempting to match and create another fare (unless Byte 59 is value X).
When processing matches the IF portion of a set, processing will attempt to match and apply the THEN portion. Processing will continue to another set attempting to match and create another fare (unless Byte 59 is value X).
Refer to Category 25 Record 2 Data Application for detailed explanation and examples of string processing.

Primary Passenger Type Code

The Record 8 Primary Passenger Type Code is an exact match to the Category 25 Resulting Fare Passenger Type Code that will be coded in the Category 25 Record 3 table.

360˚ Fares™ supports all ATPCO Passenger Type Codes.

Specific geography

Geography must be coded on every Record 8.

ATPCO has introduced Table 978 User Defined Zone Tables that can be utilized in Record 8. User Defined Zone Tables allow for specific city codes to be coded within a single User Defined Zone Table that can be used in multiple Category 25 rules. This allows for carriers to code their online destinations, thus eliminating any markets from having Category 25 fares created when they would not be applicable. 360˚ Fares™ strongly encourages carriers to utilize Table 978 where ever applicable. As many U.S./Canada transborder contracts are valid for online destinations only, 360˚Fares recommends that the zone tables are utilized when there are only a few transborder destinations serviced by the filing carrier.

Record 8 processing can be coded for IATA defined City Codes. Airport codes cannot be processed. If an airport code is coded, 360˚ Fares™ will not match to that location. Should a Fare by Rule fare be unique for a specific airport code, utilize Category 4 Flight Application in the Fare by Rule Fare to validate against the airport code.

Directional Indicator

The Record 8 Directional Indicator should be used when fare selection discounts fares in a single direction. For example, the specific geography filed is LON to HKG; however the Category 25 calculation is for fares originating LON only. The directional indicator in Record 8 should be coded.

Qualifying Account Code

This is optional and can be up to 20 alpha numeric characters where the first character must be an alpha. If an account code is to be used in the Fare by Rule, the account code should also be coded in the Record 8 but it is not mandatory. A Record 8 with a BLANK Account Code will match all Account Codes.

It is the agency who should request, or at least be aware of the account code that the carrier will use.

A good example of multiple Account Codes is below

Travelport processes automatically any account code filed/coded in ATPCO, without any further action. The only requirement is that the agency is made aware of that account code.

Qualifying Ticket Designator

360˚ Fares™ does not support this field as the functionality is similar to the Qualifying Account Code. Any data coded as the Qualifying Ticket Designator will be the indicator that that speciRecord 8 is not valid for a360˚ Fares™ customer. The Qualifying Ticket Designator in Record 8 is not used for final ticketing of the Fare by Rule. That information is obtained from Category 35 or Categories 19-22 or Category 25 Record 3. Category 25 Record 2

Passenger and Record 8 data are used to match the Cat 25 Record 2. Category 25 Record 2 points to the applicable Category 25 Record 3 data which contains the information necessary to create the fare.

Loc 1 and Loc 2

Each Category 25 Record 2 should be coded with the broadest geography applicable utilizing 978 Zone Tables in the LOC fields whenever possible.

Category 25 Record 2 processing can be coded for IATA defined City Codes. Airport codes cannot be processed. If an airport code is coded, 360˚ Fares™ will not match to that location. Should a Fare by Rule fare be unique for a specific airport code, utilize Category 4 Flight Application in the Fare by Rule Fare to validate against the airport code.

Category 25 Record 3

The Category 25 Record 3 string should be kept as short as possible. Utilize Wildcard Resulting Fare Codes if needed. 360˚ Fares™ recommends not exceeding 25 Record 3 tables within a single Record 2 sequence.

Resulting Passenger Type Code

The Resulting Passenger Type Code must be an exact match to the Record 8 Primary Passenger Type Code. The Resulting Passenger Type Code must also be an exact match to the Passenger Type Code found in Category 1 Eligibility if applicable.

If a self-booking engine is processing the Category 25 fares, the resulting passenger type code must ‘ADT’.

Resulting Display Category

Display Category Type value L, T, or C identifies that the Resulting Fare is a Negotiated Fare and specifies whether the Resulting Fare amount is a Selling Fare amount of a Net Fare amount. Category 35 is only interrogated if a Display Category Type value L, T, or C is present.

Display Category Type values E, S, N, G, or I identify that the Resulting Fare is not a Negotiated Fare. They are defined as follows: E = Excursion, S = Status, N = Normal, G = Group, I = Inclusive tour package. When any of these display category type values are present, Category 35 will not be interrogated.

360° Fares™ recommends that the Resulting Display Category Type always be coded in the Record 3, provided this does not increase the number of Category 25 Record 3 tables.

Resulting Pricing Category

The types valid are N = Normal fare, S= Special fare. The N or S further defines the fare as a Normal or Special which may be needed to during combinability.

360° Fares™ recommends that the Resulting Pricing Category always be coded in the Record 3, provided this does not increase the number of Category 25 Record 3 tables.

Resulting Fare Wildcard

360˚ Fares™ supports the ATPCO enhancement for filing a wildcard asterisk (*) in order to create a new resulting fare class code. This enhancement will combine the first character of the base fare class code with the characters that follow the asterisk.

For example:

Category 25 Record 3 Resulting Fare Class is coded *WEB.

Base fare class code is Q1R.

Result:

The created Category 25 fare class code would be QWEB.

Resulting Routing

360˚ Fares™ supports the ATPCO enhancement for wildcard routings. This allows the vendor to apply any published routing or any published routing and MPMs (for international fares only).

Category 25 Category Overrides

The individual category fields specify whether processing must validate fare rule and general rule data for the Fare by Rule only, the Base Fare only, or both. Valid entries in each of the category fields follow:

X = Fare by Rule only.

Processing should only validate the Fare by Rule fare rule and general rule data for the specified category. The Base Fare fare rule and general rule should not be validated.

B = Base Fare only.

Processing should only validate the Base Fare fare rule and general rule data for the specified category. The Fare by Rule fare rule and general rule should not be validated.

Blank = Fare by Rule and Base Fare.

Processing should validate the fare rule and general rule data for both the Fare by Rule and the Base Fare for the specified category.

360˚ Fares™ processes each of the individual category fields per ATPCO specifications. All base fare rule data and override rule data is processed as automated rule data.

989 Base Fare Table

360˚ Fares™ recommends that the base fare tariff, carrier, and passenger type code are always coded in every 989 Base Fare Table. When coding a private base fare tariff, 360˚ Fares™ strongly recommends that the applicable fare code(s) are always coded.

Both positive and negative applications are permitted in the 989 Base Fare Table. When both positive and negative applications are to be coded, all of the negative applications must be sequenced before any positive applications. 360˚ Fares™ will not process the 989 table if negative applications are mixed in with positive applications.

Security

360˚ Fares™ supports both the use of Category 15, as well as Category 35 for security purposes.

If the resulting Category 25 fares have both Category 15 and Category 35 present, 360˚ Fares™ will process the security data in Category 35, and the security and the non-security data in Category 15. However, it is strongly recommended that security always be coded only in the resulting FBR rule and not in the base rule.

Category 25 Creation of Category 35 Fare

360˚ Fares™ supports the use of resulting Display Category value of L, T, or C. Fares with these values are:

L - Identifies the Negotiated Fare amount filed as a Selling fare amount.

T - Identifies the Negotiated Fare amount as a Net fare amount with a specified or calculated Selling fare amount in Category 35 Table 979.

C – Identifies the negotiated fare amount filed as a net fare amount.

The selling fare amount requires updating for at least one seller. This code is used when the selling fare amount is not addressed in category 35 table 979 or is defined as a range in Category 35 table 979.

International Fare Construction Principles

MPM surcharges and will be applied to Category 25 Fare by Rule fares if applicable.

HIP checks will be applied to Category 25 Fare by Rule fares when a ‘B’ is found in the Category 17 field of the rule override screen.

Per industry agreed upon standards, the IATA Fare Construction Principles are not applied to Private Category 25 Fare by Rule fares or published private fares.

Those principles include:

One Way Backhaul, Directional Minimum Check, Differentials, Country of Origin Minimum check, Normal Fare check, Return Subjourney Check, Common Point Minimum, Circle Trip Minimum, and Country of Payment Check.

The following Category 25 fields are not supported by 360˚ Fares™:

Record 8:

Carrier *J for Joints; *M for Multilateral

Carrier YY for IATA fares

Joint carrier table 997

TSI (Travel Segment Indicators)

Category 25 Record 2: