Modifying Universal Records

Existing data in a Universal Record can be added to, deleted, or updated for general record and traveler data and for travel bookings.

Note:RCSrail bookings and ACH air bookings cannot be canceled because these are ticketed and paid when they are booked, and may incur a cancellation fee. These bookings must be refunded or exchanged at the PNR level. See Exceptions for details.

Schema

See the following transactions for modifying a Universal Record:

Request

Send the UniversalRecordModifyReq to make changes to the Universal Record and associated PNRs.
Specify the travel segments and passive segments to be modified in UniversalModifyCmd

VehicleAdd modifies the UR by adding a new vehicle segment, while VehicleUpdate modifies an existing vehicle segment. VehicleDelete cancels a specified vehicle segment and removes it from the active UR.
AirAdd modifies the UR by adding a new air segment, while AirUpdate modifies an existing air segment. AirDelete cancels a specified air segment and removes it from the active UR. In Air v34 and higher, the BrandInfo element of AirAdd can be used to add Rich Content and Branding (RC&B) information to the UR. AirDelete can be used to delete the brandinformation in the Brand element. See Rich Content and Branding in Air Bookings for details.
HotelAdd modifies the UR by adding a new hotel data to a segment, while HotelUpdate modifies an existing hotel segment. HotelDelete cancels a specified hotel segment and removes it from the active UR.
UniversalAdd modifies the UR by adding a new traveler to the record.
- UniversalAdd can also be used to add Review Booking data.
UniversalUpdate modifies existing traveler data or general associated to the record itself all travelers within that UR.
- UniversalUpdate can be used to modify a Review Booking.
- /OwnershipChange @OwningPCC can modify the ownership of PNR.
  - Supported in Worldspan (1P) only. Galileo (1G) and Apollo (1V) returns the error "(provider) Actual Cause - Ownership change not implemented for this provider."
  - After changing ownership using UniversalRecordModifyReq:
    - The UniversalRecordModifyRsp updates the owningPCC attribute in UniversalRecord/ProviderReservationInfo element.
    - The ownership of the UR is changed.
    - If there is no modification in Phone number, then the current phone number is considered as the new phone number.
UniversalDelete removes a specified traveler or general data from the active UR.
- When deleting Infant in Lap, the @Element must be BookingTraveler and the Key for the infant traveler must be sent in the request. The UR History is updated to show the deletion of the INF Passenger Type Code.
PassiveAdd adds a new passive segment to the UR. PassiveDelete removes a passive segment from the active UR.

Notes:

Because passive segment data is external, and cannot be modified through Universal API, passive segment data can only be added or deleted through Universal API.
Existing Sell Messages cannot be modified UniversalRecordModifyReq. Returned Messages are added to UR History.
The Key attribute is useful when batch Universal Record modifications are made in a single request. By sending a Key in the request, errors and warnings in the response are associated to the Key in the request, which helps identify where the error or warning occurred.
Galileo (1G) and Apollo (1V) have been enhanced to allow users to send in any value, A to Z, for Phone Type; previously, the type of phone that could be used in Galileo and Apollo was limited to Agency, Business, Mobile, Home, Fax, Hotel, Other, None, or Email.

Multiple Modifications

Each addition, deletion, or update to the UR information requires a separate UniversalModifyCmd request. For example, if three phone numbers are added to the Universal Record, three instances of UniversalModifyCmd must be sent. Or, if a hotel segment is added and a vehicle segment is deleted, two instances of UniversalModifyCmd must be sent to accommodate each change.

Note: For Worldspan (1P), it is not recommended to send modifications for multiple products (such as universal, passive, vehicle, air, and/or hotel) in a single UniversalModifyCmd request.

Canceling and Rebooking

A command to add a new segment can be combined in a single call with a request to delete an existing segment. For example, to cancel and rebook and air segment, an AirAdd request can be combined with an AirDelete request.

Loyalty Cards and Cross-Accruals

To accommodate cross-accruals among loyalty memberships, AirAdd, HotelAdd, and VehicleAdd can also be used to add or update a loyalty card for an air, car, or vehicle supplier, even if that segment type is not included in the PNR. Similarly, AirUpdate, HotelUpdate, and VehicleUpdate can be used to modify loyalty card data.

