Canteen & meals.

Most school systems treat the canteen as an afterthought — a free-text note on a fees line, a cash box no one reconciles. YESS treats it as what it is: a daily-operations business that touches food safety, inventory, cash handling, and the general ledger every single day. The canteen module lives inside Cluster C7 (Daily Operations) and carries the gold commerce pillar, because at the end of the day it has to balance like the bursary does.

The module is layered. A small day school can run on a menu, a till, and a transactions log. A boarding school can turn on meal-plan subscriptions, prepaid wallets, recipe costing against stock, and per-shift operator reconciliation. The chapters below move from the simplest layer to the most complete; stop wherever your school sits.

The plate is checked before it is served, and counted after it is sold.

It is 11:50 at Greenwood. Follow one lunch service end to end and the rest of this book is just detail.

11:50. The canteen manager opens the hub at /dashboard/canteen. The gold KPI rail reads the morning back to her: today's revenue, orders today, active subscribers, low-stock items, and the month's profit margin. The Active orders feed shows four tickets still preparing.

11:58. A boarder walks up to the counter. The cashier opens /dashboard/canteen/daily-payment, picks the student, adds a jollof rice and a drink to the cart, and chooses wallet. The order is created paid and delivered in one shot. Behind the scenes a database trigger atomically debits the student's prepaid wallet — and, because the dish carries a peanut allergen tag and the student's health profile lists a peanut allergy, a second trigger stamps a dietary flag on the order and fires a notification to the student's parents. The cashier sees the flag and swaps the dish.

12:30. Lunch rush over. The kitchen produced a batch of stew from a costed recipe at /dashboard/canteen/recipes: fifty servings, which drew the exact ingredient quantities out of stock and posted the cost of goods to the ledger automatically.

15:00. The operator files the shift report at /dashboard/canteen/reports — total sales, cash and mobile-money received, meal-plan servings, any cash discrepancy — and submits it for the manager's approval. The day's canteen revenue is already on the school's P&L.

Before the canteen can sell a single plate it needs a catalogue. Menu items live at /dashboard/canteen/menu. Each item carries a name, a price and a cost price, a preparation time, an availability switch, and — most importantly — its allergens and dietary tags. Those two lists are what the dietary safety check reads at order time, so they are not decoration: they are the food-safety contract.

Every item is filed under one of seven categories, fixed by a database constraint: breakfast, lunch, dinner, snack, drink, dessert, or side. Open any item's mini-world at /dashboard/canteen/menu/[id] to see its margin, prep time, and a prominent allergen safety panel.

Daily menus at /dashboard/canteen/daily-menus let you publish what is on offer per day and per meal type (breakfast, lunch, dinner, snack). A daily menu is created as a draft and made visible with the Publish action.

A menu item is what you sell; a recipe is what it costs to make. Recipes live at /dashboard/canteen/recipes. Each recipe carries a default meal type, a serving count, allergen and dietary-tag arrays, and a list of ingredients. Every ingredient is drawn from the school's inventory items, with a quantity per serving — and YESS recomputes the recipe's cost per serving automatically every time the ingredient list changes, through a database trigger.

The killer feature is Produce now. Enter how many servings you are making and YESS runs a pre-flight check against live stock: if any ingredient is short, it refuses and lists exactly what is missing. If stock is sufficient, it decrements each ingredient and posts the cost of goods to the ledger — debit COGS, credit canteen inventory — in one atomic operation.

A meal plan is a bundle a family or staff member subscribes to. Plans live at /dashboard/canteen/meal-plans, each with a plan type — boarder_full, boarder_half, staff_monthly, student_weekly, student_daily, or custom — a billing frequency (daily, weekly, monthly, per_term, per_year), a price, the meals it includes, and a daily meal cap.

Subscriptions live at /dashboard/canteen/subscriptions. A subscription ties a student or staff member to a plan over a date range, with a status (active, paused, expired, cancelled) and a payment status (pending, paid, partial, waived). Staff can pause and resume a subscription in one click.

