The following fix pertains to the <OptSuf> tag located in the
<AirSegSellMods> request. On the Galileo
Cause:
The XML translator populates blank fields with zeros. This error occurs
only on Galileo because Apollo
Solution:
A CDATA section should be used to populate the <OptSuf> field. Note
that a single character space is included between the brackets:
<OptSuf><![CDATA[ ]]></OptSuf>
This use of the CDATA section causes the XML translator to disregard the standard process of populating blank fields with zeroes. Instead, the character space will be interpreted correctly by Galileo as a blank.
Selling (booking) air segments has some differences from selling car and hotel segments. Segments are sold according to the class of service. Generally, it is recommended to store the associated fare quote when the segment is sold, unless the segment is ticketed immediately. (Stored fares are required on Galileo and optional on Apollo). Because fare quotes can change at any time prior to ticketing, storing the fare provides a history of the fare that was quoted to the traveler that can be compared against a later, quoted or ticketed fare.
Air segments may be sold with or without an availability call being made first. However, an initial check of a flight's availability can help prevent frustration and confusion. In selling a flight, the user has basically three (3) types of request codes available:
NN ('need need') - Considered a "regular sell." The passenger has selected a specific flight on a specific day and is indicating a confirmed seat is desired. When booking a flight in a regular sell, the passenger must know the airline, flight number, class of service, date of departure, number of travelers in the party, and origin and destination.
LL ('list list') - This code is used to 'waitlist' a passenger on a flight that is already showing fully booked. It is a request to be put on a list, in the event another traveler cancels his/her flight reservation. Normally, a passenger will follow a waitlist request with a regular sell on an alternate flight as backup. When waitlisting a flight, the passenger must know the airline, flight number, class of service, date of departure, number of travelers in the party, and origin and destination.
NO ('need open') - This code is used when the passenger knows only the airline, and origin and destination required, but may not sure of either the departure date, departure time or both. Because the actual flight might be selected just hours prior to departure, open segments are often booked in the class of service that represents the lowest unrestricted fare available. When this type of air segment is ticketed, the word 'Open' appears where the flight number is normally shown.
Car Vendor
Car Type - Such as economy, midsize, sedan, or wagon.
City/Airport Code - City or airport code where the car will be picked up.
Pick-up Date - Date the car will be picked up.
Traveler's Name
Arrival Time - The arrival time is required, unless the car booking follows an air segment. If the car follows an air segment, the arrival time defaults to coincide with the flight arrival time.
Drop-off Time - The drop-time time is required, unless the car booking precedes an air segment. If the car precedes an air segment, the drop-off time defaults to coincide with the flight departure time.
Drop-off Date - If no drop-off date is indicated, the default is a one-day rental.
Drop-off Location - If no drop-off location is indicated, the drop-off location defaults to the pick-up location. If the drop-off location is different, the drop-off location must be provided. The vendor may charge a fee for returning the car to a location other than where the rental began. Drop charge information can be found in the rules display for the selected car.
Optional information can be added to the car booking request.
Corporate Discount Number - A corporate discount number between the traveler's organization and the selected vendor.
Frequent Traveler Information
Guarantee Information
Awards Program Membership Number - A membership number for an awards program the traveler might have with the selected vendor.
Special Requests - Any special requests for service or equipment, such as a car equipped with a ski rack or a cellular phone.
A car booking can be sold as either a reference sell from an availability display, or as a direct sell.
After a car is booked, the vendor acknowledges the transaction by sending back a confirmation number. This number signifies the agreement between the passenger and vendor for the car rental.
This function normally follows an availability request such as CarTypeAvail_7_0 or CarStandardAvail_6_0.
After the traveler selects a hotel property, the hotel room is then sold (booked).
|
Property Number |
Provided by the RoomMaster™ system. |
|
Chain Code |
Provided by RoomMaster. |
|
Booking Code |
Provided by RoomMaster |
|
Check-In Date |
If no check out date is indicated, the reservation defaults to a one-night stay. |
|
Occupancy |
Hotel rooms are booked for one (1) or two (2) persons. To book additional occupants in a hotel room, and optional qualifier is added to the segment sell. |
|
Number of Rooms |
The number of rooms required for the sell. |
Optional information can be added to the hotel booking request.
|
Corporate Discount Number |
Negotiated rate between an organization and the select vendor. |
|
Awards Program Membership Number |
Awards program membership number for the selected vendor. |
|
Special Requests |
Such as a room with wheelchair access or a non-smoking room. |
|
Guarantee |
Used to specify a credit card to guarantee the room or provide a deposit. |
|
Extra Persons |
In addition to the maximum of two persons specific in the required data. |
|
Extra Beds |
|
|
Traveler's Name |
The traveler's name in which the room should be held. The default name is the first name in the PNR/BF. |
When a hotel booking is made from the complete availability display, the vendor acknowledges the transaction by sending back a confirmation number. This number signifies the agreement between the passenger and vendor for the hotel booking.
RoomMaster requires that a HotelCompleteAvailability_7_0 be displayed before a sell can be made. To save the hotel booking to the PNR or BF, an end transact must be implemented, using PNRBFEnd_9_0.
Form of payment may be required to sell car, hotel, or cruise segments, or to guarantee hotel segments. In rare cases, smaller airline vendors may also require a form of payment to be associated with the sale of an air segment.
For readability and continuity, it is recommended that an itinerary be stored in chronological order. However, itineraries are not always booked in chronological order. Examples of changes to an itinerary that require inserting an air segment include:
Often a user reserves the air segment first, then reserves car or hotel segments later.
An itinerary that started out as a simple "Point A to Point B" becomes more intricate with additional destinations added between Points A and B.
An itinerary is affected due to flight cancellations or schedule changes that require alternate air reservations in place of the original reservations.
The InsertAfter function allows the user to place new air segments within an existing itinerary. If the objective is to maintain date and sequence continuity within the itinerary, the new segments must be inserted after the appropriate previous segment, whether that segment is an air, car, or hotel segment.
For readability and continuity, it is recommended that an itinerary be stored in chronological order. However, itineraries are not always booked in chronological order. For example, a user often reserves the air segment first, then reserves car or hotel segments later. To maintain continuity within the itinerary, these segments must be inserted after the appropriate air segment. "Insert After" functionality is also used when a segment has been canceled and replaced with an alternative booking.
In some itineraries, a traveler flies into one city, but departs out of another city on the next air segment. How the traveler gets from the first city to the second city is not indicated on the itinerary itself. That gap between the destination point and the subsequent origin disrupts the continuity of the itinerary and is referred to as an Arrival Unknown (ARNK) segment.
To accommodate such a break, an ARNK segment must be inserted between the two points. An ARNK segment works like a placeholder in the itinerary. In the terminal example below, the traveler flies from Denver to Austin, but returns to Denver from San Antonio. Segment two (2) in the example shows an ARNK segment.
Note: ARNK segments should not be confused with 'Open' segments. In an Open segment, the passenger does intend to fly from the first to the second point; however, either the flight number and/or date is not yet determined.
It is possible to have multiple stored fares in a single PNR/BF. Multiple stored fares can occur when:
A number of ticketing modifiers are available when storing one or more fares. The same modifiers that were used to store the original fares are used by the host to calculate the new applicable fares. These modifiers include:
Itineraries will often change between original booking and actual travel, including travel dates, or preferred hotel options.
The CRS provides functionality to modify hotel booking dates without canceling and rebooking the entire hotel segment. After modification, the dates adjust forwards or backwards, as necessary.
However, it is important to note that some vendor host systems do not recognize modification functions. In these instances, the vendor host system will automatically cancel and rebook the segment. If there is no open availability, the rebook process may complete.
Itineraries will often change between original booking and actual travel. Hotel segments can have existing data modified or new optional data added. Although all this data is optional, it does provide supplementary details to the hotel booking that can help both the traveler and the vendor. Optional data includes: special requests, membership program numbers, and rate information.
This function allows the type of hotel room to be modified without canceling and rebooking the entire hotel segment. For example, when the hotel reservation was first made, only a standard room with a double bed was available, but now the passenger can book a deluxe room with a king bed.
An itinerary will often change between original booking and actual travel. In addition to modifying the reserved rental dates, the type of car or optional preferences can be modified.
Car segments can be modified because of changes in the travel dates, which adjust forward or backwards, as necessary. The CRS provides such date modification functionality to passengers who need to change their car booking dates. If required, the arrival and drop-off times can also be adjusted. This functionality allows them to make those changes without canceling and rebooking the entire car segment.
However, it is important to note that some vendor host systems do not recognize modification functions. In these instances, the vendor host system will automatically cancel and rebook the segment. If there is no open availability, the rebook process may not complete.
For car segments, changes can include modifying existing data or adding new data, such as, special requests, membership program numbers and rate information. Although this data is purely optional, it does provide supplementary details to the car booking that can help both the traveler and the rental agency.
Car segments can be modified to change the car type for travelers who need to change from one car size to another. This functionality allows travelers to change their car selection without canceling and rebooking the entire car segment.
Special Service Requests (SSR) and Other Service Information (OSIs) are messages sent directly to an airline vendor. An SSR is a request that can be made directly to one or more of the vendors represented in the itinerary. OSIs are messages that contain information only. SSRs differ from OSIs in that the airline is required to take action based on the instructions in the SSR message.
SSRs communicate a particular need on behalf of the passenger, and include messages such as a special meal for a confirmed flight, or wheelchair assistance at the destination airport. An SSR message is used when a response from the vendor(s) is required. The SSR is added to the PNR or BF.
Two (2) types of SSRs exist:
Programmatic
Manual
Programmatic SSRs use standardized codes to represent the type of special request made to the vendor. Many of these codes allow free-from text. Manual SSRs require longer inputs than programmatic SSRs and are primarily used for special requests not accounted for programmatically. For example, a manual SSR could be used to enter a mileage membership number for an airline that accepts mileage membership numbers from another carrier.
OSIs are also messages sent to the vendor. However, unlike SSRs, OSIs do not require action on the part of the vendor. OSIs are for information only, and can include messages such as customers who are traveling with small children or elderly passengers who may need assistance. OSIs are free-form text.
The ticketing arrangement indicates how and when ticketing will be executed. The ticketing arrangement specifies the date that the PNR/BF will be assigned to a queue as a reminder to issue a ticket on that date. This field is mandatory when building a PNR/BF, regardless of the form of ticketing.
The ticketing arrangement is also required for car and hotel bookings, although it is rarely used for these types of reservations. This function is a throwback to pre-electronic days when a car or hotel reservation might require an actual paper ticket. In rare instances, a vendor may still require ticketing for a car or hotel reservation. For cars and hotels, the ticketing field can be left blank.
The expiration date of the ticket can be used as the ticketing arrangement date and is contained in the fare quote response. The current date can also be used for the ticketing arrangement date, if you want to create a PNR/BF without first obtaining a fare quote.
The ticketing field may also play an important role in the actual price that the passenger pays for the ticket. In the Apollo® CRS, fares are not finalized until ticketing is complete; therefore, a gap in time between faring and ticketing can potentially result in significant differences between the quoted fare and the actual ticketed fare.
Note: Issuing tickets is a function of the travel provider, and is not accomplished by XML Select Transactions.
If a room reservation is no longer needed, the hotel segment should be canceled using PNRBFReservationModify_5_0_2 or SegmentCancel_7_0. The cancellation request notifies the vendor that the room can be released back into inventory. Typically, the vendor will acknowledge the transaction by sending back a cancellation number.
Canceling a hotel segment is particularly important if a credit card number was used to guarantee the room. Most hotels have strict cancellation policies, and require the room be released by a specific time, one to two days prior to the check-in date. Late cancellation can result in a "no-show" charge to the credit card used to guarantee the room.
Before the air segment is canceled, the PNR/BF containing the booking must first be retrieved using PNRBFReservationModify_5_0_2. This cancellation must be followed by an End Transact, such as in the PNRBFEnd_9_0, in order for any changes to take affect.
If a car rental is no longer needed, for whatever reason, the car segment should be cancelled using PNRBFReservationModify_5_0_2 or SegmentCancel_7_0. Before the air segment is canceled, the PNR/BF containing the booking must first be retrieved using PNRBFReservationModify_5_0_2. Only then can the cancellation request be made. The cancellation request informs the vendor that the car can be released back into inventory. The vendor may acknowledge the transaction by sending back a cancellation number.
This function must be followed by an End Transact, such as in the PNRBFEnd_9_0, for changes to take affect.
Changes to a travel itinerary are not uncommon, and in some instances (such as business travel), changes to the itinerary are common. Flights, dates, even destinations can undergo several changes between booking and ticketing.
Itinerary segments are numbered sequentially, and these same numbers are used to cancel one or more segments. When multiple itinerary segments are canceled separately, they should be referenced in ascending order. For example, the lowest numbered segment should be indicated first, followed by the second to the lowest segment, and so forth.
Before the air segment is canceled, the PNR/BF containing the booking must first be retrieved using PNRBFReservationModify_5_0_2 or SegmentCancel_7_0. To implement the cancellation, the function must be followed by an End Transact, such as PNRBFEnd_9_0.
Canceling an entire PNR/BF record implies canceling segments in the itinerary and canceling the stored fare (if air segments were included in the PNR/BF). Prior to canceling the record, retrieving the fare basis code using FareQuoteRulesDisplay_8_0 can indicate any penalty associated with canceling a ticketed fare.
Explicit cancellation of the stored fare is unnecessary. When the final air segment is canceled the CRS detects that the stored fare has been orphaned and deletes it automatically during the end transact transaction.
Step |
Process |
Description |
|
1 |
Rules Display |
OPTIONAL: Use fare basis code to display penalty for cancellation. |
|
2 |
Segment Cancel (FF) |
Cancels all segments for air, car, hotel, SSRs, and seats. |
The "FF" segment number submitted in the SegmentCancel_7_0 is a command to cancel all segments in the itinerary.
The process described above will cancel the reservation; however, it does not necessarily delete the PNR/BF record on the CRS. The name, phone, and other fields will still remain after the end transact command has been executed.
The CRS however keeps historical information pertaining to the segment dates even after they are canceled. More specifically, the CRS has a "garbage collection" routine that scans the system and deletes PNR/BF records 24 hours to 48 hours after the latest segment date that has been canceled or expired. Therefore, PNR/BF records can be retrieved via the Record Locator ID for a period of time after the reservation has been canceled or before it has expired.
Note on Re-Sequenced Segments:
In certain configurations, the commit command re-sequences the segments stored on the CRS. Therefore, if two (2) air segments, one (1) car segment, and one (1) hotel segment are sold in sequential order and then end transacted, the car segment may randomly change from position #3 to position #4. As a result, the PNR/BF may need to be retrieved after it is and processed to determine the segment type and position.
Contact your customer representative to determine if re-sequencing is applicable in your instance.
Before the air segment is canceled, the PNR/BF containing the booking must first be retrieved using PNRBFReservationModify_5_0_2 or AgencyPNRBFDisplay_7_5. To implement the cancellation, the function must be followed by an End Transact, such as PNRBFEnd_9_0.
SegmentCancel_7_0 and PNRBFReservationModify_5_0_2 both support canceling an air segment. SegmentCancel_7_0 is generally used for sessioned environments, while PNRBFReservationModify_5_0_2 is typically used in sessionless environments.
Note: Changes to an existing PNR/BF are not necessarily itinerary changes, but can be any sort of modification or addition to the record itself.