Food (Raj Prasad)¶

Part of the Aashray Business Logic. Related: Booking Lifecycle & Engine, Stay: Rooms & Flats, Adhyayan & Utsav, Payments, Credits & Reconciliation, Smilestones.

Raj Prasad is fundamentally a kitchen operation, not a self-service ordering app: staff publish a menu, prepare food against a projected headcount for the next day, and track what actually gets served. A member's meal booking is just one input that feeds that headcount, alongside bulk counts staff enter directly for departments and events, not the whole process.

Staff roles for food¶

Role	What the staff panel offers
Super admin, food admin	Every food screen: issue plate (by card number and by scanner), member food bookings, group food bookings, kitchen count, food reports, menu management, and the per-person meal count
Smilestones role	Group food bookings only, for Smilestones guests (see Smilestones)
Kitchen plate-count role	The K1 kitchen count screen only

The backend lets the kitchen plate-count role record kitchen counts and nothing else. It lets super admins, food admins and the Smilestones role use every other food action (backend). The narrower Smilestones view is a staff-panel rule only (see Known limitations).

Staff publish what's being served at each meal for upcoming dates; members see this as a simple menu. The plate check uses 10:00 AM IST as the breakfast end, 2:00 PM IST as the lunch end, and 7:00 PM IST as the dinner end.

How staff manage the menu (staff panel and backend).

A date has at most one menu, with a text entry for breakfast, lunch, and dinner. Adding a menu for a date that already has one is refused. Staff edit it instead.
Staff can list menus for a date range (today by default), edit one date, or delete one date.
Staff can upload a spreadsheet with a date, breakfast, lunch, and dinner column. Rows without a date are skipped. A row for a date that already has a menu replaces that menu without a warning.

What members see (member app). The menu screen lists every published date from today onward. Each date shows "Today", "Tomorrow", or the weekday, and each meal shows its dish and a fixed serving time: breakfast 7:45 to 8:45 AM, lunch 12:00 to 1:00 PM, and dinner 5:45 to 6:45 PM (backend). With no published menu, the screen says no menu is available. The member app keeps the menu for up to three days unless the member pulls down to refresh.

Projecting demand for the kitchen¶

The kitchen needs to know, ahead of time, roughly how many of each meal to prepare for the next day. That projected count combines two streams of demand:

Individual bookings. Meals booked person-by-person, by or on behalf of members, guests, and Mumukshus (see "What members request, and who's eligible," below).
Bulk (group) bookings. Some meals aren't booked person-by-person at all. An event or department can instead have a block of meals booked as a headcount, "20 breakfasts, 15 lunches" for a group, rather than 20 or 15 individually named people. This is used for department meals and event/guest groups, and is set up by staff rather than by members themselves. Group bookings aren't billed, no per-meal charge is attached to them.

Staff are given the combined count in advance, and are alerted if the number changes later in the evening, so the kitchen isn't caught off guard by a late surge or drop in bookings (backend):

At 9:00 PM IST, three fixed staff numbers get the next day's breakfast, lunch, and dinner counts on WhatsApp. Each count adds individual meals and group headcounts.
At 10:00 PM and 11:00 PM IST, the system counts again. If any of the three numbers differs from the last count sent, one fixed kitchen number gets the new counts. Any change triggers the message, however small.
If the system has no earlier count saved for that date, for example after a restart, it saves the new count and sends nothing.

The vendor food requirement (see Reports, below) does not enter these counts.

Tracking food as served¶

Food is tracked as actually served in these ways:

Individual plates. At meal time, staff confirm a person's card, in person or by scanning it, to mark that specific meal as served for that person. A meal can only be marked served once, and only if it was actually booked.
Kitchen-wide counts. Separately, kitchen staff keep their own day-by-day, meal-by-meal tally of how many physical plates actually went out, independent of who was checked in, so booked-vs-served-vs-actually-plated can be compared and reconciled.
Group (bulk) bookings track how many plates have been handed out for the group as a running count, rather than as individual scans.

A plate can also check a person in to an Utsav. When a plate is issued for a date inside an Utsav's dates, and the person has a confirmed or cash-completed booking for that Utsav, the system also marks the booking as checked in. It then sends the Utsav check-in WhatsApp, which includes the room number. This happens with every plate tool (single scan, Utsav scanner, and bulk issue) and for Utsavs at any location. Later plates do not repeat it. If the check-in step fails, the plate is still issued. Only the Utsav scanner shows the check-in on screen. (Backend; on-screen message is staff panel. See Adhyayan & Utsav for Utsav check-in.)

Issuing a plate at the counter¶

