This API is used for changing the flight(s) by changing outward date, return date, origin, destination.
This document assumes the user is familiar with the Travelfusion Search and Book API.
Applicable to options: OUT_DATE|RET_DATE|ORIGIN|DESTINATION.
The eligible bookings for change must have one of the following statuses: Succeeded, BookingChangeSucceeded, CancelFailed.
Making Changes to Bookings
With airline suppliers, it is possible to modify existing bookings that have been made via the Travelfusion XML API. This functionality is not currently available for all suppliers, however, for suppliers that do support it, the command syntax of the requests and responses is almost identical to those of the existing booking process. The XML commands and responses that differ from the existing booking process are:
To start a booking change request the following XML block needs to be included in a standard StartRouting request:
StartRouting - BookingChange component
All of the parameters in this XML block are mandatory and have the following values:
TFBookingReference - Reference of the booking that is being modified.
ChangeOutwardDate - Flags whether the date of the outward leg is being modified (true/false).
ChangeReturnDate - Flags whether the date of the return leg is being modified (true/false).
ChangeOrigin - Flags whether the origin is being modified (true/false).
ChangeDestination - Flags whether the destination is being modified (true/false).
Any suppliers defined within a SupplierList will be ignored during a booking change request since it is assumed that the supplier must be the same as that used in the original booking.
Although the TravellerList is a mandatory parameter within the StartRouting command, the exact traveler details will be retrieved from the original booking. Therefore the traveler details listed in the current booking change request do not need to match the original booking.
When performing a booking change, the OutwardDates, ReturnDates, Origin and Destination within the StartRouting request corresponds to the new desired dates for the journey.
[Note: If a return leg of a journey is being modified the OutwardDates block must be defined in the request even if the date is not being modified. However, the values specified within this block will be ignored since the actual value will be extracted from the original booking.]
Below is an example of a StartRouting request that includes a Booking Change block. This request will update both the outward and return dates of the booking with TF reference Z1VRPKORR to 21/10/2009 and 29/10/2009 respectively.
StartRouting example with Booking Change
ProcessTerms Request & Response
The only differences to the ProcessTerms request submitted during a booking change are seen in the TravellerList details. Although this parameter remains a mandatory element within the request, the actual values used when processing the booking change are retrieved from the original booking. Therefore the values submitted during the change booking request do not need to match those of the original booking.
The response is almost identical to that seen during a standard booking, however, the group level amount returned in the response corresponds to the cost of the current booking change. The TaxItemList will include key components that contribute to this cost of the booking change, these include:
Amount Already Paid - The current total cost of the booking (excluding the current request).
Net Total Price - The new price of the booking excluding fees
Non-Refundable Amount - In the event of the new booking being cheaper that the original it may not be possible to refund the difference it the bookings.
Change Booking Fee - The cost of performing the booking change.
Credit Card Fee - The fee for using a particular type of credit card.
Fees - The sum of any additional fees.
Below is an example of a Price block that might be returned by a ProcessTerms request (Note: Some values may be displayed as negative values):
ProcessTerms response - Price example
Booking Change Statuses
When performing a booking change request, the status of the new booking and the original booking will vary.
After the submission of the StartBooking request the new booking and the original booking will be assigned any of the following combinations:
See the Booking Handling Guide for more details of how to handle certain booking statuses. The BookingChangeSucceeded and BookingChangeFailed statuses need to be handled like Succeeded or Failed accordingly.
As with regular bookings, booking changes can be reviewed via the reports system. The system can display both the original booking and the changed booking that has replaced it. The screenshot below shows a booking that has been modified. The entry with the status BookingChanged corresponds to the original booking, whilst the entry with the status BookingChangeSucceeded corresponds to the new changed booking.
Clicking on the 'TF Reference' link will display the details page for the corresponding booking. The details page is almost identical to that seen for a regular booking, however, the 'Total price' field will now correspond to the price of the booking change. Additionally there is also a 'Booking Change Details' section that displays supplementary information about how the booking has been modified.
For an original booking that has subsequently been modified the following information is provided:
The TF reference of the new (child) booking (as a hyperlink to the new booking details).
The date of the booking was changed.
A verbose description of the details changed in the booking (E.g. 'Change Destination').
The branch id of the user who updated the booking.
For a new booking that has resulted from a booking change the following information is provided:
The TF reference of the original (parent) booking (as a hyperlink to the original booking details).
Note: If a booking has been changed multiple times the 'Booking Change Details' for a changed booking may contain both a parent and child TF booking reference.
The screenshots below illustrate both the original booking and new booking as they would appear after a successful booking change request has been processed: