I am working on developing a booking system for a hotel using the Bryntum Scheduler. I have reviewed the demo you provided, and overall everything looks great.
However, I have a couple of questions regarding the implementation:
Defining Resource Time Ranges with Recurrence Rules:
When defining resourceTimeRanges, how can I structure them so that if a resourceTimeRange does not have a specific start and end date and is defined with a daily recurrenceRule, it applies to all days both in the past and future?
Scenario:
Each room has a base price.
On certain days, the price of a room changes, and a new price should be defined for those specific days.
Objective:
Ensure that if a user navigates to dates one or two years in the past, the room displays the base price.
The base price should apply by default, and only specific dates should override this with different pricing.
Handling Base Prices and Exception Dates:
If a base price is defined for a room and a new price is set for a specific day, but the exceptionDates do not include the base price, two prices are being displayed simultaneously.
Question:
How can I configure the Scheduler so that only the new price is shown for specific days without duplicating the base price when exceptionDates do not redefine it?
Any guidance or examples on how to achieve this setup would be greatly appreciated.
When defining resourceTimeRanges, how can I structure them so that if a resourceTimeRange does not have a specific start and end date and is defined with a daily recurrenceRule, it applies to all days both in the past and future?
Currently it is not possible to use recurrence rule without the startDate, you will have to set a start date. In your use case, maybe you can set the start few years ago and that will help you when a user navigates few years in the past. You will not need to set an end date. It will be taken care of by the rule.
How can I configure the Scheduler so that only the new price is shown for specific days without duplicating the base price when exceptionDates do not redefine it?
I do not understand this. Can you please elaborate a bit on this and if possible please let us reproduce this in our booking example then we will be able to provide better assistance.
Currently, I have defined a base price for each room. For example, the base price is set to €150. Additionally, for specific dates, I set a different price for the same room. Below is an example of my data structure:
Issue: When a specific date (e.g., "2024-12-03", "2024-12-04") is not included in the exceptionDates, the room price is displayed twice for that day: once with the base price of €150 and again with the new price of €200. This results in overlapping prices for the same date, which causes confusion and inconsistency in the booking system.
Question: How can I configure the Scheduler so that when a new price is set for a specific date, only the new price (€200) is displayed for that day without duplicating the base price (€150), especially when the exceptionDates do not redefine the base price?
Additional Details:
If the exceptionDates do not include the specific date, only the base price should apply.
It appears that defining exceptionDates alone is insufficient to prevent the base price from displaying alongside the new price. I may need to adjust how exceptionDates are defined or modify the data structure to ensure that the new price overrides the base price correctly.
I would greatly appreciate any further guidance or examples on how to properly configure the Scheduler to achieve this behavior. Specifically, if there are adjustments needed in the exceptionDates or the overall structure of resourceTimeRanges, please let me know.
Thank you once again for your assistance!
Attachments
Screenshot 2025-01-08 at 12.06.23.png (126.04 KiB) Viewed 283 times
I can see the issue in the attached screenshot but before moving forward and suggesting you something, can you please explain how you are setting the new price? Can you please list down the steps required to replicate this behaviour in the booking example? That will help us to understand what you are doing and how we can avoid this. We will really appreciate this.
Thank you for your prompt response and willingness to assist further.
1. Overview of the Issue
In my implementation, I have a base price set for each room, which displays correctly across all dates. However, when I set a new price for specific dates without defining those dates in exceptionDates, both the base price and the new price are displayed simultaneously for those specific dates. This results in duplicate price entries for the same day, causing confusion in the booking system.
2. Data Structure
Below is the JSON structure I am using to define the resourceTimeRanges:
3. Steps to Replicate the Issue in the Booking Example
To help you replicate the issue, here are the detailed steps I followed within the Bryntum Scheduler booking example:
Step 1: Define Resources (Rooms)
Resource ID: 1
Resource Name: Room 1
Step 2: Define Base Price for the Room
Navigate to the resourceTimeRanges configuration.
Add a new time range entry for the base price:
Step 3: Define New Price for Specific Dates Without exceptionDates
Add another time range entry for the specific dates with a new price:
id: 101
resourceId: 1
startDate: "2024-12-03"
duration: 1
durationUnit: "d"
pricePerNight: "200"
recurrenceRule: "FREQ=DAILY;COUNT=2" (Applies for two consecutive days starting from the start date)
Step 4: Implement the Configuration in the Scheduler
Ensure that both time range entries are correctly added to the Scheduler's configuration.
Load the Scheduler and navigate to the dates around "2024-12-03".
4. Observed Behavior
Without Defining exceptionDates:
For the dates "2024-12-03" and "2024-12-04", both the base price (€150) and the new price (€200) are displayed simultaneously.
This duplication occurs because the new price entries overlap with the base price, and without excluding these dates in exceptionDates, both prices are active.
After Adding exceptionDates:
If I add "2024-12-03" and "2024-12-04" to the exceptionDates of the base price, the duplication issue is resolved.
However, this approach is not feasible as it requires adding every specific date with a new price to the exceptionDates, which is impractical given the large number of dates that may require different pricing.
5. Expected Behavior
For All Dates Except "2024-12-03" and "2024-12-04":
The base price of €150 should be displayed.
For "2024-12-03" and "2024-12-04":
Only the new price of €200 should be displayed, overriding the base price.
6. Additional Details
Scheduler Version: Bryntum Scheduler Pro 6.1.5
Implementation Environment: React JS
7. Summary of the Problem
Base Price Configuration:
Applies daily starting from "2023-12-01" with a price of €150.
New Price Configuration Without exceptionDates:
Starts on "2024-12-03" with a price of €200.
Recurs daily for two days ("2024-12-03" and "2024-12-04").
Despite not defining exceptionDates, the new price entries overlap with the base price, resulting in both prices being displayed for the specified dates.
8. Request for Assistance
Could you please advise on the following:
How to Properly Override the Base Price with a New Price Without Using exceptionDates:
What is the correct way to configure resourceTimeRanges to ensure that the new price replaces the base price on specific dates without causing duplication?
Best Practices for Using recurrenceRule and Handling Price Overrides:
Are there any recommended practices or alternative approaches to manage pricing overrides effectively without the need to list all exception dates?
Any Required Adjustments in Data Structure:
Should I modify the existing data structure or introduce additional fields to prevent the duplication of prices when setting new prices for specific dates?
9. Conclusion
I hope this detailed explanation and the steps provided help in understanding the issue I'm facing. I am eager to implement a solution that ensures only the appropriate price is displayed for each date without any duplication, without the need to manage an extensive list of exceptionDates.
Thank you once again for your support and assistance. I look forward to your guidance on resolving this matter.
Hey thanks for sharing a detailed explanation. I am able to understand the problem and have further checked this with our team. But unfortunately there is no other solution exists then using exception dates. Because two resourceTimeRanges for the same date are going to be renderer. How can we decide which one we should skip - mean how can we now, which has new price. There's no way because this how recurrenceRule works. You will have to use exception dates to cater this issue.
Thank you for your prompt response and for discussing my issue with your team.
I understand that using exceptionDates is currently the only available solution to prevent duplicate price entries when setting new prices for specific dates. However, in my use case, there are a large number of dates that require different pricing, making it impractical to manually add each date to exceptionDates.
Given this limitation, I would like to explore the following possibilities:
Automated Management of exceptionDates:
Is there a way to programmatically manage exceptionDates based on defined new price entries? For instance, can the Scheduler automatically exclude dates when a new price is set, without manually listing each date?
Custom Rendering Logic:
Could I implement custom rendering logic to prioritize new price entries over base prices? For example, by modifying the rendering process to display only the highest priority price per date.
Feature Enhancement:
Are there any plans to introduce functionality that allows prioritizing resourceTimeRanges or automatically handling overrides without relying solely on exceptionDates?
Alternative Approaches:
Are there alternative approaches or best practices within Bryntum Scheduler that could help manage pricing overrides more efficiently for a large number of dates?
Implementing exceptionDates for a vast number of dates is not feasible for my project, and finding an efficient solution is crucial for the functionality and scalability of the booking system. Any guidance, workarounds, or recommendations you can provide would be greatly appreciated.
Thank you once again for your assistance and support. I look forward to your guidance on resolving this matter.
Our recommended way here would be to fix your data by using exception dates. But as you said earlier it will not be feasible for you to define the exception dates. And as far as your query is concerned about automating the exception dates process, we do not have support any such thing.
