Interface: PoweredPNR

1 Introduction

ReduceNIP

This function provides the possibility to reduce the numberof passenger contained in a group PNR.

DeleteTSM

ChangeElement

This function allows user to accomplish modification on PNR elements. It is based on the cryptic element change function and it follows the same behavior.

NameChange

This function provides the possibility to update a passenger name or change a passenger name.

Split

This function divides a PNR with 2 or more passengers into two different records.

AddFrequentFlyer

This function provides the possibility to add a Frequent Flyer card.

CreateTSM

UpdateTSM

This function is used to update data of a particular TSM.

Cancel

This function allows the user to cancel elements of a PNR.

TransferOwnership

The TransferOwnership function is used to change the office of responsibility of a PNR.

AddRedemption

This function provides the possibility to request a redemption by adding an SSR FQTR element in a PNR.

Retrieve

This function retrieves a PNR and/or its contents. This function also retrieve a list of PNRs

ListTSM

AddMultiElements

Main operations that create and modify elements within a PNR.

DisplayHistory

This function is used to retrieve the history of a PNR which contains creation and modification information.

DisplayTSM

RetrieveByOARloc

The transaction Retrieve active PNRs by OA record locator enables agents to retrieve the PNRs by the record locator that the customer has as a reference from its booking originator.

There is an OA record locator present in a PNR: the true originator (original booking source)record locator stored in the responsible line. It corresponds to the PNR created originally in another system ie. GDS or external airline system. This record locator is retrievable using the Function Retrieve by OA Record Locator.

UpgradeRedemption

This function provides the possibility to request a class upgrade, by adding an SSR FQTU in a PNR.

2 Considerations

The PNR

For each reservation made, the Amadeus host system assigns a unique six character codecalled a record locator and identifies this record as a Passenger Name Record (PNR).

PNR Elements

A PNR contains all the details pertaining to a passenger's trip reservation consistingof system mandatory and optional segment and data elements.The following is a breakdown of these elements:

* At least one of each is required.

The system mandatory elements must be created prior to storing thereservation in the system, but may be modified(within the guidelines of the particular element) at any time after thereservation is made.The optional data elements may be added, ormodified (within the guidelines of the particular element) at anytime.

In the Reply sample above, the field elements of/ originDestinationDetails/ itineraryInfo could all be repetitive, whereeach level ([1]) could be repeated and would bereturned in the reply structure.

Note: the further down in the reply, the additional sub indexed itemsunder the / originDestinationDetails/ itineraryInfo levelone ([1]) could additionallybe repeated as is done in a few instances in the reply given here.

TSM Manipulation

A Miscellaneous Document) (MD) is a document used to collect charges associated to a passenger for any kind of services except standard air transportation. The Transitional Stored Miscellaneous Document (TSM) is the pricing record of the MD, it stores its data.

The 3 different types of Miscellaneous Documents are:

• type M: miscellaneous charge order. Used to cover collections for service fees, hotel accommodations, inclusive tours, car hire, refundable balances and other types of collections when standard air transportation tickets are not suitable.
• type F: service fee to collect Service Fee charges (US, BA, TASF). Described as type S in specifications for US market and BA, and type F for TASF.
• type E: excess baggage used to collect Excess Baggage charges. Described as type X in specifications.

The TSM is accessible for all MD types, except type F for US market and BA.

In addition a fourth flavour of TSM has been designed to handle charges related to optional services (represented as SSR elements in a PNR). The corresponding type is type P and is not linked to any MD. TSM type P can however be associated to multiple passengers and multiple SSR elements.

3 Limitations

The number of elements that can be displayed in a PNR display has been increased to 999(From Proxy release 2.1.23.1 December 2003)

It is strongly recommended to use the enumerated types providedinstead of hard coded numerical values in your code.

Regarding TSM manipulation, this interface only deals with operations corresponding to the cryptic entries IMC, TQM and TMI.

4 Unsupported Functions

5 Prerequisites

The Miscellaneous Document Table must be set to support the MD type for the market/airline.

Function: ReduceNIP

1 Overview

This function provides the possibility to reduce the numberof passenger contained in a group PNR.

1.1 Supported Operations

This function cancels a given number of non-assigned passengers from a group.

1.2 Limitations

Only unassigned names can be cancelled from the group PNR with this function.

1.3 Unsupported Operations

The following operations are not available from within this function:

• Cancellation of an individual name.

1.4 Prerequisites

The agent must have a group PNR in creation or a PNRretrieved from file in its context.

2 Building A Query

Depending on the flavor of the API that is used, each query will follow agiven structure. The queries for the function operations are clearly explainedwith data element examples in a generic table view that can beadapted to the specific flavor of the API in use.

It is important to note that the examples in each chapter are onlyillustrations and are meant to provide the basis for a better understandingon which fields are mandatory for basic operation utilization.It is not a full explanation of every field that can be utilized for theoperation, but rather a guideline to its use.

3 Receiving A Reply

The reply structure is basically an acknowledgement.

4 Error Messages

5 Operations

5.1 Operation: Reduce From Group

This message only needs the number of passenger that should bedeleted from the PNR.It is coded in the numberOfUnit .You also need to indicate that you are cancellingunassigned name by filling unitQualifier with U.

In case that a PNR has already been filled, the recordlocator will be returned in the reply.

recordLocator/reservation/controlNumber/2WZTBT

5.1.1 Query Structure

5.1.2 Reply Structure

5.1.3 Possible Errors

See "Error Messages", section.

Function: DeleteTSM

1 Overview

The function DeleteTSM allows deleting:

• all TSM of a given PNR
• all TSM associated to given passenger(s) tattoo
• given TSM(s) based on the TSM tattoo.

1.1 Supported Operations

Delete all TSM of an active PNR.
Delete given TSM thanks to their tattoo.
Delete all TSM associated to given passenger(s).

1.2 Limitations

TSM tattoo and passenger tattoo cannot be combined.

1.3 Unsupported Operations

1.4 Prerequisites

Prior to using the function operations, it is necessary to have an active PNR in the session with at least a passenger name.

2 Building A Query

No data is mandatory to build the query. The criteria to DeleteTSM are optional: passenger tattoo, TSM tattoo.

3 Receiving A Reply

The reply consists in the confirmation of the deletion with deleted TSM tattoos, or an error.

4 Error Messages

5 Operations

5.1 Operation: Delete all TSM of a PNR

The query is used to delete all existing TSMs of a given PNR: 37L35E'.

5.1.1 Query Structure

5.1.2 Reply Structure

5.1.3 Possible Errors

5.2 Operation: Delete by passengers tattoo

The query deletes all TSM for passenger 1 and 3

5.2.1 Query Structure

5.2.2 Reply Structure

5.2.3 Possible Errors

5.3 Operation: Delete by TSM tattoo

The query deletes TSMs with tattoo 5 and 7

5.3.1 Query Structure

5.3.2 Reply Structure

5.3.3 Possible Errors

Function: ChangeElement

1 Overview

This function provides the element change feature corresponding with the Central System one.

In order to use this interface correctly, user should already be familiar with the Amadeus element change product. This product is used through the element change cryptic entry.

PNR change parameters:

• Element Number (Mandatory)
• New Element Data (Optional)
• New Segment Association (Optional)
• New Passenger Association (Optional)

