Task: PNR/BF Maintenance for Secondary Fields

This task allows the user to create or maintain the secondary fields of a PNR/BF. Secondary fields are everything in the PNR/BF that is not considered primary, such as Remarks, SSRs, Email, Form of Payment, and Corporate ID. Details on the exact types of data included in the secondary fields can be found in the request and response field-level documentation.

This task should be used in conjunction with the task PNR/BF Maintenance for primary fields.

For additional information on PNR/BF Maintenance for Primary and Secondary Fields, see the Primary and Secondary Field Notes topic.

Section 1: Short Answer

Transaction Name:

PNRBFManagement_39

Can any other transaction perform this same task?

Previous versions of PNRBFManagement, PNRBFBuildModify_#, AgencyPNRBFBuildModify_#, PNRBFReservationModify_#, and CarHotelPNRBFModify_# all support the creation and maintenance of PNR/BF secondary data.
AgencyPNRBFBuildModify_# only works in a sessioned environment.
PNRBFReservationModify_# can create a PNR in a sessioned or sessionless environment but cannot maintain PNR/BF data. (The PNRBFReservationModify transaction does not include a PNR/BF retrieve process.)
CarHotelPNRBFModify_# can be used to create or maintain a PNR/BF in a sessioned or sessionless environment but does not have any air sell process functionality.
CruiseSellSegment_#, CruiseVerifyandOptions_#, CruiseMakePayment_#, and CruisePricing_# also support the creation and maintenance of PNR/BF primary data. However, these transactions are used strictly in the area of cruise bookings and should only be used in those scenarios.

Can this task be performed in a sessionless environment?

This task can be performed in both a sessioned and a sessionless environment.

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

The Apollo system does not support the <DOCInvoiceQual>, <DuePaidTxtQual>, and <VndRmkQual> child elements in <PNRBFSecondaryBldChgMods> (2110).

The Galileo system does not support the <PostscriptNoteQual>.

The rest of the request and response for this task are identical on both the Apollo and Galileo systems. If an error occurs, the error text can be slightly different, but the actual child elements returned are identical.

List any industry-specific knowledge required to understand this task.

This task uses an NWB structure versus a KLR structure. An NWB is a string of data set up as specified in the NWB documentation. Multiple PNR/BF data can be input together. Data can be added, deleted, and changed within the same element. The last child element in the <PNRBFSecondaryBldChgMods> must be <EndMark>.

Explain any special limits or distinct restrictions.

Billing records are available on both Apollo and Galileo. The Indicators for these four records are <BillingQualB1>, <BillingQualB2>, <BillingQualB3>, <BillingQualB4>. If a billing record displays, it should always begin with a <BillingQualB1> record followed by a <BillingQualB2>, with the <BillingQualB2> being followed by a <BillingQualB3> record. The <BillingQualB4> record is optional.

Section 2: Detailed Description

Request:

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

For a secondary field maintenance request, a <PNRBFSecondaryBldChgMods> is required with the appropriate data. All data to be maintained (added, changed, or deleted) is sent in one <PNRBFSecondaryBldChgMods> request with an <EndMark> as the last element in the request.

Billing records with the indicators <BillingQualB#> are closely tied to each other. If a billing record displays, it should always begin with a <BillingQualB1> element, followed by a <...B2>, then a <...B3> record. The <...B4> element is optional but would follow the <...B3> if it does display. These records are unique to the billing process and are not used for any other purpose. They will not appear in PNR or BF displays. They are not edited for content. They cannot be modified or deleted. Adding them is the only option.

Each individual piece of data has a <Qual> indicator, a size, and an edit type. Each individual <Qual> type has a specified layout. The layout of the <Qual> is often different based on the edit type. Details of the various layouts are in the request and response field-level documentation.

Prerequisite tasks:

For PNR/BF data to be changed or deleted, or for data to be added to an existing PNR/BF, the PNR/BF must first be retrieved.

You can only change a vendor remark prior to End-Transacting a PNR/BF with the vendor remark. Once added, the vendor remark cannot be changed, only deleted.

For a description on how to retrieve a PNR/BF, see Task Retrieve Currently Active PNR/BF in the PNRBFManagement transaction.

Expected response:

The response from a secondary field maintenance request is a <PNRBFSecondaryBldChg> (2111). This element is returned with no data if no errors occurred.

Error and warning responses:

If an error occurs, the error text is returned in the <PNRBFSecondaryBldChg>. Multiple errors are returned together. The format of the error is the same as the standard <Err> element, but is in NWB format.

The most common error returned is an editing error for data in the request. These errors vary in text and describe the error.

Follow-on requests:

There are no follow-on requests for this task.

Section 3: Tables

Request (Input) Tags

<PNRBFSecondaryBldChgMods>		Terminal Equivalents:			Apollo: Varied		Galileo: Varied
	Ordering		NWB	Min/Max		XML Tag
			2110	0 – 8		<PNRBFSecondaryBldChgMods>

Notes:

For details on the <PNRBFSecondaryBldChgMods> layout, see the request and response field-level documentation.
Up to eight <PNRBFSecondaryBldChgMods> can be submitted in one request.