Bootstrap & MySQL Student Management

SCHOOL PROJECT Functional Scope and Technical Implementation Plan Current Implementation Direction: Laravel + Bootstrap 1. Project Overview Create a web-based school management system that will manage the entire school year: students, teachers, classes, profiles, lessons, attendance, student payments, teacher earnings/payments, and administrative reports. The system should be modular so that additional features can be added later. 2. Main Users User Main Functions Administrator Manage the school, academic years, teachers, students, classes, lessons, attendance, finances, and reports. Teacher View classes/programs, lessons, attendance, completed lessons, earnings, and payments. Student View profile, class, attendance, fees, payments, and outstanding balances. 3. Main MVP Modules Module Basic Module/Data Entry Authentication and Users Login, logout, password reset, roles, profile, account status, basic security. School and Academic Year School settings, academic years, start/end dates, active year, access to historical data. Students Student registration, profile, class/profile assignment, status, enrollment history. Transferring students to other classes in subsequent years. A student can be in multiple classes. Teachers Teacher registration, profile, employment/status data, class assignment, salary configuration. A teacher can be in multiple classes and programs, and each class participation in a given school year earns a different fee. Teachers are billed for the number of teaching hours completed in each class in a given month. Classes and Profiles Class creation, profile/class type, teacher assignment, student enrollment, pricing rules. In a separate class, students pay a rate per hour of lessons, and so does the teacher. Lessons Lesson planning/creation, date/time, class, profile, teacher, lesson status, completion/cancellation. Attendance Teacher and student attendance for lessons; reasons for absence and comments. Student Billing Amount due based on class/profile/lesson policies, payment records, balances, and billing history. Teacher Pay Completed lessons payable, rate payable, adjustments, amount paid, amount outstanding. Administrative Reports Attendance, lessons, student balances, teacher billing, annual summaries, and exports. Student Portal Profile, class, attendance, lessons, payment/billing status, history. Teacher Portal Information about classes, lessons/programs, attendance, completed lessons, earnings, and payment history. Audit and Activity Important changes, financial activities, and administrative activity history. 4. Basic Document Workflow Academic Year → Classes/Profiles → Students and Teachers → Enrollment/Assignments → Lessons → Attendance → Student Fees → Student Payments → Teacher Salaries → Teacher Payments → Reports 5. Financial Logic The system should keep operational records and financial transactions separate. Rates should be stored with effective dates to ensure historical calculations do not change when a new rate is introduced. Student Fee = applicable student rate + confirmed attendance/lesson policy. Teacher Salary = applicable teacher rate + confirmed attendance/lesson policy. Student fees are recorded separately from fees. Teacher payments are recorded separately from their earnings. Adjustments/refunds should be auditable and should not silently change historical transactions. 6. Suggested Database Entities Basic Financial/Operational users, roles, permissions student_fees, student_payments academic_years payment_allocation teachers, students teacher_salaries, teacher_payments classes, class_profiles adjustments enrollment, teacher_assignments lessons, attendance audit_logs derived reports/queries 7. Technology and Architecture Backend: Laravel. Frontend: Bootstrap + Blade, initially. Database: MySQL/MariaDB (or PostgreSQL, if hosting requires it). Use Laravel authentication, policies/permissions, and form requests. Store business calculations in service/action classes, not controllers. Use database transactions for financial operations. Use automated unit/functional testing for billing calculations. Use Git in test and production environments. 8. Future Module – Building and Scheduling After MVP, add buildings, classrooms, room capacity, room availability, recurring class times, classroom assignments, and detect conflicts in teacher/class/room schedules. 9. Development Phases Phase Work 1. Discovery Review existing records and finalize business rules. 2. Basics Laravel, Bootstrap, authentication, roles, and permissions. 3. Academic Years, teachers, students, classes, profiles 7. Technology and Architecture Backend: Laravel. Frontend: Bootstrap + Blade, initially. Database: MySQL/MariaDB (or PostgreSQL, if hosting requires it). Use Laravel authentication, policies/permissions, and form requests. Store business calculations in service/action classes, not controllers. Use database transactions for financial operations. Use automated unit/functional testing for billing calculations. Use Git in test and production environments. 8. Future Module – Building and Scheduling After MVP, add buildings, classrooms, room capacity, room availability, recurring class times, classroom assignments, and detect teacher/classroom/room scheduling conflicts. 9. Development Phases Phase Work 1. Discovery Review existing records and finalize business rules. 2. Basics Laravel, Bootstrap, authentication, roles, and permissions. 3. Academic Years, teachers, students, classes, profiles, and enrollment. 4. Lessons Lessons and teacher/student attendance. 5. Finance Student fees/payments, and teacher earnings/payments. 6. Portal and Reports Teacher/student dashboards and administrative reports. 7. Testing and Launch Data migration, security, testing, UAT, and production. 8. Future Buildings, classrooms, scheduling, notifications, and integrations. 10. Technical Issues Does a student pay 50% (a parameter in the student's file) for their absence? If another teacher completes a le