Booking Changes

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.

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 correspond 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>1</Radius>
	</Origin>
	<Destination>
		<Descriptor>ALC</Descriptor>
		<Type>airportcode</Type>
		<Radius>1</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>
		</ChangeAttributeList>
	</BookingChange>
	<Timeout>60</Timeout>
	<TravellerList>
		<Traveller>
			<Age>45</Age>
		</Traveller>
	</TravellerList>
</StartRouting>

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

<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:

 Status of the original Booking Status of the new Booking Description
 Succeeded or BookingChangeSucceeded BookingChangeInProgress After StartBooking request is sent. 
 The original booking keeps the original status!
 BookingChanged BookingChangeSucceeded If the booking process is successful.
 BookingChangeUnconfirmed Unconfirmed If the booking process is not successful and TravelFusion can't confirm the status of the booking. 
 BookingChangeUnconfirmed UnconfirmedBySupplier If the booking process is not successful and the supplier couldn't confirm the status of the booking. 
 Succeeded or BookingChangeSucceeded BookingChangeFailed If the booking process is not successful and an appropriate error is found in the response (see the error handling guide for more details).
 The original booking keeps the original status!

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.

Administration System

As with regular bookings, booking changes can be reviewed via the administration 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 'info' 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 Return Date').
  • 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 bookings as they would appear after a successful booking change request has been processed:

original:
changed: