FAQ's

Current rule display follow-on after pricing design uses departure date of each component as Journey commencement date so check an FD using the travel date of Fare Component 2. The travel date would have to pass the seasonality and travel restrictions before being able to display.

Example:

In the example above the return travel (Fare Component 2) is using SKXRIMS based on the outbound seasonality (as per Fare Construction principles for Round Trip) however if we look at the Fare Display you will see that the seasonality is only up until 21Jun

Although this is correct for pricing as the seasonality is determined by the outbound it does not allow the FN to display the rule. If you had return travel that fell within the seasonality it would display the rule using FN follow on.

This can also be the case if the return fare fails Travel Restrictions (CAT14)

The APFS field gives access to the Apollo fares system, and must be set to enable access to fares in the Galileo system.

The field is set to: APFS-D/Q/B

D for Fare Display

Q for Fare Quote

B for Fare Quote Best Buy

Please refer to Missing Fare

Carriers who choose to use General Rule MPM1 must also send an email to ManualTableRequest@galileo.com using one of the following subject line headers. As all information that falls in the General Rule MPM1 is not automated data, the carrier must send an email so that a manual table within the 360Fares can be updated accordingly. In addition, carriers who alter any previous General Rule MPM1 information must send an email to advising of the adjustment.

Yes. Instruct ATPCO to point your existing general rules to your Fare by Rule tariffs.

360º Fares supports carrier filings of ticket designators, which are appended to the fare class with an oblique (/). This designator is often used to denote a discount.

For example: ticket designator CH33 is appended to fare class YOW to become YOW/CH33.

For Apollo only:

The Fare Basis Code information from a fare quote can include:

• Fare Basis Code (1 to 8 characters)

• Ticket Code (1 to 10 characters to replace the Fare Basis Code or 1 to 9 characters appended to the Fare Basis Code)

• Ticket Designator (1 to 8 characters) preceded by a ( / ) delimiter

Whichever combination of Fare Basis, Ticket Code and Ticket Designator is based on the filed fare preferences of the validating carrier and is still bound by the overall industry limitation of 15 characters for the entire field.

The Fare Basis - Ticket Designator field is enhanced to dynamically place the ( / ) delimiter after the Fare Basis+Ticket Code digits, but before the Ticket Designator, thereby accommodating varying patterns of Fares

Basis+Ticket Code/Ticket Designator. The ATFQ Fare Quote (FQ) line is enhanced to include the accompanying Ticket Code, when applicable

While many times this is correct, there seems to be instances where Airlines intend to code that the fare must be issued on their stock/plate, but code that tickets can ONLY be issued by the carrier.

Also if a CAT15 Point of Sale restriction is filed and the user is not using the correct POS the fare will show as unsaleable.

To display Unsaleable fares from a fare display use format:

Galileo 1G: FU*

Apollo 1V: $LU

360º Fares™ supports fare construction rules based on IATA resolutions. These rules include:

• Fare selection

Including suppression of YY fares by carrier instruction.

• Pricing unit logic

• Mileage and mileage exceptions

• Permissible surface sector

• Specified routings

• Limitation on indirect travel

• Unreasonable connection

• Minimum checks

• HIP (higher intermediate point)

• BHC (one-way backhaul)

• OSC (normal fare check)

• DMC (directional minimum check)

• CTM (circle trip minimum, includes around the world minimum)

• RSC (return subjourney check)

• COP (country of payment check)

• CPM (common point minimum)

With the utilisation of the ATPCO Automated Rules and Footnotes product, fares may be filed that apply to a specific passenger type based on geographic conditions. Categories 1, 15, 25, and 28 can be used to define a geographical restriction that the passenger must meet in order to qualify for the fare.

A new Personal Geography Modifier will provide the ability to validate fares that have been filed to include specific geographic locations where the passenger might reside or work. Fares formerly available without entering a location code will now require the addition of this new modifier in combination with a PTC code when filed by the airline.

