Currently, in QloApps 1.7, "Extras" (like Breakfast) are treated as static products. This is not suitable for professional hotel operations where services must scale automatically based on the number of guests and the length of the stay.
Current Limitations:
Manual Quantity: If 2 guests book for 5 nights, the system does not automatically calculate 10 breakfasts. The guest has to manually select the quantity. If they select only 5, the hotel loses 50% of the revenue.
No Demographic Differentiation: There is no native way to set different prices for Adults, Children, and Babies within a single "Extra" service.
Revenue Loss: The current "Flat-rate" approach for extras leads to either customer dissatisfaction (due to manual corrections later) or financial loss for the hotel.
Requested Features:
- Occupancy-based Multiplier
Extras should have a configuration setting to define how the quantity is calculated:
Per Person / Per Night: (Guests × Nights = Total Quantity)
Per Room / Per Night: (1 × Nights = Total Quantity)
Per Person / Per Stay: (Guests × 1 = Total Quantity)
- Demographic Pricing (Age Tiers)
Allow the "Extra" to have different price points based on the guest type:
Adults: Full price.
Children: Reduced price (with adjustable age brackets, e.g., 3–12 years).
Babies: Free or nominal fee (e.g., 0–2 years).
- Integration with Tax Splitting (Ref: Previous Issue)
Following the tax rounding issue reported earlier, these occupancy-based extras must also support the complex tax split (e.g., German 70/30 split for Food/Drinks) to be legally compliant on invoices.
Use Case Example:
A guest books a room for 2 Adults and 1 Child (5 years old) for 3 nights.
The guest selects the "Breakfast" extra.
The system should automatically calculate:
(2 Adults × 3 Nights) = 6 Adult Breakfasts @ 10.00 €
(1 Child × 3 Nights) = 3 Child Breakfasts @ 5.00 €
Total: 75.00 € (instead of a manual entry of "1" or "3").
Impact:
This feature is essential for transforming QloApps from a basic booking engine into a professional Property Management System (PMS) capable of handling European legal and operational standards.
This issue is closely related to the rounding/tax issue reported here: #1675
#1675
Currently, in QloApps 1.7, "Extras" (like Breakfast) are treated as static products. This is not suitable for professional hotel operations where services must scale automatically based on the number of guests and the length of the stay.
Current Limitations:
Manual Quantity: If 2 guests book for 5 nights, the system does not automatically calculate 10 breakfasts. The guest has to manually select the quantity. If they select only 5, the hotel loses 50% of the revenue.
No Demographic Differentiation: There is no native way to set different prices for Adults, Children, and Babies within a single "Extra" service.
Revenue Loss: The current "Flat-rate" approach for extras leads to either customer dissatisfaction (due to manual corrections later) or financial loss for the hotel.
Requested Features:
Extras should have a configuration setting to define how the quantity is calculated:
Per Person / Per Night: (Guests × Nights = Total Quantity)
Per Room / Per Night: (1 × Nights = Total Quantity)
Per Person / Per Stay: (Guests × 1 = Total Quantity)
Allow the "Extra" to have different price points based on the guest type:
Adults: Full price.
Children: Reduced price (with adjustable age brackets, e.g., 3–12 years).
Babies: Free or nominal fee (e.g., 0–2 years).
Following the tax rounding issue reported earlier, these occupancy-based extras must also support the complex tax split (e.g., German 70/30 split for Food/Drinks) to be legally compliant on invoices.
Use Case Example:
A guest books a room for 2 Adults and 1 Child (5 years old) for 3 nights.
The guest selects the "Breakfast" extra.
The system should automatically calculate:
(2 Adults × 3 Nights) = 6 Adult Breakfasts @ 10.00 €
(1 Child × 3 Nights) = 3 Child Breakfasts @ 5.00 €
Total: 75.00 € (instead of a manual entry of "1" or "3").
Impact:
This feature is essential for transforming QloApps from a basic booking engine into a professional Property Management System (PMS) capable of handling European legal and operational standards.
This issue is closely related to the rounding/tax issue reported here: #1675
#1675