Skip to content

ERP registration: the admissions desk — detailed form, registration fee, printable form

A school front office registering a walk-in applicant runs one desk workflow: fill the registration form (the full particulars, not a contact card), collect the registration fee against a numbered receipt, and print the form for the parent to sign and the office to file. Kwilo's admissions module had the pipeline (enquiry → application → merit → admit) but not the desk: the application form was ~14 fields in a cramped dialog, there was no way to take the fee, and nothing printed. This doc covers the registration module built to close that — modelled on the SchoolEarth flow a prospect school demoed and OpenEduCat's admission-register fee pattern.

Status: built (phases 1–3) — Product Mindset Gate passed 2026-07-31 (prospect-demo-driven feature parity). Code PR MySetu-AI/kwiloai_webapp#1469 (branch feat/erp-registration); this doc lands with it.

Related: erp-institution-standard-fields.md (the letterhead: logo, UDISE/affiliation numbers printed on the form), erp-student-standard-fields.md (the SIS demographics registration carries forward on admit), erp-form-builder-and-custom-fields.md (proposed: makes this form's field set per-institution configurable — the ~21 fields here seed its built-in catalogue and this layout seeds its first template; it also carries the photo upload + webcam path listed as a non-goal below).

Why this exists

  1. Who asked: A live sales context — screenshots from a school's screen-share of SchoolEarth (their current ERP) set the bar: a detailed registration form, "Save with registration fee", and a printed registration form with declarations and an office-use block. Feature parity for the workflow the school actually runs daily.
  2. User pain: The front-office clerk registering a walk-in couldn't capture the particulars (parents, class applying, APAAR/SATS/PEN, prior school…), couldn't take the ₹500 registration fee against a receipt, and had nothing to hand the parent — so the desk stayed on the old ERP or paper.
  3. Cost of not doing it: Registration is the first workflow a school office evaluates; failing it fails the demo regardless of the rest of the product.
  4. Validated: Competitor-benchmarked against the school's current system in an active evaluation.
  5. Worked when: a clerk completes a walk-in end-to-end in Kwilo — prefill from the enquiry → form → fee + receipt → print. Sean Ellis: remove it and the office asks "how do I print the registration form and take the fee?"

Personas

The front-office clerk at a K-12 school: registers walk-ins during admission season, collects the fee in cash/UPI, hands the parent the printed form, files a copy.

The parent: signs the declaration on the printed form; gets the fee receipt.

The accounts clerk: expects registration fees in the same day-book/receipt sequence as every other collection — not a side ledger.

Mental model

Registration = the existing Application, upgraded. No new entity, no rename of tables — the UI surface says "Registration" (the school's vocabulary) while the admit/merit pipeline is untouched. Three integrations do the work:

  • Round fee (OpenEduCat's register-fee pattern): the fee amount is configured once on the AdmissionRound (registration_fee_paise); every application in the round inherits it at collection time (still overridable — concessions happen).
  • One receipts ledger: fee_payments takes exactly one payer — student_profile_id XOR application_id (DB CHECK). Registration receipts share the org's REC###### sequence and appear in the fees collection register with a payer_type label. No parallel receipt trail.
  • Printables (WeasyPrint, hall-ticket pattern): the registration form PDF (letterhead with UDISE/affiliation from the institution standard fields, particulars grid, declaration + signature lines, For-Office-Use block with the fee receipt) and a generic A5 receipt PDF that serves both payer types.

User flows

  • Walk-in: New registration → full-page sectioned form (Basic / Parents & guardian / Contact / Class applying / Identity & language / Previous school / Logistics & health) → Save & collect fee → fee dialog (amount prefilled from the round) → receipt toast + receipt PDF downloads → Print form.
  • From an enquiry: the enquiry's "create application" lands on the form with name/phone/email prefilled; saving converts the enquiry.
  • Duplicate print: any application row (or its edit page) re-downloads the form PDF at any time.
  • Search: name / registration number, plus registered-before / registered-after date filters (on the editable registration_date, which supports back-dating paper registrations).
  • Admit: unchanged; mother_tongue, religion, apaar_id now carry onto the SIS student profile.

Design decisions

  • Pragmatic ~21-field set, no Aadhaar. APAAR/SATS/PEN cover the education statutory IDs; Aadhaar would reopen the encryption/parental-consent debt the student-fields work deliberately closed.
  • Fee on the round + unified FeePayment ledger over standalone columns on the application — one receipt sequence, one day-book, fee reports see registration income.
  • Full-page form over growing the dialog — 30+ fields, a fee flow and print don't fit a modal. The create dialog was retired; legacy ?fromEnquiry= deep links forward to the page.
  • class_applying/stream are free text (like AdmissionRound.program) — placement into real academic structures happens post-admission, not at the desk.
  • Offline fee modes only at the desk; online payment rides the existing Razorpay order flow later.

Non-goals (v1)

  • Photo upload flow — the photo_url column and the form's photo box exist, but no upload endpoint/UI yet; the printed box doubles as a paste-a-photo spot, as paper forms do.
  • Webcam capture, sibling linkage, SMS/WhatsApp notification toggles, structured class FK, online (Razorpay) registration fee — each has a clean later path. Photo upload, webcam capture and sibling linkage (a repeating group) are now scoped in the form builder epic (kwiloai_webapp#1476), issues #1483 and #1480.
  • Fee refunds for registrations ride the existing fees refund flow.

Risks & mitigations

  • fee_payments payer relaxation touches money queries. Mitigated: student financials filter on student_profile_id (NULL rows drop out naturally); the collection register was explicitly reworked to outer-join both payers and is regression-tested; the DB CHECK makes a payerless/double-payer row impossible.
  • PDF availability: WeasyPrint needs native libs; endpoints 503 cleanly on lib-less deploys (hall-ticket precedent), and PDF tests skip locally / run in CI.

Rollout

  1. erp0023 (additive) deploys ahead of UI safely.
  2. Round fee is opt-in per round: rounds without a fee keep today's behaviour; ad-hoc amounts still collectable per application.
  3. Follow-ups tracked above (photo flow first — the desk asks for it).

Changelog

  • 2026-08-01 — Built phases 1–3 (data+fee+search, printables, full-page form). Gate passed 2026-07-31; design locked: pragmatic fields / round fee + unified ledger / full-page form / upload-only photo deferred. Code PR kwiloai_webapp#1469.