At least one optional parameter should be filled.

1.1 Supported Operations

PNR change element:

• Content element modification
• Segment association modification
• Passenger association modification

1.2 Limitations

Not applicable

1.3 Unsupported Operations

Not applicable to Name Element.

1.4 Prerequisites

User must be Amadeus system user. Record must be held in AAA.

2 Building A Query

The query should contains a free text according to the relevant change cryptic entry.

The cryptic entry have to match the following format

[element_number]/[new_data]/[segment_association]/[passenger_association]

3 Receiving A Reply

The reply is a structured message showing new PNR details.

Reply Structure

For further information see Retrieve function on PoweredPNR interface.

4 Error Messages

5 Operations

5.1 Operation: PNR Element Change

Here is an example of query modifying the content and the passenger-segment association for the element at the line 5.

5.1.1 Query Structure

5.1.2 Reply Structure

5.1.3 Possible Errors

See "Error Messages" section

Function: NameChange

1 Overview

The NameChange transaction allows to Update or Change a name.

- The Name Update function is used to update the surname, first name or title of a name element. Passenger types and Identification code (ID or CR)attached to the name element remain unchanged. This function retains all PNR associations.

- The Name Change function is used to change surname, given name/initial(s)/title, passenger type codes and ID / CR in the name element and does not retain passenger associations.

The name element can be changed/updated at creation of the PNR or on a retrieved from file PNR.

1.1 Supported Operations

Not applicable.

1.2 Limitations

Only passenger names are covered by this function, group names are not.

Only one name element can be updated.

1.3 Unsupported Operations

Not applicable.

1.4 Prerequisites

A PNR must be present in the AAA work area.If the user works on an existing PNR that has already been end-transacted, the PNR has to be previously retrieved.This can be done via PoweredPNR_Retrieve. If he works on a new PNR, at least a name element has been added to the PNR.This can be done via PoweredPNR_Add Multi Elements.

2 Building A Query

Name update:

Only the input parameters that contain the traveler information are mandatory.Traveler Information related input parameters are:

• Traveler's surname
• Quantity - always 1 since only one name element can be updated.
• Status - The status code is always C for name update.
• Traveler's given name
• Traveler reference number - the tattoo number of the passenger that willbe updated. It has been transmitted in a previous response message.

Reservation Control Information relatedinput parameter is:

• Reservation control number, this field contains the Amadeus record locator.

Name change:

The NEW name element image including surname, first name, title, passenger type code, ID/CR number (and not only modified data) is passed in the request.

Input parameters:

Traveler Information related input parameters are:

Mandatory

• Traveler s surname
• Quantity - always 1 since only one name element can be changed
• Status - The status code is always M for name change.
• Traveler s given name
• Traveler reference number: This field contains the tattoo number of the passenger that will be changed. It has been transmitted in a previous response message.

Optional

• Passenger type code

• Infant indicator

  Code	Description
  1	Infant with no surname
  2	Infant with given name
  3	Infant with name and given name

• Infant surname
• Infant given name
• ID/CR number

Date Of Birth (of the infant) related input parameters are (optional):

• Year
• Month
• Day

Reservation Control Information related input parameter is (optional):

• Reservation control number, this field contains the Amadeus record locator.

3 Receiving A Reply

If the process is successful:

• The name element is updated with the new data.
• The name field is reviewed for reordering and renumbering if applicable.
• Modification of a name element on a retrieved PNR causes the dataaffected to be moved into the historical section of the PNR.

• Name change

  • If the surname and /or first name are part of the modified data:

    The elements associated with the modified name element are reduced and/or cancelled from the PNR, except for itinerary, fare, ticket, MCO and some seat elements, see A02RES3700 for seat processing and A02-3282 - Miscellaneous charge order.

  • If the surname and /or first name are not part of the modified data:

    The elements associated to the modified name element are retained.

• Name update

  • Passenger types and Identification code (ID or CR) attached to the name element remain unchanged.
  • The elements associated to the modified name element are retained.
• The modified name element is sent in the reply message. Some warnings can be returned as well in the reply message. New name order and reconfigured associations are not part of the reply.They will be returned on a subsequent PNR Retrieve.

If the process is not successful an error is sent in the reply message.

If the name change process is successful, the reply message contains only the record locator if it was given in the request, and the updated passenger information.

In case of error, see the 'Error Message' section.

4 Error Messages

Generic Edifact error, this type of error can be returned isthere is a problem with the contents of the message.

Generic errors.In these cases the reply contains the record locator, if given in therequest, the error information and the error message.

Errors linked to the name update process.In these cases, the reply contains the record locator, if given in the request,the passenger information, the error information and the error message.

Warning messages.

5 Operations

5.1 Operation: Name change on retrieved PNR

The example shows the message required to change the name of the passenger specified by the reference number with the following data:

Passenger surname: SURNAME

Passenger given name / title: GIVENNAME MR

Passenger reference number: 1

Passenger type code: ADT

Infant name: SMITH

Infant given name: BABY

Infant date of birth: 15 SEP 2007

Note: There must be a retrieved PNR in the AAA, with record locator XXXXXX

5.1.1 Query Structure

5.1.2 Reply Structure

5.1.3 Possible Errors

See "Error Messages" section.

5.2 Operation: Name Update On Newly Created PNR

The example shows the message required to update the name of the passengerspecified by the reference number with the following data:

• Passenger surname - SURNAME
• Passenger given name/title - GIVENNAME MR
• Passenger reference number - 3

Note: There must be a PNR in creation in the AAA, containing at least 1 name.

5.2.1 Query Structure

5.2.2 Reply Structure

5.2.3 Possible Errors

See "Error Messages" section.

5.3 Operation: Name Update On Retrieved PNR

The example shows the message required to update the name of the passengerspecified by the reference number with the following data:

• Passenger surname - SURNAME
• Passenger given name/title - GIVENNAME MR
• Passenger reference number - 3

Note: There must be a retrieved PNR in the AAA, with record locator XXXXXX.

5.3.1 Query Structure

5.3.2 Reply Structure

5.3.3 Possible Errors

See "Error Messages" section.

Function: Split

1 Overview

The function PNR_Split separates passengers from a parent PNR and creates a new child PNR with these passengers and their associated segments and elements.

The parent and child PNRs are then linked through Associated Record Indexing (AXR).

1.1 Supported Operations

The following split operations are possible:

• Split - Individual Names

This operation splits one or several passengers from the PNR (individual or group).

• Split Group PNR - Unassigned Names

This operation splits a number of unassigned names from the group PNR.

• Split Group PNR - Unassigned and Individual Names combination

This operation splits both unassigned and individual names from the group PNR.

• Split Group PNR - Partial Confirmation of Space

For a group PNR with partially confirmed segments without passenger associations, this operation allows to split unassigned and/or individual names and specify the number of confirmed/unconfirmed segments which will be split.

• Split - Special Elements Handling

Additionnally to the above operations, the user may choose to keep or move specific elements in the PNR, for example a certain number of services which are not passenger associated, or auxiliary segments.

1.2 Limitations

The following operations are not allowed on Split PNRs until end of transaction of both child and parent:

• Additional split party
• Increase/Decrease number in party
• Change office of responsibility
• Non-homogeneous conditions
• Add passenger
• Print Ticket on child PNR (Ticket print of the parent PNR will be permitted)
• Print Invoice on child PNR (Invoice print of the parent PNR will be permitted)
• Display or print of Itinerary
• PTA creation
• Print Car voucher
• Split of OA controlled PNRs (except by TR agent).
• Display AXR.

1.3 Unsupported Operations

The functionality "split range of names" is not supported. Instead the user has to specify exactly which passengers will be splitted.

1.4 Prerequisites

A PNR has been retrieved and has not been modified yet.

2 Building A Query

A user may directly split a PNR for which the record locator is known. In this case he provides the record locator in the request (reservation control number)

He may also choose to split a retrieved PNR, in which case no record locator is required.

2.1 Sub Structure: Query structure with record locator

2.1.1 Description

The general structure of the query used to split a PNR if the PNR is not in the context is the following:

2.1.2 Xml Structure

2.2 Sub Structure: Query structure without record locator

2.2.1 Description

The general structure of the query used to split a PNR which is already in the context in is the following:

2.2.2 Xml Structure

3 Receiving A Reply

Two kind of replies are possible.

• If the split is succesful, the child PNR is displayed.
• If the split fails, an error message is issued.

3.1 Sub Structure: Reply Structure

3.1.1 Description

The reply is a display of the child PNR. Special restrictions apply to this child PNR and only a "end file" type of end of transaction is permitted (AddMultiElements with optionCode 14).

After the child has been filed, the parent PNR is displayed.

Upon end of transaction of parent PNR (AddMultiElements with optionCode 10 for example), the child PNR record locator is displayed within the end of transaction reply.

3.1.2 Xml Structure

4 Error Messages

4.1 Error Reply

5 Operations

5.1 Operation: Split - individual names

This operation splits one or several passengers from the PNR (individual or group).

• If a PNR is already retrieved, the user has to specify the element type ("PT" for passenger tattoo) and the tattoos of the passengers to split (their line number in the PNR display).
• If no PNR has been retrieved, the user must add the record locator in the request.

Example: split passengers 1,5,6 from PNR ABCDEF

5.1.1 Query Structure

5.1.2 Reply Structure

5.1.3 Possible Errors

5.2 Operation: Split group PNR - unassigned names

This operation splits unassigned names from a group PNR.

• If a PNR is already retrieved, the user has to specify the element type ("PT" for passenger tattoo) and the number of unassigned names to split.
• If no PNR has been retrieved, the user must add the record locator in the request.

Example: split two unassigned names from currently displayed PNR.

5.2.1 Query Structure

5.2.2 Reply Structure

5.2.3 Possible Errors

5.3 Operation: Split group PNR - unnassigned/individual names combination

This operation splits both unassigned and individual names from a group PNR.

• If a PNR is already retrieved, the user has to specify the element type ("PT" for passenger tattoo), the number of unassigned names to split, and the tattoos of individual names to split
• If no PNR has been retrieved, the user must add the record locator in the request.

Example: split two unassigned names and split passengers 1 and 3 from currently displayed PNR.

5.3.1 Query Structure

5.3.2 Reply Structure

5.3.3 Possible Errors

5.4 Operation: Split group PNR with partial confirmation of space

This operation splits names from a group PNR and specifies for partially confirmed segments how confirmed/unconfirmed space will be split.

• If a PNR is already retrieved, the user has to specify the element type ("PT" for passenger tattoo), the unassigned and individual names to split.
• If no PNR has been retrieved, the user must add the record locator in the request.

The user can then specify:

• the number of confirmed (HK) seats to split for each segment
• OR the number of confirmed and the number of unconfirmed seats, in which case the total number of specified seats must match the number of split passengers.

Example: split two unassigned names and passengers 1 and 2 from currently displayed PNR, take 2 seats from segment 3 and 2 seats from segment 4.

5.4.1 Query Structure

5.4.2 Reply Structure

5.4.3 Possible Errors

5.5 Operation: Split with special elements handling

This operation splits names from PNR and specifies how to handle special elements.

• If a PNR is already retrieved, the user has to specify the element type ("PT" for passenger tattoo), the unassigned and individual names to split.
• If no PNR has been retrieved, the user must add the record locator in the request.

When there are elements in the PNR without passenger association, the user can specify whether to transfer them (by choosing a number of items to transfer), or to keep them in parent PNR (by choosing 0 as number of items to transfer). This applies to both auxiliary segments (choose ST type) and services/other elements (choose OT type).

Example: split passengers 1,2, 4 from currently displayed PNR, keep auxiliary segment 7 within PNR, keep element 10 and 18 in parent PNR, transfer elements 11 and 12  to child PNR.

5.5.1 Query Structure

5.5.2 Reply Structure

5.5.3 Possible Errors

Function: AddFrequentFlyer

1 Overview

The AddFrequentFlyer function is used to add a Frequent Flyer card in a PNR. It has two functions corresponding to the FFN and FFA entries:

Frequent Flyer SSR FQTV Creation (FFN)

This function is used to create one or several SSR FQTV elements associated to a name element that is already in the PNR.

The SSR FQTV element indicates that the passenger will be accruing miles under that card number for the segment being flown.

For airlines which store their frequent flyer database within the Amadeus system the frequent flyer number is validated against the card owning airline's database and the name with which it is associated is used to match the name already entered into the PNR. If the airline does not store the frequent flyer database within Amadeus system, the frequent flyer number is stored in the PNR without validation.

Multiple SSR elements can be created in one single transaction by specifying a list of target airlines.

For airlines which are users of the AF group Customer Application, the card number validation is performed in the Customer Application. The Customer Application may respond to the user with a FD element which will be added to the PNR.

This function allows creating an SSR FQTV that is validated against the Frequent Flyer database. It also checks the correspondence between the name in the PNR and the owner of the card. This function can also add in the PNR the name of the owner of the card.

Frequent Flyer Name and SSR FQTV Creation (FFA)

This function is for airlines that have a Frequent Flyer database in Amadeus. It is used to create passenger name and SSR FQTV elements in the PNR.

The SSR FQTV element indicates that the passenger will be accruing miles under that card number for the segment being flown.

The frequent flyer number is validated against the card owning airline's database and the name with which it is associated is used to build a PNR name element.

Multiple SSR elements can be created in one single transaction by specifying a list of target airlines.

For airlines which are users of the AF group Customer Application, the card number validation is performed in the Customer Application. The Customer Application may respond to the user with a FD element which will be added to the PNR.

Special for Air France

With some Air France Frequent Flyer cards, the message can create FD (Fare Discount) elements instead of SSR FQTV. FD elements are distinguished from SSR FQTV in the Reply if the Frequent Traveler Verification contains the category PAX.

1.1 Supported Operations

Not applicable.

1.2 Limitations

There can be only one Frequent Flyer card per request.

The exact frequent flyer number must be provided in an SSR FQTV creation. Any other characters, such as blanks, must be avoided.

For instance, SSR FQTV entry with the Frequent flyer number 2220 12956097 213 will be rejected,although an SSR FQTV entry with the Frequent flyer number 22201296097213will succesfully create the associated SSR FQTV.

1.3 Unsupported Operations

Not applicable.

1.4 Prerequisites

Frequent Flyer SSR FQTV creation (FFN)

A PNR must be retrieved:

If the user works on an existing PNR that has already been end-transacted, the PNR has to be previously retrieved. This can be done via the structured service Retrieve .