Should the carrier file a geographical restriction, the system will include that geography when validating the fare rules. Therefore, the personal geography modifier will need to be entered to quote fares that have specific location restrictions as coded by the carrier and must be used in combination with a valid PTC, including ADT for adult if applicable. If the user does not include the personal geography modifier when the carrier has filed a geographical restriction, the system will fail to auto-price that fare.

The personal geography modifier can be up to 5 characters long, and must follow a passenger type code, including ADT.

1st position – “L” to indicate presence of personal location modifier

2nd to 5th positions – used to indicate specific geographic location. This includes:

a 2 position country code (e.g. DE – Germany)

a 3 position city code (e.g. CHI – Chicago)

a 4 position code consisting of a 2 position country code, followed by a 2 position US state or Canadian province code (e.g. USCO – Colorado, CAPQ – Quebec).

General Rule MPM1 filings are held in a manually updated table. Therefore any updates for your airline should be emailed to :

ManualTable.Request@galileo.com

Note: Please ensure that the words ‘General Rule MPM1 filing’ are contained within the subject line of the email.

360º Fares allows a passenger with accompaniment restrictions to be priced separately from the accompanying passenger, either through the use of an accompaniment fare quote modifier, or implicit recognition of unselected accompanying passengers in the same reservation. This ensures the integrity of the fare rules validation.

By using the pricing modifier /ACC, you can price a passenger in one Booking File and indicate that the accompanying passenger is in another Booking File.

Refer to: How do I quote fares that require accompanied travel?

Some fares, such as children's fares and companion fares, require that a passenger travel with other passengers to qualify for the fare.

Note: You must specify a passenger type code (PTC), and often the age of the child/passenger, otherwise the system will assume that the passenger is an adult.

Pricing Together

In most cases, you can quote the fare in the same entry using name select and a passenger type code (PTC) pricing modifiers stored as a name remark. Refer to: How do I quote and file a fare when a Booking File contains multiple passenger types such as adults, children and infants?

Pricing Separately

Sometimes you need to price or store the passengers separately. For example, if they have different forms of payment, the fare for each passenger would be stored separately. Another example is passengers in separate Booking Files. You can price and store fares separately and still validate the accompanied travel provisions of the fare.

Passengers in the same Booking File

For passengers in the same Booking File, the Galileo system detects the unselected passengers and validates the accompanied travel provisions of the fare. For example, if there is an adult and child in the same Booking File and you name select the child, the system detects the adult in the Booking File and validates the accompanied travel provisions.

Passengers in separate Booking Files

By using the pricing modifier /ACC, you can price a passenger in one Booking File and indicate that the accompanying passenger is in another Booking File.

Note: You can append the number of accompanying passengers or the PTC of accompanying passenger to the /ACC modifier if required.

The passenger description on the right of the screen specifies an adult fare (ADT).

You must include the pricing modifier ACC to indicate that the child is accompanied by an adult on a separate Booking File.

Enter: FQ/ACC

Galileo checks for HIPs on Routing Fares when there is an intermediate stopover.

To avoid a HIP check at a stopover, you may file an exception in Cat 17.

For Detail please refer to CAT17

The answer is ‘yes’. Any booking code exception(s) that the owning carrier files for themselves and any secondary carrier that they may have an agreement with always takes precedence (Record 6 -Convention 2) If no match is found there, then the next check is done on the booking code exception(s) filed by secondary carrier (Record 6 Convention 1).

Refer to RBD Record 6

Yes. If any of the resulting fare fields are left blank, the resulting fare will take that characteristic from the base fare. HOWEVER, if there is a Category 35 in the rule, the resulting display category MUST be coded with a C, L, or T.

See CAT25 FBR

360º Fares™ supports carrier filings of ticket codes, which replace the filed fare class code or append to fare class code. For example: For fare class YOW, ticket code –CH is appended to fare class code to become YOWCH

For Apollo only:

The Fare Basis Code information from a fare quote can include:

 Fare Basis Code (1 to 8 characters)

 Ticket Code (1 to 10 characters to replace the Fare Basis Code or 1 to 9 characters appended to the Fare Basis Code)

 Ticket Designator (1 to 8 characters) preceded by a ( / ) delimiter

Whichever combination of Fare Basis, Ticket Code and Ticket Designator is based on the filed fare preferences of the validating carrier and is still bound by the overall industry limitation of 15 characters for the entire field. The Fare Basis - Ticket Designator field is enhanced to dynamically place the ( / ) delimiter after the Fare Basis+Ticket Code digits, but before the Ticket Designator, thereby accommodating varying patterns of Fares Basis+Ticket Code/Ticket Designator. The ATFQ Fare Quote (FQ) line is enhanced to include the accompanying Ticket Code, when applicable.

Because Record 8 is the starting point, it is preferred that specific geography is coded here.

Category 3 - Seasonal Application defaults to a pricing unit.

This can be overridden with the use of a fare component TSI such as TSI 3 - "Each Trip" however you must also code the override tag.

Using Category 9 can control surface sector restrictions without manual intervention.

The following fields in Category 9 permit control of surface sectors. Please refer to ATPCO data application documents for complete details.

Please note that the SURF TBL 976 permits the vendor to control the surface sector further by defining geographic points where the surface sector may/may not occur, as well as limiting it to domestic or international points, and origin/destination points in the case of fare break surface sectors only. Please refer to ATPCO data applications documents for complete details of those features in the Category 9 product.

Recommended Filing

Airline and third party vendors should review their Category 9 data to ensure that Category 9 is coded as necessary to control surface sector restrictions to ensure that the fare is priced in accordance with carrier intent.

360 Fares currently only processes tour codes with a type of T.

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

Mileage surcharge band exceptions are held in a manually updated table. Therefore any updates for your airline should be emailed to : ManualTableRequest@galileo.com

One reason may be the TSI. If, for instance, your itinerary is domestic but the seasons have been coded with TSI 48- Departure of First International Sector, it would not apply to a domestic itinerary.

In it's place, the ATP System Default which is "no seasons are applicable" is applied and the fare will quote.

Yes, unlike Category 15, Category 35 includes a passenger type field.

When the information within multiple data tables applies to different passenger type codes, it can be coded within the Category 35 without having to IF to a Category 1.

However, if there is a need to indicate that the different data tables within the same sequence are applicable to different account codes or other eligibility information, then an IF Category 1 is needed

Example 1

Data

Then Category 35 PTC JCB (1V)

Then Category 35 PTC PFA (1G)

Results

Only 1V can sell to the JCB passenger and only 1G can sell to the PFA passenger. 1V is not able to sell to the PFA passenger and 1G is not able to sell to the JCB passenger. The category 35 controls who can sell the fare and to whom.

 

Example 2 (with Account code)

Data

Then Category 35 PTC JCB (1V pcc 123/1G pcc 456) IF Category 1 JCB Account code ABC

Then Category 35 PTC PFA (1V pcc 789) IF Category 1 PFA Account code DEF

Results

Both 1V pseudo city 123 and 1G pseudo city 456 can sell to the JCB passenger using account code ABC. They are not able to sell to the PFA passenger using account code DEF. Only 1V pseudo city 789 can sell to the PFA passenger using account code DEF. This user is not able to sell to the JCB passenger using account code ABC. The category 35 controls who can sell the fare and the IF Category 1 controls to whom the fare can be sold.

Category 12 Surcharges defines the conditions under which surcharges are applicable and the corresponding charge. Should the surcharges for infant and children passenger type codes vary, the data does need to be coded as such. Please refer to ATPCO’s passenger type code hierarchy for a list of passenger type codes that map to child.

The examples below illustrate best practices for adult, infant, and children fares when their surcharges differ from one another. Please note that each example differs as the intent behind each of the conditions differs.

 

Example 1

The data in the example illustrates that there is a 0.00 USD surcharge for infant without a seat. All other passenger type codes will have a 20.00 USD surcharge applied; the surcharge amount is not subject to a children/infant discount.

