Task: Low Fare Shop Request

The Low Fare Shopping tool allows a user to find the best price options for a proposed journey, using origin/destination and date information, without requiring a booked itinerary. It allows a user to enter criteria to limit the shopping request, such as time period, specific carriers to include or exclude, private fare modifiers, and passenger types.

See the Air Shop FAQ for questions regarding all air shopping transactions.

Section 1: Short Answer

Transaction Name:

FareQuoteSuperBB_11

Can any other transaction(s) perform this same task?

Yes. Use FareQuoteFinder_# to fare shop if you have a booked itinerary and you want other itinerary and price options which fulfill the origin/destination and date parameters.

Can this task be performed in a sessionless environment?

Yes.

Are the request and response identical on both the Apollo and Galileo systems?

Yes.

Industry-specific knowledge required to understand this task in terms of the specific business process:

• To receive web/private fares, the requestor must know the Pseudo City Code under which the fare was filed.
• The requestor must know valid passenger types.
• The requestor understand which flights (contained within the child elements of <RulesInfo>),  relate to which price (contained within the child elements of <GenQuoteDetails>) and which booking codes pertain to which flight.
• A special setting in the AAT (Agency Account Table) is needed for access to Galileo Optimal Shopping. See Errors and Warning responses in Section 2.

Special limits or distinct restrictions to the input data:

• A maximum of 8 origin/destination pairs can be entered.
• A maximum of 4 unique passenger types can be entered.
• A maximum of 24 carriers in the carrier preferences can be entered. However, a maximum of 4 carriers is recommended, as this will maximize the availability scoop.

Section 2: Detailed Description

Request:

<AirAvailMods> must be sent with a general availability <GenAvail> child element; arrays of origin/destination pairs can be sent. The <SuperBBMods> element must also be sent with <PassengerType>.

Other data in the request can include:

• (Optional) <AirVPrefs> provides the ability to include or exclude air vendors via the array <AirVAry>. <AirVAry> can contain up to 24 <AirVInfo> items. Including more than 24 <AirVInfo> items results in a CRS error.
  

• If <Optimize> is sent on the request, then response data is organized and filtered according to data contained in <Optimize>. To minimize the amount of data returned, the requestor can specify only the reply elements that they to receive.
  

• A <GenQuoteInfo> element to include ticket dates in the request. If no dates are sent, today’s date is assumed.
  
• For a historical fare quote, <GenQuoteInfo> must include ticket dates. For an accurate historical quote, a <SegSelection> element with <FareType> set to ‘F’, and a fare basis code <FIC> are recommended.
  
• If the user wishes to define whether the most restrictive rules for the entire quote (single fare component) are returned in <RsvnRules>, <GenQuoteInfo> must be sent with the <RulesProcess> indicator set to N. If the indicator is set to Y, applicable rules are returned in <AdvRsvnTktRule>/ <MinStayRule>/ <MaxStayRule>/ <SalesRestrictionsRule>/ <PenaltiesRule> per fare component.
  
• For an Airline Private Fares quote, the <PFInfo> element must be sent with the indicator for <ReqAirVPFs> set to ‘Y’ and <StartODRange> and <EndODRange> must be included. Within the Private Fares section, the types of fares considered can be further restricted for the input segment/segment range. Limitations can include:
  • The types of fares (both public and private fares or only private fares).
  • The types of private fares (only airline private fares or only agency private fares).
  • The requirement for account code usage (only fares for the input account code and input contract, if any or no restriction on account code usage).

  The response formats do not vary if Airline Private Fares are returned.
  

• For public and private fares to be considered in the response, the <PublishedFaresInd> child element in <SegSelection>  must be set to 'Y'. The lowest fares, whether public or private are returned. If public fares will not be considered, <PublishedFaresInd> must be set to 'N'.
  
• The Galileo CRS includes cancel/rebook change fees (coded in Category 16 Penalties) in a fare quote. Under certain conditions, the airline may waive these fees by providing a waiver to the agency. The <WaiverMods> allows the agent to provide a waiver to bypass automated change fee collection. This waiver code can be 10-14 alpha-numeric characters long.
  
• Fares with rule category 35 (CAT 35) data, which is net fare information, will potentially contain multiple fare levels: sell, net, ticket-audit, ticket-passenger. For users requesting the additional CAT 35 data, this information is returned in the elements identified with an asterisk (*) within the <FareInfo> (1425 Data Record) response (see the <FareInfo> Response table in Section 3).
  Note: The <EnhancedPrivateFare> (GFPX KLR) is used for rules follow-ons. It is returned with rules follow-on transactions so that the correct rules text displays. Do not use or modify anything in this element.
  
• The <PassengerType> element support several functions. <PassengerType> can be used to:

• Supply personal geography details in the request, which allow pricing of fares that have geographical restrictions, such as country residency or state employment. Fares that have geographical restrictions are not quoted unless matching personal geography information for the passenger is sent in the request.