If he works on a new PNR, at least one name element has been added to the PNR. This can be done via the structured service AddMultiElements

The context must be kept between the different transactions.

Frequent Flyer Name and SSR FQTV creation (FFA)

This transaction may be used as first transaction to create a PNR or may be used on a non end-transacted PNR.

2 Building A Query

Input parameters

Only the input parameters containing the frequent traveler information are mandatory.

Input parameters involved in the Frequent Traveler Verification

• action request: see fqtvData in the codesets
• airline code: Frequent Flyer Card owning airline
• target airline: optional target airline that will use the frequent flyer card
• frequent flyer number
• expanded name: will be concatenated to the name associated to the frequent flyer card whenadding the name with the card (FFA)

Input parameters involved in the Reservation Control Information:

• reservation control number: this field contains the Amadeus record locator

Input parameters involved in the Traveler Information

• The passenger surname
• The passenger given name
• The traveler reference number: this field contains the tattoo number of the passengerthat will be associated to the SSR FQTV. It has been transmitted in a previous response message.

3 Receiving A Reply

• If the process is successful
  • The SSR FQTV is added in the PNR
  • If requested, the frequent flyer name is added in the PNR
• If the process is not successful: an error is sent in the reply message.

Remark: This transaction does not save the PNR. The update will become effective after a Commit transaction. Therefore a context must be kept between the different transactions.

A generic reply can contain

• a record locator
• a generic error containing:
  • An error code: the Amadeus canned message number corresponding to the error
  • An error category for either a Mutually defined warning (code WZZ) or a Mutually defined error (code ZZZ)
  • An error code owner (always 1A)
• A generic error message
• A Traveler Information containing:
  • The passenger surname
  • The passenger given name
  • The passenger reference
• One Frequent Traveler Verification per SSR FQTV / FD created containing:
  • The Frequent Flyer Card owning airline
  • The target airline
  • The Frequent Flyer number
  • The airline priority code or tier level
  • The alliance tier description
  • The category: set to PAX if the element is an FD
• A Related Product Information containing:
  • The status code of the SSR / FD
• A Frequent Flyer error containing:
  • An error code: the Amadeus canned message number corresponding to the error
  • An error category for either a Mutually defined warning (code WZZ) or a Mutually defined error (code ZZZ)
  • An error code owner (always 1A)
• A Frequent Flyer error message

Note: this is only a generic reply. In reality, all these fields can not be present atthe same time.

In case of error, see the "Error Message" section.

4 Error Messages

Generic Edifact error

The reply contains only the error information and the error message.

Generic errors

In these cases, the reply contains the record locator if given in the request,the error information and the error message.

Errors linked to the Frequent Flyer Add process

In these cases, the reply contains the record locator if given in the request,the Frequent Traveler Verification given in the request, the error information and the error message.

4.1 Error Reply

5 Operations

5.1 Operation: Add a Frequent Flyer Name and SSR FQTV (FFA)

There may be a PNR in creation, or this can be the first transaction to create a PNR.

The example shows the message required to add a frequent flyer name and SSR FQTV specified by the following data:

5.1.1 Query Structure

5.1.2 Reply Structure

5.1.3 Possible Errors

See "Error Messages" section.

5.2 Operation: Add an SSR FQTV on retrieved PNR (FFN)

There must be a retrieved PNR, with record locator XXXXXX.

The example shows the message required to add an SSR FQTV specified by the following data:

5.2.1 Query Structure

5.2.2 Reply Structure

5.2.3 Possible Errors

See "Error Messages" section.

5.3 Operation: Add an SSR FQTV with passenger association on retrieved PNR (FFN)

There must be a retrieved PNR, with record locator XXXXXX.

The example shows the message required to add an SSR FQTV specified by the following data:

The associated passenger is specified by the following data:

5.3.1 Query Structure

5.3.2 Reply Structure

5.3.3 Possible Errors

See "Error Messages" section.

5.4 Operation: Add an SSR FQTV with target airlines on retrieved PNR (FFN)

There must be a retrieved PNR, with record locator XXXXXX.

The example shows the message required to add an SSR FQTV specified by the following data:

The SSR FQTV is created for the airlines specified in the message: IB, BA

5.4.1 Query Structure

5.4.2 Reply Structure

5.4.3 Possible Errors

See "Error Messages" section.

Function: CreateTSM

1 Overview

The function CreateTSM creates a TSM with at least:

• one passenger association
• a MD or TSM type (M,E,F,P)

and other data when specified (date, accounting data, reason for issuance code, reason for issuance description, international sales indicator, VAT country).

The presence of some data depends on the market/carrier and the MD type.

This transaction returns the tattoo of the created TSM or an error.

1.1 Supported Operations

The TSM creation for a passenger or an infant is not supported.

1.2 Limitations

It is only possible to create up to 127 active TSM.

TSM type M,E,F are single passenger associated. Multiple passenger associations are only allowed for TSM type P.

1.3 Unsupported Operations

1.4 Prerequisites

It is necessary to have an active PNR in the session with at least a passenger name.

2 Building A Query

Following data are mandatory in the query message:

• passenger tattoo (/mcoData /paxTattoo)
• MD/TSM type (/mcoData /mceDocData /tktNumber /documentDetails /type)

3 Receiving A Reply

The reply consists in the confirmation of the TSM creation (with passenger and TSM tattoo number) or an error.

4 Error Messages

5 Operations

5.1 Operation: Create TSM type E

This query requests the creation of a TSM type E, for an AY ATO/CTO.

5.1.1 Query Structure

5.1.2 Reply Structure

5.1.3 Possible Errors

5.2 Operation: Create TSM type F, BA ATO/CTO

This query requests the creation of a TSM type F, for a BA ATO/CTO.

5.2.1 Query Structure

5.2.2 Reply Structure

5.2.3 Possible Errors

5.3 Operation: Create TSM type F, TASF

This query requests the creation of a TSM type F, TASF, on CH market.

5.3.1 Query Structure

5.3.2 Reply Structure

5.3.3 Possible Errors

5.4 Operation: Create TSM type F, US market

5.4.1 Query Structure

5.4.2 Reply Structure

5.4.3 Possible Errors

5.5 Operation: Create TSM type M, FR market

This query requests the creation of a TSM type M, for a Travel Agency on French market.

5.5.1 Query Structure

5.5.2 Reply Structure

5.5.3 Possible Errors

5.6 Operation: Create TSM type M, LH ATO/CTO, infant

This query requests the creation of a TSM type M for an infant, for a LH ATO/CTO.

5.6.1 Query Structure

5.6.2 Reply Structure

5.6.3 Possible Errors

5.7 Operation: Create TSM type M, LH ATO/CTO, VAT country DE, RFIC Q for emco

This query requests the creation of a TSM type M, for a LH ATO/CTO, with a VAT country DE, and international indicator Domestic.

5.7.1 Query Structure

5.7.2 Reply Structure

5.7.3 Possible Errors

5.8 Operation: Create TSM type P

This query requests the creation of a TSM type P

5.8.1 Query Structure

5.8.2 Reply Structure

5.8.3 Possible Errors

Function: UpdateTSM

1 Overview