Food admins and super admins issue plates on two screens: one where staff type or scan a card number, and one that reads the QR code on a member's card with the device camera (staff panel).

Which meal (backend). The system picks the meal from the time of the scan, in IST: up to 10:00 AM is breakfast, up to 2:00 PM is lunch, and up to 7:00 PM is dinner. After 7:00 PM the scan is refused as outside meal time.
Checks (backend). The person must have a food booking for that date with that meal booked. The plate must not already be issued. Otherwise the scan is refused with the reason, and the staff panel plays an error sound.
On success, the staff panel shows the person's name.
Offline scans (staff panel). If the device has no connection, the scan is saved on the device. A second scan of the same card within 5 minutes is not saved again. When the connection returns, the saved scans are sent with their original scan time, so the meal and date match the moment of the scan. A saved scan that the backend refuses is removed from the queue and counted as failed. Both screens share the same saved queue on a device.

Issuing plates from the no-show list¶

From the food report, staff open the list of people who booked a meal but did not collect it. For today or a past date, they can issue a plate to one person or to several selected people at once (staff panel). The backend then uses the chosen meal and date, not the time of day.

A bulk issue is all or nothing. If one selected person cannot get a plate, for example because the plate is already issued, no plate in that batch is issued (backend).

Kitchen count (K1 kitchen count)¶

The kitchen plate-count role, food admins, and super admins record how many physical plates went out for breakfast, lunch, and dinner on a date (staff panel and backend).

A date and meal has one count. Adding a count that exists is refused, and updating a count that does not exist is refused. The screen loads any saved counts for the chosen date and switches to update mode.
Staff enter all three meals together. If some meals save and others fail, the screen reports which failed.
The food report shows this count beside each meal, with a link to edit it.

Group plates¶

For a group booking, staff raise or lower the plates issued for each meal (staff panel). The backend allows this only on the booking's own date, and never above the number booked for that meal. The Smilestones role does not see these counts (staff panel).

What members request, and who's eligible¶

Three meals a day, breakfast, lunch, and dinner, each bookable independently for a single day or a range of days. Alongside the meal choice, a person picks a spice level (regular or non-spicy) and, separately, a hightea preference (tea, coffee, or none). A booking can be made for the member themselves, for a guest they're hosting, or for one or more Mumukshus they're acting on behalf of, this is the "individual bookings" stream that feeds the kitchen's projected count, above.

Who's eligible to book:

Permanent Residents and Seva Kutir members can always book food.
Guests can always book food (and are charged for it, see Pricing, below).
A plain Mumukshu-status member can only book food if they already have, or are in the process of booking, a room or flat stay covering those dates. This ties food eligibility to having a stay at the centre; without one, the booking is refused.
Staff can book food on anyone's behalf regardless of this rule.

Adding a new meal to a day that already has some meals booked simply adds to it, an ordinary later booking never reduces an existing one. Meals can be removed in these ways:

by cancelling the meal, described below;
by a Tapascharya form answer, which replaces that day's meals (see "Tapascharya (fasting) choices," below);
by cancelling a Research Centre Utsav booking that held a seat. This clears every meal in that package's dates, including meals the member booked separately for those days. Cancelling a waitlisted booking leaves the member's meals alone, because a waitlisted booking never received Utsav meals. This holds for a member cancellation, a staff cancellation, and the automatic cancellation of an unpaid booking. (Backend.)

When the system sends its food-booking WhatsApp message, it skips the message if the meals are for a Permanent Resident, whether they booked the meals themselves or someone else booked for them. (Backend.)

Seeing and cancelling meals in the member app¶

The list (member app and backend). A member sees each upcoming meal, from today onward, that is for them or that they booked for someone else. The list shows 15 meals at a time, in date and meal order. The member can filter by date, by meal, by spice level, and by person: all, self, or any one person they have booked food for, most recent first.
Cancelling. The member selects one or more meals and cancels them. A meal is greyed out and cannot be selected once 8 PM IST the day before has passed (member app). The backend applies the same cutoff. If every selected meal is past the cutoff, the request is refused; otherwise the backend cancels the meals still inside the cutoff and skips the rest without saying so.
Charges. When a member cancels a meal they booked for someone else, the meal's charge is cancelled under the normal credit rules (see Pricing). No message is sent for a food cancellation.

Staff food bookings and cancellations¶

Food admins and super admins manage one person's meals from the member food bookings screen (staff panel and backend).

