The below tables list the enhancements within the latest release and links to any related implementation guidance within the implementation guide.
|CR 145b||Ticket Designator||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.|
|CR 059a||Airline Taxonomy||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.|
|CR 145a||Offer and Order Restrictions for Change, Cancel, Stopover||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. Additional capabilities were also checked (such as|
|CR 139a||Offer Commission Structure|| 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.
|CR 163a||Product Type and Negotiated Indicator||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)|
|CR 145d||Seller Margin in the Offer and Order Messages||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.|
|CR 147b||Order Retrieve Documentation and Clean Up||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.|
|CR 147b||Message Docs Deprecation in all Message||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.|
|CR 147e||Update and Documentation for Payload Attributes||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.|
|CR 147g||Order Cancel Documentation and Clean Up||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.|
|CR 147h||Augmentation Points Documentation and Update||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).|
|CR 147n||Air Doc Notif Documentation|| 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.
|CR 147o||Acknowledgement Documentation||The Document the Elements Working Group have reviewed and endorsed Implementation Guidance for the Acknowledgement Message.|
|CR 147m||Order Rules Documentation||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.|
|CR 160a||Validating Carrier Change|| 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.
|Change Request||Item||Description of Change|
|CR 146||Voluntary Servicing Supporting Order Changes and Cancellation||The change request is proposing several enhancements to support the following voluntary servicing scenarios: full cancellation, partial cancellation and order modification.|
|CR 133||Informing a Seller of Changes to an Order and Servicing|| The change request is proposing the following enhancements to support Schedule Change scenarios:
|CR 067||Notification of Order Changes||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.|
|CR 136||Accepted Payment Instruments and Associated Surcharges|| The change request is proposing several enhancements to:
|CR 148||Supporting EasyPay in the NDC and OO schemas|| IATA EasyPay, allowing Agents to remit to airlines via the BSP, is currently is not supported in the list of payment methods in the Enhanced 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.
|CR 156||Net Clearance Amount||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.|
|CR 110||Ability to handle multiple types of contacts||Proposing a solution to resolve several issues when collecting contact details (addresses at destination; emergency contact details; unaccompanied minor contact details…).|
|CR 022||Details to Determine the Context of an Interaction||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.|
|CR 128||Redirection to a hosted payment page during payment||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.|
|CR 129||Support 3DS 2.0 for Card Payment in the NDC schemas||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|
|CR 039||Send ticket information to Accounting during transition to ONE Order||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.|