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 |
For the same stay period, there are different prices for different stays like weekend, week and midweek. | Per price rule a rentability record will be generated resulting in multiple rentability rules for same period as it is not always possible to merge the weekdays in single rule. Hence splitting/merging/blocking logic based on periods is not supported | Overlapping or duplicate rentability rules allowed as no logic implemented. | Rentability for offers | Price engine and price indexing. Only one of the rentability condition is shown on websites and hence partial prices applied. | Functional bug | Consider all rentability rules. | CMS-22915 |
For the same stay period, there are different prices for different stays like weekend, week and midweek having same accommodations selected in price rule. | Based on the stay period selected in each price rule and the selected accommodations there will be accommodations linked to the offer for that period. | The same accommodation is linked multiple times to the offer for same/different period. | Linking of accommodation types to offer. | In price comparison multiple records are shown for each record resulting in too many options. Also the price is calculated only for partial period(addition period in that record) even if the discounted prices are available for complete stay of accommodation. | Functional bug |
| MXTS-36687 |
For the same stay period, there are different prices for different stays like weekend, week and midweek having same accommodations selected in price rule for different rate types. | Based on the stay period selected in each price rule and the selected accommodations there will be accommodations linked to the offer for that period. | The same accommodation is linked multiple times to the offer for same/different period. | Linking of accommodation types to offer. | In price comparison multiple records are shown for each record resulting in too many options. Also the price is calculated only for partial period(addition period in that record) even if the discounted prices are available for complete stay of accommodation. | Functional bug |
| MXTS-36687 |
Ferry tickets with offer : Tickets(addon) implied on offer. The rates in offer also allow additional discount on acc. prices,tickets etc. but for some partial periods. For remaining period there are 0 price rules created so that the offer is still available and ferry tickets can be provided at regular prices. | We do not allow creating rates with 0 value. | Ferry ticket is available only with discounted price and not with regular price. | Offer rates with 0 value | Not supported. | Functional limitation. | Allow to set up prices with 0 values. | Looking for an alternative. |
1-2 adults 10% discount on accommodation price , 3+ adults 15% discount on accommodation price | This was achieved in old system by setting up two rules. One for % and other for subject based. However in MXTS we allow only one type of price rules for offer. Hence not supported | Cannot be supported due to design limitation | Offer rates with different price type within same offer | Not supported | Design limitation/Usability issue | ||
1-2 adults accommodation price = x per night, 3+ adults accommodation price = y per night | This was achieved in old system by setting up two rules. One for % and other for subject based. However in MXTS we allow only one type of price rules for offer. Hence not supported | Cannot be supported due to design limitation | Offer rates with different price type within same offer | Not supported | Design limitation/Usability issue | ||
All weekdays selected in price rule but limit the booking via restrictions on weekdays in rentability | The rentability is generated based on price rules and hence such a rentability where the condition is different then the price rule cannot be achieved. However the user does have a option to
| The case depicts more of always having rates for rentability conditions however the implementation is more like always having rentability for defined rates. | Offer rentability and offer rates intentionally not in synch | Supported but requires manual handling | Usability issue | ||
Price rule applicable for all accommodations /specific accommodations | After selecting that the price rule is applicable for all accommodation still the user is prompted to select accommodations for which the offer is applicable. | Users find it difficult to understand which option to be selected even after adding descriptions. | Offer flow | Usability issue | Screen improvements needed for easy usability. | ||
Price rule applicable for all accommodations /specific accommodations | Only specific accommodations supported through import so not possible to create a price rule applicable for all accommodations. | Offer importing | Functionality limitation | ||||
Rentability toggle in flow | The rentability toggle in the flow is used to decide if the rentability should be generated or not for the corresponding price rules. | User finds it difficult to decide this per price rule. | Offer flow/importing | Usability issue | |||
Min/max LOS | Supported in offer flow but not in importing. User can define price rules 1-7 nights x per night and 8 night onwards y per night | It is a setting at price rule level and not offer level. Users sometimes miss this toggle and its functionality. Also they may not want to use it but is always a part of price creation flow. | Offer flow | Usability issue | |||
Min/Max deviation | Supported in offer flow but not in importing. User can define price rules 1-7 nights before arrival x per night and 8 night or more before arrival y per night | It is a setting at price rule level and not offer level. Users sometimes miss this toggle and its functionality.Also they may not want to use it but is always a part of price creation flow. | Offer flow | Usability issue | |||
Price type linked to offer | One offer can have only price type linked to it which means only those type of prices can be created for the offer. Once the price type is set it cannot be changed. | Users cannot use the same offer for combined price types. For instance they were giving % discount but hence forth would like to give a fixed amount discount. | Rates | Resusability of offer not possible | Design/usability issue | ||
Offer- Translation issue | While creating offer via import or manually we do not allow to enter the name per language. The system considers the name linked to the default language set. Once the offer is created user can go to the translation card and update the translations for different languages. | Names may get added under wrong language. | Translation | Usability issue due to functional limitation |
B. Updating details in already created offer: As per the current implementation, offer rates are considered as the driving factor for setting up rentability and linking the accommodation types. However the user still has the possibility to make modifications in rentability records and linked accommodation records without impacting the price rules.
...