The clever bit is for boarders. Mark exactly one plan as the boarder default, and the moment a student is flipped to boarder status anywhere in YESS, a database trigger auto-enrols them on that plan — no manual subscription needed. A nightly cron job renews auto-renewing subscriptions the day before they expire.

There are two ways a plate gets sold. The kitchen order board at /dashboard/canteen/orders walks an order through the canonical six-state lifecycle — pending → confirmed → preparing → ready → delivered (or cancelled). The walk-up till at /dashboard/canteen/daily-payment is the cashier's point of sale: pick who is paying (student, staff, or guest), build a cart, take the payment, and the order is created already paid and delivered.

An order can be paid by cash, mobile_money, card, wallet, meal_plan, or invoice. The wallet is the prepaid balance a student carries. The cashier (or, in a future release, a parent online) tops it up at the till; topping up posts a debit to cash and a credit to the prepaid-wallet liability account. When a wallet order is placed, a database trigger debits the balance atomically — and if the balance is short, the order is blocked at the database, not merely warned about.

Revenue is recognised cleanly. A non-wallet order that is paid and delivered posts debit cash, credit canteen revenue. A wallet order already recognised its revenue when the wallet was debited, so the order trigger deliberately skips it — no double counting.

This is the chapter that makes the canteen module unlike any other shop. Every time a student order is created, a database trigger fires before the row is even written. It loads the student's health profile — their food allergens and dietary restrictions — and walks every item in the order.

It runs two checks. An allergen conflict is the intersection of an item's allergens with the student's allergen list — a peanut dish for a peanut-allergic child. A restriction conflict is a dietary requirement the item fails to meet — a student who needs halal being served an item that is not tagged halal. Any conflict stamps a structured dietary flag onto the order recording exactly which items and which conflicts, and a second trigger fans out a notification to every linked parent with a link into /portal/canteen.

One honest caveat: the check flags, it does not block. The order still goes through; the cashier and the parents are warned. This is a deliberate operational choice — a hard block at the till would stop service over a mis-tagged side dish — but it means the tags must be accurate and the operator must read the flag. Allergen safety is a shared duty between the catalogue, the till, and the health record.

The canteen's own stockroom lives at /dashboard/canteen/inventory. Items are filed under raw_ingredient, prepared, packaging, cleaning, equipment, or other, each with a stock level, a reorder threshold, a unit cost, and a supplier. Every stock change is a movement — purchase, consumption, waste, adjustment, return, or transfer — and a consumption movement posts the cost of goods to the ledger automatically.

The canteen's standalone ledger lives at /dashboard/canteen/transactions. Each line is income or expense, filed under sales, purchase, salary, utilities, maintenance, equipment, or other. This is where the manager records the diesel for the generator or the bag of rice bought for cash.

At the end of each shift the operator files a reconciliation report at /dashboard/canteen/reports: total sales, cash, mobile money and card received, meal-plan servings, waste, and any cash discrepancy. The report moves draft → submitted → approved. Finally, the read-only analytics at /dashboard/canteen/analytics show revenue, expenses, net profit and margin over a date range, the top-ten most-sold items, and an expenses-by-category breakdown.

The canteen's behaviour is configured once at /dashboard/canteen/settings, across three cards. Financial: currency, tax rate, and a default delivery fee. Orders: an order cut-off window, whether guest orders are allowed, whether pre-orders are required, and whether orders auto-deduct from the wallet. Inventory alerts: whether low-stock alerts fire, the low-stock threshold percentage, and whether cost prices are shown to floor staff.

One operational note: the auto-deduct-from-wallet toggle is configured here but is not yet consumed by the order flow — wallet payment today is chosen per order at the till. Treat it as a setting that records intent ahead of the automation that will read it.

In the spirit of an honest handbook, here is what is scaffolded but not yet complete. These are real gaps, listed so you can plan around them.

The canteen is wired into four other modules. Some connections are automatic; some are configured.