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>DQPPUSS8K5BTNTBO</XmlLoginId>
    <LoginId>DQPPUSS8K5BTNTBO</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 both the new (changed) and original bookings will vary slightly from those seen during the regular booking process. The first difference will be seen after the submission of the StartBooking command when the new and original bookings will be given the following statuses.
 Status of Original Booking New Status of Booking
 BookingChangeInProgress BookingChangeInProgress

If an error occurs during the booking stage the status of each of the bookings will be updated as follows:
 Status of Original Booking New Status of Booking
 BookingChangeInUnconfirmed Unconfirmed or Failed

If the booking stage completes successfully the status of each of the bookings will be as follows:
 Status of Original Booking New Status of Booking
 BookingChangeInProgress Succeeded

The CheckBooking command will finalise the statuses of the new and original bookings to the following:
 Status of Original Booking New Status of Booking
 BookingChanged BookingChangeSucceeded

Note: If the booking change was successfully processed the first time the CheckBooking command is executed the response status will be Succeeded. However if the command is resubmitted all subsequent responses will have a status of BookingChangeSucceeded.

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 screen shot 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 be 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 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 screen shots below illustrate both the original booking and new bookings as they would appear after a successful booking change request has been processed:

original:
changed: