Requesting Air Tickets

AirReqRsp.xsd

Air Pricing > Create Air Booking > Air Ticketing OR
Low Fare Shop > Air Pricing (recommended) > Create Air Booking > Air Ticketing

Ticketing is typically included as a follow-on request to an Air Booking response.

Any number of tickets can be issued from one Stored Fare Quote when a booking has multiple passengers. Tickets can also be issued when there is more than one Stored Fare Quote in the PNR.

Schema

Located in AirReqRsp.xsd:

Request

AirTicketingReq is used to request tickets for an existing booking.

  1. Enter the minimum required data for the air ticketing request.

    • /BillingPointOfSaleInfo @OriginApplication
    • /AirReservationLocatorCode

  2. Optionally, add ticketing modifiers.

    Air ticketing modifiers are located in AirTicketingReq/AirTicketingModifiers.

    • @PlatingCarrier: The plating carrier for the ticket.

    • @TicketedFareOverride: Allows reissuance of stored fares that have already been ticketed.

    • /DocumentModifiers: Allow generation of itinerary and/or invoice and accounting interface message at time of ticketing.

    • /AirPricingInfoRef: References AirPricing from a shared list.

    • /TourCode: Allows tour code modification during ticket issuance. Supports sending:

      • 14 characters in requests to the Worldspan (1P) provider, as currently supported by DIR

        If AirTicketingModifiers/TourCode @Value is provided in a request to a provider other than Worldspan (1P), a warning is returned: TourCode modifier is not supported for the requested provider. Galileo (1G), Apollo (1V), and Airline Content Hub (ACH) do not support the modifier.

    • BulkTicket: Allows a user to set the amount being charged for the ticket in the provider PNR, rather than the amount paid by the user.

      • When AirTicketingReq @BulkTicket is sent, TourCode must also be included in the request or a warning is returned: BulkTicket cannot be requested without Tour Code.

      • Bulk ticket is available for Worldspan (1P) only. If a request with @BulkTicket is submitted to another provider, a warning is returned: BulkTicket is not supported for the requested provider.

    • Commission: Typically used for Net Remittance.

      Commission is available for Galileo (1G) and Worldspan (1P). If a request with AirTicketingReq/Commission is submitted to another provider, a warning is returned: Commission is not supported for the requested provider in AirTicketingReq.

      • @Level must be "Fare" or an error is returned.
      • @Type can be "Flat", "PercentBase", or "PercentTotal".
        • If "Flat", then Amount must be present or an error is returned.
        • If "PercentBase" or "PercentTotal", then @Percentage must be present or an error is returned.

        • @Amount is used for Net Remit ticketing, and documents how the commission is to be calculated/reported. Amount is an optional string. Either the Value or the Amount attribute must be populated, but are mutually exclusive.

        • @Value is used for Net Remit ticketing, and documents how the commission is to be calculated/reported. The Value is supported only if the BSP permits a Net Remit scheme. A Value that is valid for the scheme/method for customer’s BSP must be entered.

          Special characters and spaces are not supported in @Value because they are not accepted by Galileo. Value supports non-numeric commission values. When the Value attribute is populated, additional Commission attributes must have the following values:

          • Level="Fare"
          • Type="Flat"

          Value is an optional string. Either the Value or the Amount attribute must be populated, but are mutually exclusive. Additionally, if the Value attribute is populated, a valid value must be supplied in the Modifier attribute.

      • Commission @CommissionOverride is used to continue ticketing when a commission mismatch error is returned by the provider in the AirTicketingRsp: "CAT 35 COMMISSION EXISTS-ADD -OK OPTION TO OVERRIDE".

        CommissionOverride must be sent in a subsequent AirTicketingReq when an error is returned in the initial request.

        Note: Only Worldspan (1P) supports this functionality.

    • AirTicketingModifiers/TicketEndorsement: allows endorsements to be added to the ticket. Only the first 29 characters of each endorsement are added to the stored fare and saved in the Universal Record. Up to three manually-entered endorsements are allowed.

      • TicketEndorsement is available for Worldspan (1P) only. If a request is submitted to another provider that includes TicketEndorsemenet, a warning is returned: TicketEndorsement is not supported for the requested provider in AirTicketingReq.

    • AirTicketingModifiers @SuppressTaxandFee: Suppresses the tax and fees from printing with the invoice itineraries. Set to "true" to suppress taxes and fees from printing.

      • SuppressTaxandFee is available for Worldspan (1P) only. If a request is submitted to another provider that includes FormOrPayment, a warning is returned: FormOfPayment is not supported for the requested provider in AirTicketingReq.

      SuppressTaxandFee must be used with DocumentModifiers @GenerateItineraryInvoice or a warning is returned: The SuppressTaxandFee Ticketing modifier is applicable for E-Ticket or E-Ticket and GenerateItineraryInvoice option only.

    • AirTicketingModifiers/FormOfPayment: Add a Form of Payment to a ticket. See AirTicketingReq schema for Forms of Payment for more details.

    • AirTicketingModifiers/CreditCardAuth can be used to add an approval code to ticket and stored fare for credit and debit cards.

      CreditCardAuth is available for Galileo (1G) and Worldspan (1P). If a request is submitted to another provider that includes CreditCardAuth, a warning is returned: CreditCardAutho is not supported for the requested provider in AirTicketingReq.

      If a CreditCardAuth is added with a reference to a cash or check form of payment, an error is returned: "Invalid Form of Payment for Credit Card authorization".

      If an AirPricingInfo already has an existing Payment, then the Payment is added to the ticket, no new Payment is created. If the existing Payment already has a CreditCardAuth, then the existing CreditCardAuth is removed and a new CreditCardAuth must be added.

      Review the schema table for CreditCardAuth in AirTicketingReq > FormOfPayment > Credit Card > CreditCardAuth

    For Worldspan , when the StoredFareQuote is different from the StoredFare at ticketing, Universal API returns an error message that there is a difference in price. To allow users to bypass the error and issue the ticket, in release 17.4 and later, the NoComparisonSFQ attribute has been added to AirTicketingModifiers. By default @NoComparisonSFQ is set to false and will override an existing StoredFareQuote. This issue does not affect Apollo or Galileo.

  3. Other ticketing scenarios include:

    By default, Air Ticketing requests check for multiple Ticket Records; if multiple Ticket Records are found, an error is returned. To issue tickets for additional passengers in a Worldspan (1P) booking, the Air Ticketing check can be overridden, allowing ticketing for individual passengers.

    The Air Ticketing check can be overridden in the following requests.

    • Universal Record Modify/Air Add request can be sent to override the ticketed Ticket Record. This override provides the capability to issue a ticket against a Ticket Record that was previously issued. A subsequent Air Ticketing request can then be sent to issue a ticket for another passenger in the stored fare.

      • Add the ticketing override to the Universal Record by sending a Universal Record Modify request. The override is specified in Air Add/Air Pricing Modifiers/Ticketing Modifiers/Document Options/Override Option=ReIssueTicketedStoredFare.

      • To issue tickets passengers other than the first one in the booking, send a Air Ticketing Request next.
    • An Air Ticketing request with the override allows the ticketing of multiple passengers on a single Ticket Record. To override the Air Ticketing check, set the AirTicketingModifiers/TicketedFareOverride attribute to "true". By default, this attribute is false.

    Currently, Traveler-Specific ticketing is possible when all the PTCs are under different AirPricingInfoGroup attributes. E.g., AirPricingInfoGroup="1" AirPricingInfoGroup="2" etc. In other words, the fares are filed separately. Otherwise, Universal API returns the error, “All AirPricingInfos associated to an AirPricingInfoGroup should be provided in the request.”

    • Passenger-Specific Ticketing is implemented for Galileo (1G) and Worldspan (1P). This functionality is not supported for Apollo (1V) or Airline Content Hub (ACH).

    • AirTicketingReq/AirPricingInfoRef/BookingTravelerRef/@Key is used to perform Booking Traveler Specific Ticketing (with single FOP). See Form of Payment for Ticketing Modifiers.

    • PaymentRef@Key was added to AirTicketingReq/AirPricingInfoRef/BookingTravelerRef/ to facilitate Multiple FOP per booking traveler. The cardinal for this element is 0..3.

    • OB Fees Charge indicator is sent with Credit Card FOP within Multiple FOP.

    • AirTicketingReq/AirTicketingModifiers/common:CreditCardAuth has the value 1..unbounded due to multiple booking Traveler.

     

    Any number of tickets can be issued from one Stored Fare Quote when a booking has multiple passengers. If an Infant in Lap (INF) passenger type is included in the Stored Fare, tickets are created for all the adult passengers and the INF passengers. For international fares, the INF pricing in AirPricingInfo may have only taxes. For domestic fares with a Unites States Point-of-Sale and US Itinerary, the AirPricingInfo may have all zero (0) amount values. Because not all carriers or itineraries have only taxes or a zero amount for INF passengers, a fare may occur for the INF passenger.

    When permitted by the provider, tickets may be reissued in certain cases, such as reissuing a ticket after voiding the ticket and verifying the stored fare. See Reissuing Tickets for details.

    Traveler-specific Ticketing is allowed on Worldspan .

    Some Universal Air Travel Plan (TP) credit cards respond to a ticketing request with a request for Detailed Billing Information (DBI). Ticketing does not occur until the DBI data is sent in AirTicketingReq.

    The required information is returned in the initial ticketing response in the DetailedBillingInformation element. Up to 10 fields may be returned, and the amount of information requested varies by individual card. After the information is received, another AirTicketingReq that includes the DetailedBillingInformation element must be submitted.

    Note: When the DBI data is successfully ticketed against, it is not required again for that PNR.

