Creating Passive Segments

In some cases, passive segments are automatically created by Universal API as a response to specific events. However, passive segments can also be created and populated by a create request.

Passive segments can be "manually" created to store data for a third-party reservation that was booked and lives outside of Universal API through an SDK segment.

Schema

See the Passive Booking transactions in Passive.xsd:

How To

Passive Segments (particularly Air, Car, Hotel and Surface) are included for Continuity Check within the Universal Record. A Continuity Error is returned if the Passive Segments that are sold have discontinuity with each other or existing segments and the ContinuityCheckOverrideRemark attribute is not sent in the Universal API request. Air Passive Segments are considered at par with active air segments, Hotel Passives with active hotel, and so on for the continuity validation. ARNK segments are added for Air Passives and are similar to active air segments. If the override remark is added, any continuity breaks are returned as warnings.

  1. Create a passive segment is created using PassiveCreateReservationReq.

  2. Include the information required for the request. PassiveSegment@SegmentType identifies the type of passive segment being created.

    The minimum data required to create a passive air segment is:

    • SegmentType, set to 'Air'

    • Vendor

    • FlightNum

    • ClassOfService

    • StartDate

    • Origin

    • Destination

    • Status

    • NumberOfItems

    The minimum data required to create passive car, hotel, surface, tour, and other travel segments is:

    • SegmentType, set to any travel segment value, except 'Air'

    • Vendor
    • FlightNum
    • ClassOfService
    • StartDate
    • EndDate, required for hotel segments, optional for other segment types
    • CarType, required for vehicle segments only.
    • Origin (City)
    • Status
    • NumberOfItems
    • AmountPaidDue. If the 'Text' enumeration is indicated for the AmountPaidDue Type, then the segment is typically a retention segment.

  3. Optional data can be included to further define the passive segment.

    • Destination
    • City
    • Amount
    • Review booking
    • Passive Remark Type and Text. As an example, a user may put "CF" as a PropAddrInd and the Text would be the confirmation number (for Air or Hotel, etc).
    • Status
    • RuleName. Universal API supports attaching a mandatory Custom Check rule when a request to create a reservation has a Custom Check rule name, using the RuleName attribute. RuleName supports up to 10 alphanumeric characters (no special characters) and the attachment of a Custom Check rule name in the booking request. If Custom Check rule is attached to a reservation, the rule is captured in the Universal Record History.

      • Note: The user must know the name of the rule to attach to the booking.

      See Creating Air Bookings, Creating Hotel Bookings, and Creating Vehicle Bookings for details.

    • Emulation using OverridePCC

      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.

    • RetrieveProviderReservationDetails

      RetrieveProviderReservationDetails is a Boolean attribute.

      • When set to false (default), the response displays provider details using UniversalRecord/ProviderReservationInfo/ProviderReservationDetails.
      • When set to true, ProviderReservationDisplayDetailsList displays in the response in UniversalRecord/ProviderReservationInfo. This element displays some details of the PNR elements that are not otherwise returned in the Universal Record.

      Universal versions prior to v29.0 will not return the ProviderReservationDisplayDetailsList element.

    • Passive Remarks may be sent in the request when a Passive Segment is created. When a request is sent to the Apollo (1V) provider only, special characters are included in the Passive Remark. ^(caret), &(ampersand), and <(Less Than) are removed because they return an error or need special handling.

      Note: No other providers support this enhancement. All other providers continue to remove special characters in Passive Remarks when a passive reservation is created or modified.

      Universal API does not perform any validation of special characters, and if the provider returns an error for any special character, it is include in the Universal API response.

      Service Information (SI) Remarks typically contain information such as cancellation references in Galileo (1G) and Apollo (1V).

      SI Remarks are supported for passive bookings for hotel segment types from Universal API to the provider. To support SI Remarks in PassiveCreateReservationReq:

      • PassiveSegment @SegmentType must be set to "HTL".
      • PassiveRemark/Type must contain the value "SI".
      • PassiveRemark/Text must contain a free-text remark.

      Notes:

      • In Galileo and Apollo, SI Remarks are supported for both hotel segments and vehicle segments. However, in Universal API, SI Remarks are supported only for passive hotel bookings, and are not currently supported for passive vehicle bookings (SegmentType="CAR").
      • SI Remarks are not supported for passive bookings in Worldspan (1P).

    • SSRs (Special Service Requests)

      @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.

      See the response for more details.

    • Book on Book

      Air, hotel, vehicle, and passive Book on Book is allowed to append itinerary content in the same provider PNR if the PNR's owning PCC has a host bridge branch relationship with the Override PCC or PCC of the Target Branch in the request. The emulating PCC and owning PCC must have host bridge branch relationship so that the PNR can be retrieved and can be modified in the host.

      Book on Book for a Passive Create Reservation request is allowed with host Provider Locator Code and Universal Record Locator Code.

    • AgentIDOverride

      AgentIDOverride in the request overrides any default agent sine placed in the PNR. This is a two-character alphanumeric code of the agent sine that should replace the default. The AgentOverride attribute is returned in the response, noted below in Provider Reservation Info. The agent sine cannot be updated after the PNR has been finalized.

  4. A basic Passive Reservation response includes the Universal Record, as well as the Passive Reservation information for this booking in the PassiveReservation element. Other information that may be returned includes the following.

    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.

    /ProviderReservationDetails @CustomCheck

    @CustomCheck is set to "true" if a PNR has a Custom Check attached in the Galileo or Apollo provider reservation that was imported via Universal API.

    The Custom Check rule name is returned in the detailed display of the Provider Reservation, or if it is not found, a message is returned: Custom Check not found.

    If creation of the background passive fails on the provider (for example, a RuleName is not attached to a PNR or there is non-compliance with an attached RuleName), a Universal Record is created successfully, with a provider locator of ACH or SDK, as appropriate.

    If a Pseudo City Code (PCC) has a mandatory Custom Check rule that was attached during reservation creation, and the attached rule is compliant, a background passive is successfully created on the Galileo or Apollo provider, and the reservation is also successfully created in Universal API.

    @AgentOverride

    If the request included the optional AgentIDOverride attribute, the AgentOverride attribute returns the agent sine used to override the default agent sine.

    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: 
    • PassiveCreateReservationRsp/UniversalRecord/BookingTraveler/SSR @ProfileSecureFlightDocKey
    • PassiveCreateReservationRsp/UniversalRecord/BookingTraveler/SSR @ProfileID
    • The Universal Record level:
    • PassiveCreateReservationRsp/UniversalRecord/SSR @ProfileSecureFlightDocKey
    • PassiveCreateReservationRsp/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.

    • 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".

    @TravelOrder in PassiveReservation/PassiveSegment is returned to indicate the position of each Passive Segment within the UniversalRecord.

    All passive Segment types are ordered within the itinerary by Start Date and then End Date, when applicable. Primarily, End Date is considered for Air and Rail segments. For others, currently, only the Start Date is considered. If the dates match, a priority is used at the UR level for sorting the segments.

    • PRIORITY_AIR = 0; // highest
    • PRIORITY_RAIL = 1;
    • PRIORITY_ARNK = 2;
    • PRIORITY_VEHICLE = 3;
    • PRIORITY_HOTEL = 4;
    • PRIORITY_PASSIVE = 5;

    The priority of passives segments is the same as the active counterparts. Within the same date, the passive segments of other segment types, such as Tour or Limousine, do not have a specific priority order hierarchy and can be placed in no particular order after considering the Date criteria.

    • Type set to 'Air'

    • Vendor

    • FlightNum  

    • ClassofService  

    • StartDate  

    • Origin  

    • Destination

    • Status  

    • NumberOfItems  

