Suggests for future AlpineBits development
Stefano Seppi
yesal...@gmail.com
Issue:
Sometimes rates configurations can be quite complex and as a consequence their XML require thousands of BookingRule and Rate elements that would slow down their retrieval and their processing.
Part of these situations are due to a weekly recursion of data which AlpineBits forces to send day-by-day, most of the times for very long timespans.
Use cases:
- a B&B that offers different rates for working days and for weekends.
- a hotel that set different minLOS on different weekdays, e.g. to have arrivals on Mondays and Tuesdays only if their stays last until Sunday (or more extreme situations where every weekday has a different minLOS).
Solution:
Where this recursion is present and the client is able to detect it (because directly introduced by its data acquisition or because a pattern has been detected), the client can decide to send the data on a weekday basis instead of a day-by-day basis, thus reducing the number of needed XML elements.
BookingRules implementation proposal:
- use of the AvailableDaysOfWeek element contained in DOW_Restrictions:
Given that the ArrivalDayOfWeek and DepartureDayOfWeek restrictions are already referring to weekdays, the presence of the DOW_Restrictions element only containing the AvailableDaysOfWeek element implies that the other restrictions in the parent BookingRule are to be applied to every weekday set to true that is within the BookingRule timespan.
Example:
<BookingRule Start="2018-03-01" End="2018-05-31">
<DOW_Restrictions>
<AvailableDaysOfWeek Thur="1" Sat="1"/>
</DOW_Restrictions>
<LengthsOfStay>
<LengthOfStay Time="3" TimeUnit="Day" MinMaxMessageType="SetMinLOS"/>
<LengthOfStay Time="7" TimeUnit="Day" MinMaxMessageType="SetMaxLOS"/>
</LengthsOfStay>
</BookingRule>
In the given example the minLOS and maxLOS restrictions are applied only to Thursdays and Saturdays from March 1st to May 31st 2018.
Rate implementation proposal:
- use of attributes Mon, Tue, Weds, Thur, Fri, Sat and Sun contained in the Rate element:
The presence of such attributes set to true implies that the rate is to be applied only to the corresponding weekdays.
Example:
<Rate InvTypeCode="double" Start="2018-03-01" End="2018-05-31" Sat="1" Sun="1">
<BaseByGuestAmts>
<!-- ... -->
</BaseByGuestAmts>
<AdditionalGuestAmounts>
<!-- ... -->
</AdditionalGuestAmounts>
<MealsIncluded MealPlanIndicator="true" MealPlanCodes="12"/>
</Rate>
In the given example the rates are applied only to the weekends from March 1st to May 31st 2018.
For a client, sending recursive data this way can be optional but strongly recommended whenever possible. It is yet to discuss if a server should be forced to accept and process this format or if it is better to introduce a new capability.
-----------------------------------------------------------------------
Proposta: aggiunta di un'opzione per l'aggregazione settimanale dei dati delle tariffe.
Problema:
Alcune configurazioni di prezzi molto complesse possono comportare degli invii molto pesanti rendendo necessarie liste di migliaia di BookingRules o Rates.
In alcuni di questi casi il problema nasce da una ciclicità settimanale delle restrizioni che chi utilizza AlpineBits è costretto a trasmettere giorno per giorno, anche per periodi molto lunghi.
Casi di utilizzo:
- un B&B che ha per un'intera stagione una tariffa per i giorni infrasettimanali diversa da quella per i weekend
- un albergo che ha impostato minLOS diversi per giorni diversi della settimana, per esempio per avere arrivi il lunedì o il martedì solo se restano fino a domenica (fino a casi estremi in cui ogni giorno ha un minLOS diverso)
Soluzione:
Nei casi in cui tale ciclicità è presente e il client è in grado di rilevarla (o perché direttamente derivata da metodo di acquisizione dei dati o perché venga riconosciuto il pattern), il client può decidere di inviare i dati per giorno della settimana (lun, mar,...) anziché per ciascun giorno dell'intervallo riducendo i dati inviati.
Proposta di implementazione per le BookingRules:
- uso del tag AvailableDaysOfWeek contenuto in DOW_Restrictions:
Essendo scontata la ciclicità settimanale per le restriction ArrivalDayOfWeek e DepartureDayOfWeek, la presenza dell'elemento DOW_Restrictions con all'interno solamente il tag AvailableDaysOfWeek, implica il dover applicare le altre restriction della BookingRule ciclicamente ai soli giorni impostati a true.
Esempio:
<BookingRule Start="2018-03-01" End="2018-05-31">
<DOW_Restrictions>
<AvailableDaysOfWeek Thur="1" Sat="1"/>
</DOW_Restrictions>
<LengthsOfStay>
<LengthOfStay Time="3" TimeUnit="Day" MinMaxMessageType="SetMinLOS"/>
<LengthOfStay Time="7" TimeUnit="Day" MinMaxMessageType="SetMaxLOS"/>
</LengthsOfStay>
</BookingRule>
Nell'esempio, le restriction minLOS=3 e maxLOS=7, per i mesi di marzo, aprile e maggio, sono da applicare solamente ai giovedì e ai sabati.
Proposta di implementazione per i Rate:
- uso degli attributi Mon, Tue, Weds, Thur, Fri, Sat e Sun presenti nel tag Rate:
La presenza degli attributi impostati a true, implica che il Rate viene applicato solamente ai giorni corrispondenti.
Esempio:
<Rate InvTypeCode="double" Start="2018-03-01" End="2018-05-31" Sat="1" Sun="1">
<BaseByGuestAmts>
<!-- ... -->
</BaseByGuestAmts>
<AdditionalGuestAmounts>
<!-- ... -->
</AdditionalGuestAmounts>
<MealsIncluded MealPlanIndicator="true" MealPlanCodes="12"/>
</Rate>
Nell'esempio, i prezzi indicati nel rate sono da applicare solo per i sabati e le domeniche di marzo, aprile e maggio.
Per il client inviare i dati con questa impostazione è opzionale ma, dove possibile, altamente consigliato. Si può valutare se obbligare il server a gestire i dati che arrivano in questo formato oppure se inserire una capability per gestirne la compatibilità.
Francesco Vovk
YesAlps
XLbit snc
via Marconi, 4 - 34133 Trieste
tel: 040 3728958
Matteo Dalle Feste
Daniele Gobbetti - Peer GmbH/Srl
Hi everybody,
I've created this thread in order to collect suggestions about the development of the future versions of AlpineBits.
Those could be organized by a specific Hotel, or a Lodging Structure could simply "collect" Activities organized by other entities (e.g. TV) and make them available.
From a first brief look at the OTA-provided examples, I believe the "TourActivity" Element could be used.
Best regards,
Daniele
 |
