The disruption handling actions feature allows the end user to accept the involuntary changes or reject them by amending the booking.

The process consists of the following two steps:

Step 1: List bookings with latest changes using TF Order Change Notification API.


In the GetLatestBookingDetails response there can be found an extra special element indicating the possible follow up actions or remark how to handle the disruption via airline call center for involuntary changes to the booking. If missing then any follow up action is not required to the booking.

GetLatestBookingDetails response XML

<CommandList>

<GetLatestBookingDetails>

<!-- if the value of the isRequired attribute is true then one of the listed follow up action is required by the supplier -->

<InvoluntaryChangeActionList isRequired="true">

<!-- the most common follow-up action -->

<InvoluntaryChangeAction type="accept">

<!-- optional: contains T&C or remarks for a type of change -->

<SupplierInfoList>

<SupplierInfo>

<DisplayName>Remark</DisplayName>

<InfoType>...</InfoType>

<!-- Examples -->

<!-- - to denote the flight segments that have been disrupted -->

<Info>Disrupted flight segments</Info>

<!-- OR -->

<!-- - to denote the flight segments that have been re-accommodated by the airline -->

<Info>New flight segments</Info>

</SupplierInfo>

</SupplierInfoList>

</InvoluntaryChangeAction>

<!-- optional: -->

<InvoluntaryChangeAction type="cancel">

<!-- optional: -->

<SupplierInfoList>

<SupplierInfo>...</SupplierInfo>

</SupplierInfoList>

</InvoluntaryChangeAction>

<!-- optional: -->

<InvoluntaryChangeAction type="change">

<!-- optional: -->

<SupplierInfoList>

<SupplierInfo>...</SupplierInfo>

</SupplierInfoList>

</InvoluntaryChangeAction>

<!-- optional: -->

<InvoluntaryChangeAction type="call airline">

<!-- optional: -->

<SupplierInfoList>

<SupplierInfo>...</SupplierInfo>

</SupplierInfoList>

</InvoluntaryChangeAction>

</InvoluntaryChangeActionList>

...

</GetLatestBookingDetails>

</CommandList>

Step 2: Use the following follow up actions to handle the booking disruptions.


(1) Accept.

It is a process in which the end user can accept involuntary changes to the booking in the following way:

AcceptInvoluntaryBookingChange request XML

<CommandList>

<AcceptInvoluntaryBookingChange>

<XmlLoginId>[Travelfusion Login Id]</XmlLoginId>

<LoginId>[Travelfusion Login Id]</LoginId>

<!-- Either TF booking reference … -->

<TFBookingReference>TFREF000B</TFBookingReference>

<!-- ... or supplier booking reference (PNR, booking locator) needs to be provided -->

<SupplierReference>LTB7ZL</SupplierReference>

</AcceptInvoluntaryBookingChange>

</CommandList>

AcceptInvoluntaryBookingChange response XML

<CommandList>

<AcceptInvoluntaryBookingChange>

// the latest booking details with removed InvoluntaryChangeActionList element if the accept process has been successful

</AcceptInvoluntaryBookingChange>

</CommandList>


(2) Cancel (a.k.a Reject).

It is a process in which the end user can reject involuntary changes to the booking using Cancellation API in the following way.

(a) Preview cancellation

<CommandList>

<GetBookingDetails>

...

<BookingProfile>

<CustomSupplierParameterList>

<CustomSupplierParameter>

<Name>IsBookingForCancellation</Name>

<Value>true</Value>

</CustomSupplierParameter>

<CustomSupplierParameter>

<Name>IsForInvoluntaryBookingChange</Name>

<Value>true</Value>

</CustomSupplierParameter>

...

</CustomSupplierParameterList>

...

</BookingProfile>

</GetBookingDetails>

</CommandList>

(b) Start cancellation

<CommandList>

<StartBookingCancelPlane>

...

<BookingProfile>

<CustomSupplierParameterList>

<CustomSupplierParameter>

<Name>IsForInvoluntaryBookingChange</Name>

<Value>true</Value>

</CustomSupplierParameter>

...

</CustomSupplierParameterList>

</BookingProfile>

</StartBookingCancelPlane>

</CommandList>


After successful cancellation in the GetLatestBookingDetails response there will be no more InvoluntaryChangeActionList element visible until the next involuntary change occurs.


(3) Change (a.k.a. Re-shop).

It is a re-book process in which the end user can reject the involuntary changes and re-shop the booking using Booking Change API in the following way:

Start booking change

<CommandList>

<StartRouting>

...

<BookingChange>

<TFBookingReference></TFBookingReference>

<ChangeAttributeList>...</ChangeAttributeList>

</BookingChange>

...

<BookingProfile>

<CustomSupplierParameterList>

<CustomSupplierParameter>

<Name>IsForInvoluntaryBookingChange</Name>

<Value>true</Value>

</CustomSupplierParameter>

...

</CustomSupplierParameterList>

</BookingProfile>

</StartRouting>

</CommandList>


After successful change in the GetLatestBookingDetails response there will be no more InvoluntaryChangeActionList element visible until the next involuntary change occurs.