For example, AirAdd can be used to include loyalty card information in a PNR that contains only hotel segments if the air supplier has a cross-accrual agreement with a hotel chain.

For all segment types, cross-accrued loyalty cards must be added for the primary traveler in the UR; if the loyalty card is added for a non-primary traveler , an error is returned: User is not the primary traveler on the PNR, action not allowed.

Note: Prior to Universal v33.0, when a Cross Accrual was applied on a Universal Record (UR) with an existing loyalty card tied to a Passenger Name Record (PNR), if cross accrual failed, the existing loyalty card associated to the PNR was deleted. With Universal v33.0, Universal API now adds the loyalty information back in if the cross accrual application fails.

Emulating PCC

Note: Refer to Emulation for more information.

The OverridePCC is used to specify the emulated PCC in Common.xsd. When the Override PCC is sent in a booking request:

The OwningPCC attribute in ProviderReservationInfo is set to the emulated PCC (the OverridePCC).
For Worldspan , the Override PCC is used to set the PCC in the first phone field of the provider PNR, therefore making the OverridePCC the Owning PCC of the PNR.
For Galileo and Apollo, Service Bureau set up is required for emulation with Override PCC.

If OverridePCC is NOT sent in the booking request, the OwningPCC attribute in ProviderReservationInfo is set to the Target Branch.

Form of Payment

In Universal schema:

Credit card authorization codes can be added, modified, or deleted. These changes are supported at both the PNR level and stored-fare level.

Show more information

When credit card authorizations are modified for cards added through the Universal API, masked data is supported using the CreditCardAuth@FormOfPaymentRef, which is a reference to the form of payment in the existing Universal Record. Masked data can occur if the credit card has been added by a user or from a profile.

When masked credit card data is used, Universal API looks up the credit card in the Universal Record using the PaymentRef or FormOfPaymentRef in order to get the credit card number to which the authorization code is applied. FormOfPaymentRef attribute is required for adding masked PNR-level credit card authorization.
Credit card form of payment without an associated credit card type is allowed during Universal Record modify air. A credit card form of payment without a credit card type is allowed at the PNR level and stored-fare level.

Important: If Reuse FOP option is specified during Book-on–Book or through UR Modify using a credit card FOP with a missing vendor code for hotel or vehicle book, then the existing validation check or the provider validation error remains.
When a booking is created with multiple Forms of Payment (FOP), each from a separate Profile ID, payments are applied and saved as such. Additionally, in the response, all of the Forms of Payments are shown, applied, and saved to each corresponding Profile ID.

Commission Override

A Commission Override modifier can be included in a UR Modify request. It updates the booking with a document instructions line (DI) that allows the commission to be overridden if a commission mismatch error is returned by the provider in AirTicketingRsp: "CAT 35 COMMISSION EXISTS-ADD -OK OPTION TO OVERRIDE".

If an error is returned in the Air Ticketing response, @CommissionOverride can be sent in the UR Modify request to override the mismatch:

UniversalModifyReq/UniversalModifyCmd/AirAdd/PricingTicketingModifiers/TicketingModifiers
UniversalModifyReq/UniversalModifyCmd/AirUpdate/PricingTicketingModifiers/TicketingModifiers

After the Universal Record is modified, the Air Ticketing request must be sent again.

Note: Only Worldspan (1P) support this functionality.

Special Service Requests (SSR)

@ProfileID and @ProfileSecureFlightDocKey can be included in the request for DOCO, DOCA, or DOCS SSRs (Special Service Requests). Universal API validates the TravelerID in BookingTraveler/AppliedProfile against the Universal Record and the Air Booking request that is being sent. The ProfileSecureFlightDocKey is not validated.

Both ProfileID or ProfileSecureFlightDocKey must be sent in the request for secure flight SSRs or an error is returned.

If a Traveler name is more than 55 characters, the secure flight SSR is displayed at the Universal Record level and not at the Booking Traveler level. This means that when SSR @ProfileID and @ProfileSecureFlightDocKey are sent in the request, they are returned in the response at either:

The Booking Traveler level:
UniversalRecordModifyRsp/UniversalRecord/BookingTraveler/SSR @ProfileSecureFlightDocKey
UniversalRecordModifyRsp/UniversalRecord/BookingTraveler/SSR @ProfileID
The Universal Record level:
UniversalRecordModifyRsp/UniversalRecord/SSR @ProfileSecureFlightDocKey
UniversalRecordModifyRsp/UniversalRecord/SSR @ProfileID

After SSRs are added successfully with the Traveler ProfileID and ProfileSecureFlightDocKey and the UR is finalized, the UR displays the ProfileID and ProfileSecureFlightDocKey that is associated to SSR DOCS/DOCO/DOCA.

Errors and Warnings

If ProfileID and ProfileSecureFlightDocKey are present in SSRs other than DOCO/DOCA/DOCS, Universal API returns an error: "Profile ID and ProfileSecureFlightDocKey only valid for SSR DOCA/DOCO/DOCS".

Universal API validates the Traveler Profile ID (BookingTraveler/AppliedProfile/@TravelerID) against the Universal Record and the Air Booking request that is being sent. If there is no match, an error is returned: "Profile ID specified in SSR is not present in Booking traveler(s) in request or Universal Record"

Both ProfileID and ProfileSecureFlightDocKey must be sent in the request or an error is returned: "Profile ID or ProfileSecureFlightDocKey must be accompanied with each other for Secure Flight SSRs".

Response

UniversalRecordModifyRsp is returned with the modified UR information in the UniversalRecord.

AirSegmentSellFailureInfo indicates the presence of failed Air segments in a partially failed PNR that also contains a least one successfully booked Air segment. If all requested Air segments fail, then only an error is returned because no PNR is created.
ARNK (Arrival Unknown) segments are added to the host PNR automatically wherever required, particularly for continuity breaks with the provider PNR. ARNK (Arrival Unknown) segments that are present in Galileo and Apollo provider PNRs are included in the response in the ProviderARNKSegment, to allow agents to view the exact provider PNR composition.
If the Universal Record was imported and that PNR's owning PCC did not exist in Universal API, a dynamic target branch was automatically created for that PCC. The dynamic target branch information displays in UniversalRecord/AgencyInfo/AgentAction. For more information about how the dynamic target branch is created, see Importing PNRs.
@ProfileID and @ProfileSecureFlightDocKey can be included in the request to delete a DOCO, DOCA, or DOCS SSRs (Special Service Requests).
The applied residency type returns in booking and ticketing retrieve responses, so that the nationality from the applied residency type by passenger line or data can be applied in a future exchange. This is useful because of taxes based on nationality. For example, Mexico has a tax for foreigners and Argentina has two taxes for residents. Release 23.1AirSolutionsChangedInfo/AirPricingSolution/AirPricingInfo/PassengerType @ResidencyType
OptionalServicesTotal returns sums for Optional Services in the Approximate Base Price, Approximate Total Price, Total Price, and Taxes when available, in Universal v29.0 and greater.

Universal API returns the total for the Optional Services, including taxes.
For ATPCO-filed Optional Services, the total of all Optional Services is added by Universal API and returned in OptionalServicesTotal.
When ACH LCC and API carrier Optional Services are returned from multiple carriers and the currency codes are the same, Universal API returns BasePrice, Taxes, Fees, and TotalPrice in OptionalServices/OptionalServicesTotal.
When ACH LCC and API carrier Optional Services are returned from multiple carriers and the currency codes are the different, Universal API does not return BasePrice, Taxes, or TotalPrice in OptionalServices/OptionalServicesTotal. Instead, the ApproximateTotalPrice and ApproximateBasePrice are returned in OptionalServicesTotal based on the default currency code of the TargetBranch (WAB).
If Optional Services are returned from multiple providers in the response, Universal API returns OptionalServices/OptionalServicesTotal with the combined price.
If Optional Services are returned from multiple providers in the response and the currency codes are different, the ApproximateTotalPrice and ApproximateBasePrice are returned in OptionalServicesTotal based on the default currency code of the TargetBranch (WAB).

Errors

More structured warnings and errors are available if any or all of the commands fail in a Universal Modify request. Errors and warnings are mapped to the respective commands in the UniversalRecordModify request where some of the commands resulted in errors and warnings. This mapping is especially helpful when batch Universal Record modifications are made in a single request. When keys are specified in the request at UniversalRecordModifyCmd @Key, errors and warnings in the response are mapped to the key provided in the request. If all of the commands in the UniversalRecordModify request fail, structured error messages are returned in the SOAP Fault response.