Daniele Gobbetti Head of Development & Operations |
| Peer GmbH/Srl - www.peer.biz
Tel. +39 0471 631080 - Fax +39 0471 631724  |
Matteo Dalle Feste
<OTA_ReviewsRS xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.opentravel.org/OTA/2003/05"
xsi:schemaLocation="http://www.opentravel.org/OTA/2003/05 OTA_ReviewsRS.xsd"
Version="1.001">
<Success/>
<Reviews>
<!-- Foreach Review -->
<ReviewSubject>
<!-- Useful if we want to permit sending multiple hotel's reviews -->
<Hotel HotelCode="1492" HotelName="Hotel Eydos"/>
<!--
For each review - Optional
ReviewID="12345" Unique ID for each review
ResponseLanguageCode="it" Language of the review
AggregateRating="100" Value of the overall rating
ReviewerCompany="TripAdvxx" The company who send the review,
TripDuration="P3D" Duration of the vacation (ISO 8601)
-->
<Review ReviewID="12345" ResponseLanguageCode="it" AggregateRating="100" ReviewerCompany="TripAdvxx" ReviewDate="2018-12-24" TripDuration="P3D">
<!--
Specific info of the trip
TravelerType="Group" Identify numbers of traveller
TravelType="Business" Identify the nature of the travel, e.g. Busiless, Liesure..
Gender="Male" Genter: Male, Female, Unknow
AnonymousInd="false" Specify if the review must remain anonymous or not
-->
<ReviewerInfo TravelerType="Group" TravelType="Business" Gender="Male" AnonymousInd="false">
<!-- Name and mail of the reviewer - Optional but very interesting to give the possibility of associate image and trust of the reviewer. e.g.: Gravatar, white/banlist -->
<ReviewerName>
<Surname>Matteo</Surname>
</ReviewerName>
<ReviewerEmail>
<Email>mat...@xxx.it</Email>
</ReviewerEmail>
<!-- Useful? if we're interested about the nationality of the traveller - Optional -->
<ReviewerAddress>
<Address>
<County>Italy</County>
</Address>
</ReviewerAddress>
</ReviewerInfo>
<CategoryAggregations>
<!-- detailed review for services - Optional
QuestionCategoryRPH="123123" Identify a service reviewed e.g. rooms, cleaning room..
AggregateRating="10" The rating for the service reviewed
Is need to define a shared table? e.g. "22222"=Room, "55555"="Staff", "7777777"=Amenities
We could decide the range of the rating: e.g. 0-5 or 0-100. The 0-5range can be converted multiplying by 20 if we adopt the 0-100 range
-->
<CategoryAggregation QuestionCategoryRPH="22222" AggregateRating="10"/>
<CategoryAggregation QuestionCategoryRPH="55555" AggregateRating="10"/>
<CategoryAggregation QuestionCategoryRPH="7777777" AggregateRating="10"/>
</CategoryAggregations>
<!-- Optional -->
<MultimediaDescriptions>
<!-- Title of Review - Optional -->
<MultimediaDescription InfoCode="25">
<TextItems>
<TextItem>
<Description Language="it" TextFormat="PlainText">Super holiday!</Description>
</TextItem>
</TextItems>
</MultimediaDescription>
<!-- short Description of Review - Optional -->
<MultimediaDescription InfoCode="25">
<TextItems>
<TextItem>
<Description Language="it" TextFormat="PlainText">Comfortable bedroom with many amenities, professional staff!</Description>
</TextItem>
</TextItems>
</MultimediaDescription>
<!-- Image of Review - Optional -->
<MultimediaDescription InfoCode="23">
<ImageItems>
<!-- 20 means miscellaneous, see OTA table PIC -->
<ImageItem Category="20">
<ImageFormat CopyrightNotice="Name of Reviewer?">
<URL>http://www.sitewithimage.com/spaPoolvacation2017.jpg</URL>
</ImageFormat>
<Description TextFormat="PlainText" Language="en">My Bedroom</Description>
</ImageItem>
</ImageItems>
</MultimediaDescription>
</MultimediaDescriptions>
<!-- Reply of the Hotelier - Optional -->
<SupplierResponse>
<Text Language="it" TextFormat="PlainText">Thanks! It is a pleasure to satisfy our customers.</Text>
</SupplierResponse>
</Review>
</ReviewSubject>
</Reviews>
</OTA_ReviewsRS>
Matteo Dalle Feste
<OTA_ReviewsRS xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.opentravel.org/OTA/2003/05"
xsi:schemaLocation="http://www.opentravel.org/OTA/2003/05 OTA_ReviewsRS.xsd"
Version="1.001">
<Success/>
<Reviews>
<Questions>
<QuestionCategory>
<!--
Could be mapped a list of QuestionID corrisponding to a dedicated Alpinebits code list
E.g.
"001" = Overall,
"002" = Comfort
"003"
= Staff
"004" = Location
...
or we can use an existing Code list like Hotel Amenity Codes
-->
<Question QuestionID="001">
<Aggregations>
<Aggregation TravelerType="Leisure" AggregateRating="98" ReviewCount="10" />
</Aggregations>
</Question>
<Question QuestionID="002">
<Aggregations>
<Aggregation TravelerType="Business" AggregateRating="92" ReviewCount="5" />
</Aggregations>
</Question>
</QuestionCategory>
</Questions>
</Reviews>
</OTA_ReviewsRS>
Stephan P.
L'abbiamo già in uso con alcuni partner.
Invece ho dei dubbi sulla proposta per le BookingRules.
La documentazione OTA dell'elemento AvailableDaysOfWeek dice:
"Days of week on which this room/rate combination is available."
E ciò non corrisponde allo scopo per il quale lo vorremmo utilizzare.
Ciao
Stephan
Thomas Alber
Es gibt noch die Notwendigkeit die Stornobedingungen einzubringen. Hotels Verwenden vermehrt unterschiedliche Stornobedingungen für Ihre Zimmerkategorien und Saisonen. Somit kann AlpineBits gewährleisten, dass das Hotel die höchstmögliche Konsistenz auf all seinen Vertriebskanälen erhält. Es handelt sich hierbei um wichtige Daten für Buchungssysteme.
Stephan P.
Abbiamo dei casi dove MaxOccupancy è uguale a StandardOccupancy e MaxChildOccupancy è maggiore 0.
Ciò significa che bambini possono godere di un prezzo ridotto se il numero degli adulti è minore della StandardOccupancy (MinFullPayer = MaxOccupancy - MaxChildOccupancy). Attualmente però non funziona, perchè non possiamo trasmettere AdditionalGuestAmounts se MaxOccupancy non è maggiore di StandardOccupancy. Dovremmo quindi modificare le regole per la trasmissione delle AdditionalGuestAmounts.
Regola:
- MaxChildOccupancy > 0: AdditionalGuestAmount con AgeQualifyingCode ="8" sono sempre amessi.
Modificando le regole potremmo supportare anche un altro caso:
Letti aggiuntivi solamente per bamini (non per adulti).
Per supportare questo caso potremmo definire opzionale l'elemento AdditionalGuestAmount con AgeQualifyingCode ="10". L'assenza del prezzo per un letto aggiuntivo per adulti potrebbe essere interpretato come: letto aggiuntivo non disponibile per adulti (solamente per bambini).
Ciao
Stephan