1. If the passenger on the fare component being validated is using passenger type code INF under the age of 2, then a fuel surcharge of 0.00 USD will apply to the fare component.

2. Otherwise, a fuel surcharge of 20.00 USD will apply to the fare component.

Category 12 – Record 2 Unless otherwise specified

Category 12 - Record 3 THEN

Please see here

If the specified carrier used in the Fare Quote Planner (FQP) entry has filed the YQ in their Service Record 1 (S1) with an equipment code for the sector being validated , FQP (unbooked itinerary) cannot validate and apply the YQ since no flights are booked.

Either category can be coded to show a resulting tour code on the ticket. However, if both categories are coded with different tour codes, only the tour code found in category 35 will show on the ticket.

Category 1 – Eligibility

Employee – must be/must not be of specific location

National – must be/must not be of specific location

Resident – must be/must not be of specific location

Category 15 – Sales Restrictions

Resident – must be/must not be a resident or citizen of a specific location

Category 25 – Fare by Rule

Employee – must be/must not be of specific location

National – must be/must not be of specific location

Resident – must be/must not be of specific location

Ship Registry – must be/must not be of specific location

Category 28 – Visit Another Country

Resident – must not be a resident of specific location

 

Travelport also recommends that carriers review the geographical restrictions as filed in Categories 1, 15, 25, and 28 to ensure it meets with their intentions. Further information regarding this is available on ATPCO’s website www.atpco.net if additional information is required.

Please see cat35 here

You may have cancelled the footnote that was keeping the fare from being displayed/sold.

Or possibly, you added a "Not Applicable" tag to the footnote, which cancelled the application of this footnote.

Travelport system has been designed to always quote the carrier published fare over the IATA (YY) fare if both fares have the same fare type. The design is to quote the carrier fare even if it is higher than the YY fare.

Different fare types

Fares for YY fares may be BU (business unrestricted) and the airline fare type is BR (business restricted). Since the fare type is not the same on each fare and the YY fare is lower, the YY fare will be chosen for quote.

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.

Entry format to display full rules text in both directions for rule Category 4 FLIGHT APPLICATION:

Galileo 1G: FN*1/04/F

Apollo 1V: $V1/04/F

Entry format to display full rules text for all Rule categories:

Galileo 1G: FN*1/ALL/F

When you code data in a text table, it is freeform data only and cannot be validated.

It displays on the rule text display preceded by the word NOTE. Any data following the word NOTE is not validated.

Only main surcharges (i.e. non-conditional) surcharges are included when this modifier is used (refer to the Phase 1 functional advisory book). If in doubt, look at the category 12 rules text. If you see statements such as IF in the text, this indicates that the surcharge is conditional and not applicable for inclusion when /Q is used.

Fare Usage describes whether a fare is being used as a one way fare or a half round trip fare.

When a round trip fare is used to force a fare (FIC ) and the itinerary does not qualify for half round trip fares, the FIC will fail for Fare Usage.

Special fare open jaws and special fare circle trips are limited to two international fare components only. When trying to price an itinerary using special fares or a combination of normal and special fares and there are more than two international fare components the pricing solution will always fail for Fare Usage.

If the text produces the word "when", then the ticketing requirement only applies "when" the reservations are made according to the time frame in the rule.

 

Example:

2 TYOKUL 20APR07 XX JPY 69000 HLNR2M STAY-02/2M BK-H

5. ADVANCE RES/TICKETING

UNLESS OTHERWISE SPECIFIED

RESERVATIONS ARE REQUIRED FOR ALL SECTORS.

WHEN RESERVATIONS ARE MADE AT LEAST 7 DAYS

BEFORE

DEPARTURE TICKETING MUST BE COMPLETED WITHIN 5

DAYS AFTER

RESERVATIONS ARE MADE OR AT LEAST 7 DAYS BEFORE

DEPARTURE

WHICHEVER IS EARLIER.

