Stay: Rooms & Flats (Raj Sharan) — Technical Reference¶

Part of the Aashray Technical Reference. Pairs with Business Logic — Stay: Rooms & Flats, which describes these rules in plain terms with no code detail. Related technical detail currently lives inline in: Booking Lifecycle & Engine, Payments, Credits & Reconciliation, Adhyayan & Utsav, Admin Panel Map, API Reference, Status & Cron.

This file is 100% derived from reading the backend and admin source on main — no operational/staff-knowledge content lives here (that's in the business-logic companion, plus everything else at the product level). It covers exactly how room and flat booking, availability/assignment, block dates, the 24-hour room-number reveal, charges, and admin check-in/out are implemented: every route, the data model, admin mechanics, edge cases, and known defects.

Relevant code: controllers/client/roomBooking.controller.js, helpers/roomBooking.helper.js, controllers/admin/roomManagement.controller.js (+ its routes), models/{room_booking,roomdb,flat_booking,flatdb,block_dates}.model.js, and the shared controllers/helper.js.

Verification status: audited & anchored per docs/DOCS-METHODOLOGY.md on 2026-07-07 against aashray-backend main. Every rule carries a [src: …] anchor. All 8 discrepancies were confirmed against code; D6 (undeclared error constants) was found to affect two more call sites than originally listed and has been expanded.

1. Room vs Flat — data model shape¶

Room (RoomBooking / RoomDb) — a bed in a shared centre room. Rooms are inventory owned by the centre; the system auto-assigns a specific roomno at booking time from an availability pool. A booking is per-person per-date-range. Category string room (self, guest, and mumukshu all use 'room' — TYPE_ROOM === TYPE_GUEST_ROOM).

Flat (FlatBooking / FlatDb) — a whole flat that a member owns. A flat owner reserves their flat for other people (fellow mumukshus / brought guests). There is no self-flat booking — the app hides the "Self" chip for the flat category, which only appears at all for flat owners. Category string flat (TYPE_FLAT).

Both share the same status enum and both hasMany Transactions by bookingid.

2. Member-app flow¶

Entry: Book Now → Raj Sharan chip (rooms), or the Flat chip (owners only, defaulting to the Mumukshus sub-flow). Raj Sharan has a segmented control: Select Dates (default) and One Day Visit.

Select Dates (Self): range calendar (earliest = tomorrow) → "Book for" chips (Self/Guest/Mumukshus; guest-status accounts see Self only) → Room Type (Non AC default / AC) → Select Floor Type (Any Floor default / Only Ground Floor) → Book Now. This does not book immediately; it saves the slice and navigates to Booking Details (add-ons) → Review → pay. Create call is POST /api/v1/mumukshu/booking (self/mumukshu) or /guest/booking.
One Day Visit (Self): single-date calendar (earliest = tomorrow) → Book Now books instantly (POST /api/v1/mumukshu/booking, booking_type: room, check-in = check-out). Room type is forced to Non-AC, floor "any"; no charge, no Razorpay, immediate success alert.
Guest/Mumukshu: collect N people on the entry screen (a reusable pool), then on the add-ons screen split them into room groups — each group its own room type + floor type. Review shows aggregate counts per date range (never individual names) with a tappable Room/Flat Charge Breakdown sheet (per-person nights + charge + credits).
Flat: owner picks a date range (from today) and the guests/mumukshus; entry collects only dates + people (no room/floor pickers). Flat is a standalone primary — the engine forbids flat as an add-on or alongside room/utsav add-ons.
Room number is not shown in the app until 24h before check-in (see §7).
Manage/cancel: the Bookings tab lists room+flat via GET /api/v1/stay/bookings; a future-dated, non-cancelled booking shows Cancel Booking → POST /api/v1/stay/cancel.

3. Backend rules & logic¶

Room types, floor & gender¶

Room types: 'ac', 'nac' (non-AC), and 'NA' (reserved for day visits). Enum on both RoomBooking.roomtype and RoomDb.roomtype.
Gender/floor encoding: RoomBooking.gender and RoomDb.gender ∈ {M, F, SCM, SCF, NA}. The floor preference is folded into gender: createRoomBooking computes gender = floor_pref ? floor_pref + user_gender : user_gender. floor_pref is the string 'SC' for "Only Ground Floor" (set by the client controller and passed into the helper), so a ground-floor male becomes SCM, female SCF. Rooms are matched to the exact gender value, which is how ground-floor rooms are segregated from upper floors. [src: helpers/roomBooking.helper.js:410,661]
Day visit: nights == 0. bookDayVisit writes roomno='NA', roomtype='NA', gender='NA', nights:0, status pending checkin, no transaction, no charge. [src: helpers/roomBooking.helper.js:82-111]

Charges (`config/constants.js`)¶

NAC_ROOM_PRICE = 700, AC_ROOM_PRICE = 1100 per night. roomCharge(roomtype) returns 700 for nac, else 1100. [src: config/constants.js:25-26; helpers/roomBooking.helper.js:478-480]
Room charge = roomCharge(roomtype) * nights, created as a pending Transactions row (category='room') with credits from the room pool applied by useCredit.
Flat charge always uses the NAC rate: createFlatBooking computes roomCharge('nac') * nights = 700 * nights for non-owners (flats have no AC/NAC attribute). The flat-owner-of-this-flat pays ₹0 and is set straight to pending checkin. [src: helpers/roomBooking.helper.js:551-609 (nac charge :593, owner-free :566-569)]
Credits fold flat → room (getCreditType), so room and flat draw from the same credit pool. [src: helpers/transactions.helper.js:289-293]

Availability & automatic room assignment¶

Room assignment is automatic at booking time (not chosen by the user, not deferred). findRoom(checkin, checkout, room_type, gender, excludeRooms): [src: helpers/roomBooking.helper.js:199-252] 1. Queries RoomDb for roomstatus='available', matching roomtype + gender, excluding NA%/WL% room numbers and any in excludeRooms. 2. Excludes rooms already booked on overlapping dates via a subquery on room_booking where checkout > reqCheckin AND checkin < reqCheckout and status not in (cancelled, admin cancelled). 3. Orders by room number numerically then by trailing letter (CAST(SUBSTRING(roomno,1,len-1) AS UNSIGNED), then the last char) and takes the first — i.e. it assigns the lowest-numbered free room of the right type/gender.

checkRoomAlreadyBooked(checkin, checkout, ...cardnos) blocks a person from double-booking overlapping dates when they already hold a waiting/payment pending/checkedin/pending checkin room (checks cardno only, not bookedBy). Overlap uses the standard three-way date-range predicate. ERR_ROOM_ALREADY_BOOKED if hit. If no room is free, ERR_ROOM_NO_BED_AVAILABLE ("No beds available"). [src: helpers/roomBooking.helper.js:46-80]

Block dates (Research-Centre closures)¶

BlockDates (blockdates table: checkin, checkout, comments, status ∈ {active, inactive}). Admins block RC date ranges; getBlockedDates finds active overlapping blocks and validateBlockedDates throws "Dates are blocked during following periods: …". Block-date validation runs inside the room availability path (getDateRangesDuringUtsav → validateBlockedDates). Flat bookings do not check block dates (only validateDate + checkFlatAlreadyBooked) — see Discrepancies. [src: models/block_dates.model.js:26-31; helpers/utsavBooking.helper.js:544,590; helpers/roomBooking.helper.js:482-549,714-770 (flat path, no block-date call)]

Waitlist around a festival (utsav boundary)¶

Rooms normally never waitlist — except around a festival: - createRoomBooking: a single-night booking whose check-in is a festival's end_date or whose check-out is a festival's start_date (findUtsavOnBoundaryDates) is forced to waiting via bookWaitingRoom (roomno='NA', no transaction). [src: helpers/roomBooking.helper.js:417-439; helpers/utsavBooking.helper.js:628-636] - For multi-night stays straddling a festival, getDateRangesDuringUtsav/splitDateRanges split the stay so nights outside the festival window are confirmed and the boundary night is waitlisted (checkRoomAvailabilityForMumukshus sets minNights = overlappingWithUtsav && nights>0 ? 1 : 0; nights above minNights are assigned a room, the rest wait). This is the only room waitlist path, and it is not auto-promoted by the cron — an admin moves it forward (§5). [src: helpers/roomBooking.helper.js:671; cron.js:164-207 (no room case)]

Flat ownership & flat-for-others¶

FlatDb PK is the composite (flatno, owner) — a flat can list multiple owners, and owner FKs card_db.cardno. Extra columns: last_deep_cleaning, deep_cleaning_interval (default 90 days), deep_cleaning_history (JSON).
bookFlatForMumukshus resolves the flat by owner = booker.cardno; if none, 404 "Flat not found for {cardno}". It validates dates, checks each person via checkFlatAlreadyBooked (which excludes cancelled/admin cancelled/checkedout), computes nights, and creates one FlatBooking per person. [src: helpers/roomBooking.helper.js:482-549 (owner lookup :497-505); controllers/helper.js:99-101]
createFlatBooking: if the person owns that flat (isMumukshuFlatOwner) → free, status pending checkin, no transaction. Otherwise → payment pending + a nac-rate transaction (credits applied). [src: helpers/roomBooking.helper.js:551-609]
FlatBooking.bookedBy follows the standard rule (booker.cardno == cardno ? null : booker.cardno). flatno is nullable INTEGER.

Check-in / check-out (rules)¶

Check-in/out are admin actions (there is no self check-in endpoint). Rooms: - Check-in (manualCheckin, PUT /admin/stay/checkin/:bookingid): only from pending checkin; refuses if checkin > today (IST) and refuses while the transaction is payment pending/cash pending ("Cannot check-in until payment is completed."). Sets checkedin. [src: controllers/admin/roomManagement.controller.js:271-334] - Check-out (manualCheckout): only from checkedin. Branches on today (IST) vs planned checkout (thresholds CHECKOUT_DEADLINE='11:00:00', LATE_CHECKOUT_HALF='15:00:00'): [src: controllers/admin/roomManagement.controller.js:73-74] - Same day, on time (≤ 11:00) or nights < 1 → checkedout. [src: controllers/admin/roomManagement.controller.js:83-96] - Same day, late (> 11:00): a late-checkout fee transaction is created (amt_type='late_checkout_room', status cash pending): half-day if ≤ 15:00 (price/2), else full-day (full nightly price for the room type). Booking → checkedout; a push nudges the guest to pay. [src: controllers/admin/roomManagement.controller.js:76-81,104-116] - Overstay (today > planned checkout): currently just marks checkedout (the overstay-extension handler exists but is commented out — see Discrepancies). [src: controllers/admin/roomManagement.controller.js:392-404] - Early (today < planned checkout): handleEarlyCheckout admin-cancels the original booking + credits its transaction, then creates a new checkedout booking for the actual nights at the recomputed (never higher) amount, crediting the difference to the payer. [src: controllers/admin/roomManagement.controller.js:175-269] - Flat check-in/out (flatCheckin/flatCheckout): check-in only from pending checkin, refuses checkin > today. Check-out only from checkedin; overstay is refused ("Please create a new booking …"); otherwise it rewrites nights/checkout to today and sets checkedout. [src: controllers/admin/roomManagement.controller.js:565-617] - Late-checkout fees are managed via GET /admin/stay/late-checkout-fees?payment_type= (buckets: payment_pending→cash pending, payment_done→completed, fees_revoked→admin cancelled) and PUT /admin/stay/late-checkout-fees/revoke ({transactionId, status} — waiving fires a WhatsApp).

4. Every route¶

Member (client) — auth realm: member `validateCard`¶

Method	Path	Auth realm	Purpose	Key params/body
GET	`/api/v1/stay/bookings`	member	List my room+flat bookings (paginated UNION, joined to latest room/flat/guest-room transaction)	`page`, `page_size`
POST	`/api/v1/stay/cancel`	member	Cancel a room or flat booking I own or booked	`bookingid`
POST	`/api/v1/stay/flat`	member	Deprecated direct mumukshu flat booking	`mumukshus[]`, `startDay`, `endDay`
POST	`/api/v1/mumukshu/booking`	member	Create room/flat (self & mumukshu) via primary+addons	`primary_booking{booking_type:'room'\|'flat', details:{checkin_date, checkout_date, mumukshuGroup\|mumukshus}}`, `addons[]`
POST	`/api/v1/mumukshu/validate`	member	Preview room/flat availability + charge	same shape
POST	`/api/v1/guest/booking`	member	Create room/flat for guests	`primary_booking{…, details:{…, guestGroup\|guests}}`
POST	`/api/v1/guest/validate`	member	Preview (guest)	same
POST	`/api/v1/guest/flat`	member	Deprecated guest flat booking	`guests[]`, `startDay`, `endDay`

(Room type comes from details.mumukshuGroup[].roomType; floor from floorType; day-visit = checkin_date === checkout_date.)

Admin — auth realm: `auth` + `authorizeRoles(officeAdmin, superAdmin, roomAdmin)` (base `/api/v1/admin/stay`)¶

Method	Path	Purpose	Key params/body
POST	`/bookForMumukshu`	Create a room booking (or day-visit) for a card, `cash pending`, confirmed	`mobno` or `cardno`, `checkin_date`, `checkout_date`, `room_type`, `floor_pref`
PUT	`/checkin/:bookingid`	Manual room check-in	`:bookingid`
PUT	`/checkout/:bookingid`	Manual room check-out (+ late fee / early credit)	`:bookingid`
PUT	`/update_room_booking`	Reassign a room number	`bookingid`, `roomno`
PUT	`/update_booking_status`	Drive room status transitions (`waiting→payment pending→pending checkin`, or `admin cancelled`) w/ credit math	`bookingid`, `status`, `description`
GET	`/room_list`	All rooms (excl. `NA`/`WL`)	—
GET	`/available_rooms/:bookingid`	Rooms matching a booking's type+gender	`:bookingid`
GET	`/available_rooms_for_day`	Free rooms on a day	`date`, `roomtype`, `gender`
GET	`/fetch_room_bookings/:cardno`	A card's room bookings	`:cardno`
POST	`/bookFlat/:mobno`	Create a flat booking for a card (confirmed, `cash pending`)	`:mobno`, `checkin_date`, `checkout_date`, `flat_no`
PUT	`/flat_checkin/:bookingid`	Flat check-in	`:bookingid`
PUT	`/flat_checkout/:bookingid`	Flat check-out (overstay refused)	`:bookingid`
PUT	`/flat_cancel/:bookingid`	Admin-cancel a flat booking	`:bookingid`
GET	`/flat_list`	Distinct flat numbers	—
GET	`/fetch_flat_bookings/:cardno`	A card's flat bookings	`:cardno`
PUT	`/update_flat_booking_status`	Drive flat status transitions (flat rate = ₹700/night, credit math)	`bookingid`, `status`, `description`
PUT	`/block_room/:roomno`	Block room(s) by prefix (`roomno LIKE '<p>%'`)	`:roomno`
PUT	`/unblock_room/:roomno`	Unblock by prefix	`:roomno`
PUT	`/update_room/:roomno`	Change a room's `roomtype`/`gender`	`:roomno`, `roomtype`, `gender`
POST	`/block_rc`	Block a Research-Centre date range	`checkin_date`, `checkout_date`, `comments`
PUT	`/unblock_rc/:id`	Deactivate a block (`status='inactive'`)	`:id`
GET	`/rc_block_list`	Current/future blocks	—
GET	`/reservation_report`	Room reservations in range	`start_date`, `end_date`, `statuses`, `page`, `page_size`
GET	`/flat_reservation_report`	Flat reservations in range	`start_date`, `end_date`, `statuses`
GET	`/daywise_report`	Per-day AC/NAC booked vs available	`start_date`, `end_date`
GET	`/occupancyReport`	Currently checked-in guests	—
GET	`/guestsByDateAndRoomtype`	Guests occupying a room type on a day	`date`, `roomtype`
GET	`/late-checkout-fees`	Late-checkout fee list by bucket	`payment_type` (`payment_pending`/`payment_done`/`fees_revoked`)
PUT	`/late-checkout-fees/revoke`	Waive/settle a late-checkout fee	`transactionId`, `status`

Admin — booking management (base `/api/v1/admin/bookings`)¶

Method	Path	Purpose	Key params/body
PUT	`/cancel/:type/:bookingid`	Admin-cancel (issues credit via `adminCancelTransaction`)	`:type` — only `room` implemented; `:bookingid`

Full cross-domain endpoint catalog and role table also appear in the API Reference and Admin Panel Map.

5. Admin operations (staff panel)¶

The vanilla-JS admin panel (admin-main/admin/room/*) is the operational surface, all hitting /api/v1/admin/stay/*: - roomBooking.js / flatBooking.js — create a stay for any card on behalf (by mobile/cardno) → bookForMumukshu / bookFlat/:mobno. - manageRooms.js / updateRoom.js — block/unblock (block_room/unblock_room, prefix-based so "10" blocks 101, 102, …) and change room type/gender (update_room). - updateRoomBooking.js — reassign a roomno (update_room_booking); pushes a "Room number changed" notification + room_number_updated WhatsApp. - fetchRoomBookingsByCard.js / fetchFlatBookingsByCard.js — per-card history. - roomReports.js / roomDetailReport.js — reservation, occupancy, day-wise, guests-by-day reports; late-checkout-fee console (late-checkout-fees + revoke). - blockRC.html — Research-Centre date-range blocking (block_rc, rc_block_list, unblock_rc). - Check-in/out and status changes drive the waiting → payment pending → pending checkin → checkedin → checkedout lifecycle; update_booking_status enforces legal transitions (e.g. payment pending only from waiting; pending checkin only from payment pending; admin cancelled only from waiting/payment pending; cannot revert to waiting).

6. Data & relationships¶

RoomBooking (room_booking, timestamps): bookingid (PK, UUID string), cardno (FK card_db, whose stay), bookedBy (nullable FK, who booked), roomno (FK roomdb, or 'NA'/'WL'), checkin/checkout (DATEONLY), nights (int), roomtype ∈ {ac,nac,NA}, status, gender ∈ {M,F,SCM,SCF,NA}, updatedBy (default 'USER'). [src: models/room_booking.model.js:16-84]

RoomDb (roomdb, no timestamps): id, roomno (unique), roomtype ∈ {ac,nac,NA}, gender ∈ {M,F,SCM,SCF,NA}, roomstatus ∈ {available, blocked}, updatedBy. [src: models/roomdb.model.js:13-32]

FlatBooking (flat_booking, timestamps): bookingid (PK), cardno (FK), bookedBy (nullable FK), flatno (nullable INT FK flatdb), checkin/checkout, nights, status, updatedBy. No roomtype (flats have no AC/NAC). [src: models/flat_booking.model.js]

FlatDb (flatdb, no timestamps): composite PK (flatno, owner); owner FK card_db; updatedBy; last_deep_cleaning, deep_cleaning_interval (default 90), deep_cleaning_history (JSON). [src: models/flatdb.model.js:7-37]

BlockDates (blockdates, timestamps): id, checkin, checkout, comments, status ∈ {active,inactive} (default active), updatedBy. [src: models/block_dates.model.js:26-31]

Associations: RoomDb hasMany RoomBooking by roomno; FlatDb hasMany FlatBooking by flatno. RoomBooking/FlatBooking each belongsTo CardDb twice (cardno, and bookedBy as bookedByCard) and hasMany Transactions (as:'transactions') by bookingid (so reports can join the latest transaction for payment status). CardDb hasMany both by cardno and by bookedBy (aliases roomBookedByCard/flatBookedByCard; room's is SET NULL on delete).

7. Every status & the 24h room-number reveal¶

Room/flat booking statuses (RoomBooking.status / FlatBooking.status enum): waiting, pending (payment pending), pending checkin, checkedin, checkedout, cancelled, admin cancelled.

Lifecycle: - waiting (WL): room only, and only around a festival boundary (roomno='NA', no transaction). Admin can move it to payment pending. Not auto-promoted by cron. - payment pending: a transaction exists but is unpaid (online) or cash pending (NRI/admin). Auto-cancelled by the 24h cron if unpaid (online). - pending checkin: confirmed & paid (or fully credit-covered, or a free day-visit / flat-owner booking). Ready for arrival. - checkedin / checkedout: set by admin check-in/out. - cancelled (user) / admin cancelled (admin or cron).

RoomDb.roomstatus: available (assignable) or blocked (excluded from findRoom, set via block_room).

24-hour room-number reveal: the backend always stores the assigned roomno at booking time (§3 findRoom), but the app hides it until it's meaningful. The Bookings-tab detail shows the literal text "24h before check-in" instead of the room number until either (a) it's a flat, or (b) the transaction is completed and it's within 24h of / after check-in. This is a client-side presentation rule — there is no backend endpoint gating room-number disclosure; a determined client could read roomno from GET /api/v1/stay/bookings earlier. Flat numbers are shown without the 24h gate.

8. Edge cases & branches¶

Day visit = checkin_date === checkout_date (nights==0): forced Non-AC-style NA room, pending checkin, free, instant — no review, no payment.
NRI cards (country != 'India'): transactions created as cash pending; no Razorpay order; not swept by the 24h cron.
Fully credit-covered stay: useCredit completes the transaction and advances the booking straight to pending checkin with no Razorpay.
Festival boundary single night: forced waiting even if rooms are free.
Overlap guard: a person can't hold two overlapping active room bookings (checkRoomAlreadyBooked).
Early checkout rewrites the booking (admin-cancel + new checked-out booking) and credits the payer the difference; late checkout adds a half/full-day fee; overstay (room) currently just closes the booking with no extra charge.
Block dates stop room bookings but not flat bookings.
Room assignment is deterministic (lowest free room of the matching type+gender), so two simultaneous bookings for the same slot are separated only by the excludeRooms accumulator within a single request and the overlap subquery across requests.
Admin status transitions are guarded: illegal jumps throw (e.g. "Pending can only be set from waiting status", "Cannot revert back to waiting").

Discrepancies¶

Flat AC/NAC is never distinguished. createFlatBooking has a comment "Check if flat is AC or NAC" but unconditionally charges roomCharge('nac') (₹700/night). FlatDb/FlatBooking have no room-type column, so all flats bill at the NAC rate. [src: helpers/roomBooking.helper.js:592-593]
RoomBooking/FlatBooking have no amount column, yet code writes one. updateBookingStatus / updateFlatBookingStatus call booking.update({ amount: finalAmount, … }), but neither model declares amount — Sequelize silently drops the unknown attribute, so the value is only persisted on the Transactions row, not the booking. Latent no-op. [src: controllers/admin/roomManagement.controller.js:1540,1892; models/room_booking.model.js; models/flat_booking.model.js]
amt_type is used but not modeled. Late-checkout fees are written with amt_type:'late_checkout_room' and queried via raw SQL (WHERE t.amt_type = 'late_checkout_room'), but the Transactions Sequelize model doesn't declare amt_type — it relies on the physical column existing outside the ORM definition. [src: controllers/admin/roomManagement.controller.js:110,2160]
Inline price literals in admin status transitions. updateBookingStatus hardcodes ac=1100 / nac=700 and updateFlatBookingStatus hardcodes 700, instead of reusing the imported AC_ROOM_PRICE/NAC_ROOM_PRICE. Drift risk if constants change. [src: controllers/admin/roomManagement.controller.js:1506,1859]
Overstay-extension is dead code. handleOverstayCheckout (auto-creates an extension booking + charge for the extra nights) is fully implemented but its call site in manualCheckout is commented out; overstay now just marks checkedout with no extra charge for rooms, and is outright refused for flats. This is described in plain terms in the business-logic companion's "Check-in and check-out" section. [src: controllers/admin/roomManagement.controller.js:136-170 (impl), 392-397 (commented call)]
Undeclared error constants referenced → ReferenceError. roomManagement.controller.js uses ERR_INVALID_DATE, ERR_ROOM_FAILED_TO_BOOK, and ERR_BOOKING_ALREADY_CANCELLED but does not import them (imports at :9-38 omit all three), so those branches throw a raw ReferenceError instead of the intended ApiError. Affected call sites: ERR_INVALID_DATE at :626 (roomBooking) and :725 (flatBooking); ERR_ROOM_FAILED_TO_BOOK at :228 and :242 (handleEarlyCheckout); ERR_BOOKING_ALREADY_CANCELLED at :1494 (updateBookingStatus) and :1847 (updateFlatBookingStatus). [src: controllers/admin/roomManagement.controller.js:9-38,228,242,626,725,1494,1847]
Block dates enforced for rooms but not flats (see §3/§8) — a flat can be booked on an RC-blocked range. Described in plain terms in the business-logic companion's "Block-out dates" section. [src: helpers/roomBooking.helper.js:482-549,714-770 (flat path, no block-date check)]
Room waitlist has no auto-promotion. Unlike adhyayan/utsav/travel, a cancelled/expired confirmed room does not promote the next waitlisted room booking; an admin must intervene. Described in plain terms in the business-logic companion's "Known limitations today" section. [src: cron.js:164-207 (cancel switch has no room case)]

Cross-cutting discrepancies spanning multiple domains are also tracked centrally in Discrepancies & Open Questions.

How this connects to other domains (technical)¶

Booking Lifecycle & Engine (business-logic file 03): room/flat rows are created by the shared primary+addons engine (bookedBy, validate→booking→pay); stay is the most common add-on attached to Adhyayan/Utsav/Travel primaries.
Payments, Credits & Reconciliation (business-logic file 08): room/flat charges, the shared room↔flat credit pool, the NRI cash-pending path, and the 24-hour pay-later auto-cancel cron are detailed there.
Adhyayan & Utsav (business-logic file 07): the festival-boundary waitlist logic (findUtsavOnBoundaryDates / getDateRangesDuringUtsav) ties room availability directly to utsav dates.
Status & Cron (business-logic file 13): room/flat reuse the global status vocabulary and the 24-hour unpaid-booking auto-cancel cron.
Admin Panel Map (11): the officeAdmin/roomAdmin/superAdmin roles and the Room/Flat Management pages are catalogued there.
API Reference (12): full parameter-level detail for every route in §4.