System Guide

A prospective student fills the public form: name, guardian, contact, program, city, prior education, optional date of birth, gender and a certificate upload. No login needed.

Staff review the application (uploaded documents are viewable), then approve, reject, or waitlist - singly or in bulk. The waitlist is a real queue with positions; 'Promote from waitlist' re-decides to approved. The applicant's own text is never overwritten by staff notes.

One click turns an approved applicant into a student with a gap-free registration number (e.g. EAK2026-0011). Guardians are matched by phone so one mother of three girls stays ONE guardian record. Details can be corrected later via Edit - fixing a reg number safely renames the login too.

Pick program → batch → section (fullness shown against capacity). The same dialog transfers a student between classes later. One active enrolment per batch is enforced by the database itself.

Provision a login per student, per guardian, or for a whole batch of guardians at once. Staff get logins too (Provision login on the staff profile) - that is what lets teachers into Moodle. One account opens both the ERP portal and Moodle (OIDC single sign-on).

Create fee types (Tuition, Admission…), combine them into a per-batch structure, then generate a month's challans for the whole batch in one action. Generation is duplicate-proof (even across Urdu/English month spellings), skips exited students, and uses only the newest active structure.

Record the request (percent or agreed amount), then accept or reject. Acceptance is not just a status: the discount lands on the student's open challans immediately and on every future challan at generation time - linked, so you can always see which scholarship produced which discount.

Desk payments are recorded and verified in one step (receipt emailed). Students can submit a bank-deposit slip from the portal: it stays pending - no receipt number, no balance change - until staff verify it (number minted then) or reject it. A wrongly recorded payment can be reversed with a mandatory reason.

Mark a section's register and submit. Submitted registers are locked - but can be reopened for correction with a reason (the reason stays on the record). Duplicate registers for the same day are impossible; sessions attach themselves to the current term.

Create weighted assessments, enter marks, then Compute results for the term (per section or whole term - multi-section terms compute correctly). Publishing stamps the sheets, locks them against silent recompute, and notifies students. Rechecks go through an approval queue - an approved recheck really updates the mark and the result sheet.

Issue one certificate or a whole batch. Every certificate carries a scannable QR of its public verification page - anyone can confirm it is genuine without logging in. The certificate stays valid forever, independent of logins.

Year end: promote a batch (with per-student selection) into the next one - if the target batch has no fee structure yet, the system tells you so billing is never silently missed. Graduating creates the alumni record by itself. Suspending or withdrawing a student requires a reason and truly closes the door: login banned, sessions killed, Moodle suspended, future billing stopped. Re-admission reverses all of it.