School store.

The school store is the most under-managed money flow in most schools. Uniforms are sold from a storeroom; the takings go into a drawer; stock is counted once a term, if ever; and nobody can say at the end of the year whether the shop made money or quietly lost it.

YESS treats the store as exactly what it is — a small retail operation that belongs on the school's books. It has a catalogue with real stock levels, an order that moves through a defined lifecycle, a return that the desk decides on, and an automatic journal entry that recognises revenue and the cost of goods sold at the moment of delivery. Eight tables under the hood, five screens on top, and one number the owner can finally trust: shop margin.

A real store with a real ledger — the cash tin closed for good.

It is the first week of term at Greenwood. Follow the store manager through one morning and the rest of the book is detail.

07:50. She opens the store hub at /dashboard/shop. The gold KPI rail reads at a glance: active products, revenue in the last 30 days, pending fulfilment, and low stock. Two items are flagged low — the Junior blazer (size 32) and exercise books — so before anything else she opens /dashboard/shop/products and updates their stock from the morning's delivery.

08:30. A parent pays cash for a senior blazer and a PE kit. The order is recorded at the till, lands in the desk as paid, and the manager opens /dashboard/shop/orders, finds it, and walks it forward: → preparing while she bags it, then → ready, then → delivered when the parent collects. On that last click the system decrements stock and — because the order is both paid and delivered — posts the sale to the general ledger automatically.

10:15. The blazer is the wrong size. The parent comes back; a return is logged against the order and arrives in the manager's queue at /dashboard/shop/returns. She reviews the reason, approves the return, and records the refund amount and method.

16:00. The accountant closes the cashier shift. The cash the store took today is already in the Z-report at /dashboard/finance/cashier-shifts — the shop's cash sales were folded into the till's expected takings, so the count either reconciles or surfaces a variance. No separate tally, no spreadsheet.

Before the store can sell a thing it needs a catalogue. That is two screens: categories that organise the shelf, and products that sit on it.

Categories

Open /dashboard/shop/categories. A category carries a name, a slug (auto-derived from the name if you leave it blank), an optional parent category — so you can nest Uniforms → Blazers — a sort order, an icon key, and an active flag. The vital strip counts total, active, top-level, and how many products are still uncategorised. Categories are soft structure: a product can live without one, but a tidy shelf sells better.

Products

Open /dashboard/shop/products and click Add product. The form captures the name, an SKU (unique per school), a description, a category, the selling price, the cost price (this is what drives cost-of-goods-sold on the ledger), a tax rate, the opening stock, a low-stock threshold, a visibility, and an is-available switch. The vital strip shows the product count, total stock value (stock × price), low-stock items, and how many are hidden.

Visibility has four levels — public, school_only, staff_only and hidden — so a staff-discount item or an internal-only product never appears on the parent storefront. Deleting a product is a soft delete: the row is stamped with a deletion time rather than removed, because past orders reference it and the books must always be able to name what was sold.

An order at the store carries two independent statuses, and learning to read them is the whole job of the desk at /dashboard/shop/orders.

Payment status answers "has the school been paid?" — one of pending, paid, partial, refunded, failed, or cancelled. Fulfilment status answers "has the goods left the shelf?" — one of pending, preparing, ready, delivered, returned, or cancelled. A blazer paid for online but not yet collected is paid + pending; the same blazer once bagged and handed over is paid + delivered.

The desk is a set of one-click transitions that walk the order forward: Mark paid (pending → paid), → preparing, → ready, → delivered. Each row shows the customer — a linked student where the order is for a child, otherwise the typed customer name — and a customer type of student, parent, staff, or external. A detail dialog opens the line items: the product-name snapshot, quantity, unit price and any variant key, all frozen at the moment of sale so a later price change never rewrites history.

Two things happen automatically as the status moves. When an order becomes paid, its stock is reserved so it can't be oversold while it waits. When it becomes delivered, the reservation is released and stock is decremented — and if the product is linked to an inventory item, that operational stock decrements too, with a stock_out transaction written against the shop order.

This is the chapter that separates the YESS store from a cash tin. The moment an order is both paid and delivered, a balanced journal entry posts to the general ledger automatically — through a database trigger, not application code — and the store's books are never out of step with its sales.

The entry is built from the order's own numbers. The cash account is chosen by payment method (1100 Cash for cash, the bank account otherwise) and debited the total. Shop revenue account 4600 is credited the net of subtotal and discount. If there is tax, Sales Tax Payable 2200 takes its share. And because each line item froze its unit cost at sale time, the system also posts cost of goods sold — debit Shop COGS 5600, credit Inventory–Shop 1310 — so the margin on every blazer is on the books, not in someone's head.

The posting is idempotent: the journal-entry id is written back onto the order, and the trigger refuses to post twice. You can read every shop entry at /dashboard/accounting/journal and the accounts themselves at /dashboard/accounting/chart. Wallet-paid orders are the deliberate exception — they recognise revenue through the wallet ledger instead, so the school never double-counts the same sale.

Cash sales also flow into the cashier's day. The Z-report at /dashboard/finance/cashier-shifts folds cash-method shop orders into the till's expected takings, so the counter's declared cash reconciles against everything it actually sold — fees, canteen, and shop together.

A family can reach the store in two ways, and it is worth being clear about how they differ today.

At the counter (the order desk). A cash or wallet sale becomes a real shop order with line items, stock reservation, the fulfilment state machine, and — on delivery — the journal entry described above. This is the path the four store screens manage end to end.

From the parent portal. Parents browse the same catalogue at /portal/shop and check out online. Today that checkout takes a deliberately simpler route: it raises a charge invoice per category that the parent pays through the normal online-payment flow, reusing the fees machinery rather than creating a shop order. It is an honest way to let families pay from home — but it does not yet reserve shop stock or appear on the Orders desk. Unifying the two paths is on the roadmap.

A return is logged against an order and its line item, with a reason, and lands in the queue at /dashboard/shop/returns. The vital strip surfaces what needs attention: returns awaiting a decision, approved-but-unpaid refunds, and the count and value refunded in the last 30 days.

The manager's decision walks a four-state lifecycle — requested → approved → refunded, or rejected. Approve records the refund amount; Refund records the amount and method (cash, mobile_money, card, wallet, or a credit_note); Reject records a reason. Every decision stamps who processed it and when.

Every product carries its own stock count, a reserved-stock figure, and a low-stock threshold. The hub and the products screen both surface low stock so the manager reorders before a shelf runs dry. Reservation on payment and decrement on delivery keep the count honest through the order lifecycle.

A product can also be linked to an inventory item — the operational asset register the school already keeps. When a linked product is delivered, the inventory item's stock decrements in the same breath and a stock_out transaction is written referencing the shop order. The store and the storeroom stay in agreement.

Products support variants — sizes, colours — in the data model, and the order and ledger machinery honours them. The on-screen variant editor is still to come, so for now variant stock is set up by import; the chapter on what comes next says so plainly.

The store ships a real catalogue, a real order lifecycle, and a real ledger. The features below are built in part or scaffolded in the database, and are honestly not yet wired end to end. They appear here so you can plan around them.

The store is a small business inside the school, so it touches money, stock, and families.