Questions about first OfferRule element
43 views
Skip to first unread message
Tech YA
Dec 4, 2018, 8:55:07 AM12/4/18
to alpin...@googlegroups.com
Hi everybody,
We came up with a couple of questions while studying the price calculation chapter of version 2018-10 (4.5.2) and the whole "new" RatePlan system (we skipped version 2017-10 so for us is still new).
We would like to hear from you if our interpretations are correct and if are consistent with yours.
1) The mandatory first OfferRule element, among other things, may contain some of the "classic" booking rules (ArrivalDOW, DepartureDOW, minLOS and maxLOS) when the corresponding capability is given, and they apply to the whole RatePlan.
About this OfferRule element there is the statement "All the restrictions that are defined in this element must be fulfilled by a stay in order to make the rate plan bookable."
Which priority and/or restriction exist between these booking rules and the usual BookingRules elements?
Our interpretation:
Since in the calculation algorythm the OfferRule is checked at step 1b while the usual BookingRules are checked at step 4a, this should force the usual BookingRules to exist only if more restrictive.
2) The AdditionalGuestAmounts regarding children (AgeQualifyingCode="8") must have at least one of the attributes MinAge or MaxAge.
About the AdditionalGuestAmounts there is the statement "All the Rate elements in a Rateplan must be consistent with the "brackets" defined in the first OfferRule element, it is a client responsibility to ensure this."
In the mandatory first OfferRule, the children-Occupancy element, when present, might have MinAge and/or MaxAge attributes... but they are not mandatory, so it can also have none.
When this case occurs (that means that the RatePlan allows children of any age < adult threshold), how can the children-AdditionalGuestAmount elements be consistent?
Our interpretation:
The only two possible consistent AdditionalGuestAmount would be with MinAge = 0 or MaxAge = adult threshold, as they would be in the case in which such attributes existed in the corresponding Occupancy.
3) Based on the previous point, I consider the two following cases:
- the OfferRule forces all guests to be treated as adults (adult-Occupancy with no MinAge attribute)
- the OfferRule prohibits the RatePlan to be sold in presence of children (adult-Occupancy with MinAge attribute but no children-Occupancy)
Do these cases imply the same AdditionalGuestAmount configuration (= one AdditionalGuestAmount element for adult and no one for children) in order to be consistent?
Our interpretation:
Yes. In both cases I won't need any price for children, even if for different reasons as specified by the first OfferRule.
I'm sorry if for some of you these questions may seem obvious but we wanted to be sure to act as the other AlpineBits implementers.
Thank you in advance for your answers.
Francesco Vovk
XLbit snc
via Marconi, 4 - 34133 Trieste
tel: 040 3728958
We came up with a couple of questions while studying the price calculation chapter of version 2018-10 (4.5.2) and the whole "new" RatePlan system (we skipped version 2017-10 so for us is still new).
We would like to hear from you if our interpretations are correct and if are consistent with yours.
1) The mandatory first OfferRule element, among other things, may contain some of the "classic" booking rules (ArrivalDOW, DepartureDOW, minLOS and maxLOS) when the corresponding capability is given, and they apply to the whole RatePlan.
About this OfferRule element there is the statement "All the restrictions that are defined in this element must be fulfilled by a stay in order to make the rate plan bookable."
Which priority and/or restriction exist between these booking rules and the usual BookingRules elements?
Our interpretation:
Since in the calculation algorythm the OfferRule is checked at step 1b while the usual BookingRules are checked at step 4a, this should force the usual BookingRules to exist only if more restrictive.
2) The AdditionalGuestAmounts regarding children (AgeQualifyingCode="8") must have at least one of the attributes MinAge or MaxAge.
About the AdditionalGuestAmounts there is the statement "All the Rate elements in a Rateplan must be consistent with the "brackets" defined in the first OfferRule element, it is a client responsibility to ensure this."
In the mandatory first OfferRule, the children-Occupancy element, when present, might have MinAge and/or MaxAge attributes... but they are not mandatory, so it can also have none.
When this case occurs (that means that the RatePlan allows children of any age < adult threshold), how can the children-AdditionalGuestAmount elements be consistent?
Our interpretation:
The only two possible consistent AdditionalGuestAmount would be with MinAge = 0 or MaxAge = adult threshold, as they would be in the case in which such attributes existed in the corresponding Occupancy.
3) Based on the previous point, I consider the two following cases:
- the OfferRule forces all guests to be treated as adults (adult-Occupancy with no MinAge attribute)
- the OfferRule prohibits the RatePlan to be sold in presence of children (adult-Occupancy with MinAge attribute but no children-Occupancy)
Do these cases imply the same AdditionalGuestAmount configuration (= one AdditionalGuestAmount element for adult and no one for children) in order to be consistent?
Our interpretation:
Yes. In both cases I won't need any price for children, even if for different reasons as specified by the first OfferRule.
I'm sorry if for some of you these questions may seem obvious but we wanted to be sure to act as the other AlpineBits implementers.
Thank you in advance for your answers.
Francesco Vovk
XLbit snc
via Marconi, 4 - 34133 Trieste
tel: 040 3728958
Luca Rainone
Dec 5, 2018, 9:31:37 AM12/5/18
to AlpineBits
Hello Francesco,
> 1) [...] Since in the calculation algorythm the OfferRule is checked at step 1b while the usual BookingRules are checked at step 4a, this should force the usual BookingRules to exist only if more restrictive.
We, as server, do not perform any check in this order. Simply if there are two or more disjointed restriction rules, the rateplan is accepted but it will never be fulfilled (=> empty intersection).
> 2) [...] When this case occurs (that means that the RatePlan allows children of any age < adult threshold), how can the children-AdditionalGuestAmount elements be consistent?
We considered the word "consistent" as synonym of "coherent". So these fields may not be strictly equal but they shoul mean the same thing.
Therefore your final interpretation is equals to the ours.
> 3) Based on the previous point, I consider the two following cases:
> - the OfferRule forces all guests to be treated as adults (adult-Occupancy with no MinAge attribute)
> - the OfferRule prohibits the RatePlan to be sold in presence of children (adult-Occupancy with MinAge attribute but no children-Occupancy)
>
> Do these cases imply the same AdditionalGuestAmount configuration (= one AdditionalGuestAmount element for adult and no one for children) in order > to be consistent?
Yes. A direct consequence is that if the MinAge is not specified then is not possible to define children ages (therefore is not possible to define children prices).
Luca
Tech YA
Dec 13, 2018, 11:52:44 AM12/13/18
to alpin...@googlegroups.com
Thank you, Luca, for your reply. It helped
evaluating the mentioned cases.
I have another question for which I won't open a new discussion since it's always related to price calculation.
The documentation specifies that "It is never necessary to perform permutations or recursion to find an "optimized solution"." and "A stay is only possible if every night of the stay can be covered by a rate."
In the case of a rate plan for a limited time offer, if a stay is given across the end of such offer, it would fall in the case of the second sentence since not every night of the stay fits in the offer.
In this case is it possible to split the stay in two parts, one that ends the same day as the offer and the second with the remaining nights (which might fall in another rate plan)? This would be an "optimized solution" mentioned in the first sentence but I understand it is not forbidden nor discouraged. Am I right?
The same can be applied for specific booking rules.
For example if a rate plan is only for one-week-stays and a stay counts 10 nights, I might give a price for the first 7 nights with that rate plan and the remaining 3 with another one.
Thank you in advance for your replies.
I have another question for which I won't open a new discussion since it's always related to price calculation.
The documentation specifies that "It is never necessary to perform permutations or recursion to find an "optimized solution"." and "A stay is only possible if every night of the stay can be covered by a rate."
In the case of a rate plan for a limited time offer, if a stay is given across the end of such offer, it would fall in the case of the second sentence since not every night of the stay fits in the offer.
In this case is it possible to split the stay in two parts, one that ends the same day as the offer and the second with the remaining nights (which might fall in another rate plan)? This would be an "optimized solution" mentioned in the first sentence but I understand it is not forbidden nor discouraged. Am I right?
The same can be applied for specific booking rules.
For example if a rate plan is only for one-week-stays and a stay counts 10 nights, I might give a price for the first 7 nights with that rate plan and the remaining 3 with another one.
Thank you in advance for your replies.
Francesco Vovk
XLbit snc
via Marconi, 4 - 34133 Trieste
tel: 040 3728958
Il 05/12/18 15:31, Luca Rainone ha
scritto:
--
You received this message because you are subscribed to the Google Groups "AlpineBits" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alpinebits+...@googlegroups.com.
To post to this group, send email to alpin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/alpinebits/08d4d5a9-a617-4c71-9eb2-644561937cb4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Stefano Seppi
Jan 17, 2019, 3:21:02 AM1/17/19
to AlpineBits
Hi Francesco,
we discussed this topic some time ago and the solution that we found for this problem is to use more roomStay to elaborate the offer.
KR
Stefano
To unsubscribe from this group and stop receiving emails from it, send an email to alpinebits+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages