Release Notes 19.1

For details, see:

• DA 828 Defect Fixes for Release 19.1
• DA 835 Defect Fixes for Release 19.1.1
• DA 839 Defect Fixes for Release 19.1.2
• DA 842 Defect Fixes for Release 19.1.3
• DA 845 Defect Fixes for Release 19.1.4
• DA 846 Defect Fixes for Release 19.1.5
• DA 848 Defect Fixes for Release 19.1.7
• DA 851 Defect Fixes for Release 19.1.8
• DA 852 Defect Fixes for Release 19.1.9

Previously, the flight service information display did not return the codeshare operating carrier and flight number in the flight service response, preventing agents from understanding the carrier on which the Minimum Connect Time (MCT) was based.

This enhancement provides users with the carrier code and flight number for the operating carrier of a codeshare agreement (DEI 50).

• The DEI 50 carrier code is used as the default carrier for MCT processing and is found in the *SVC response.
• By allowing the codeshare carrier and flight number in the flight service response, users can respond to questions and problems both pre- and post-departure without having to call Travelport to obtain the data.

The CodeshareInfo attribute contained within the FlightDetails element previously had a Max Occurrence of 0. Thus, when the FlightDetailsReq is sent for a flight, which has multiple legs and different operating carrier for each leg, the response was unable to show all operating carriers.

With this enhancement, in order to show the CodeshareInfo for each leg for flights where multiple legs exist, customers will need to request the legs individually until such a time that the system is updated to return codeshare information at a segment level. Segment-level codeshare is expected in a future release.

This enhancement prices a specific fare in a specific brand. In order to price a fare that was received in a search response, all the required modifiers and fare details need to be sent. This includes both the booking code and the brand tier along with any other pricing modifier.

The fare returned in the response is associated to the brand tier, booking code and any other pricing modifier sent in the request. If no fare is found for those modifiers an error is returned.

For example, when Air Price is requested with SellCheck and AirSegmentPricingModifiers:

<air:AirPricingModifiers SellCheck=”true” >

 <air:AirPricingCommand>

  <air:AirSegmentPricingModifiers AirSegmentRef="S100" BrandTier="0003">

   <air:air:PermittedBookingCodes>

    <air:BookingCode Code="S"/>

   </air:PermittedBookingCodes>

  </air:AirSegmentPricingModifiers>

 </air:AirPricingCommand>

Sell Check is performed and the first solution returns for the requested BrandTier and Booking code. With the example, the first solution is for BrandTier="0003" and BookingCode “S”

This enhancement supports the exemption of specific taxes by tax code and/or country code, which assists with customers who deal with tax-exempt accounts, like governments, etc.

To use this feature, in Air Price and Reprice, in the ExemptTaxes element, use:

• @AllTaxes=True - Returns all taxes exempted.
• @CountryCode for specific country
• @TaxCategory for specific tax category

And /AirPricingModifiers @Sellcheck=True and Reprice

Notes:

• Split Pricing is out of scope for this enhancement.
• Galileo (1G) and Apollo (1V) already support this feature.

For AirPrice, when both SellCheck and AirReservationLocatorCode indicators are included, the response will differ (shown below) from other transactions due to maintaining consistency between the provider and Universal API responses. For example:

<air:TaxInfo Category=""AY"" Key=""70002"" TaxExempted=""true"">

  <air:Amount CurrencyCode=""USD"" Value=""0.00""/>

</air:TaxInfo>

For all other transactions,

• Universal API only displays the non-exempted taxes. If all the taxes are exempted, and any US tax is involved, only the US tax is exempted in response.
• @CountryCode for a specific country is not supported.

This enhancement provides the ability to include a Corporate Customer ID at time of booking, before the initial end transact, to track actual versus forecast segments for corporate customers via reporting and analysis. For example:

<common_v48_0:XMLRemark Key="R7qWosBAAA/BZyVAAAAAAA==" Category="Corp ID"> TEST01USCWT </common_v48_0:XMLRemark>

Corporate IDs:

• Include at initial Booking creation.
• Are visible in the book response and when retrieving the booking.

New Corporate ID's can also be added via UR modify request, but can’t be modified or deleted after it is added to the PNR.

With this enhancement, Travelport validates on the length of the rental for vendors that have supplied us with maximum rental days for prepay rates. For example, one car vendor does not allow pre-pay for rentals exceeding 28 days. Rental car suppliers will receive less unnecessary traffic, which helps reduce performance items such as slower response times and timeouts:

• By Travelport limiting VehicleSearchAvailability “prepay” requests to only be sent to the vendor when the length of the rental does not exceed vendor specifications, such as if a rental request is 28 days or less, a significant amount of traffic is prevented from being sent to the vendor.
• Universal API customers, when sending a VehicleSearchAvailability request that includes rate category as prepay, it allows Travelport to validate the length of rental information being sent in the request, and if it is outside of what the vendor or supplier allows for pre-paid, an error returns to block unnecessary traffic that may be impacting supplier performance.
• If more than the set number of days, (for example, 28 days), the following error returns:
  <faultstring>Prepay rates are not available for rental requests that exceed 28 days.</faultstring>

When the SARA validation provides a case 003 result, it typically means two possible scenarios:

• "NO VERIFICADO" with hash code which equals no response from Spanish Police, or
• "PLATAFORMA SARA NO DISPONIBLE" which equals no response from the Spanish Ministry of Public Works

However, when 003 No Verificado, with no hashcode, is returned by Spanish Police Department, this enhancement provides a configurable resend validation to re-request up to five times, or until you get valid response. Each re-request automatically voids the previous ETKT issued with case 003 if an additional permitted SARA attempt occurs.

To configure retry attempts, contact your Travelport Account Manager.

A successful response is:

• Case 000 No Verificado with HASH code

• Case 001 Verificado

Previously, the FareCalc element only returned in the base fare in the Air Price response. With this enhancement, the Fare Calc attribute returns for the base and upsell fares in the Air Price response. For example:

Base Fare info:

Line 35: <air:Brand Key="1SGdT3MJ3BKA2fNAAAAAAA==" BrandID="164677" UpSellBrandID="164679" Name="Economy Light" Carrier="LH" BrandTier="0002">

Line 270: <air:FareCalc>ADT LON LH FRA36.66NUC36.66END ROE.818146 LH</air:FareCalc>

Upsell Fare info:

Line 327: <air:Brand Key="1SGdT3MJ3BKAggNAAAAAAA==" BrandID="164679" Name="Economy Classic" UpSellBrandFound="false" Carrier="LH" BrandTier="0003">

Line 563: <air:FareCalc>ADT LON LH FRA63.55NUC63.55END ROE.818146 LH</air:FareCalc>

Previously, performing an exchange with a ticket that was not booked through Universal API, nor having an existing PNR on the provider system, customers were unable to receive all the details of the ticket to do a calculation on the datapoints.

This enhancement returns all the ticket details that Rapid Reprice requires to execute and exchange. Data points retrieved include all available fields in the ETR element.:

Integration of SARA, Spanish government system responsible to verify the eligibility the resident passengers.

1G

A new framework has been implemented to verify the eligibility of passengers wanting to fly using a Spanish Residency discount. This validation is done when the ticket is issued. The Spanish government has provided access to a database called SARA (Automatic Residency Accreditation System) which can validate if the passenger is eligible for that discount. If the passenger has a Resident discount, the provider must call SARA to validate the passenger. The default Boolean @ValidateSpanishResidency value is false, and if set to 'true' a SARA validation is executed.

These are the possible responses from that Validation call:

• VERIFICADO (verified) Case number: 001: this passenger's eligibility has been validated by the Spanish Police database, so he/she does not need to show his/her resident certificate at the time of check-in and/or boarding at the airport.
  • The SSR CKIN will be sent to the Airline with “VERIFICADO”.
  • The passenger will be able to check in and go to the gate.
• NO VERIFICADO (not verified) Case number 000: The Spanish Police database has processed the request but find the passenger no eligible.
  •  An SSR CKIN “NO VERIFICADO” is sent to the airline.
  • The passenger will need to show his/her resident certificate at the time of check-in in order to board at the airport.
• NO VERIFICADO Case Number 003 with Hash Code:
  • An SSR CKIN “NO VERIFICADO” is sent to the airline.
  • The passenger will need to show their resident certificate at the time of check-in in order to board at the airport.
• NO VERIFICADO Case Number 003 PLATAFORMA NO DISPONIBLE (Platform not available).
  • An SSR CKIN “NO VERIFICADO” is sent to the airline.
  • The passenger will need to show his/her resident certificate at the time of check-in to board at the airport.

All carriers, in addition to the SSR CKIN information, also require the transmission of all resident, numerous family details and the SARA validation results via the RET FILE FRCA IT/07, when the BSP reports take place. Consequently, all these details are present in the fare construction of the electronic ticket in order to properly populate and transmit.

After the ticket is issued the Web Service “Ticket” is called.

• Ticket - store the details of the issued ticket and the related validation data. That data is used to generate a nightly report to the airline and SARA.
• Void - used in two scenarios:
  • Void an issued ticket.
  • When it has not been possible to issue a ticket after making a call to the SARA validation service (example: credit card has no balance and the ticket has not been issued).
  • In both scenarios a service call is made to let to civil aviation that there will be no ticket associated to the validation call.

Spanish Resident Fares

Identify the country of reissue PCC to ensure that correct processing (BSP or ARC) takes place.

Previously, the country code of the active PCC was not returned in the BookingDisplayRsp nor UniversalRecordRetrieveRsp

This enhancement has been implemented to differentiate ARC (used for 1V reconciliation) PCCs from BSP (use for 1G reconciliation) PCCs, and from Worldspan (1P) PCCs. With this information, Travelport can enable the correct processing of reissues in Galileo, in US PCCs, so that when repricing, results display in a netted (ARC) or non-netted (BSP) format.

Shared Booking

UR Retrieve

Travelport Rooms and More will be retiring. As part of our multi-source content strategy, Travelport made the decision to retire Rooms and More on August 3rd, 2019

Customers will have the opportunity to modify or cancel existing bookings (within the policies specified for the booking) in Rooms and More until August 3rd, 2019 in the usual way. After August 3rd, 2019, customers will need to contact the provider directly for any modifications or cancellations to any remaining active bookings.

Until August 3rd, 2019 customers will still be able to make new bookings. However, it may be simpler for you to transition to an alternative booking solution as soon as possible to make the ongoing management of your bookings easier.

The retirement of Rooms and More is driven by our aim to provide access to aggregated hotel content from multiple sources delivered through a single point of sale to enhance your user experience..

All TRM content is removed from the Universal API Help System.

In the original 19.1 schema release, the version of the shared booking file was labeled "SessionContext_v1_0" instead of "SessionContext_v1"

The typo is fixed in the 19.1 schema, and an updated version of the .zip file is available for download (updated 02 August 2019), as well as the differences file.

Support of fare penalties details for base fares and upsell fares in Air Shop (price points)

Previously, fare penalties were not included for any upsell fares. As a result, upsell fares were unused.

This enhancement provides the same penalty and refund data for the upsell fares as related fares, returning the most restrictive fare penalty details (refundable, change, and cancel), so that agents and/or OTAs can display accurate penalty details when ReturnUpsellFare="true"

For example, if

LowFareSearchReq/@SolutionResult="false" and LowFareSearchReq/@ReturnUpsellFare="true",

Details for Upsell / Price Points are returned in:

LowFareSearchRsp/AirPricePointList/AirPricePoint/AirPricingInfo

• @Refundable=”true”
• /ChangePenalty
• /CancelPenalty

Low Fare Search

Support of fare penalties details for base fares and upsell fares in Air Price

This enhancement adds fare penalties details for base fares and upsell fares (all fares) in AirPrice.

The most restrictive rules in the CAT16 category (cancel, change, and refundable attributes) for base and upsell fares now return in the response, along with PenaltyApplies tags to denote Anytime, Before Departure, and After Departure penalty information.

Air Price

This enhancement allows users to determine original branded fare information when the ticketing time limit has expired, so that the fare can be restored based on historical details.

• The ability to request fare with brand details with historical dates allows a user to know the original branded fare stored when ticketing time limits have expired and the fare needs to be restored.
• Bookings that are ITX (Independent Tour Excursion fare. Group tour fare that may be availed-of by an independent traveler who purchases a ground tour package with air travel), which means bookings that are created days, weeks, or months in advance of the ticketing date, leads to the requirement of being able to store historical fares with current and historical taxes (depending on the contracts with individual airlines).
• This feature allows users to know what brand and brand optional services would apply to such a booking.

