Depending on the OTA, generally, because of issues like this, I would suggest placing them in the OTA extranet directly for purchase and adding checks as part of daily received reservations checks to manually add the product internally and adjust rate accordingly. This is the workaround I have used rather than products natively pushing from MEWS.
Another method is mapping each package rate to a rate in MEWS that maps to OTA, and having MEWS then use product rules to remove accommodation to the value of the product, and add the one time only product, takes a bit of workaround and testing, but can be made to work. Essentially its telling mews to adjust the rate and add products etc based on the rate coming from the OTA
The issue with this is not MEWS specific, have encountered on multiple PMS systems due to the API with various OTAs. As a general rule I would say build the package in OTA rather than MEWS if sending one time products such as early check in and then use specific rates for these packages (if selling packaged) and handle with product rules in MEWS. If selling as add on products at end of checkout with OTA, use the route of reservation checks. If you have a specific example of a package and products, feel free to advise and I will rack my brains on a solution
Depending on the OTA, generally, because of issues like this, I would suggest placing them in the OTA extranet directly for purchase and adding checks as part of daily received reservations checks to manually add the product internally and adjust rate accordingly. This is the workaround I have used rather than products natively pushing from MEWS.
Another method is mapping each package rate to a rate in MEWS that maps to OTA, and having MEWS then use product rules to remove accommodation to the value of the product, and add the one time only product, takes a bit of workaround and testing, but can be made to work. Essentially its telling mews to adjust the rate and add products etc based on the rate coming from the OTA
The issue with this is not MEWS specific, have encountered on multiple PMS systems due to the API with various OTAs. As a general rule I would say build the package in OTA rather than MEWS if sending one time products such as early check in and then use specific rates for these packages (if selling packaged) and handle with product rules in MEWS. If selling as add on products at end of checkout with OTA, use the route of reservation checks. If you have a specific example of a package and products, feel free to advise and I will rack my brains on a solution
Hello @MattJones ,
Great input. Your second method (bolded) is quite similar to how we currently operate. Using product rules, we can get Mews to reduce the rate value and replace it with products - in other words, create an internal split.
However, what mainly restricts us is that prices cannot be set directly in the partner extranet, since our CRS - as mentioned - sends all or nothing. This means any prices entered manually in the extranet are overwritten by the data pushed from the CRS (natively from Mews).
Thinking about it, sending ONCE products from Mews might not be the right solution for us, as those products are only meant to apply to one of the nights. I'm not sure how either Mews or the CRS would recognize and distribute that data accurately.
At this point, I'm leaning more toward the idea that an enhancement in our CRS - allowing us to select which data points to send for a specific room/rate combination - is what’s actually needed.
Thanks again for your input!
