Offer Management

This module allows the user to create different types of discounts that can be applicable during bookings.

Necessary components for offer:

  1. Offer structure with general information

  2. Representation for offers

  3. Rates for offers

  4. Linking accommodations that are applicable for the offer.

  5. Rentability for offers.

Conceptual implementation: It is expected that users provide information related to 1,2 and 3. The system processes this information automatically and sets up all the components 1-5 in the system thus making the offer valid for booking. User does not need to give any additional information for 4 and 5. This will be taken care by the system based on the information provided in 1,2 and 3.

To achieve the above we are basically supporting three flows for creating offer.

Flow 1: Create offer only with general information like name, description etc.

In this flow it is expected that the user only mentions basic information related to point 1 and the offer gets created.

Once the offer is created it is the responsibility of the user to visit the required cards in offer and update the other required information (2 and 3).

Please refer the screens below to understand the flow.

User hits the ‘Create offer’ button.

It is a single page with a scroll bar using which the fields can be reached.

By default, the toggle shown in the above screen should remain off.

The button ‘Create offer’ is shown only if both toggles are off. On clicking the ‘Create offer’ button the offer should be created successfully, and the user should be directed directly to the newly created offer.

As the rates are not defined the price type field should not be shown in this case until the prices are defined.

The missing configurations that the user needs to complete should be highlighted.

 

Flow 2: Create offer with basic information and representation

On selecting the toggle for representation, the ‘Next step’ button and ‘previous step’ button are shown using which the user can navigate to the respective steps. Also a stepper is added at the top.

On clicking the ‘next step’ the user is directed to the next screen where the user can select the dc/dc group for the representation. This representation will be created without any rentability rules.

With the help of scroll bar, the user can navigate through the list of DC/DC groups. On clicking the ‘Create offer’ button the offer should be created successfully, and the user should be directed directly to the newly created offer.

As the rates are not defined the price type field should not be shown in this case until the prices are defined.

The missing configurations that the user needs to complete should be highlighted.

Flow 3: Create offer with basic information and representation and rates.

It should not be possible to select the rate toggle without selecting the representation toggle. The main reason for this is that we generate rentability conditions based on the conditions selected while defining rates. In order to add rentability we need a representation and hence this validation.

The date fields shown in above screen are applicable for all the rates defined in the section below it.

The ‘Rate type’ field is now added in price configuration section. This field should have the possibility to select all or multiple rate types.

The rate types shown in this field should be filtered out only on the basis of the dates selected.

 

On hitting the ‘Add’ button it should be possible to create multiple price rules with different criteria.

The already existing validations need to be maintained.

 

On hitting the ‘Create offer’ button all the 5 components for offer should be set up in the system.

 

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]

There are two options in the blank Import/sheet Options

  1. Data

  2. Information

  3. 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,

 

After that Parent Offer Name 1, Parent Offer Name 2, Parent Offer Name 3, etc,

[In the screenshot you can see Parent Offer Name 1, Parent Offer Name 2, Parent Offer Name 3

2. Add the Offer Name and Offer code that you want for your Special/Promotions/offer

3. Offer types means It is a General Type of Offer or Offers With Addon [Package]

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.

 

5. Location Code Of Accommodation, Parent Accommodation Code, Accommodation Type Code

When We add Location means In which Particular Resorts[Location] you want to Configured that Offer, after that option is Parent Accommodation Type means In which parent Type your bookable type is present/Available for booking[ Tahiti(tah)--> mobile home Tahiti (tahmob)] , Last is Accommodation Type means exactly which type you wanted to give a discount or book that offers/Special [mobile home Tahiti (tahmob)]

6. Arrival Date From-Arrival Date To, Book Date From-Book Date To :

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]

8. Select the Type of Rate, Rate, Rate Type Code, which is you want for the Special, Means Type of rate [New Price, Percentage, stay log pay less, etc] Fixed discount or
New price or percentage discount after that Rate[Price of offer], Rate Type code[eur, Doller[bar], rupees[inr], etc] which is base on Location country base.

 

9. At the time of importing the file, you can also Generate Rentability same as it is mentioned Dates select only the "Y" option.

Note:- If you want to change in Previous Configured or Import Offer then where you already inserted Rentability then for the again same period and offer you don’t need to add Rentability

or select Option of “Generate Rentability” or “Yes” just need that column Blank [Shows in below Screenshot]

FYI:- Already Configured or import offer and you want to change in anything like Rates for that Offer and you selected “Generate Rentability” option is “Yes” then the same Rentabilty is inserted without Blocking old Rentability because you already configured for the same offer with the same parameters.

 

