Task: PNR/BF Retrieve by Traveler Name

This task allows the user to retrieve an existing PNR/BF by a Traveler Name in the PNR/BF.

Section 1: Short Answer

Transaction Name:

PNRBFManagement_8

Can any other transaction perform this same task?

PNRBFManagement_7_12, AgencyPNRBFDisplay_7_5, CarHotelPNRBFModify_7_5, and CarRulesPNRBF_7_5 all have processes to retrieve an existing PNR/BF by Traveler Name.

• CarHotelPNRBFModify_7_5 can be used in a sessioned or sessionless 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 sessionless environment to retrieve car rule information from an existing PNR/BF.
• PNRBFManagement_8 is the preferred transaction for a simple retrieval of the existing 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 is not 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 request and response formats are identical.

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

The addition of Branch or Affiliate (for Selective Access) information can be used to further clarify the PNR/BF to retrieve. In this scenario, the user must be familiar with Branch and Affiliate processing.

• Branch processing is used to locate a PNR/BF by Traveler Name from any associated Pseudo City Codes (PCCs).
• Affiliate processing is used to locate a PNR/BF by Traveler Name from any Pseudo City Code in a specified Selective Access Affiliate.

If the user is unclear of these processes, a standard retrieve by Traveler Name should be done.

Explain any special limits or distinct restrictions.

The user must have the authority to retrieve 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 based on information in the existing AAA.

Section 2: Detailed Description

Request:

For a PNR/BF retrieve by Traveler Name request, a <PNRBFRetrieveMods> is required with a <CustNameInfo> element. <CustNameInfo> must contain the Traveler Name in the format LastName or LastName/FirstName. The name can also be a wild card, such as SM* or SMITH/JE*.

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. If the Branch or Affiliate option is being used, this information also needs to be supplied in <TargetCRSInfo>.

There is also an option to retrieve only certain pieces of the requested PNR/BF. For this option, a <RequiredData> element is required to list the types of data requested.

Prerequisite tasks:

No prerequisite tasks apply.

Expected response:

The response from a PNR/BF retrieve by Traveler Name 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 the <RequiredData> are returned in <PNRBFRetrieve>. If a Similar Titles List is returned, the data is in <AgncySimlrName>.

<Control> is always the first element in a non-error response, including a Similar Titles response. This element contains the information regarding the remainder of the response including the total number of primary elements, and the Record ID and number of each type of primary element returned. Following are any items with special characteristics; these items only apply if an an exact match is found.

Form of Payment

For Form of Payment, one of three elements is 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, as the data is no longer available after the transaction completes.

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

• Fare Redisplay

•  Retrieve TravelScreen Status

• 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

Retrieve by Traveler Name (Same CRS)

Request (Input) Tags

Response (Output) Tags

2) Retrieve by Traveler Name (Different CRS)

Request (Input) Tags

Response (Output) Tags

Related Samples

PNRBFManagement_8_s38