This module allows the user to create different types of discounts that can be applicable during bookings.
...
Offer importing: This Functionality is useful to create/configuring multiple Offers/Specials through one Import File
Steps to be followed:
Rate Manager->Offer->Batch Update
...
Rate Manager->Offer->Batch Update->Download template->Import
...
After Downloading “Template” [Blank File]
...
Data
Information
In Datasheet you have to add/fill related all data in the Import file columns
Important Informations you have to follow as given in below when you add/fill data in the sheet
Orange Color Column - Mandatory fields and a must needed information
Blue color Column - Mandatory under certain conditions only
Green Color column - Non-mandatory but helpful to give more clear information
...
While creating the Special[Offer] Import file some important Information [Which data you have to add]
1. "The name of the location in which offer is configured or needs to be configured can be added in 1st column,
...
11. After all details adding you have to “Import” file
If all data is correct then it shows you Completed otherwise in any error in your file then it shows an Error/Failed and you can download the error file.
...
After that, you can check all details like Accommodation type[Additions], Rates, Rentability, DCs, etc added properly in all Resorts which is added in Import File
...
Here you all process related to Offer Import Functionality end.
...
Current behavior : The system will update the existing price rule with new values and the other existing rules that have overlapping conditions shall be split accordingly. Blocking of other existing rules will never happen. This option is actually used to replace the values in existing rules. The splitting happens only in cases like your existing price rule had a stay period of 1 jan to 30 Mar but while using the updating option you have requested to update a period of only 15 Jan to 30 Jan....
Expected behavior: the requirement is somewhat a combination of add and update feature that we currently have.
...
In such a case rentability generated cannot be combined as the arrival weekdays are different and could result in wrong end markers.
Impact: Some of the price rules are not considered in price indexing. Nilesh is already checking it. Rentability marker cache is skipping some rules.
Linking of accommodation types to offer (Additions): We are using the same logic as that for rentability auto generation to decide the stay dates selected while linking the accommodations to offer.
Bugs: Multiple price comparison options shown with partial periods even when the price rules are applicable for complete stay. Also blocking an accommodation type for offer gets uneasy for the user due to multiple rules for the same accommodation.
Expected behavior: Duplicate records from price comparison should be eliminated and offer should be applicable for complete stay if required conditions like prices etc are satisfied.
Possible solution : We will be revising the logic for auto linking accommodation types to offer. There will be only one record for each accommodation type linked to the offer without any kind of dates mentioned. We have already tested this and the above issues are solved.
...
Scenario details | Current behavior | Issues | Area | Impact | Category | Possible solution | Tickets linked |
|---|---|---|---|---|---|---|---|
Updating of value in rates via import/ rates card- by adding new rates. | Old rates will be blocked. New rates will be added. Rentability rules and accommodation type linking records will be generated even if already existing. | Duplicate rentability and linking of accommodation types observed. | Rentability | Readability of rentability and linked accommodation types is lost making it difficult for the user to maintain them further and take actions like blocking etc. | Functional bug | Consider all rentability rules.
| CMS-22915 |
Updating of value in rates via import/ rates card- by editing the existing rates. | The new information is updated in the same rule. | The existing bookings on recalculation will have the revised prices which may not be desired. | Existing Bookings | The existing rate should be blocked and a new rate should be created that is applicable from current instance. So the new rate will be applicable only for future bookings without having an impact on existing ones. | MXTS-33801 | ||
Modification in rentability parameters by editing the existing rule | No impact on rates. | This could give rise to situations where the price rule is no more valid as per the revised rentability. | Booking flow | User may start with the booking but end up with price error and not able to proceed ahead. | With every modification in rentability rule the system should check if there is a valid price rule meeting the new conditions. If not then a proper message should be shown and the user should be directed to the rates card to create rates with prepopulated fields such that user only needs to select rate type and value. | Too complex | |
Modification in rentability parameters by editing the existing rule | The new information is updated in the same rule. | The existing bookings may no longer be valid as per the revised conditions and can give issues during recalculation. | Existing Bookings | The existing rentability should be blocked and a new rate should be created that is applicable from current instance. So the new conditions will be applicable only for future bookings without having an impact on existing ones. | MXTS-33867 | ||
Removing linked accommodation type | No impact on rates and rentability. | The existing booking with the removed accommodation type may give issues during recalculation and may also create doubts how the offer was booked at first place if it was not applicable for the accommodation in the booking. | Existing bookings and also giving rise to misinterpretation by the users. | Could create confusions for the user. | Usability | Should be allowed to remove the linking only if there is no existing booking with the offer for the accommodation type. If a booking exists then a proper message mentioning the booking number should be shown. | MXTS-36692 |
Linking new accommodation type | No impact on rates and rentability | In case if a rate for all accommodation types or for the new added accommodation is missing then the offer will never be applicable | New Booking | Incomplete configuration resulting in offer not getting applicable | Usability | On linking a new accommodation type the system should check if there are future prices applicable for selected accommodation or atleast a rate applicable for all accommodations. If not a proper message should be shown directing the user to the rates card. | MXTS-36694 |
Blocking offer for specific accommodation: Changing validity period of already linked accommodation type | No impact on rates and rentability. Usage is somewhat tricky and risky | It works on stay date concept resulting in bookings getting impacted on recalculation. There is no proper way to block the offer for a specific accommodation | Linking acccommodation types/units | ||||
Clear view about expected results | A clear view is not available upfront about the resultant rentability or rates after addition of new rule or modifying existing rule. | User is not confident if the changes would result in expected results. Also making it unclear to them related to splitting/blocking logic. | Rates and rentability. | Usability issue. |
| Jira Premium plan | ||
|---|---|---|
|