All TSM (except type F for US market and BA ATO/CTO, and type P) can be updated, based on its tattoo. The update mechanism is in mirror mode. The update query contains all the TSM information. A missing segment or data element in the query means that the corresponding data is reset.
All TSM data can be updated, except the date, the TSM type and the passenger association.

The reply is the full data of the TSM.

1.1 Supported Operations

1.2 Limitations

No fare elements can be updated via this function (FP, FM,...).

1.3 Unsupported Operations

TSM type F for US market and BA ATO/CTO can't be updated.
TSM type P can't be updated.

1.4 Prerequisites

Prior to using the function operations, it is necessary to have an active PNR in the session.

2 Building A Query

The query must be filled in mirror mode i.e. all the existing fields must be filled in. A voided field corresponds to a deletion of the data matching the field.

3 Receiving A Reply

The reply consists in the display of TSM data or an error.

Example of update reply of a TSM type E:

4 Error Messages

5 Operations

5.1 Operation: Update a TSM type E

This query is to request the update of the TSM 3 which is type E.

5.1.1 Query Structure

5.1.2 Reply Structure

5.1.3 Possible Errors

5.2 Operation: Update a TSM type F, TASF

This query is to request the update of the TSM 3 which is type F on CH market.

5.2.1 Query Structure

5.2.2 Reply Structure

5.2.3 Possible Errors

5.3 Operation: Update a TSM type M

This query is to request the update of the TSM 3, which is type M.

5.3.1 Query Structure

5.3.2 Reply Structure

5.3.3 Possible Errors

5.4 Operation: Update for VAT country in a TSM type M

This query is to request the update of VAT country in TSM 3, which has type M.

5.4.1 Query Structure

5.4.2 Reply Structure

5.4.3 Possible Errors

Function: Cancel

1 Overview

The Cancel functionality is used to cancel selected elements from a PNR. A PNR contains all the elements (details) pertaining to a passenger's trip and reservation. It must contain the following five elements:

• Name element : A passenger name.
• Itinerary element: A booking for a flight or another service.
• Contact element: Telephone number or contact information for the person making the booking.
• Ticketing element: An indication of the arrangements for issuing a ticket for the booking.
• Received from element: The 'Received From' element is a mandatory element following a cancelled (modified) element, it is used to identify the name of the person or entity that has made the booking or has modified the PNR.

Each PNR that is created is assigned a six Character code called a Record Locator, which is the unique identifier for the PNR and can be used to retrieve the PNR. For more information regarding other methods and the rules for retrieving a PNR, please refer to the Retrieve functionailty.

Each element in the PNR is identified with a tattoo type (PT, OT, ST or OOT) and a unique tattoo number. Below is a description of these tattoo types.

With the cancel function, single and multiple elements are cancelled and moved to the PNR history. The cancel function is also used to cancel all active itinerary elements, except certain rail segments and all non-mandatory PNR elements. Itinerary flight segments that are marked as flown, or auxiliary segments that are marked as past, cannot be cancelled from a PNR. Cancellation of the elements in the PNR can be done in two ways:

• Single cancel query message structure

Under a single cancel query message structure, cancellation is not allowed for a combination of elements of different types of tattoos. For example, cancellation of name elements and itinerary is not allowed. Whereas cancellation is allowed for a combination of elements of same types of tattoos. For example, cancellation of multiple OT elements in a single cancel query message is allowed.

• Multiple cancel query message structure

Cancellation is not allowed for elements of same types and/or different types under multiple instance of the cancel message structure

Exception: For extended contents, there is only one tattoo type "OT" which can refer to many product types such as Air, Ferry, Cruise, Rail, Coach, Bus, Hotel, Visit, Insurance, Vaccine, Restaurant... Cancel cannot be performed on elements from different family types. For instance, an air segment from extended content and a remark from the PNR cannot be cancelled in a single querry message even if they both have the same tattoo type OT.

Note:

Repetition factors

The cancelElements/entryType below are used to cancel elements. The structure is limited to a repetition of '1':

1.1 Supported Operations

Following is a list of examples showing some of the supported operations:

• Single Data Element

This operation cancels a data element from a PNR  and adds it to the PNR history.

• Multiple Data Elements

This operation cancels multiple data elements from the active PNR and adds them to the PNR history.

• Cancel Elements in a previously retrieved PNR

This operation cancels data elements from a retrieved PNR and adds them to the PNR history.

• Cancel Elements in a non previously retrieved PNR

This operation retrieves the PNR, cancels data elements and adds them to the PNR history.

• Cancel Elements and End Transaction

This operation cancels multiple data elements from an active PNR and ends the transaction.

• Cancel Elements and End Transaction (Automatic add of Received From)

This operation cancels multiple data elements from an active PNR and files and closes the PNR with the end transaction action automatically adding a received from element.          

• Cancel the entire Itinerary and other Elements

This operation removes the entire Itinerary from an active PNR (Except for Rail segments)and adds it to the PNR history.  Associated SSR and OSI elements are also moved to history.

• Cancel Itinerary and End Transaction

This operation removes an Itinerary and other data elements from an active PNR followed by an End of Transaction action that files and closes the PNR.

• Name Integration

A group name element in a PNR specifies the collective name and the number of members (a group of people) travelling together. The Name Integration operation reduces the space that has already been booked for agroup by cancelling named or unnamed group members from the group element.

• Optional PNR actions

These features are special cases incorporated directly into the cancel functionality and which specify specific actions to be processed on a PNR. Below is a list of the most commonly used action codes supported in the cancel functionality:

1.2 Limitations

Following is a list of some limitations using certain operations in the Cancel PNR element:

• Group name

The group name element can not be cancelled; however, you can reduce the group size.

• Itinerary elements

When all the itinerary elements are cancelled, the segments will remain in the PNR until the end transaction. All Special Service Requests are then cancelled from the PNR and any remaining Other Service Information elements will need to be cancelled before the end transaction. Itinerary flight segments that are marked as flown or auxiliary segments that are marked as past can not be cancelled from a PNR.

Important: any elements associated to the cancelled itinerary will also be cancelled simultaneously following this action.

• Name element

The name element can be cancelled with no reservation as long as the PNR has not been saved.Once a PNR has been saved it can not exist without at least one name element, if an attempt is made to cancel the last remaining name element an error will be received.

Important: any elements associated to the cancelled name will also be cancelled simultaneously following this action.

1.3 Unsupported Operations

Unsupported operations

• End transaction and queue place
• Cancel MCO sub-elements
• Cancel segment but do not transmit to airline

1.4 Prerequisites

Prior to using the function Cancel, it is necessary to have a PNR that has just been created and or a PNR that has just been retrieved.

This example is a query request to retrieve a PNR by Record Locator and is used throughout this chapter and is NOT part of the PNR cancel function. For more information about the function Retrieve, please refer to Retrieve user guide.

2 Building A Query

2.1 Sub Structure: Query structure to cancel an AP element

2.1.1 Description

Below is an example of a query structure to cancel an AP element (Contact element) in PNR 5PO9P4. The cancel entry type is "E" as for cancel element. OT is the reference qualifier and 8 is the tattoo reference number for this element in the PNR:

2.1.2 Xml Structure

2.2 Sub Structure: Query structure to cancel a name element

2.2.1 Description

Below is an example of a query structure to cancel a name element in the same PNR as before (5PO9P4). PT is the reference qualifier and 1 is the tattoo reference number for this name element in the PNR:

2.2.2 Xml Structure

3 Receiving A Reply

For each PNR query cancel presented, there is a corresponding reply structure returned.Reply is a structured PNR representation, the acknowledgement of a successful commit or an error message.

3.1 Sub Structure: Reply structure: Successful commit

3.1.1 Description

Below is a reply structure to an attempt to cancel an AP element (Contact element) in PNR 5Q7D6M. The PNR is displayed and the AP element has been successfully deleted.

3.1.2 Xml Structure

3.2 Sub Structure: Reply structure: Error message

3.2.1 Description

Following is a possible reply structure to cancel a name element in a PNR. For this case, the PNR contains only one name element. An error message "NEED NAME" is received in the reply message upon the cancel transaction since every PNR must contain at least one name element. 

3.2.2 Xml Structure

4 Error Messages

The following errors can be returned while trying to use the cancel function.

No Match for Record Locator

This error message is returned when the control number (PNR record locator) entered can not be found, therefore ensure that the PNR being referenced is valid, refer to the function Retrieve for further methods of retrieving a PNR.

1931 - NO MATCH FOR RECORD LOCATOR

Invalid format

This error message is received if the identifier for the action is missing and the data element to be cancelled is present. The solution is to return to the query and add the missing information.

12290 - INVALID FORMAT/NOT ENTERED/>

Cancel restricted

This error message is received when there is an attempt to cancel an element that cannot be cancelled.

3134 - CANCEL RESTRICTED -

Check segment status

This error message is received when there is an attempt to cancel a flown or past dated itinerary element.

3006 - CHECK ITINERARY/INACTIVE SEGMENT

Range problem

This error is received when elements to cancel are selected in a wrong order.

1933 - CHECK RANGE ORDER

Delete restricted

This error is received when there is an attempt to delete a segment, or range of segments that belongs to an airline that prohibites segment deletion.

3135 - DELETE RESTRICTED

Check element number

This error is received when there is an attempt to cancel a non-existing element number

1895 - CHECK ELEMENT NUMBER

Duplicate element

This error is received when there is an attempt to delete the same element with one message.The same element number have been entered more than once in the cancellation entry.

1939 - DUPLICATE ELEMENT - X             (where x is the element number)

Element does not exist

This error is received when there is an attempt to cancel a non-existing element.

1938 - ELEMENT DOES NOT EXIST

Element conflict

This error is received when there is an attempt to delete different element types in the same message.

1935 - ELEMENT CONFLICT

ETKT status problem while trying to delete a FA element

This error is received when there is an attempt to cancel the itineray for which an FA/ET element exists.

9123 - FA ELEMENT DELETED - VERIFY ETKT STATUS FOR -

Warning related to TST

This error is received when there is an attempt to cancel the last remaining air segment for which an FA/ET element exists.
2888 - WARNING: SEGMENT DELETED - TST WILL BE DELETED IF ET/ER

Itinerary deleted

All itinerary has been deleted.

3512 - ITINERARY DELETED

Need name

An attempt has been made to delete the name element, whereas it is not authorized in some cases.

1436 - NEED NAME

Restricted

An attempt has been done to cancel a name associated to a FA/ET element.

9029 - RESTRICTED - FA/ET EXISTS

After name element cancel, a RF (Receive From) must be done before doing another update.

3350 - RESTRICTED/NAME ELEMENT PREVIOUSLY CANCELLED

When the XI is performed on a child PNR after the Split transaction and before EOT. This error response is issued.       

RESTRICTED DURING SPLIT PARTY 

In a PNR in which an Increase Number in Party ( INP ) entry has been performed if XI is input before EOT the system issues the following error response:

RESTRICTED DURING INCREASE NUMBER IN PARTY

XI can only be performed on a retrieved PNR. When attempted on a newly created PNR this error message is displayed.

RESTRICTED / USE XE

TRN error

A attempt has been made to cancel a itinerary containing SNCF Rail segment.

6527 - TRN 2C CANNOT BE MODIFIED - RESARAIL PNR MUST BE UPDATED

Wrong name element number

2577 - CHECK NAME ELEMENT NUMBER

Invalid Format

477 - INVALID FORMAT

Inactive Segment

This error is issued if an attempt is made to cancel, change, or delete a specific or a range of flown/past elements. (i.e. XEn or n,n).

CHECK ITINERARY/INACTIVE SEGMENT

Verify with cruise

the name element has been cancelled, but the cancellation has not been applied to the cruise segment cru in the pnr.

NAME ELEMENT DELETED - VERIFY WITH CRUISE - XXX  

(where xxx is the cruise company code)   

EXAMPLE: Below is an example of an error message (GENRES) returned upon a cancel query using a wrong tattoo number.

5 Operations

5.1 Operation: 1 - PNR used as example

In this section, the sample PNR scenarios consist of the following elements:

• Record locator (5PPGFR)
• 2 passenger names
• 2 flights
• 1 phone
• 1 ticket
• 1 Remark
• 1 special service request

Below is the query and reply structures to cancel a name element from the above PNR. Unlike the previous example, there is no error received after this transaction because the PNR still contains a name element. Instead, the PNR is displayed and one of the initial name elements as well as the special service requests associated to this passenger have indeed been cancelled. Note: The cancellation of an element removes all associations for that element.

The following is an extract of the items that are removed from the returned reply, indicating the cancelled passenger name. Important: A PNR must have at least one name element.

5.1.1 Query Structure

5.1.3 Possible Errors

5.2 Operation: 2 - Cancel Element with tattoo 14

This query is a request to cancel element with tattoo number 14, which happens to be a contact element AP from the sample PNR.

The control number is the PNR Record locator number whereas the action code 0 (Zero) corresponds to a simple cancel action. The value 'E' declares the type of cancel entry, hence to cancel an element. The 'OT' value signifies the type of element tattoo (other) and the last item indicates the reference number of the element to be cancelled.

As a result only the left items are listed in the reply.

Listed are the items that have been removed from the original PNR.

5.2.1 Query Structure

5.2.3 Possible Errors

5.3 Operation: 3 - Cancel Elements in PNR

This query is a request to cancel two elements (the special service request for a vegetarian meal and the remark) in the sample PNR given previously. This illustration signifies that the PNR is an active PNR and or is in current session. Hence as the record has not been stored, there is no PNR in the context. However the PNR is retrieved in the query.

The reply returned is the same as the example Cancel Element ; the only difference is the fact that the query uses a Record Locator to retrieve the PNR.

5.3.1 Query Structure

5.3.3 Possible Errors

5.4 Operation: 4 - Cancel Elements, End Transaction

This query is a request to cancel two elements (a special service request for a vegetarian meal and a remark) in the example pnr given previously.The difference compared to the previous example is the fact that the PNR action code value is set to 10 which indicates that regardless of the operation on the PNR an End of transaction command will be automatically performed by the application. After this cancel query, the pnr contains now the following elements:

• 2 passenger names
• 2 flights
• 1 phone
• 1 ticket

5.4.1 Query Structure

5.4.3 Possible Errors

5.5 Operation: 5 - Cancel Entire Itinerary

To recapitulate - an itinerary is a list of a passenger's travel arrangements. It can include flight information, hotel and car rental information, and any other miscellaneous information.