Even though the rule says "OR" at least 7 days before departure which ever comes earlier, the fact is this is coded in one table where the 'Exception time' field is coded. This field produces the condition of "when".

See here for more details

Tour Code processing is fare component driven.

Tour Code conflicts within a single category 27 or 35 (for multiple fare components) will fail to quote.

Forcing fares does allow for a Tour Code override when multiple components have different Tour Codes, but this fare is not guaranteed for the agencies.

When both fare rule and general rule information are applicable on a given fare, only the information from the fare rule will apply with the exception of Categories 5, 8, 9, 11, 12, 15, and 16 where both information will always apply. For these categories, both the fare rule and general rule information will apply. When reconciling between Fare Rule and General Rule where the General Application is blank, both conditions are to be considered as a single thought as if they were in a single table.

The Validated Fare Display returns all fares for a specified date or set of dates by validating specific rule and footnote data.

The validated fare display enables extended fare validation based upon the dates in the request. If one date is input, one-way fares are assumed; if two dates are input, round-trip fares are assumed.

Formats are as follows: FDV12JULMANNYC FDV12JUL18JULMANNYC

Additional Rule Categories

The following rule categories are validated in this display, in addition to the categories validated by the Basic Fare Display:

• Day/Time (Day of week restrictions only. The time of day is not validated.)
• Seasonality
• Advance Reservations/Ticketing
• Minimum stay
• Maximum stay
• Blackout
• Travel restrictions

The Fare Creator Table (Table 979) allows several methods for the creation of a Selling Fare based on the Net Fare, or vice versa.

Each sequence on the Fare Creator Table can be defined by:

• Direction
• Type / Geographic Location (as in the Security Table)
• Net or Selling Fare – identifies the fare being “created”
• N = Net Fare
• S = Selling Fare
• Fare Indicator – identifies the method used to create the fare:

 

C = Calculated. Multiply the fare in the Fare Record by the percentage in Table 979.

Fare Record: USD 100.00

Percent: 150

Fare Created: USD 150.00

 

S = Specified. Apply specified fare amount in Fare 1 field -or- Fare 2 field.

Fare Record: USD 100.00

Specified: USD 150.00

Fare Created: USD 150.00

Note: Apply Fare 1 or Fare 2 based on the currency of the fare being assessed.

 

A = Add. Add the resulting amount calculated from Percent field to the specified amount in Fare 1 field –or- Fare 2 field.

Fare Record: USD 100.00

Percent: 150

Amount: USD 25.00

Fare Created: USD 175.00

Note: Apply Fare 1 or Fare 2 based on the currency of the fare being assessed.

 

M = Minus. Subtract the specified amount in Fare 1 field –or- Fare 2 field from the resulting amount calculated from the Percent field.

Fare Record: USD 100.00

Percent: 150

Amount: USD 25.00

Fare Created: USD 125.00

Note: Apply Fare 1 or Fare 2 based on the currency of the fare being assessed.

 

The following calculation methods define a “range” for the created fare. The user must determine a specified amount for the created fare. Travelport employs Agency Private Fares for this purpose. The resulting fare is validated to ensure it falls within the range calculated by cat35.

 

Note: APF processing does not allow for the base fare to be a fare created by Category 25.

 

P = Calculated Range Amount. Apply calculated minimum and/or maximum Selling Fare amount created from the percentage rate in Minimum Fare Percent field and/or Maximum Fare Percent field (Bytes 58-61).

Fare Record: USD 100.00

Minimum Percent: 150

Maximum Percent: 200

Fare Range Created: USD 150.00 – USD 200.00

 

R = Specified Range Amount. Apply specified minimum and/or maximum Selling Fare amount in Range 1 Minimum Fare field and/or Maximum Fare field -or- Range 2 Minimum Fare field and/or Maximum Fare field.

Fare Record: USD 100.00

Minimum Amount: USD 150.00

Maximum Amount: USD 200.00

Fare Range Created: USD 150.00 – USD 200.00

