Travelfusion Direct Connect XML API > Post Booking APIs
Booking Changes API
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.
The ManageBookingAvailabilityPlane command should be executed before the user performs a Booking Change API modification. The element <ChangeOptions> in the response will indicate which change options are supported by Travelfusion, and hence, which post booking API to use.
This API is applicable to change 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:
StartRouting Request
ProcessTerms Request
ProcessTerms Response
StartRouting Request
To start a booking change request the following XML block needs to be included in a standard StartRouting request:
StartRouting - BookingChange component
<BookingChange>
<TFBookingReference></TFBookingReference>
<ChangeAttributeList>
<ChangeOutwardDate></ChangeOutwardDate>
<ChangeReturnDate></ChangeReturnDate>
<ChangeOrigin></ChangeOrigin>
<ChangeDestination></ChangeDestination>
</ChangeAttributeList>
</BookingChange>
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.
The TravellerList is described in the standard StartRouting command. For the Booking Changes API, it is not mandatory for the TravellerList content to correspond to the traveller(s) of the airline supplier booking to be changed.
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
<StartRouting>
<XmlLoginId>****</XmlLoginId>
<LoginId>****</LoginId>
<Mode>Plane</Mode>
<Origin>
<Descriptor>STN</Descriptor>
<Type>airportcode</Type>
<Radius>1000</Radius>
</Origin>
<Destination>
<Descriptor>ALC</Descriptor>
<Type>airportcode</Type>
<Radius>1000</Radius>
</Destination>
<OutwardDates>
<DateOfSearch>21/10/2009-00:00</DateOfSearch>
</OutwardDates>
<ReturnDates>
<DateOfSearch>29/10/2009-23:59</DateOfSearch>
</ReturnDates>
<MaxChanges>8</MaxChanges>
<MaxHops>8</MaxHops>
<BookingChange>
<TFBookingReference>Z1VRPKORR</TFBookingReference>
<ChangeAttributeList>
<ChangeOutwardDate>true</ChangeOutwardDate>
<ChangeReturnDate>true</ChangeReturnDate>
<ChangeOrigin>false</ChangeOrigin>
<ChangeDestination>false</ChangeDestination>
</ChangeAttributeList>
</BookingChange>
<Timeout>60</Timeout>
<TravellerList>
<Traveller>
<Age>45</Age>
</Traveller>
</TravellerList>
</StartRouting>
ProcessTerms Request & Response
The differences to the standard ProcessTerms request of Search and Book API are in the TravellerList element. The TravellerList is required to contain all the travellers, having the same names and ages and in the exact same order, as found in the current airline supplier booking. Any new / additional travellers’ CustomSupplierParameter should be included if needed or required (as per the normal search & book flow).
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 the following key components (which are intended for the booking change flow) that contribute to this cost:
Amount Already Paid - The total amount that has been paid for this booking so far, excluding the current booking change request. Please note that there is always a minus sign ahead of the amount, meaning that is deducted in the calculations.
Net Total Price - The new price of the booking (excluding fees) after this change. This would be the total price of the new selected fares for the legs that have been requested to change and any unchanged fares for the legs that have not; any extra fees like booking change fees or ancillary charges are excluded.
Non-Refundable Amount -Any amount that is not refunded by the supplier. For example, it could include the difference from a new selected cheaper fare and/or any other non-refundable fees like ancillary charges coming from the previous booking.
Change Booking Fee - The standard extra cost of performing the booking change imposed by the supplier.
Credit Card Fee - The fee for using a particular type of credit card.
Please note that occasionally, and depending on the airline supplier, any of the above could be absent, in which case the respective tax item amount is considered zero. Moreover, you might encounter additional tax items as per normal search & book flow, e.g. Credit Card Fee, Luggage Fees, etc. For every tax item, the type of contribution (whether to be added or deducted) to the group level total cost is defined by the sign ahead of each amount.
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
<Price>
<Amount>71.75</Amount>
<Currency>GBP</Currency>
<TaxItemList>
<TaxItem>
<Name>Amount Already Paid</Name>
<Amount>-219.36</Amount>
<Currency>GBP</Currency>
</TaxItem>
<TaxItem>
<Name>Net Total Price</Name>
<Amount>197.36</Amount>
<Currency>GBP</Currency>
</TaxItem>
<TaxItem>
<Name>Non-Refundable Amount</Name>
<Amount>22.00</Amount>
<Currency>GBP</Currency>
</TaxItem>
<TaxItem>
<Name>Change Booking Fee</Name>
<Amount>70.00</Amount>
<Currency>GBP</Currency>
</TaxItem>
<TaxItem>
<Name>Credit Card Fee</Name>
<Amount>1.75</Amount>
<Currency>GBP</Currency>
</TaxItem>
</TaxItemList>
</Price>
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.
Reports System
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:
Original:
Changed:
