Repository navigation
[16.0][ADD] pms: price a room type by its occupancy - #464
Open
jesusVMayor wants to merge 3 commits into
Open
jesusVMayor wants to merge 3 commits into
jesusVMayor wants to merge 3 commits into
Conversation
Rooms declared how many people fit, with no way to say how many of those places are for children only, such as child bunk beds. Children were meant to be counted through the reservation children_occupying, but nothing kept that field in sync with children and it was left empty, so children did not count towards the room capacity at all. Rooms get children_capacity now. capacity keeps its meaning, the places where anyone can sleep, and children take those first, overflowing into the children places only once they are full. Adults never occupy them, so a room with free children places can still be full for adults. Whether children take a place at all is up to the property, through the pms.children_occupy_capacity system parameter, and off unless it says otherwise: counting them refuses reservations that properties have been taking all along, so it cannot be something an upgrade decides for them. children_occupying is dropped. A reservation could declare an occupying child without counting it in children, so the migration folds it into children before the column goes away. Assisted-by: Claude Opus 5
The INE extra bed count subtracted the children occupying the room from the extra beds sold for that date. Nothing ever filled children_occupying in, so the subtraction always took zero, and the field is gone now. Assisted-by: Claude Opus 5
2 tasks
A pricelist gave a room type one price per night, whoever stayed in it. Selling a double for less when a single guest takes it, or charging for a third one, could only be done by hand on every reservation. Room types get the occupancy their rooms guarantee (max_occupancy, the smallest capacity among them, as any of them can be the one assigned) and the occupancy their price is given for (default_occupancy). A pricelist then carries, per room type, how much each guest above or below that default changes the price, as a percentage or as an amount. The modifier is linear, applying once per guest of difference, which is what channel managers derive from a default occupancy as well. A price asked for without an occupancy, or a room type with no modifiers, is the plain one of the pricelist, so this is transparent to everything pricing a room type without guests in hand. Changing the adults leaves the prices of the nights as they are, the same as changing the pricelist or the room type does: the form flags them as outdated, and updating them prices the nights for the adults staying. Nights added afterwards are priced for them already. A price is never rewritten behind the back of whoever wrote it, such as a channel manager writing what an OTA sold. The birthdate of the guests checking in never takes part in it: nobody reprices at the desk because a guest had a birthday.
jesusVMayor
force-pushed
the
16.0-add-occupancy-pricing
branch
from
October 21, 2026 10:33
f683146 to
7b3773f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Depends on #463 (children capacity in rooms), which this builds upon. Review
that one first; only the last commit belongs here.
A pricelist gave a room type one price per night, whoever stayed in it. Selling
a double for less when a single guest takes it, or charging for a third one,
could only be done by hand on every reservation.
What this does
Room types get two things: the occupancy their rooms guarantee (
max_occupancy,the smallest capacity among them, as any of them can be the one assigned) and
the occupancy their price is given for (
default_occupancy, which defaults tothe former and follows it down when a smaller room joins the type).
A pricelist then carries, per room type, how much each guest above or below that
default changes the price, as a percentage or as a fixed amount:
The modifier is linear, applying once per guest of difference, which is what
channel managers derive from a default occupancy as well.
It stays out of the way
The modifiers do not live in
product.pricelist.item, so neither the ruleresolution nor its ordering change: an item is still one price per pricelist,
room type and day. The price is derived afterwards, in a single place.
A price asked for without an occupancy, or a room type with no modifiers
configured, is the plain one of the pricelist. Everything that prices a room
type without guests in hand keeps working untouched.
Where it is wired
product.pricelist.item._compute_consumption_price()ends in_apply_occupancy_price(), which hands over topms.room.type. Reservationspass the adults staying through
pms.reservation.line._get_price_kwargs(), andthe booking engine lets you pick them per room type so the price shown is the
one you will pay.
Changing the adults leaves the prices of the nights as they are, the same as
changing the pricelist or the room type does: the form flags them as outdated,
and updating them prices the nights for the adults staying. Nights added
afterwards are priced for them already. A price is never rewritten behind the
back of whoever wrote it, such as a channel manager writing what an OTA sold.
The birthdate of the guests checking in never takes part in it: nobody reprices
at the desk because a guest had a birthday.