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

4. 

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

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.