Task: Low Fare Flexible Shopping

DO NOT USE THIS TRANSACTION: This transaction is limited to a few beta customers at this time.

The Low Fare Flexible 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.

The FareQuoteFlexShop transaction mirrors the FareQuoteSuperBB transaction, except that it allows for Flex Shopping. See the Request section for further details.

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

Section 1: Short Answer

Transaction Name:

FareQuoteFlexShop_5

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 Low Fare Shopping. Separate AAT settings are also required for each Flex Shop option. See Errors and Warning responses in Section 2.

Special limits or distinct restrictions to the input data:

• A maximum of 2 origin/destination pairs (i.e., one way or round trip) can be entered if Flex Shop is indicated in the request.
• A maximum of 8 origin/destination pairs can be entered if Flex Shop is NOT indicated in the request.
• 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:

Unless otherwise specified, use ALL CAPS in any request data.

<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>.

The Flex Shop <FlexShopMods> element increases the range of possible values in a shopping request, which increases the flexibility in the response. Multiple Flex Shop options are available; however, availability varies depending on the customer’s Tier level. See Quick Info for a more detailed description of Tier levels.

• Flex Airports.
• Flex One Days, which supports a range of plus or minus one day from departure/return.
• Flex More Days, which supports a range of dates (plus or minus one to three days from departure/return).
  • The first set of Flex More Days elements supports departure and return dates with the same ranges.
    
    In <MoreDaysInd>, ‘A’ for departure, ‘B’ for return, or ‘C’ for both departure and return can be specified. For ‘C’, the following <MoreDaysBefore> and <MoreDaysAfter> apply to both the departure and return. For example:
    
    Departure Ranges Only:
    <MoreDaysInd> = ‘A’. Departure from DEN 3 days before and 2 days after 10 December.
    
    Departure and Return Ranges:
    <MoreDaysInd> = ‘C’. Both departure and return (DEN and LAX) 3 days before 10 December/20 December and 2 days after 10 December/20 December.
    Note: The second set of Flex More Days is not needed because the number of days is the same for both departure (10 December) and return (20 December).
    
  • The second set of Flex More Days elements, <MoreDaysInd2>, are used only if the traveler wants different departure and return ranges. In other words, if the first set of Flex More Days is ‘A’ departure, and the second set of Flex More Days is ‘B’ return. For example:
    
    Separate Departure and Return Ranges for the Same Flight:
    <MoreDaysInd> = ‘A’. Departure from DEN 3 days before and 2 days after 10 December.
    
        AND
    
    <MoreDaysInd2> = ‘B’. Return from LAX 2 days before and 1 day after 20 December.
    
  • Flex Origin and Destination
    Note: For O&D to display correctly, the Board/Off City Airport Indicator in the AAGA <GenAvail> or AACS <AirVSpecificAvail> must be set to A. Miles or kilometers must be specified. The maximum distance is 100 miles or 160 kilometers.
    
  • Flex Weekend trips (ranges from Thursday to Tuesday).
    Note: For flex weekend, the user must specify a round trip, and never a one-way trip. The nature of Flex Weekend is to shop outbound Thu, Fri, Sat and return Sun, Mon, Tue for the next four weekends. If one-way is specified, the error INVLD FORMAT/DATA displays.

  Note: Flex Shop options are mutually exclusive. If multiple options are included in a single request, an error response is returned.
  

WARNING: For GWS customers, DO NOT USE MultiSubmitXml with FareQuoteFlexShop. Only use SubmitXml with FareQuoteFlexShop.

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.
  
  Note: Unlike a FareQuoteSuperBB request, a Flex Shop request does NOT organize filtered data. Flex Shop returns data in the following order:

  1. Pricing data
  2. Availability data
     
     
• 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:

For Flex Shop functionality to be accessed by users, they must have an agreement that includes the Low Fare Shopping and Flex Shop functions. The following permissions in the AAT table must be configured:

• The Low Fare Shopping field must be set to ‘Y’ (yes).
• The Flex Shop field must have the appropriate values set for the various Flex Shop options available to that user.
• If applicable, the user’s Tier level must be set for Levels 2 or 3 (be default, all users are Tier 1). As noted previously, certain Flex Shop options are permitted only for specified Tier levels.

The users may also be signed up for agency and/or airline private fares to receive private fares.

Expected response:

The order of the response displays the 1425 <FareInfo>  followed by the 1001 <AirAvail>. This order cannot be changed.

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).

The number of results in a response can vary depending on the type of Flex product requested, and whether or not Flex Shop Premium is indicated in the request.

• If Flex Shop is NOT indicated in the requested, the response returns up to a total of seven responses.
• If Flex Shop IS requested, the following table applies. Note that results vary depending on whether standard Flex Shop or Flex Shop Premium is indicated in the request.

The following chart details the maximum number of results available for the various Flex Shop options:

Error and warning responses:

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

If GWS customers use MultiSubmitXml, a Procedure 5030 metering error displays. GWS customers should not use MultiSubmitXml with FareQuoteFlexShop.

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

Tags with asterisks (*) in the Ordering column can contain CAT 35 elements on the Galileo CRS.

Related Samples

FareQuoteFlexShop_5_s1

FareQuoteFlexShop_5_s2

FareQuoteFlexShop_5_s3

FareQuoteFlexShop_5_s4

FareQuoteFlexShop_5_s5

FareQuoteFlexShop_5_s6

FareQuoteFlexShop_5_s7

FareQuoteFlexShop_5_s8

FareQuoteFlexShop_5_s9

FareQuoteFlexShop_5_s10

FareQuoteFlexShop_5_s11

FareQuoteFlexShop_5_s12

FareQuoteFlexShop_5_s13