Fare Display is a request for a list of fares applicable for travel from one city to another. Minimally, the request will contain an ordered city pair (i.e. if the city pair is NYC-DEN, NYC will be treated as Board City, DEN as Off City), and fares will be valid for ticketing today for travel today. Requesters have the option to add modifiers to further filter the fares returned, such as carrier(s), passenger type groupings, travel date, private fare account code(s), etc.
See the Air Shop FAQ for questions regarding all air shopping transactions.
Transaction Name:
FareQuoteMultiDisplay_14
Can this task be performed in a sessionless environment?
Yes. This is an “initial” entry, i.e. one that initiates a host session.
Are the request and response identical on both the Apollo and Galileo systems?
Yes. Additionally, requests can ask for either a structured response or a screen display response.
List any industry-specific knowledge required to understand this task in terms of the specific business process.
Fares returned are applicable from the Board to the Off city. However, this does not mean that all fares are valid for use on the travel date specified. Whether a fare can be used depends on a number of factors relating to the rules and restrictions of the fare, and the availability of flights for a particular travel day. For example, Fare Display will show fares for travel tomorrow that require a 14-day advance purchase, and so are not valid to be used for travel tomorrow. The “validating display” option (see the <TravConstraints> tag) will restrict the display to valid fares, but users must still take account of other factors before being able to use the fare, such as booking class and flight routing.
Explain any special limits or distinct restrictions to the input data that may not be readily apparent.
Some markets – particular those in which many carriers have fares - contain so many fares that it is not possible to return them all in a response. In this case the user should use the optional fields in the <TravConstraints> tag to more narrowly focus the request.
Request:
Unless otherwise specified, use ALL CAPS in any request data.
The requirement for this function is a <FareDisplayMods> request containing at least a <QueryHeader> and a <TravConstraints> tag. The <TravConstraints> tag provides the option to add surcharges to the fare amount display that is returned, using the <Surcharges> tag. Click here to view a list of Action Codes to enter in the <QueryHeader> tag.
The <PsgrTypes> tag is used to provide passenger information, the <PFMods> tag (GFPW) is used to provide private fare information, and the <PenaltyModsTag> is used to provide penalty modifiers. Additionally, the <PTCDisplay> tag can be used to request a list of available Passenger Type Codes (PTCs).
If the <QueryHeader> node <PFPWInd> indicator is set to Y, the <PFMods> tag must also be included in the request.
Note: When entering data in the <PICReq> tag within the <PsgrTypes> tag, a user should use the ATPCo Passenger Type Codes. The proprietary Galileo by Travelport PIC codes were discontinued in early 2005.
Prerequisite tasks:
There are no prerequisite tasks for this function.
Expected response:
The <FareInfo> response, which always contains a <RespHeader> tag. The user may request the format of the response to be either <Tariff> tag or <Msg> tag format. The <Tariff> tag contains fare data for a single fare; a Fare Display request that results in 30 fares will return 30 <Tariff> tags. In addition, header information will be returned in <InfoMsg> tags. The <Msg> tag contains a formatted screen display of the headers and all the fares in the response.
Error and warning responses:
Error and advice messages will be returned in an <InfoMsg> tag:
Follow-on requests:
Follow on requests are possible from an initial (successful) Fare Display request.
After a tariff display request is made, it is often desirable to request the rules associated with particular tariffs.
Sessioned
When sessioned, a rules follow-on request can be submitted. To properly provide the requested rules, the host fares application uses two pieces of information, the tariff display line number and additional information stored on the host in the Agent Assembly Area (AAA) from the previous request.
Sessionless
When sessionless, a rules follow-on request can still be submitted but only under specific circumstances. By design all sessionless requests receive a clean AAA on the host. Since the host fares application will have no information stored in the AAA from the previous request, a sessionless rules follow-on request must provide all necessary additional information to be processed successfully. A rules follow-on request must include a <RulesInfo> tag taken directly from the previous host response. For example, a sessionless FareQuoteSuperBB_# response will contain a <RulesInfo> tag. A sessionless rules follow-on request using FareQuoteMultiDisplay_14 may now be made as long as the <RulesInfo> tag is included in the request. A sessionless rules follow-on request cannot be submitted when no <RulesInfo> tag is available. A tariff display response does not include a <RulesInfo> tag and thus cannot be followed with a sessionless rules request.
NOTE: Although a rules follow-on request will accept multiple <RulesInfo> tags, only the first one is processed. Therefore, a rules follow-on request should only contain one <RulesInfo> / <EnhancedPrivateFare>.
|
<FareDisplayMods> |
Terminal Equivalents: Apollo: $DBRDOFF… Galileo: FDBRDOFF… |
|
||||
|
Ordering |
KLR |
Min-Max |
XML Tag |
||
|
|
GFQH |
1-1 |
<QueryHeader> |
||
|
|
GFFD |
1-1 |
<TravConstraints> |
||
|
|
GFPE |
0-1 |
<PenaltyMods> |
||
|
|
GFPI |
0-1 |
<PsgrTypes> |
||
|
|
GFPT |
0-1 |
<PTCCodes> |
|||
|
|
GFPW |
0-3 |
<PFMods> |
||
|
<FareInfo> |
|
|
||||
|
Ordering |
KLR |
Min-Max |
XML Tag |
||
|
|
GFRH |
1-1 |
<RespHeader> |
||
|
|
GFMM |
0-? |
<InfoMsg> |
||
|
|
GFTD |
0-? |
<Tariff> |
||
|
|
GROM |
0-1 |
<OutputMsg> |
||