Finding the person. Staff enter a mobile number or a card number. A mobile number fills in the person's name and card number.
Booking. Staff choose a start and end date (today by default), at least one meal, a spice level, and a beverage. The backend refuses a date before today, but has no 11 AM cutoff for staff. Food admins and super admins are not bound by the stay rule for Mumukshus. The meals are recorded as booked by the person themselves.
Guest charges. For a guest, each new meal creates a charge on the guest's own card, marked as cash to be collected, at the normal guest prices.
Message. The person gets the food-booking WhatsApp for their own booking, unless they are a Permanent Resident (see Food messages).
Cancelling. The screen lists the person's upcoming meals from today. Staff cancel one meal, or select several and cancel them together. There is no cutoff for staff. If a cancelled meal has a charge, the charge is cancelled as a staff cancellation (see Payments, Credits & Reconciliation). In a multi-meal cancel, a meal that is no longer booked is skipped.

Group (bulk) food bookings¶

Food admins, super admins, and the Smilestones role book group meals on the group food bookings screen (staff panel). The rules for the Smilestones role, including its cutoffs, are on the Smilestones page.

What staff enter. A card number or mobile number of the person responsible, a date (today by default), a guest count, at least one meal, and a guest group: Research Centre, school, medical, Smilestones, Sanisa, personal, or event guests (staff panel).
What is saved (backend). Each ticked meal gets the guest count, and each unticked meal gets zero. No charge is created. Food admins and super admins have no cutoff and no date limit; the backend accepts any date.
Changing a booking. Staff look up a card's group bookings from today onward and raise or lower each meal's count. The panel saves a few seconds after the last change. The guest count becomes the highest of the three meal counts (backend).
Messages. The card holder gets a WhatsApp when a group booking is made and each time a change is saved (see Food messages).
Group bookings have no cancel action. Staff set the meal counts to zero.

Tapascharya (fasting) choices¶

During a fasting observance, members fill in a Tapascharya form (see Custom Forms (Form Builder)) that asks for a fasting choice for each date. Each time a member submits or edits the form, the system sets that member's meals for each answered date (backend):

Choice	Meals booked for that day
Upvaas, Only Liquid	None
Aayambil	Lunch
Ekasna	The one chosen meal
Biyasna	The two chosen meals
Ras Tyaag, Regular	Breakfast, lunch, and dinner

The answer replaces whatever meals that day already had. If the member had no booking that day, one is created. No charge is created.
A date is skipped once 8 PM IST the day before has passed. This is a different cutoff from the 11 AM booking cutoff.
When the form is linked to an Utsav and the member has an active booking with a package, dates outside the package dates are skipped.

Booking and cancellation cutoffs¶

Meals must be booked before 11 AM the day before. The member app only lets a member pick dates that respect this: before 11 AM, the earliest bookable day is tomorrow; from 11 AM onward, the earliest becomes the day after tomorrow.
A booked meal can be cancelled up to 8 PM the day before. After that, cancelling that meal is refused.
Staff aren't bound by either cutoff when booking or cancelling on a member's behalf.

Pricing¶

Meals are free for Permanent Residents, Seva Kutir members, and Mumukshus, no charge is ever created for them.
Guests pay per meal. Breakfast, lunch, and dinner each carry a fixed price, set in the backend and not editable by staff (currently ₹60 for breakfast and ₹120 each for lunch and dinner), billed to whoever did the booking on the guest's behalf. A meal that's already been booked for a person isn't charged again if it's booked a second time.
Cancelling a paid guest meal reverses the charge, following the normal credit rules (see Payments, Credits & Reconciliation). New guest meal charges spend the payer's food credit first, and the booking quote shows the credit applied (backend).
If food is booked as part of an Utsav package, the days actually inside the Utsav are covered by the Utsav's own food arrangement, only the extra days before arrival or after departure are booked and priced as ordinary individual meals.

Reports available to staff¶

Staff can review, for any date range, how many of each meal were booked, how many were actually served, and how many were booked but never picked up (a no-show). The same rollup separates out spice and hightea preferences. Staff can also drill into who specifically booked or missed a given meal on a given date, and pull a per-person history of booked-versus-served meals over a range of dates.

The food report (staff panel and backend). Food admins and super admins choose a date range (today by default). For each meal and date, the report shows:

booked: individual meals (with the day's non-spicy count) plus group headcounts, and the total;
issued: individual plates plus group plates, and the total;
no-show: individual plus group, and the total;
the K1 kitchen count, with a link to edit it;
a total row for the range, and a separate tea and coffee count per date.

Each issued and no-show figure links to a list of names. The individual list shows each person's name and mobile number. The group list shows the card holder, mobile number, guest group, the meal count, and the plates issued; staff can adjust group plates there. The no-show list also lets staff issue late plates (see Tracking food as served).

Excluding Utsav meals. Staff can choose to leave out Utsav meals. The backend then zeroes every meal that falls inside any Utsav's dates, at any location: from the Utsav's starting meal on its first day to its ending meal on its last day, and every meal on the days between. A date where all three meals are excluded drops out of the report. This exclusion uses the Utsav's own dates, not any member's package.

Download. The report downloads as a spreadsheet with a section per meal (booked, issued, and no-show, each split into individual and group, plus the K1 kitchen count), the Tapascharya breakdown, and the tea and coffee counts.

The same report has two add-on views in the staff panel:

Tapascharya breakdown. For each date in the range, the count of members who chose Upvaas, Aayambil (direct Aayambil plus Ras Tyaag), Ekasna, Biyasna, Only Liquid, or Regular. Only each member's latest answer counts. A member is counted only with a confirmed, paid, or checked-in Utsav booking: for the linked Utsav when the form has one, or for any Utsav when it does not. The lunch figure also shows the Aayambil count. Staff can open a date-wise table and download it, and the main report download includes the same breakdown.
Vendor food requirement. Departments and vendors submit their meal needs per date on a vendor registration form. The report totals breakfast, lunch, and dinner per date, split between the Main Kitchen Mandap and the other kitchen (such as K1), with a per-department list and remarks. Only each department's latest submission counts. Staff can download it. These needs are for information only. They do not enter the kitchen's projected count or the evening meal-count messages.

Per-person meal count (staff panel and backend). Staff enter a mobile number and a date range (today by default). The screen shows the person's name and card number, and for each meal the number booked, issued, and missed. It leaves out every date inside a Research Centre Utsav and names each Utsav it left out. Unlike the food report's event exclusion, this leaves out whole dates, and only for Research Centre Utsavs.

Food messages¶

Event	Message	Recipient
Meals booked in the member app for oneself	WhatsApp: meals booked, with the first and last date	The person
Meals booked for someone else, with a charge still unpaid	WhatsApp: payment pending, with the dates and the person's name. A booker outside India gets a variant of this message.	The booker
Meals booked for someone else, no unpaid charge	WhatsApp: booked, with the dates, the person's name, and the payment reference	The booker
Meals booked for someone else	WhatsApp with the dates and the booker's name, marked payment pending or booked	The person the meals are for
Staff book meals for a person	WhatsApp: meals booked for oneself, with the dates	The person
Staff create a group booking	WhatsApp with the guest group, the card holder's name, the guest count, the date, and the meals	The card holder
Staff change a group booking	WhatsApp with the date, the guest count, and each meal's count	The card holder
A plate checks a person in to an Utsav	The Utsav check-in WhatsApp, with the room number	The person
9:00 PM	Next day's meal counts (see Projecting demand)	Three fixed staff numbers
10:00 PM, 11:00 PM	New meal counts, only when a count changed	One fixed kitchen number

No food WhatsApp is sent when the meals are for a Permanent Resident.
No message is sent when a meal is cancelled, by a member or by staff.
If a message fails, the booking is still saved (backend).

Known limitations today¶

The 11 AM booking cutoff isn't actually enforced for most bookings, it's only enforced by which dates the member app lets a member pick. A booking made through some other path could bypass it.
There's no on-screen way for staff to change meal prices. They exist as fixed values that currently require an engineering change to update.
Group booking cutoffs apply only to the Smilestones role, and only for tomorrow's date. Food admins and super admins have no cutoff, and no role is refused a group booking for today or a past date. The details are on the Smilestones page.
The backend gives the Smilestones role every food action except the kitchen count. The staff panel shows that role only the group food bookings screen.
The vendor food report always reads one fixed vendor form. Staff cannot choose a different form on screen.
Member meal cancellation trusts the request. The backend does not check that the member who cancels is the person the meal is for or the booker.
A partly late cancellation is silently partial. When a member cancels several meals and some are past the 8 PM cutoff, the backend cancels only the others and does not report the skipped ones.
Staff bookings send the wrong food message to a guest. A guest whose meals staff booked gets the "meals booked" message even when the charge is still to be collected. A guest who books their own meals also always gets the "meals booked" message.
Staff can mark a past meal as served. The no-show list lets staff issue a plate for any earlier date, and the backend does not check the date.
Spreadsheet menu upload overwrites without warning. An uploaded row replaces the existing menu for that date.
The tea, coffee, and non-spicy counts in the food report include days whose meals were all cancelled. A cancelled meal leaves the day's food record in place, and these counts read every record for the date.
Every saved group-booking change sends a WhatsApp. Several quick changes can send several messages.

These limitations mainly affect staff tools and pricing behind the scenes.