10. Also you can add parent DC or Particular DC also for Offer, means for which channel through you want to book that offer like [internet, receipt, desk, 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.

You can search your Special/Offer after the Complete message shows in the import batch update offer [Search code, name, code of offer]

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.

 

Rentability generation logic: In case of offers, the rentability is autogenerated based on the information in the rates.

Example 1: The price rule details are as follows

Arrival date from - arrival date to : 1 Dec 2022 to 25 Dec 2022

Usage unit (Type of rate calculation) : Weekend

Arrival days of week : Fri

The corresponding rentability generated (Extended stay period)

Stay date from - 1 Dec 2022 Stay date to : 26 Dec

Stay date to = Last date valid in selected period as per arrival day of week.(In above case the last Fri is 23 Dec) + No of days as per usage unit (weekend =3)

 

**The corresponding rentability generated (Non-extended stay period)

Stay date from - 1 Dec 2022 Stay date to : 26 Dec

Stay date to = Last date valid in selected period as per arrival day of week.(In above case the last Fri is 23 Dec)

 

Rates modification logic: User is allowed to modify all information in the selected price rules and there is no validation to avoid its impact on current bookings. It is the users responsibility to take care of impacted bookings.

We also allow the user to select past stay dates and book dates.

Expected behavior (MXTS-33961)

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.

It is expected that a new price rule gets added in the system such that a few selected fields should have new values set while the remaining fields should have the values carried forwarded from the existing rules.

So we ideally dont update the existing rule with new values but instead create a new rule and replace values in some fields and carry forward values for other fields from existing ones and then add the rule and block existing overlapping ones.

Scenarios : All scenarios related to price rule editing supported in offers should be supported for all price types.

  1. Resource selection changes done in price rules (VS-2349)

  2. Subject selection changes done in price rules.

  3. X and Y values changed for x=y price type.

  4. Value changed for any of the above price rules.

Possible solution: On editing ,any of the fields of an existing price rule,

On editing ,any of the fields of an existing price rule,

  1. The system should check if the price rule is used in any of the bookings.

  2. If yes then block the existing price rule,with existing values, from current instant (book date to) and then create a new rule with new information(changed field) + other values for remaining fields from existing rule valid from current instant (book date from).

  3. If No then delete the existing price rule and create new rule, from current instant (book date from) OR in other words just update the same rule (current behavior)

Possible solution:

A) While adding new rate rules

  1. User should not be allowed to select a book date from less than the current date.

  2. User should not be allowed to select a book date to less than the current date and also less than book date from.

  3. User should not be allowed to select arrival date from less than current date.

  4. User should not be allowed to select arrival date to less than current date.

B) While editing existing rate rules

  1. User should not be allowed to select a book date from less than the current date.

  2. User should not be allowed to select a book date to less than the current date and also less than book date from.

  3. 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.

  4. If a user is modifying any other fields like rate type, arrival weekdays etc. then the system should follow the behavior as described under.

However we still need to handle scenarios like

a) moving bookings from one system to other.

b) moving bookings from one accommodation to other.

c) Do corrections in existing configurations of past and ready to manage existing bookings accordingly.

For such scenarios,

  1. A new permission ‘Allow adding or modifying rates for past period’ will be introduced.

  2. Users having such a permission will be able to add/modify existing rate rules there itself by selecting past dates. The current behavior as described earlier will be followed.

  3. However there will be a validation maintained to check if the price rule is getting used in any existing bookings and a message ‘“There are existing bookings that could be impacted on recalculation. Do you still want to proceed with changes?’” .If the user decides to proceed then the same rule will be updated and the user will be responsible for handling the required changes.

  4. The modifications done will remain valid as per the book dates selected in the existing rules. The system will not create new rules but update the existing rules itself.

  5. However if the new values set in price rules result in overlapping with other existing rules, then the new rule will be given high priority and the other overlapping rules shall be split/blocked accordingly. This is already the current behavior and shall be followed.

 

Rentability modification logic: Same as rates

Rentability splitting/blocking logic : There is no logic implemented for this and overlapping rentability rules are allowed. The main reason for this is the following scenario

Scenario details : for arrival days of 1 Dec to 25 Dec there are weekend (Fri -3) ,midweek(mon-4) and week (Sat -7)

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.

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

  1. Do not mention any period while linking accommodation types to offers and link only unique accommodation types.

  2. Revise the logic for price comparison and price calculation such that multiple records are supported.

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

  1. Do not mention any period while linking accommodation types to offers and link only unique accommodation types.

  2. Revise the logic for price comparison and price calculation such that multiple records are supported.

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

  1. Modify the rentability later. This will not do any modifications in price rule.

  2. to disable rentability generation and then can go and add rentability manually or via rentability template.

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.

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.

  1. Do not mention any period while linking accommodation types to offers and link only unique accommodation types.

  2. Revise the logic for price comparison and price calculation such that multiple records are supported.

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.