Status Vocabulary & Automatic Checks¶

Part of the Aashray Business Logic. Related: Booking Lifecycle & Engine, Payments, Credits & Reconciliation, Accounts, Identity & Auth, Services — WiFi, Maintenance, Support, Gate. For implementation detail — exact routes, database structure, and known code-level defects — see the companion Technical Reference — Status & Scheduled Jobs.

Every booking and payment in Aashray moves through a shared set of states, and the system runs a handful of checks on its own, without anyone asking, to keep things moving. This file is the one place that explains what those states mean and what those automatic checks do; the domain files (stay, food, travel, adhyayan/utsav) assume this vocabulary rather than re-explaining it.

What a booking's status means¶

Awaiting confirmation — the request has been received but a staff member (or, for travel, a coordinator/staff assembling a vehicle) hasn't reviewed and locked it in yet.
Confirmed — the booking is secured. Nothing further needs to happen for it to stand.
Waitlisted — the thing being booked (a seat, a room, a spot) was full at the time of the request, so the person is in line for the next opening. If a confirmed booking ahead of them is cancelled, they're meant to be automatically moved into a confirmed spot and notified — though this doesn't reliably happen for every booking type today (see the relevant domain file's "Known limitations" section, e.g. Travel).
Pending payment / ready to pay — the booking exists but money hasn't been settled yet. This is where the 24-hour rule below applies.
Cancelled by the member and cancelled by staff are treated as two different things, even though the end result (booking called off) looks the same to everyone else. Who initiated it, and why, is recorded and can affect whether a refund becomes a credit or something else.
Credited — a payment for a cancelled booking was returned as store credit (usable toward a future booking) rather than sent back to the original payment method. See Payments, Credits & Reconciliation for exactly when a cancellation produces a credit versus a real refund.
Approved / rejected — used for one-off staff decisions outside a normal booking flow, such as a member's request for a permanent WiFi connection.
Open / closed — whether a given event (an adhyayan session, a festival) is currently accepting new registrations at all.
In progress — used for ongoing work orders, such as a maintenance request that's being worked on.

Staff permission levels¶

Staff act under one or more permission levels tied to their job — rooms, food, travel, accounts, adhyayan, utsav, wifi, maintenance, the gate, and so on — the same way a travel coordinator is a narrowly-scoped role rather than a full staff account. How permission levels are granted, narrowed to view-only, or scoped to a single centre is described in Accounts, Identity & Auth; this file doesn't repeat that list.

A couple of real prices worth stating here¶

Meal prices (breakfast, lunch, dinner) are covered in Food. Two prices that aren't documented elsewhere: an overnight Non-AC room currently costs ₹700 a night, and an AC room currently costs ₹1,100 a night — these are the actual live rates staff and the system charge today, not just "AC costs more."

The 24-hour payment rule¶

If a member chooses to pay later rather than at the moment of booking, and doesn't finish that payment within 24 hours, the system automatically cancels the booking. The system checks periodically for bookings that have crossed this window and cancels them on its own — no staff member has to notice and act. Depending on the type of booking, cancelling this way also automatically frees up the seat or room for the next waitlisted person and lets the kitchen know a meal is no longer needed. The affected member is notified. Full detail on the payment window itself lives in Payments, Credits & Reconciliation and Booking Lifecycle & Engine.

Other things the system checks on its own¶

Tomorrow's meal count. Each evening, the system automatically works out how many of each meal are needed for the next day and sends that tally to the catering team, without a staff member having to compile or request it.
WiFi capacity. The system periodically checks how many WiFi access codes are still available. If the pool is running low, it automatically alerts staff so more can be issued before the centre actually runs out — it only alerts once per low period, so staff aren't repeatedly pinged about the same shortage.

Known limitation¶

There's a second, similar auto-cancellation rule — cancelling stays that are unpaid and already in the past — that exists in the system's design but isn't currently switched on. In practice, the only thing that auto-cancels a booking today is the 24-hour unpaid-online-payment rule described above.

How this connects to other domains¶

Every booking domain (04–07) uses this status vocabulary; Payments, Credits & Reconciliation owns the full detail on the 24-hour window and how cancellations turn into credits; Accounts, Identity & Auth owns staff permission levels; the automatic checks described here are what turn a missed payment, a full WiFi pool, or tomorrow's kitchen prep into something staff (and sometimes members) get told about without asking.