Cat35 - Negotiated Fares

To view how to troubleshoot missing CAT35 fares click here

Overview

The Negotiated Fare Product brings organization and more control to the creation, distribution, and implementation of negotiated fares. The design utilizes the current fare system, Fare By Rule product (to include Record 8, Category 25 and Table Number 989), Category 35 – Negotiated Fare Restrictions, Security Table 983, and Fare Creator Table 979. The design enables a carrier to file negotiated fares based on specific markets or zones, with restricted sale and distribution. The negotiated fare has multiple fare levels associated to it: the net amount remitted to the carrier, the selling fare level, and the gross or ticketed fare level. In addition, the negotiated fare level has the associated commission and ticketing requirements for the fare.

This design includes utilizing both the current fare system and automated rules system to allow for the distribution of negotiated fares and rule provisions. Category 35 – Negotiated Fare Restrictions was created to accommodate this design. Category 35 holds all the Negotiated Fare Restrictions information for both filed negotiated fares and negotiated fares created through the Fare By Rule product. The Category includes these three parts:

1. Security (Table Number 983) – who can or cannot view, update, redistribute, sell, and/or ticket (including reissue) the negotiated fare after it has been distributed to the applicable subscribers.

2. Fare Calculation (Fare Creator Table Number 979) – the ability to create the other level of the fare (either Net Submitted Fare Amount or Selling Fare Amount).

3. Commission and Ticketing Requirements.

Coding Conventions

• Sequencing:

  • Sequence from most restrictive to least restrictive.
  • Negative sequences should be followed by positive sequences within equal restrictive data.
  • At least one positive sequence is required.

If discounts apply based on Categories 19-22 and Table 979 specifies a selling amount, the associated Category 35 Record 3 should have data in the PTC field (bytes 22-24) indicating that the data in Table 979 only applies for a specified PTC. If data is not in the PTC field, then the specified selling amount in Table 979 applies to all PTCs, regardless of discount data in Categories 19-22

  • When Display Category is value L, Table 979 must not contain a selling amount (Table 979 is not required; however, if present, it must contain a net amount). Table 983 must contain Update (byte 49) value N.
  • When Display Category is value T, Table 979 must contain a specified or calculated selling amount (ranges are not permitted). Table 983 must contain Update (byte 49) value N.
  • Display Category value C is required whenever Table 979 contains a range selling amount and Table 983 Update (byte 49) is value Y. Value C is used when the selling amount for at least one fare requires updating.

Processing Laws for Display Category Type

  • If Display Category Type code is not L, T, or C (not a negotiated fares Display Category Type), Category 35 has no application. Do not attempt to process any data in Category 35. (Even if data exists in Category 35 that may resolve to the fare being processed, this data is not applicable and should not be applied.)
  • If Display Category Type code is value L the following is valid:
    • Applicable Table 979 with net amount and Table 983 without update authority
    • No applicable Table 979
  • If Display Category Type code is value T the following is valid:
    • Applicable Table 979 with specified/calculated selling amount and Table 983 without update authority
  • If Display Category Type code is value C the following is valid:
    • Applicable Table 979 with range selling amounts and Table 983 with update authority
    • Applicable Table 979 with specified/calculated selling amount and Table 983 without update authority
    • No applicable Table 979 and Table 983 with update authority
  • If Table 983 permits update authority (Update byte 49 is value Y), then the Display Category Type must be value C.
    • Invalid data may result in a fail condition (refer to the examples below).

NOTE 1: The application of the negotiated fares Display Category Type in relation to Category 35 data only applies to subscribers that process Category 35. Subscribers that do not process Category 35 may still receive Record 1s with any of the Negotiated Fares Display Category Types in which case the subscriber should process Category 15 instead of Category 35.

NOTE 2: In public tariffs, edits prevent entering Category 35 data, and edits prevent entering negotiated fares Display Category Type values.

When security restrictions, fare calculation, Method Type, commission information, and/or ticketing information are differentiated by the point of sale, use the relational indicator IF to Category 15 to specify the point of sale point.

  • Sequence from most restrictive to least restrictive.
  • When Table 979 is present but not matched, processing will fail the Category 35 Record 3 table; therefore, once geographic data is present in a sequence, a higher numbered sequence and/or another Category 35 Record 3 is required to encompass all other applicable origin/destination points for the fare.
  • When Net/Selling Indicator (byte 51) is value N (Net Submit Fare), Display Category Type must be value L (filed fare is a selling fare). If not value L, fail.
  • When Net/Selling Indicator (byte 51) is value S (Selling Fare), Display Category Type must be value T or C (filed fare is a net submit fare). If not value T or C, fail
  • When a range is specified, Table 983 Update (byte 49) must be value Y.