Note: Apply Range 1 or Range 2 based on the currency of the fare being assessed.

 

N = Add calculated range to specified range. Add the calculated amount from the Minimum Fare percent field and/or the maximum fare percent field to the specified amount in Range 1 Minimum Fare field / Range 2 Maximum Fare field.

Fare Record: USD 100.00

Minimum Percent: 150

Maximum Percent: 200

Minimum Amount 1: USD 25.00

Maximum Amount 1: USD 50.00

Fare Range Created: USD 175.00 – USD 250.00

Note: Apply Range 1 or Range 2 based on the currency of the fare being assessed.

 

T = Subtract calculated range from specified range. Subtract the specified amount in Range 1 Minimum Fare field / Range 2 maximum Fare field from the calculated amount from the Minimum Fare percent field or Maximum Fare Percent field.

Fare Record: USD 100.00

Minimum Percent: 150

Maximum Percent: 200

Minimum Amount 1: USD 25.00

Maximum Amount 1: USD 50.00

Fare Range Created: USD 125.00 – 200.00

Note: Apply Range 1 or Range 2 based on the currency of the fare being assessed

No. However, you may want to consider using a different passenger type code for your FBR fares than are on your base fares. Or you may want to consider assigning a resulting ticket designator or tour code to your FBR fares. Either and/or all of these options may help to avoid the number of Record 3 tables required to specify each resulting fare code

The following list are ‘text only’ categories. As such, information displayed from these categories is not validated by the 360Fares system for fare quote, fare display, and shopping entries. The text displayed is for informational purposes only.

• Category 26 Groups
• Category 29 Deposits
• Category 31 Voluntary Changes
• Category 32 Involuntary Changes
• Category 33 Voluntary Cancellations
• Category 34 Involuntary Cancellations
• Category 50 Rule Application and Other Conditions

The Galileo® filed fare allows for storage of up to 15 characters of the Fare Basis Code, Ticketing Code and Ticket Designator.

When the combination of these three elements amounts to more than 15 characters, truncation of the Fare Basis Code and/or Ticketing Code will occur. The entire Ticket Designator will always be retained. In the rare event that the Ticket Designator contains 14 characters (with the mandatory ‘/’ creating the 15th character), 360° Fares™ will return a fare quote but not file the fare, and an error message will be displayed.

Note: All characters of the Fare Basis Code, Ticketing Code, and Ticket Designator currently appear in the linear fare calculation area of the Filed Fare.

Ticketing Information Data Transfer (TIDT) refers to functionality where Travelport International provides, at the airline's option, various collections of data relating to ticketing activity within the GDS.

Note: Ticketing data relating to your airline from other systems can also be collected if agreed.

If your airline wishes to request TIDT, please contact your Operational Account Manager.

Airport Fares and City Fares often are filed within the same market. For example, a carrier may file fares as NYC-TLV, JFK-TLV, and EWR-TLV. The system is designed to quote the lowest applicable fare.

Example:

Carrier XX filed fares from New York City (NYC) and Newark Airport (EWR) to Tel Aviv-Yafo (TLV). The fares filed from NYC are less expensive than the fares filed from EWR. As EWR is a multi-airport of NYC, when a EWR/TLV segment is priced, the lower NYC fare is quoted.

Recommended Filing:

Category 4 Flight Application should be reviewed for all city and airport fares. If a city fare is not valid to a specific airport, travel to/from that airport should not be permitted. Category 4 allows you to control that by the airport code or by specific flight numbers

Record 8 should ALWAYS contain an account code if it is to be used. Category 1 can be filed with an account code at the same time. Just note, that the passenger type on the Record 8 must match that of the passenger type being coded in Category 1

Mileage Display

This follow-on request displays the mileage surcharges that may apply for a specified mileage-based fare from the initial Fare Display. The display shows both the applicable mileage and the fare amount with each surcharge applied. The format is FM*xx (xx is line number from fare display)

Example

Example: Both fares are applicable Business Class Fares and the lower fare is a YY fare, the higher is carrier specific.

