Cat9 - Transfers

Category 9 defines the provisions for application of Transfers on a pricing unit or fare component. In the absence of Category 9 data, the system assumption is that unlimited transfers are permitted on the pricing unit - Embedded surface sectors are permitted, International fare break surface sectors are permitted and USCA (any USCA Domestic tariff) Fare Break surface sectors are not permitted. Fare break surface sectors are not permitted at journey origins.

Assumptions

In the absence of a Record 2 that resolves to a fare, or when a match is not made to any Record 3 tables within a string, then the system assumption applies as follows:

  • Unlimited transfers are permitted on the pricing unit

  • Embedded surface sectors are permitted between any points

  • International fare break surface sectors are permitted

  • USCA (any USCA Domestic tariff) fare break surface sectors are not permitted.

  • Fare break surface sectors are not permitted at journey origins

THEN/AND table data

THEN/AND subsets should not have tables with mixed application. If a THEN table contains a MAX value, every subsequent table should also contain a MAX value. Additionally, if the THEN table contains only an OUT/IN value, then any subsequent AND table should NOT contain a MAX value. If a GDS/CRS receives a subset containing mixed application for Category 9, they should ignore processing, apply the system assumption (or another processing level – general rule or fare rule – that can be applied) and contact the carrier.

Processing Steps THEN/AND

  1. Match to the first Category 9 Record 3 table (THEN table) for the fare component being validated.

  2. Determine if any AND tables exist in the subset, and attempt to match the AND tables.

  3. Calculate the sum of the MIN, MAX, OUT, IN number of transfers for all matched tables in the subset.

  4. Determine if data should be measured against the pricing unit or the fare component, based on the absence of a value in the MAX field.

  5. Validate the MIN, MAX, OUT, IN number of transfers (calculated in step 3 above) against the pricing solution. If the MAX field(s) contains a ‘blank’ value, validate all transfers data against the fare component being validated. If the MAX field contains a value other than ‘blank’ validate all transfers data against the entire pricing unit. Tables that are fare component in application (as defined by the absence of data in the MAX field) may only be used to validate transfers on the fare component being processed. Tables that are pricing unit in application (as defined by the presence of data in the MAX field) may be used to validate transfers on the fare component being processed as well as the pricing unit containing the fare component being processed. NOTE: fare component vs. pricing unit application will be discussed later in this document where the O/I indicator is presented.

  6. Continue validation of the transfers using recurring segment data in the matched tables according to fare component or pricing unit scope as outlined in step 5. Recurring segment transfer data must remain within the confines of the MIN, MAX, OUT, IN of the table housing that recurring segment being processed.

  7. Apply any applicable charges.

Processing Steps THEN/OR

  1. Match to the first category 9 record 3 table (THEN table)

    1. Validate the MIN, MAX, OUT, IN number of transfers on the fare component or pricing unit as defined by the data. Continue to validate the transfers using recurring segment data

    2. If any of the transfers cannot be validated continue processing to the next OR table or next set. If another table or set is not found that can be used to validate the transfers, the fare fails pricing.

  2. If the fare being validated does not match to the THEN table, continue to the next OR table or set. If another table or set is not found that matches or if no other tables exist, apply the system assumption for this level: unlimited transfers allowed; surface permitted, other than for USCA Fare Break surface.

  3. Apply transfer charges.

Category 9 allows for the data to be determined as applying to the entire pricing unit or to a single fare component. If there is a positive value in the MAX field, the entire table is considered to have a pricing unit application. If the MAX does not contain any value (‘blank’) and there is a positive value in either/both the OUT/IN fields, the table is considered to have a fare component application. NOTE: the only way a table will not have a value in either MAX or OUT/IN is if the entire table contains Surface Tags and/or Text Table 996 only.

All of the data tables in an AND set should have the same processing application, either pricing unit or fare component as determined by the MAX or OUT/IN fields. If any table in an AND set states a fare component application and the remainder of the set contains pricing unit tables; the GDS should ignore the entire set. If any table in an AND set states a pricing unit application and the remainder

of the set contains fare component tables; the GDS should ignore the entire set. When a set is ignored, a subsequent set should still be interrogated for purposes of autopricing. If there are no additional sets, apply the system assumption.

For a THEN/OR set where

1) the tables in the set have mixed application and

2) the THEN table is Pricing Unit and

3) the OR table is Fare Component and

4) a FAIL condition is reached on the THEN table

Processing should use the OR table for the Fare Component being validated and the THEN tables (granted they pass) for all subsequent fare components in the pricing unit. Additionally, in 2+ component pricing units - any fare components validated previously in the solution as Pricing Unit must be re-validated as Fare Component should the THEN table fail.