Chapter 13

Store & Inventory

school_adminprincipal

Overview

School Store & Inventory runs everything the school sells or lends to students and staff — uniforms, textbooks, lab equipment, sports gear — from one catalog through to the fee challans billable items generate. It's organised into six areas, matching the tab strip at the top of every Store screen: Catalog (what you stock), Purchasing & Transfers (how stock enters the school and moves between branches), Issue & Return (who has what), Billing (charging a parent for a billable item), Reports (everything above, summarised), and Access (delegating day-to-day store operations to specific staff). Every screenshot in this chapter is a real screen from a real walkthrough — a Sports Equipment category, a serialized Basketball Hoop Set, and a billable House T-Shirt were created live for this chapter, not staged.

Key concepts

Category (Group)A named bucket items belong to — Uniform, Books, Stationery, Sports Equipment. It is also the unit Store Access (13.6) scopes a delegated staff member to, so how you split items into Categories decides how finely you can later delegate.
ReturnableWhether an issued unit is expected back — a textbook or lab microscope is returnable; a notebook or exercise book is consumed and never returned. Only returnable items appear on Pending Returns.
SerializedOnly meaningful on a returnable item — whether each physical unit is individually tagged and tracked (a specific projector, a specific microscope) rather than just a bare quantity count. A serialized item's stock is COUNT of untagged/in-stock units, not a running total.
BillableWhether issuing this item to a student charges a fee. A billable item needs a price (13.4 Class-wise Price List) before it can actually be sold — issuing one with no configured price is refused, not silently free.
Selection vs. IssuanceA Selection (13.4) is the billing event — a parent is opted in and a fee challan is generated immediately. An Issuance (13.3) is the physical handover. For a billable item these are normally two separate moments: select now, hand the item over later once it's in stock or the fee is paid — the Fulfillment Queue (13.4) is where that handover happens.
Branch vs. Category scopingStock, purchases, and issuances are branch-scoped (Main Branch and North Campus keep separate stock counts). The catalog itself — Categories, Items, pricing — is shared school-wide. A delegated Store Manager (13.6) can be scoped by branch, by Category, or both at once.

13.1.1 Category Manager

Every item belongs to exactly one Category. Categories are admin/principal-only to create or edit — they're the boundary Store Access (13.6) scopes against, so letting a delegated Store Manager create their own Categories would let them grant themselves broader access than intended.

Category Manager listing the school's existing Categories — Figure 13.1. Category Manager — Books, Lab & Electronics Equipment, Stationery, Uniform, and the new Sports Equipment Category created for this walkthrough.

Sports Equipment Category created and listed as Active — Figure 13.2. A new Category is just a name — Active by default, deactivate rather than delete to preserve the items already assigned to it.

13.1.2 Item Catalog Manager

Each item's Returnable, Serialized, and Billable checkboxes (13's Key Concepts above) decide which later screens even apply to it — a non-returnable item never appears on Pending Returns, a non-billable item never appears on Class-wise Pricing. Serialized can only be turned on once Returnable already is.

Item Catalog Manager listing all items across every Category — Figure 13.3. Item Catalog Manager — every item school-wide, regardless of Category, with its own Returnable/Serialized/Billable flags.

New Item form with Returnable and Serialized checked — Figure 13.4. Serialized is disabled (greyed out) until Returnable is checked first — a non-returnable item has nothing to track individual units of.

Basketball Hoop Set created in the Item Catalog — Figure 13.5. The new Basketball Hoop Set — returnable and serialized, so 13.1.4 (Asset Unit Manager) and 13.3 (Issue & Return) both track it by individual tagged unit, not a bare count.

One catalog, every branch

Categories and Items are shared school-wide — Main Branch and North Campus see the exact same catalog. What differs by branch is stock: how many units of an item are actually sitting at each branch, which is what 13.2 (Purchasing & Transfers) and 13.5 (Stock Report) track.

13.1.3 Size-Matrix Generator

Uniform items in particular repeat across a whole class range × gender × size grid — rather than creating "Class 1 Boys Shirt S", "Class 1 Boys Shirt M" … one at a time, the Size-Matrix Generator creates the whole grid in one action. Re-running it over a range that already has some sizes created is safe — it previews New vs. Already Exists and only creates the New ones.

Size-Matrix Generator preview grid before confirming — Figure 13.6. The live preview updates as soon as a Group, class range, and at least one gender are chosen — every row shows whether it's New or Already Exists before anything is actually created.

Size-Matrix batch generated — Figure 13.7. Confirm creates every "New" row from the preview in one action — this batch made 12 new Uniform items (LKG/UKG × Boys/Girls × S/M/L) from a single form.

13.1.4 Asset Unit Manager

For a serialized item, this is where the individual tagged units live — each one's status (In Stock, Issued, Retired) and its own auto-generated or manually-entered tag. Tags are what a printable label sticks to a physical projector, microscope, or (here) a basketball hoop set.

Asset Unit Manager showing the Basketball Hoop Set's three tagged units — Figure 13.8. Three real units — BASK-00025 through BASK-00027 — auto-tagged when the purchase in 13.2.1 was recorded. One was later transferred to North Campus (13.2.3), one issued to a student (13.3.1).

13.2.1 Record Purchase

Recording a purchase is how stock enters the school — quantity, unit cost, vendor, and invoice number for the audit trail. A serialized item's purchase also creates that many tagged Asset Units in the same action, either auto-generated (ITEM-00001 style) or with tags entered manually if the vendor's own labels are being reused.

Record Purchase form for a serialized item, showing the Asset Tags section — Figure 13.9. Selecting a serialized item reveals the Asset Tags section — auto-generate is the default; switching to manual entry requires exactly one tag per unit.

Purchase recorded confirmation, 3 Basketball Hoop Sets — Figure 13.10. A real purchase — 3 units at ₹8,500 each from Sunrise Sports Co. — with three auto-generated tags shown right on the confirmation.

13.2.2 Purchase History

Every purchase ever recorded, filterable by item, Category, vendor, branch, and date range — the Opening Balance flag (not exercised in this walkthrough) distinguishes a genuine new purchase from a one-time starting-stock entry made when the module was first set up.

Purchase History showing the Basketball Hoop Set purchase — Figure 13.11. Purchase History — every restock, real vendor and invoice number included, not just an internal reference number.

13.2.3 Transfer Stock

Moves stock — or, for a serialized item, one specific tagged unit — from one branch to another. This is the one Store screen where branch-scoping deliberately works differently: a branch-scoped Store Manager (13.6) is still allowed to move stock out of their own branch even though the destination is a different branch, since a transfer is fundamentally something their own branch's stock is party to.

Transfer Stock form, Basketball Hoop Set, Main Branch to North Campus — Figure 13.12. For a serialized item the specific Asset Unit is picked by tag, not a bare quantity — the unit's branch changes, not a separate counter.

Transfer recorded confirmation — Figure 13.13. One real unit — BASK-00025 — moved from Main Branch to North Campus. Asset Unit Manager (13.1.4) reflects the new branch immediately.

13.2.4 Transfer History

Every inter-branch transfer, filterable the same way Purchase History is — useful for reconciling why a branch's stock count moved without a new purchase behind it.

Transfer History showing the real Main Branch → North Campus transfer — Figure 13.14. Transfer History — a full audit trail of stock movement between branches, independent of any single item's own detail screen.

13.3.1 Issue Item

Hands one item to one student or staff member, with the live available-stock count shown before you commit. A returnable item requires an Expected Return Date; a serialized item requires picking the specific unit being handed over.

Issue Item — Student/Staff recipient toggle and search — Figure 13.15. Recipient search works by name or admission number, or narrow first by Class/Section — the same picker pattern used throughout Store & Inventory.

Issue Item form filled — Basketball Hoop Set, specific Asset Unit, return date set — Figure 13.16. Once a serialized item is chosen, the Asset Unit dropdown lists exactly the units currently in stock at the recipient's branch — nothing already issued or transferred away shows up.

Issued confirmation with Print Issue Slip — Figure 13.17. A real issuance — one Basketball Hoop Set unit issued with a 14-day expected return. Print Issue Slip generates a branded PDF receipt for the recipient.

13.3.2 Bulk Issue

Issues the same item to an entire class/section roster in one action — for a serialized item, the next in-stock unit is auto-assigned to each eligible student in turn. A student who's already been issued the item, or one the school has run out of stock for, is skipped and reported by name rather than silently failing the whole batch.

Bulk Issue roster preview for Digital Microscope, Class LKG — Figure 13.18. The roster loads live once an item and class are chosen — every active student in that class/section, with anyone already holding the item flagged before you commit.

Bulk issue result — N issued, M skipped — Figure 13.19. A real bulk issue against Class LKG's full roster — the result summary names exactly who succeeded and, where relevant, why anyone was skipped.

