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).
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 timezones (e.g. LastModifiedDateTime, PaymentCommitmentDateTime, OfferExpirationTimeLimitDateTime…). See Reference to Times for more details.
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).
When defining rules regarding baggage allowance, 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).
Total Price at Offer-level should not be used (https://retailing.iata.org/tools/xsd_viewer/21.3.4/IATA_AirShoppingRS/?xpath=%2FIATA_AirShoppingRS%2FResponse%2FOffersGroup%2FCarrierOffers%2FOffer%2FTotalPrice).
There are two elements where birthdate is mentioned in Datalists:
The first element is to be used only in case of anonymous shopping, while the latter is to be used once the passenger data is communicated.
The same rules apply to the elements
/IATA_AirShoppingRQ/Request/PaxList/Pax/CitizenshipCountryCode and
/IATA_AirShoppingRQ/Request/PaxList/Pax/IdentityDoc/CitizenshipCountryCode
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.
The DueByAirlineAmount and DueToAirlineAmount elements within the OrderViewRS’s PriceDifferential structure should only be present if there are any outstanding amounts to be paid or refunded.
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.