When a historical date is used in the @TicketDate in the request for an AirPrice, the successful response returns the historical fare, tax details, and associated brand and attribute details.

This feature is configured by PCCs. Please contact your Travelport representative to be activated.

This enhancement provides the ability to include ticket issue date, IATA number, and ticketing agent sign-on in a single book retrieve request. This functionality allows the ability to review when, and by whom, a ticket was issued when displaying a booking in a single request, whereas previously it took multiple requests.

Previously, DI (Document Instruction) lines were not fully shown in the Ticketing Modifiers.

With this functionality, the request retrieves all the DI line Lines present in the PNR from the provider and returns the DI lines as Free Text in the response. For example:

<air:TicketingModifiers Key="ZmWi5d/Y3BKATfiAAAAAAA==" ElStat="A" FreeText=" N1.1|K8.5" DocumentInstructionNumber="1" Status=”Ticketed” NameNumber="1.1" IsPrimaryDI="false" >

<BookingTravelerRef Key="iqYs30Z+TtSh9xXV6q50yA=="/>

<common_v47_0:Commission Level="Fare" Type="PercentBase" Percentage="8.5"/>

</air:TicketingModifiers>

Prior schema versions continue to support the old format of displaying DI without the "status" information.

Schema change only.

Schema change for future functionality.

Air Booking

Shared Booking

UR Retrieve

Add SVC segments to Air Exchange.

1P

This enhancement and the next one support the ability for Worldspan customers to identify a change fee in an Exchange transaction and to collect the change fee using EMD-S through Universal API.

Prior to this release, when a voluntary exchange resulted in a change fee, the customer had to add an SVC segment directly in the GDS host system in order to account for a change fee.

With this release, an SVC segment for each passenger type can be added to the Air Exchange request to specify the change fee for that passenger PTC type. If the change fee is zero, no SVC segment is added.

• AddSvc element added.
• @RFIC, @RFISC, and @SvcDescription are required.

Note: At this time, an SVC cannot be added for an Infant passenger type with Exchange.

In previous releases of Universal Record Retrieve, service segments were identified in PassiveReservation. With this release, service segments are returned in the new element AirReservation/SvcSegment.

Air Exchange

UR Retrieve

Yes

Enable EMD-S for voluntary exchanges.

1P

Prior to this release, when a voluntary exchange resulted in a change fee, the customer had to manually add an SVC segment and manually issue an EMD-S to collect the change fee.

Prior to this release, the EMDIssuance transaction only supported EMD-A (Associated). With this release, EMDIssuance can be used to issue one or more EMD-S (Standalone).

For Worldspan (1P), the updated workflow for exchanging a ticket and collecting a change fee includes:

1. Check eligibility using AirExchangeEligibilityReq.

2. Request an exchange quote using AirExchangeQuoteReq.

3. If the exchange results in a change fee, send an exchange request with AddSvc using either AirExchangeReq or BookingAirExchangeReq. Include @RFIC, @RFISC, and @SvcDescription information.

4. Re-issue the ticket.

5. Issue an EMD-S using EMDIssuanceReq.

EMD Issuance

Yes

Perform a Split Ticketing Search in a single request

Universal API supports split bookings for provisioned customers. If you are interested in this functionality, please contact your Travelport representative.

A split booking allows you to book a roundtrip ticket by submitting two separate pricing solutions in one reservation request. Prior to this release, you had to submit two separate booking requests, one for the outbound itinerary and the other for the inbound itinerary. You can then ticket the two segments separately under the same PNR.

If you are provisioned for split booking, send two AirPricingSolution elements in AirCreateReservationReq to specify that a split booking should be made. @ProviderCode in each AirPricingSolution/AirSegment must match.

The response returns one provider PNR. Each AirPricingSolution must be ticketed separately with the airlines.

For the Split Ticketing Search, a split book request is submitted via AirCreateReservationReq with two (and only two) AirPricingSolutions.

• The first AirPricingSolution contains pricing details about outbound segments.
• The second AirPricingSolutions contains pricing details about inbound segments.

After submitting an AirCreateReservationReq with 2 AirPricingSolutions, a split booking validation process occurs.

Support fare rules in structure format for categories 31 and 33.

Consume updated structured fare rules.

