This list contains general best practice rules which apply to multiple capabilities and which should be followed across all messages affected.
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).
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.
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 creating OrderItems from an Offer containing flights (in shopping or reshopping), flights must be materialized as a Service(s) using the Service structure. When flights are included as a service they should reference the passenger segments directly within the following XPath: /IATA_OrderViewRS/Response/Order/OrderItem/Service/OrderServiceAssociation/PaxSegmentRef.
In the instance of Offers that contain OfferItem(s) with flight service(s), as well as baggage allowance, the flight(s) and baggage must be instantiated as separate services in the resulting OrderItem(s) created. Reference Worked Example: Shop and Order a Flight For a Single Passenger
Therefore, bags, as disclosed under baggage allowance, may be inserted as Services within the OrderItem containing the flight, or as separate zero-priced OrderItems adjacent to the flight OrderItem(s).
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.
Order, OrderItem, Service, and 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).
Reference the ATSB Codeset Directory for all available Status Codes.
Reference EASD Implementation Guide Worked Examples for use of statuses.
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.
PaymentStatusCode should be included to all payment confirmations.
In “even exchange” scenarios, the commitment 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.
All XML samples published in EASD Implementation Guide Worked Examples follow all of the items below as best practice. Each of these points is likely to be used in validations once the EASD Implementation Guide or schemas have been further updated in the future.
General
Element “IncludedInd” is not to be used under ServiceCriteria, as the PrefLevel element supersedes it (21.3.4 IATA_AirShoppingRQ).
When defining rules regarding baggage allowance by weight, the TotalMaximumWeightMeasure element should also be populated (e.g. 21.3.4 IATA_AirShoppingRS).
Shopping
Total Price at Offer-level should not be used in shopping responses (e.g. 21.3.4 IATA_AirShoppingRS or 21.3.4 IATA_OrderReshopRS).
The PSC standards boards voted in the 24.4 release cycle to deprecate the element TotalPrice at Offer and Order level. Please see the note labeled TSSWG-17 in the 24.4 release notes: 24.4 Release notes
Payment
Any OrderItems that have been fully or partially paid, the payment transaction(s) should reference all OrderItemIDs affected by the payment.
PaymentCommitmentDateTime should be included to all payment confirmations.
PrefLevel element within Payment functions no longer in use.