You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A night is sold at several prices in the weeks before it, but we only know its average from total revenue ÷ rooms sold. We can't see when the rate was raised, or whether bookings kept coming afterwards.
Goal
For every booked night we know the rate plan and price the guest paid, so we can see how a night's price changed while it filled up.
Scope
A table with one row per booking per night: booking reference, stay date, rate plan code, price (nett).
A parser for Daily Rate Analysis (e.g. BAR_RO 242.19 split into rate plan and price).
Link each row to its booking from the bookings table.
Models, repository and services through every layer; idempotent upserts.
An Alembic migration that applies and rolls back.
Considerations
Check whether this report's prices are nett or gross and store nett.
Rows whose booking isn't in the bookings table (e.g. made before the export range) should still load and be flagged, not fail the file.
Acceptance criteria
A sample file loads, with rate plan and price split correctly.
Loading the same file twice doesn't add rows.
Each row can be joined to its booking where one exists.
Closing: decision 0037 dropped the Daily Rate Analysis report, so there's no per-booking-night price to store. #104 now trains on each booking's nett ADR from Daily New Reservations (#84) instead.
Activity
selvarajuv commentedon Oct 27, 2026
Closing: decision 0037 dropped the Daily Rate Analysis report, so there's no per-booking-night price to store. #104 now trains on each booking's nett ADR from Daily New Reservations (#84) instead.