19.2 Release Notes

Features

Ticket Designator

CR 145b | Implementation Guidance

Simple addition of a Ticket Designator Code field to separate the fare Basis Code from the Ticket Designator. There is an additional action item for 201. To move this more into an “Offer item type” field once the requirements have been fully scoped.

Airline Taxonomy

CR 059a | Implementation Guidance

The Offer Taxonomy Group has designed a means to transmit an Offer Taxonomy via the Offer and Order messages which are associated to a Services, Offer and Order Items. This change is to provide support for the Industry Taxonomy which will be published to the Developer Portal. This will allow greater detail to be sent to the Seller around the Offer and Order and compliment the Offer and Order Rules capabilities.

Offer and Order Restrictions for Change, Cancel, Stopover

CR 145a | Implementation Guidance

The Offer and Order Rules Working Group designed a programmatic way to send rule information relating to the conditions of the Offer and the Order. This includes how to send Change and Cancel Fees and Stopover Information.

Commission

CR 139a | Implementation Guidance

The Offer and Order Rules Working Group reviewed and endorsed the change to move the Commission Structure to a more appropriate place within the Offer and the Order.

Additionally, the group reviewed the internal structure of the class and defined the usage of the Commission class.

Product Type and Negotiated Indicator

CR 163a

The Offer and Order Rules Working Group reviewed the need for the Airline to present a Product Type and Negotiated Codes at the relative levels (Order, Offer, Fare Component)

Seller Margin

CR 145d | Implementation Guidance

The defines how a Seller can add a margin onto an Offer using the E&SD messages. The process does not require any changes to the current schemata and has simply been documented as one use case for Sellers and Airlines.

Order Retrieve Documentation

CR 147b | Implementation Guidance

The Document the Elements Working Group have reviewed and endorsed Implementation Guidance for the Order Retrieve RQ message in detail. With this, the group has also deprecated items which are not used within the message for clarity. These elements will be removed in 20.2.

Deprecation of Message Docs

CR 147b

The Document the Elements Working Group have reviewed and endorsed the decision to deprecate the Message Docs element within all messages. These elements will be removed in 20.2.

Payload Attributes Documentation

CR 147e | Implementation Guidance

The Document the Elements Working Group have reviewed and endorsed the use for the Payload Attributes within the messages and deprecated the elements which are not needed in the standards. These elements will be removed in 20.2.

Order Cancel Documentation and Clean Up

CR 147g | Implementation Guidance

The Document the Elements Working Group have reviewed and endorsed Implementation Guidance for the Order Cancel RQ message in detail. With this, the group has also deprecated items which are not used within the message for clarity. These elements will be removed in 20.2.

Augmentation Points Documentation and Update

CR 147h | Implementation Guidance

The Document the Elements Working Group have reviewed and endorsed Implementation Guidance for the Augmentation Points. This CR also requests a model for more structure in the Augmentation Points for legislative backwards porting of features if required. The technical solution will be drafted and refined during the modelling, but this CR is requesting business endorsement to ensure we can back-port things like 3d secure, India GST and important structures at an industry level (but also keep the same flexibility we have today).

Air Doc Notif Documentation

CR 147n | Implementation Guidance

The Document the Elements Working Group have reviewed and endorsed Implementation Guidance for the Air Doc Notif Message.

The key point here was to document the capabilities for the message. The message itself still required clean up and review, however the group wanted to extract the capabilities for 19.2 first.

Acknowledgement Documentation

CR 147o | Implementation Guidance

The Document the Elements Working Group have reviewed and endorsed Implementation Guidance for the Acknowledgement Message.

Offer and Order Rules Documentation

CR 147m | Implementation Guidance

Adds the ability for a Seller to request Fare Information during the Offer Stage and documents the capability for this message, noting that this message will not be used for programmatic fare rule information.

Validating Carrier Change

CR 160a

Today, the Validating Carrier cannot be associated to a fight service, only a non-flight service (e.g. Ancillary)

Prior to 17.1, the Validating Carrier element was found at the Service level, allowing it to be associated with any type of service (flight, bag, etc.).

During the 17.1 Offer/Order restructuring, the Validating Carrier element was moved into the new Service Definition structure which is used for the product description of non-flight services, preventing it from being associated to flight-related services.

Voluntary Servicing Supporting Order Changes and Cancellation

CR 146

The change request is proposing several enhancements to support the following voluntary servicing scenarios: full cancellation, partial cancellation and order modification.

Informing a Seller of Changes to an Order and Servicing

CR 133

The change request is proposing the following enhancements to support Schedule Change scenarios:

• supporting the Seller follow-up action

• supporting Fare Waiver to be passed from the Seller to the Airline (and back

Notification of Order Changes

CR 067

The change request, for the OrderChangeNotificationRQ message, is to establish a standard structure and a set of best practices around data synchronization to handle notification of Order changes from an Airline to a Seller/Aggregator after an unsolicited, involuntary, voluntary, and/or schedule change type changes.

Accepted Payment Instruments and Associated Surcharges

CR 136

The change request is proposing several enhancements to:

• communicate the airline accepted payment methods to the Seller

• communicate final prices to the Seller inclusive of any associated payment fees, during the shopping phase and before commitment to pay for an order.

Supporting EasyPay in the NDC and OO schemas

CR 148

IATA EasyPay, allowing Agents to remit to airlines via the BSP, is currently is not supported in the list of payment methods in the Enhance

d and Simplified Distribution schemas.

IATA EasyPay is defined in IATA Resolution Passenger Agency Conference 812 as a specific remittance mechanism and as such it cannot fit into the existing payment methods found in the schemas, until they are upgraded to accommodate it.

Net Clearance Amount

CR 156

The proposed change request – to clearly define the Net Clearance Amount – will provide clarity and will eliminate the possible confusion to each party’s obligations.

Ability to handle multiple types of contacts

CR 110

Proposing a solution to resolve several issues when collecting contact details (addresses at destination; emergency contact details; unaccompanied minor contact details…).

Details to Determine the Context of an Interaction

CR 022

This change enables Airlines to know the detailed characteristics of the interaction between the buyer and the seller so the Airline can take action for the appropriate experience to the customer.

Redirection to a hosted payment page during payment

CR 128

This change makes it possible for an Airline to instruct the Seller on how to redirect the Payer to a hosted payment page. With this change Payment Card details are entered directly onto the hosted Payment Page rather than the Seller’s page and also enables to offer Payment methods not yet covered by the NDC schemas.

Support 3DS 2.0 for Card Payment in the NDC schemas

CR 129

This change enables Airlines to implement 3DS 2.0 in the NDC schemas in order to be compliant with the new EU regulations regarding Strong Customer Authentication as per September 2019

Send ticket information to Accounting during transition to ONE Order

CR 039

This change enables to create the OrderSalesInfoAccountingDocNotifRQ for transition purposes to ONE Order. This message enables to support hybrid scenarios when some services are still in the e-ticket and others are ONE Order.

Known Defects

This section will report reported defects with the release of the standard and their corresponding action for the next release.

As these are unintentional changes to the standard, implementers are urged to adapt the current release to resolve these defects during implementation.

If you come across something that may be a defect, please email standards@iata.org or talk to an industry representative in the Offer, Order or Customer Payment Groups.