Evaluate a school management system through 3 connected demonstrations: an applicant becomes an enrolled student, the correct fee record follows that enrolment and each user sees only the information needed for their task. A feature list or attractive parent dashboard does not establish that those records remain consistent.
Frappe Education and ERPNext documentation provides the examples below. It does not prove that a proposed installation meets a Zambian school’s legal, accounting or safeguarding requirements. This guide uses fictional records and reports no implementation, learner data processing or professional review performed for a school.
How should admissions and fee records remain connected?
Start with the admissions decision rather than an empty student table. A prospective learner, an approved application and an enrolled student represent different states. Decide which record is authoritative at each stage and who may advance it. Importing a spreadsheet into a student list does not automatically establish that the admissions process was followed.
The official Student Applicant guide describes preparation involving an academic term, academic year and programme. It then describes creating an applicant with the relevant programme and contact information. Those relationships matter because a name alone does not identify the intended course or period. Make the demonstrator show how the application connects to the correct academic context.
The guide describes an online web form creating an applicant in Applied status, with approval or rejection followed by enrolment where appropriate. Keep those transitions explicit in the proposed process. An application arriving through a form should not silently be represented as admission, and a rejected application should not become an active student simply because a fee record exists.
It also states that enrolment creates a student linked to the applicant and changes the application status to Admitted. The documented restriction on later status changes is a reason to test corrections carefully. Do not supply instructions to delete a real student record merely to reverse a mistake; establish the appropriate correction process for the installed version before use.
The Fees guide relates fees to the student, fee categories and a fee structure. It describes selecting a structure and populating its components. Ask the demonstrator to show why the selected structure belongs to that learner and period. A plausible-looking balance can still be attached to the wrong programme or student.
Version scope is important. The same page describes changes to invoicing from version 15.1.0 and a sales-order option from version 15.3.0. Do not combine those statements into one timeless claim about every installation. Record the proposed version and the exact fee-to-accounting behaviour demonstrated by that configuration.
Use this original connected-record test with fictional data. It is a requirements artefact, not a completed school workflow.
| Scenario | Relationship to demonstrate | Failure to retain |
|---|---|---|
| Application received | Applicant linked to intended programme and period | Form submission treated as automatic admission |
| Admission decision | Authorised decision and applicant history | Unexplained stage change |
| Enrolment | Student linked to the original applicant | Duplicate learner created |
| Fee preparation | Student, period and structure agree | Correct-looking charge on the wrong record |
| Payment recording | Payment relates to the intended obligation | Balance changed without traceable evidence |
| Correction | Reason and resulting records remain understandable | History removed to conceal an error |
How should permissions and exceptions be tested?
Map the roles before configuring access. Admissions staff, teachers, finance staff and administrators may need different information and actions. Do not grant every user broad access merely because several departments work with the same learner. A proposed system should explain the task each permission enables and the information that remains outside that role.
ERPNext’s role-based permission guide describes roles, document types, field permission levels and document stages. It also describes restricting users to particular documents. Use those controls as a concrete example to evaluate, not a guarantee that the proposed school setup already applies the right boundaries.
Demonstrate access with ordinary accounts. Ask an admissions user to perform the intended applicant task and then attempt a finance action they should not perform. Ask a finance user to work with the relevant fee record without assuming access to every other learner detail. A negative test is useful evidence about the actual configuration; an administrator-only demonstration is not enough.
Test a duplicate applicant and a corrected identity field. Define how staff recognise that the records concern the same learner and how the change reaches connected records. Retain uncertainty where a match is not clear. The system should not merge learners based only on similar names or quietly create a second student when an application is resubmitted.
Inspect fee notifications before enabling them. The Fees guide describes an option to send a payment request. Establish who receives it, which record supplies the contact information and whether it is appropriate to send in the scenario. Use controlled test destinations so a rehearsal does not accidentally contact families or imply that a fictional obligation is real.
Keep payment evidence separate from an edited balance. Ask how a recorded payment links to the obligation and what happens when it is entered against the wrong learner. This guide states no monetary example, prescribed accounting treatment or guarantee of a bank integration. The actual proposed arrangement needs its own supported evidence.
Plan migration around the relationships the school needs to retain. Applicants, enrolled learners, academic periods and outstanding obligations should not be flattened into one unstructured list. Rehearse representative records and inspect the rejected or unresolved cases. A successful import message cannot establish that every relationship or historical meaning survived.
Minimise personal information in evaluation materials. Use fictional learners and avoid copying identity records or sensitive family details into a general trial. The purpose is to prove the workflow and access controls, not to create a second uncontrolled store of school data. This is an operational recommendation, not a legal compliance certification.
End with an acceptance note naming the version, scenarios observed, permissions tested and unresolved local requirements. Keep manual tasks visible and assign responsibility for them. For related application scoping, see Spout’s web development page. Get started with the connected-record test and the administrative problem you need to solve, keeping learner records and account credentials outside the initial enquiry.
By Spout Team. AI-assisted drafting by Codex, grounded in the linked primary documentation.