Exceptions

  • Passive Remarks cannot be added with an air segment request in Galileo, therefore, any Passive Remarks are converted to General Remarks.

  • There is no interactive Insurance passive segment in 1G. Segment Type can be “Insurance(SUR)”, “Tour” or “Surface” but the Supplier Code must be “ZN”

  • When the first 15 characters of a last name/first name combination match another last name/first name combination in the same PNR, the names are sent to the Galileo host in the booking request as a cluster of names, with an allowed cumulative total of 55 characters for first name, prefix, last name, and suffix.

    For example: A PNR with these two passengers:

    • Salomonowicz/Barbara
    • Salomonowicz/Bartholomew

    • Is clustered because the first 15 characters are the same: Salomonowicz/Ba

  • Galileo supports hotel passive segments with MK and BK status. See Passive Hotel Segments with MK or BK Status for details.
  • Apollo supports hotel passive segments with MK and BK status. See Passive Hotel Segments with MK or BK Status for details.
    • Worldspan does not support Review Bookings.
    • Worldspan only supports hotel passive segments with the MK status. Passive requests with the BK status are not processed.

    ACH does not support Review Bookings.

    • Air.xsd allows the creation of a passive segments for book and hold with ACH. To create background passive segments for Hold Bookings in an Air Booking, send AirCreateReservationReq @CreatePassiveForHold as "true."
    • If the provider does not support Hold Bookings, a warning is returned: CreatePassiveForHold is not applicable for this provider.
    • If a FormOfPayment value is also present in the AirCreateReservationReq to pay for and confirm a hold booking, Universal API:
      • Ignores @CreatePassiveForHold, processes the booking request as usual, and returns a warning: CreatePassiveForHold is not applicable when FormOfPayment is provided.
      • Continues to form a FOP/General remark that contains Form of Payment information for confirmed bookings.