Order History

Overview

The history of an Order is managed and tracked by the Airline in their Order Management System from the time of Order creation. Tracked changes can be comprised of Seller- and Airline-initiated changes. These details can be retrieved at any time by the Seller.

Technically, the Order history attempts to capture all the information that differs between one version of an Order and the next, following a change requested by any actor in the Order. It returns an accumulation of all changes within the lifecycle of an Order in sequential/chronological order . The data involved in each tracked change follows a similar principle used when an Airline notifies a Seller of a change (OrderChangeNotifRQ). Therefore, the only information that is needed in each group of changes is the specific data elements that have actually changed, as well as the related IDs necessary to indicate where those elements are located within the Order. Data that has not changed should not be included in the ChangeOperation.

Structure of History

The structure of historical details of an Order in OrderHistoryRS is composed primarily of two parts:

1. The original snapshot of the Order at the time of its creation, starting at version “1”.

2. Any changes made to the Order following its creation.

These changes may be grouped together, where each group of changes collectively increases the version of the Order by one. These groups are represented within a “ChangeOperationGroup”, which can in turn consist of one or multiple “ChangeOperation” elements. Below is a representation of the hierarchy of information in OrderHistoryRS:

• ChangeOperationGroup - [each ChangeOperationGroup can contain as many ChangeOperations needed to collectively increase the version of the Order. OrderVersion is defined at this level, i.e. the resulting version of the Order incurred after having applied the changes specified in this group of ChangeOperations]. Note – the interpretation of the order of each ChangeOperationGroup is defined by the OrderVersion, with each value incrementing by one integer value for each group of change operations.

  • ChangeOperation - [contains add/delete/replace type operations on any changes applied anywhere within an Order]

    • ChangeDateTime - [Timestamp for when this change is effective from in the OMS]

    • ChangeTypeCode - [The type of change being made to the Order – see ATSB Codeset Directory “CHT”]

    • ReasonCode - [The reason behind the change being made to the Order – see ATSB Codeset Directory “CHR”]

    • New - [data elements to be appended to Order structure or to replace elements defined in “Old”]

    • Old - [data elements to be physically removed from Order structure or replaced by elements defined in “New”]

Open

Order History at Time of Order Creation

The first version of the Order should be presented in the “New” structure in its entirety (with nothing in “Old”), be placed in a single ChangeOperation, and with “OrderVersionNumber” set to “1”.

Once an Order has been created, if a Seller requests the history of an Order before any Seller- or Airline-initiated changes have occurred, they should simply see the equivalent of an entire snapshot of the Order, as it would appear if retrieving it through OrderRetrieveRQ.

Subsequently, changes can be structured as defined in the sections above, depending on the type of change.

This allows the Seller system to interpret and reconstruct the state of an Order at any point in its lifecycle simply by using the initial Order (version 1) as a baseline, and applying subsequent incremental changes onto this baseline.

How to Capture Changes

Three basic types of operations can affect the information of an Order: addition, removal, and replacement of information. To capture these, the “New” and “Old” structures need to be used in the following combinations:

1. Adding information to an Order:

   1. Include new data elements only in the “New” structure. “Old” should remain empty.

2. Removing information from an Order:

   1. Inversely to adding information above, the removal makes use of only the “Old” structure, which includes the data that should no longer appear in the Order.

3. Replacing information in an Order:

   1. Make use of both “New” and “Old” by defining the data in “Old” that is intended to be replaced by the data in “New”.

Design Considerations

The decision of how and when to use New, Old or both depends on each Airline’s implementation, acknowledging that the schemas provide flexibility in this regard. For example, replacing data (i.e. making use of New and Old together) could also be achieved by two consecutive ChangeOperations of New followed by Old, or vice versa.

The important thing to consider is that all changes defined within one group of ChangeOperations (i.e. all occurrences of ChangeOperation within each ChangeOperationGroup) are to be interpreted atomically. This means that when the Seller parses through changes within the group, all changes are to be interpreted together and in their intended sequence. This similar design principle is also, and to a greater extent, important for the functioning of OrderChangeNotifRQ, which works very similarly to OrderHistoryRS in this regard.

Identification of Change source 

The Airline may optionally attach the identity information of the Seller to the Seller-initiated changes by using the “DistributionChain” structure. This is especially useful in case an Order could be serviced by more than one Seller (e.g. multiple Agency IDs involved).

Similarly, the Airline may wish to include their identity to change operations that were triggered by themselves, for increased clarity and transparency.