Module Technical Specifications

Technical detail for each functional area. For sales packaging (Core + add-ons), see module catalog.

Module 1 — Student Registration Core

Service: student-service, file-service · Phase: 1

Purpose

Capture student bio data, guardians, photo, documents; assign admission number; enroll in class per campus and academic year.

Workflow

1. Reception creates student draft → assigns campus, class, boarding type
2. Add 1+ guardians (link to existing parent user or invite new)
3. Upload photo + birth certificate → file-service
4. If health module enabled: parent completes health questionnaire (or deferred to portal)
5. Admin approves → status ACTIVE → publishes StudentEnrolled
6. fee-service consumes event → creates fee_account

Key rules

• Admission number unique per organization
• At least one primary guardian with phone for SMS
• Transfer between campuses creates new enrollment row, preserves history

Module 2 — Fees & Defaulters Add-on

Service: fee-service · Phase: 2

Purpose

Fee structures by class/boarding/term; track balances; payment claims (Option B); defaulter lists and SMS reminders.

Payment paths

• Option B (primary): Parent claim → bursar verify — see payment workflow
• Direct: Bursar records at counter → immediate receipt

Defaulters

Nightly job: students with OPEN/PARTIAL invoices past due_date. Dashboard by class, amount, days overdue. Bulk SMS via notification-service with opt-out respect.

Events

PaymentClaimSubmitted, PaymentReceived, InvoiceGenerated, DefaulterReminderSent

Module 3 — Invoices & Receipts

Service: fee-service, file-service · Phase: 2

Invoice generation

Bulk generate per term + class from fee_structures. Lines: tuition, boarding, meals, activity levy (configurable). Invoice number format: INV-{campus}-{year}-{seq}.

Receipt generation

On PaymentReceived, file-service renders PDF from template (school logo, TIN, line items). Stored in MinIO; metadata in notice-service document library.

Void & audit

Receipt void requires reason + director approval if amount > threshold. Original receipt marked VOIDED; audit log immutable.

Module 4 — Attendance

Service: attendance-service · Phase: 3

Workflow

Teacher marks class register daily (present/absent/late/excused). One record per student per date. Summary % on parent dashboard and report cards.

API

POST /attendance/sessions          { classId, date }
PUT  /attendance/sessions/{id}/marks  [{ studentId, status }]
GET  /attendance/students/{id}?from=&to=

Android (Phase 6)

Offline queue syncs when connectivity returns; conflict resolution: server wins on same date.

Module 5 — Finance & Accounting

Service: finance-service · Phase: 2 basic, 5 full

Phase 2

Auto journal on fee payment: debit Cash/MoMo, credit Fees Income. Expense entry with attachment.

Phase 5

Full chart of accounts, P&L, balance sheet, bank reconciliation. Fee payments reconcile against bursar daily totals and payment claims approved count.

Module 6 — Academics & Grading

Service: academic-service · Phase: 4

Grading

Configurable schemes: CBC A–E and legacy UNEB. Mark entry by subject teacher; class teacher reviews; admin locks term.

Report cards

Generate PDF → ReportCardPublished → parent document library. Homework assignments linked to class + subject.

Module 7 — Stock Keeping

Service: inventory-service · Phase: 3

Items (stationery, textbooks), quantities per campus store, stock in/out transactions, low-stock alerts to admin. Not linked to student fees unless configured.

Module 8 — Requirements Checklist

Service: student-service · Phase: 3

Per-class template (e.g. mattress, bible, calculator). On enrollment, checklist instantiated. Reception marks items received. Report: students missing items before term start.

Module 9 — Uniform Management

Service: inventory-service · Phase: 5

Catalog by size/colour, stock per campus, issue to student, track unpaid uniform charges on fee account optional.

Module 10 — Notice Board

Service: notice-service · Phase: 3

Campus notices with audience targeting (all, class, boarding). Rich text + attachments. Parent inbox with read tracking. Publishes NoticePublished → optional SMS.

Module 11 — Parent & Student Portal

Services: auth-service, notice-service, fee-service, file-service, academic-service · Phase: 2–4

Features

• One parent account → multiple children
• Student view via same login (homework, holiday packs)
• Document library: receipts, invoices, reports, circulars
• Payment claim submission (Option B)
• Fee balance and defaulter visibility
• Admin document distribution to one / group / all parents

Holiday access

Portal always on; homework tagged with availableFrom/availableUntil. Teachers schedule holiday pack publish on last day of term.

Technical APIs and payment flow: payment workflow · parent portal requirements

Module 12 — Student Health Records Add-on

Service: health-service · Phase: 3 · Full requirements

Purpose

Sensitive student health data for school-day care. Parents submit at registration, confirm on dashboard, upload doctor's note as proof. Only Health Records Access group (nurse + top admin) views full records.

Key rules

• Default deny — teachers, bursar, reception cannot view clinical data
• Parent confirmation timestamp required before record is official
• Doctor's note mandatory when allergies, medications, or chronic conditions declared
• Every read/export logged in health_access_audit
• Updates after confirm require re-confirmation + new note if conditions changed

Integration

Registration wizard adds health step; parent dashboard shows health card with status. Events: HealthRecordConfirmed, HealthReconfirmationRequired.

Extended modules (13–22)

Planning specifications — deploy as additional microservices when sold. See full roadmap with integration matrix.