When Category 35 is present, Higher Intermediate Point (HIP) checks only apply when all of the following conditions apply:

  • The fare is a private Fare by Rule created via Category 25.
  • The Fare by Rule is a calculated Fare by Rule and the base fare is a public fare.
  • The Fare by Rule Category 17 Override field is value B.
  • Display Category Code for the Resulting Fare is type L (selling fare amount)
  • Category 35 Table 979 does not contain a net fare amount.

Refer to Data Application for Category 25 Fare by Rule for detailed information on the application of HIP checks for Fare by Rules.

  • When Method Type (byte 33) is value 2, 3, or 4, Tour Code/Value Code/CAR Code Type byte 105 must be value T or C.
  • When data is present in Ticketing Carrier Restrictions Indicator (byte 98), data must also be present in Carrier (bytes 100-102). When data is present in Indicator (byte 98) and Carrier (bytes 100-102) is blank, the application of data is the same as if all Carrier Restrictions fields were blank (bytes 100-102 were blank): ticket issue is not restricted to the owning/publishing carrier plate or stock or any other carrier plate or stock
  • Data on the audit coupon and data on the passenger coupon is the same unless specifically instructed/coded otherwise by the carrier.
  • When Ticketed Fare Data Indicator (byte 136) is value A or B, data should not be present in Fare Box bytes 173-194. If data is present in Fare Box bytes 173-194, then Fare Box data overrides the data in the Indicator field, and the data in the Fare Box field will be placed in the Fare Box on the ticket.
  • When data is present in Ticketed Fare Data bytes 136-172, data must also be present in Indicator byte 136. If data is not present in Indicator byte 136, then processing does not know whether to retrieve the fare class only or the fare class and the associated fare amount. In this case, the data in bytes 136-172 has no application. The Fare Class Code for the fare being processed should be placed in the Fare Basis/Ticket Designator Box on the ticket. The Selling Amount for the fare being processed should be placed in the Fare Box on the ticket, unless otherwise specified in Fare Box bytes 173-194

Commission

On the Galileo system, CAT 35 Commission is part of the CAT 35 Net Ticketing Functionality.

If a pcc is not activated to CAT 35 Net Ticketing Functionality (AAT field NGGF-N), the commission filed in

CAT 35 is not applied. Instead the commission from the default Galileo Commission table is applied.

If commission is filed via Airline Private Fares Category 35 and/or APF Private Fares then the following logic is applied:

· If commission information exists and “matches” then it can not be changed or overridden.

· If commission information does not exist then it can be added / modified.

· If commission information exists but does not match, i.e. conflicts, then it can be added or modified.

· If commission is absent then the user can modify or add or the system will go to default values that are applicable by airline/fare/market.

CGCTD/CXX (XX = Carrier code) wil list them all for Galileo

 

Activation of the NGGF field is not actually the turning on/off of CAT35 fares in a market.It is a setting in a customer PCC relating to the display of specific data.

If a CAT35 fare is filed in a PCC that has Private Fares capability then the fare would display/price with or without NGGF activated.

The commission filed in a CAT35 would however not be applied to tickets issued in the PCC if NGGF is not activated. The default commission from the country table would be applied.

*** MANUAL INPUT NEEDED BEFORE TICKETING ***

This error occurs when there is a commission conflict within CAT35. For example two fares are combined and the first one has 0% and the second one has no commission or any value other than 0%

When ticketed together this is considered a commission conflict and requires the commission be entered manually.

The Net Ticketing Detail Screen would reflect:

COMMISSION: *** MANUAL INPUT NEEDED BEFORE TICKETING ***

LYSRAI: 000.0000 PCT

SIDLYS: 000.0000 PCT

The commission would need to be entered manually at the time of ticketing or System processing then applies the commission from the Default Commission Table.

360°Fares™ Security Processing for Negotiated Fares

360° Fares™ supports both the use of Category 15 and Category 35 for security purposes.

Display Category Type values E, S, N, G, or I identify that the Resulting Fare is not a Negotiated Fare. When any of these display category type values are present in the Record 1 or Category 25 Record 3 table, Category 35 will not be interrogated.

