Cat2 - Day & Time

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

• Day/Time of each flight within the fare component.
• Departure/Arrival day/time for all flights within the pricing unit or journey because the inclusion of a Travel Segment Indicator (TSI) and the setting of the assumption override tag in this category can modify the application of the system assumption.

Assumptions

The assumptions for Day/Time application are:

• When there is no Category 2 information (no Category 2, Record 2 that resolves to the fare, including Record 2 match, inbound/outbound directional indicators, Geographic Specifications and date overrides), then the fare is valid for all days of the week and/or times of day within the confines of the other category provisions.
• Once there is data present for Category 2 that resolves to the fare, the assumption is that the data applies to the departure day and time of the origin flight of the fare component.

The ability to override this assumption and state that the data applies to departure from the origin of the pricing unit is provided within the category (Byte 58, Application Tag). The presence of a TSI and/or Geo Locs within Category 2 can further modify where the application of day/time restrictions are to be applied within the fare component. Additionally, there is the ability to further modify the category application with Byte 58 (Application Tag), to indicate where the restrictions of day/time should be applied within the pricing unit; i.e., a TSI alone does not modify the application of Category 2. It is important to note that the TSI or Geo Specification does not modify the Category Application from fare component to pricing unit; it only further identifies where the application of the time/days are to be measured from. Additionally, use of an arrival TSI can override the departure application of the category, causing the data to apply to the arrival at the point specified by the TSI.

Application Tag Byte 58

Here is an example where Travelport correctly fails to price due to CAT2 Failure of the App Tag Byte 58

As you can see the Airline expected to pass pricing because S4 is on a Tuesday ex HKG.

Byte 58 in CAT2 (APPL field) has two input options, BLANK or X. If blank then system assumption is that day/time restrictions apply to the whole fare component. If X then it is pricing unit.

This one was blank so we failed NRT-HKG as it is MON Also an Airline can use the GEOTBLNO field #995 which indicates the portion of travel to which the day/time restriction applies. In this case it was BLANK. Here is the ATPCO data application text for this byte.

The Application Tag is used to indicate whether the day/time provisions apply to the departure from the fare component origin or pricing unit origin. When the Application Tag is BLANK, the day/time restrictions apply to the departure from the first flight segment of the fare component. When the Application Tag is set, it overrides the fare component assumption, and the day/time restrictions apply to the departure from the first flight segment of the pricing unit.

The Application Tag may be used alone or in combination with data in the Geo Spec Table #995.

Therefore we correctly fail and if the airline intended to price it would be necessary to code Byte 58 with X and add the O/D in the #995 table.

Day of Week Indicator

In order to match a sequence for a fare valid on a specific day of the week the day of week indicator should be filed in both Record 1 Fare Application and the Cat2 Record 2. As per ATPCO data application . If you only file in the Record 2 the system will no match and move on to process the next sequence.

Record 1 Fare Application (aka Fare Class)

Record 2 Cat2

Stringing

When stringing multiple data tables in a set where the Negative Tag (Byte 57) is set in at least one of the tables, the relational indicator should be AND. For example: THEN Not permitted Mon-Wed AND only permitted 0700-1100.