Mixed Flight Suppliers

FAB’s Mixed Flight Suppliers function (MIX) allows return trips to be constructed from two distinct oneways.

This offers the following potential benefits:

• An Open Jaw trip can be constructed for supplier(s) that do not natively support Open Jaw.
• A cost or datetime optimised trip can be constructed.

In all cases the outbound and inbound supplier need not match. In fact, by default, a MIX trip will only have the same outbound and inbound supplier if it is Open Jaw. This default was chosen because a roundtrip MIX with the same outbound/inbound supplier is normally undesirable; as it will rarely be cheaper than a non-MIX roundtrip. This default can be changed via config.

A MIX FAB booking journey is much the same as a non-MIX booking journey; the same messages (FAB_PkgAvailRQ/FAB_BasketRQ) are used. This page will highlight the key differences.

Search

MIX results are returned under the Supplier Code MIX. Therefore you must ensure that you do not exclude this Supplier Code from your search request.

For MIX results, the following response attributes have a slightly different definition:

• PackageHoliday@Supplier - always set to “MIX”
• PackageHoliday/Flight@FareType - most “private” type (NoFrills<Published<Private) across both flights
• PackageHoliday/Flight@ITFare - set when either flight is ITFare=”true”
• PackageHoliday/Flight@CAT35Fare - set when either flight is CAT35Fare=”true”

FlightJourneyDetails a sub-element of Flight will appear. This is used to provide further information on each underlying one-way flight. See FAB_PkgAvailRS reference page.

Basket - create / amend

When creating a Basket from a “Mixed Flight Suppliers” result (Roundtrip or OpenJaw), FAB will convert the ItineraryId value on the result into two component TravelSegments just like it does with other normal Flight ItineraryId values.

The basket response will consist of two ItineraryCost Components, and other parts of the response (e.g ItineraryOptions) will also appear twice; one for each Component.

A ComponentId value will be set on numerous details of the basket to enable linking of those details to each product component. The ComponentId value will be unique to this Basket, defaulting to 1a and 1b.

Such basket details include:

• TravelSegments
• ItineraryCost Component
• OptionalExtra
• ImportantInformation Errata
• BookingInfo
• FOIDAllowed lists
• Itinerary & Basket “Component”
• SeatOptions

An example of ComponentId being set on Errata:

...
<ImportantInformation>
<Errata SupplierCode="EZJ" ComponentId="1b" Code="Seat Selection - Restricted"
Text="Exit Row seats are not available for selection for Passengers who are Child under 16
yrs have hearing, Sight or other disability, has Infant on Lap, Pregnant, Physical disorder,
Elderly and fragile"/>
...

You must reference the relevant ComponentId when selecting seats and/or optional extras.

E.g:

...
<OptionalExtra ComponentId="1a" Code="YN1" Supplier="NOR" Quantity="2"/>
...

...
<SeatOptions FlightNumber="DY1349" ComponentId="1a" Supplier="NOR" DeparturePoint="MAN">
  <Seat Num="3B"/>
</SeatOptions>
...

Basket - book

• Remember that it’s possible for both components to require card payment.
  • If you are paying via Pax2Pay this will be automatically handled for you.
  • If paying with a passed in card see Paying with a passed in card for tips on identifying this, and remember to use a multi-use card.
• Two discrete transactions will occur (outbound/inbound) therefore:
  • It is possible that the resultant BookingComponents have different Success states.
  • If successful, two separate BookingReferences will be issued.