School Fee Invoicing and Parent Portal

What it does

School Management keeps the school's records. This module is the layer that turns them into money, reporting and a parent-facing front door.

Fees come first. A fee statement gains an Invoice button that raises a genuine customer invoice against the guardian, on the school's own journal, which the bursar posts and collects through Odoo accounting like any other invoice. The statement links to that invoice; it never derives its numbers from it, and it never pretends to be it. That distinction is the whole design. Because the two are separate, they can disagree, and the module says so out loud: every statement carries a reconciliation state of Not Invoiced, Reconciled or Needs Review, plus a Difference figure showing what the office recorded less what the ledger actually collected. Needs Review has a screen of its own that opens already filtered, so chasing discrepancies is a list rather than an investigation.

On top of that sit two SQL-backed analysis models, one over fee charges and one over examination results, and a School Dashboard built from them. Twenty-six KPI cards cover enrolment, attendance, examinations, fees, arrears by age, invoicing and reconciliation, and the transport, hostel and library registers. Below them, twenty-one tiles chart the same data: fifteen graphs, four pivots and two working lists, every one of them a real Odoo view rather than a picture of one, so they regroup and expand in place. One set of filters, academic year, grade level, class or section and a date range, re-queries the whole page at once.

Guardians get their own way in. Grant Portal Access on a guardian record creates their login and sends the invitation; from then on they land on My Children and can read each child's profile, attendance, results, library loans and fee statements with a total due.

The interesting engineering is in who sees what, because this module puts money and children's records on the same screens.

The dashboard is assembled per user. Before anything is drawn, the server answers which models this user may read, and a section they may not read is left out entirely rather than shown as zero, on the principle that a fabricated zero is a wrong number and a missing card is an honest one. The chart tiles follow the same rule for a harder reason: a tile is a view on a model, so embedding one the caller cannot read does not produce an empty chart, it produces an access error in the middle of the dashboard. Tiles are therefore built only for models the user can read. A teacher opening the dashboard sees enrolment, attendance and examination figures for their own classes, and no money at all.

The portal is read only by construction. There is no field a parent can write and no record a parent can create, and fourteen record rules scope every model a guardian can reach, so the limit holds over the API rather than only in the pages. The rules are deliberately conservative about work in progress: attendance comes from submitted registers, results from completed examinations, and fees from confirmed statements, so a draft register or an unreleased mark cannot leak to a family through a page that was only meant to show finished work. Closing an account is its own action. Archiving a guardian blanks their pages without closing their login, which reads exactly like a revocation and is not one, so the form says so in as many words and points at Revoke Portal Access instead.

The accounting side is guarded at the database rather than in Python. One invoice per statement is a unique constraint, which is the only version of that rule a double click, a second tab or an RPC call cannot get around. The Accountant role carries both the school Administrator group and Odoo's own Billing group, so one account covers the whole path from statement to posted invoice without handing anyone superuser rights.

It ships 141 automated tests across invoicing, reconciliation, report security, dashboard scoping and portal access, and demo data that installs uninvoiced on purpose so the module still comes up cleanly on a database with no chart of accounts.

Who it's for

Schools already running School Management in Odoo that have outgrown fee statements as record-keeping and want the fees in the ledger, the ledger reconciled against the office, and the whole picture on one screen. It suits a bursar who needs to know which families are behind and by how long, an administrator who wants examination and attendance trends without exporting to a spreadsheet, and a school that wants parents to stop phoning the office to ask what their child scored or what is still owed.

It is not an online payment product. Parents read; they do not pay through these pages. It is also not a replacement for School Management, which it extends and requires.