General Guidance

This list contains general best practice rules which apply to multiple capabilities and which should be followed across all messages affected.

General

• RQ messages, specifically within Order creation/servicing flows, should include the identification of the Seller and Carrier (optional could also include participants, such as aggregators) Distribution Chain, with the exception of AirShoppingRQ (which does not require Carrier, as it can be used for anonymous shopping across multiple airlines). Ordinal values should begin with “1”.

• Currency codes should always be present against any element containing a monetary amount.

• All monetary amounts should reflect the number of decimal precision as enforced by Resolution 024d.

• When there is a need to associate an infant on lap with its parent, the PaxRefID element must be used in the correct direction, i.e. the infant must reference the parent (https://retailing.iata.org/tools/xsd_viewer/21.3.4/IATA_AirShoppingRS/?xpath=%2FIATA_AirShoppingRS%2FResponse%2FDataLists%2FPaxList%2FPax%2FPaxRefID).

• Element “IncludedInd” is not to be used under ServiceCriteria, as the PrefLevel element supersedes it (https://retailing.iata.org/tools/xsd_viewer/21.3.4/IATA_AirShoppingRQ/?xpath=%2FIATA_AirShoppingRQ%2FRequest%2FOfferCriteria%2FServiceCriteria%2FIncludeInd).

• Mandatory elements must contain values, despite schema-validation allowing them to remain empty. This best practice should also be extended to all optional elements - elements without values (empty elements) should not be included in the XML payload.

• Departure and Arrival times in flight segment and flight leg details should not contain timezone offsets (must be in local times only). All other timestamps should, however, specify a timezone, specifically using only UTC (e.g. LastModifiedDateTime, PaymentCommitmentDateTime, OfferExpirationTimeLimitDateTime…). See Reference to Times for more details.

• When defining rules regarding baggage allowance by weight, the TotalMaximumWeightMeasure element should also be populated (e.g. https://retailing.iata.org/tools/xsd_viewer/21.3.4/IATA_AirShoppingRS/?xpath=%2FIATA_AirShoppingRS%2FResponse%2FDataLists%2FBaggageAllowanceList%2FBaggageAllowance%2FWeightAllowance%2FTotalMaximumWeightMeasure).

Shopping

• Within Offers (excluding a-la-carte Offers), there should always be at least one OfferItem marked with the MandatoryInd=true. Absence of this element implies the OfferItem is optional (same as using MandatoryInd=false).

• Total Price at Offer-level should not be used in shopping responses (e.g. https://retailing.iata.org/tools/xsd_viewer/21.3.4/IATA_AirShoppingRS/?xpath=%2FIATA_AirShoppingRS%2FResponse%2FOffersGroup%2FCarrierOffers%2FOffer%2FTotalPrice or https://retailing.iata.org/tools/xsd_viewer/21.3.4/IATA_OrderReshopRS/?xpath=%2FIATA_OrderReshopRS%2FResponse%2FReshopResults%2FReshopOffers%2FOffer%2FTotalPrice).

Order Management

• In servicing scenarios where a price differential is returned (following the replacing or removal of an existing OrderItem), the PriceDifferential structure needs to be persisted in the OrderViewRS until payment is fully allocated to those affected OrderItems.

• Delivery Status elements should always be present in OrderViewRS (https://retailing.iata.org/tools/xsd_viewer/21.3.4/IATA_OrderViewRS/?xpath=%2FIATA_OrderViewRS%2FResponse%2FOrder%2FOrderItem%2FService%2FDeliveryStatusCode).

  • Unpaid OrderItems: DeliveryStatusCode=”CONFIRMED”.

  • Paid OrderItems: DeliveryStatusCode=”READY TO PROCEED”.

  • Cancelled OrderItems: DeliveryStatusCode=”REMOVED”.

  • Reference the ATSB Codeset Directory (codeset DELIVERYSERVICE) for all available Delivery Status Codes.

Payment

• If the Seller associates a Payment Method preference to any specific OfferItemIDs, the Airline should return precisely calculated payment surcharge amounts for those specific OfferItems.

• Any OrderItems that have been fully or partially paid, the payment transaction(s) should reference all OrderItemIDs affected by the payment.

• PaymentStatusCode and PaymentCommitmentDateTime should be included to all payment confirmations.

• In “even exchange” scenarios, the committment to accept a change (in the absence of an amount to be paid) should be done by setting the PaymentTypeCode and PaymentBrandCode elements to “OT” and setting the amount to zero.

• PrefLevel element within Payment functions no longer in use.