Cat8 - Stopovers
Category 8 - Stopovers defines the conditions when a stopover(s) is permitted or required within the fare component or pricing unit and the applicable charges, carriers, and locations associated with those stopovers.
In order to validate this category it is mandatory to know the following:
- All intermediate ticketed points on the pricing unit encompassing the fare component being validated
- All fare components and fare break points on the pricing unit encompassing the fare component being validated.
- The amount of elapsed time at each intermediate ticketed point on the fare component
- All marketing carriers providing transportation on each fare component in the pricing unit being validated
- The type of pricing solution in which the fare component is being priced (e.g. open jaw, round trip, circle trip).
- Embedded surface sectors on each fare component in the pricing unit being validated
- Whether the fare component being processed is used outbound or inbound on the pricing unit
- The Stopover Time conditions of all fare components on the pricing unit
- The type of passenger for whom the fare is being priced
- Travel, ticketing, and reservation dates (refer to Data Application for Override Date Table 994)
- Tariff applicable to the fare component being processed (for RTW/CT fares)
Assumptions
When there is no data present for Category 8:
In the absence of Category 8 (no Category 8 Record 2 that resolves to the fare or no Category 8 Record 3 is applicable within the string) the system assumption is that stopovers are not permitted at any point on the fare component being validated. A stopover is defined as an interruption of travel greater than 4 hours for the ATPCO Domestic Fare Product data and greater than 24 hours for the ATPCO International Fare Product data.
When there is data present for Category 8:
When processing resolves to an applicable Category 8 Record 3 that permits/requires stopovers, stopovers may occur at any point on the fare component/pricing unit (depending upon the presence or absence of data in the MAX field (bytes 16-17) with no geographic or carrier restrictions unless otherwise specified. No charges will be assessed unless otherwise specified. Additionally, stopovers at embedded surface sectors are permitted provided both end points of the surface sector are permitted (i.e. based on Recurring Segment data); an embedded surface sector only counts as 1 stopover. A stopover is defined as an interruption of travel greater than 4 hours for the ATPCO Domestic Fare Product data and greater than 24 hours for the ATPCO International Fare Product data, unless otherwise specified in the Category 8 Time Fields (bytes 52-59).
Fare break points are never considered stopover points for the purposes of processing Category 8 data.
Processing Steps THEN/AND Subset
In a THEN/AND subset, processing will calculate the total sum of the required/permitted number of stopovers across all matched tables in the set based on the MIN (bytes 14-15), MAX (bytes 16-17), Out (bytes 18-19), and IN (bytes 20-21) fields. The basic processing steps are:
-
Attempt to match the first Category 8 Record 3 table (THEN table) for the fare component being validated.
-
Determine if any AND tables exist in the subset, and attempt to match the AND tables. If the fare component being validated does not match to any tables in the subset, continue to the next subset:
- If a match is not made to another subset; or
- If a match is made to another subset but processing cannot validate all stopovers against the matched subset; or
- If no other subsets exist, then Apply the system assumption for this level (stopovers are not permitted on the fare component being validated)
- Calculate the sum of the MIN (bytes 14-15), MAX (bytes 16-17), OUT (bytes 18-19), and IN (bytes 20-21) number of stopovers for all matched tables in the subset. In other words, calculate:
- The sum of the MIN number of stopovers for all matched tables in the subset to determine the total MIN number of stopovers required; and
- The sum of the MAX number of stopovers for all matched tables in the subset to determine the total MAX number of stopovers permitted; and
- The sum of the OUT number of stopovers for all matched tables in the subset to determine the total number of stopovers permitted outbound; and
- The sum of the IN number of stopovers for all matched tables in the subset to determine the total number of stopovers permitted inbound).
4. Determine if data should be measured against the pricing unit or the fare component, based on the presence or absence of a value in the MAX field (bytes 16-17) and data in the OUT (bytes 18-19) and IN (bytes 20-21) fields.
5. Validate the MIN, MAX, OUT, IN number of stopovers (calculated in step 3 above) against the pricing solution.
- If all MAX fields in the subset contain data (other than ‘blank’), then validate the calculated Max against the pricing unit (unless otherwise specified). Tables that are pricing unit in application (as defined by the presence of data in the MAX field) are used to validate stopovers on the fare component being processed as well as the pricing unit encompassing the fare component being processed.
- If all MAX fields in the subset contain a ‘blank’ value and OUT or IN contains data, validate the calculated OUT and IN data against the fare component being validated. Tables that are fare component in application are only used to validate stopovers on the fare component being processed.
NOTE: Fare component vs. pricing unit application will be discussed later in this document for each applicable field.
6. Continue validation of the permitted/required stopovers using Recurring Segment data in the matched tables according to fare component or pricing unit scope defined by the Recurring Segment (and the presence or absence of data in the MAX field).
- Recurring segment stopover data must remain within the confines of the MAX, OUT, IN numbers specifications of the table housing that specific Recurring Segment being processed.
- Recurring segments specifying a “required” condition must be validated and passed prior to attempting to validate and pass other Recurring Segments.
-
For any stopovers that do not pass validation against the THEN table, continue processing to an AND table and attempt to validate them against the AND table. All stopovers on the fare component or pricing unit do not have to pass validation against the same Category 8 Record 3 table, but all must pass validation against the same THEN/AND subset.
7. For any matched and passed Category 8 Record 3, apply any applicable stopovers charges. All stopovers must pass validation against the THEN/AND subset in order to pass Category 8 processing.
Pricing Unit vs. Fare Component Application
Category 8 allows for the data to be determined as applying to the entire pricing unit or to a single fare component based on the presence or absence of data in the MAX field (bytes 16-17) as described below:
• If MAX (bytes 16-17) contains any value other than Blank, then all data in the Category 8 Record 3 has a pricing unit application unless otherwise specified by the application of an individual field.
• If MAX (bytes 16-17) is value Blank and OUT (bytes 18-19) and/or IN (bytes 20-21) contain data (i.e. contain any value other than Blank), then all data in the Category 8 Record 3 has a fare component application.
NOTE: Edits only permit value Blank in MAX, Out, and In fields when the table only contains Text Table 996 only (Unavailable Data Tag byte 138 value Y). In this case processing ignores the table and continues to another table, attempting to find a match and pass. If no other tables exist or are matched, apply the system assumption for this level (no stopovers permitted on the fare component being validated).
Pricing Unit Table with Fare Component Data
A single Record 3 table can have data in MAX (bytes 16-17) as well as in the OUT (bytes 18-19) and/or IN (bytes 20-21) fields. In this case, the table has a pricing unit application (based on presence of data in the MAX field); however, data in the Out and In fields are always applied to the fare component only (depending upon the outbound or inbound application of the fare component), even when used in a pricing unit table. Likewise, when MAX (bytes 16-17) contains data, the Recurring Segment data applies to the pricing unit, unless the segment contains value O (Outbound) or I (Inbound) in the I/O Indicator field (byte 163) . When the I/O indicator is set to value O or I, then the data in that Recurring Segment are always applied to the fare component only (depending upon the outbound or inbound application of the fare component), even when used in a pricing unit table. [Refer to later sections of this document regarding the application of the Out/In fields (bytes 18-21) and the I/O indicator (byte 163).]
NOTE: The pricing unit vs. fare component application of each individual field is detailed in Section 4.1 of this document.
Fare Component Table with Pricing Unit Data
A single Record 3 table with MAX (bytes 16-17) value Blank and data in the OUT (bytes 18-19) and/or IN (bytes 20-21) fields has a fare component application. In this case, data in the Recurring Segment has a fare component application. If a Recurring Segment has I/O Indicator (byte 163) value E (Either Outbound or Inbound but not both), then processing ignores this Recurring Segment since value E requires a pricing unit application. In this case, stopovers must be validated based on any other Recurring Segments. If no other Recurring Segments exist or if all Recurring Segments have I/O indicator value E, then fail this Category 8 Record 3.
Mixture of Pricing Unit and Fare Component Data within a Single THEN/AND Subset
All of the data tables in a THEN/AND subset should have the same processing application, either pricing unit or fare component as determined by the MAX or Out/In fields. If a THEN/AND set contains a mixture of pricing unit and fare component tables, then processing ignores the entire set and continues to the next set. If no further subsets exist or are matched, then apply the system assumption (stopovers are not permitted on the fare component being validated).
When a Category 8 Record 3 table within a THEN/AND subset contains Text Table 996 only (Unavailable Data Tag byte 138 value Y), the table is ignored and has no automated application when processing the subset. For automated processing, the THEN/AND subset is processed as if this table (containing Text Table 996 only) does not exist. A table with Unavailable Data Tag byte 138 value Y (Text Table 996 only) can be present as part of a THEN/AND subset where the application of the subset is either pricing unit or fare component (based on data in MAX and OUT/IN fields).
Mixture of Pricing Unit and Fare Component Data across Fare Components in a Single Pricing Unit
When multiple fare components are combined in a single pricing unit:
- If all fare components resolve to applicable Category 8 data relevant to the pricing unit (i.e. MAX bytes 16-17 contains data for all applicable Category 8 Record 3s), then the Category 8 data for all fare components is validated against the pricing unit.
- If at least one fare component resolves to Category 8 data applicable to the pricing unit (i.e. MAX bytes 16-17 contains data) and at least one fare component resolves to Category 8 data applicable to the fare component (i.e. MAX bytes 16-17 is value Blank and Out bytes 18-19 and/or In bytes 20-21 contain data), then the Category 8 data applicable to the pricing unit validates against the entire pricing unit and the Category 8 data applicable to the fare component validates against the fare component that resolved to the data. (Refer to the example below.)
THEN/AND subsets
All of the data tables in a THEN/AND subset should have the same processing application, either pricing unit or fare component
- If MAX (bytes 16-17) contains data in one table in the subset, then all tables in the subset must contain data in MAX.
- If MAX (bytes 16-17) is Blank in one table in the subset, then all tables in the subset must have MAX value Blank..
All of the data tables in a THEN/AND subset should have the same Time data in the TIME MIN and TIME MAX fields
Recurring Segments
Recurring segments must be coded within Charge value in most specific to least specific order, taking into account:
- Geographic hierarchy
- Negative before positive within geographic locales
-
Do NOT code both positive and negative provisions for the exact same locale unless the Charge (byte 164) values differ.
-
The sum of the Number (bytes 143-144) value across all Recurring Segments within the table must be greater than or equal to the MAX value (Bytes 16-17) when MAX is present. When MAX is Blank, then the sum must be greater than or equal the higher of the OUT (bytes 18-19) or IN (bytes 20-21) values.
-
If the Maximum number of stopovers is restricted to a specified number Outbound and a specified number Inbound, the Out and In fields in the fixed portion of the record (bytes 18-19, 20-21) must be coded to express this. The I/O field in the Recurring Segment (byte 163) should only be used to define the outbound or inbound portion to which the Recurring Segment data applies.
Time Max (Bytes 56-59)
A common filing error for is invalid coding of the Time Max Byte. Whenever you have a THEN AND set with time restrictions on the Stopover duration the data must be the same in both tables.
If not the restrictions are ignored. Here is a good example where CAT8 will fail due to invalid coding in CAT8
As per ATPCO CAT8 data application Page E.03.05.60 the values must be the same within a subset or that subset is ignored.
Inbound/Outbound (Byte 163)
Another common filing error in CAT8 is the In/Out Byte 163
Here there is a stop in MIA in both directions
value E in byte 163 in Record 3 Table 995685 Charge 1 and 2 and MIA is a Recurring segment which would only pass in one direction not both.
4.1.15.6 Inbound/Outbound (byte 163)
This field specifies the application of the data in the Recurring Segment based on whether the fare component is used Inbound or Outbound. Following is an explanation of applicable values:
Value I: Inbound. The data in the Recurring Segment applies to the fare component being validated when the fare is used inbound. If the fare is used outbound, then the Recurring Segment is not applicable.
Value O: Outbound. The data in the Recurring Segment applies to the fare component being validated when the fare is used outbound. If the fare is used inbound, then the Recurring Segment is not applicable.
Value E: Either Outbound or Inbound But Not Both. The data in the Recurring Segment applies to the pricing unit encompassing the fare component being validated. The stopover condition specified in the Recurring Segment is only permitted outbound or inbound, but not both. If the stopover being validated meets the conditions in the Recurring Segment, then processing must look at fare components in the opposite direction of travel to validate that the same stopover condition is not present. If the Recurring Segment condition is met both outbound and inbound, then processing will fail the Recurring Segment and continue to another Recurring Segment with a different Charge value (byte 164) or to another table in the subset.
Value Blank: When MAX (bytes 16-17) contains data, then the data in the Recurring Segment applies to the pricing unit encompassing the fare component being validated. When MAX (bytes 16-17) is Blank, then the data in the Recurring Segment applies to the fare component being validated.