Booking push functionality

[Stefano Seppi]

In order to reduce the number of empty requests in the next version of the standard it will be introduced the booking push functionality.

[Manfred Thaler]

Am Donnerstag, 8. Februar 2018 15:36:22 UTC+1 schrieb Stefano Seppi:

In order to reduce the number of empty requests in the next version of the standard it will be introduced the booking push functionality.

GuestRequests (PUSH)

Server Capability: action_OTA_HotelResNotif_GuestRequests

the server implements pushing quote requests, booking reservations and cancellations to the client

(GuestRequests PUSH)

Client Capability: action_OTA_HotelResNotif_GuestRequests

the client implements recieving quote requests, booking reservations and cancellations from server

(GuestRequests PUSH)

Action: OTA_HotelResNotif:GuestRequests

Request XML: OTA_HotelResNotifRQ

Response XML: OTA_HotelResNotifRS

The structure of the HotelReservation element in the exchanged messages remains the same as defined in the actual Alpinebits 2017-10 document. 

XML Request Samples:

GuestRequests-OTA_HotelResNotifRQ-reservation.xml

GuestRequests-OTA_HotelResNotifRQ-cancellation.xml

XML Response Samples:

GuestRequests-OTA_HotelResNotifRS-success.xml

GuestRequests-OTA_HotelResNotifRS-error.xml

 

[bert...@rateboard.io]

Hello everyone,

since "Booking PUSH" is also one of the most important messages for us, and is directly connected to our core business I wanted to add my 2 cents to this. I will most probably not be able to attend tomorrows Developer Meeting, so I would at least like to share my opinion here.

I will only focus on the content of the messages and ignore capabilities, handshaking, pub-sub, etc.


Cancellation
------------
I'm aware that in the current AlpineBits release we are using

<UniqueID Type="15" ID="abc..."/>

for cancellations. However, I think the intention of the OpenTravel Alliance here was to also give the cancellation its own ID. To me it seems more logical using

<UniqueID Type="14" ID="xyz..."/>

also for cancellations because Type 14 (Reservation) describes *which reservation* is about to be cancelled. We can still additionally also send UniqueID Type 15 (Cancellation) to remain backwards compatible because arbitrarily many UniqueID elements are allowed.


E.g.:

<OTA_HotelResNotifRQ>
<HotelReservations>
<HotelReservation CreateDateTime="2018-06-27T13:35:00+01:00" ResStatus="Cancelled">
<!-- This is cancellation abc123 and it cancels reservation xyz987. -->
<UniqueID Type="15" ID="abc123"/>
<UniqueID Type="14" ID="xyz987"/>
<!-- ... -->
</HotelReservation>
</HotelReservations>
</OTA_HotelResNotifRQ>


Reservation
-----------
Due to the fact that not only the PMS is a potential recipient of these messages (see Revenue Management Systems, CRM, Correspondence Managers, etc.) this will lead to new use cases that are not covered by the AlpineBits 2017-10 GuestRequests message. It is not only a guest request anymore but becomes a description of a guest's stay.

Two things that are very important to us in this context are room moves during stay, and rates.

* Room move during stay: if a guest is not staying in the same room during the whole stay also the connected systems should be informed by this because their internal processes may depend on this. This could be solved by using multiple <RoomStay>s but currently AlpineBits 2017-10 forbids multiple RoomStay elements with *different* TimeSpan elements (see section 4.2.2 page 25).

* Rates: the rates may vary depending on room type and date. AlpineBits 2017-10 allows for exactly one RatePlan and only the total amount of the room stay. For an RMS (and I assume also CRM etc.) it is important to have very precise information on what a guest pays for on a daily basis and how much.

Our proposal would be to allow for multiple RatePlan elements and additionally include RoomRates:

E.g.:

<OTA_HotelResNotifRQ>
<HotelReservations>
<HotelReservation CreateDateTime="2018-06-27T13:35:00+01:00" ResStatus="Reserved">
<!-- ... -->

<RoomStays>
<RoomStay MarketCode="Winter - Ski / Snowboard" SourceOfBusiness="RB - MICE (Incentives, usw.)">
<RoomTypes>
<RoomType IsRoom="true" RoomTypeCode="DZ" RoomID="210" NumberOfUnits="1"/>
</RoomTypes>
<RatePlans>
<!-- All used rate plans are listed. Full board on first day, B&B on the remaining two days. -->
<RatePlan RatePlanCode="FB" EffectiveDate="2017-12-16" ExpireDate="2017-12-17">
<​MealsIncluded​​ ​​MealPlanIndicator​="true"​ ​​MealPlanCodes​="10"/>
</RatePlan>
<RatePlan RatePlanCode="BB" EffectiveDate="2017-12-17" ExpireDate="2017-12-19">
<​MealsIncluded​​ ​​MealPlanIndicator​="true"​ ​​MealPlanCodes​="3"/>
</RatePlan>
</RatePlans>
<RoomRates>
<!-- List all amounts the stay includes. -->
<RoomRate RatePlanCode="FB" RoomTypeCode="DZ" RoomID="210" EffectiveDate="2017-12-16" ExpireDate="2017-12-17" NumberOfUnits="1">
<Rates>
<Rate RateTimeUnit="Day" EffectiveDate="2017-12-16" ExpireDate="2017-12-17" UnitMultiplier="1">
<Base AmountAfterTax="130.95" CurrencyCode="EUR"/>
<Total AmountAfterTax="130.95" CurrencyCode="EUR"/>
</Rate>
</Rates>
</RoomRate>
<RoomRate RatePlanCode="BB" RoomTypeCode="DZ" RoomID="210" EffectiveDate="2017-12-17" ExpireDate="2017-12-19" NumberOfUnits="1">
<Rates>
<Rate RateTimeUnit="Day" EffectiveDate="2017-12-17" ExpireDate="2017-12-19" UnitMultiplier="1">
<Base AmountAfterTax="73.95" CurrencyCode="EUR"/>
<Total AmountAfterTax="147.90" CurrencyCode="EUR"/>
</Rate>
</Rates>
</RoomRate>
</RoomRates>
</RoomStay>
</RoomStays>

<!-- ... -->

</HotelReservation>
</HotelReservations>
</OTA_HotelResNotifRQ>


Best,
Berthold