Response

AirTicketingRsp is returned. The ticketing response contains:

Applied Residency

Applied residency type returns in booking and ticketing retrieve responses, so that the nationality from the applied residency type by passenger line or data can be applied in a future exchange. This is useful because of taxes based on nationality. For example, Mexico has a tax for foreigners and Argentina has two taxes for residents. Release 23.1
AirSolutionsChangedInfo/AirPricingSolution/AirPricingInfo/PassengerType @ResidencyType

ETR

Errors and Warnings

The following errors and warnings may occur:

Ticketing messages are returned from providers along with corresponding textual descriptions of the error codes. Ticketing error codes are generated by the provider and passed through Travelport Universal API.

When received, the following provider (host) error/warning messages and corresponding two-character host error codes are returned in AirTicketingRsp:

  • CC: Credit Card Restrictions Apply. Confirm Ticket Issuance.
  • CO: Fare changed
  • DB: Detailed Billing Data for Credit Cards (1G only)
  • EE: Itinerary is eligible to issue Eticket
  • ER: Refund
  • ET: Electronic ticket failed
  • EX: Exchange
  • FC: Fare construction
  • FX: DFX screens
  • MA: MCO TKPMCO MCOA data
  • ME: Form of payment error
  • MO: Misc. Charge Order
  • MR - Multiple receivable
  • NM: $NME screen
  • OK: Ticket issued
  • TA: Tax breakdown screen
  • TK: Initial ticketing entry
  • UC: Undecodable city code

  • ZP: ZP Tax breakdown screen

