Most schools, colleges and coaching institutes run academic operations across a spreadsheet for admissions, a separate register for timetables, a shared drive for ID cards and someone's memory for which batch a student actually sits in. Odoo's core contacts, hr and calendar apps give you people and events, but they have no concept of an enrollment ID, a program–course–batch hierarchy, an academic year split into terms, or a timetable that refuses to double-book a room or a teacher. The moment a registrar needs a headcount by batch, a year-end promotion run, or a clash-free period grid, native Odoo runs out of road — education is a domain model, not a CRM contact with a tag.

School & College Core ERP is the foundation layer we build to close that gap. We author a proper set of Odoo models — education.student, education.faculty, education.program, education.course, education.subject, education.batch, education.academic.year and education.term — with the relational integrity education actually needs. A student carries a unique, sequence-generated enrollment ID (via ir.sequence), a photo, guardian res.partner links and a lifecycle state field that moves applicant → enrolled → alumni through guarded transitions. Faculty records extend hr.employee so a teacher is one person across payroll and academics, with subject and department assignment. Programs, courses, subjects and batches/sections are modelled as first-class records related through Many2one/One2many fields, so the data forms a real academic tree rather than free text.

Technically, the app is a standard installable addon with its own __manifest__.py declaring dependencies on base, mail, contacts, hr and calendar. Business rules live in models.Model classes using @api.depends computes for headcount and batch-strength KPIs, @api.constrains for the timetable clash checks (a room or a faculty member cannot occupy two overlapping period slots), and @api.onchange for registrar ergonomics. Every model ships access rules in ir.model.access.csv plus ir.rule record rules so a teacher sees only their batches, a registrar sees the institution, and a parent/student sees only their own record — mapped to dedicated security groups (admin, registrar, teacher, student, parent). Multi-campus and group-institution setups are handled with company_id scoping and Odoo's multi-company rules. Student and staff QWeb ID cards render as configurable PDF reports with an embedded QR payload, and a batch-promotion wizard (TransientModel) rolls a whole cohort into the next academic year in one governed action. Because this is the shared base, all of our add-on education apps (admissions, attendance, examinations, fees) depend on these models rather than reinventing them — and everything is reachable over the XML-RPC/JSON-RPC API for integrations.

Delivery is build-to-order: nothing ships until we run a scoping call, agree the exact program/course/batch structure, campuses, roles and ID-card layout, then build your version against your target Odoo (17.0, 18.0 or 19.0; Community or Enterprise), demo it on a staging database, run UAT, and cut over with a rollback plan. Typical delivery is one working week from confirmed scope. Pricing starts from $999 (indicative, single-company base scope); multi-campus/multi-company configuration, deeper localization, and larger student-data migration volumes increase the quoted scope. You receive a fixed quote after the scoping call — never a surprise bill.