Pricing snapshots
A reservation remembers what it was quoted, so a later price change cannot rewrite it.
When a reservation is created, the price it was quoted is frozen onto the reservation itself. Changing a building's rent tomorrow does not change what an existing resident is billed, and does not change what their old invoices say they were billed.
This is not a caching optimisation. It is the reason a two-year-old invoice still reconciles.
Two snapshots, doing different jobs
The original price is written once, at booking, and never changes. It is the answer to "what did this resident agree to?" — the figure their contract was generated from.
The current price is a timeline: a list of periods, each with its own amounts and its own date range, the last of which runs open-ended. It is the answer to "what are they paying now?" Rent that steps up at year two, a utility change, a guest surcharge appearing when a co-occupant moves in — each is a new period on that timeline, not an edit to the old one.
Because the current price is a timeline rather than a value, you can always ask what someone was paying on a given date, and get the right answer for that date. Billing a past month re-reads the period that was in force then.
What a snapshot holds
Only the recurring monthly amounts live on the snapshot: base rent, utilities, building maintenance, the short-term surcharge, the guest surcharge, and any monthly fees your workspace has defined in the fee catalogue.
Workspace-defined monthly fees are stored self-describing — the label and the P&L category travel with the amount. That means a rent row can be written from the snapshot alone, without going back to the catalogue to ask what a code meant at the time. Rename or retire a fee and the historical rows still read correctly.
One-time amounts are not on the snapshot. The reservation fee and the security deposit are fields on the reservation itself, because they are collected once.
Discounts are snapshotted too
A discount is frozen alongside the price, including the minimum-stay condition that made the resident eligible. A resident who qualified keeps what they qualified for, even if the campaign later changes or ends.
The frozen quote
Workspaces running the fee catalogue in active mode also freeze the whole quote at booking: which rules produced each number, the season and length-of-stay rent plan that applied, and every workspace-defined fee line.
That is the audit trail. When someone asks in eight months why this resident pays what they pay, the quote answers it without anyone having to reconstruct what the catalogue looked like on the booking date.
What this means in practice
- Changing a fee rule never touches existing residents. If you intend to change what a current resident pays, that is a change to their reservation, not to the catalogue.
- Add a rule, do not edit one. Editing a rule that has already been quoted against rewrites what the past says it charged. See the fee catalogue.
- A resident's price looking "wrong" against the current catalogue is usually correct. Check when they booked before treating it as a defect.
Never repair a pricing problem by editing a snapshot to the number you want. The snapshot is what invoices, contracts and the ledger were all derived from; moving it silently desynchronises them from documents already sent. Correct the reservation's pricing through the proper amendment, which writes a new period and leaves the history intact.
See also Contract dates and The ledger.