Task: Issue Ticket

Issues a ticket for a specified fare or an MCO within a PNR or BF. All modifier updates must be stored with the fare prior to issuing the ticket or the MCO. No modifiers can be applied at the time of issuance.

Section 1: Short Answer

Transaction Name:

DocProdFareManipulation_7

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?

Yes, they are identical, except the Detailed Billing Mask processing (DPDB KLR), which is only on the Galileo system.

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

Linkage must be set up to a printer. If an itinerary and MIR are required, this linkage will need to set up as well.

On Galileo, the Detailed Billing Information (DBI), also known as Extended Billing Data (EBD), is required by some credit card vendors. This information is used along with the credit card number to identify the user of the card is valid and to track how the card is used.

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

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

On Galileo, when the Detailed Billing Information (DBI) is required, the amount and type of information required for input may vary depending on what the credit card vendor requires for the given card number. If the credit card vendor is not available, all possible fields may be presented for input, but are not all required.

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 stored fare.
Linkage must be set up to the printer.
Send the fare number in the <FareNumInfo>.
Send the transaction type in the <TicketingControl>.
The <ElectronicTicketFailed> contains alternate ticketing information if the electronic ticket failed.

Prerequisite tasks:

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

Expected response:

<FareNumInfo> (DPFI KLR) contains the fare number.
<TicketingControl> (DPTK KLR) contains the control information for ticketing. It will have the “OK” option for transaction type. If more information is needed, the appropriate response is used. For example, if the FAX number is needed the FX option is used. When Extended Billing Data (EBD) is required by the credit card vendor (when FOP is CC), then a “DB” transaction code is returned.
<RecordLocator> (DPRL KLR ) contains the record locator.
<DetailedBillingMask> (DPBD KLR) returns to be completed with Detailed Billing Mask data when the transaction type in <TicketingControl> is “DB”.

Error and warning responses:

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

If printer linkage is not established the following error response is returned:
ERROR 42 – INVALID ND LINKAGE
If there isn’t a form of payment the following error response is returned:
ERROR 4366 – FORM OF PAYMENT REQUIRED

If the wrong data or format is entered, the following error response is returned
ERROR 5355 – INVALID FORMAT/DATA - FORM OF PAYMENT REQUIRED

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 <TicketingMods> (‘TK’), and EBD (Extended Billing Data) is required (as stated previously), it returns a <Ticketing> response (4033 Data record) with the following elements:

<TicketingControl> (DPTK KLR), with a transaction of 'DB'
<DetailedBillingMask> (DPDB KLR)

The follow-on request is to enter the <TicketingMods> (4032 Data Record) with the following elements:

The <TicketingControl> (DPTK KLR) with a ‘DB’ transaction code
A completed <DetailedBillingMask> (DPDB KLR).

To issue an MCO with a reason code (TKPMCO) see Task Issue MCO with Reason Code.

See the Follow-on Request in the tables in section 3.

Section 3: Tables

Initial Request

Request (Input) Tags

<TicketingMods>

Terminal Equivalents:

Apollo
HB:

Galileo
TKP

Ordering	KLR	Min/Max	XML Tag
A	DPFI	1-1	<FareNumInfo>
B	DPTK	1-1	<TicketingControl>
C	DPEF	1-1	<ElectronicTicketFailed>

Response (Output) Tags

<Ticketing>
	Ordering	KLR	Min/Max	XML Tag
	A	DPFI	0-1	<FareNumInfo>
	B	DPTK	0-1	<TicketingControl>
	C	DPRL	0-1	<RecordLocator>
	D	TEXT	1-3	<TextMsg>

<Ticketing>
	Ordering	KLR	Min/Max	XML Tag
	A	DPFI	0-1	<FareNumInfo>
	B	DPTK	0-1	<TicketingControl>
	C	DPRL	0-1	<RecordLocator>
	D	EROR	0-1	<ErrText>

Follow-on Request (Galileo TKP)

Request (Input) Tags

<TicketingMods>

Terminal Equivalents:

Galileo
TKP

Ordering	KLR	Min/Max	XML Tag
A	DPTK	1-1	<TicketingControl>
B	DPDB	0-1	<DetailedBillingMask>

Response (Output) Tags

<Ticketing>
	Ordering	KLR	Min/Max	XML Tag
	A	DPTK	1-1	<TicketingControl>
	B	DPPI	0-1	<AssocPsgrs>
	C	DPDB	0-1	<DetailedBillingMask>
	D	TEXT	0-1	<TextMsg>

<Ticketing>		Error response from DBI information
	Ordering		KLR	Min/Max	XML Tag
	A		EROR	1-1	<ErrText>
	B		DPDB	0-1	<DetailedBillingMask>

Related Samples

DocProdFareManipulation_7_s5