Why Schools Run on Spreadsheets (and Why That Breaks at 200 Students)
Every school starts the same way: student names in a Google Sheet, course schedules printed from Word, and fee tracking in a bank statement. It works until it doesn't. Around 200 students, the cracks become canyons — enrollment forms go missing, double-booked classrooms cause chaos, parents call the front desk because they can't tell which installment is overdue, and report cards are assembled manually from five different grade spreadsheets the night before distribution day.
Dedicated Student Information Systems (SIS) exist, but they're expensive, rigid, and disconnected from finance. You pay $15–$40 per student per month for a system that still can't generate an invoice. So the accounting team runs a parallel system and someone manually reconciles tuition payments against enrollment records every month. Data drifts. Parents get incorrect statements.
Odoo 19 solves this by treating education as a vertical configuration of existing ERP modules. Students extend res.partner. Enrollment is a sales-like workflow with approval stages. Fee collection maps to Accounting with installment plans and automated reminders. Timetables use the Planning module. Transcripts render as QWeb PDF reports. And because it's one database, a student's enrollment status, course schedule, grades, and payment history are all queryable from a single screen.
Building a Student Record Model with Guardian Links and Academic History
The student model is the spine of every education module. In Odoo 19, we create an edu.student model that links to res.partner for contact infrastructure — addresses, email, phone, portal access — while adding education-specific fields: student ID, date of birth, grade level, guardian contacts, medical notes, and enrollment status. This approach means invoicing, email templates, and portal login all work out of the box because Odoo already knows how to handle partners.
from odoo import models, fields, api
from dateutil.relativedelta import relativedelta
class EduStudent(models.Model):
_name = 'edu.student'
_description = 'Student Record'
_inherit = ['mail.thread', 'mail.activity.mixin']
_rec_name = 'display_name'
partner_id = fields.Many2one(
'res.partner', string='Contact', required=True,
ondelete='restrict', tracking=True,
)
student_id_number = fields.Char(
string='Student ID', required=True, copy=False,
default=lambda self: self.env['ir.sequence'].next_by_code(
'edu.student'
),
)
date_of_birth = fields.Date(string='Date of Birth', tracking=True)
age = fields.Integer(string='Age', compute='_compute_age', store=True)
gender = fields.Selection([
('male', 'Male'), ('female', 'Female'),
('other', 'Other'),
], string='Gender', tracking=True)
grade_level = fields.Selection([
('k', 'Kindergarten'),
('1', 'Grade 1'), ('2', 'Grade 2'),
('3', 'Grade 3'), ('4', 'Grade 4'),
('5', 'Grade 5'), ('6', 'Grade 6'),
('7', 'Grade 7'), ('8', 'Grade 8'),
('9', 'Grade 9'), ('10', 'Grade 10'),
('11', 'Grade 11'), ('12', 'Grade 12'),
], string='Grade Level', tracking=True)
guardian_ids = fields.Many2many(
'res.partner', string='Guardians',
relation='edu_student_guardian_rel',
)
primary_guardian_id = fields.Many2one(
'res.partner', string='Primary Guardian',
tracking=True,
)
enrollment_ids = fields.One2many(
'edu.enrollment', 'student_id', string='Enrollments',
)
state = fields.Selection([
('prospect', 'Prospect'),
('enrolled', 'Enrolled'),
('graduated', 'Graduated'),
('withdrawn', 'Withdrawn'),
], string='Status', default='prospect', tracking=True)
active = fields.Boolean(default=True)
@api.depends('date_of_birth')
def _compute_age(self):
today = fields.Date.today()
for rec in self:
if rec.date_of_birth:
rec.age = relativedelta(today, rec.date_of_birth).years
else:
rec.age = 0
def action_view_enrollments(self):
return {
'type': 'ir.actions.act_window',
'name': 'Enrollments',
'res_model': 'edu.enrollment',
'domain': [('student_id', '=', self.id)],
'view_mode': 'list,form',
'context': {{'default_student_id': self.id}},
} The mail.thread mixin gives you a complete audit trail — every status change, grade entry, and guardian update is logged with user and timestamp. The guardian_ids Many2many field lets a student have multiple guardians (divorced parents, grandparents with custody), while primary_guardian_id determines who receives fee invoices and report cards by default.
Some education modules create a standalone edu.guardian model with duplicated contact fields. This breaks Odoo's portal access, invoicing, and email infrastructure. By using res.partner for guardians, parents can log into the Odoo portal with their email, view invoices, download report cards, and communicate with teachers — all through standard Odoo features that require zero custom portal development.
Enrollment Workflow: From Application to Confirmed Seat with Approval Stages
Enrollment is a multi-step process: document collection, eligibility checks, seat verification, fee quotation, and class assignment. In Odoo 19, the enrollment model tracks every stage and automates transitions.
class EduEnrollment(models.Model):
_name = 'edu.enrollment'
_description = 'Student Enrollment'
_inherit = ['mail.thread', 'mail.activity.mixin']
_order = 'create_date desc'
student_id = fields.Many2one(
'edu.student', required=True, tracking=True,
)
academic_year_id = fields.Many2one(
'edu.academic.year', string='Academic Year',
required=True, tracking=True,
)
program_id = fields.Many2one(
'edu.program', string='Program / Grade',
required=True, tracking=True,
)
section_id = fields.Many2one(
'edu.section', string='Section',
)
state = fields.Selection([
('draft', 'Application'),
('documents', 'Documents Pending'),
('review', 'Under Review'),
('accepted', 'Accepted'),
('fee_pending', 'Fee Pending'),
('confirmed', 'Confirmed'),
('cancelled', 'Cancelled'),
], default='draft', tracking=True)
document_ids = fields.One2many(
'edu.enrollment.document', 'enrollment_id',
string='Required Documents',
)
fee_invoice_id = fields.Many2one(
'account.move', string='Fee Invoice', readonly=True,
)
notes = fields.Html(string='Internal Notes')
def action_submit_documents(self):
for rec in self:
missing = rec.document_ids.filtered(
lambda d: not d.attachment_id
)
if missing:
raise models.ValidationError(
f"Missing: "
f"{{', '.join(missing.mapped('name'))}}"
)
rec.state = 'review'
def action_accept(self):
for rec in self:
rec.state = 'accepted'
rec.student_id.state = 'enrolled'
def action_generate_fee_invoice(self):
for rec in self:
lines = [(0, 0, {
'product_id': f.product_id.id,
'quantity': 1,
'price_unit': f.amount,
'name': f.name,
}) for f in rec.program_id.fee_line_ids]
inv = self.env['account.move'].create({
'move_type': 'out_invoice',
'partner_id':
rec.student_id.primary_guardian_id.id,
'invoice_line_ids': lines,
})
rec.fee_invoice_id = inv.id
rec.state = 'fee_pending' The workflow mirrors a sales pipeline with clear entry/exit criteria. The action_submit_documents method blocks progression until every required document has an attachment. Once accepted, action_generate_fee_invoice creates a real accounting invoice from the program's fee structure — finance never manually creates tuition bills.
Add a _check_seat_availability constraint on the enrollment model that counts confirmed enrollments per section against edu.section.max_capacity. Fire this on action_accept so admissions knows immediately if a section is full before sending the acceptance letter. Waitlist management becomes a filtered view of enrollments in "Under Review" for full sections.
Course and Class Scheduling: Programs, Subjects, and Teacher Assignment
A school's academic structure is hierarchical: Academic Year → Program (Grade) → Section → Subjects → Sessions. The program defines which subjects are taught and how many hours per week. The section is a group of students. The session is a single class meeting with a teacher, room, and time slot.
class EduProgram(models.Model):
_name = 'edu.program'
_description = 'Academic Program / Grade'
name = fields.Char(required=True) # e.g. "Grade 10"
code = fields.Char(required=True) # e.g. "G10"
academic_year_id = fields.Many2one(
'edu.academic.year', required=True,
)
subject_ids = fields.One2many(
'edu.program.subject', 'program_id',
string='Subjects',
)
section_ids = fields.One2many(
'edu.section', 'program_id', string='Sections',
)
fee_line_ids = fields.One2many(
'edu.program.fee', 'program_id', string='Fee Structure',
)
class EduProgramSubject(models.Model):
_name = 'edu.program.subject'
_description = 'Subject in Program'
program_id = fields.Many2one('edu.program', required=True)
subject_id = fields.Many2one('edu.subject', required=True)
weekly_hours = fields.Float(
string='Hours / Week', required=True, default=3.0,
)
teacher_id = fields.Many2one(
'hr.employee', string='Default Teacher',
domain="[('department_id.name', '=', 'Faculty')]",
)
is_elective = fields.Boolean(string='Elective', default=False)
class EduSection(models.Model):
_name = 'edu.section'
_description = 'Class Section'
name = fields.Char(required=True) # e.g. "Section A"
program_id = fields.Many2one('edu.program', required=True)
homeroom_teacher_id = fields.Many2one(
'hr.employee', string='Homeroom Teacher',
)
max_capacity = fields.Integer(
string='Max Students', default=30,
)
enrolled_count = fields.Integer(
compute='_compute_enrolled_count',
)
room_id = fields.Many2one('edu.room', string='Default Room')
def _compute_enrolled_count(self):
Enrollment = self.env['edu.enrollment']
for rec in self:
rec.enrolled_count = Enrollment.search_count([
('section_id', '=', rec.id),
('state', '=', 'confirmed'),
]) The edu.program.subject junction model connects a subject to a program with its weekly hour allocation and default teacher. This drives timetable generation: Grade 10 needing 5 hours of Math across 2 sections means 10 teacher-hours of math slots. The is_elective flag splits students into different tracks without separate sections.
Automatic Timetable Generation: Constraint-Based Scheduling with Odoo Planning
Manual timetable creation for 20 sections, 40 teachers, and 15 rooms takes 2–3 full weeks every semester — and the result is still riddled with conflicts. The generator below uses a greedy constraint-satisfaction approach that handles common cases in seconds.
from odoo import models, fields, api
from odoo.exceptions import UserError
class EduTimetableGenerator(models.TransientModel):
_name = 'edu.timetable.generator'
_description = 'Timetable Generator Wizard'
academic_year_id = fields.Many2one(
'edu.academic.year', required=True,
)
program_ids = fields.Many2many(
'edu.program', string='Programs to Schedule',
)
SLOTS = [
('08:00', '08:45'), ('08:50', '09:35'),
('09:50', '10:35'), ('10:40', '11:25'),
('13:00', '13:45'), ('13:50', '14:35'),
]
DAYS = ['monday', 'tuesday', 'wednesday',
'thursday', 'friday']
def action_generate(self):
Session = self.env['edu.timetable.session']
# Clear existing draft sessions
Session.search([
('academic_year_id', '=', self.academic_year_id.id),
('state', '=', 'draft'),
]).unlink()
teacher_busy = {} # (day, slot_idx): set of teacher ids
room_busy = {} # (day, slot_idx): set of room ids
for program in self.program_ids:
for section in program.section_ids:
for ps in program.subject_ids:
hours_needed = int(ps.weekly_hours)
hours_placed = 0
day_usage = {d: 0 for d in self.DAYS}
for day in self.DAYS:
if hours_placed >= hours_needed:
break
# Max 2 hours of same subject per day
if day_usage[day] >= 2:
continue
for idx, (start, end) in enumerate(
self.SLOTS
):
key = (day, idx)
t_set = teacher_busy.setdefault(
key, set()
)
r_set = room_busy.setdefault(
key, set()
)
teacher = ps.teacher_id
room = section.room_id
if (teacher.id in t_set
or room.id in r_set):
continue
Session.create({
'academic_year_id':
self.academic_year_id.id,
'section_id': section.id,
'subject_id': ps.subject_id.id,
'teacher_id': teacher.id,
'room_id': room.id,
'day_of_week': day,
'time_start': start,
'time_end': end,
'state': 'draft',
})
t_set.add(teacher.id)
r_set.add(room.id)
hours_placed += 1
day_usage[day] += 1
break
if hours_placed < hours_needed:
raise UserError(
f"Could not place all hours for "
f"{{ps.subject_id.name}} in "
f"{{section.name}}. "
f"Placed {{hours_placed}}/"
f"{{hours_needed}}."
)
return {{
'type': 'ir.actions.client',
'tag': 'display_notification',
'params': {{
'title': 'Timetable Generated',
'message': 'Review draft sessions before publishing.',
'type': 'success',
}},
}} The algorithm greedily assigns each subject to the first slot without teacher or room conflicts. The day_usage dictionary caps the same subject at 2 hours per day for better learning distribution. Sessions are created in draft state so the coordinator reviews before publishing. The UserError on failure pinpoints exactly which subject/section couldn't be placed.
The greedy approach works for schools with up to ~30 sections and ~50 teachers. Beyond that, integrate Google OR-Tools' CP-SAT solver as a Python dependency. Define teacher availability, room capacity, and break periods as constraints, then let the solver find an optimal assignment. The Odoo wizard interface stays the same — only the placement engine changes.
Fee Collection with Installment Plans, Late Penalties, and Automated Reminders
Most institutions offer installment plans and need to track partial payments, apply late fees, and send reminders. In Odoo 19, this maps directly to Accounting's payment terms, follow-up actions, and invoice splitting. No custom payment engine required.
class EduFeePlan(models.Model):
_name = 'edu.fee.plan'
_description = 'Tuition Fee Installment Plan'
name = fields.Char(required=True)
program_id = fields.Many2one('edu.program', required=True)
line_ids = fields.One2many(
'edu.fee.plan.line', 'plan_id', string='Installments',
)
late_fee_product_id = fields.Many2one(
'product.product', string='Late Fee Product',
)
late_fee_amount = fields.Monetary(
string='Late Penalty', currency_field='currency_id',
)
grace_days = fields.Integer(default=7)
currency_id = fields.Many2one(
'res.currency',
default=lambda self: self.env.company.currency_id,
)
class EduFeePlanLine(models.Model):
_name = 'edu.fee.plan.line'
_description = 'Fee Installment Line'
_order = 'sequence'
plan_id = fields.Many2one('edu.fee.plan', required=True)
sequence = fields.Integer(default=10)
name = fields.Char(required=True)
due_date = fields.Date(required=True)
percentage = fields.Float(string='% of Total', required=True)
invoice_id = fields.Many2one(
'account.move', string='Invoice', readonly=True,
)
state = fields.Selection([
('pending', 'Pending'), ('invoiced', 'Invoiced'),
('paid', 'Paid'), ('overdue', 'Overdue'),
], default='pending', compute='_compute_state', store=True)
@api.depends('invoice_id', 'invoice_id.payment_state', 'due_date')
def _compute_state(self):
today = fields.Date.today()
for line in self:
if not line.invoice_id:
line.state = 'pending'
elif line.invoice_id.payment_state == 'paid':
line.state = 'paid'
elif line.due_date and line.due_date < today:
line.state = 'overdue'
else:
line.state = 'invoiced' Each line tracks its own invoice and payment state. The _compute_state method marks lines overdue automatically. The real automation comes from scheduled actions:
<odoo>
<data noupdate="1">
<!-- Generate installment invoices 7 days before due -->
<record id="cron_generate_fee_invoices"
model="ir.cron">
<field name="name">
Education: Generate Installment Invoices
</field>
<field name="model_id"
ref="model_edu_fee_plan_line"/>
<field name="state">code</field>
<field name="code">model._cron_generate_invoices()</field>
<field name="interval_number">1</field>
<field name="interval_type">days</field>
<field name="numbercall">-1</field>
</record>
<!-- Apply late fees after grace period -->
<record id="cron_apply_late_fees"
model="ir.cron">
<field name="name">
Education: Apply Late Fee Penalties
</field>
<field name="model_id"
ref="model_edu_fee_plan_line"/>
<field name="state">code</field>
<field name="code">model._cron_apply_late_fees()</field>
<field name="interval_number">1</field>
<field name="interval_type">days</field>
<field name="numbercall">-1</field>
</record>
</data>
</odoo>The first cron generates invoices 7 days before due and emails the guardian automatically. The second checks for overdue invoices past the grace period and appends a late fee line. Combined with Odoo's built-in follow-up reports (Accounting → Customers → Follow-ups), you get a three-tier reminder system: pre-due invoice, post-due reminder, and escalation letter.
Parent Self-Service Portal: Grades, Invoices, and Communication in One Login
The number one complaint from parents isn't tuition cost — it's lack of visibility. They want to see grades without waiting for report card day, check fee balances without calling the front desk, and communicate with teachers without phone tag. Because guardians are res.partner records, they already have Odoo portal access with invoices and payment history. We extend it with a custom education dashboard showing courses, grades, attendance, and upcoming fee dates.
<odoo>
<template id="portal_my_home_education"
name="Education Portal Dashboard"
inherit_id="portal.portal_my_home"
priority="30">
<xpath expr="//div[hasclass('o_portal_my_home')]"
position="inside">
<div class="row mt-4"
t-if="student_records">
<div class="col-12">
<h3>My Children</h3>
</div>
<t t-foreach="student_records"
t-as="student">
<div class="col-md-6 col-lg-4 mb-3">
<div class="card h-100">
<div class="card-body">
<h5 class="card-title"
t-out="student.partner_id.name"/>
<p class="mb-1">
<strong>Grade:</strong>
<span t-out="student.grade_level"/>
</p>
<p class="mb-1">
<strong>Section:</strong>
<span t-out="student.section"/>
</p>
<p class="mb-2">
<strong>Status:</strong>
<span t-att-class="
'badge bg-success'
if student.state == 'enrolled'
else 'badge bg-secondary'"
t-out="student.state"/>
</p>
<a class="btn btn-sm btn-primary"
t-attf-href=
"/my/student/{{student.id}}">
View Details
</a>
</div>
</div>
</div>
</t>
</div>
</xpath>
</template>
</odoo> The portal controller queries edu.student records where the current user's partner is in guardian_ids. A parent with two children sees both cards. Each links to a detail page with the student's timetable, grade history, attendance percentage, and outstanding fee balance.
Define ir.rule records restricting portal users to students where they are listed as a guardian. Without this, any portal user could enumerate student IDs in the URL. The rule: [('guardian_ids', 'in', [user.partner_id.id])] applied to the portal group on edu.student, edu.transcript.line, and edu.enrollment.
Transcript and Grade Management: Entry, GPA Calculation, and PDF Report Cards
Grades flow from teachers into transcript lines, which aggregate into term GPAs, which render into PDF report cards. The data model is straightforward: each edu.transcript.line links a student, subject, term, and grade. The GPA calculation is a computed field that weights grades by credit hours. The PDF report card is a QWeb template that pulls everything together.
class EduTranscriptLine(models.Model):
_name = 'edu.transcript.line'
_description = 'Student Grade Entry'
_order = 'term_id, subject_id'
student_id = fields.Many2one(
'edu.student', required=True, ondelete='cascade',
)
term_id = fields.Many2one(
'edu.term', string='Term', required=True,
)
subject_id = fields.Many2one(
'edu.subject', required=True,
)
credit_hours = fields.Float(
related='subject_id.credit_hours', store=True,
)
score = fields.Float(string='Score (%)')
letter_grade = fields.Char(
compute='_compute_letter_grade', store=True,
)
grade_point = fields.Float(
compute='_compute_letter_grade', store=True,
)
teacher_id = fields.Many2one(
'hr.employee', string='Graded By',
)
remarks = fields.Text()
@api.depends('score')
def _compute_letter_grade(self):
"""Standard 4.0 GPA scale."""
for rec in self:
s = rec.score or 0
if s >= 93:
rec.letter_grade, rec.grade_point = 'A', 4.0
elif s >= 90:
rec.letter_grade, rec.grade_point = 'A-', 3.7
elif s >= 87:
rec.letter_grade, rec.grade_point = 'B+', 3.3
elif s >= 83:
rec.letter_grade, rec.grade_point = 'B', 3.0
elif s >= 80:
rec.letter_grade, rec.grade_point = 'B-', 2.7
elif s >= 77:
rec.letter_grade, rec.grade_point = 'C+', 2.3
elif s >= 73:
rec.letter_grade, rec.grade_point = 'C', 2.0
elif s >= 70:
rec.letter_grade, rec.grade_point = 'C-', 1.7
elif s >= 67:
rec.letter_grade, rec.grade_point = 'D+', 1.3
elif s >= 60:
rec.letter_grade, rec.grade_point = 'D', 1.0
else:
rec.letter_grade, rec.grade_point = 'F', 0.0
class EduStudent(models.Model):
_inherit = 'edu.student'
cumulative_gpa = fields.Float(
compute='_compute_cumulative_gpa', store=True,
digits=(3, 2),
)
@api.depends('transcript_line_ids.grade_point',
'transcript_line_ids.credit_hours')
def _compute_cumulative_gpa(self):
for student in self:
lines = student.transcript_line_ids.filtered(
lambda l: l.credit_hours > 0
)
total_credits = sum(lines.mapped('credit_hours'))
if total_credits:
weighted = sum(
l.grade_point * l.credit_hours
for l in lines
)
student.cumulative_gpa = (
weighted / total_credits
)
else:
student.cumulative_gpa = 0.0 The GPA uses a weighted average — a 4-credit Mathematics grade counts twice as much as a 2-credit PE grade. The store=True parameter means GPA recalculates whenever grades change, so reporting queries never recompute. For PDF report cards, create a QWeb template iterating transcript lines grouped by term, using t-call="web.external_layout" for consistent school branding.
Enrollment: applications by stage, seat utilization, conversion rate. Finance: billed vs collected, overdue aging, late fee revenue. Academic: GPA by section, subject pass rates, grade distribution. HR: weekly teacher hours, sections per teacher, grading backlog.
3 Education Module Mistakes That Cause Semester-Start Chaos
No Seat Capacity Check on Enrollment Confirmation
Without a constraint, the system confirms 45 students into a 30-seat section. The teacher discovers this day one when desks run out. Re-assigning means cascading timetable changes, updated invoices, and angry parents.
Add an @api.constrains('section_id', 'state') method that raises ValidationError if confirmed enrollments exceed max_capacity. Display remaining seats as a computed badge on the section form.
Generating All Installment Invoices at Enrollment Time
Some implementations create all 4 quarterly invoices at enrollment time. The parent sees a massive outstanding balance, follow-up reminders fire for invoices not yet due, and mid-year fee adjustments (scholarships, sibling discounts) require modifying or crediting multiple posted invoices.
Generate invoices one at a time, 7 days before each due date, using the cron described above. The fee plan tracks installments as plan lines with due dates and percentages, but invoices are only created when actually due. This keeps the portal clean, prevents premature follow-ups, and makes mid-year adjustments trivial.
Letting Teachers Edit Grades After Transcript Publication
If transcript lines remain editable after report cards are distributed, a teacher can silently change a grade weeks later. The parent's PDF shows B+ but the database says C. The GPA no longer matches the published report card, and accreditation auditors flag it as a data integrity issue.
Add a state field to edu.transcript.line with "draft", "submitted", and "published" values. Published lines become read-only via attrs. Post-publication changes require a "Grade Amendment" wizard that logs who changed it, from what, to what, and why — then updates the transcript line via chatter.
What a Unified Education Platform Saves Your Institution
Replacing disconnected tools with a single Odoo-based platform delivers measurable gains:
Automated document tracking, seat capacity checks, and fee invoice generation cut enrollment processing from 3 weeks to under 10 days. Admissions staff handle 40% more applications in the same time window.
Pre-due invoice generation, automated email/SMS reminders, and late fee penalties push on-time collection from a typical 70% to 92%. For a 500-student school at $5,000 annual tuition, that's $550,000 collected on schedule instead of chased manually.
Automated timetable generation with conflict resolution replaces 2-3 weeks of manual scheduling. The coordinator reviews and adjusts the generated draft in 2 hours instead of building from scratch.
Beyond operational savings, a unified parent portal reduces front-desk call volume by 60%. Parents check grades, download invoices, and view timetables themselves. Staff freed from phone duty focus on student welfare and admissions outreach — work that actually grows the school.