13.3.3 Recipient Issuance Ledger

Everything one specific student or staff member currently holds, plus their full issuance history — the screen to check before assuming someone has (or doesn't have) an item outstanding.

Recipient Issuance Ledger for the student who received the Basketball Hoop Set — Figure 13.20. Currently Held splits out anything still outstanding; Full History below it never disappears, even once an item is returned.

13.3.4 Pending Returns

Every open issuance of a returnable item, across every recipient, with a Record Return Event action right on the row — Returned, Damaged, or Lost, with an optional recovery charge for the latter two. For a student recipient, a recovery charge becomes a real fee challan immediately, the same billing mechanism 13.4's Student Item Selection uses.

Pending Returns listing every open issuance — Figure 13.21. Every returnable item currently out — Overdue is flagged in red the moment the expected return date passes, same badge 13.5.5's Overdue Returns Report reads from.

Record Return Event — Damaged outcome with a ₹1,500 recovery charge — Figure 13.22. Recovery Charge only appears once the outcome is Damaged or Lost — a plain Returned outcome has nothing to charge for.

Return event recorded, issuance closed — Figure 13.23. The Basketball Hoop Set unit is back — the return event closes this issuance and, for a student recipient, the recovery charge is already sitting on a real fee challan.

A recovery charge on a staff recipient works differently

Staff have no fee-challan account to bill — a recovery charge against a staff recipient is just tracked as Paid/Unpaid on the issuance itself, toggled manually once they've settled it, rather than generating a challan.

13.3.5 Bulk Return

The Bulk Issue counterpart — marks an entire roster's open issuances of one item Returned in a single action. Unlike Bulk Issue, which decides eligibility have algorithm, which rows to include here is a deliberate human choice (uncheck anyone whose item needs a Damaged/Lost outcome instead, and record that one separately via Pending Returns).

Bulk Return roster for Digital Microscope, Class LKG — Figure 13.24. Every row is checked by default — unchecking one excludes it from this bulk action, for a student whose return needs individual handling instead.

Bulk return completed — Figure 13.25. The same Class LKG roster Bulk Issue (13.3.2) issued to, now returned in one action — Pending Returns no longer lists any of them.

13.4.1 Class-wise Price List

A billable item needs a price before it can be sold — either one flat price for every class, or a different price per class (a Class 10 lab coat costing more than a Class 1 one, say). No price configured for a student's class means Student Item Selection refuses the sale outright rather than charging ₹0.

Class-wise Price List for the new billable House T-Shirt — Figure 13.26. Price List before a price is set — every billable item in the catalog appears here, whether priced yet or not.

A flat ₹450 price set on House T-Shirt — Figure 13.27. One flat price applies to every class unless a class-specific override is added on top of it — the flat price is always the fallback.

13.4.2 Student Item Selection

Opts a student — or, via the roster's own bulk action, a whole class — into a billable item. This is the actual billing moment: selecting immediately generates a real, standalone fee challan, independent of the school's regular termly fee cycle.

Student Item Selection roster for House T-Shirt, Class 1 — Figure 13.28. The resolved price for this class is shown before anyone is selected — ₹450, the flat price from 13.4.1, since no Class 1-specific override was set.

A student selected into House T-Shirt — Figure 13.29. Selecting one student generates their fee challan immediately — visible to their parent the same way any other fee challan is.

13.4.3 Fulfillment Queue

Every student with an active, not-yet-handed-over Selection, across every billable item — fee status and issuance status side by side, with an Issue Now action that hands the item over and closes the loop. If the item is set to require payment first, Issue Now stays blocked until the challan is actually paid.

Fulfillment Queue listing pending Selections — Figure 13.30. The queue spans every billable item, not just one — filterable by item/class/fee status when it gets long.

House T-Shirt fulfilled via Issue Now — Figure 13.31. Issue Now delegates straight to the same Issue Item logic 13.3.1 uses — the Selection's existing challan is what gets fulfilled, never a second, duplicate charge.

13.5.1 Stock Report

The module's own dashboard landing page — every item's available stock per branch, with a Low Stock flag once it drops to or below the item's own reorder threshold.

Stock Report across every item and branch — Figure 13.32. Non-serialized items show a plain available count; serialized items break down by status (In Stock / Issued / Retired) instead, since "available" means something different for them.

13.5.2 Issuance History Report

Every issuance ever made, across every item and recipient, with its resolution state — Open, Returned, Partially Resolved, Damaged, or Lost — so a full history is one screen, not scattered across each item's own detail view.

13.5.3 Purchase/Spend Report

Total spend broken down by item, Category, vendor, branch, or date range — the budgeting-side counterpart to Purchase History's plain audit-trail listing.

Purchase/Spend Report with breakdown tables — Figure 13.34. Grand total plus four breakdown tables (item/Category/vendor/branch) computed from the same purchase records Purchase History (13.2.2) lists individually.

13.5.4 Physical Stock Audit

Records a real physical headcount against what the system expects — the variance is applied directly to that item's available-stock formula, correcting for shrinkage, breakage, or a miscount without needing a manual stock adjustment entry. Serialized items are excluded — there's no single number to reconcile a headcount against when every unit is individually tracked.

Physical Stock Audit form for Digital Microscope — Figure 13.35. The "system expects" figure is shown live, sourced from the same available-stock formula the Stock Report uses, before the physical count is even entered.

Audit recorded, variance applied — Figure 13.36. A real audit — the counted figure becomes the new available stock immediately, and the variance is kept as a permanent record of what changed and when.

13.5.5 Overdue Returns Report

Every currently-overdue open issuance — the same Overdue badge Pending Returns (13.3.4) shows inline, gathered into one dedicated list with a Days Overdue column. This is also what feeds the automatic overdue-return reminder notifications covered in Chapter 12.

13.5.6 Fee Collection by Item

How much has been billed and actually collected, per billable store item, for an academic year — the Store module's own view onto the same Total Due / Total Collected split the Fee module's own dashboards use.

Fee Collection by Item, showing House T-Shirt — Figure 13.38. The real ₹450 House T-Shirt challan from 13.4.2 shown here as Total Due — Total Collected updates once the parent actually pays it.

13.5.7 Asset Register

Every serialized unit school-wide, in one list — tag, item, branch, status, and current holder if it's issued. The audit-facing counterpart to Asset Unit Manager's own per-item view.

Asset Register filtered to Basketball Hoop Set — Figure 13.39. All three real tagged units from this chapter — one at North Campus (transferred, 13.2.3), one issued and returned (13.3.1/13.3.4), one still in stock at Main Branch.

13.6.1 Store Access

Day-to-day Store & Inventory operations can be delegated to specific staff without making them a school admin or principal — scoped by branch (their own JWT branch claim), by Category, or both together, composed as an AND, not a replacement of one dimension by the other. Category CRUD itself and the financial reports (Purchase/Spend, Fee Collection by Item) stay admin/ principal-only regardless of any grant — Categories are the scoping boundary a grant is measured against, and money-touching reports are deliberately excluded from delegation.

Store Access screen before any grant — Figure 13.40. Any staff member not already an admin/principal can be granted access — the dropdown lists every eligible candidate.

Access granted to a real staff member — Figure 13.41. A fresh grant starts Unrestricted — sees every Category — until scoped down explicitly, the same permissive-if-unconfigured default every dimension of this grant uses.

Grant scoped to one Category — Figure 13.42. Scoped to 1 Category — this staff member now only sees items, purchases, and issuances belonging to that one Category, composed with their existing branch scope if they have one.

Does this delegated Store Manager see a given screen or item?

Composed as an AND across whichever dimensions are configured — not an OR, and not a replacement of one for the other.

Access granted

No Category scope rows configured for this grant

Unrestricted on the Category dimension — every Category is visible (still subject to their branch scope, if one applies).

Access granted

Category scope rows exist AND the item's Category is one of them

Visible — the item/purchase/issuance is within their delegated Category.

Access denied

Category scope rows exist AND the item's Category is not among them

Not visible, even if their branch scope would otherwise allow it — Category scoping is a real restriction once configured, not just a filter.

Revoking clears the Category scope too

Revoking a Store Access grant and later re-granting the same person starts them fresh at Unrestricted — an old Category scope from a previous grant is never silently inherited.

No AI anywhere in this module, by design

Reorder thresholds and overdue flags are static, admin-configured rules — School Store & Inventory deliberately has no predictive/ML feature anywhere in it, a direct product decision documented in the module's own spec.

A few catalog screens cache briefly for speed

Categories, Items, and Prices are cached for up to a day in the installed app for faster loading — a change you just made can take a few seconds to appear on a screen you had already open before the refresh; reloading the page always shows the current data immediately.