Exceptions

  • Galileo supports Itinerary (IT), Back Office (BO), and Ticket (TK) device types only.

  • Galileo does not support Ticketing Modifiers with BookingTravelerRef for the DI line with Name Select.
  • Galileo does not support the Air Ticketing fare override, which allows the ticketing of individual passengers within a booking.

  • Universal API does not have a discrete equivalent to an end transact (PNRBFEnd). When a created, modified or canceled booking is submitted, Universal API internally processes the end transact as part of the request. There is also no equivalent functionality to PNRBFIgnore.

All Apollo agencies require a ticket printer.

Apollo does not support:

  • Ticketing Modifiers with BookingTravelerRef for the DI line with Name Select.
  • TrueLastDateToTicket
  • The Air Ticketing fare override, which allows the ticketing of individual passengers within a booking.
  • Worldspan supports the following device types:
  • Itinerary (IT)
  • Back Office (BO)
  • Ticket (TK)
  • Auditor (A)
  • Agent (T)
  • Passenger Receipt (P)
  • Charge (C)
  • Reissue (R)
  • Worldspan supports the following document types:
  • Blank Card (BC)
  • ATB Ticket Stock (H1)
  • Plain Paper (PP)
  • Layman’s Language (LN)
  • Worldspan supports Ticketing Modifiers with BookingTravelerRef for the DI line with Name Select.
  • Worldspan does not generate ticket numbers for Infant in Lap (INF) passengers for domestic journeys inside the United States. When the Stored Fare is ticketed, tickets are created for adult passengers only.
  • To ticket multiple stored fares, Worldspan requires the Ticket Record (TR) and the Name Select when ticketing.
  • To ticket a singer passenger when multiple passengers exist, use the Name Select when ticketing.
  • Worldspan does not support TrueLastDateToTicket.

  • Worldspan supports multiple Ticketing Instruction Lines for a stored fare, and ticketing using one or more ticketing instruction lines. AirTicketingReq contains TicketingModifiersRef child element, which contains an AirPricingInfoRef child element. TicketingModifiersRef store references to the Ticketing Instruction Lines that were used during Air Ticketing. AirPricingInfoRef child of TicketingModifiersRef stores references to any stored fares:

    • If TicketingModifiersRef contains an AirPricingInfoRef child element, the Ticketing Instructions are applied to the stored fare corresponding to the AirPricingInfoRef.
    • If TicketingModifiersRef does not contain an AirPriceInfoRef child element, the ticketing instructions are applied to all the stored fares in the PNR.

    Travelport Universal API supports multiple Ticketing Instruction lines for a stored fare only in the UniversalRecordRetrieveRsp, UniversalRecordImportRsp, and AirTicketingReq. Therefore, the addition, modification, or deletion of Ticketing Instruction lines is not supported for segments that are created using Universal API services.

  • In Terminal Data, the auto-pricing data stored in the PNR includes details such as Date, Time, and Agent Information. However, these details were previously not available in Universal API.

    • With Universal.xsd, Universal API maps the information from the stored auto-pricing data in the PNR into the AirPricingInfo/ActionDetails/ element, including all data for @PricingType; StoredFare, StoredFareQuote, PricingInstruction, and TicketRecord information.

    • Only data that is available is mapped. For example, @EventTime values are not always returned, and only the Date values available.

For a more complete list of functionality available from various ACH carriers, see ACH Carriers Functionality. Because functionality for carriers may be subject to change, always confirm functionality directly with the ACH carrier before implementation.

  • All ticketing functions are handled by the ACH supplier.

  • ACH suppliers are all ticketless or e-ticket. A TCR (Ticketless Carrier Record) is built at the time of booking (or when the Form of Payment is added).

  • Some ACH suppliers (DY) return e-ticket numbers, but these cannot be used in the traditional manner. They are returned as TCR elements.

  • ACH does not support TrueLastDateToTicket