The query below is a request to cancel the entire itinerary from the PNR 5PPGFR. Evidently, the value used to cancel an itinerary is the letter 'I'. The PNR option code is set to 0 which means that no special processing is performed apart from the cancel query. Therefore, unless an end of transaction is performed, the changes are not going to be saved in the pnr history.

5.5.1 Query Structure

5.5.3 Possible Errors

5.6 Operation: 6 - Cancel Itinerary, End Transaction

This query is a request to cancel an itinerary and to End the Transaction. To recapitulate - the End Transaction entry is the last mandatory entry for creating a new PNR or modifying a retrieved PNR.

The PNR optionCode value 10 means that, following the deletion of the itinerary, the End of transaction command will be performed by the application.

This is the reply given after removal of the itinerary closely followed by the operation to end the transaction.

5.6.1 Query Structure

5.6.3 Possible Errors

5.7 Operation: 7 - Name Integration for Group PNR

The group name element can be a maximum of 53 characters in length. It can only be entered and modified during PNR creation.The maximum group size is 99 passengers.

Two name counters appear in the group name: Element to show the number of unnamed and named group members:Unassigned names counter shows how many group members have not yet been named. This decreases as individual name elements are entered. Individual name counter shows how many group members have been named using name element entries. The combination of named and unnamed counters is equal to the total number in the group.

Note: once you have entered the group name, you cannot change the number of passengers in the group name element.

In this section, the sample group PNR scenario consists of the following elements:

• Record locator (5PP4C2)
• A group of 11 passengers (Football team) including three assigned names: Christiano RONALDO, Ozil MESUT and Karim BENZEMA
• 1 flight
• 1 phone
• 1 ticket
• 1 special service request: Group Fare

This query is a request to cancel a group name element for one of the group members who tattoo type PT as for passenger and tattoo number 3 (Christiano RONALDO).

5.7.1 Query Structure

5.7.3 Possible Errors

5.8 Operation: 8 - Cancel Offer

The query below is a request to cancel an offer (an air segment offer) from the PNR 5P5FLB. The value used to cancel an offer is E as for element. The tattoo type is OOT as for all offers. The tattoo number of this offer is equal to 1 in this example.

We can see in the PNR_Reply message the TAG ''OFR'' in the PNR header which indicates that the PNR contains or used to contain one or many offers. However, offers cannot be displayed through PNR_Reply message. For more information about how to retrieve and redisplay offers, refer to the user guide of PNR_Redisplay and PNR_RetrieveAndDisplay.

5.8.1 Query Structure

5.8.3 Possible Errors

5.9 Operation: 9 - Cancel Extended Content

The query below is a request to cancel an extended content (a bike) from a PNR in creation. The value used to cancel an extended element is E as for element. The tattoo type is OT as for all extended contents. The extended content BIKE in this PNR has tattoo number 6.

Extended contents cannot be displayed through PNR_reply message. For more information about how to retrieve and redisplay extended contents, refer to the user guide of PNR_Redisplay and PNR_RetrieveAndDisplay.

5.9.1 Query Structure

5.9.3 Possible Errors

Function: TransferOwnership

1 Overview

The TransferOwnership function is used to change the office ofresponsibility of a PNR. The responsible office can be either an Amadeus office id or OA identification.Additionally, the queuing office ID, the ticketing office ID, the office idspecified in the option queue element can be modified.
This functionality can be used at creation of the PNR or on a retrieved from file PNR.

1.1 Supported Operations

Not applicable.

1.2 Limitations

The queuing office, ticketing office and/or the office ID in the option queue element can not be changed without changing the owner of the PNR.

1.3 Unsupported Operations

Not applicable.

1.4 Prerequisites

The user is entitled to transfer the PNR ownership.

A PNR must be retrieved:

• If the user works on an existing PNR that has already beenend-transacted, the PNR has to be previously retrieved.This can be done via the function Retrieve.
• If the PNR being created, at least one element needs to have been added to the PNR. This can be done via the function AddMultiElements,

The context must be kept between the different transactions.

2 Building A Query

At least one Amadeus office ID or OA identification (mutually exclusive) must be present.

Input parameters involved:

• PNR record locator (optional), recordLocator
• New PNR Owner (mutually exclusive, one mandatory)

1. Amadeus Office ID (officeIdentification)
2. OA Identification (oaIdentificatior)

• Single PNR indicator : indicate to change only current PNR, not PNRs linked with AXR to the current one

Input parameters involved in the Amadeus office ID:

• Amadeus Office ID
• Queuing office (optional)

• Ticketing office (optional)

• Option queue office (optional)

The record locator may be passed when the transaction is performed on retrieved PNR. In that case, the system checks that it corresponds to the current PNR.

3 Receiving A Reply

If the process is successful:

• The ownership of the PNR is transfered
• If new owner is an Amadeus Office ID and if corresponding indicators were set, the queuing office, the ticketing office and the option queue office are changed
• If specified in the request, the record locator is put in the reply
• The new owner is put in the reply (the one specified in the query)

If the process is not successful, an error is sent in the reply.

A generic reply contains:

A generalError group contains error details and message

• The /errorDetails /errorCode (on five digits)
• The /errorDetails /errorCategory (ZZZ = Mutually defined error)
• The /errorDetails /errorOwner (always 1A)
• The /errorFreeText /freeTextDetails /textSubjectQualifier (always 3 = literal text)
• The /errorFreeText /freeTextDetails /source (always A = system)
• The /errorFreeText /freeTextDetails /encoding (always 2 = ASCII 8 bits)
• The /errorFreeText /freeText of the error

A group for the Amadeus office ID (if specified in the query) (officeIdentification)

• The owner specified in the query (officeIdentificator)
• An error group officeError (see above structure of the general error group)

A group for the OA identification (oaIdentification)

• The owner specified in the query (oaIdentificator)
• An error group oaError (see above structure of the general error group)

An error group is present only in case of error occurring during the process, and only one.

4 Error Messages

Description of any error messages that might be received when using this Interface. List of all error messages that this Function might give.

5 Operations

5.1 Operation: Transfer Ownership To An OA Identification

This example shows the transfer of ownership to an OA identification on a retrieved PNR.

5.1.1 Query Structure

5.1.2 Reply Structure

5.1.3 Possible Errors

See "Error Messages" section.

5.2 Operation: Transfer Ownership To An Office ID

This example shows the query which transfers ownership of a retrieved PNR, changing also the ticketing office, without propagation through the AXR.

5.2.1 Query Structure

5.2.2 Reply Structure

5.2.3 Possible Errors

See "Error Messages" section.

Function: AddRedemption

1 Overview

The AddRedemption function is used to create one or several SSR FQTR. The SSR FQTR element indicates that the passenger will be redeeming miles which were accrued under that card numberfor the segments to be flown.

For airlines which store their frequent flyer database within the Amadeus Global Core system the frequent flyer number is validated against the card owning airline's database but there is no validation of the name since a card holder may redeem his points in favor of someone else.If the airline does not store the frequent flyer database within Amadeus Global Core system,the SSR FQTR is stored in the PNR without validation.

For airlines which are users of the AF group Customer Application, the card number validationis performed in the Customer Application. The Customer Application may respond to the user with an FD element which will be added to the PNR.

