V2User's Guide
|
V2 User's Guide |
The Powered Ticket interface has been designed and implemented to facilitate the means of providing a stand-alone Credit Card validation for common Credit Card data. A valid PNR is required to perform some transactions, however the validations are performed independently of any other data. It should be noted that cards issued in the United States of America and in Canada perform address verification.
Another integral part of this interface is the Transitional Stored Ticket also known as the TST it is a record containing all the ticketing information attached to a PNR.
The Ticketing operations have been categorized in the following functions:
Operation used to check the form of payment made with a credit card and able to obtain an approval code status for the transaction made.
Operation used to check the validity of a Credit Card.
Operation to Authenticate Description Billing Data.
Operation used to return information on an existing TST.
Operation to alter an existing TST.
Delete existing TST or TSTs
Consists of Get Airport control and Push Airport Control.
Get Airport control allows airport control of ET flight coupons from a carrier to be requested.
Push Airport Control permits the transfer of control of ET flight coupons to a carrier to be requested.
This transaction has been created with the objective of providing Amadeus Customers with an automated solution for the re-issuance of airline ticket after involuntary changes.
Operation Used to create an empty TST manually, only containing most basic information (passenger/ticket information, SATA or OPEN option)
The Powered Ticket, AlterTSTSegmentAssociation request offers a means of re-setting the links between a TST and its related segments.
Eticket Void : This function is used to void an Eticket
Eticket Print: This function is used to request a paper ticket
Eticket History Display: This function displays electronic ticket history
Eticket List Display: This function displays a list of electronic tickets
Eticket Single Display: This function displays a single electronic ticket
Operation used to confirm the creation of the TST after a pricing transaction.
Not applicable
There are currently no known limitations to the actual Interface itself. All functional limitations are listed within the applicable function areas of this document.
Not applicable
Not applicable
The Powered Ticket, Credit Card Authorization request offers a means of checking the form of payment made with a credit card and is able to obtain an approval code status for the transaction made. For cards issued in the US and CANADA you can also make an address verification. Credit Card checks can be preformed without the issuance of a ticket.
Important: the address verification field in your office profile* must be set to ON to allow you to use this function. If it is not set the verification process is stopped and an error message is returned. Additionally, an approval code is only valid for a ticket issued on the Day that the approval code was obtained. Once obtained, an Approval cannot be cancelled through the system.
* To know more about the Office Profile please refer to the Powered Profile User's Guide.
This option allows for credit card check as the form of payment.
For the cards issued in the United States of America and in Canada address verification is performed, therefore to use the Credit Card Check function this field in the Office Profile* needs to be set. Otherwise, when the function is performed the verification process is stopped and an error message is returned.
* To know more about the Office Profile please refer to the Powered Profile User's Guide.
Not applicable
There are no specific requirements to use Powered Ticket Interface except a valid Credit card.
The following code sets may be used when building a query for the Interface Powered Ticket, Credit Card authorization Function:
| Code | Currency Cardholder Billing |
|---|---|
| 840 | USD |
| Code | AVS Result |
|---|---|
| Y | Exact match (both address and POSTAL code) |
| Z | Partial match on POSTAL code (address does not match) |
| U | CCAVS info not available |
| A | Partial match on address (POSTAL code does not match) |
| N | No match (nor address, nor POSTAL code) |
| R | Retry later (authorization system unavailable) |
| E | Error in transaction (not eligible for CCAVS) |
| S | Service not valid for CCAVS |
When transmitting the Credit Card Authorization request to VISA, in the authorization message the country code is the country code of the point of sale (officeId). But there is the possibility to override this country code with a given one by entering it in the field Country of this verb. This country code override will only work for:
- CA / XS / BZ / EC cards
Country code (Alpha Numeric 2)
FR
GB
If the request was not successful, the CreditCardCheck will respond with an appropriate error message. The error messages returned depends upon the specific situation encountered, the possible errors that are unique to a specific operation are covered in the individual operation scenarios within this document.
If you do not specify a currency value in the PriceInfo section, the system defaults to USD (American dollars). It should also be noted that gaps should not be left between numbers when entering the cardNumber value, as this will cause the system to report an erroneous error at validation time. However, for clarity in the examples listed in this document spaces have been left to aid in the readability of this document.
| /commonCcData/ccInfo/cardNumber | 4410 0301 1234 0024 |
This message is the result of a Credit card check digit (last digit of credit card number). For example, the original card number given was 3782 9102 7851 004 and the check digit was changed to a number '3', to make the card number valid 3782 9102 785 1003.
| 4377 | INVALID ACCOUNT NUMBER |
This message is the result of a Invalid expiry date.
| 1149 | CREDIT CARD EXPIRED |
This message is a result of a missing expiry date in a query.
| 1146 | EXPIRATION DATE MISSING OR INVALID |
Additionally, following errors may be encountered:
| ERROR MESSAGE | CODE | DESCRIPTION |
|---|---|---|
| ERR CC SECURITY ID IS A MATCH | 12677 | Security ID on the back of the CC matches the data kept by the issuing bank. |
| ERR CC SECURITY ID DOES NOT MATCH | 12678 | Security ID provided at entry time doesnt match the above |
| ERR CC SECURITY ID NOT PROCESSED BY CREDIT CARD VENDOR | 12682 | the data is not supported by the CC vendor (ie: brand) Ie: TP, JCB etc. |
| ERR CREDIT CARD ISSUER DOES NOT SUPPORT SECURITY ID | 12683 | Issuing bank system is unable to cope with CC sec ID data |
| ERR CREDIT CARD ISSUER STATES SECURITY ID IS ON THE CARD | 12684 | when CV is entered with M as missing (client states theres no CC sec id on his card) but bank responds there IS one present. |
Create a visa card payment without address information.
All standard error messages are outlined in the section, "Error Messages".
Create a master card payment with address verification information.
All standard error messages are outlined in the section, "Error Messages".
Create a visa card payment with country code override option.
All standard error messages are outlined in the section, "Error Messages".
create a payment for american express credit cards.
All standard error messages are outlined in the section, "Error Messages".
Further to the VbV (Verified by Visa) project, new data field may be carried into the CC message when the request for authorization is sent to the CC Company (onto the VISANET link). This is applicable to VISA cards (vendor code VI) and MASTERCARD group (vendor codes: BZ, CA, EC and XS).
This occurs when an authentication process (client identity verification) occurred upstream the authorization process (card creditworthiness check). This authentication process occurs in the case the cardholder is subscribing into the VbV program through an enrolled issuing bank. It enables the bank to verify that the cardholder is properly authenticated when purchasing goods over the Net.
The authentication fields available are listed as such:
See "Error Messages" section.
This example creates a payment for american express credit cards.
See "Error Messages" section.
The security Id may be conveyed to the CC database. A dedicated field, securityIdResponse, is sent back in the reply.
See "Error Messages" section.
The Validate Credit Card function requests Credit card validation from the preferred Credit card company, in return the Credit card company is sending back an approval code to validate the request made in the Passenger Name Record (PNR).
The Powered Ticket, Validate Credit Card function allows for the validation of an accepted Credit Card
Here is a list of the Credit Cards accepted by the System:
It should be noted that not all airlines accept all credit cards listed as a form of payment. Also it should be noted that even though an airline may well accept a specific credit card as a form of payment, it might not allow automated approval processing in the Amadeus system.
Not applicable
A pre-requisite to use the Validate Credit Card function is to validate the card. Data requirements include such items as: Credit Card number, expiry date, vendor code and agent type.
The validation process can be stopped for one of the following errors: The Credit Card has expired, there is an invalid account number and or the form of payment is invalid.
Depending on the flavor of the API that is used, each query will follow a given structure. The queries for the function operations are clearly explained with data element examples in a generic table view that can be adapted to the specific flavor of the API in use. It is important to note that the examples in each chapter are only illustrations and are meant to provide the basis for a better understanding on which fields are mandatory for basic operation utilization. It is not a full explanation of every field that can be utilised for the operation, but rather a guideline to its use.
There is only one mandatory field in the query and that is the authorization process type, such as FP.
The following code sets may be utilised when building a query for this function:
| Code | Company Identification |
|---|---|
| AB | Australian Bank |
| AU | Carte Aurrore |
| AX | American Express |
| BC | Bank Card of Japan |
| BH | Bank of Hawaii |
| CA | Mastercard |
| CB | Carte Blanche |
| CS | Citizens amp; Southern National Bank |
| CU | Connecticut Bank/Trust Co |
| CX | City National Bank Coice Card |
| DC | Diners Club/American Torch Club/Sun Diners Club |
| DS | Discover Card |
| EC | Eurocard |
| FH | Federation Nationale de l'industrie Hoteliere |
| ID | Comites |
| IK | Interbank |
| JC | Japan Credit Bureau |
| MC | Million Credit Service |
| MD | Diamond Credit |
| MT | AEmpire Card |
| OK | Finnish domestic credit card |
| OT | OTB Card |
| RA | Raptim-France |
| SC | Shoppers Charge |
| SR | Select Credit |
| TC | Trust Card |
| TP | Universal Air Traval Plan (Air Traval Card,Airplus,PassAge) |
| UD | Union Credit Bankcard New Zealand |
| VI | Visa International Discover Card |
| WB | Walker BankCard |
| XS | Access |
| Code | Form Of Payment Identification |
|---|---|
| CC | Credit Card |
| Code | Response Type, Coded |
|---|---|
| U | Descriptive Billing data updated |
| Code | Processing Status Code |
|---|---|
| P | OK processed. No data follows |
| Code | Processing Indicator, Coded |
|---|---|
| B | Credit Card authorization based on both PNR and MCO Form of Payment |
| FP | Credit Card authorization based on PNR Form of Payment |
| MCO | Credit Card authorization based on MCO form of payment |
The authorization code (also known as approval code) can vary from 1 to 6 characters and is returned in the PNR (Passenger Name Record).
In this example the data for the attribute is sent as well as the approvalCode for the validation made and the PNR is updated with the approval code, which could be anything up to and including 6 characters. This information needs to be 'captured' and used to fill up the ValidateDescBillData function fields.
On processing a Validate Credit Card request there are only two outcomes possible, either a rejection or an authorization for the transaction. If the request was not successful, the response will be an appropriate error message.
Validate credit card using a generic credit card.
See the section, "Error Messages".
Further to the VbV (Verified by Visa) project, new data field may be carried into the CC message when the request for authorization is sent to the CC Company (onto the VISANET link). This is applicable to VISA cards (vendor code VI) and MASTERCARD group (vendor codes: BZ, CA, EC and XS).
This occurs when an authentication process (client identity verification) occurred upstream the authorization process (card creditworthiness check). This authentication process occurs in the case the cardholder is subscribing into the VbV program through an enrolled issuing bank. It enables the bank to verify that the cardholder is properly authenticated when purchasing goods over the Net. That is the reason why, these authentication data may only be available in the transaction for Amadeus clients using the Planitgo application.
The authentication fields available are listed as such:
See "Error Messages" section.
The Validate Descriptive Billing data function provides the foundation, in cooperation with AirPlus® in Germany, for Descriptive Billing when a Payment is made by selected AirPlus® Cards*. The descriptive billing information allows a customer to reconcile their travel expenses into categories, for example by booking date.
This function will be used by all AMADEUS locations that have subscribed to this function with AirPlus® when authorization is requested for selected AirPlus Cards, either in connection with ticket issuance or as a standalone entry or as PNR (Passenger Name Record) Credit card form of payment processing. The Stand Alone Entry is used for any type of service other than automated tickets or as fallback when Descriptive Billing Data for any reason was not captured in connection with Ticket Issuance. It should be noted that the billing is not performed by AirPlus® in Germany and not Amadeus.
*http://www.airplus.com
Not applicable
There is a limit of up to 10 occurrences of attributeDataLabel in the same record. You are limited to 15 characters maximum in length for the accountNumber.
Not applicable
Not applicable
Depending on the flavor of the API that is used, each query will follow a given structure. The queries for the function operations are clearly explained with data element examples in a generic table view that can be adapted to the specific flavor of the API in use. It is important to note that the examples in each chapter are only illustrations and are meant to provide the basis for a better understanding on which fields are mandatory for basic operation utilization. It is not a full explanation of every field that can be utilised for the operation, but rather a guideline to its use.
| Data element | Value |
|---|---|
| /returnCode/type | U |
| /returnCode/statusCode | P |
The function returns an acknowledgement of reception, if the data entered by the end user does not pass the field format validation, then message 'INVALID FIELD LENGTH' is sent.
Validate description billing.
See the section, "Error Messages".
A transitional stored ticket (TST) is a record containing all the ticketing information associated to a passenger name record. The system automatically stores information requested from the Fare Server in the TST.
The system creates automatically multiple TST if:
*When the system creates more than one MST, the output of the TTC command is a TST index. Since no pricing data is returned from the Fare Server, the TSTs total defaults to zero (0).
If more than one TST exists, the system numbers the TST and appends the TST creation date, office identification and agent sign to the TST.
If a PNR contains more than one TST, active and/or deleted, a TST INDEX is created by the system and may be displayed by the user. (TQT)
If only deleted TSTs exist, a TST index is also created showing the deleted TSTs.
If no EOS agreement, only the office who sets the confidentiality of the TST can access, read and update the TST. The Office creating or retrieving a TST (not necessarily the one creating the PNR) is able to flag the TST as confidential, restricting the access of that TST to any other office An Asterix is appended to the header line of the PNR meaning that at least one of the TST(s) present in that PNR is confidential. An asterix is also appended to the confidential TST number(s).
PNR
RP/MUC1A0701/MUC1A0701 BM/PR 9DEC98/0821Z ZL6GMX
- AGUIA/MR 2.ELEFANTE/MR
- RG 117 Y 09FEB 2 POAGRU HK2 2 1730 1900 *1A/
- RG 818 Y 09FEB 2 GRUMIA HK2 2 2355 0455+1 *1A/
TST INDEX
T P/S NAME TOTAL FOP SEGMENTS
- * .1 AGUIA/MR EUR 1862.61 CASH 3-4
- .2 ELEFANTE/MR EUR 1862.61 CASH 3-4
Itinerary changes made subsequent to TST creation may be moved from the PNR into the TST automatically by the system; e.g. schedule change. The TST panel contains a 'PC' flag to alert the user of an itinerary change to the PNR subsequent to TST creation. The purpose of the flag is to warn the user to check the fare stored on the TST because of an itinerary change.
Whenever the PNR Change flag is activated under one or several TSTs, (name change, itinerary update etc.),it is simultaneously added to the TQT list associated to the corresponding TST. The two letters 'PC' are displayed in the TST header as well as in the TST index. It can be manually removed by performing a TTF command.
There are two different types of tickets, namely:
A manual stored ticket (MST) is a TST which has been created manually (TTI,TTC), or an automatic TST that has been updated manually.
An Automatic Stored Ticket (AST) is automatically created by the system as a result of a PNR itinerary pricing command. The ticket image is for information only as the system uses the TST to issue the ticket an identification is placed on the header line of the PNR to indicate that a TST is attached to a PNR.
If a TST does not exist and a ticketing command, is entered, the system prices the airfare for the PNR (except if the multiple fares exist for the same class), creates the TST and the interface record which is sent to the ticketing system to request issuance.
Some negociated data are confidential. As such access to this data is restricted in case of Negociated Fares used for pricing;
Base Fare is always accessible
Net Fare and Published Fare are accessible according to the office profile setting.
So, in the response to a TSTdisplay, Base Fare will always be present with codeset B (selling Fare). Net Fare (codeset H) and Published Fare (codeset PU) will only be present if TQN in the office profile is set to Yes.
Display TST.
A Fare calculation panel has been created to support an automatic pricing of 16 segments which implies a fare calculation line extended to 547 characters. Whenever the Fare calculation line exceeds 247 characters (standard length), a symbol "+" is displayed on the 248 position of the main Ticket panel.
The following fare element information is stored both in the PNR and the TST when using native cryptic entries.
These elements are NOT returned in the PoweredTicket_DisplayTSTReply, but may be obtained using the PoweredPNR_Retrieve.
1st Phase: From March 31st to June 1st
2nd Phase: From June 1st
TST History.
A newly created or an existing PNR with segments containing ticketing information.
Depending on the flavor of the API that is used, each query will follow a given structure. The queries for the function operations are clearly explained with data element examples in a generic table view that can be adapted to the specific flavor of the API in use.
It is important to note that the examples in each chapter are only illustrations and are meant to provide the basis for a better understanding on which fields are mandatory for basic operation utilisation. It is not a full explanation of every field that can be utilised for the operation, but rather a guideline to its use.
Not applicable.
Not applicable.
A Standard ValidateCreditCard response is received.
Display TST of PNR YQQJ68.
A Standard ValidateCreditCard response.
Display TST with passenger selection (including infant).
A Standard ValidateCreditCard response.
Display TST with passenger selection (without infant).
A Standard ValidateCreditCard response.
Display TST with segment selection.
A Standard ValidateCreditCard response.
Display TST with scrolling.
A Standard ValidateCreditCard response.
Scrolling on.
A Standard ValidateCreditCard response.
Display TST with TST select.
A Standard ValidateCreditCard response.
This example shows how to display all the TST.
See "Error Messages" section.
A transitional stored ticket (TST) is a record containing all the ticketing information associated to a passenger name record.
A manual stored ticket (MST) is a TST which has been created manually (TTI, TTC), or an automatic TST that has been updated manually.
An Automatic Stored Ticket (AST) is automatically created by the system as a result of a PNR itinerary pricing command. The ticket image is for information only as the system uses the TST to issue the ticket an identifier is placed in the header line of the PNR to indicate that a TST is attached to a PNR.
If a TST does not exist and a ticketing command, is entered, the system prices the airfare for the PNR (except if the multiple fares exist for the same class), creates the TST and the interface record which is sent to the ticketing system to request issuance.
The TST can be updated:
The modification can be done on different fields of the TST.
A TST modified by the request UpdateTST becomes a MANUAL TST.
In order to use the UpdateTST function, the TST Tattoo number should be used to define which TST in the PNR needs to be modified.
Update TST.
The Update TST function allows to Update ONE TST.
The following fare element information is stored both in the PNR and the TST when using native cryptic entries.
These elements are NOT returned in the PoweredTicket_UpdateTSTReply, but may be obtained using the PoweredPNR_Retrieve.
Not applicable.
A newly created or an existing PNR with segments containing ticketing information. The TST that needs to be updated should be present in the PNR.
The Update query has the structure that is in fact the sub-structure of the TST display response (PoweredTicket_DisplayTSTReply ) containing all the potential modified data.
In order to update a TST, the query should contain the ticket image (TST display response) with all the potential modified or not. If an unmodified data is not mentioned in the query, this data will be erased from the TST.
PoweredTicket_UpdateTSTReply has the same structure as the TST display reply. As we can update only one TST, the TST update Reply provides the Ticket image of the updated TST in the same way as the TST display reply.
Not applicable.
Not applicable.
The update TST example
Not applicable.
A transitional stored ticket (TST) is a record containing all the ticketing information associated to a passenger name record.
The function DeleteTst allows one or many TSTs present in the PNR to be deleted. It allows deleteTST(s) with TST selection or the passenger or segment selection.
Delete TST
Not applicable.
Not applicable.
A newly created or an existing PNR with segments containing ticketing information. The PNR needs to contain TST(s) to delete.
Depending on the flavor of the API that is used, each query will follow a given structure. The queries for the function operations are clearly explained with data element examples in a generic table view that can be adapted to the specific flavor of the API in use.
It is important to note that the examples in each chapter are only illustrations and are meant to provide the basis for a better understanding of which fields are mandatory for basic operation utilisation. It is not a full explanation of every field that can be utilised for the operation, but rather a guideline to its use.
Not applicable.
Not applicable.
Not applicable.
Delete all the TSTs present in the PNR.
Not applicable.
Delete a TST with a TST Tattoo number.
Not applicable.
Delete a TST with a TST number.
Not applicable.
Delete TSTs associated with the passenger selected.
Not applicable.
Delete TSTs associated with the tattoo segment selected.
Not applicable.
Contains ET - Electronic Ticket - related functions:
This function allows to request airport control of ET flight coupons from a carrier.
This function allows requesting the transfer of control of ET flight coupons to a carrier. It is also known as Redirect Airport Control. The carrier that the control is pushed to is known as the new operating carrier.
This function can be used in interline scenarii.
All targeted flight coupons shall belong to the same ET.
This function cannot be used in ground handling scenarii.
The user should be familiar with ET functionality and can refer to the IATA Passenger Services Conference Resolutions Manual Resolution 722f (airline) and Resolution 722g (neutral) for more details.
An ET record shall be attached to the AAA
The involuntary indicator can be part of the query.
The query shall contain the ET flight coupons airport control is requested for.
The query shall contain the ET flight coupons that airport control is being pushed together with the new operating carrier.
The reply acknowledges or rejects the Get Airport Control request or Push Airport Control request.
For valid transactions, a message is sent to the ET database of the airline the requesting office belongs to, to request the ET update. If the ET database reply indicates the request was processed successfully, the system returns:
| 09173 | OK ETKT RECORD UPDATED |
The following example illustrates a successful push airport control.
The get airport control request is only valid after an ET display request. If no ET record is attached to the AAA, the system replies:
| 07108 | NO ET DETAILED RECORD PRESENT |
The ET flight coupon(s) specified in the request must exist in the ET. The system rejects a wrong coupon specification with the following message:
| 10592 | INVALID COUPON NUMBER |
If the coupon status is not "O" nor "A" nor "N", the system rejects the transaction with the following message:
| 05486 | INVALID TICKET/COUPON STATUS |
For valid transactions, a message is sent to the ET database of the airline the requesting office belongs to, to request the ET update.
If the ET database reply indicates the request is rejected for validating carrier YY, the system returns the error message contained in the ET database reply:
YY ETKT: ERROR MESSAGE
This example illustrates a get airport control request for the first coupon of an AA ET.
AA may reject the request.
This example illustrates the redirect airport control of the second coupon of an AY ET to the new operating carrier IB. Involuntary Reroute indicator is set in the query.
AY may not support the redirect airport control message.
Context:
This transaction has been created with the objective of providing Amadeus Customers with
an automated solution for the re-issuance of airline ticket after involuntary changes.
The AutomaticUpdate function re-prices one passenger for the entire flight itinerary or
for a selected flight itinerary in a newly created or retrieved PNR.
The system re-prices one passenger for involuntary reissues/exchanges in accordance with IATA guidelines.
The class of service is obtained automatically from the PNR. The re-pricing concerns E-Ticket documents. This transaction store and create a corresponding TST record which would include all the re-issue involuntary data. It is possible to select only one passengerType (infant or Adult) in a PNR and to re-price its itinerary.
It is possible to choose which parts of a segment are to be included in the itinerary pricing.
It is possible to choose which part of the original e-ticket has to be exchanged. This selection must begin with the first coupon open for use.
AutomaticUpdate function allows for the following supported operation(s):
Only the involuntary repricing option is supported.
The End-User must be authorized to perform an Amadeus Ticket Update transaction. The office profile is checked in order to authorize the Amadeus Ticket Update process and/or redirect the End user to the current manual process.
Data availability:
E-Ticket must be accessed in order to retrieve all the necessary data pertaining to the Original document.
Once the retrieval has been done, the process can be performed using old/new information. The AutomaticUpdate function needs the following elements:
If the PNR contains only one passenger (with no infant), the Passenger selection is not mandatory. Therefore, for a PNR with more than one passenger or with infant, the passenger selection is mandatory.
Concerning the Passenger or the segment selection, the tattoo numbers need to be specified.
Depending on the flavor of the API that is used, each query will follow a given structure, the queries for the function operations are clearly explained with data element examples in a generic table view that can be adapted to the specific flavor of the API in use.
It is important to note that the examples in each chapter are only illustrations and are meant to provide the basis for a better understanding on which fields are mandatory for basic operation utilisation. It is not a full explanation of every field that can be utilised for the operation, but rather a guideline to its use.
A TST has been created if the transaction is successful.
In the example we receive the tattoo of the TST element created and also pax and segment tattoo
CM00005 - Check segment number
A segment with the TATTOO number specified in the REF segment is not present in the PNR
CM00011 - Unable to process Process error - normally it should not be related to data from the request
CM00258 - Function not supported Request a functionality not yet implemented
CM00477 - Invalid format Data specified in the request is not valid, although is OK from the message definition
CM01908 - Check passenger number
A segment with the TATTOO number specified in the REF segment is not present in the PNR
CM01959 - Need PNR A request has been made without a retrieved/newly created PNR.
CM02230 - Single selection code only Different passenger types specified in the same REF segment.
CM04070 - Unable to process + seg name
Process error - normally it should not be related to data from the request - the name of the program where error occurred is appended at the end of the message.
Here is an example of query with a passenger selection (pax 1) and a coupon selection (coupon 2 and 3).
See "Error Messages" section.
The Powered Ticket, CreateManualTST request offers a means of creating a TST manually and filling it in with the most basic data. Among this data, there are Passenger/segment/TST/fare tattoo reference number, the record locator, and the possibility to flag the TST OPEN or SATA (these are two possible options, one excludes the other).
Not applicable
The other data contained in the TST must be added via updates.
Not applicable
At least one name and one segment must exist in the PNR.
The query must contain the passengers/segments for which TST is created. It is possible to append a SATA or an OPEN option. Below is an example of a SATA option.
The replies received (except error messages) contains TST number and Passenger/segment association
1908 CHECK PASSENGER NUMBER
If passenger number does not match a passenger number in the PNR.
5 CHECK SEGMENT NUMBER
If segment number does not match a segment number in the PNR.
1903 CHECK PASSENGER ASSOCIATION
If there is an overlap
12363 SATA MEMBER CODE NOT FOUND
Create a TST with SATA option for passenger 1, segments 1 and 2.
All standard error messages are outlined in the section, "Error Messages".
The Powered Ticket, AlterTSTSegmentAssociation request offers a means of re-setting the links between a TST and its related segments. At creation time a TST must be segment and passenger associated. The segment association is updated with this AlterTSTSegmentAssociation verb.
Not applicable
One TST only can be handled per message.
Not applicable
At least one name, one segment and one TST must exist in the PNR.
The query must contain the list of the new segments that will be associated to the TST and the TST tattoo.
The reply received (except error messages) contains the list of the new segments that have been associated to the TST and the TST tattoo
5 CHECK SEGMENT NUMBER
If segment number does not match a segment number in the PNR.
This example change segment association for TST 1.Once this message has been processed, TST 1 will be associated to segments 2 and 3 from the PNR.If other segments were associated to TST 1, they are removed from it.
See "Error Messages" section.
Eticket Single Display: This function displays a single electronic ticket
Eticket List Display: This function displays a list of electronic tickets
Eticket History Display: This function displays electronic ticket history
Eticket Print: This function is used to request a paper ticket
Eticket Void : This function is used to void an Eticket
See overview
Ticket number is mandatory field even for Eticket Void, Eticket Print or History display.
Before Eticket Void, Eticket Print or History Display, you have to perform an Eticket Display.
TWDRT entry is not covered
The user should be familiar with ET functionality and can refer to the IATA Passenger Services Conference Resolutions Manual Resolution 722f (airline) and Resolution 722g (neutral) for more details.
An ET record shall be attached to the AAA
The query shall contain the ET number that is requested to be displayed and the message function 131 for Single Display
The query shall contain the 3-alphanumeric airline code owing the electronic documents which are requested to be displayed and the message function 131 for List Display
The query shall contain the ET number whose history is requested to be displayed and the message function 137 for History Display
The query shall contain the ET number that is requested to be printed and the message function 132 for Print
The query shall contain the ET number that is requested to be voided and the message function number 133 for Void
The reply acknowledges or rejects the different Eticket follow up requests.
For valid transactions, a message is sent to the ET database of the airline owing the electronic documents. If the ET database reply indicates the request was processed successfully, the system returns:
SALE IS CANCELLED IN REPORTING SYSTEM
The ReplyExample to the following query can be found in the operation :
There is below the successfule reply to Eticket Single Display query which can be found in the operations.
See specific messages in each section
This function displays a single electronic ticket
If the ticket number entered in the request does not exist in the airline Eticket Data Base, you get an error with the errorCode 401
The following example illustrates a successful reply to Eticket Single Display
See "Error Messages" section.
This function displays a list of electronic tickets by Travel information and Passenger Name
See "Error Messages" section.
This function displays a list of electronic tickets by CC Number and Passenger Name
See "Error Messages" section.
This example shows a successful Reply to Eticket List Display
See "Error Messages" section.
This function displays electronic ticket history.
You must have displayed the Eticket before.
If you perform the Eticket History Display without performing an Eticket display before, you will get the following error:
“NO ET DETAILED RECORD PRESENT”
This example shows a successful Reply to Display Eticket History after having displayed the Eticket
See "Error Messages" section.
This function is used to request a paper ticket
"Message Function" 153 is not a valid UseCase
See "Error Messages" section.
This function is used to void an Eticket
If you perform a ticket void directly without displaying the Electronic ticket before, you get the error with errorCode 310:
“Ticket arrangement data missing”
When the document to void is not available to void ( see with TSR why ), you get the error with errorCode 354.
This example shows a successful Reply to Void Eticket after having displayed the Eticket
See "Error Messages" section.
This function provides Amadeus Customers with an automatic way to create TST.
In the TST, the system automatically stores information obtained from the Fare Server during a previous Pricing transaction.
There are as much as TST created as there are different passenger types and discount codes in the PNR.
Note: A TST (Transitional Stored Ticket) is a record containing all the ticketing information associated to a passenger name record.
The function CreateTSTFromPricing allows the following operation:
Create TST
A maximum of 10 TST can be created for each passenger.
Not applicable.
A pricing transaction must have been performed before.
At least one name and one segment must exist in the PNR.
The query contains the references to the different TST that have to be created. These references have been returned by a previous pricing transaction.
The received reply (except error messages) contains TST number and Passenger association
The reply contains the reference of the TST created with its passenger association.
There are as much as TST created as there are different passenger types and discount codes in the PNR.
Data:
TST Reference (IRV): the reference to the created TST (tattoo number and identification number)
Pax Information (REF): the reference of the passengers that are associated to the TST
In this example, the PNR contains 2 infants and 5 adults in the PNR and there are 4 different passenger types. Here is the reply obtained:
CM00001 - Unable to process
Process error - normally it shouldn't be related with data from the request.
CM00005 - Check segment number
A segment with the TATTOO number specified in the REF segment is not present in the PNR
CM00258 - Function not supported
Request a functionality not yet implemented
CM00339 - Need Name
The PNR does not contain any names.
CM00357 - Link down
A problem of communication between the different systems occurs.
CM00477 - Invalid format
Data specified in the request is not valid, although is OK from the message definition
Examples: recommendation number is not digit.
CM01908 - Check passenger number
A segment with the TATTOO number specified in the REF segment is not present in the PNR
CM01959 - Need PNR.
A request has been made without a retrieved/newly created PNR.
CM01966 - Need itinerary
There is no itinerary in the PNR.
CM02058 - Previous TST exists / Segment Overlap
The TST can not be created because there is an overlap with the existing TST.
The End User has to delete the existing TST if he wants to price the selected recommendation.
CM02230 - Single selection code only
Different passenger types specified in the same REF segment.
CM03052 - Maximum tsts this passenger
The maximum number of TST (10) is reached for a passenger
In this example, the End-User requires for the creation of the 4 TST previously returned by a pricing transaction.