Currently, air fare rules can be returned in full text or abbreviated text using @FareRuleType.

With the Air 47.0 release in Universal API 18.4, air fare rules were returned in a structured format so that customers could customize how they want rules displayed to their own customers (for example, in a different language).

This enhancement ensures that the air fare rules return in a structured format for easier consumption.

To return air fare rules in a structured format, send AirFareRulesReq/FareRulesFilterCategory. If FareRulesFilterCategory is blank, all categories with structured fare rules are returned.

To return a specific category, set CategoryCode to one of the following values (multiple CategoryCode elements can be sent in a request):

• ADV returns advanced reservation and ticketing rules (Cat 5).
• MIN returns minimum stay rules (Cat 6).
• MAX returns maximum stay rules (Cat 7).
• STP returns stopover information (Cat 8).
• CHG returns penalty information (Cat 16).
• VOL returns Voluntary Changes rules (CAT 31).
• VOR returns Voluntary Refunds information (CAT 33).

Note: VOL and VOR are new for Universal API 19.1 Release.

Only categories for which structured fare rules exist are returned.

Fare rules return in CategoryDetails and VariableCategoryDetails AirFareRulesRsp/FareRule/StructuredFareRulesType .

If both text and structured fare rules are requested at the same time, only structured fare rules are returned.

This enhancement adds the attribute AirPriceReq/@IgnoreAvailability. If IgnoreAvailability= true, then it allows users, when working in a session, the ability to get the lowest price and class of service without checking availability.

This allows their automated system to decide when a lower class of service is available, and they can rebook the itinerary at a lower fare.

Air Pricing

Session BookingPricing

Previously, AirFareDisplay service only supported Departure date and Return Date for seasonal types of fares.

This enhancement adds the Seasonal fare option in the AirFareDisplayReq/AirFareDisplayModifiers/@FareSearchOption="Seasonal" which allows consolidators the ability to determine the seasonality of a specific fare when requesting a fare display to narrow the results to a specific season.

This functionality requires @FareSearchOption = "Seasonal" and @DepartureDate in the Air Fare Display Modifiers. The response populates the FareRestrictionSeasonal element.

This enhancement provides the flight or flights that cause the issue when pricing error messages are returned at time of pricing specific flights. The information in the error response includes:

• Carrier
• FlightNumber
• ClassOfService
• DepartureTime
• Origin
• Destination

Return commission indicator for sold segments

1G, 1V

This enhancement allows the commission content to be returned in the sold hotel segment so that the middle office, back office, and third party commission partner can track the commission.

The UniversalRecord/HotelReservation/HotelCommission has two attributes: Commission Percentage and Commission Indicator

Commission percentage has the precedence over Commission Indicator.

• If the Commission percentage is present, this value displays:
  • <HotelCommission>08</HotelCommission>
  • “08” is a commission value
• If commission indicator is present, one of the following values display:
  • <HotelCommission>Y</HotelCommission> or
  • <HotelCommission>N</HotelCommission>
  • Y or N is a commission indicator

Hotel Booking

UR Retrieve

UR Import

Support of regional trains schedules for SNCF in shop, price, book

This enhancement includes PAO (3C) regional trains as a supplier for SNCF in shop, price, and book. Customers who want to use it must be provisioned for the 3C supplier code.

To specify PAO in the availability response, you must specify it as a preferred supplier in RailSearchModifiers/PreferredSuppliers/RailSupplier Code="3C"

The HostToken in availability response must be used in the pricing and rail reservation requests.

With PAO:

• When shopping regional rail, service is returned for the 11 regions in France.
• When shopping, journey solutions return in association with a fare quote, as received from the 3C/SNCF Regional provider
• When performing a shop/price/book for PAO, an agent must:
  • Provide the origin and destination dates of travel and other shopping modifiers if necessary. For example, loyalty cards, discount codes, corporate codes, etc.
  • Be able to price a selected journey solution with or without modifiers i.e. loyalty cards, discount codes, corporate codes, etc.
  • Be able to select a journey solution and create a booking with or without modifiers i.e. loyalty cards, discount codes, corporate codes.

Notes:

• SNCF (2C) does not have a host token, but is available for 3C.

• Loyalty card is not supported by 2C/3C.

• Agency Mail ID is not supported by 3C.