What this module is for
Manage hostel buildings, blocks, rooms, beds, student allotments, checkouts, cancellations, history, and hostel reports.
Prerequisites
- Hostel permissions assigned
- Students active in the current school/session
- Hostel, room, and bed setup completed before allotment
Main screens
Step-by-step workflows
Prepare hostel setup
- Create hostel records.
- Add blocks if your school uses blocks.
- Create rooms under the correct hostel/block.
- Create beds and define monthly fee only at the bed setup level when applicable.
Allot a student
- Open Student Allotments.
- Select the student, hostel, room, and available bed.
- Confirm effective dates and status.
- Save the allotment.
- Use checkout or cancel actions only when the student leaves or the allotment was created incorrectly.
Operational detail
Permission checkpoints
- Hostel setup, rooms, beds, allotments, checkout, cancellation, and reports are permission controlled.
- Student allotment uses active student records and available bed status from the authenticated school.
- Hostel fee information follows the approved boundary and does not directly alter fee module tables.
Field guidance
Create the main hostel first. Use blocks only when the building structure needs another grouping level.
Rooms belong to a hostel and optional block. Room capacity should match the number of beds configured.
Beds carry availability status and optional monthly fee. Monthly fee should not be repeated unnecessarily during allotment.
Use the effective start date for the student stay. Checkout or cancellation should record the real lifecycle change.
Allot only active students from the school, and avoid duplicate active allotments for the same student.
Use occupancy, vacancy, and allotment history reports to review hostel utilization.
Validation and system feedback
- Beds must be active and available before allotment.
- A student should not have overlapping active hostel allotments.
- Room, bed, hostel, and student relationships are validated on save.
- Checkout and cancellation must use the allowed lifecycle action for the current allotment state.
Common mistakes to avoid
- Repeating monthly fee entry in allotment instead of maintaining it on the bed.
- Creating more beds than room capacity without reviewing setup.
- Cancelling a valid past stay instead of checking it out.
- Allotting inactive or wrong-session student records.
Recommended next steps
Screenshot plan
Final public screenshots will use synthetic QA data only. Sensitive values such as names, phone numbers, emails, admission numbers, document numbers, credentials, cookies, tokens, and internal IDs must be removed or redacted.
Important safety notes
Use normal Schoolixa workflows
Public docs explain user workflows only. They do not expose internal IDs, direct database operations, credentials, provider prompts, or private system configuration. Permission visibility in the interface does not replace server-side permission checks.