Task: PNR/BF Retrieve by Carrier Code and Flight

This task retrieves an existing PNR/BF by the carrier code and flight number of an itinerary item in the PNR/BF.

Section 1: Short Answer

Transaction Name:

PNRBFManagement_15

Can any other transactions perform this same task?

Previous versions of PNRBFManagement, AgencyPNRBFDisplay_7_5, CarHotelPNRBFModify_7_0, and CarRulesPNRBF_7_0 and _7_5 all have processes to retrieve an existing PNR/BF by Carrier Code and Flight:

• CarHotelPNRBFModify_7_5 can be used in a sessioned or non-Session environment to retrieve an existing PNR/BF, and make modifications to PNR/BF information as well as Car and Hotel Itinerary.
• CarRulesPNRBF_7_5 can be used in a sessioned or Non-Session environment to car rule information from an existing PNR/BF.
• PNRBFManagement is the preferred transaction for a simple retrieval of the PNR/BF.

Can this task be performed in a sessionless environment?

This task can be performed in a sessioned or sessionless environment. However, in a sessionless environment, the data will not be accessible for any type of follow-on action.

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

The request and response information is identical on both the Apollo and Galileo systems. If an error occurs, the actual error text may differ, but the formats are identical.

Industry-specific knowledge required to understand this task.

The user must have access to the Carrier Code and Flight number in the PNR/BF to make this type of request.

Special limits or distinct restrictions to the input data.

The user must have the authority to look at the requested PNR/BF. If the user is retrieving a PNR/BF they own, no security checks are required. If the PNR/BF being retrieved belongs to someone else, security checks are made to ensure the user has the proper authority. All security checks are done based on information in the existing AAA. 

Section 2: Detailed Description

Request:

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

For a PNR/BF retrieve by Carrier Code and Flight request, a <PNRBFRetrieveMods> data record is required with a <PNRAirIndex> element. <PNRAirIndex> must contain the Carrier Code, Flight Number, Flight Date, and Traveler Last Name (with or without a wild card). <PNRAirIndex> can also contain optional data, such as Board Point and Traveler First Name (with or without a wild card).

If the request is for a PNR/BF outside of the client's CRS, a <TargetCRSInfo> element must also be supplied, with the CRS where the PNR/BF resides. There is also an option to retrieve only certain pieces of the requested PNR/BF. For this option, the client supplies a <RequiredData> element that lists the types of data requested.

Prerequisite tasks:

No prerequisite tasks apply.

Expected response:

The response from a PNR/BF retrieve by Carrier Code and Flight is a <PNRBFRetrieve> data record with an <ErrText> element, if an error occurred, or all of the PNR/BF data requested if an exact match is found. The elements for an exact match are listed in Section 3. If a <RequiredData> element is in the request, and an exact match is found, only the types of data requested in <RequiredData> are returned in the <PNRBFRetrieve> data record. If a Similar Titles List is returned, the data is in a <AgncySimlrName> data record.

<Control> is always the first tag in a non-error response. This element contains the information about the remainder of the response, including the total number of main elements, and the Record ID and number of each type of main element returned. Following are any items with special characteristics.

Following are items with special characteristics. Note that these items apply only when an exact match was found.

Form of Payment

For Form of Payment, one of three elements are returned: <CreditCardFOP>, <CheckFOP>, and <OtherFOP>. Only one Form of Payment can be added to a PNR/BF, so only one of these three elements is present in the response.

Name

The <LNameInfo> and <FNameInfo> elements are for Last Name and First Name, respectively. The number of <LNameInfo> and <FNameInfo> elements is shown in <Control>, but may not reflect the order exactly.

• If there is more than one surname in the PNR/BF, a set of <LNameInfo>/<FNameInfo> elements exist for each Last Name/First Name combination.

• If there is only one surname but multiple first names, only one <LNameInfo> exists, followed by a <FNameInfo> for each first name.

Itinerary

For all types of Itinerary (Air, Car, Hotel, etc.), there are primary elements, which have the basic itinerary information, and secondary elements, which have additional information such as Change of Gauge, Operated By, and Optional Car or Hotel data.

The order for this information is Primary followed by any Secondary(s) that apply to the Primary. For example, an <AirSeg> element followed by an <AirSegOpAirV> followed by an <AirSegDetail> followed by the next <AirSeg> element.

The order of the Primary Itinerary elements is determined by their location in the PNR/BF. The maximum number of Itinerary items in a PNR/BF is 99, so the combination of all types of Primary Itinerary elements cannot exceed 99. The total number of each Primary and Secondary elements is shown in <Control>, but may not reflect the order exactly.

Seats

For seat information, there is a <SeatSeg> element for each segment. Following the <SeatSeg> is be a <SeatAssignment> element for each passenger for that segment. The total number of <SeatSeg> and <SeatAssignment> elements is shown in <Control>, but may not reflect the order exactly.

Special Services (SSRs) and Other Special Services (OSIs)

For Special Service Information (SSRs), there is a <NonProgramaticSSR> (Manual SSR) element or <ProgramaticSSR> element for each SSR. There is an <OSI> element for each OSI. The combination of SSRs and OSIs cannot excede 255 in the PNR/BF.

The <NonProgramaticSSR>/<ProgramaticSSR> elements are in the order they are in the PNR/BF and, therefore, may be mixed. In addition, if there is free text for a Programmatic SSR, <ProgramaticSSRText>, which immediately follows the applicable <ProgramaticSSR>. The total number of <NonProgramaticSSR>, <ProgramaticSSR>, and <ProgramaticSSRText> elements is shown in <Control>, but may not reflect the order exactly.

Ticketing Arrangement

For ticketing arrangement, there is a possible one of five element that can be returned: <TkArrangement>, <TAUTkArrangement>, <TAWTkArrangement>, <TLTkArrangement>, and <TAMkArrangement>. Only one type of Ticketing Arrangement can be added to a PNR/BF, so only one of the five elements is present in a response.

Error and warning responses:

The most common error returned is an error that no match (exact or similar) can be found.

Follow-on requests:

For a sessioned environment, numerous follow-on requests can be made. Additional data can be added to the PNR/BF, or current information in the PNR/BF can be changed or deleted. In a sessionless environment no, follow-on entries are available, because the data is no longer available after the transaction completes.

There are several other tasks that can be done in conjunction with the retrieval of the PNR/BF, or that can be done as a follow-on request in a sessioned environment. These tasks are:

1. Fare Redisplay

2. Retrieve TravelScreen Status

3. Retrieve AAA information

These tasks can be combined, and the user can choose which task, if any, to include either with the PNR/BF retrieve request or as a follow-on request.

Section 3: Tables

1) Retrieve by Carrier Code and Flight (Same CRS)

Request (Input) Tags

Response (Output) Tags

2) Retrieve by Carrier Code and Flight (Different CRS)

Request (Input) Tags

Response (Output) Tags

Related Samples

PNRBFManagement_15_s39