Display Category Type value L, T, or C identifies that the Fare is a Negotiated Fare. Category 35 is only interrogated if a Display Category Type value L, T, or C is present in the Record 1 or Category 25 Record 3 table.

Should both Category 15 and Category 35 be present in the fare rule and Display Category Type is L, T, or C, 360° Fares™ will process the security data in Category 35 and the non-security data in Category 15.

For Negotiated Fares processing, the security found in Category 35 983 table must pass. Should Category 15 also exist in the same rule where Category 35 processing has passed, processing will continue to Category 15 where non-security will be validated and surety data will be ignored.

*Rule validation processing will continue when Category 35 passes validation and Category 15 does not fail validation. A result of Pass or No Match will continue processing. A result of Fail would stop processing and prevent the fares from being created for fare quote and fare display.

Category 15 data as an IF from CAT35

Should both Category 15 and Category 35 be present in the fare rule and Display Category Type is L, T, or C, 360° Fares™ will process the security data in Category 35 and the non-security data in Category 15.

DATA APPLICATION FOR NEGOTIATED FARE RESTRICTIONS – CATEGORY 35

Page E.03.35.025

4.1 Application of Data for Category 35 – Negotiated Fare Restrictions:

4.1.1 Security Table Number 983 – Bytes 14-21

The Security Table Number 983 data is carrier-instructed information located at the Category 35 – Negotiated Fare Restrictions level. When a Record 3 Category 35 is present, Security Table Number 983 data is required. The Security Table Number 983 identifies by whom and where the negotiated fare can or cannot be viewed, updated, redistributed, sold (booked), and/or ticketed (including reissued) after it has been distributed to the subscribers. All data within the Security Table Number 983 must be positively validated before processing the remainder of Category 35. When applicable security data is present in both Category 35 and Category 15 (Fare Rule, General Rule, and/or Footnote level/s), Category 35 is used for all security information, and only the non-security portion of Category 15 is validated (this applies when Category 15 is used as a Main Category). However, when Category 15 is used in the IF portion of a set (used as a Qualifying Category) in any main category, all fields are validated in Category 15, including security data (e.g. THEN Cat 5 IF Cat 15; in this case, all fields in Category 15 are validated).

NOTE: If a subscriber does not process Category 35 data, they will apply security information from Category 15 instead.

The following fields in Category 15 are considered the security portion of the category and will not be validated when both Category 35 and Category 15 (Fare Rule, General Rule, and/or Footnote) are present as a Main categories:

Passenger Types in Category 35

For published fares, when using a passenger type in Category 35 to associate security and/or other Category 35 features such as tour code to certain passenger types, all applicable passenger types must also be coded in the Record1 of the published fare. If ADT applies, include ADT as the last passenger type in the Record 1. If the passenger type field in Record 1 is left blank and all the records in Category 35 have passenger types coded, the desired result will not be achieved.

Definitions

ARC: Airline Reporting Corporation – calculates airline and travel agency shares of ticketing transactions for fares sold in the United States.

BSP: Billing and Settlement Plan – calculates airline and travel agency shares of ticketing transactions for fares sold outside of the United States.

CAR Code: Commercial Agreement Reference – An agreement between specific airlines and agents used in Net Reporting.

Duty Code : Job function of the person pricing the fare, as defined by the subscriber. May be the same as a Function Code.

Function Code: Job function of the person pricing the fare, as defined by the subscriber. May be the same as a Duty Code.

Gross (Ticketed) Fare Amount: A filed published or private fare (the amount shown in the Base Fare Box of the passenger coupon).

Home Agency: Specified Pseudo City Code or IATA Travel Agency Number to which other Pseudo City Codes or IATA Travel Agency Numbers are associated as subsidiaries/affiliates.

HOT: Hand Off Tape. Airline Accounting/Sales data. Contains all agent automated or manual transactions exclusive to a carrier.

Net Submit Fare Amount: The amount a carrier is willing to accept from the agency (or consolidator) for the negotiated fare.

Owner Agency: The agency for whom the Secondary Seller Control ID No. Table 980 is created. Just as the Record 2 carrier is the owner of Table 983, each Table 980 has an Owner Agency. The Owner Agency is given authority by the owning carrier of Table 983 or by another Owner Agency in a previous Table 980 level.

Redistribute: Further distribute a fare beyond the initial list of receivers identified by the carrier.

RET: Agent Reporting data - Agent reporting process.

Secondary Seller: An entity other than the owning carrier authorized to markup a fare amount and/or redistribute the fare.

