Building a PNR (Passenger Name Record) or BF (Booking File) is essential for booking reservations through a CRS. PNRs and BFs serve as booking records. Booking records are called PNRs on Apollo and BFs on Galileo.
PNR/BFs can contain both mandatory and optional fields relevant to the type travel booked. PNR/BFs are related to all CRS-initiated travel reservations associated with a specific trip; therefore, these PNR/BFs can be created or modified to air, car, and/or hotel records. For example, a customer may need to book a round-trip airline ticket and a rental car in the destination city. The resulting itinerary contains both air and car segments as part of the reservation record on the CRS. Or, a customer may need to book only a hotel in a given city with no air or car segments. Both situations and many more are possible variations of an itinerary.
Users have five (5) mandatory elements that must be entered in order to create a PNR or BF.
Traveler's Name - The name of the passenger(s) for whom the travel arrangements were made. More than one passenger can be on the PNR/BF. However, all passengers represented in the same record must have the same itinerary. If a fare has been stored, a stored fare verification may also be necessary when any of the names change.
Traveler's Phone - A contact telephone number, either for the traveler or travel provider. Although multiple telephone numbers may exist, at least one number is mandatory. At least one phone number is mandatory to allow the vendor to contact the travel provider or traveler. While multiple phone numbers are permitted, some vendor host systems do not recognize more than two phone numbers.
Itinerary - The PNR/BF must contain at least one sold air, car, or hotel itinerary segment. If multiple itinerary segments are present, it is absolutely mandatory that continuity of date, time, and location is maintained. If the itinerary contains only car and hotel segments, then the Stored Fare field is not used, even if the Agency Access Table (AAT) defines the field as mandatory.
Ticketing Arrangement - Indicates how and when ticketing will be executed. The ticketing field plays a very important role in the actual price that the passenger pays for the ticket. See Storing Fares for more information. The ticketing arrangement field may serve as a reminder for ticketing the itinerary at a specified date and time, or it may serve as a status field to indicate that the itinerary has already been ticketed. The ticketing arrangement field is also required for car or hotel reservations, although they are rarely ticketed. In these cases, the field is left blank.
Received By - Indicates the last person to change the PNR/BF. However, when the PNR/BF is first created, the passenger name is often used. Typically, the individual will be either the traveler or the traveler’s representative. The process described above has one caveat when working in non-terminal environments. Specifically, the Received By field is completed via the End Transact (ET) command.
In addition to the mandatory data, there are additional data fields that can be added to a PNR or BF. Types of optional data include:
SSR
& OSI - Used only for air segments, SSRs (Special Service Request)
and OSIs (Other Service Information) are messages sent directly to the
vendor to communicate traveler preferences or requirements. SSRs, such
as meal preference or wheelchair assistance require the carrier to take
action, while OSIs are for information only. SSRs are freeform text up
to 55 characters in length and can be related to individual names and
segments in the PNR/BF. In addition, the SSR can send an alert message
back to the agent.
OSIs are typically used to notify a carrier of special circumstances
such as the passenger only speaks French. OSIs are used to send
an information only message to a specific carrier and may contain freeform
text up to 69 characters in length.
Stored
Fare Quotes - Stored fares keep a record of the fare and any related
modifiers at the time that it was stored. The stored fare is known as
an Automated Fare Quote (ATFQ) field on the Apollo CRS and a Filed File
(FF) on the Galileo CRS. The Galileo CRS requires storing a fare
to guarantee the fare. While fares are not guaranteed on Apollo until
they are ticketed, many travel providers require storing fares as part
of their business practice.
This field may be mandatory or optional depending on how the AAT was
defined. If the AAT table has been set to make this field mandatory,
then the fare must be stored in the PNR/BF before issuing an End Transact
command. Furthermore, the ATFQ/FF field must be verified if the Name field
in the PNR/BF changes.
General Remarks - General remarks are free-form text fields that can be used to record anything noteworthy that occurred during the creation or life of the PNR/BF. Agents many times use general remarks to indicate services that were offered but refused by the passenger. Unlike the SSR, remarks are not forwarded to a carrier.
Secondary
Ticketing Remarks - These remarks fields contain formatted information
that is designed to be printed on an itinerary or invoice. In the agency
environment, these remarks can also be passed off to another application,
such as a back-office accounting system. Examples of secondary ticketing
remarks include client account codes, credit card approval information,
or fare savings data.
Some, such as ticketing or stored fares, are specific to booking air
segments only. Others fields, such as form of payment, are generally used
for car or hotel bookings, but may also be used for air bookings.
Creating and storing a reservation on the CRS is known as PNR/BF Build. To create and store a reservation on the CRS, there are seven essential steps one must follow. These seven steps embody many possible variations to enable the user to book or reserve various types of itineraries in a flexible manner.
Step |
Process |
Description |
|
1 |
Connection |
Establishing communication to the Apollo or Galileo CRS. |
|
2 |
Sign On |
OPTIONAL: Only required in sessioned environments. |
|
3 |
PNR/BF Build |
Creates the PNR/BF on the Apollo or Galileo CRS. |
|
4 |
Store Fare |
OPTIONAL: Only required for actual ticketing of air
segments.
|
|
5 |
End Transact or Ignore |
Commits or discards the PNR/BF on the Apollo or Galileo CRS. |
|
6 |
Sign Off |
OPTIONAL: Only required in sessioned environments. |
|
7 |
Disconnection |
Closing the line of communication from the Apollo or Galileo CRS. |
If the PNR/BF record is successfully filed, a Record Locator Number is returned. The Record Locator Number is a unique file address assigned by the Apollo or Galileo host that can be used to retrieve the PNR/BF later for review or modification. The PNR/BF is kept within the host system until approximately 24 hours after the end date of the last itinerary segment.
For the purpose of illustration, the PNR/BF record that is created and stored on the CRS can be thought of as having the following structure.