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 Open Import/ Batch Update Offer Functionalityto 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,
...
[In the screenshot you can see Parent Offer Name 1, Parent Offer Name 2, Parent Offer Name 3
...
2. You can add Add the Offer Name and Offer code that you want for your Special/Promotions/offer
...
4. Policy (Hidden or Open) : Offer with policy hidden is accessible only through offer code while the one with open is accessible normally.
...
Policy (Hidden or Open) when your Offer is “New Import” but if it Existing [Already imported or configured] then needs to be Blank.
...
6. Arrival Date From-Arrival Date To, Book Date From-Book Date To you have to add for your Offer/Special.
The Arrival From and To is the dates, when a customer comes to that Location for use and the Book date from-To, means when the offer location book by the customer
...
7. Stay Duration means how many days and which days:
...
7. Stay Duration means how many days and which days[Mod, Tue, Wed, Thus, Fri, Sat, Sun] he comes to that location, As mentioned dates, you can add so Rates and Rentability configured as it is and stay duration [Weekend, week, midweek, etc]
...
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.
...
User should not be allowed to select a book date from less than the current date.
User should not be allowed to select a book date to less than the current date and also less than book date from.
User should be allowed to modify stay period only if there are no existing bookings for the existing period that user is dropping from the existing rule.
If a user is modifying any other fields like rate type, arrival weekdays etc. then the system should follow the behavior as described underPossible solution.
However we still need to handle scenarios like
...
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.
Issues currently:
...
Issues
...
Area
...
Impact
...
- When using Offer import, the system is never blocking rentability and only adding new rule of rentability which can be an issue
...
- When adding additions, the additions are never added or removed, which can create a huge issue
...
- Indexing issue
...
- Extension of stay - Feature flag
This will also make it easy for the users to block the offer for specific accommodations as now only record per accommodation is visible.
Observations and testing results:
A) Creating new offer using new offer flow OR via offer import template
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 |
| |
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 |
| |
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. | |
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 | ||
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 | ||
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 | |||||
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 | |||
B. Updating details in already created offer.