When implementing this mutation, be sure to calculate to full supplier amount for each day in the reservation, even if only a subset of the stay dates’ amounts is modified. For each date in a stay, the rate must be sent using the RECONCILED_AMOUNT supplier fee type enumeration, which indicates the commissionable value for each stay date. If taxes and fees are set up to be commissionable, partners must include these as well in the daily rate calculations.
Here are the validation rules that determine if a reservation can be reconciled:
Only Hotel Collect reservations can be reconciled.
Check-in dates should be the current date and/or in the past.
Reservations can be reconciled from the check-in date until the fourth day of the month after the checkout date (you cannot reconcile future reservations). For example, if a guest checks out on March 2nd, the partner can reconcile the reservation until April 4th. If you do not reconcile the reservation on time, the invoice includes the booked amount.
Amounts for dates included in the original reservation cannot be modified to a value of three times above the actual amounts applicable to that date (for additional dates, there is no limit).
Up to three days can be added before the original check-in date or up to three days after the original checkout date.
Updated checkout date. When specifying this date, be aware that a reservation
cannot be reconciled if its checkout date was before the first day of the
previous month, the first of the current month, or the reservation check-in date.
Partner's transaction ID that uniquely identifies the request, which can be
used to associate requests and responses for troubleshooting purposes. This ID
must be unique across requests and cannot be reused. However, if a request
needs to be retried, such as because it failed or timed out, the ID provided
in the original request should be used. The ID can be in any format as long as
it uniquely identifies the request.
Partner's transaction ID that identifies the request, which can be used to
correlate with partner's transaction logs. This ID must be unique across
requests and cannot be reused.
The traveler's Expedia Group VIP Access loyalty tier. These reservations often
include value add promotions (VAPs), therefore it is important to associate
this field and reservation:valueAddedPromotions in your systems so that
end-users can properly identify loyal travelers and loyalty perks that the
traveler is expecting. Values include MEMBER, VIP, PREMIUMVIP, and null. You
must include this field to complete certification.
Details about the frequent traveler reward program. This field identifies if
the traveler is a member of the supplier's loyalty program to ensure the
supplier is able to greet the guest accordingly and award loyalty points as needed.
The ID scalar type represents a unique identifier, often used to refetch an object or as key for a cache. The ID type appears in a JSON response as a String; however, it is not intended to be human-readable. When expected as an input type, any string (such as "4") or integer (such as 4) input value will be accepted as an ID.
Reason why the reservation cannot be reconciled. Values include the following:
GUEST_REQUESTED_CANCEL - Traveler cancelled the reservation
NO_SHOW - Traveler was a no-show
MODIFY_DATES_AMOUNTS - There was a difference in the booking price when the
lodging partner charged the traveler (for example, because an extra night was
added at the time of stay)
Reason why the reservation can be reconciled. Values include the following:
GUEST_REQUESTED_CANCEL - Traveler cancelled the reservation
NO_SHOW - Traveler was a no-show
MODIFY_DATES_AMOUNTS - There was a difference in the booking price when the
lodging partner charged the traveler (for example, because an extra night was
added at the time of stay)
Timestamp of when the reservation was created (format: yyyy-mm-ddThh:mm:ssTZD,
where TZD is a time zone designator in the form +/-hh:mm). Compare this value
to that of lastUpdatedDateTime to determine if a reservation has been modified.
ID of message thread (conversation) associated with the reservation. This
requires implementation and certification of the messaging capability. If no
message threads exist for a reservation, null is returned.
ID of the rate/rate plan and the source of the ID. In the response, when
idSource is set to SUPPLIER, the id field returns the same value as
returned by the existing booking APIs. However, for Hotel Collect properties,
the A- prefix is no longer added to the source value and the A suffix is no
longer appended to the rate ID as was done by the booking APIs.
Source of the reservation. Refer to Booking sources
for the list of possible values (though \"A-\" is not included in Hotel
Collect sources returned by this API).
Value add promotion(s) used to book the reservation, which are additional
benefits that travelers receive based on loyalty tier status, chosen property,
and room type or rate plan they book. If a value add promotion was not used,
an empty array is returned. We strongly recommend that you include this field
in your implementation to ensure traveler-promised perks can be properly
fulfilled by suppliers.
The String scalar type represents textual data, represented as UTF-8 character sequences. The String type is most often used by GraphQL to represent free-form human-readable text.
Nightly rate with no additional taxes, fees, or surcharges.
EXTRA_GUEST_FEES
Fees that are included in the price that guests see when booking. They are
paid in advance for Expedia Collect reservations or upon arrival for Hotel
Collect reservations.
SERVICE_FEES
Fees that only apply to guests who make use of specific facilities or
services, such as resort fees, parking fees, or fees for rollaway beds.
RECONCILED_AMOUNT
Updated rate, which must be the commissionable value for the stay date.
Amounts for dates included in the original reservation cannot be modified to a
value of three times more than the commissionable rate applicable to that date.
SupplierLoyaltyPlanInfo
Object
Details about the frequent traveler reward program. This field identifies if the
traveler is a member of the supplier's loyalty program to ensure the supplier is
able to greet the guest accordingly and award loyalty points as needed.
Updated rates for an existing stay date. Make sure the stay dates (fromDate
and toDate) are specified for every reconciliation amount (rateItems), and
the fromDate and toDate cannot overlap. The date ranges must match the
check-in and checkout date window (in ChangeReservationReconciliationInput).
Field
Description
fromDate
Not nullable.
Date (inclusive) when the rate becomes effective (format: YYYY-MM-DD). Make sure this date does not overlap toDate.
changeReservationReconciliation mutation