For airlines which are users of interactive validation application,the validation of theredemption is performed in the Loyalty System of the airline asking for this interactive validation (it can be target airline or card owner airline or the both). In this case, the SSR FQTR is storedin the PNR only if it is approved by the interactive validation: if an error is returned by Loyaltysystem of the airline concerned by interactive validation, the SSR FQTR is not added in the PNR.

1.1 Supported Operations

Not applicable.

1.2 Limitations

Not applicable.

1.3 Unsupported Operations

Not applicable.

1.4 Prerequisites

A PNR must be present in the AAA:
If the user works on an existing PNR that has already been end-transacted, the PNR has tobe previously retrieved. This can be done via the verb PoweredPNRRetrieve.

If he works on a new PNR, name elements and segments must be present in the PNR. This can be done via the verb PoweredPNRAddMultiElements.

The context must be kept between the different transactions.

2 Building A Query

Input parameters:

Only the input parameters containing the frequent traveler information are mandatory.

Input parameters involved in the Frequent Traveler Verification:

• action request: see fqtvData in the codesets
• airline code: Frequent Flyer Card owning airline
• frequent flyer number
• In the context of interactive validation, the certificate number: this field contains a number, delivered by card owner airline, which identifies the content of upgrade request in card owner airline system. (passenger name, flights, dates..)

Input parameters involved in the Related Product Information

• The status code that will be used for the SSR FQTR added

Input parameters involved in the Interactive Free Text

• Free text: can contain a reason for the redemption

Input parameters involved in the Reservation Control Information

• reservation control number: this field contains the Amadeus record locator

Input parameters involved in the Traveler Information

• The passenger surname
• The passenger given name
• The traveler reference number: this field contains the tattoo number of the passenger that will be associated to the SSR FQTV. It has been transmitted in a previous response message.

Input parameters involved in the Travel Product Information

• The segment reference number: this field contains the tattoo number of the segment that will be associated to the SSR FQTR. It has been transmitted in a previous response message.

3 Receiving A Reply

If the process is successful

• For airlines users of the AF group Customer Application:
  • One or several validated SSR FQTR elements are created.
  • And/Or an FD element is created.
  • And/Or Warning messages are displayed.
  • SSR FQTR elements, warnings, FD element are sent in the reply message.
• For other airlines
  • One or several SSR FQTR elements are created. They may be validated or not.
  • SSR FQTR elements are sent in the reply message.

If the process is not successful: an error is sent in the reply message

Remark: This transaction does not save the PNR. The update will become effective after a Commit transaction. Therefore a context must be kept between the different transactions.

A generic reply can contain

• a record locator
• a generic error containing:
  • An error code: the Amadeus canned message number corresponding to the error
  • An error category for either a Mutually defined warning (code WZZ) or a Mutually defined error (code ZZZ)
  • An error code owner (always 1A)
• A generic error message
• One or several Travel Product Information containing:
  • The segment reference
• A Traveler Information containing:
  • The passenger surname
  • The passenger given name
  • The passenger reference
• One Frequent Traveler Verification per SSR FQTR created containing:
  • The alliance tier description
  • The Frequent Flyer Card owning airline
  • The target airline
  • The Frequent Flyer number
  • The category: set to PAX if the element is an FD
  • The certificate number
  • The airline priority code or tier level
  • The award code
• A Related Product Information containing:
  • The status code of the SSR / FD
• A Free Text containing:
  • The reason for the redemption
• A Frequent Flyer error containing:
  • An error code: the Amadeus canned message number corresponding to the error
  • An error category for either a Mutually defined warning (code WZZ) or a Mutually defined error (code ZZZ)
  • An error code owner (always 1A)
• A Frequent Flyer error message

Note: this is only a generic reply. In reality, all these fields can not be present at the same time.

In case of error, see the "Error Message" section.

Generic reply containing Passenger information:

4 Error Messages

Generic Edifact error

The reply contains only the error information and the error message.

Generic errors

In these cases, the reply contains the record locator if given in the request, the error information and the error message.

Errors linked to the Frequent Flyer Add process

In these cases, the reply contains the record locator if given in the request,the Frequent Traveler Verification given in the request, the error information and the error message.

Errors linked to the Interactive validation process

In these cases, the reply contains the record locator, the error information returned by the airline loyalty system (the airline which was asking for aninteractive validation) and the error message.

Note:

• The messages below are just examples. The list is not an exhaustive list.
• These error messages are returned by the loyalty system of the airline which is asking for an interactive validation. Do not forget it could be target airline or card owner airline.

Errors linked to the Interactive validation process

In these cases, the reply contains the record locator, the errorinformation returned by the airline loyalty system (the airline which was asking for aninteractive validation) and the error message.

Note:

• The messages below are just examples. The list is not an exhaustive list.
• These error messages are returned by the loyalty system of the airline which is asking for an interactive validation. Do not forget it could be target airline or card owner airline.

5 Operations

5.1 Operation: Add an SSR FQTR

There must be a PNR retrieved with record locator XXXXXX or in creation in the AAA.

The example shows the message required to add an SSR FQTR specified by the following data:

5.1.1 Query Structure

5.1.2 Reply Structure

5.1.3 Possible Errors

See "Error Messages" section.

5.2 Operation: Add an SSR FQTR with associations

There must be a PNR retrieved with record locator XXXXXX or in creation in the AAA.

The example shows the message required to add an SSR FQTR specified by the following dataand associations:

5.2.1 Query Structure

5.2.2 Reply Structure

5.2.3 Possible Errors

See "Error Messages" section.

5.3 Operation: Add an SSR FQTR with certificate number for interactive validation

There must be a PNR retrieved with record locator XXXXXX or in creation in the AAA.

The example shows the message required to add an SSR FQTU specified by the following dataand associations, with a certificate number:

5.3.1 Query Structure

5.3.2 Reply Structure

5.3.3 Possible Errors

See "Error Messages" section.

5.4 Operation: Generic Reply

5.4.1 Query Structure

5.4.3 Possible Errors

Function: Retrieve

1 Overview

The function Retrieve is used to retrieve and display an active passenger name record (PNR) or to redisplay a PNR during the current user session.

1.1 Supported Operations

The PNR Retrieve function allows for the following operations:

1.2 Limitations

The function Retrieve will only work on completed reservations. The reservation must have been completed and stored with an assignment of a system record locator to be acknowledged in the retrieval process. Except in the case of a simple redisplay retrieval request, where the active unfinished reservation information will be returned.

It is not possible to retrieve a PNR by specifying segment information for a segment that is past its departure date. In addition, any PNR that has a completion date greater than three days is no longer available in the system for retrieval.

It is strongly recommended to use the enumerated types provided instead of hard coded numerical values in your code.

1.3 Unsupported Operations

The following operations are not available from within this function:

• Partial PNR element retrievals
• Retrieval of group PNRs with individual names returned
• Displaying Airline System record locators
• Retrieval of PNRs by specifying MCO information
• Retrieval of PNR elements applicable to a specific passenger
• Retrieval of PNR by a Customer or Product Number
• Retrieval of PNR AIR element detailed information only
• Retrieval of PNR CAR element detailed information only
• Retrieval of PNR HOTEL element detailed information only
• Retrieval of merged split PNR elements direct with specification of record locator.

1.4 Prerequisites

Prior to using the function operations, it is necessary to have ( either depending on the type of operation) an active PNR in the session or stored records in the system.

2 Building A Query