Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 23 Next »

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 timezones (e.g. LastModifiedDateTime, PaymentCommitmentDateTime, OfferExpirationTimeLimitDateTime…). See Reference to Times for more details.

Shopping

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.

  • No labels