Selling Fare Amount: The amount a passenger pays the agency (or consolidator) for the negotiated fare. This amount is equivalent to the base fare filed with ATPCO today for a published fare.

Subsidiary: Location affiliated with a home agency.

Value Code: Indicates the calculation method used in Net Reporting. Each character may represent an encoded value as determined by the carrier and/or ticketing agent.

Child & Infant & Other PTC Filing

When filing a Private Fare with discounts for any PTC other than ADT it is mandatory to file an IF CAT1 table for each PTC.

A Passenger type of ADT in Category 1 does not match ALL passenger types; it only matches ADT. Therefore, when category 35 is filed with an IF to Category 1 for a passenger type and, if applicable, account code and other associated PTCs (i.e. CNN, INF) are also eligible for the fare, the string must contain an OR Category 1 for each passenger type. An OR CAT01 is needed for all the primary passenger types in Record 1/Record 8/Category 25 and the secondary passenger type found in C19-22 that are eligible for the private fare.

Example

THEN Category 35 – passenger type blank

IF Category 01 – passenger type ADT account code TEST

OR Category 01 – passenger type CNN account code TEST

OR Category 01 – passenger type INF account code TEST

OR Category 01 – passenger type INS account code TEST

OR Category 01 – passenger type UNN account code TEST

 

When you file a specific PTC processing will only match that PTC

QUOTE

DATA APPLICATION FOR NEGOTIATED FARE RESTRICTIONS – CATEGORY 35

4.1.2 Passenger Type Code – Bytes 22-24

When the PTC field is value Blank or ADT, processing will match to any passenger type for which the fare is being priced.

UNQUOTE

This section includes data that will determine how the ticket is issued and reported to the BSP.

 

§ The plate and/or stock to be used for ticketing. (360° Fares™ makes no distinction between plate and stock.)

§ BSP Method

§ Commission data for the BSP

§ Audit and Passenger Coupons: The following data can have up to two occurrences/sequences; one for the audit coupon and one for the passenger coupon.

o Ticket Designator

o Fare Box Data

o Fare Class / Fare Family

o Tour Code

§ C = CAR (Commercial Agreement Reference) Code. An agreement between specific airlines and agents used in Net Reporting.

§ V = Value Code. A one alpha character indicating the calculation method type used in Net Reporting.

§ B = CAR Code and Value Code (separated by a ‘/’)

§ T = Tour Code. Any other type (i.e. Contract Code)

 

Note: Ticket Designator and Tour Code (type 'T' only) are currently processed for category 35 using current Airline Private Fares functionality. Tour Code types 'C', 'V', and 'B' and all other Audit and Passenger Coupon data is currently processed by 360° Fares™ for customers activated to our Net Ticketing product.

All of the Category 35 ticketing information is available in a Fare Display Follow-on entry,

Apollo®: ►FD#/NET

Galileo®: ►FD*#/NET

(where # is the fare display line number)

 

The user can manually update the ATFQ(1V) or Filed Fare(1G) with the appropriate ticketing modifiers.

1The BSP Reporting Method is controlled by the CGNR database, which is maintained by Document Production. The CGNR database is available in 1G only.

2Use of these modifiers, either individually or in combination, is controlled by the CGNR database (in Document Production), which validates the ticketing and BSP reporting requirements for every BSP where Travelport issues tickets. (This is the same database that defines the BSP reporting method.) The CGNR database is available in 1G only.

3Although ATPCO allows other data in this field (e.g. the actual word ‘BULK’), IATA restricts what may actually print in the fare box. It is expected that the 360˚ Fares™ Automated Rules Ticketing Interface project will include edits to prevent invalid text from being entered from Category 35.

Tour Codes (type T)

As there are currently no industry standards as to how to apply tour codes, particularly when conflicts exist, the following outlines 360° Fares™ processing:

Tour Codes can be filed in Category 27 – Tours or Category 35 – Negotiated Fares.

If a single fare component contains a tour code in Category 27 and in Category 35, the tour code in Cat 35 overrides Cat 27.

Tour code conflicts within a single category (multiple fares), fail to quote. Meaning, that if the outbound has a tour code and the inbound has a different tour code, we will fail to quote the pricing solution.

For multiple fares, if one fare has a tour code, the other does not; this is not considered a conflict. We quote and the tour code from the first fare component will print on the ticket. If the first fare does not contain a tour code, then one will not print on the ticket.