Without appropriate personal geography information, a user may not receive a lower fare based on their request. If a lower fare is NOT returned, either higher fares or an error response are returned.

• Enter an amount increase (IF) or decrease (DF) of more than six characters when necessary, e.g., 'IF20000'.

• Supply Spanish residency modifiers in the request, which allows the pricing of Spanish resident fares:

  • A Spanish resident fare can only be quoted if the appropriate Spanish resident PTC and Spanish resident modifier is given in the request.
  • You must use the Spanish modifier in conjunction with the residency SSR from the booking file to provide required residency information.

• Enter a PTC and a discount in the <PassengerType> in a single request.

  Note: The use of proprietary Galileo by Travelport Passenger Information Codes (PIC) was discontinued in early 2005. PICs have been been replaced with ATPCo Passenger Type Codes (PTC).

  Previously, PIC data was sent in the <PIC> child element within <PsgrMods> or <FqPicOnly>. <PsgrMods> searches for a lower fare with the specified passenger type. If a lower fare does not exist, it sends back the lowest adult fare. <FqPicOnly> only searches for a lower fare for the specified passenger type. While these elements are still available, it is now recommended to send PTCs using the <PTC> child element in <PassengerType>.

  The <PassengerType> element also allows the <PricePTCOnly> (PIC Only) search to be requested for fares for a specific PTC only (similar to <FqPicOnly>).

• Override any fare ticket codes or designators using the <TkDesignator> and <TkCode> elements.

Availability and Classes of Service
There are three basic ways to request flights with respect to flight classes:

• Class-Specific Request
  Returns flights for a specific class only.
  
  Use the <Class> child element in <GenAvail> (AAGA)/<AirAvailMods> (Data Record 1000) to specify the class 'F’, ‘C’, or ‘Y’.
  The response returns flights available only for that class. If that specific class is unavailable for one or more legs of the journey, the response is: NO AVAILABILITY FOR THIS REQUEST.
  
  Note: Using the 'S' option in <Class> yields results for all scheduled flights, regardless of the number of passengers in the party, and actual seat availability.
  

• Downgradeable Class Preference
  Returns flights for a preferred class, with downgrade functionality.
  
  Use the <ClassPref> child element in <ClassPrefs> (GQCL)/<SuperBBMods> (Data Record 1400) to show the class preference 'F’, ‘C’, or ‘Y’.
  Leave <Class> (described above) blank.
  The response returns all flights available for that class, including flights for which a class downgrade is possible for one or more legs of the journey when the preferred class is unavailable.
  
  Note: the 'S' option is not valid for <ClassPref>.
  

• Return all flights for all classes
  Return flights for all classes available.
  
  Leave both elements, <Class> and <ClassPref> (described above) blank.
  
  Note: Using the 'S' option in <Class> yields results for all scheduled flights, regardless of the number of passengers in the party, and actual seat availability.
  
  IMPORTANT: There is also <Class> element in both <AirVSpecificAvail> (AACS) and <SpecificAvailMods> (AASA). It is not advised to use either of these elements for FareQuoteSuperBB requests. FareQuoteSuperBB is designed to work only with <GenAvail> (AAGA).

Prerequisite tasks:

To use the transaction, a user must be signed up for the Low Fare Shopping function and have the appropriate field in the AAT table set to Y (yes). The user may also be signed up for agency and/or airline private fares to receive private fares.

Expected response:

The response sends back <FareInfo> with:

• The summary fare information in <GenQuoteDetails> and <FlightItemCrossRef>.
• Related flight information (referenced in the <FareInfo> summary) in <AirAvail>.
• All other fare details in the remainder of the <FareInfo> element (see the Response Tables in Section 3).

Error and warning responses:

Additionally, the following error/warning messages can display:

• Invalid Sequence (origin/destination in wrong order).
• Invalid dates, city codes, carriers, etc.
• Error to indicate you are not signed up to use FareQuoteSuperBB_#.
• Multiple Fares Exist for Same Fare Amount.

Additional errors may display in the <ErrorCode> tag in the Response. See the main help system topic Troubleshooting > Errors > Transaction and Translation Error Descriptions.

Follow-on requests:

The follow-on requests for this transaction are:

• FareQuoteMultiDisplay_# – Rules Display.
• PNRBFManagement_# – Air Segment Sell via Reference Sell.

Section 3: Tables

Request (Input) Tags

Response (Output) Tags

Related Samples

FareQuoteSuperBB_11_s1

FareQuoteSuperBB_11_s2

FareQuoteSuperBB_11_s3

FareQuoteSuperBB_11_s4

FareQuoteSuperBB_11_s5

FareQuoteSuperBB_11_s6

FareQuoteSuperBB_11_s7

FareQuoteSuperBB_11_s8

FareQuoteSuperBB_11_s9

FareQuoteSuperBB_11_s10

FareQuoteSuperBB_11_s11

FareQuoteSuperBB_11_s12

FareQuoteSuperBB_11_s13

FareQuoteSuperBB_11_s14