The airline is able to notify the Seller of the airline-initiated Order changes and receive the acknowledgement of receipt of notification from the Seller. Notification includes use of order versioning, grouping of change operations and use of reason codes/change types features, as proposed in 19.2 and later.
The Seller is able to receive notification of the airline-initiated Order changes and acknowledge receipt of notification. Including the ability for Seller to make use of Order version numbers to detect whether they are in sync with the latest version of the Order.
Capability: Notification of Airline-initiated changes on an Order: https://standards.atlassian.net/wiki/spaces/EASD/pages/574455903
Concept: Seller Follow-up Actions:
Concepts: Offers & Orders: https://standards.atlassian.net/wiki/spaces/EASD/pages/574750733 and https://standards.atlassian.net/wiki/spaces/EASD/pages/574717963
Capabilities: Offers & Orders: https://standards.atlassian.net/wiki/spaces/EASD/pages/574750721 and https://standards.atlassian.net/wiki/spaces/EASD/pages/574259560
Worked Examples: Offers & Orders: https://standards.atlassian.net/wiki/spaces/EASD/pages/574881865 and https://standards.atlassian.net/wiki/spaces/EASD/pages/574619770
For all capabilities, please also consult the list of general guidelines for adherence to best practices that span across several capabilities and messages: |
The OrderChangeNotifRQ (OCN) message (as well as OrderHistoryRS in parallel) have been re-designed in v19.2 to improve data synchronization between an Airline and a Seller. The OCN messages is now particularly efficient at synchronizing elements that have changed within an Order, and the message size is optimized and kept lean, improving performance.
The following are the main components of an OCN:
ChangeOperation - contains the information that has changed within the Order, as well as metadata related to the change. This structure is unbounded and can be repeated to package change operations atomically. Each operation should be either adding, deleting or replacing data in an Order.
ChangeDateTime - timestamp of when the change occurred in the Airline’s Order Management System.
ChangeTypeCode - the type of change operation occurring (typically reflecting the add/delete/update functions above).
ReasonsCode - a more business-contextual reason behind the change (e.g. “weather” in case of a disruption scenario).
Valid codes for the elements ChangeTypeCodes and ReasonCodes have been defined in v21.1 and are available in the IATA EDIFACT and XML CodeSet document (specifically codesets CHR and CHT).
New / Old - Structures holding all elements found in OrderViewRS. The use of these two structure drives the type of operation being performed:
New - Information is being appended to the Order.
Old - Information is being removed from the Order.
New and Old - information is being replaced/updated in the Order (the data in New showing what should be replacing data from the Old structure).
New and Old should only contain values for elements that are changing. No unchanged elements should be repeated in the OCN, as this would imply that they should be treated as changes by the receiving Seller system and would also defeat the purpose of reducing/optimizing messages size.
Each element that is subject to changes must be accompanied by the persistent ID closest to each respective element. This allows the Seller to know in which instance of a core object the change is taking place. Persistent IDs are references to an Order’s data objects which are permanent to that Order in and Airline’s OMS. e.g. OrderID, OrderItemID, ServiceID, PaxFlightSegmentID, PaxID, PaymentID are some examples of IDs which should remain unchanged from the moment of Order creation. For a full list of persistent IDs, please consult the EASD Online Implementation Guide https://guides.developer.iata.org/v213/docs/identifier-usage
OrderVersion - Concept introduced in v19.2 to support OrderChangeNotifRQ and OrderHistoryRS functionality. It is now necessary for an Order Management System to keep track of changes, both voluntary and involuntary, that change the information of the Seller’s view of an Order. Only changes that would otherwise affect an OrderViewRS should increment the version of the Order (as there would certainly be many changes in the Airline’s OMS related to an Order, but which are not pertinent to the Seller’s consumption).
The Seller can use the OrderVersion from simple OrderRetrieveRQ/OrderViewRS API calls to determine if they are in sync with the latest version of the Order, as per the Airline’s OMS. If, for any technical reasons, the Seller was unable to receive a particular OCN for a given change, they are likely to find out by retrieving the Order and verifying the OrderVersion against what the Seller is currently storing on their system. The recovery for this scenario would typically be to request the OrderHistory, which is also designed to store multiple changes with the same approach as the OCN. This would allow the Seller to re-synchronize their platform to the latest version of that Order.
Optionally, in addition to the changes carried in the New/Old structures, the OCN can also carry the entire snapshot of the Order (element OrderBaseline), on top of which the values in the New/Old structures need to be applied. This assists with some implementations, but is not required if the Seller also has a way of storing each version of the Order following voluntary and involuntary changes. Note: OrderBaseline is a representation of the Order prior to the changes that are being carried in the New/Old structures.
Minimum Requirements |
|---|
OrderChangeNotifRQ/Acknowledgement |
Minimum Requirements |
|---|
OrderChangeNotifRQ/Acknowledgement |