If both fares are of the same fare type, general category and fare usage, then the carrier specific fare is selected over the YY (IATA) fare.

In this case the Carrier fare is a Business Restricted fare, while the YY is unrestricted. The carrier can change their fare to BU or request that YY fares be suppressed

Yes. Galileo supports processing of security in either category. However, if the resulting display cat of the Category 25 is L, C, or T, then there must be a Category 35.

How to Link Eligibility and Security Data

Category 15 IF Category 1 (Recommended)

Option 1 uses Category 1 as a qualifying condition to control to whom can sell the fare. Coding Category 15 Sales Restrictions as a main provision allows the 360Fares system to sell the fare to anyone who is eligible to use the fare. Listing the 1V/1G CRS code in the main Category 15 and linking to the qualifying IF Category 1 controls to whom the fare can be sold to. Once a passenger is identified in the IF Category 1, then only the CRS/GDS listed in the associated Category 15 portion can sell to the specified passenger.

 

Example 1

Data

Then Category 15 (1V) IF Category 1 JCB

Then Category 15 (1G) IF Category 1 PFA

Results

Only 1V can sell to the JCB passenger and only 1G can sell to the PFA passenger. The category 15 controls who can sell the fare and the IF Category 1 controls to whom the fare can be sold.

 

Example 2

Data

Then Category 15 (1V pcc 123) or Category 15 (1G pcc 456) IF Category 1 JCB Account code ABC

Then Category 15 (1V pcc 789) IF Category 1 PFA Account Code DEF

Results

Both 1V pseudo city 123 and 1G pseudo city 456 can sell to the JCB passenger using account code ABC. Only 1V pseudo city 789 can sell to the PFA passenger using account code DEF. The category 15 controls who can sell the fare and the IF Category 1 controls to whom the fare can be sold.

Category 35 or Category 35 IF Category 1

Option 2 uses Category 1 as a qualifying condition to control to whom can sell the fare. Coding Category 35 Negotiated Fares as a main provision allows the 360Fares system to sell the fare to anyone who is eligible to use the fare.

 

Unlike Category 15, Category 35 includes a passenger type field. When the information within multiple data tables applies to different passenger type codes, it can be coded within the Category 35 without having to IF to a Category 1. However, if there is a need to indicate that the different data tables within the same sequence are applicable to different account codes or other eligibility information, then an IF Category 1 is needed.

 

Listing the 1V/1G CRS code in the main Category 15 and linking to the qualifying IF Category 1 controls to whom the fare can be sold to. Once a passenger is identified in the IF Category 1, then only the CRS/GDS listed in the associated Category 15 portion can sell to the specified passenger.

 

Example 1

Data

Then Category 35 PTC JCB (1V)

Then Category 35 PTC PFA (1G)

Results

Only 1V can sell to the JCB passenger and only 1G can sell to the PFA passenger. The category 15 controls who can sell the fare and the IF Category 1 controls to whom the fare can be sold. 1V is not able to sell to the PFA passenger and 1G is not able to sell to the JCB passenger. The category 35 controls who can sell the fare and to whom.

 

Example 2

Data

Then Category 35 PTC JCB (1V pcc 123/1G pcc 456) IF Category 1 JCB Account code ABC

Then Category 35 PTC PFA (1V pcc 789) IF Category 1 PFA Account code DEF

Results

Both 1V pseudo city 123 and 1G pseudo city 456 can sell to the JCB passenger using account code ABC. They are not able to sell to the PFA passenger using account code DEF. Only 1V pseudo city 789 can sell to the PFA passenger using account code DEF. This user is not able to sell to the JCB passenger using account code ABC. The category 35 controls who can sell the fare and the IF Category 1 controls to whom the fare can be sold.

 

Category 1 IF Category 15

Option 3 uses Category 15 as the qualifying condition to control when the eligibility provision applies. This option does not apply to Category 35 as Category 35 cannot be used as a qualifying category. This option does not control the passenger type to whom the system can sell the fare.

 

