Overview

This section describes the Order Versioning concept. It has close relations to:

Orders undergo changes during their lifetime, starting with Order creation and up to their most recent status. A version number allows  reference to an Order as it was at a given point in time.  The Order version should be incremented by the airline whenever a data element visible to the Seller is changed (i.e. OrderViewRS, OrderHistoryRS, OrderChangeNotifRQ).

Order Versioning principles

  1. The Order version is an integer, starting at 1 for the first version of the Order (i.e. the version created by an OrderCreateRQ message) and increasing over time by 1.

  2. The airline can decide that a set of changes leads to a single version increase. This is visible in OrderChangeNotifRQ message, where an Order version number is attached to a ChangeOperationGroup (consisting of one or multiple ChangeOperation elements).

  3. The airline may maintain an internal versioning of the Order that will typically be more granular than the external one. Only the external versioning is visible in NDC messages.

Usage of Order versioning

This allows the airline to ensure that the Offers are created for the latest version of the Order.

The best practice is:

a. For the seller: to send the version number in any ServiceListRQ, SeatAvailabilityRQ, OrderReshopRQ, OrderQuoteRQ and OrderChangeRQ message. The most recent version of the Order can be obtained by the seller with any prior OrderViewRS message from the airline (e.g., as a reply to a prior OrderRetrieveRQ message).

b. For the airline:

  1. If no version is passed in the ServiceListRQ, SeatAvailabilityRQ, OrderReshopRQ, OrderQuoteRQ and OrderChangeRQ message, proceed assuming the seller is aware of the current version of the Order.

  2. If a version is passed in the ServiceListRQ, SeatAvailabilityRQ, OrderReshopRQ, OrderQuoteRQ and OrderChangeRQ message. :

    1. If it matches the current order version, proceed as usual.

    2. If it doesn’t, then the airline may return an error.