Task: Issue MCO with Reason Code

Issues a MCO with Filed Fares with explicit mention of reason code. The reason code can be any single alpha-numeric character, other than 0.

Section 1: Short Answer

Transaction Name:

DocProdFareManipulation_13

Can any other transactions(s) perform this same task?

No.

Can this task be performed in a sessionless environment?

No. A Booking File / PNR with Filed Fares is required.

Are the request and response identical on both the Apollo and Galileo systems?

No, this is specific to the Galileo.

List any industry-specific knowledge required to understand this task in terms of the specific business process.

Knowledge of reservations, fares and ticketing is required, as well as knowledge of MCO issuance.

Explain any special limits or distinct restrictions to the input data that may not be readily apparent.

None.

Section 2: Detailed Description

Request:

Unless otherwise specified, use ALL CAPS in any request data.

Following are the steps required to carry out this task:

The PNR/BF must be created with a filed fare
Linkage must be set up to an ATB2 printer
Insure there is a fare quote with an authorized plating carrier
Insure these ticketing modifiers are present TMU1FS/Z9/PT
End transact the Booking File
Send the fare number in the <FareNumInfo> (DPFI KLR), e.g. 001.
Send the transaction type in the <TicketingControl> (DPTK KLR), e.g. TK.
The <ElectronicTicketFailed> contains alternate ticketing information if the electronic ticket failed.

In the <TicketingMods> (4032 Data Record), the <TicketingControl> will initially be sent using the ‘TK’ transaction type to request a ticket (see Task Issue Ticket).

If the host processing determines that this is MCO issuance request, a response <TicketingControl> with an ‘MA’ transaction, and additional elements, are returned. This indicates equivalence of MCOA FIF generated on terminal emulation with TKPMCOxxx/R-y entry.

As a follow-on request (with data from the previous response), send a <TicketingMods> request with the <TicketingControl> element with the ‘MA’ transaction code, in addition to all other tags in the previous response.

Prerequisite tasks:

A PNR/BF must exist.
A fare must exist.
Printer linkage must be set up.

Expected response:

For the initial response of <Ticketing>

<FareNumInfo> (DPFI KLR) contains the fare number.
<TicketingControl> (DPTK KLR) contains the control information for ticketing.
When Extended Billing Data (EBD) is required by the credit card vendor (when FOP is CC), then an “MA” transaction code is returned.

The follow-on response of <Ticketing> (with the <TicketingControl> element containing the ‘MA’ transaction code plus the additional tags for a complete MCO issue request) will be the associated MCO tags displayed in the tables in Section 3, assuming no additional data is required and no errors are encountered.

Error and warning responses:

Errors are returned in the <Ticketing> response, in the <ErrText> element.

If the wrong data or format is entered, the following error response is returned, with the reason code in the <MCOReasonCode>
ERROR 7890 – INVALID FORMAT - REASON CODE
If the request is incorrect either due to incorrect data in BF or incorrect data in the request
ERROR 259 – INVALID FORMAT/DATE

The following error messages are returned from Category 35 fares:

9095 – NET TICKET DATA MAY NOT BE MODIFIED
To resolve, cancel it and re-quote for published fares or other fare types.
9096 – UNABLE TO TICKET – NET FARE TOUR CODE EXCEEDS MAXIMUM LENGTH
To resolve, cancel and re-quote, changing parameters to get a new quote, such as a public fare, specific fare, etc.
9097 - NOT AUTHORISED TO TICKET THE FILED FARE. CANCEL AND REFILE
To resolve, cancel the stored fare and re-quote as own identity.
9099 – INVALID CAT35 COMMISSION RETURNED. CANCEL AND REFILE
To resolve, cancel and re-quote, changing parameters to get a new quote, such as a public fare, specific fare, etc.

Follow-on requests:

On Galileo, after the previous follow-on request with the <TicketingMods> (‘TK’), and a transaction of 'MA' (with additional complete tags as stated previously), the follow-on request is to enter the <TicketingMods> (4032 Data Record) with the following elements:

The <TicketingControl> (DPTK KLR) with a ‘MA’ transaction code.
Additional completed tags (KLRs).

Section 3: Tables

Request with TKPMCO (Galileo Only)

Below tables are equivalent for terminal entry – TKPMCO, with data/modifier - (PTA/TOD/OTH) and Reason code.

Request (Input) Tags

<TicketingMods>

Terminal Equivalents:

Apollo
N/A

Galileo
TKPMCO

Ordering	KLR	Min/Max	XML Tag
A	DPFI	1-1	<FareNumInfo>
B	DPTK	1-1	<TicketingControl>
C	DPM1	1-1	<MCOTicketData>
D	DPMC	0-1	<MCOReasonCode>

Response (Output) Tags

<Ticketing>
	Ordering	KLR	Min/Max	XML Tag
	A	DPTK	0-1	<TicketingControl>
	B	DPM1	0-1	<MCOTicketData>
	C	DPMG	0-1	<PTATODFee>
	D	DPMA	0-1	<MCOTicketing>
	E	DPMR	0-1	<MCORemarks>

<Ticketing>		Error response
	Ordering		KLR	Min/Max	XML Tag
	A		DPFI	0-1	<FareNumInfo>
	B		EROR	0-1	<ErrText>

Related Samples

DocProdFareManipulation_13_s22