This option is used when the eligibility provisions is dependent upon the sales restriction provision. For example, a Category 1 IF Category 15 would be coded when the account code for a passenger type is dependent upon the GDS selling the fare.

 

Example 1

Data

Then Category 1 PTC ADT account code APOLLO IF Category 15 1V

Then Category 1 PTC ADT account code GALILEO IF Category 15 1G

 

Results

All 1V agencies must use account code APOLLO in order to sell the fares. 1V agencies who do not use an account code or use an account code other than APOLLO are not able to sell the fares. All 1G agencies must use account code GALILEO in order to sell the fares. 1G agencies who do not use an account code or use an account code other than GALILEO are not able to sell the fares.

 

Example 2

Data

Then Category 1 PTC JCB IF Category 15 1V

Then Category 1 PTC PFA IF Category 15 1G

Results

This is considered bad coding as there are not any eligibility restrictions found in the Category 1 table. The same result would appear IF Category 1 was not coded at all. If the intent is to control the type of fare that can be sold by the system, then either option 1 Category 15 IF Category 1 or option 2 Category 35 without the IF Category 1 as described above should be used

 

Recommended Filing:

It is recommended that carriers use either option 1 or option 2 depending upon which main category is used to control security. For carriers who have multiple wholesale/bulk type contracts, either option 1 or option 2 must be used. It is also recommended that for wholesale/bulk type contracts that specific non-adult passenger type codes are used per contract type versus account codes that have a passenger type code of adult.

Note: When using a passenger type in Category 1 to link eligibility to security, all applicable passenger types must 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, the desired result will not be achieved.

If the filing in Rule Category 9 does not restrict a surface sector the system will construct fare with a closed surface, if that results in a lower fare than an open-jaw construction.

360Fares ignores mileage rules up to 25M. When the route of travel exceeds 25M, then the fare cannot be quoted.

The suggestion to the carrier is that they file the fare as a diagrammatic routing to allow over 25M travel.

Yes, rule category overrides are processed per ATPCO specifications. Coding can instruct use of base fare rules, fare by rule rules or a combination of both for most categories. (see cat25)

No. A constructed fare can be used as a base fare to calculate a discount, but constructed fares are not created from FBR processing.

The 360º Fares system provides for one year of historical information. This historical data includes:

• Automated Rules data, as filed by the airline.
• Currency exchange rates.
• Taxes.
• All other supporting data.

Additionally, this historical data is available through the following functionality:

• Fare Display, which makes one year of historical data available to any user. The year and a carrier must be included in the entry. For example FDLONFRA01DEC06/LH
• Fare Quote, which makes historical fare quote available to any user for both North American and International itineraries.

Note that some constructed fares may not be available in 1P historically due to system limitations.

There are 3 common reasons.

 

1) Fare Class Application Record 1

The 'X' is in the Unavailable field of the Fare Class Application Record 1.

Action: Remove the 'X' if you want the fare to quote.

 

2) Fares with footnotes but no footnote exists.

When fares have a footnote, the footnote must be active.

Action: Either add a meaning to the footnote or remove the footnote from the fare record.

 

3) Unavailable tag within the Record 3 of a category.

If a carrier has intentionally code an 'X' in one of the rule Categories, this advises the GDS that the rule is incomplete.

Action. Remove the 'X' from the unavailable field.

Travelport provides two different methods for differential calculations: Method A and Method H. Method H is the default method.

In method H:

The differential is calculated by subtracting the lowest applicable fare in the lower class from the lowest applicable fare in the higher class, over the sector(s) traveled in the higher class. The higher compartment fare candidate used to calculate the differential must pass booking code validation for the higher compartment sector(s).

In method A:

The differential is calculated by subtracting the lowest applicable fare in the lower class from the lowest applicable fare in the higher class, over the sector(s) traveled in the higher class. There is no booking class validation on the higher class sector.

Booking codes on the lower class through fare are always validated regardless of the method used for the differential calculation