# **Sports Module System Design**

# **Chapter 1 — Sports Activity Module Overview**

## **1.1 Introduction**

The **Sports Activity Module** is a comprehensive subsystem within the Club ERP that manages all sports-related operations, including training activities, recreational activities, players, trainers, academies, facilities, scheduling, attendance, medical approvals, subscriptions, treasury integration, and reporting.

The purpose of this module is to centralize every sports operation into a single integrated platform that allows club employees to efficiently manage daily activities while ensuring complete integration with the Membership Module, Treasury Module, Medical Module, and Reporting System.

The system must support clubs of different sizes, from small sports academies to large multi-sport organizations operating dozens of facilities simultaneously.

---

## **1.2 Module Objectives**

The Sports Activity Module has been designed to achieve the following objectives:

* Digitize all sports-related operations.  
* Eliminate manual scheduling and paperwork.  
* Simplify player registration.  
* Simplify trainer management.  
* Organize sports into structured programs and groups.  
* Manage facilities and their schedules visually.  
* Prevent scheduling conflicts.  
* Track player attendance accurately.  
* Track trainer assignments.  
* Integrate all financial operations with the Treasury Module.  
* Improve facility utilization.  
* Generate detailed operational and financial reports.  
* Provide a scalable architecture that supports future expansion without redesigning the system.

---

## **1.3 Module Scope**

The Sports Activity Module manages every process beginning with the creation of sports and facilities and ending with reporting and analytics.

The module includes:

* Sports Management  
* Facilities Management  
* Mirror (Facility Scheduling) System  
* Programs Management  
* Groups Management  
* Player Management  
* Trainer Management  
* Academy Management  
* Medical Management  
* Attendance Management  
* Subscription Management  
* Recreational Sports  
* Facility Bookings  
* Treasury Integration  
* Dashboard & Analytics  
* Reports  
* Notifications  
* User Permissions  
* Audit Logs

---

## **1.4 Sports Categories**

The system shall support two completely independent categories of sports.

### **A. Training Sports**

Training Sports are sports where players register into structured training programs under the supervision of one or more trainers.

Examples include:

* Football  
* Swimming  
* Basketball  
* Karate  
* Gymnastics  
* Volleyball  
* Tennis

Characteristics:

* Organized into Programs.  
* Programs contain Groups.  
* Groups contain Players and Trainers.  
* Monthly subscriptions.  
* Attendance tracking.  
* Medical approval required.  
* Treasury approval required before activation.  
* Long-term enrollment.

---

### **B. Recreational Sports**

Recreational Sports are sports where customers reserve facilities temporarily without joining a training program.

Examples include:

* Bowling  
* Padel  
* Football Pitch Rental  
* Table Tennis  
* Billiards  
* Squash Court Booking

Characteristics:

* Reservation-based.  
* No attendance tracking.  
* No medical approval required.  
* Payment may occur after the activity finishes.  
* Supports hourly pricing and per-game pricing.  
* Supports individual and institutional bookings.

---

## **1.5 Core Hierarchy**

Every training activity inside the system follows a fixed hierarchical structure.

Sport  
    ↓  
Facility  
    ↓  
Program  
    ↓  
Group  
    ↓  
Players  
    ↓  
Attendance

Each level depends on the previous level and cannot exist independently.

For example:

Swimming

↓

Olympic Pool

↓

2012 Program

↓

Group A

↓

Players

↓

Attendance

This hierarchy ensures organized management of all training activities and prevents inconsistent data relationships.

---

## **1.6 Main System Workflow**

The normal workflow for a new training activity is as follows:

1. Create Sport.  
2. Create one or more Facilities.  
3. Configure each Facility.  
4. Create Programs for the Sport.  
5. Create Groups within each Program.  
6. Register Trainers.  
7. Register Players.  
8. Upload required player documents.  
9. Assign Players to Programs.  
10. Complete Treasury payment.  
11. Activate Player enrollment.  
12. Assign Groups to Facility schedules using the Mirror System.  
13. Record attendance for every training session.  
14. Renew subscriptions monthly.  
15. Generate operational and financial reports.

---

## **1.7 System Integration**

The Sports Activity Module is not an isolated system. It integrates with several ERP modules.

### **Membership Module**

When registering an existing club member using their membership number, the system shall automatically retrieve all available personal information, including identification details, contact information, guardian information (if applicable), and membership status.

This prevents duplicate data entry and ensures synchronization between the Membership Module and the Sports Activity Module.

---

### **Treasury Module**

All financial operations originating from the Sports Activity Module shall be transferred automatically to the Treasury Module.

Examples include:

* New player subscriptions.  
* Monthly renewals.  
* Recreational sport bookings.  
* Institution bookings.  
* Additional service fees.  
* Penalties (if applicable).  
* Refunds (if supported).

The Sports Module shall never directly receive payments. All payment processing must be handled exclusively through the Treasury Module to maintain centralized financial control.

---

### **Medical Module**

Medical staff shall review uploaded medical certificates independently from sports staff.

The Sports Module shall only display the current medical status of each player without allowing sports employees to approve or reject certificates.

Medical approval determines the player's eligibility for continued participation according to the business rules defined in the Medical Management chapter.

---

### **Reporting Module**

All operational data generated by the Sports Module shall be available for reporting, including:

* Revenue.  
* Attendance.  
* Facility utilization.  
* Program performance.  
* Trainer workload.  
* Player statistics.  
* Booking statistics.  
* Medical compliance.  
* Subscription analytics.

---

## **1.8 User Roles**

Different users shall have different permissions depending on their responsibilities.

Typical roles include:

* Reception Employee  
* Sports Administrator  
* Sports Manager  
* Trainer  
* Medical Employee  
* Treasury Employee  
* Academy Manager  
* Club Manager  
* System Administrator

The detailed permissions for each role will be defined in the Permissions chapter.

---

## **1.9 Design Principles**

The Sports Activity Module shall be designed according to the following principles:

* Simplicity of use.  
* Minimal data entry.  
* Clear workflow.  
* Fast navigation.  
* High scalability.  
* Strong data validation.  
* Complete auditability.  
* Full integration with the ERP ecosystem.  
* Prevention of duplicate data.  
* Accurate reporting.  
* Conflict-free scheduling.

# 

# 

# **Chapter 2 — Complete System Workflow**

## **2.1 Introduction**

Before defining each feature individually, it is essential to establish the complete operational workflow of the Sports Activity Module. This chapter explains how every component of the module interacts with the others, ensuring a clear understanding of the entire business process from system setup to daily operations.

The workflows described in this chapter represent the standard operational procedures that the system shall support. Individual chapters will later define the detailed logic, validation rules, permissions, and edge cases for each process.

---

# **2.2 Initial System Setup Workflow**

Before the Sports Activity Module can be used, administrators must complete the initial configuration in the following order:

1. Create Sports.  
2. Create Facilities for each Sport.  
3. Configure each Facility (working hours, grid size, availability, etc.).  
4. Create Programs for each Sport.  
5. Create Groups within each Program.  
6. Register Academies (optional).  
7. Register Trainers.  
8. Assign Trainers to Groups.  
9. Configure pricing for Programs.  
10. Configure recreational sports pricing (if applicable).

The system shall prevent users from skipping mandatory setup steps. For example:

* A Program cannot be created before its Sport exists.  
* A Group cannot be created before its Program exists.  
* A Trainer cannot be assigned to a non-existent Group.  
* A Mirror schedule cannot be created before the Facility exists.

---

# **2.3 Sports Hierarchy**

The Sports Module follows the following hierarchy:

Sport  
│  
├── Facilities  
│  
├── Programs  
│      │  
│      ├── Groups  
│      │      │  
│      │      ├── Trainers  
│      │      ├── Players  
│      │      ├── Attendance  
│      │      └── Mirror Assignments  
│  
└── Reports

This hierarchy is fixed and must be maintained throughout the system.

No entity shall exist without its parent.

---

# **2.4 Training Sports Workflow**

The complete workflow for Training Sports is as follows:

Create Sport  
        ↓  
Create Facility  
        ↓  
Create Program  
        ↓  
Create Group  
        ↓  
Register Trainer  
        ↓  
Register Player  
        ↓  
Upload Documents  
        ↓  
Assign Player to Program  
        ↓  
Generate Treasury Transaction  
        ↓  
Payment Confirmation  
        ↓  
Player Becomes Active  
        ↓  
Assign Group to Mirror  
        ↓  
Daily Attendance  
        ↓  
Monthly Subscription Renewal

Each step must be completed successfully before the next step can proceed, except where explicitly allowed by business rules (such as the medical certificate grace period).

---

# **2.5 Recreational Sports Workflow**

Recreational Sports follow a different workflow because customers are reserving facilities rather than joining structured training programs.

Create Sport  
        ↓  
Create Facility  
        ↓  
Configure Pricing  
        ↓  
Customer Booking  
        ↓  
Mirror Reservation  
        ↓  
Customer Uses Facility  
        ↓  
Treasury Payment  
        ↓  
Booking Closed

Unlike Training Sports:

* No Groups exist.  
* No Trainers are assigned.  
* No Attendance is recorded.  
* Payment may occur after the reservation ends.

---

# **2.6 Player Registration Workflow**

The complete player registration workflow is:

Player Registration  
        ↓  
Upload Documents  
        ↓  
Potential Player Created  
        ↓  
Player Appears in Assignment Page  
        ↓  
Choose Sport  
        ↓  
Choose Program  
        ↓  
Generate Treasury Request  
        ↓  
Payment Confirmation  
        ↓  
Player Activated

A newly registered player is **not** considered an active trainee until all activation requirements are completed.

---

# **2.7 Trainer Workflow**

Trainer management follows this workflow:

Register Trainer  
        ↓  
Upload Trainer Documents  
        ↓  
Assign Academy (Optional)  
        ↓  
Assign Sports  
        ↓  
Assign Groups  
        ↓  
Trainer Begins Training

A trainer may work:

* Independently.  
* Through one Academy.  
* Across multiple Sports.  
* Across multiple Groups.

The system shall support assigning multiple trainers to the same Group.

---

# **2.8 Medical Approval Workflow**

Medical approval operates independently from sports operations.

Player Uploads Medical Certificate  
                ↓  
Medical Department Reviews Certificate  
                ↓  
Approved  
        OR  
Rejected  
                ↓  
Medical Status Updated  
                ↓  
Player Continues or Stops Renewals

Important business rule:

A player may begin training before approval.

However:

* The player receives a 30-day grace period.  
* Renewal shall not be permitted after the grace period if no valid medical certificate has been approved.

---

# **2.9 Monthly Subscription Workflow**

Every active player follows the monthly subscription cycle.

Subscription Due  
        ↓  
Generate Treasury Request  
        ↓  
Payment  
        ↓  
Subscription Renewed  
        ↓  
Continue Training

If payment is not completed:

* The subscription becomes Expired.  
* The player cannot renew attendance eligibility until payment is completed.  
* The player's historical records remain intact.

---

# **2.10 Attendance Workflow**

Attendance is recorded per training session.

Training Session  
        ↓  
Open Attendance  
        ↓  
Select Attendance Status  
        ↓  
Save Attendance  
        ↓  
Update Reports

Attendance statuses include:

* Attended  
* Absent  
* Accepted Excuse  
* Rejected Excuse

Accepted excuses may generate future make-up sessions according to business rules.

---

# **2.11 Mirror Scheduling Workflow**

Facility scheduling follows the Mirror workflow.

Choose Facility  
        ↓  
Open Mirror  
        ↓  
Select Date  
        ↓  
Select Hour  
        ↓  
Select Grid Area  
        ↓  
Choose Assignment Type  
        ↓  
Save Assignment

Possible assignment types include:

* Training Group  
* Maintenance  
* Free Time  
* Institution Booking  
* Recreational Booking

The system shall validate all scheduling conflicts before saving.

---

# **2.12 Institution Booking Workflow**

Institution bookings follow this workflow:

Register Institution  
        ↓  
Choose Facility  
        ↓  
Choose Grid Area  
        ↓  
Choose Schedule  
        ↓  
Enter Booking Fee  
        ↓  
Generate Treasury Request  
        ↓  
Payment  
        ↓  
Booking Activated

Institution bookings shall appear separately from player training schedules while still occupying the reserved area within the Mirror.

---

# **2.13 Recreational Booking Workflow**

Customers booking recreational facilities follow this workflow:

Choose Sport  
        ↓  
Choose Facility  
        ↓  
Choose Time  
        ↓  
Mirror Reservation  
        ↓  
Play Activity  
        ↓  
Treasury Payment  
        ↓  
Booking Completed

Payment occurs after the activity unless configured otherwise by the club.

---

# **2.14 Trainer Assignment Workflow**

Assigning a trainer follows this process:

Choose Trainer  
        ↓  
Choose Sport  
        ↓  
Choose Program  
        ↓  
Choose Group  
        ↓  
Assign

The system shall verify that the trainer is:

* Active.  
* Authorized for the selected Sport.  
* Not already scheduled in another Group during the same time period.

If a scheduling conflict exists, the assignment shall be rejected with a clear validation message.

**Added to make the idea better.**

---

# **2.15 Group Assignment Workflow**

When assigning players to Groups:

Potential Player  
        ↓  
Choose Sport  
        ↓  
Choose Program  
        ↓  
Choose Group  
        ↓  
Capacity Validation  
        ↓  
Treasury Validation  
        ↓  
Assignment Completed

The system shall verify:

* Group capacity.  
* Program availability.  
* Payment status.  
* Medical grace period.  
* Duplicate enrollment.

**Added to make the idea better.**

---

# **2.16 Daily Operational Workflow**

A typical operational day follows this sequence:

1. Employees review the Dashboard.  
2. Register new players.  
3. Register new trainers.  
4. Assign players to programs.  
5. Complete Treasury payments.  
6. Review Medical approvals.  
7. Open today's Mirror schedule.  
8. Conduct training sessions.  
9. Record attendance.  
10. Handle recreational bookings.  
11. Generate daily reports.  
12. Review notifications and pending actions.

This workflow provides a standardized daily routine for club staff and ensures consistent operation across all departments.

---

# **2.17 Cross-Module Integrations**

The Sports Activity Module communicates with the following ERP modules:

* Membership Module for retrieving member information.  
* Treasury Module for processing all financial transactions.  
* Medical Module for certificate review and player eligibility.  
* Notification Module for reminders, alerts, and warnings.  
* Reporting Module for operational and financial analytics.  
* User Management Module for permissions and access control.  
* Audit Log Module for recording all user actions.

All integrations shall occur automatically without requiring duplicate data entry.

---

# **2.18 General Business Rules**

The following rules apply across the entire Sports Activity Module:

* A Sport must exist before any related entity can be created.  
* A Facility belongs to exactly one Sport.  
* A Program belongs to exactly one Sport.  
* A Group belongs to exactly one Program.  
* A Player may be enrolled in multiple Sports if allowed by club policy.  
* A Trainer may coach multiple Groups.  
* Multiple Trainers may be assigned to the same Group.  
* Every financial transaction must pass through the Treasury Module.  
* Every attendance record must belong to a scheduled training session.  
* Mirror assignments shall never overlap unless explicitly permitted by club configuration.  
* Deleted entities shall be archived rather than permanently removed if they contain historical data.

# **Chapter 3 — Sports Dashboard**

## **3.1 Introduction**

The Sports Dashboard shall serve as the main entry point of the Sports Activity Module. It shall provide club employees and management with a real-time overview of all operational, financial, and administrative activities without requiring navigation through multiple pages.

The dashboard shall present only information relevant to the logged-in user's permissions. For example, a Sports Manager may view operational and financial statistics, while a Trainer may only view assigned groups, attendance, and today's schedule.

The dashboard shall be designed to minimize the number of clicks required to perform common daily tasks and to immediately highlight important alerts and pending actions.

---

# **3.2 Dashboard Objectives**

The dashboard shall enable users to:

* Monitor the current status of all sports activities.  
* Monitor financial performance.  
* Monitor player registrations.  
* Monitor trainer assignments.  
* Monitor attendance.  
* Monitor facility occupancy.  
* Monitor medical certificate status.  
* Monitor pending treasury operations.  
* Access frequently used pages through Wizards.  
* Identify operational issues immediately.

---

# **3.3 Dashboard Layout**

The dashboard shall be divided into the following sections:

1. Header  
2. KPI Cards  
3. Financial Statistics  
4. Sports Statistics  
5. Facility Statistics  
6. Player Statistics  
7. Trainer Statistics  
8. Medical Statistics  
9. Treasury Statistics  
10. Attendance Statistics  
11. Mirror Statistics  
12. Notifications & Alerts  
13. Recent Activities  
14. Wizards  
15. Charts  
16. Calendar  
17. Upcoming Events

The layout should remain clean, modern, and responsive while allowing administrators to customize the displayed widgets based on their preferences.

**Added to make the idea better.**

---

# **3.4 Header Section**

The top section of the dashboard shall include:

* Current Date.  
* Current Time.  
* Logged-in User Name.  
* User Role.  
* Selected Club Branch (if multi-branch support is enabled).  
* Quick Search Bar.  
* Notifications Icon.  
* Messages Icon (optional).  
* User Profile Menu.

The Quick Search Bar shall allow users to search for:

* Players  
* Trainers  
* Programs  
* Groups  
* Sports  
* Facilities  
* Academies  
* Bookings

without navigating away from the dashboard.

**Added to make the idea better.**

---

# **3.5 KPI Cards**

The top of the dashboard shall display summary cards containing important statistics.

Suggested KPI Cards include:

### **Financial**

* Today's Revenue  
* This Month's Revenue  
* This Year's Revenue  
* Revenue Between Two Dates  
* Outstanding Payments  
* Pending Treasury Transactions

---

### **Players**

* Total Registered Players  
* Active Players  
* Inactive Players  
* New Players Today  
* New Players This Month  
* Potential Players Awaiting Assignment  
* Players Awaiting Payment  
* Players with Expired Subscriptions

---

### **Trainers**

* Total Trainers  
* Active Trainers  
* Trainers Assigned Today  
* Trainers Without Groups

---

### **Programs**

* Total Sports  
* Total Programs  
* Total Groups  
* Active Programs  
* Full Groups  
* Groups with Available Capacity

---

### **Facilities**

* Total Facilities  
* Facilities Currently In Use  
* Facilities Under Maintenance  
* Available Facilities

---

### **Medical**

* Pending Medical Reviews  
* Approved Medical Certificates  
* Rejected Medical Certificates  
* Certificates Expiring Soon  
* Expired Medical Certificates

---

### **Attendance**

* Today's Sessions  
* Completed Sessions  
* Players Present Today  
* Players Absent Today  
* Accepted Excuses  
* Rejected Excuses

---

### **Bookings**

* Today's Bookings  
* Active Institution Bookings  
* Recreational Bookings  
* Upcoming Bookings

---

# **3.6 Financial Statistics**

The dashboard shall include interactive financial reports.

Users shall be able to switch between:

* Daily Revenue  
* Weekly Revenue  
* Monthly Revenue  
* Quarterly Revenue  
* Yearly Revenue  
* Custom Date Range

The statistics shall distinguish revenue by category:

* Training Programs  
* Recreational Sports  
* Institution Bookings  
* Other Sports Services

Charts shall update automatically based on the selected period.

---

# **3.7 Sports Statistics**

The dashboard shall display operational statistics including:

* Number of Sports.  
* Number of Programs.  
* Number of Groups.  
* Average Group Occupancy.  
* Most Popular Sport.  
* Least Popular Sport.  
* Highest Revenue Sport.  
* Lowest Revenue Sport.  
* Newly Created Programs.

**Added to make the idea better.**

---

# **3.8 Player Statistics**

The Player Statistics section shall include:

* Players by Age Group.  
* Players by Gender.  
* Players by Sport.  
* Players by Program.  
* Players by Membership Status.  
* Players with Medical Issues.  
* Players Awaiting Assignment.  
* Players Near Subscription Expiration.

Users shall be able to click any statistic to navigate directly to the corresponding filtered list.

**Added to make the idea better.**

---

# **3.9 Trainer Statistics**

The Trainer Statistics section shall display:

* Trainers by Sport.  
* Trainers by Academy.  
* Independent Trainers.  
* Trainers Assigned Today.  
* Trainers Without Groups.  
* Trainers With Scheduling Conflicts.  
* Trainer Workload.

The workload shall display:

* Number of Groups.  
* Number of Players.  
* Weekly Training Hours.

**Added to make the idea better.**

---

# **3.10 Facility Statistics**

Facility information shall include:

* Total Facilities.  
* Facilities Occupied Today.  
* Facilities Available Today.  
* Facilities Under Maintenance.  
* Facility Utilization Percentage.  
* Peak Usage Hours.

The utilization percentage shall be calculated based on:

(Total Reserved Hours ÷ Total Available Working Hours) × 100

**Added to make the idea better.**

---

# **3.11 Mirror Statistics**

The dashboard shall summarize Mirror scheduling information.

Examples include:

* Today's Occupancy.  
* Free Time Available.  
* Scheduled Maintenance.  
* Institution Reservations.  
* Recreational Reservations.  
* Number of Scheduling Conflicts.  
* Unused Facilities.

Clicking any statistic shall open the Mirror page with the relevant filters applied.

---

# **3.12 Medical Statistics**

Medical widgets shall display:

* Pending Reviews.  
* Certificates Expiring in 7 Days.  
* Certificates Expiring in 30 Days.  
* Expired Certificates.  
* Players Currently in Medical Grace Period.  
* Players Blocked from Renewal.

The system shall use color indicators:

Green \= Valid

Yellow \= Expiring Soon

Red \= Expired

---

# **3.13 Treasury Statistics**

Treasury information shall display:

* Pending Payments.  
* Completed Payments.  
* Failed Transactions.  
* Today's Collections.  
* Monthly Collections.  
* Pending Recreational Payments.  
* Pending Institution Payments.

Each item shall link directly to the Treasury Module.

---

# **3.14 Attendance Statistics**

Attendance information shall include:

* Today's Attendance Percentage.  
* Weekly Attendance Percentage.  
* Monthly Attendance Percentage.  
* Average Attendance by Sport.  
* Average Attendance by Trainer.  
* Players Frequently Absent.  
* Players with Consecutive Absences.

**Added to make the idea better.**

---

# **3.15 Calendar Widget**

The dashboard shall contain a calendar displaying:

* Today's Training Sessions.  
* Recreational Bookings.  
* Institution Bookings.  
* Maintenance Schedules.  
* Trainer Assignments.  
* Medical Expiration Dates.  
* Subscription Renewal Dates.

Clicking an event shall open its detailed page.

**Added to make the idea better.**

---

# **3.16 Recent Activities**

A live activity feed shall display recent system actions, including:

* New Player Registered.  
* New Trainer Added.  
* Program Created.  
* Group Created.  
* Player Assigned.  
* Subscription Renewed.  
* Booking Created.  
* Medical Certificate Approved.  
* Attendance Submitted.  
* Facility Closed.  
* Institution Booking Confirmed.

Each activity shall display:

* Timestamp.  
* User who performed the action.  
* Related entity.  
* Quick link to details.

---

# **3.17 Notifications & Alerts**

The dashboard shall display system-generated alerts, such as:

* Medical certificates expiring soon.  
* Players awaiting assignment.  
* Pending treasury payments.  
* Groups exceeding capacity.  
* Trainers with schedule conflicts.  
* Facilities under maintenance.  
* Mirror scheduling conflicts.  
* Upcoming subscription renewals.  
* Bookings ending today.

Alerts shall be prioritized by severity (High, Medium, Low) and use distinct visual indicators.

**Added to make the idea better.**

---

# **3.18 Dashboard Wizards**

The dashboard shall provide one-click shortcuts for the most frequently used operations.

The default wizard set shall include:

### **Registration**

* Register New Player.  
* Register New Trainer.  
* Register New Academy.

### **Sports Setup**

* Create Sport.  
* Create Facility.  
* Create Program.  
* Create Group.

### **Daily Operations**

* Assign Player to Program.  
* Assign Trainer to Group.  
* Open Attendance.  
* Open Mirror.  
* Create Recreational Booking.  
* Create Institution Booking.

### **Financial**

* Send Selected Transactions to Treasury.  
* Renew Subscription.  
* View Pending Payments.

### **Medical**

* Review Medical Certificates.  
* View Expiring Certificates.

### **Reports**

* Daily Report.  
* Monthly Report.  
* Attendance Report.  
* Financial Report.

The system administrator shall be able to configure which Wizards are displayed based on user roles and frequently used actions.

**Added to make the idea better.**

---

# **3.19 Filters**

Every dashboard widget shall support filtering by:

* Sport.  
* Program.  
* Group.  
* Trainer.  
* Academy.  
* Facility.  
* Branch (if applicable).  
* Date Range.  
* Membership Type.  
* Player Status.

Changes to filters shall update all related widgets dynamically without requiring a full page refresh.

**Added to make the idea better.**

---

# **3.20 Performance Requirements**

To ensure a responsive user experience:

* The dashboard shall load within an acceptable time under normal operating conditions.  
* Statistical widgets should retrieve aggregated data efficiently.  
* Long-running calculations should be cached or processed asynchronously where appropriate.  
* Charts and tables shall support lazy loading or pagination for large datasets.

**Added to make the idea better.**

---

# **3.21 Dashboard Permissions**

Dashboard content shall be role-based.

Examples:

* **Reception:** Player registration, pending assignments, and daily bookings.  
* **Trainer:** Assigned groups, today's schedule, attendance, and player list.  
* **Medical Staff:** Pending certificates, expiring certificates, and review queue.  
* **Treasury:** Pending payments, collections, and revenue summaries.  
* **Sports Manager:** Full operational dashboard.  
* **System Administrator:** Full access to all widgets and configuration options.

The system shall hide widgets the user is not authorized to view instead of displaying empty sections.

# **Chapter 4 — Dashboard Wizards**

## **4.1 Introduction**

Dashboard Wizards are intelligent shortcuts that allow users to perform the most common operations directly from the dashboard without navigating through multiple pages.

Each Wizard shall launch a guided workflow that validates all required information before completing the operation.

The available Wizards shall depend on the logged-in user's permissions.

---

# **4.2 Wizard Objectives**

The Wizard system is designed to:

* Reduce the number of clicks required for common operations.  
* Guide users through complex workflows.  
* Reduce data entry mistakes.  
* Ensure business rules are followed.  
* Prevent incomplete operations.  
* Increase employee productivity.

---

# **4.3 Wizard Categories**

Dashboard Wizards shall be grouped into the following categories:

### **Registration Wizards**

* Register Player  
* Register Trainer  
* Register Academy

---

### **Sports Management Wizards**

* Create Sport  
* Create Facility  
* Create Program  
* Create Group

---

### **Assignment Wizards**

* Assign Player  
* Assign Trainer  
* Assign Facility Schedule

---

### **Daily Operations Wizards**

* Open Attendance  
* Create Booking  
* Review Medical Certificates  
* Renew Subscription

---

### **Financial Wizards**

* Send Transactions to Treasury  
* View Pending Payments  
* View Today's Collections

---

### **Reporting Wizards**

* Generate Daily Report  
* Generate Attendance Report  
* Generate Revenue Report  
* Generate Facility Usage Report

---

# **4.4 Register Player Wizard**

This Wizard shall guide the user through the complete player registration process.

### **Workflow**

Step 1

Choose whether the player is:

* Club Member  
* Non-Member

---

Step 2

If Club Member:

The user may enter:

* Membership Number

or

* National ID

The system shall automatically retrieve all available information from the Membership Module.

The user may edit only fields that are allowed by system permissions.

---

Step 3

If Non-Member:

The user shall manually enter all required information.

---

Step 4

Upload required documents.

---

Step 5

Review entered information.

---

Step 6

Save Player.

The player shall automatically appear in the Potential Players list awaiting assignment.

---

The Wizard shall prevent registration if:

* National ID already exists.  
* Membership already has an active player profile for the same sport (if duplicate enrollment is not permitted).  
* Required fields are missing.

---

# **4.5 Register Trainer Wizard**

The Trainer Wizard shall collect all trainer information.

Workflow:

Step 1

Enter personal information.

Step 2

Assign academy (optional).

Step 3

Choose sports specialization.

Step 4

Upload trainer documents.

Step 5

Review information.

Step 6

Save trainer.

After saving, the trainer becomes available for assignment to Groups.

---

# **4.6 Register Academy Wizard**

Workflow:

Step 1

Enter academy information.

Step 2

Select supported sports.

Step 3

Assign academy status.

Step 4

Review information.

Step 5

Save academy.

The academy shall immediately become available in Trainer registration.

---

# **4.7 Create Sport Wizard**

Workflow:

Step 1

Enter:

* Sport Name  
* Sport Category (Training / Recreational)  
* Description  
* Status

Step 2

Save Sport.

The system may optionally prompt the user to immediately create the first Facility.

**Added to make the idea better.**

---

# **4.8 Create Facility Wizard**

Workflow:

Step 1

Select Sport.

Step 2

Enter:

* Facility Name  
* Facility Type  
* Working Hours  
* Maximum Capacity  
* Grid Size

Step 3

Review information.

Step 4

Generate Facility.

The system shall automatically generate the corresponding Mirror based on the selected grid size.

---

# **4.9 Create Program Wizard**

Workflow:

Step 1

Select Sport.

Step 2

Enter:

* Program Name.  
* Member Monthly Price.  
* Non-Member Monthly Price.  
* Status.

Step 3

Save Program.

The Wizard may optionally allow the user to immediately create the first Group for the Program.

**Added to make the idea better.**

---

# **4.10 Create Group Wizard**

Workflow:

Step 1

Choose Program.

Step 2

Enter:

* Group Name.  
* Maximum Capacity.  
* Minimum Capacity (optional).  
* Group Type.  
* Default Training Days (optional).  
* Default Training Time (optional).

**Added to make the idea better.**

Step 3

Assign Trainers.

Step 4

Review.

Step 5

Save.

The Group shall become available for Player assignment and Mirror scheduling.

---

# **4.11 Assign Player Wizard**

This Wizard performs one of the most important operations in the Sports Module.

Workflow:

Step 1

Choose Player.

Only Potential Players shall appear by default.

The user may also search for existing active players if reassignment is permitted.

---

Step 2

Select Sport.

The Wizard shall display all active Sports.

---

Step 3

Select Program.

Only Programs belonging to the selected Sport shall be displayed.

---

Step 4

Select Group.

The system shall display:

* Trainer(s)  
* Current Capacity  
* Available Seats  
* Schedule

before allowing selection.

---

Step 5

Review Subscription Details.

The Wizard shall display:

* Member Price  
* Non-Member Price  
* Discounts (if applicable)  
* Total Amount

---

Step 6

Send to Treasury.

The system shall automatically create the financial transaction.

---

Step 7

Wait for Treasury confirmation.

After payment:

* Player status becomes Active.  
* Player appears in Group.  
* Player becomes available in Attendance.  
* Player becomes available in Mirror schedules.

---

The Wizard shall prevent assignment if:

* Group is full.  
* Program is inactive.  
* Sport is inactive.  
* Player is already assigned to the same Program.  
* Treasury transaction already exists and is still pending for the same enrollment.

**Added to make the idea better.**

---

# **4.12 Assign Trainer Wizard**

Workflow:

Step 1

Select Trainer.

Step 2

Select Sport.

Step 3

Select Program.

Step 4

Select Group.

Step 5

Validate trainer availability.

The system shall automatically verify:

* Schedule conflicts.  
* Existing assignments.  
* Trainer status.

Step 6

Confirm assignment.

The Trainer immediately becomes responsible for the selected Group.

---

# **4.13 Attendance Wizard**

The Attendance Wizard shall automatically display all Groups that have scheduled sessions on the current day.

The user shall select the Group.

The system shall immediately open the attendance screen for that Group.

This Wizard eliminates the need to manually search for today's sessions.

---

# **4.14 Mirror Wizard**

Workflow:

Step 1

Select Sport.

Step 2

Select Facility.

Step 3

Open today's Mirror.

The Wizard shall automatically navigate to the current day's schedule.

If today's schedule has not yet been created, the system may suggest copying the previous week's schedule.

**Added to make the idea better.**

---

# **4.15 Medical Wizard**

The Medical Wizard shall display:

* Pending Certificates.  
* Certificates Expiring Soon.  
* Certificates Awaiting Review.

The Medical Employee shall immediately access the selected certificate for review.

---

# **4.16 Renew Subscription Wizard**

Workflow:

Step 1

Search Player.

Step 2

Display current subscription.

Step 3

Calculate renewal amount.

Step 4

Generate Treasury transaction.

Step 5

Wait for payment.

Step 6

Activate new subscription period.

---

# **4.17 Recreational Booking Wizard**

Workflow:

Step 1

Choose Sport.

Step 2

Choose Facility.

Step 3

Choose Date.

Step 4

Choose Time.

Step 5

Choose Duration or Number of Games depending on the sport.

Step 6

Review booking.

Step 7

Save reservation.

The booking shall immediately appear in the Mirror schedule while remaining unpaid until completed according to the sport's payment policy.

---

# **4.18 Institution Booking Wizard**

Workflow:

Step 1

Search or create Institution.

Step 2

Choose Facility.

Step 3

Select Date.

Step 4

Select Time.

Step 5

Select Grid Area.

Step 6

Enter custom fees.

Step 7

Generate Treasury transaction.

Step 8

Confirm reservation.

The reservation shall immediately appear in the Mirror and in the Bookings page.

---

# **4.19 Reports Wizard**

The Reports Wizard shall provide quick access to the most commonly used reports.

Users shall be able to generate:

* Daily Operations Report.  
* Daily Attendance Report.  
* Monthly Attendance Report.  
* Daily Revenue Report.  
* Monthly Revenue Report.  
* Facility Utilization Report.  
* Trainer Workload Report.  
* Medical Compliance Report.  
* Active Programs Report.  
* Active Bookings Report.

Each report shall allow exporting to PDF and Excel.

**Added to make the idea better.**

---

# **4.20 Wizard Permissions**

Every Wizard shall be permission-based.

Examples:

* Reception Employees may access Player Registration and Player Assignment.  
* Medical Employees may access Medical Review only.  
* Treasury Employees may access Financial Wizards only.  
* Trainers may access Attendance Wizards for their assigned Groups only.  
* Sports Managers may access all operational Wizards.  
* System Administrators shall have unrestricted access to all Wizards.

Users shall never see Wizards for operations they are not authorized to perform.

---

# **4.21 Wizard Design Standards**

All Wizards throughout the Sports Activity Module shall follow a consistent design and behavior.

Each Wizard shall:

* Display a progress indicator showing the current step and remaining steps.  
* Allow users to navigate back to previous steps before final submission.  
* Validate required fields before proceeding to the next step.  
* Display clear error messages when validation fails.  
* Save the operation only after all mandatory steps are completed successfully.  
* Show a confirmation summary before completing the operation.  
* Display a success message with a direct link to the created record after completion.  
* Automatically record the operation in the system's Audit Log.

**Added to make the idea better.**

# **Chapter 5 — Sports Management**

## **5.1 Introduction**

Sports Management is the foundation of the Sports Activity Module. Every training activity and recreational activity must first be registered as a Sport before any facilities, programs, groups, bookings, or players can be created.

A Sport represents the highest level in the Sports hierarchy and acts as the parent entity for all related data.

Each Sport shall operate independently while sharing the same system architecture and business rules.

---

# **5.2 Sport Types**

The system shall support two main Sport Types:

### **Training Sports**

Training Sports are sports that require structured training programs.

Examples include:

* Football  
* Swimming  
* Basketball  
* Volleyball  
* Karate  
* Gymnastics  
* Tennis  
* Handball

Training Sports support:

* Programs  
* Groups  
* Trainers  
* Player Registration  
* Attendance  
* Monthly Subscriptions  
* Medical Certificates  
* Mirror Scheduling

---

### **Recreational Sports**

Recreational Sports are reservation-based sports.

Examples include:

* Bowling  
* Padel  
* Football Field Rental  
* Squash  
* Billiards  
* Table Tennis

Recreational Sports support:

* Facility Reservations  
* Hourly Pricing  
* Per Game Pricing  
* Mirror Scheduling  
* Treasury Integration  
* Institution Bookings

Recreational Sports do not include:

* Programs  
* Groups  
* Attendance  
* Medical Certificates  
* Monthly Subscriptions

---

# **5.3 Creating a Sport**

When creating a Sport, the system shall require the following information:

### **Basic Information**

* Sport Name (Arabic)  
* Sport Name (English) (Optional)  
* Sport Type  
* Description (Optional)  
* Status (Active / Inactive)

---

### **Financial Configuration**

For Training Sports:

* Default Member Monthly Price (Optional)  
* Default Non-Member Monthly Price (Optional)

These values act as defaults only. Programs may override them.

**Added to make the idea better.**

For Recreational Sports:

* Pricing Method  
  * Hourly  
  * Per Game  
* Default Member Price  
* Default Non-Member Price

These values may also be overridden at the Facility level if required.

**Added to make the idea better.**

---

### **Operational Settings**

* Allow Multiple Program Enrollment  
* Allow Waiting List  
* Allow Transfers Between Programs  
* Allow Temporary Suspension

These settings are optional and may be enabled or disabled depending on club policy.

**Added to make the idea better.**

---

# **5.4 Sport Status**

Each Sport shall have one of the following statuses:

### **Active**

The Sport is fully operational.

Users may:

* Create Facilities.  
* Create Programs.  
* Register Players.  
* Register Trainers.  
* Create Bookings.

---

### **Inactive**

The Sport is temporarily unavailable.

The system shall prevent:

* New registrations.  
* New programs.  
* New bookings.

Existing historical records shall remain accessible.

---

### **Archived**

Archived Sports remain available only for historical reporting.

No modifications shall be allowed except by System Administrators.

**Added to make the idea better.**

---

# **5.5 Sport Details Page**

Opening a Sport shall display a complete overview.

The page shall include:

### **General Information**

* Sport Name  
* Status  
* Type  
* Date Created  
* Last Updated

---

### **Statistics**

* Number of Facilities  
* Number of Programs  
* Number of Groups  
* Active Players  
* Active Trainers  
* Monthly Revenue  
* Yearly Revenue

---

### **Quick Actions**

* Add Facility  
* Add Program  
* View Mirror  
* View Reports  
* Edit Sport  
* Deactivate Sport

---

### **Related Lists**

Facilities

Programs

Groups

Bookings

Reports

Recent Activities

---

# **5.6 Editing a Sport**

Users with sufficient permissions may edit:

* Name  
* Description  
* Default Prices  
* Status  
* Operational Settings

The system shall automatically update all dependent pages where appropriate.

Changing default prices shall not modify existing Program prices unless the user explicitly chooses to propagate the changes.

**Added to make the idea better.**

---

# **5.7 Deleting a Sport**

Permanent deletion shall only be allowed if the Sport has:

* No Facilities.  
* No Programs.  
* No Groups.  
* No Players.  
* No Bookings.  
* No Financial Transactions.

Otherwise, deletion shall be prohibited.

Instead, users shall Archive the Sport.

This ensures historical integrity of reports and financial records.

---

# **5.8 Sport Validation Rules**

The system shall validate the following:

* Sport Name must be unique.  
* A Sport Type must be selected.  
* Pricing Method is mandatory for Recreational Sports.  
* Member and Non-Member prices cannot be negative.  
* Inactive Sports cannot accept new registrations.  
* Archived Sports cannot be modified.

---

# **5.9 Search & Filters**

Users shall be able to search Sports using:

* Sport Name  
* Sport Type  
* Status

Filters shall include:

* Active  
* Inactive  
* Archived  
* Training Sports  
* Recreational Sports

Sorting options:

* Name  
* Date Created  
* Number of Players  
* Revenue  
* Number of Programs

**Added to make the idea better.**

---

# **5.10 Duplicate Prevention**

The system shall prevent duplicate Sports.

Examples:

Swimming

SWIMMING

Swimming Club

These names should be detected as potential duplicates and the user should receive a warning before saving.

The user may override the warning if they have sufficient permissions.

**Added to make the idea better.**

---

# **5.11 Business Rules**

* Every Facility must belong to exactly one Sport.  
* Every Program must belong to exactly one Training Sport.  
* Recreational Sports cannot contain Programs or Groups.  
* Every Sport may contain one or more Facilities.  
* A Sport cannot be deleted while it contains dependent records.  
* Historical data shall remain accessible even if the Sport becomes inactive or archived.  
* Changes to a Sport shall not modify historical financial transactions.

---

# **5.12 Permissions**

### **Reception Employee**

* View Sports

---

### **Sports Employee**

* View Sports  
* Create Sports  
* Edit Sports

---

### **Sports Manager**

* Full Sport Management  
* Activate Sports  
* Deactivate Sports  
* Archive Sports

---

### **System Administrator**

* Full access.  
* Delete Sports.  
* Restore Archived Sports.

---

# **5.13 Notifications**

The system shall generate notifications for:

* Sport successfully created.  
* Sport successfully updated.  
* Sport status changed.  
* Sport archived.  
* Attempt to register a player into an inactive Sport.  
* Attempt to create a Program under a Recreational Sport.  
* Attempt to delete a Sport that contains related records.

---

# **5.14 Audit Log**

Every operation performed on a Sport shall be recorded.

The Audit Log shall include:

* Operation Type.  
* User.  
* Date and Time.  
* Previous Values.  
* New Values.  
* IP Address (if supported).  
* Reason for the change (optional).

No Sport modification shall occur without being recorded in the Audit Log.

**Chapter 6 — Facilities Management**

## **6.1 Introduction**

Facilities represent the physical locations where sports activities take place. Every Facility must belong to exactly one Sport and acts as the operational area where training sessions, recreational bookings, institution reservations, maintenance, and other activities are scheduled.

Each Facility shall have its own independent Mirror (Scheduling Grid), working hours, operating rules, and booking history.

Examples of Facilities include:

* Olympic Swimming Pool  
* Training Swimming Pool  
* Football Field No. 1  
* Football Field No. 2  
* Basketball Court  
* Tennis Court  
* Karate Hall  
* Gymnastics Hall  
* Bowling Lane Area  
* Padel Court

One Sport may contain multiple Facilities.

---

# **6.2 Facility Creation**

When creating a Facility, the system shall require the following information.

### **Basic Information**

* Facility Name (Arabic)  
* Facility Name (English) (Optional)  
* Related Sport  
* Facility Type  
* Description (Optional)  
* Status

---

### **Facility Types**

The system administrator shall be able to define Facility Types.

Examples include:

* Swimming Pool  
* Football Field  
* Indoor Hall  
* Outdoor Court  
* Tennis Court  
* Bowling Area  
* Fitness Area  
* Multi-Purpose Hall

This list shall be configurable by the system administrator.

**Added to make the idea better.**

---

### **Working Hours**

The Facility shall include:

* Working Days  
* Opening Time  
* Closing Time

Example:

Saturday to Thursday

08:00 AM

11:00 PM

The Mirror System shall generate available scheduling hours based on these working hours.

---

### **Mirror Configuration**

Every Facility must define its Mirror settings during creation.

Required fields:

* Number of Rows  
* Number of Columns

Example:

10 Rows × 15 Columns

Immediately after saving, the system shall automatically generate the Mirror Grid for the Facility.

This Mirror shall remain associated with the Facility throughout its lifetime.

---

### **Operational Information**

Optional settings include:

* Maximum Simultaneous Capacity  
* Indoor / Outdoor  
* Air Conditioned  
* Lighting Available  
* Equipment Available  
* Notes

**Added to make the idea better.**

---

# **6.3 Facility Status**

Each Facility shall have one of the following statuses.

### **Active**

The Facility is available for:

* Training  
* Recreational Bookings  
* Institution Bookings  
* Mirror Scheduling

---

### **Under Maintenance**

The Facility cannot receive:

* New Assignments  
* New Bookings  
* New Training Sessions

Existing historical records remain unchanged.

---

### **Closed**

The Facility is permanently unavailable.

No future scheduling shall be permitted.

Historical data remains available.

---

### **Archived**

Archived Facilities remain available for reporting purposes only.

No modifications shall be allowed except by System Administrators.

**Added to make the idea better.**

---

# **6.4 Facility Details Page**

Each Facility shall have its own details page containing the following sections.

### **General Information**

* Facility Name  
* Sport  
* Facility Type  
* Status  
* Working Hours  
* Grid Size  
* Date Created

---

### **Statistics**

* Total Programs Using Facility  
* Total Groups Assigned  
* Monthly Occupancy Percentage  
* Today's Occupancy  
* Revenue Generated  
* Number of Bookings  
* Maintenance History

---

### **Quick Actions**

* Open Mirror  
* Create Booking  
* Add Maintenance  
* Edit Facility  
* View Reports

---

### **Related Information**

* Current Assignments  
* Upcoming Bookings  
* Institution Reservations  
* Recreational Reservations  
* Maintenance Schedule

---

# **6.5 Working Hours Rules**

The Facility's working hours shall control every scheduling operation.

The system shall prevent scheduling:

* Before opening time.  
* After closing time.  
* Outside working days.

Example:

Facility Working Hours

08:00 AM → 10:00 PM

The Mirror shall only display hourly slots between these times.

---

# **6.6 Facility Availability**

The system shall determine Facility availability automatically.

Possible states include:

* Available  
* Fully Occupied  
* Partially Occupied  
* Under Maintenance  
* Closed

Availability shall be calculated using the Mirror assignments for the selected date.

---

# **6.7 Facility Capacity**

Facilities may optionally define a maximum simultaneous capacity.

Example:

Swimming Pool

Maximum Capacity

40 Players

The system shall warn users if scheduled groups exceed the defined capacity.

The warning may be overridden only by users with sufficient permissions.

**Added to make the idea better.**

---

# **6.8 Facility Images**

Each Facility may contain:

* Main Image  
* Additional Images

These images shall be displayed on the Facility details page and may assist users in identifying the correct Facility.

Supported file types:

* JPG  
* PNG  
* WEBP

**Added to make the idea better.**

---

# **6.9 Editing a Facility**

Users may edit:

* Name  
* Working Hours  
* Status  
* Capacity  
* Notes  
* Images

Editing the Mirror Grid dimensions shall not be allowed once scheduling data exists.

If no scheduling history exists, administrators may regenerate the Mirror.

**Added to make the idea better.**

---

# **6.10 Deleting a Facility**

Permanent deletion shall only be permitted if:

* No Mirror assignments exist.  
* No Bookings exist.  
* No Programs use the Facility.  
* No historical records exist.

Otherwise, the system shall require the Facility to be Archived instead.

---

# **6.11 Facility Search**

Users shall be able to search Facilities using:

* Facility Name  
* Sport  
* Facility Type

Filters shall include:

* Active  
* Closed  
* Maintenance  
* Archived  
* Indoor  
* Outdoor

Sorting options:

* Name  
* Occupancy  
* Revenue  
* Date Created

---

# **6.12 Facility Business Rules**

* Every Facility belongs to exactly one Sport.  
* Every Facility owns one Mirror.  
* Multiple Programs may use the same Facility through the Mirror schedule.  
* Multiple Groups may use the same Facility at different times.  
* Recreational Bookings and Training Sessions may use the same Facility provided no scheduling conflict exists.  
* Institution Bookings shall also occupy Mirror time slots.  
* Maintenance reservations shall block the reserved area from any other assignment.

---

# **6.13 Facility Notifications**

The system shall notify users when:

* A Facility is created.  
* A Facility becomes inactive.  
* Maintenance begins.  
* Maintenance ends.  
* A Facility reaches maximum capacity.  
* A booking conflicts with an existing assignment.  
* Working hours are modified.  
* An attempt is made to schedule outside working hours.

---

# **6.14 Facility Audit Log**

Every Facility operation shall be recorded.

The Audit Log shall include:

* Operation Type  
* User  
* Date and Time  
* Previous Values  
* New Values  
* Reason (Optional)

---

# **6.15 Future Expansion**

The Facility architecture shall support future enhancements without requiring structural changes.

Examples include:

* Multiple Mirrors for a single Facility (for facilities that can be divided into sections independently).  
* IoT integration to display real-time facility occupancy.  
* Smart lighting and access control integration.  
* Equipment reservation linked to Facility bookings.  
* Automatic maintenance scheduling based on usage hours.

**Added to make the idea better.**

# **Chapter 7 — Mirror Management System**

## **7.1 Introduction**

The Mirror Management System is the scheduling engine of the Sports Activity Module. It provides a visual representation of each Facility, allowing users to schedule training sessions, recreational bookings, institution reservations, maintenance, and free time by assigning activities to specific areas of the Facility.

Unlike a simple calendar, the Mirror represents the physical layout of the Facility using a configurable grid structure. Users interact directly with this grid to reserve complete facilities or selected sections for specific periods.

The Mirror shall function as a **dynamic scheduling engine**, meaning that the displayed grid is generated from scheduling records stored in the database rather than being stored as static grid data. This architecture allows the system to efficiently detect conflicts, support recurring schedules, copy schedules between periods, and accommodate future enhancements.

---

# **7.2 Mirror Architecture**

Every Facility shall have exactly one Mirror.

The Mirror consists of three main components:

* Physical Grid Layout  
* Time Schedule  
* Assignment Records

The Mirror shall display scheduling information by combining these components dynamically.

The system shall never permanently store colored cells or drawings. Instead, it shall generate the visualization from assignment records.

**Added to make the idea better.**

---

# **7.3 Mirror Structure**

Each Mirror shall be configured using:

* Number of Rows  
* Number of Columns

Example:

10 Rows × 10 Columns

The resulting Mirror contains 100 individual cells.

Each cell represents a physical location inside the Facility.

Examples:

Swimming Pool

Each cell may represent one swimming lane section.

Football Field

Each cell may represent a training area.

Indoor Hall

Each cell may represent a practice zone.

The interpretation of the cells depends entirely on the Facility and is determined by the club.

---

# **7.4 Time Structure**

The Mirror shall generate its schedule based on the Facility working hours.

Example:

Working Hours

08:00 AM → 10:00 PM

The Mirror shall automatically generate hourly slots:

08:00

09:00

10:00

...

10:00 PM

The duration of each scheduling slot shall be configurable.

Possible options include:

* 30 Minutes  
* 60 Minutes  
* 90 Minutes  
* 120 Minutes

The default duration shall be configurable in the system settings.

**Added to make the idea better.**

---

# **7.5 Mirror Navigation**

Users shall be able to navigate the Mirror using:

* Previous Day  
* Next Day  
* Previous Week  
* Next Week  
* Previous Month  
* Next Month  
* Date Picker

The selected date shall immediately update all displayed assignments.

---

# **7.6 Selecting Cells**

The Mirror shall provide multiple methods for selecting cells.

### **Single Cell Selection**

Click one cell.

---

### **Multiple Cell Selection**

Click and drag across multiple cells.

---

### **Entire Row**

Click the row header.

The entire row becomes selected.

---

### **Entire Column**

Click the column header.

The entire column becomes selected.

---

### **Custom Area**

Users may drag to create rectangular selections.

Example:

Rows 2–5

Columns 3–8

All selected cells become highlighted.

---

### **Entire Facility**

One action shall allow selecting every cell in the Mirror.

This is useful for:

* Full Facility Maintenance  
* Institution Reservation  
* Exclusive Training Sessions

---

# **7.7 Assignment Types**

The Mirror shall support multiple assignment types.

### **Training Group**

Assign a Group to the selected area.

---

### **Recreational Booking**

Reserve the selected area for recreational customers.

---

### **Institution Booking**

Reserve the selected area for an external institution.

---

### **Maintenance**

Reserve part or all of the Facility for maintenance.

---

### **Free Time**

Reserve the selected area as intentionally unavailable.

Example:

Cleaning

Internal Event

Club Activity

Reserved Buffer Time

**Added to make the idea better.**

---

### **Custom Assignment**

The system administrator may create additional assignment types.

Examples:

* Tournament  
* Competition  
* Coach Meeting  
* Media Event  
* Private Event

**Added to make the idea better.**

---

# **7.8 Creating an Assignment**

The workflow shall be:

Step 1

Choose Date.

Step 2

Choose Facility.

Step 3

Choose Time.

Step 4

Select Grid Cells.

Step 5

Choose Assignment Type.

Step 6

Enter assignment details.

Step 7

Save.

The Mirror shall immediately update after saving.

---

# **7.9 Training Group Assignment**

When assigning a Training Group, the system shall display:

Sport

↓

Programs

↓

Groups

The interface shall include:

* Sport Filter  
* Program Search  
* Group Search

Selecting a Group shall display:

* Group Name  
* Program  
* Trainers  
* Number of Players  
* Assigned Color

The selected Group shall then be assigned to the selected cells.

---

# **7.10 Recreational Booking Assignment**

For recreational bookings, the user shall select:

* Customer  
* Sport  
* Facility  
* Date  
* Time  
* Duration  
* Selected Cells

The system shall calculate pricing according to:

* Hourly Pricing

or

* Per Game Pricing

depending on the Sport configuration.

---

# **7.11 Institution Assignment**

Institution assignments shall include:

* Institution Name  
* Contact Person  
* Phone Number  
* Assigned Area  
* Booking Period  
* Custom Fees  
* Treasury Status  
* Notes

Saving the assignment shall automatically generate the corresponding Treasury transaction.

---

# **7.12 Maintenance Assignment**

Maintenance assignments shall include:

* Maintenance Type  
* Description  
* Assigned Area  
* Start Date  
* End Date  
* Start Time  
* End Time

The selected area shall become unavailable for every other assignment until maintenance is completed.

---

# **7.13 Mirror Colors**

Each assignment type shall have its own color.

Example:

Training Groups

Blue

Recreational Bookings

Green

Institution Bookings

Purple

Maintenance

Red

Free Time

Gray

Administrators shall be able to customize these colors through system settings.

**Added to make the idea better.**

---

# **7.14 Conflict Detection**

The system shall validate every assignment before saving.

Conflicts include:

* Two Groups occupying the same cells during the same time.  
* Institution booking overlapping another booking.  
* Recreational booking during maintenance.  
* Maintenance during active training.  
* Double booking of the same area.

The conflicting cells shall be highlighted before saving.

The user shall receive a detailed explanation of the conflict.

The assignment shall not be saved until the conflict is resolved.

---

# **7.15 Copy Schedule**

Users shall be able to copy schedules.

Supported options include:

* Copy One Day  
* Copy One Week  
* Copy One Month  
* Copy Custom Date Range

The copied schedule shall preserve:

* Time  
* Assigned Cells  
* Assignment Types  
* Groups  
* Institutions

The system shall validate conflicts before completing the copy process.

Existing assignments may be:

* Skipped  
* Replaced  
* Merged (where applicable)

The user shall choose the desired behavior before execution.

**Added to make the idea better.**

---

# **7.16 Editing Assignments**

Users may edit:

* Time  
* Cells  
* Group  
* Institution  
* Duration  
* Notes

Every edit shall trigger conflict validation before saving.

---

# **7.17 Deleting Assignments**

Deleting an assignment shall immediately release the occupied cells.

Historical records shall remain available in the Audit Log.

Administrators may configure whether deleted assignments remain visible in historical reports.

**Added to make the idea better.**

---

# **7.18 Mirror Filters**

Users shall be able to filter the Mirror by:

* Sport  
* Facility  
* Program  
* Group  
* Trainer  
* Institution  
* Assignment Type  
* Date  
* Time

---

# **7.19 Mirror Search**

Users shall be able to search using:

* Group Name  
* Trainer  
* Institution  
* Customer  
* Booking Number

Selecting a result shall automatically navigate to the corresponding date and highlight the assignment.

---

# **7.20 Business Rules**

* Every assignment belongs to exactly one Facility.  
* Every assignment has a defined start and end time.  
* Every assignment occupies one or more grid cells.  
* Grid cells may not overlap with another active assignment during the same period.  
* Maintenance has the highest scheduling priority.  
* Closed Facilities cannot receive assignments.  
* Assignments outside Facility working hours shall be rejected.  
* Every assignment shall be recorded in the Audit Log.  
* Every Institution booking shall generate a Treasury transaction.  
* Recreational bookings shall follow the payment policy configured for the corresponding Sport.

---

# **7.21 Notifications**

The system shall notify users when:

* A scheduling conflict occurs.  
* A booking is successfully created.  
* A booking is edited.  
* A booking is cancelled.  
* Maintenance begins.  
* Maintenance ends.  
* A copied schedule contains conflicts.  
* A Facility reaches full occupancy.

---

# **7.22 Audit Log**

Every Mirror operation shall be recorded.

The Audit Log shall include:

* Operation Type.  
* User.  
* Date and Time.  
* Facility.  
* Assignment Type.  
* Previous Values.  
* New Values.  
* Reason (Optional).

---

# **7.23 Future Expansion**

The Mirror architecture shall support future enhancements without structural modifications.

Potential enhancements include:

* Recurring weekly schedules with automatic holiday exceptions.  
* Drag-and-drop assignment editing directly on the Mirror.  
* Real-time collaboration where multiple users can schedule simultaneously with live conflict detection.  
* Color legends and occupancy heat maps.  
* AI-powered schedule optimization to maximize Facility utilization.  
* Automatic trainer availability suggestions during scheduling.  
* Integration with electronic access control systems to unlock Facilities during active reservations.  
* Public booking portal synchronized with the internal Mirror.

**Added to make the idea better.**

# **Chapter 8 — Programs Management**

## **8.1 Introduction**

Programs are the primary organizational level within each Training Sport. Every Training Sport may contain one or more Programs, and each Program represents a category of trainees grouped according to the club's organizational structure.

Programs are used to organize trainees before they are divided into Groups. A Program may represent a birth year, age category, skill level, training level, competition level, or any other classification determined by the club.

Examples include:

* 2008 Program  
* 2010 Program  
* Beginners Program  
* Advanced Program  
* Elite Program  
* Adults Program

Every Program belongs to exactly one Sport.

---

# **8.2 Program Hierarchy**

The relationship shall always be:

Sport

↓

Program

↓

Group

↓

Players

Programs cannot exist independently from a Sport.

---

# **8.3 Creating a Program**

When creating a Program, the following information shall be required.

### **Basic Information**

* Program Name (Arabic)  
* Program Name (English) (Optional)  
* Related Sport  
* Description (Optional)  
* Status

---

### **Financial Information**

Every Program shall define its own pricing.

Required fields:

* Member Monthly Price  
* Non-Member Monthly Price

These prices override the Sport's default pricing.

The system shall always use the Program price when calculating subscriptions.

---

### **Operational Information**

Optional settings include:

* Maximum Number of Groups  
* Minimum Age  
* Maximum Age  
* Gender Restriction  
* Registration Start Date  
* Registration End Date

**Added to make the idea better.**

---

### **Program Status**

Available statuses:

* Active  
* Registration Closed  
* Inactive  
* Archived

---

# **8.4 Program Details Page**

Each Program shall contain the following sections.

### **General Information**

* Program Name  
* Related Sport  
* Status  
* Description  
* Registration Period

---

### **Financial Information**

* Member Monthly Price  
* Non-Member Monthly Price  
* Monthly Revenue  
* Yearly Revenue

---

### **Statistics**

* Number of Groups  
* Number of Active Players  
* Number of Trainers  
* Available Seats  
* Occupancy Percentage

---

### **Quick Actions**

* Add Group  
* Assign Player  
* View Mirror Assignments  
* View Attendance  
* View Reports  
* Edit Program

---

### **Related Information**

* Groups  
* Players  
* Trainers  
* Revenue  
* Attendance Statistics  
* Recent Activities

---

# **8.5 Registration Period**

Programs may optionally define a registration period.

The system shall prevent new player assignments outside this period unless the logged-in user has permission to override the restriction.

**Added to make the idea better.**

---

# **8.6 Age Validation**

If a Program defines an age range, the system shall automatically validate the player's age before assignment.

Example:

Program

2015 Program

Allowed Age

9–11 Years

Players outside this range shall not be assigned unless an authorized user overrides the validation.

**Added to make the idea better.**

---

# **8.7 Gender Restriction**

Programs may optionally restrict registration to:

* Male  
* Female  
* Both

The system shall validate player gender during assignment.

**Added to make the idea better.**

---

# **8.8 Pricing Rules**

Each Program shall maintain independent pricing.

The system shall calculate subscription fees according to:

* Membership Status  
* Program Price  
* Applicable Discounts  
* Additional Fees (if configured)

Historical subscription records shall always retain the price that was valid at the time of payment, even if the Program price changes later.

**Added to make the idea better.**

---

# **8.9 Program Capacity**

Programs may optionally define a maximum number of Groups.

Once this limit is reached, the system shall prevent creating additional Groups unless the limit is increased.

This validation shall not affect existing Groups.

---

# **8.10 Editing a Program**

Users may edit:

* Program Name  
* Description  
* Prices  
* Registration Period  
* Status  
* Age Restrictions  
* Gender Restrictions

Price changes shall affect future subscriptions only.

Existing paid subscriptions shall never be modified.

---

# **8.11 Closing Registration**

When a Program is marked as "Registration Closed":

The system shall:

* Prevent new player assignments.  
* Continue allowing existing players to renew subscriptions.  
* Continue attendance.  
* Continue scheduling.

Managers may reopen registration at any time.

---

# **8.12 Archiving a Program**

Archived Programs:

* Cannot accept new players.  
* Cannot create new Groups.  
* Remain visible in historical reports.  
* Preserve all financial records.  
* Preserve attendance history.

---

# **8.13 Search & Filters**

Users shall be able to search Programs using:

* Program Name  
* Sport

Filters shall include:

* Active  
* Registration Closed  
* Inactive  
* Archived

Sorting options:

* Number of Players  
* Revenue  
* Date Created  
* Program Name

---

# **8.14 Business Rules**

* Every Program belongs to exactly one Sport.  
* Programs may only exist under Training Sports.  
* Every Group belongs to one Program.  
* Pricing shall be determined at the Program level.  
* Archived Programs cannot be modified except by System Administrators.  
* Historical subscription data shall remain unchanged after price updates.

---

# **8.15 Notifications**

The system shall notify users when:

* A Program is created.  
* Program registration opens.  
* Program registration closes.  
* Program reaches maximum capacity.  
* Program pricing changes.  
* Program status changes.

---

# **8.16 Audit Log**

Every Program operation shall be recorded.

The Audit Log shall include:

* Operation Type  
* User  
* Date and Time  
* Previous Values  
* New Values  
* Reason (Optional)

---

# **Chapter 9 — Groups Management**

## **9.1 Introduction**

Groups represent the operational training units within each Program. Players do not train directly under Programs; they train within Groups.

Each Group consists of one or more Trainers and one or more Players, and is scheduled using the Mirror System.

A Program may contain any number of Groups depending on the club's requirements.

Examples include:

* Group A  
* Group B  
* Elite Group  
* Beginners Group  
* Private Session Group

Every Group belongs to exactly one Program.

---

# **9.2 Group Structure**

Relationship:

Sport

↓

Program

↓

Group

↓

Players

↓

Attendance

↓

Mirror Assignments

---

# **9.3 Creating a Group**

Required information:

### **Basic Information**

* Group Name  
* Related Program  
* Description (Optional)  
* Status

---

### **Capacity**

* Maximum Number of Players

Optional:

* Minimum Number of Players

The system shall continuously display:

* Current Players  
* Remaining Seats

---

### **Trainers**

Users shall assign one or more Trainers during creation.

One Trainer shall be designated as the Primary Trainer.

Additional Trainers shall be marked as Assistant Trainers.

**Added to make the idea better.**

---

### **Default Schedule**

Optional fields:

* Training Days  
* Start Time  
* End Time  
* Session Duration

These values act as default suggestions when scheduling the Group in the Mirror.

The Mirror may later be adjusted independently.

**Added to make the idea better.**

---

# **9.4 Group Details Page**

The Group page shall include:

### **General Information**

* Group Name  
* Program  
* Sport  
* Status

---

### **Trainers**

Display:

* Primary Trainer  
* Assistant Trainers

---

### **Players**

Display:

* Active Players  
* Inactive Players  
* Waiting List (if enabled)

**Added to make the idea better.**

---

### **Statistics**

* Capacity  
* Occupancy Percentage  
* Monthly Attendance  
* Revenue  
* Average Attendance  
* Total Sessions

---

### **Quick Actions**

* Assign Player  
* Remove Player  
* Open Attendance  
* Open Mirror  
* View Reports  
* Edit Group

---

# **9.5 Group Capacity**

Before assigning a player, the system shall validate:

Current Players

\<

Maximum Capacity

If the Group is full:

Assignment shall be rejected.

Managers may override this restriction if permitted by their user role.

---

# **9.6 Waiting List**

If enabled, full Groups may maintain a Waiting List.

When a seat becomes available:

The first player on the Waiting List shall receive priority for assignment.

Reception employees shall be notified that a seat has become available.

**Added to make the idea better.**

---

# **9.7 Trainer Assignment Rules**

A Trainer may belong to multiple Groups.

The system shall validate:

* Trainer availability.  
* Scheduling conflicts.  
* Trainer status.

The same Trainer may not be assigned to two Groups that overlap in time.

---

# **9.8 Player Assignment Rules**

A Player may only belong to one Group within the same Program at a time.

Moving a player to another Group within the same Program shall be treated as a Group Transfer rather than a new assignment.

The system shall preserve the player's attendance and subscription history during the transfer.

**Added to make the idea better.**

---

# **9.9 Group Transfers**

Authorized users may transfer players between Groups.

During transfer, the system shall:

* Validate capacity.  
* Validate schedule conflicts.  
* Preserve historical attendance.  
* Preserve subscription history.  
* Record the transfer in the Audit Log.

The transfer shall become effective immediately unless a future effective date is specified.

**Added to make the idea better.**

---

# **9.10 Group Status**

Available statuses:

* Active  
* Full  
* Inactive  
* Archived

The "Full" status may be assigned automatically when maximum capacity is reached.

If players leave the Group and seats become available, the system shall automatically return the status to "Active."

**Added to make the idea better.**

---

# **9.11 Editing Groups**

Users may edit:

* Name  
* Capacity  
* Trainers  
* Status  
* Schedule  
* Description

Capacity reductions shall not remove existing players automatically.

Instead, the system shall warn the user if the new capacity is less than the current number of enrolled players.

---

# **9.12 Search & Filters**

Users shall search Groups using:

* Group Name  
* Program  
* Trainer

Filters:

* Active  
* Full  
* Inactive  
* Archived

Sorting:

* Capacity  
* Number of Players  
* Attendance Percentage  
* Revenue

---

# **9.13 Business Rules**

* Every Group belongs to exactly one Program.  
* Every Group may contain one or more Trainers.  
* Every Group must have one designated Primary Trainer.  
* Every Group has a configurable maximum capacity.  
* Attendance shall always be recorded at the Group level.  
* Mirror assignments shall reference Groups rather than individual Players.  
* Deleting a Group with historical records shall not be permitted; it must be archived instead.

---

# **9.14 Notifications**

The system shall notify users when:

* A Group is created.  
* A Group reaches full capacity.  
* A player joins a Group.  
* A player leaves a Group.  
* A Group transfer is completed.  
* A trainer is assigned or removed.  
* A Group becomes inactive.

---

# **9.15 Audit Log**

Every Group operation shall be recorded.

The Audit Log shall include:

* Operation Type.  
* User.  
* Date and Time.  
* Previous Values.  
* New Values.  
* Reason (Optional).

---

# **Chapter 10 — Player Registration**

## **10.1 Introduction**

The Player Registration process is the entry point for every trainee joining the Sports Activity Module. A player must first be registered before they can be assigned to any Sport, Program, or Group.

The registration process is designed to minimize manual data entry by integrating with the Membership Module while still supporting Non-Members.

A registered player is initially considered a **Potential Player** until they are assigned to a Program and their financial requirements are completed.

---

# **10.2 Registration Methods**

The system shall support two registration methods.

### **Member Registration**

The employee may search using:

* Membership Number

or

* National ID

If a matching membership is found, the system shall automatically retrieve all available information from the Membership Module.

Retrieved information shall include:

* Full Name  
* National ID  
* Gender  
* Date of Birth  
* Age  
* Phone Number  
* Guardian Information (if available)  
* Membership Status  
* Membership Type

The retrieved data shall be read-only by default unless the user has permission to edit it.

---

### **Non-Member Registration**

If the player is not a club member, the employee shall manually enter all required information.

---

# **10.3 Registration Form**

The Player Registration page shall contain the following sections.

## **Membership Information**

* Membership Number (Optional)  
* Membership Status

---

## **Personal Information**

* National ID  
* Passport Number (Optional for Foreign Players)  
* Arabic Full Name  
* English Full Name  
* Gender  
* Date of Birth  
* Age (Calculated Automatically)  
* Nationality

---

## **Contact Information**

* Mobile Number  
* Alternative Mobile Number (Optional)  
* Email Address (Optional)  
* Address

---

## **Guardian Information**

If the player is under the club's configured guardian age (default: under 18 years old), the following fields become mandatory:

* Guardian Name  
* Guardian Relationship  
* Guardian National ID (Optional)  
* Guardian Mobile Number  
* Alternative Guardian Number (Optional)

The guardian age threshold shall be configurable through the system settings.

**Added to make the idea better.**

---

## **Sports Information**

The registration process shall not assign a Sport immediately.

Instead, the player becomes a Potential Player awaiting assignment.

---

# **10.4 Required Documents**

The following documents shall be uploaded during registration.

Mandatory:

* Player Photo  
* Birth Certificate  
* Parent/Guardian National ID  
* Medical Certificate

Optional:

* Passport Copy  
* Membership Card  
* Additional Documents

The system shall allow uploading multiple files under "Additional Documents."

---

# **10.5 Document Validation**

Supported formats:

* PDF  
* JPG  
* PNG

Maximum file size shall be configurable by the system administrator.

The system shall reject corrupted or unsupported files.

**Added to make the idea better.**

---

# **10.6 Duplicate Detection**

Before saving a player, the system shall check for duplicates using:

* National ID  
* Passport Number  
* Membership Number

If a duplicate is found:

The system shall display the existing player profile and prevent duplicate registration unless the user has override permission.

---

# **10.7 Foreign Players**

The system shall support registering foreign players.

Instead of a National ID, users may enter:

* Passport Number  
* Passport Expiration Date  
* Nationality

The system shall validate that either a National ID or Passport Number exists.

**Added to make the idea better.**

---

# **10.8 Saving the Registration**

After successful registration:

The player shall receive the status:

**Potential Player**

Potential Players:

* Cannot attend training.  
* Cannot appear in Attendance.  
* Cannot be scheduled in the Mirror.  
* Cannot renew subscriptions.

They shall only become Active after completing the assignment and payment workflow.

---

# **10.9 Registration Workflow**

Player Registration

↓

Upload Documents

↓

Validation

↓

Potential Player Created

↓

Awaiting Program Assignment

↓

Treasury Payment

↓

Active Player

---

# **10.10 Registration Validations**

The system shall validate:

* National ID format.  
* Passport format (if applicable).  
* Required fields.  
* Duplicate records.  
* Guardian information (if required).  
* Required documents.

Registration shall not be completed until all validations pass.

---

# **10.11 Registration Statuses**

Every registered player shall have one of the following statuses:

* Potential Player  
* Awaiting Payment  
* Active  
* Suspended  
* Inactive  
* Archived

Status changes shall occur automatically whenever possible.

Examples:

Payment Completed → Active

Subscription Expired → Inactive

Administrative Suspension → Suspended

**Added to make the idea better.**

---

# **10.12 Search & Filters**

Reception employees shall be able to search players using:

* Name  
* National ID  
* Membership Number  
* Mobile Number  
* Passport Number

Filters:

* Members  
* Non-Members  
* Potential Players  
* Active Players  
* Suspended Players  
* Inactive Players

---

# **10.13 Notifications**

The system shall generate notifications when:

* A new player is registered.  
* Duplicate registration is attempted.  
* Required documents are missing.  
* Registration is successfully completed.  
* A Potential Player has remained unassigned for a configurable number of days.

**Added to make the idea better.**

---

# **10.14 Audit Log**

Every registration operation shall be recorded.

The Audit Log shall include:

* User  
* Registration Date  
* Registration Method  
* Previous Values  
* New Values  
* Uploaded Documents  
* Reason for changes (if edited later)

---

# **Chapter 11 — Player Profile**

## **11.1 Introduction**

Every registered player shall have a dedicated Player Profile that acts as the central record for all sports-related information. This profile shall consolidate personal information, documents, enrollments, attendance, subscriptions, medical status, financial history, and activity logs into a single page.

The Player Profile shall remain available even if the player becomes inactive or leaves the club, ensuring complete historical tracking.

---

# **11.2 Profile Layout**

The Player Profile shall be divided into the following sections:

* Summary Header  
* Personal Information  
* Contact Information  
* Guardian Information  
* Sports Information  
* Program & Group History  
* Subscription Information  
* Medical Information  
* Attendance  
* Documents  
* Financial History  
* Activity Timeline  
* Notes

---

# **11.3 Summary Header**

The top of the profile shall display:

* Player Photo  
* Full Name  
* Player Code (Auto Generated)  
* Membership Number (if applicable)  
* National ID / Passport Number  
* Current Status  
* Current Sport(s)  
* Current Program(s)  
* Current Group(s)  
* Assigned Trainer(s)  
* Medical Status

The Medical Status shall be visually highlighted:

* Green: Approved  
* Yellow: Grace Period  
* Red: Expired / Rejected

---

# **11.4 Personal Information**

Display:

* Arabic Name  
* English Name  
* Gender  
* Date of Birth  
* Age  
* Nationality

Age shall always be calculated automatically from the Date of Birth.

---

# **11.5 Contact Information**

Display:

* Mobile Number  
* Alternative Number  
* Email  
* Address

Authorized users may update contact information without affecting historical records.

---

# **11.6 Guardian Information**

If applicable:

* Guardian Name  
* Relationship  
* National ID  
* Mobile Number  
* Alternative Number

Changes shall be recorded in the Audit Log.

---

# **11.7 Sports Information**

Display all current enrollments.

For each Sport:

* Sport Name  
* Program  
* Group  
* Join Date  
* Current Status  
* Assigned Trainer(s)

The system shall support multiple active sports for the same player if permitted by club policy.

**Added to make the idea better.**

---

# **11.8 Subscription Information**

Display:

* Current Subscription Status  
* Last Payment Date  
* Next Renewal Date  
* Subscription Amount  
* Outstanding Balance  
* Treasury Transaction Reference

Users shall be able to navigate directly to the related Treasury transaction.

---

# **11.9 Medical Information**

Display:

* Current Medical Status  
* Certificate Level  
* Approval Date  
* Expiration Date  
* Reviewing Medical Employee  
* Grace Period End Date (if applicable)

If the certificate expires, a warning banner shall appear at the top of the profile.

---

# **11.10 Attendance**

Display attendance history with filters by:

* Sport  
* Program  
* Group  
* Date Range

Each attendance record shall include:

* Session Date  
* Attendance Status  
* Recorded By  
* Excuse Details (if any)

The profile shall also display:

* Total Sessions  
* Attended Sessions  
* Absent Sessions  
* Attendance Percentage

---

# **11.11 Documents**

All uploaded documents shall be organized into categories:

* Player Photo  
* Birth Certificate  
* Guardian ID  
* Medical Certificates  
* Passport  
* Other Documents

Users with appropriate permissions may:

* View  
* Download  
* Replace  
* Upload New Versions

The system shall preserve previous document versions where version control is enabled.

**Added to make the idea better.**

---

# **11.12 Financial History**

Display all financial transactions related to the player:

* Initial Registration Fees  
* Monthly Subscriptions  
* Recreational Bookings (if applicable)  
* Additional Charges  
* Refunds  
* Discounts Applied

Each transaction shall include its Treasury status and reference number.

---

# **11.13 Activity Timeline**

The profile shall include a chronological timeline of important events, such as:

* Registration  
* Program Assignment  
* Group Transfer  
* Medical Approval  
* Subscription Renewals  
* Attendance Warnings  
* Suspensions  
* Document Updates

Each event shall include the user who performed the action and the timestamp.

**Added to make the idea better.**

---

# **11.14 Notes**

Authorized users may add internal notes to the player profile.

Each note shall record:

* Author  
* Date and Time  
* Note Content

Notes shall not be visible to players or guardians if a future player portal is implemented.

**Added to make the idea better.**

---

# **11.15 Business Rules**

* A Player Profile is created automatically after successful registration.  
* Historical records shall never be deleted.  
* Multiple sports may be associated with one player if permitted.  
* Medical status shall update automatically after certificate review.  
* Financial data shall remain synchronized with the Treasury Module.  
* All modifications shall be recorded in the Audit Log.

---

# **11.16 Permissions**

Reception Employees may:

* View profiles.  
* Edit contact information.  
* Upload documents.

Sports Employees may additionally:

* View sports information.  
* Assign programs and groups.

Medical Employees may only modify medical information.

Treasury Employees may only view financial information.

System Administrators shall have full access to all profile sections.

---

# **11.17 Audit Log**

Every modification to the Player Profile shall be recorded, including:

* Edited fields.  
* Uploaded or replaced documents.  
* Status changes.  
* Program and Group changes.  
* User performing the action.  
* Date and Time.  
* Reason for the modification (optional).

**Chapter 12 — Trainer Management**

## **12.1 Introduction**

The Trainer Management section is responsible for registering, organizing, and managing all trainers within the Sports Activity Module. Trainers are responsible for conducting training sessions, supervising players, recording attendance, and managing assigned Groups.

A trainer may work independently or be affiliated with an Academy. The system shall support assigning one trainer to multiple Groups and multiple trainers to the same Group while preventing scheduling conflicts.

Each Trainer shall have a dedicated profile containing personal information, assigned sports, groups, schedules, attendance responsibilities, documents, and activity history.

---

# **12.2 Trainer Registration**

When registering a Trainer, the following information shall be collected.

### **Basic Information**

* Trainer Code (Generated Automatically)  
* Arabic Full Name  
* English Full Name (Optional)  
* National ID  
* Passport Number (Optional for Foreign Trainers)  
* Gender  
* Date of Birth  
* Age (Calculated Automatically)  
* Nationality

---

### **Contact Information**

* Mobile Number  
* Alternative Mobile Number (Optional)  
* Email Address (Optional)  
* Residential Address

---

### **Employment Information**

* Employment Type  
  * Full-Time  
  * Part-Time  
  * Freelance  
  * Academy Trainer  
* Employment Start Date  
* Employment End Date (Optional)  
* Status

---

### **Academy Information**

If the Trainer belongs to an Academy:

* Academy Name  
* Academy Position (Optional)

If the Trainer works independently, this section shall remain empty.

---

### **Sports Specialization**

The user shall select one or more Sports that the Trainer is qualified to coach.

The system shall only allow assigning the Trainer to Programs and Groups belonging to the selected Sports.

---

### **Documents**

The Trainer profile shall support uploading:

* Personal Photo  
* National ID  
* Passport (Optional)  
* Employment Contract (Optional)  
* Certifications  
* Coaching Licenses  
* Medical Clearance (Optional)  
* Other Documents

Multiple files shall be allowed where applicable.

---

# **12.3 Trainer Status**

Available Trainer statuses include:

* Active  
* On Leave  
* Suspended  
* Inactive  
* Archived

Only Active Trainers may be assigned to Groups.

---

# **12.4 Trainer Profile**

Every Trainer shall have a dedicated profile containing:

### **Summary**

* Trainer Photo  
* Trainer Code  
* Full Name  
* Status  
* Academy  
* Assigned Sports

---

### **Personal Information**

* National ID  
* Date of Birth  
* Age  
* Nationality

---

### **Contact Information**

* Phone Numbers  
* Email  
* Address

---

### **Sports Information**

Display:

* Sports  
* Programs  
* Groups  
* Total Active Players

---

### **Schedule**

The Trainer Profile shall display the Trainer's complete weekly schedule, including:

* Training Sessions  
* Assigned Facilities  
* Training Hours  
* Upcoming Sessions

The schedule shall be synchronized with the Mirror System.

---

### **Performance Statistics**

Display:

* Number of Groups  
* Number of Players  
* Weekly Training Hours  
* Monthly Attendance Percentage for Assigned Groups  
* Average Group Attendance  
* Years of Service

**Added to make the idea better.**

---

### **Documents**

Display all uploaded Trainer documents with options to:

* View  
* Download  
* Replace  
* Upload New Versions

---

### **Activity Timeline**

Display all important Trainer activities.

Examples:

* Trainer Registered  
* Assigned to Group  
* Removed from Group  
* Status Changed  
* Documents Updated

---

# **12.5 Trainer Assignment**

Trainers shall be assigned to Groups rather than directly to Players.

Each Group shall have:

* One Primary Trainer  
* Zero or More Assistant Trainers

The Primary Trainer shall be responsible for:

* Attendance  
* Daily Training  
* Session Management

Assistant Trainers may also record attendance if granted permission.

**Added to make the idea better.**

---

# **12.6 Trainer Availability Validation**

Before assigning a Trainer, the system shall validate:

* Trainer Status  
* Assigned Sports  
* Scheduling Conflicts  
* Working Hours

Assignment shall be rejected if:

* The Trainer is inactive.  
* The Trainer is suspended.  
* The Trainer is already assigned to another Group during the same time period.

---

# **12.7 Working Hours**

The Trainer profile may define working hours.

Example:

Sunday

08:00 AM \- 04:00 PM

Monday

10:00 AM \- 08:00 PM

These working hours shall be used when validating assignments.

The system shall warn users when assigning sessions outside the Trainer's working hours.

**Added to make the idea better.**

---

# **12.8 Trainer Transfer**

Authorized users may transfer a Trainer between Groups.

The transfer process shall:

* Preserve attendance history.  
* Preserve historical reports.  
* Update future Mirror assignments where applicable.  
* Record the transfer in the Audit Log.

The transfer may become effective immediately or on a future date.

**Added to make the idea better.**

---

# **12.9 Trainer Search & Filters**

Search fields:

* Trainer Name  
* Trainer Code  
* National ID  
* Mobile Number  
* Academy

Filters:

* Sport  
* Academy  
* Active  
* On Leave  
* Suspended  
* Inactive

Sorting:

* Name  
* Number of Groups  
* Number of Players  
* Weekly Hours  
* Employment Date

---

# **12.10 Business Rules**

* Every Trainer shall have a unique Trainer Code.  
* Trainers may coach multiple Groups.  
* Multiple Trainers may coach the same Group.  
* Only one Primary Trainer may exist per Group.  
* Trainers shall only coach Sports for which they are registered.  
* Trainer schedules shall remain synchronized with the Mirror System.  
* Historical Trainer assignments shall never be deleted.

---

# **12.11 Notifications**

The system shall notify users when:

* A Trainer is registered.  
* A Trainer is assigned to a Group.  
* A Trainer is removed from a Group.  
* A scheduling conflict occurs.  
* A Trainer becomes inactive.  
* A Trainer returns from leave.

---

# **12.12 Permissions**

Reception Employees may:

* View Trainer information.

Sports Employees may:

* Register Trainers.  
* Edit Trainers.  
* Assign Trainers.

Sports Managers may additionally:

* Change Trainer status.  
* Transfer Trainers.  
* Archive Trainers.

System Administrators shall have unrestricted access.

---

# **12.13 Audit Log**

Every Trainer operation shall be recorded.

The Audit Log shall include:

* Operation Type  
* User  
* Date and Time  
* Previous Values  
* New Values  
* Reason (Optional)

---

# **Chapter 13 — Academy Management**

## **13.1 Introduction**

The Academy Management section allows the club to register external or internal academies that provide training services. Academies act as organizational entities under which Trainers may work.

An Academy may be responsible for one or more Sports, employ multiple Trainers, and manage multiple Groups through those Trainers.

Academies simplify the management of outsourced coaching teams while maintaining complete operational and financial tracking.

---

# **13.2 Academy Registration**

The following information shall be collected.

### **Basic Information**

* Academy Code (Generated Automatically)  
* Academy Name (Arabic)  
* Academy Name (English) (Optional)  
* Status  
* Description (Optional)

---

### **Contact Information**

* Contact Person  
* Mobile Number  
* Alternative Number  
* Email Address  
* Address

---

### **Sports**

Users shall select one or more Sports managed by the Academy.

Only Trainers belonging to the Academy may coach those selected Sports unless overridden by an authorized user.

**Added to make the idea better.**

---

### **Documents**

The Academy shall support uploading:

* Commercial Registration (Optional)  
* Tax Card (Optional)  
* Contract  
* Logo (Optional)  
* Other Documents

---

# **13.3 Academy Status**

Available statuses:

* Active  
* Suspended  
* Inactive  
* Archived

Only Active Academies may have Trainers assigned to Groups.

---

# **13.4 Academy Profile**

The Academy Profile shall include:

### **Summary**

* Academy Name  
* Academy Code  
* Status

---

### **Contact Information**

* Contact Person  
* Phone Numbers  
* Email  
* Address

---

### **Sports**

Display all associated Sports.

---

### **Trainers**

Display:

* Active Trainers  
* Inactive Trainers  
* Total Trainers

Each Trainer shall link directly to their Trainer Profile.

---

### **Groups**

Display all Groups currently coached by Academy Trainers.

---

### **Statistics**

Display:

* Number of Sports  
* Number of Trainers  
* Number of Groups  
* Number of Players coached  
* Total Monthly Revenue generated through Academy Groups (reporting purposes only)

**Added to make the idea better.**

---

### **Documents**

Display all uploaded Academy documents.

---

### **Activity Timeline**

Display:

* Academy Registered  
* Trainer Added  
* Trainer Removed  
* Status Changes  
* Contract Updates

---

# **13.5 Trainer Relationship**

A Trainer may:

* Belong to one Academy.

or

* Work independently.

A Trainer cannot belong to multiple Academies simultaneously.

If a Trainer changes Academies, the previous relationship shall remain available in historical records.

**Added to make the idea better.**

---

# **13.6 Academy Search & Filters**

Search:

* Academy Name  
* Academy Code  
* Contact Person

Filters:

* Active  
* Suspended  
* Inactive  
* Archived  
* Sport

Sorting:

* Name  
* Number of Trainers  
* Number of Sports  
* Date Created

---

# **13.7 Editing an Academy**

Users may edit:

* Name  
* Contact Information  
* Sports  
* Documents  
* Status

Removing a Sport from an Academy shall not automatically remove Trainers already assigned to Groups. The system shall warn the user before saving such changes.

**Added to make the idea better.**

---

# **13.8 Business Rules**

* Every Academy shall have a unique Academy Code.  
* An Academy may manage multiple Sports.  
* An Academy may employ multiple Trainers.  
* A Trainer may belong to only one Academy at a time.  
* Inactive Academies shall not receive new Trainer assignments.  
* Historical Academy information shall never be deleted.

---

# **13.9 Notifications**

The system shall notify users when:

* An Academy is registered.  
* An Academy becomes inactive.  
* A Trainer joins an Academy.  
* A Trainer leaves an Academy.  
* Academy documents are updated.  
* Academy status changes.

---

# **13.10 Permissions**

Reception Employees may:

* View Academy information.

Sports Employees may:

* Register Academies.  
* Edit Academies.

Sports Managers may additionally:

* Activate or suspend Academies.  
* Archive Academies.

System Administrators shall have unrestricted access.

---

# **13.11 Audit Log**

Every Academy operation shall be recorded.

The Audit Log shall include:

* Operation Type  
* User  
* Date and Time  
* Previous Values  
* New Values  
* Reason (Optional)

# **Chapter 14 — Player Assignment Management**

## **14.1 Introduction**

The Player Assignment Management section is responsible for converting a **Potential Player** into an **Active Player** by assigning them to a Sport, Program, and Group. This process also integrates with the Treasury Module to ensure that financial requirements are completed before the player begins training.

This chapter governs the entire assignment workflow, including validations, program selection, group assignment, payment requests, activation, transfers, and reassignment.

---

# **14.2 Assignment Workflow**

Every newly registered player shall follow the workflow below:

Potential Player

↓

Select Sport

↓

Select Program

↓

Select Group

↓

System Validation

↓

Generate Treasury Transaction

↓

Payment Completed

↓

Player Activated

↓

Player Appears in Attendance & Mirror

The player shall not appear in attendance sheets or training schedules until activation is complete.

---

# **14.3 Program Assignment Screen**

The **Player Assignment** page shall display all Potential Players in a searchable list.

For each player, the following information shall be displayed:

* Player Photo  
* Player Name  
* Player Code  
* Membership Status  
* Age  
* Registration Date  
* Medical Certificate Status  
* Current Assignment Status

Users may select one or multiple players for assignment.

**Added to make the idea better.**

---

# **14.4 Selecting a Sport**

After selecting a player, the system shall display all available Training Sports as interactive cards.

Each card shall display:

* Sport Name  
* Number of Available Programs  
* Active Players  
* Sport Status

Inactive Sports shall not be selectable.

---

# **14.5 Selecting a Program**

After selecting a Sport, the system shall display all Active Programs belonging to that Sport.

Each Program card shall display:

* Program Name  
* Member Price  
* Non-Member Price  
* Number of Groups  
* Available Seats  
* Registration Status

Programs with closed registration shall be displayed but disabled unless overridden by an authorized user.

---

# **14.6 Selecting a Group**

After selecting a Program, the system shall display all available Groups.

Each Group shall display:

* Group Name  
* Primary Trainer  
* Assistant Trainers  
* Capacity  
* Remaining Seats  
* Training Days  
* Training Hours  
* Current Attendance Percentage

If the Group has reached maximum capacity, it shall either:

* Prevent assignment, or  
* Offer to place the player on the Waiting List (if enabled).

---

# **14.7 Validation Before Assignment**

Before completing the assignment, the system shall validate:

* Player Status.  
* Program Status.  
* Group Capacity.  
* Player Age Restrictions.  
* Gender Restrictions.  
* Duplicate Assignments.  
* Registration Period.  
* Subscription Rules.  
* Trainer Availability (where applicable).

The assignment shall not proceed until all validations pass.

---

# **14.8 Treasury Integration**

After successful validation, the system shall automatically create a pending Treasury transaction.

The transaction shall include:

* Player Name  
* Sport  
* Program  
* Subscription Period  
* Member / Non-Member Pricing  
* Discounts Applied  
* Taxes (if applicable)  
* Additional Fees  
* Final Amount

The player status shall change to:

**Awaiting Payment**

---

# **14.9 Player Activation**

Once the Treasury confirms payment:

The player status shall automatically change to:

**Active**

The player shall immediately become available in:

* Attendance.  
* Mirror Assignments.  
* Reports.  
* Trainer Lists.  
* Group Statistics.

No manual activation shall be required.

---

# **14.10 Multiple Sports**

If allowed by club policy, a player may enroll in multiple Sports simultaneously.

Each Sport shall maintain:

* Independent Program  
* Independent Group  
* Independent Subscription  
* Independent Attendance  
* Independent Medical Tracking (if required by policy)

The system shall prevent duplicate enrollment within the same Program but shall allow enrollment in different Sports.

**Added to make the idea better.**

---

# **14.11 Assignment History**

Every assignment shall be preserved.

History shall include:

* Assignment Date  
* Assigned By  
* Sport  
* Program  
* Group  
* Treasury Reference  
* Activation Date  
* Status

Historical assignments shall remain accessible even after transfers or cancellations.

---

# **14.12 Reassignment**

Authorized users may reassign a player to another Program or Group.

Examples:

* Program Change  
* Group Change  
* Sport Transfer

During reassignment, the system shall:

* Validate capacity.  
* Preserve attendance history.  
* Preserve payment history.  
* Record the reason for transfer.  
* Update future Mirror schedules.

Previous assignments shall remain available in the player's history.

---

# **14.13 Cancellation**

Assignments may be cancelled before activation.

Cancellation shall:

* Remove pending Group assignments.  
* Cancel the Treasury transaction if unpaid.  
* Return the player to Potential Player status.

If payment has already been completed, cancellation shall follow the club's refund policy.

**Added to make the idea better.**

---

# **14.14 Search & Filters**

Users shall search assignments using:

* Player Name  
* Player Code  
* Membership Number  
* Sport  
* Program  
* Group

Filters:

* Potential Players  
* Awaiting Payment  
* Active  
* Suspended  
* Cancelled

Sorting:

* Registration Date  
* Activation Date  
* Player Name

---

# **14.15 Business Rules**

* Players cannot be assigned directly to Groups without selecting a Program.  
* Players cannot attend training before activation.  
* Every assignment shall generate a Treasury transaction.  
* Assignment history shall never be deleted.  
* Group capacity shall always be validated.  
* Waiting Lists shall only be used if enabled.

---

# **14.16 Notifications**

The system shall notify users when:

* A player is assigned.  
* Payment is pending.  
* Payment is completed.  
* A player becomes active.  
* Assignment fails due to validation errors.  
* A waiting list position becomes available.

---

# **14.17 Permissions**

Reception Employees may:

* View Potential Players.

Sports Employees may:

* Assign Players.  
* Reassign Players.  
* View Assignment History.

Sports Managers may additionally:

* Override validation rules.  
* Approve exceptional assignments.  
* Cancel assignments.

System Administrators shall have unrestricted access.

---

# **14.18 Audit Log**

Every assignment operation shall be recorded.

The Audit Log shall include:

* User  
* Date and Time  
* Assignment Details  
* Previous Values  
* New Values  
* Treasury Reference  
* Reason (Optional)

---

# **Chapter 15 — Medical Management**

## **15.1 Introduction**

Medical Management ensures that every player meets the club's medical requirements before participating in sports activities. The system shall manage the complete lifecycle of medical certificates, including submission, review, approval, expiration tracking, grace periods, renewals, and notifications.

The Medical Management section shall be accessible only to authorized medical personnel and administrators.

---

# **15.2 Medical Workflow**

The medical process shall follow the workflow below:

Player Registration

↓

Medical Certificate Uploaded

↓

Pending Medical Review

↓

Medical Employee Review

↓

Approved or Rejected

↓

Medical Level Assigned

↓

Certificate Monitoring

↓

Renewal Before Expiration

Players may begin training during the configured grace period, but renewal restrictions shall apply if the certificate is not approved in time.

---

# **15.3 Medical Review Dashboard**

The Medical Dashboard shall display:

* Pending Reviews  
* Approved Certificates  
* Rejected Certificates  
* Expired Certificates  
* Certificates Expiring Soon  
* Players in Grace Period

Each section shall include search, filters, and sorting options.

---

# **15.4 Medical Certificate Review**

Medical employees shall open each pending certificate and view:

* Player Information  
* Uploaded Certificate  
* Registration Date  
* Program  
* Group  
* Current Status

The reviewer may:

* Approve  
* Reject  
* Request Replacement

A comment field shall be available for all review outcomes.

**Added to make the idea better.**

---

# **15.5 Medical Levels**

Upon approval, the reviewer shall assign one of the following levels:

* Level 1  
* Level 2  
* Level 3

The level shall remain visible on:

* Player Profile  
* Medical Dashboard  
* Attendance Screen (optional indicator)

The meaning of each level shall be configurable by the club.

**Added to make the idea better.**

---

# **15.6 Grace Period**

The system shall support a configurable grace period.

Default:

30 Days

During this period:

* Players may attend training.  
* Attendance shall be recorded normally.  
* Program participation shall continue.

If the grace period expires without an approved certificate:

* Subscription renewal shall be blocked.  
* New Program assignments shall be blocked.  
* Warning messages shall appear on the Player Profile.

Existing attendance history shall remain unchanged.

---

# **15.7 Certificate Expiration**

Every approved certificate shall contain:

* Approval Date  
* Expiration Date

The system shall automatically monitor expiration.

Notifications shall be generated:

* 30 days before expiration.  
* 14 days before expiration.  
* 7 days before expiration.  
* On the expiration date.

The reminder intervals shall be configurable.

**Added to make the idea better.**

---

# **15.8 Certificate Renewal**

Players may upload a new certificate before the current one expires.

The renewal process shall:

* Preserve previous certificates.  
* Create a new review request.  
* Maintain complete historical records.  
* Update the Player Profile after approval.

---

# **15.9 Rejected Certificates**

If a certificate is rejected:

The reviewer shall specify:

* Reason for Rejection  
* Additional Notes  
* Required Corrections

The player may upload a replacement certificate without creating a new registration.

---

# **15.10 Medical History**

The system shall preserve all previous medical certificates.

History shall include:

* Upload Date  
* Reviewer  
* Decision  
* Medical Level  
* Approval Date  
* Expiration Date  
* Comments

Historical certificates shall never be overwritten or deleted.

---

# **15.11 Search & Filters**

Search by:

* Player Name  
* Player Code  
* National ID  
* Membership Number

Filters:

* Pending Review  
* Approved  
* Rejected  
* Grace Period  
* Expired  
* Expiring Soon  
* Medical Level

Sorting:

* Upload Date  
* Expiration Date  
* Player Name

---

# **15.12 Business Rules**

* Every player shall have a medical record.  
* Every uploaded certificate shall undergo review.  
* Historical certificates shall remain permanently available.  
* Expired certificates shall not invalidate historical attendance.  
* Medical approval shall synchronize automatically with the Player Profile.  
* Grace period duration shall be configurable through system settings.  
* Only authorized medical personnel may approve or reject certificates.

---

# **15.13 Notifications**

The system shall notify:

* Medical staff when new certificates are submitted.  
* Players (through the club's notification mechanism) when certificates are approved or rejected.  
* Reception employees when a player is blocked due to an expired certificate.  
* Administrators when certificates remain pending beyond a configurable review period.

**Added to make the idea better.**

---

# **15.14 Permissions**

Reception Employees may:

* View medical status.  
* Upload replacement certificates.

Medical Employees may:

* Review certificates.  
* Approve certificates.  
* Reject certificates.  
* Assign medical levels.

Sports Employees may:

* View medical status only.

System Administrators shall have unrestricted access.

---

# **15.15 Audit Log**

Every medical operation shall be recorded.

The Audit Log shall include:

* Operation Type.  
* User.  
* Date and Time.  
* Previous Status.  
* New Status.  
* Medical Level.  
* Comments.  
* Reason for Rejection (if applicable).

# **Chapter 16 — Attendance Management**

## **16.1 Introduction**

Attendance Management is responsible for recording, monitoring, and analyzing player attendance for every scheduled training session. Attendance shall always be recorded at the **Group Session** level, ensuring accurate tracking of player participation and allowing the club to monitor attendance trends, absenteeism, and make-up sessions.

Attendance is directly linked to the Mirror System. Only Groups scheduled in the Mirror for the current date and time shall appear in the Attendance screen.

The Attendance Module shall support daily attendance recording, attendance reports, excuses, make-up session eligibility, and attendance analytics.

---

# **16.2 Attendance Workflow**

The attendance process shall follow the workflow below:

Mirror Schedule Created

↓

Training Session Begins

↓

Trainer Opens Attendance Screen

↓

Attendance Recorded

↓

Attendance Saved

↓

Attendance Statistics Updated

↓

Reports Generated

Attendance may only be recorded once per scheduled session unless edited by an authorized user.

---

# **16.3 Daily Attendance Screen**

The Daily Attendance page shall automatically display all scheduled Groups for the selected date.

For each Group, the system shall display:

* Sport  
* Program  
* Group Name  
* Facility  
* Mirror Assignment  
* Session Start Time  
* Session End Time  
* Primary Trainer  
* Number of Registered Players

Selecting a Group shall display all active players enrolled in that Group.

---

# **16.4 Attendance Options**

Each player shall have one attendance status for every session.

Available statuses:

### **Attended**

The player attended the entire session.

---

### **Absent**

The player did not attend.

No compensation session shall be granted.

---

### **Accepted Excuse**

The player was absent for an approved reason.

The trainer shall enter:

* Excuse Description

The player becomes eligible for a make-up session according to the club's policy.

---

### **Rejected Excuse**

The player submitted an excuse that was not approved.

The trainer shall enter:

* Excuse Description

This attendance shall be treated as an ordinary absence.

---

### **Late Arrival**

The player attended but arrived after the scheduled start time.

The trainer may optionally record:

* Arrival Time  
* Minutes Late

Late arrivals shall count as attendance unless club policy specifies otherwise.

**Added to make the idea better.**

---

### **Left Early**

The player attended but left before the session ended.

The trainer may optionally enter:

* Departure Time  
* Reason

This status shall still count as attendance unless configured differently.

**Added to make the idea better.**

---

# **16.5 Attendance Recording Rules**

Attendance shall only be recorded for:

* Active Players  
* Active Groups  
* Scheduled Sessions

The system shall prevent attendance recording for:

* Suspended Players  
* Inactive Players  
* Cancelled Sessions  
* Groups without scheduled Mirror assignments

---

# **16.6 Bulk Attendance**

To reduce data entry time, the system shall provide quick actions:

* Mark Everyone Present  
* Mark Everyone Absent  
* Clear Attendance  
* Copy Previous Session Attendance (Optional)

After applying a bulk action, trainers may manually edit individual players.

**Added to make the idea better.**

---

# **16.7 Attendance Editing**

Attendance may be edited only by authorized users.

When attendance is modified after being saved, the system shall record:

* Original Status  
* New Status  
* User  
* Date and Time  
* Reason for Modification

Historical attendance shall never be overwritten without maintaining an audit trail.

---

# **16.8 Session Cancellation**

If a scheduled training session is cancelled:

The trainer or manager shall specify:

* Cancellation Reason  
* Cancellation Type

Examples:

* Weather Conditions  
* Facility Maintenance  
* Public Holiday  
* Trainer Unavailable  
* Emergency

Cancelled sessions shall not affect player attendance percentages and shall not be counted as absences.

**Added to make the idea better.**

---

# **16.9 Attendance Statistics**

The system shall automatically calculate:

Per Player:

* Total Sessions  
* Attended Sessions  
* Absent Sessions  
* Accepted Excuses  
* Rejected Excuses  
* Attendance Percentage

Per Group:

* Average Attendance  
* Attendance Trend  
* Number of Active Players  
* Average Players per Session

Per Program:

* Overall Attendance Percentage  
* Total Sessions  
* Total Players

Per Sport:

* Overall Attendance Rate  
* Attendance Comparison Between Programs

---

# **16.10 Attendance Warnings**

The system shall support configurable attendance warning rules.

Examples:

* Attendance below 80%  
* Three consecutive absences  
* Five absences during one month

When triggered, the system shall generate notifications for:

* Reception  
* Sports Manager  
* Trainer

Warning thresholds shall be configurable.

**Added to make the idea better.**

---

# **16.11 Attendance Reports**

Reports shall include:

* Daily Attendance  
* Weekly Attendance  
* Monthly Attendance  
* Attendance by Sport  
* Attendance by Program  
* Attendance by Group  
* Attendance by Trainer  
* Attendance by Player

Reports shall support:

* Export to PDF  
* Export to Excel  
* Printing

---

# **16.12 Search & Filters**

Search:

* Player Name  
* Group Name  
* Program  
* Trainer

Filters:

* Date  
* Sport  
* Attendance Status  
* Group  
* Program  
* Trainer

Sorting:

* Player Name  
* Attendance Percentage  
* Number of Absences  
* Number of Sessions

---

# **16.13 Business Rules**

* Attendance may only be recorded for scheduled sessions.  
* One attendance record shall exist per player per session.  
* Accepted excuses shall make the player eligible for make-up sessions.  
* Rejected excuses shall be treated as absences.  
* Cancelled sessions shall not affect attendance statistics.  
* Attendance percentages shall update automatically after every session.  
* Attendance records shall never be permanently deleted.

---

# **16.14 Notifications**

The system shall notify users when:

* Attendance has not been recorded for today's sessions.  
* A player's attendance falls below the configured threshold.  
* Consecutive absences exceed the configured limit.  
* Attendance has been modified after submission.  
* A session has been cancelled.

---

# **16.15 Permissions**

Reception Employees may:

* View attendance.

Trainers may:

* Record attendance.  
* Edit attendance before the daily attendance deadline.

Sports Managers may:

* Edit attendance at any time.  
* Cancel sessions.  
* Generate attendance reports.

System Administrators shall have unrestricted access.

---

# **16.16 Audit Log**

Every attendance operation shall be recorded.

The Audit Log shall include:

* Operation Type  
* User  
* Date and Time  
* Session  
* Player  
* Previous Status  
* New Status  
* Reason (if modified)

---

# **Chapter 17 — Make-up Sessions (تعويض الحصص)**

## **17.1 Introduction**

The Make-up Session Management module allows players who miss training sessions with an **Accepted Excuse** to recover those missed sessions without paying additional fees.

A Make-up Session represents a replacement training session that compensates for a previously approved absence.

The system shall ensure that make-up sessions are managed fairly, tracked accurately, and scheduled without exceeding group capacities or causing scheduling conflicts.

---

# **17.2 Eligibility Rules**

A player becomes eligible for a Make-up Session only if all of the following conditions are met:

* The player has an **Accepted Excuse**.  
* The missed session belongs to an Active Program.  
* The player's subscription is active.  
* The missed session has not already been compensated.  
* The compensation period has not expired.

The compensation period shall be configurable by the club.

Default recommendation:

30 days from the missed session.

**Added to make the idea better.**

---

# **17.3 Make-up Session Workflow**

Accepted Excuse

↓

Player Added to Eligible List

↓

Reception or Trainer Schedules Make-up Session

↓

Player Attends Make-up Session

↓

Original Session Marked as Compensated

↓

Statistics Updated

---

# **17.4 Eligible Sessions List**

The system shall provide a page displaying all players eligible for make-up sessions.

Displayed information:

* Player Name  
* Player Code  
* Sport  
* Program  
* Group  
* Missed Session Date  
* Excuse Reason  
* Remaining Validity Period  
* Compensation Status

---

# **17.5 Scheduling a Make-up Session**

When scheduling a make-up session, the system shall allow the user to:

* Select the player.  
* Choose an available Group.  
* Select the training date.  
* Select the session.  
* Confirm the reservation.

The selected Group may be different from the player's original Group, provided that:

* It belongs to the same Sport.  
* It matches the player's skill level or Program (configurable by club policy).  
* Capacity allows an additional player.

**Added to make the idea better.**

---

# **17.6 Capacity Validation**

Before confirming the make-up session, the system shall validate:

* Group capacity.  
* Trainer availability.  
* Mirror availability.  
* Session status.  
* Player schedule conflicts.

The system shall reject reservations that violate any validation rule.

---

# **17.7 Make-up Session Attendance**

Attendance for make-up sessions shall be recorded separately from normal sessions.

Possible statuses:

* Attended  
* Absent  
* Accepted Excuse  
* Rejected Excuse

If the player attends, the original missed session shall automatically be marked as **Compensated**.

If the player misses the make-up session without an accepted excuse, the compensation opportunity shall be considered used unless overridden by a Sports Manager.

**Added to make the idea better.**

---

# **17.8 Expiration**

Eligible make-up sessions shall automatically expire after the configured compensation period.

Expired sessions shall:

* Be marked as Expired.  
* No longer be available for scheduling.  
* Remain visible in historical records.

---

# **17.9 Make-up History**

Each player shall have a complete make-up session history.

Displayed information:

* Original Session Date  
* Make-up Session Date  
* Assigned Group  
* Trainer  
* Attendance Status  
* Compensation Status

Historical records shall never be deleted.

---

# **17.10 Reports**

The system shall provide reports including:

* Eligible Make-up Sessions  
* Completed Make-up Sessions  
* Expired Make-up Sessions  
* Compensation Rate by Sport  
* Compensation Rate by Trainer

---

# **17.11 Search & Filters**

Search:

* Player Name  
* Player Code  
* Sport  
* Group

Filters:

* Eligible  
* Scheduled  
* Completed  
* Expired  
* Cancelled

Sorting:

* Missed Session Date  
* Expiration Date  
* Player Name

---

# **17.12 Business Rules**

* Only Accepted Excuses generate make-up eligibility.  
* Each missed session may generate only one make-up session.  
* Make-up sessions shall not require additional payment.  
* Expired make-up sessions shall not be reactivated without manager approval.  
* Make-up attendance shall remain separate from regular attendance records while still contributing to compensation tracking.  
* Every completed make-up session shall be permanently linked to its original missed session.

---

# **17.13 Notifications**

The system shall notify users when:

* A player becomes eligible for a make-up session.  
* A make-up session is scheduled.  
* A make-up session is approaching its expiration date.  
* A make-up session expires.  
* A player misses a scheduled make-up session.

---

# **17.14 Permissions**

Reception Employees may:

* View eligible make-up sessions.  
* Schedule make-up sessions.

Trainers may:

* Record make-up attendance.

Sports Managers may:

* Override eligibility rules.  
* Extend expiration periods.  
* Cancel scheduled make-up sessions.

System Administrators shall have unrestricted access.

---

# **17.15 Audit Log**

Every make-up session operation shall be recorded.

The Audit Log shall include:

* Operation Type.  
* User.  
* Date and Time.  
* Original Session.  
* Make-up Session.  
* Previous Status.  
* New Status.  
* Reason (if applicable).

**Chapter 18 — Subscription Management**

## **18.1 Introduction**

The Subscription Management module is responsible for managing the financial lifecycle of every player's enrollment in Training Sports. It controls subscription creation, renewals, expirations, suspensions, pricing, discounts, and Treasury integration.

Each Program assignment shall have its own subscription. If a player is enrolled in multiple Sports or Programs, each enrollment shall maintain an independent subscription.

The Subscription Management module shall integrate directly with:

* Player Registration  
* Player Assignment  
* Treasury Module  
* Medical Management  
* Attendance  
* Reports  
* Notifications

---

# **18.2 Subscription Workflow**

The subscription process shall follow the workflow below:

Player Assigned

↓

Treasury Transaction Created

↓

Payment Completed

↓

Subscription Activated

↓

Training Begins

↓

Renewal Reminder

↓

Renewal Payment

↓

Subscription Extended

or

Subscription Expired

---

# **18.3 Subscription Types**

The system shall support the following subscription types:

### **Monthly Subscription**

The default subscription type.

Valid for one calendar month from the activation date unless configured otherwise.

---

### **Multi-Month Subscription**

The club may optionally allow subscriptions for:

* 2 Months  
* 3 Months  
* 6 Months  
* 12 Months

Pricing may include discounts according to club policy.

**Added to make the idea better.**

---

### **Promotional Subscription**

A temporary subscription created during club promotions.

The promotion may define:

* Fixed Discount  
* Percentage Discount  
* Valid Date Range

Promotional pricing shall not affect the Program's default pricing.

**Added to make the idea better.**

---

# **18.4 Subscription Creation**

A subscription shall be automatically created after:

* Program Assignment  
* Successful Treasury Payment

The subscription shall include:

* Subscription Number (Auto Generated)  
* Player  
* Sport  
* Program  
* Group  
* Start Date  
* End Date  
* Subscription Type  
* Price  
* Discounts  
* Final Amount  
* Treasury Reference  
* Status

---

# **18.5 Subscription Status**

Available statuses:

* Pending Payment  
* Active  
* Expired  
* Suspended  
* Cancelled  
* Refunded

Status changes shall occur automatically whenever possible.

---

# **18.6 Renewal Process**

Before a subscription expires, the system shall generate renewal reminders.

Default reminders:

* 14 Days Before Expiration  
* 7 Days Before Expiration  
* 3 Days Before Expiration  
* On Expiration Date

Reminder intervals shall be configurable.

Upon payment, the subscription shall automatically extend according to the selected subscription type.

---

# **18.7 Expired Subscriptions**

When a subscription expires:

The player shall:

* Remain in historical records.  
* Be removed from future attendance lists.  
* Be excluded from new Mirror sessions.  
* Be prevented from participating in future training sessions.

Historical attendance and payment information shall remain unchanged.

---

# **18.8 Subscription Suspension**

Authorized users may temporarily suspend a subscription.

Examples:

* Medical Injury  
* Long-Term Travel  
* Administrative Decision

During suspension:

* Attendance shall not be expected.  
* Future sessions shall be blocked.  
* Subscription time shall not automatically pause unless enabled in the system settings.

The club administrator may choose whether suspension pauses the subscription duration or allows it to continue counting.

**Added to make the idea better.**

---

# **18.9 Subscription Cancellation**

A subscription may be cancelled before or after activation.

Cancellation reasons may include:

* Player Withdrawal  
* Administrative Error  
* Duplicate Registration  
* Refund Approved

If cancellation occurs after payment, the refund process shall follow the club's financial policy.

---

# **18.10 Subscription Transfer**

If a player changes Groups within the same Program:

The subscription shall remain unchanged.

If the player changes Programs:

The system shall calculate any price difference.

Possible outcomes:

* No Additional Payment  
* Additional Payment Required  
* Credit Balance  
* Refund

The system shall automatically create the required Treasury transactions.

**Added to make the idea better.**

---

# **18.11 Pricing Calculation**

The subscription amount shall be calculated using:

Program Price

* 

Additional Fees

* 

Discounts

\=

Final Amount

The calculation shall preserve historical pricing.

Price changes made to Programs shall affect future subscriptions only.

---

# **18.12 Discounts**

The system shall support:

* Fixed Amount Discounts  
* Percentage Discounts  
* Membership Discounts  
* Promotional Discounts  
* Manual Discounts (Authorized Users Only)

Every applied discount shall be recorded with:

* Discount Type  
* Discount Value  
* User  
* Approval (if required)

---

# **18.13 Subscription History**

Every player shall maintain a complete subscription history.

Displayed information:

* Subscription Number  
* Sport  
* Program  
* Group  
* Start Date  
* End Date  
* Amount Paid  
* Payment Date  
* Treasury Reference  
* Status

Historical subscriptions shall never be modified after completion.

---

# **18.14 Search & Filters**

Search:

* Player Name  
* Subscription Number  
* Membership Number

Filters:

* Active  
* Expired  
* Pending Payment  
* Suspended  
* Cancelled  
* Refunded  
* Sport  
* Program

Sorting:

* Expiration Date  
* Renewal Date  
* Player Name

---

# **18.15 Business Rules**

* One active subscription shall exist for each active Program enrollment.  
* A subscription shall only become Active after successful payment.  
* Expired subscriptions shall automatically restrict attendance.  
* Historical subscriptions shall never be deleted.  
* Subscription renewals shall preserve historical pricing information.  
* Transfers between Programs shall recalculate pricing when necessary.

---

# **18.16 Notifications**

The system shall notify users when:

* A subscription is created.  
* Payment is pending.  
* Renewal is approaching.  
* A subscription expires.  
* A subscription is suspended.  
* A subscription is cancelled.  
* A refund is completed.

---

# **18.17 Permissions**

Reception Employees may:

* View subscriptions.  
* Create renewal requests.

Sports Employees may:

* View subscription status.

Treasury Employees may:

* Process payments.  
* Process refunds.

Sports Managers may:

* Suspend subscriptions.  
* Cancel subscriptions.  
* Approve manual discounts.

System Administrators shall have unrestricted access.

---

# **18.18 Audit Log**

Every subscription operation shall be recorded.

The Audit Log shall include:

* Operation Type  
* User  
* Date and Time  
* Previous Status  
* New Status  
* Treasury Reference  
* Reason

---

# **Chapter 19 — Treasury Integration**

## **19.1 Introduction**

The Sports Activity Module shall be fully integrated with the ERP Treasury Module. The Sports Module shall never process payments directly. Instead, it shall generate financial transactions that are automatically sent to the Treasury Module for payment processing.

Once the Treasury confirms payment, the Sports Module shall automatically update the corresponding records without requiring manual intervention.

This integration ensures a single financial source of truth across the ERP.

---

# **19.2 Treasury Integration Points**

The following operations shall automatically generate Treasury transactions:

### **Player Program Assignment**

Creates the initial subscription payment.

---

### **Subscription Renewal**

Creates the renewal payment.

---

### **Recreational Booking**

Creates a booking payment request.

---

### **Institution Booking**

Creates an institution reservation payment request.

---

### **Program Transfer**

Creates additional payment or refund transactions if pricing changes.

---

### **Manual Charges**

Examples:

* Uniform Fees  
* Equipment Fees  
* Registration Fees  
* Tournament Fees

**Added to make the idea better.**

---

### **Refunds**

Approved refunds shall automatically generate Treasury refund requests.

---

# **19.3 Transaction Workflow**

Sports Module

↓

Treasury Transaction Created

↓

Treasury Review

↓

Payment Completed

↓

Sports Module Updated

or

Payment Cancelled

↓

Sports Module Updated

All synchronization shall occur automatically.

---

# **19.4 Transaction Information**

Each Treasury transaction shall include:

* Transaction Number  
* Player  
* Membership Number (if applicable)  
* Sport  
* Program  
* Group  
* Transaction Type  
* Amount  
* Discounts  
* Taxes  
* Final Amount  
* Due Date  
* Created By  
* Creation Date

---

# **19.5 Transaction Status**

Supported statuses:

* Pending  
* Paid  
* Partially Paid (if supported by Treasury)  
* Cancelled  
* Refunded  
* Failed

Status updates shall synchronize automatically with the Sports Module.

---

# **19.6 Payment Confirmation**

After payment confirmation:

The Sports Module shall automatically:

* Activate the subscription.  
* Update player status.  
* Enable attendance.  
* Enable Mirror participation.  
* Update reports.  
* Update dashboards.

No manual approval shall be required.

---

# **19.7 Failed Payments**

If payment fails:

The transaction shall remain pending until:

* Successfully paid.  
* Cancelled.  
* Expired.

The player shall remain in the **Awaiting Payment** status.

---

# **19.8 Partial Payments**

If the Treasury Module supports partial payments, the Sports Module shall respect the configured policy.

Possible policies:

* Do not activate until full payment is received.  
* Activate after reaching a configurable payment percentage.  
* Activate manually after manager approval.

The selected policy shall be configurable through the system settings.

**Added to make the idea better.**

---

# **19.9 Refund Management**

When a refund is approved:

The system shall:

* Create a Treasury refund transaction.  
* Update the subscription status.  
* Update player status if necessary.  
* Preserve the original payment history.

Refund reasons shall be mandatory.

---

# **19.10 Financial History**

Every player profile shall display all Treasury transactions related to Sports.

Displayed information:

* Transaction Number  
* Transaction Type  
* Amount  
* Payment Date  
* Status  
* Receipt Number (received from the Treasury Module)  
* Payment Method (Cash, Card, Online, etc., if provided by the Treasury Module)

---

# **19.11 Search & Filters**

Search:

* Transaction Number  
* Player Name  
* Membership Number

Filters:

* Pending  
* Paid  
* Cancelled  
* Refunded  
* Failed

Sorting:

* Date  
* Amount  
* Status

---

# **19.12 Business Rules**

* Every financial operation shall generate a Treasury transaction.  
* The Sports Module shall not store independent payment records.  
* Treasury shall remain the financial authority.  
* Status synchronization shall occur automatically.  
* Financial history shall remain immutable after completion.  
* Failed payments shall not activate subscriptions.

---

# **19.13 Notifications**

The system shall notify users when:

* A Treasury transaction is created.  
* A payment is completed.  
* A payment fails.  
* A refund is approved.  
* A transaction is cancelled.  
* A transaction remains pending beyond a configurable period.

---

# **19.14 Permissions**

Reception Employees may:

* View transaction status.

Sports Employees may:

* Create financial requests.

Treasury Employees may:

* Process payments.  
* Process refunds.  
* Cancel financial transactions.

Sports Managers may:

* View all financial records.  
* Request refunds.

System Administrators shall have unrestricted access.

---

# **19.15 Audit Log**

Every Treasury integration event shall be recorded.

The Audit Log shall include:

* Operation Type.  
* User.  
* Date and Time.  
* Transaction Number.  
* Previous Status.  
* New Status.  
* Related Player.  
* Related Subscription.  
* Reason (if applicable).

# **Chapter 20 — Discounts & Pricing Management**

## **20.1 Introduction**

The Discounts & Pricing Management module is responsible for managing all pricing rules used within the Sports Activity Module. It defines how subscription prices, registration fees, recreational bookings, institution bookings, and other sports-related services are calculated.

The module shall support centralized pricing management while allowing each Sport, Program, or Booking to define its own pricing when necessary.

Pricing rules shall integrate directly with the Treasury Module and every calculated amount shall remain historically preserved after payment.

---

# **20.2 Pricing Sources**

Pricing may originate from one of the following levels:

### **Sport Default Price**

The default pricing configured when creating a Sport.

Example:

Swimming

Member: 600 EGP

Non-Member: 850 EGP

These prices act as fallback values.

---

### **Program Price**

Programs may override the Sport's pricing.

Example:

Swimming → Elite Program

Member: 800 EGP

Non-Member: 1,100 EGP

Program pricing shall always take precedence over Sport pricing.

---

### **Recreational Sport Pricing**

Recreational Sports shall define pricing based on:

* Per Hour  
* Per Game

Separate pricing shall be maintained for:

* Members  
* Non-Members

---

### **Institution Booking Pricing**

Institution bookings shall use custom pricing entered during booking creation.

These prices shall not affect the default pricing configuration.

---

### **Manual Pricing**

Authorized users may manually override the calculated amount.

Every manual override shall require:

* Reason  
* User  
* Approval (if configured)

**Added to make the idea better.**

---

# **20.3 Discount Types**

The system shall support multiple discount types.

### **Percentage Discount**

Example:

10%

20%

50%

The discount shall be applied to the calculated amount before additional fees unless configured otherwise.

---

### **Fixed Amount Discount**

Example:

100 EGP

250 EGP

500 EGP

---

### **Membership Discount**

Automatically applied according to the player's membership status.

---

### **Promotional Discount**

Temporary discounts valid between configured dates.

Example:

Summer Promotion

01 June → 31 August

---

### **Coupon / Promo Code**

The system may optionally support promotional codes.

Each coupon may define:

* Code  
* Expiration Date  
* Maximum Usage Count  
* Discount Type  
* Discount Value

**Added to make the idea better.**

---

### **Scholarship Discount**

Clubs may provide long-term discounts for selected players.

Examples:

* Outstanding Athlete  
* National Team Player  
* Employee Child  
* Social Support

Scholarship validity shall be configurable.

**Added to make the idea better.**

---

# **20.4 Discount Priority**

When multiple discounts are applicable, the system shall apply them according to a configurable priority.

Example:

1. Membership Discount  
2. Promotional Discount  
3. Scholarship Discount  
4. Manual Discount

Only authorized users may change the priority configuration.

**Added to make the idea better.**

---

# **20.5 Discount Validation**

Before applying any discount, the system shall validate:

* Discount validity period.  
* Player eligibility.  
* Maximum usage limits.  
* User permissions.  
* Discount status.

Expired or inactive discounts shall not be applied.

---

# **20.6 Additional Fees**

The system shall support additional fees that are added after price calculation.

Examples:

* Registration Fee  
* Uniform Fee  
* Equipment Fee  
* Tournament Registration Fee  
* Insurance Fee

Each fee may be:

* Mandatory  
* Optional

Optional fees may be selected during the transaction.

**Added to make the idea better.**

---

# **20.7 Price Calculation**

The calculation sequence shall be:

Base Price

↓

Applicable Discounts

↓

Additional Fees

↓

Taxes (if applicable)

↓

Final Amount

The system shall display every calculation step to the user before confirming the transaction.

---

# **20.8 Price Preview**

Before creating the Treasury transaction, the system shall display a detailed pricing summary.

The summary shall include:

* Base Price  
* Applied Discounts  
* Additional Fees  
* Taxes  
* Final Amount

Users shall be able to expand each section to view detailed calculations.

**Added to make the idea better.**

---

# **20.9 Historical Pricing**

Historical pricing shall never change.

If the club updates Program prices later, previous subscriptions shall retain:

* Original Price  
* Original Discounts  
* Original Fees  
* Final Paid Amount

This rule guarantees accurate financial reporting.

---

# **20.10 Search & Filters**

Users shall search pricing records using:

* Sport  
* Program  
* Discount Name  
* Fee Name

Filters:

* Active  
* Expired  
* Scheduled  
* Promotional  
* Scholarship  
* Membership

Sorting:

* Name  
* Creation Date  
* Expiration Date

---

# **20.11 Business Rules**

* Program pricing overrides Sport pricing.  
* Discounts shall be validated before application.  
* Historical pricing shall remain unchanged.  
* Manual discounts shall require appropriate permissions.  
* Manual price overrides shall require a mandatory reason.  
* Every applied discount shall be included in the Treasury transaction.

---

# **20.12 Notifications**

The system shall notify users when:

* A promotional discount begins.  
* A promotional discount expires.  
* A manual price override is requested.  
* A discount reaches its expiration date.  
* A pricing configuration is modified.

---

# **20.13 Permissions**

Reception Employees may:

* View pricing.

Sports Employees may:

* View pricing.  
* Apply standard discounts.

Sports Managers may:

* Create discounts.  
* Edit pricing.  
* Apply manual discounts.  
* Override pricing.

System Administrators shall have unrestricted access.

---

# **20.14 Audit Log**

Every pricing operation shall be recorded.

The Audit Log shall include:

* Operation Type  
* User  
* Date and Time  
* Previous Values  
* New Values  
* Approval Details (if applicable)  
* Reason

---

# **Chapter 21 — Recreational Sports Management**

## **21.1 Introduction**

Unlike Training Sports, Recreational Sports are reservation-based activities where customers book a Facility for a specific period or game rather than enrolling in Programs and Groups.

Examples include:

* Bowling  
* Padel  
* Football Field Rental  
* Squash  
* Billiards  
* Table Tennis

Recreational Sports shall have independent workflows while still sharing Facilities, Mirrors, Treasury integration, and reporting with the rest of the Sports Activity Module.

---

# **21.2 Recreational Sport Configuration**

When creating a Recreational Sport, the following information shall be configured:

* Sport Name  
* Status  
* Pricing Method  
* Member Price  
* Non-Member Price  
* Default Booking Duration (Optional)  
* Booking Interval  
* Cancellation Policy (Optional)

The Booking Interval defines the minimum reservation unit.

Examples:

* 30 Minutes  
* 60 Minutes  
* 90 Minutes

**Added to make the idea better.**

---

# **21.3 Pricing Methods**

The system shall support two pricing methods.

### **Per Hour**

The total price shall be calculated based on:

Reserved Hours × Hourly Rate

---

### **Per Game**

The customer pays one fixed amount regardless of duration.

Example:

Bowling

120 EGP per game

---

# **21.4 Booking Workflow**

The recreational booking process shall follow the workflow below:

Customer Selection

↓

Sport Selection

↓

Facility Selection

↓

Mirror Reservation

↓

Treasury Transaction Created

↓

Booking Confirmed

↓

Customer Plays

↓

Payment Completed

The system shall allow clubs to choose whether payment is required before play or after play through a configurable system setting.

This accommodates clubs with different operational policies.

**Added to make the idea better.**

---

# **21.5 Customer Registration**

Bookings may be created for:

* Club Members  
* Non-Members  
* Institutions

Required information:

Members:

* Membership Number

Non-Members:

* Name  
* Mobile Number

Institutions:

* Institution Name  
* Contact Person

---

# **21.6 Booking Creation**

During booking creation, users shall select:

* Sport  
* Facility  
* Date  
* Time  
* Duration (Hourly Sports)  
* Number of Games (Per Game Sports, if applicable)  
* Reserved Area (Mirror)  
* Customer

The system shall automatically calculate the total price.

---

# **21.7 Mirror Integration**

Every recreational booking shall occupy the selected area in the Mirror.

The system shall prevent overlapping reservations.

Training sessions, maintenance, and institution bookings shall all participate in the same conflict validation process.

---

# **21.8 Booking Status**

Available statuses:

* Pending Payment  
* Confirmed  
* In Progress  
* Completed  
* Cancelled  
* Expired  
* Refunded

Status transitions may occur automatically based on payment confirmation and scheduled booking times.

**Added to make the idea better.**

---

# **21.9 Booking Modification**

Authorized users may modify:

* Date  
* Time  
* Facility  
* Duration  
* Reserved Area

The system shall immediately validate:

* Mirror conflicts  
* Facility availability  
* Pricing changes

If pricing changes, a new Treasury adjustment transaction shall be generated automatically.

---

# **21.10 Booking Cancellation**

Bookings may be cancelled according to the configured cancellation policy.

Possible outcomes:

* Full Refund  
* Partial Refund  
* No Refund

The applicable policy shall determine the generated Treasury transaction.

**Added to make the idea better.**

---

# **21.11 Booking History**

The system shall maintain a complete booking history.

Displayed information:

* Booking Number  
* Customer  
* Sport  
* Facility  
* Date  
* Duration  
* Amount  
* Payment Status  
* Booking Status

Historical bookings shall never be deleted.

---

# **21.12 Search & Filters**

Search:

* Booking Number  
* Customer Name  
* Membership Number  
* Institution Name

Filters:

* Pending Payment  
* Confirmed  
* Completed  
* Cancelled  
* Expired  
* Refunded  
* Sport  
* Facility

Sorting:

* Booking Date  
* Booking Time  
* Customer Name

---

# **21.13 Business Rules**

* Recreational Sports shall not contain Programs or Groups.  
* Every booking shall reserve space in the Mirror.  
* Overlapping bookings shall not be permitted.  
* Pricing shall follow the configured pricing method.  
* Historical bookings shall remain immutable after completion.  
* Booking modifications affecting pricing shall automatically synchronize with the Treasury Module.

---

# **21.14 Notifications**

The system shall notify users when:

* A booking is created.  
* A booking is modified.  
* A booking is cancelled.  
* Payment is completed.  
* A booking is about to begin.  
* A booking expires without payment (if applicable).

---

# **21.15 Permissions**

Reception Employees may:

* Create bookings.  
* Edit bookings before confirmation.  
* View booking history.

Sports Employees may:

* Manage facility schedules.  
* View bookings.

Sports Managers may:

* Override booking conflicts (where permitted).  
* Approve cancellations.  
* Approve refunds.

Treasury Employees may:

* Process payments.  
* Process refunds.

System Administrators shall have unrestricted access.

---

# **21.16 Audit Log**

Every booking operation shall be recorded.

The Audit Log shall include:

* Operation Type.  
* User.  
* Date and Time.  
* Booking Number.  
* Previous Values.  
* New Values.  
* Treasury Reference.  
* Reason (if applicable).

**Chapter 22 — Mirror Management (Facility Scheduling & Grid System)**

## **22.1 Introduction**

The Mirror Management module is the core scheduling system of the Sports Activity Module. It provides a visual representation of every sports facility using a configurable grid, allowing users to assign training groups, recreational bookings, institution reservations, maintenance activities, and blocked areas to specific locations within a facility.

Every facility shall have its own independent Mirror, and all scheduling shall occur through this module. The Mirror shall prevent conflicts, optimize facility utilization, and provide a real-time overview of facility occupancy.

---

# **22.2 Mirror Structure**

Each facility shall have a configurable grid created during facility registration.

The administrator shall define:

* Number of Rows  
* Number of Columns

Example:

* 10 × 10 Grid  
* 20 × 8 Grid  
* 50 × 10 Grid

Each cell represents a physical area within the facility.

The grid dimensions cannot be modified after scheduling begins unless the facility has no active schedules.

**Added to make the idea better.**

---

# **22.3 Mirror Views**

The system shall provide multiple viewing modes.

### **Daily View**

Displays all assignments for one day.

---

### **Weekly View**

Displays the entire week's schedule.

---

### **Monthly View**

Displays all scheduled activities during the selected month.

---

### **Timeline View**

Displays the day's schedule as hourly blocks.

---

### **Grid View**

Displays the graphical layout of the facility with colored occupied areas.

Users may switch freely between views.

**Added to make the idea better.**

---

# **22.4 Working Hours**

Each facility shall define its operating hours.

Example:

Sunday

08:00 AM → 10:00 PM

Monday

06:00 AM → 11:00 PM

The Mirror shall prevent scheduling outside these working hours unless overridden by an authorized user.

---

# **22.5 Assignment Types**

The Mirror shall support the following assignment types:

* Training Group  
* Recreational Booking  
* Institution Booking  
* Maintenance  
* Free Practice  
* Club Event  
* Tournament  
* Reserved Area

The assignment type shall determine the displayed color and available actions.

**Added to make the idea better.**

---

# **22.6 Creating an Assignment**

When creating a new assignment, the user shall select:

* Assignment Type  
* Date  
* Start Time  
* End Time  
* Facility  
* Grid Area  
* Related Entity

Examples of related entities:

* Group  
* Institution  
* Booking  
* Maintenance Request

The system shall validate all information before saving.

---

# **22.7 Grid Selection**

The grid shall support multiple selection methods.

### **Individual Cells**

Users may click individual cells.

---

### **Drag Selection**

Users may drag across multiple cells.

---

### **Row Selection**

Clicking a row header selects the entire row.

---

### **Column Selection**

Clicking a column header selects the entire column.

---

### **Rectangle Selection**

Users may drag to create rectangular selections.

**Added to make the idea better.**

---

### **Multi-Area Selection**

Users may hold a modifier key (such as Ctrl) to select multiple independent areas in one assignment.

**Added to make the idea better.**

---

# **22.8 Color Coding**

Each assignment type shall use a different color.

Example:

* Training Groups  
* Recreational Bookings  
* Institution Bookings  
* Maintenance  
* Club Events  
* Free Areas

The exact colors shall be configurable through system settings.

**Added to make the idea better.**

---

# **22.9 Training Group Assignment**

When assigning a Training Group:

The system shall display:

* Sport Filter  
* Program Filter  
* Group Search  
* Group List

Each Group shall display:

* Program  
* Trainer  
* Number of Players  
* Session Time  
* Current Schedule

After selecting the Group, the assignment shall appear immediately on the Mirror.

---

# **22.10 Recreational Booking Assignment**

Recreational bookings shall automatically reserve their selected grid area after confirmation.

If a booking is cancelled, the reserved cells shall immediately become available.

---

# **22.11 Institution Assignment**

Users may reserve all or part of a facility for institutions.

Required information:

* Institution Name  
* Contact Person  
* Booking Date  
* Time  
* Reserved Area  
* Custom Price  
* Notes

The booking shall automatically generate a Treasury transaction.

Its status shall synchronize with the Booking Module.

---

# **22.12 Maintenance Assignment**

Maintenance assignments may occupy:

* Entire Facility  
* Selected Areas

The user shall specify:

* Maintenance Type  
* Description  
* Start Date  
* End Date  
* Responsible Department

During maintenance, affected cells shall not be available for any other assignment.

---

# **22.13 Conflict Detection**

Before saving any assignment, the system shall validate:

* Date conflicts  
* Time conflicts  
* Grid conflicts  
* Facility conflicts  
* Trainer conflicts  
* Group conflicts

If any conflict exists, the assignment shall not be saved unless overridden by an authorized user.

---

# **22.14 Copy Schedule**

Users may copy schedules between periods.

Supported copy operations:

* Day → Day  
* Week → Week  
* Month → Month

During copying, users may choose:

* Copy only Training Groups.  
* Copy only Bookings.  
* Copy all Assignments.

After copying, all conflicts shall be revalidated before saving.

---

# **22.15 Recurring Assignments**

The Mirror shall support recurring schedules.

Examples:

* Every Sunday  
* Every Monday and Wednesday  
* Every Day  
* Every Two Weeks  
* Monthly

The recurrence shall define:

* Start Date  
* End Date  
* Frequency

Individual occurrences may later be modified without affecting the remaining schedule.

**Added to make the idea better.**

---

# **22.16 Mirror Statistics**

The Mirror Dashboard shall display:

* Facility Utilization Percentage  
* Total Bookings  
* Total Training Sessions  
* Maintenance Hours  
* Free Hours  
* Peak Usage Times

Statistics shall be available for:

* Daily  
* Weekly  
* Monthly  
* Yearly

---

# **22.17 Search & Filters**

Search:

* Facility  
* Group  
* Program  
* Trainer  
* Institution

Filters:

* Assignment Type  
* Date  
* Sport  
* Facility  
* Trainer

Sorting:

* Time  
* Facility  
* Assignment Type

---

# **22.18 Business Rules**

* Every facility shall have its own Mirror.  
* Grid conflicts shall never be allowed unless explicitly overridden.  
* Assignments shall respect facility working hours.  
* Cancelled bookings shall immediately release reserved cells.  
* Maintenance assignments shall block affected areas.  
* All copied schedules shall undergo conflict validation before being saved.  
* Historical schedules shall never be deleted.

---

# **22.19 Notifications**

The system shall notify users when:

* A scheduling conflict occurs.  
* A copied schedule fails validation.  
* Maintenance begins.  
* A facility reaches full utilization.  
* A recurring assignment ends.  
* An institution booking is approved or cancelled.

---

# **22.20 Permissions**

Sports Employees may:

* View Mirrors.  
* Create assignments.  
* Modify assignments.

Sports Managers may:

* Override scheduling conflicts.  
* Create recurring schedules.  
* Copy schedules.  
* Delete future assignments.

System Administrators shall have unrestricted access.

---

# **22.21 Audit Log**

Every Mirror operation shall be recorded.

The Audit Log shall include:

* Operation Type  
* User  
* Date and Time  
* Facility  
* Assignment Type  
* Previous Values  
* New Values  
* Reason (if applicable)

---

# **Chapter 23 — Institution Bookings**

## **23.1 Introduction**

The Institution Bookings module allows external organizations, schools, companies, universities, sports clubs, federations, and other entities to reserve sports facilities for private use.

Institution bookings differ from recreational bookings because they are typically larger, may occupy multiple facilities or large areas of a facility, and usually involve custom pricing negotiated by the club.

Institution bookings shall integrate directly with the Mirror Management and Treasury modules.

---

# **23.2 Institution Registration**

Before creating a booking, the institution shall be registered.

Required information:

### **Basic Information**

* Institution Code (Generated Automatically)  
* Institution Name  
* Institution Type

Examples:

* School  
* University  
* Company  
* Sports Club  
* Government Organization  
* Private Organization

---

### **Contact Information**

* Contact Person  
* Mobile Number  
* Alternative Number  
* Email Address  
* Address

---

### **Documents**

Optional uploads:

* Contract  
* Commercial Registration  
* Tax Card  
* Other Documents

---

# **23.3 Institution Profile**

Each institution shall have its own profile displaying:

* Institution Information  
* Contact Details  
* Booking History  
* Active Reservations  
* Financial Transactions  
* Documents  
* Activity Timeline

---

# **23.4 Booking Workflow**

Institution Selected

↓

Facility Selected

↓

Mirror Area Selected

↓

Custom Price Entered

↓

Treasury Transaction Created

↓

Payment Confirmed

↓

Booking Activated

↓

Facility Reserved

The club may configure whether payment is required before the booking starts or after the booking ends.

**Added to make the idea better.**

---

# **23.5 Booking Details**

Each booking shall include:

* Booking Number  
* Institution  
* Facility  
* Reserved Grid Area  
* Date  
* Start Time  
* End Time  
* Duration  
* Booking Purpose  
* Number of Participants (Optional)  
* Notes

---

# **23.6 Pricing**

Institution bookings shall always allow custom pricing.

Pricing may include:

* Facility Rental Fee  
* Additional Equipment  
* Staff Charges  
* Cleaning Fees  
* Security Fees  
* Discounts

The system shall calculate the final amount and send it to the Treasury Module.

---

# **23.7 Multiple Facility Booking**

The system shall allow one institution booking to reserve:

* One Facility  
* Multiple Facilities  
* Multiple Areas within different facilities

All selected facilities shall be validated for scheduling conflicts before confirmation.

**Added to make the idea better.**

---

# **23.8 Booking Status**

Available statuses:

* Draft  
* Awaiting Payment  
* Confirmed  
* In Progress  
* Completed  
* Cancelled  
* Refunded

Status changes shall synchronize automatically with the Treasury Module where applicable.

---

# **23.9 Booking Modification**

Authorized users may modify:

* Facility  
* Reserved Area  
* Date  
* Time  
* Pricing  
* Notes

Any pricing changes shall automatically create the necessary Treasury adjustment transaction.

---

# **23.10 Booking Cancellation**

When cancelling an institution booking, the system shall:

* Release the reserved Mirror area.  
* Update the booking status.  
* Generate refund transactions if applicable.  
* Preserve the booking history.

---

# **23.11 Search & Filters**

Search:

* Institution Name  
* Institution Code  
* Booking Number  
* Contact Person

Filters:

* Active  
* Awaiting Payment  
* Completed  
* Cancelled  
* Refunded  
* Facility

Sorting:

* Booking Date  
* Institution Name  
* Booking Status

---

# **23.12 Business Rules**

* Institution bookings may reserve one or more facilities.  
* Every booking shall reserve space within the Mirror.  
* Conflicting reservations shall not be permitted.  
* Pricing shall always be customizable.  
* Historical bookings shall remain permanently available.  
* Treasury integration shall be mandatory for every institution booking.

---

# **23.13 Notifications**

The system shall notify users when:

* A new institution booking is created.  
* Payment is received.  
* A booking is modified.  
* A booking is cancelled.  
* A booking is approaching its scheduled date.  
* A booking expires without payment.

---

# **23.14 Permissions**

Reception Employees may:

* View institution bookings.

Sports Employees may:

* Create and edit institution bookings.

Sports Managers may:

* Approve bookings.  
* Override scheduling conflicts.  
* Cancel bookings.

Treasury Employees may:

* Process payments.  
* Process refunds.

System Administrators shall have unrestricted access.

---

# **23.15 Audit Log**

Every institution booking operation shall be recorded.

The Audit Log shall include:

* Operation Type  
* User  
* Date and Time  
* Institution  
* Booking Number  
* Previous Values  
* New Values  
* Treasury Reference  
* Reason (if applicable)

**Chapter 24 — Reports & Analytics**

## **24.1 Introduction**

The Reports & Analytics module provides management with comprehensive operational, financial, and statistical insights into the Sports Activity Module. All reports shall support filtering, grouping, exporting, and printing, enabling users to analyze performance across players, trainers, programs, facilities, and finances.

Reports shall always retrieve live data from the system unless the user explicitly requests historical snapshots.

---

# **24.2 General Report Features**

Every report in the Sports Activity Module shall support the following capabilities:

* Search  
* Advanced Filters  
* Grouping  
* Sorting  
* Export to PDF  
* Export to Excel  
* Printing  
* Saved Report Templates  
* Favorite Reports

Users shall be able to save frequently used filter combinations for future use.

**Added to make the idea better.**

---

# **24.3 Dashboard Analytics**

The Sports Dashboard shall display real-time statistics including:

### **Financial Statistics**

* Today's Revenue  
* This Week's Revenue  
* This Month's Revenue  
* This Year's Revenue  
* Revenue Between Two Dates  
* Pending Payments  
* Outstanding Balances  
* Refund Totals

---

### **Player Statistics**

* Total Registered Players  
* Active Players  
* Inactive Players  
* Suspended Players  
* Potential Players  
* New Players This Month  
* Players by Age Group  
* Players by Gender  
* Players by Membership Type

---

### **Program Statistics**

* Total Sports  
* Total Programs  
* Total Groups  
* Average Group Capacity  
* Full Groups  
* Groups Near Capacity

---

### **Trainer Statistics**

* Total Trainers  
* Active Trainers  
* Trainers by Academy  
* Average Number of Players per Trainer  
* Weekly Coaching Hours

---

### **Facility Statistics**

* Facility Utilization Rate  
* Most Used Facilities  
* Least Used Facilities  
* Maintenance Hours  
* Free Hours

---

### **Recreational Statistics**

* Recreational Bookings Today  
* Active Bookings  
* Completed Bookings  
* Cancelled Bookings  
* Most Popular Recreational Sports

---

### **Medical Statistics**

* Pending Medical Reviews  
* Approved Certificates  
* Rejected Certificates  
* Expired Certificates  
* Certificates Expiring Soon

---

### **Attendance Statistics**

* Attendance Today  
* Weekly Attendance Rate  
* Monthly Attendance Rate  
* Lowest Attendance Groups  
* Highest Attendance Groups

---

# **24.4 Player Reports**

Available reports:

* Player List  
* Active Players  
* Inactive Players  
* Potential Players  
* Players by Sport  
* Players by Program  
* Players by Group  
* Players by Trainer  
* Players by Membership Status  
* Players by Age Group  
* Players with Expired Medical Certificates  
* Players in Medical Grace Period

---

# **24.5 Attendance Reports**

Reports shall include:

* Daily Attendance  
* Weekly Attendance  
* Monthly Attendance  
* Attendance by Player  
* Attendance by Trainer  
* Attendance by Program  
* Attendance by Group  
* Attendance by Sport  
* Attendance Exceptions  
* Consecutive Absence Report

---

# **24.6 Financial Reports**

Reports shall include:

* Subscription Revenue  
* Recreational Revenue  
* Institution Booking Revenue  
* Outstanding Payments  
* Refund Report  
* Discounts Applied  
* Revenue by Sport  
* Revenue by Program  
* Revenue by Trainer (Reporting Only)  
* Revenue Between Dates

---

# **24.7 Trainer Reports**

Available reports:

* Trainer Assignments  
* Trainer Schedules  
* Trainer Workload  
* Trainer Attendance Performance  
* Trainer Group Distribution  
* Trainers by Academy

---

# **24.8 Facility Reports**

Reports shall include:

* Facility Utilization  
* Facility Occupancy Timeline  
* Maintenance History  
* Facility Downtime  
* Mirror Usage Statistics  
* Peak Usage Hours

---

# **24.9 Mirror Reports**

Reports shall include:

* Daily Mirror Schedule  
* Weekly Schedule  
* Monthly Schedule  
* Assignment History  
* Scheduling Conflicts  
* Unused Time Slots  
* Recurring Assignment Summary

---

# **24.10 Institution Reports**

Available reports:

* Institution Booking History  
* Active Institution Bookings  
* Institution Revenue  
* Institution Usage by Facility  
* Institution Payment Status

---

# **24.11 Recreational Reports**

Reports shall include:

* Booking History  
* Revenue by Sport  
* Peak Booking Hours  
* Cancellation Report  
* Customer Visit Frequency  
* Facility Usage

---

# **24.12 Medical Reports**

Reports shall include:

* Medical Approvals  
* Medical Rejections  
* Expired Certificates  
* Certificates Expiring Soon  
* Grace Period Report  
* Medical Levels Distribution

---

# **24.13 Academy Reports**

Reports shall include:

* Academy List  
* Trainers per Academy  
* Groups Managed by Academy  
* Players Managed by Academy  
* Academy Activity Summary

---

# **24.14 Custom Reports**

Authorized users shall be able to create custom reports by selecting:

* Data Source  
* Displayed Fields  
* Filters  
* Grouping  
* Sorting  
* Calculated Columns

Custom reports may be saved and shared with other users based on permissions.

**Added to make the idea better.**

---

# **24.15 Scheduled Reports**

The system shall allow automatic generation of reports.

Examples:

* Daily Attendance Report  
* Weekly Revenue Report  
* Monthly Facility Utilization  
* Monthly Medical Expiration Report

Reports may be delivered automatically through the ERP notification system or email if configured.

**Added to make the idea better.**

---

# **24.16 Search & Filters**

All reports shall support:

Search by:

* Player  
* Trainer  
* Program  
* Sport  
* Facility  
* Institution

Filters:

* Date Range  
* Sport  
* Program  
* Group  
* Trainer  
* Academy  
* Facility  
* Status

---

# **24.17 Business Rules**

* Reports shall always reflect the latest available data.  
* Historical reports shall preserve historical values.  
* Deleted records shall continue appearing in historical reports if they existed during the selected reporting period.  
* Exported reports shall preserve applied filters.  
* User permissions shall determine report visibility.

---

# **24.18 Permissions**

Reception Employees may:

* View operational reports.

Sports Employees may:

* View operational reports.  
* Export reports.

Sports Managers may:

* View all reports.  
* Create custom reports.  
* Schedule reports.

System Administrators shall have unrestricted access.

---

# **24.19 Audit Log**

The system shall record:

* Report Generation  
* Export Operations  
* Scheduled Report Creation  
* Custom Report Modifications

Each log entry shall include:

* User  
* Date and Time  
* Report Name  
* Filters Used  
* Export Format (if applicable)

---

# **Chapter 25 — Dashboard & Wizards**

## **25.1 Introduction**

The Dashboard shall be the landing page of the Sports Activity Module. Its purpose is to provide users with a complete overview of the module through real-time statistics, alerts, shortcuts, pending tasks, and quick actions (Wizards).

The Dashboard shall be customizable according to user permissions, ensuring that each employee sees only the information relevant to their role.

---

# **25.2 Dashboard Layout**

The Dashboard shall consist of the following sections:

* KPI Cards  
* Charts  
* Quick Statistics  
* Notifications  
* Pending Tasks  
* Wizards (Quick Actions)  
* Calendar  
* Recent Activity  
* System Alerts

Users may rearrange dashboard widgets according to their preferences.

**Added to make the idea better.**

---

# **25.3 KPI Cards**

The Dashboard shall display configurable KPI cards such as:

### **Financial KPIs**

* Revenue Today  
* Revenue This Month  
* Pending Payments  
* Outstanding Amounts

---

### **Player KPIs**

* Active Players  
* Potential Players  
* New Registrations  
* Expired Subscriptions

---

### **Training KPIs**

* Active Sports  
* Active Programs  
* Active Groups  
* Sessions Today

---

### **Facility KPIs**

* Facilities in Use  
* Facilities Under Maintenance  
* Facility Utilization Rate

---

### **Medical KPIs**

* Pending Reviews  
* Expired Certificates  
* Grace Period Players

---

# **25.4 Charts**

The Dashboard shall include interactive charts such as:

* Monthly Revenue  
* Player Growth  
* Attendance Trend  
* Facility Utilization  
* Recreational Booking Trend  
* Trainer Workload  
* Medical Certificate Status Distribution

Charts shall support filtering by:

* Date Range  
* Sport  
* Program  
* Facility

---

# **25.5 Notifications Panel**

The Dashboard shall display important notifications including:

* Expiring Subscriptions  
* Pending Payments  
* Expired Medical Certificates  
* Groups at Full Capacity  
* Maintenance Starting Today  
* Institution Bookings Today  
* Recreational Bookings Today  
* Trainer Schedule Conflicts

Users may open the related record directly from each notification.

---

# **25.6 Pending Tasks**

The Dashboard shall automatically display outstanding tasks, such as:

* Medical Certificates Waiting for Review  
* Unassigned Potential Players  
* Attendance Not Recorded  
* Bookings Awaiting Confirmation  
* Pending Treasury Transactions  
* Expiring Institution Reservations  
* Pending Refund Requests

---

# **25.7 Wizards (Quick Actions)**

The Dashboard shall provide shortcut buttons for frequently used operations.

The following Wizards shall be available:

### **Player Wizards**

* Register New Player  
* Assign Player to Program  
* Transfer Player Between Groups  
* Renew Subscription  
* Upload Medical Certificate  
* Register Walk-in Recreational Customer **(Added to make the idea better.)**

---

### **Trainer Wizards**

* Register Trainer  
* Assign Trainer to Group  
* Transfer Trainer  
* View Trainer Schedule

---

### **Academy Wizards**

* Register Academy  
* Add Trainer to Academy  
* View Academy Profile

---

### **Sports Wizards**

* Create Sport  
* Create Facility  
* Create Program  
* Create Group

---

### **Mirror Wizards**

* Open Mirror  
* Create Mirror Assignment  
* Copy Monthly Schedule  
* Create Maintenance Assignment  
* Reserve Facility for Institution

---

### **Recreational Wizards**

* Create Booking  
* Check Facility Availability  
* Start Booking  
* Complete Booking  
* Cancel Booking

---

### **Medical Wizards**

* Review Medical Certificates  
* View Expired Certificates  
* View Players in Grace Period

---

### **Treasury Wizards**

* View Pending Payments  
* View Refund Requests  
* Open Treasury Transaction

---

### **Reports Wizards**

* Generate Daily Attendance Report  
* Generate Revenue Report  
* Generate Facility Utilization Report  
* Generate Trainer Performance Report

---

# **25.8 Calendar Widget**

The Dashboard shall include a calendar displaying:

* Training Sessions  
* Recreational Bookings  
* Institution Bookings  
* Maintenance  
* Tournaments  
* Club Events

Selecting any calendar item shall open its corresponding record.

---

# **25.9 Recent Activity**

The Dashboard shall display recent system activity such as:

* Newly Registered Players  
* New Trainers  
* New Bookings  
* Recent Payments  
* Recently Completed Medical Reviews  
* Recent Group Transfers

---

# **25.10 System Alerts**

The Dashboard shall display high-priority alerts, including:

* Facility Overbooking  
* Mirror Scheduling Conflicts  
* Subscription Expirations  
* Medical Certificate Expirations  
* Trainer Scheduling Conflicts  
* Groups Exceeding Capacity  
* Facilities Under Emergency Maintenance

Alerts shall remain visible until resolved or acknowledged.

---

# **25.11 Personal Dashboard**

Each user shall have a personalized dashboard based on their role.

Examples:

Reception:

* New Registrations  
* Pending Payments  
* New Bookings

Trainer:

* Today's Groups  
* Attendance Pending  
* Upcoming Sessions

Medical Staff:

* Pending Reviews  
* Expiring Certificates

Treasury:

* Pending Transactions  
* Refund Requests

Sports Manager:

* Operational Statistics  
* Alerts  
* Financial Summary  
* Facility Utilization

**Added to make the idea better.**

---

# **25.12 Business Rules**

* Dashboard data shall update in real time or at configurable refresh intervals.  
* Dashboard widgets shall respect user permissions.  
* Wizards shall only display operations the current user is authorized to perform.  
* KPI calculations shall always use live operational data.  
* Alerts shall automatically disappear when the underlying issue is resolved.

---

# **25.13 Permissions**

Every dashboard component shall respect role-based access control.

Users shall only see:

* Statistics they are authorized to access.  
* Wizards they are authorized to execute.  
* Reports they are authorized to generate.  
* Notifications related to their responsibilities.

---

# **25.14 Audit Log**

The system shall record significant dashboard actions, including:

* Wizard executions.  
* Report generation from dashboard shortcuts.  
* Alert acknowledgments.  
* Manual dashboard layout changes.

Each log entry shall include:

* User  
* Date and Time  
* Action Performed  
* Related Record (if applicable)

**Chapter 26 — Notifications & Communication**

## **26.1 Introduction**

The Notifications & Communication module is responsible for delivering system alerts, reminders, operational messages, and announcements to employees, trainers, players, parents/guardians, academies, and institutions.

The notification engine shall be event-driven, automatically generating notifications based on actions performed throughout the Sports Activity Module.

This module shall integrate with the ERP Notification Center and may optionally integrate with external communication channels such as SMS, Email, WhatsApp, or Mobile Push Notifications if those services are enabled.

**Added to make the idea better.**

---

# **26.2 Notification Types**

The system shall support the following notification categories:

### **Informational**

General informational messages.

Example:

* Registration Completed  
* Trainer Assigned  
* Program Created

---

### **Reminder**

Time-based reminders.

Examples:

* Subscription Expiration  
* Medical Certificate Expiration  
* Upcoming Booking  
* Attendance Not Recorded

---

### **Warning**

Operational warnings requiring attention.

Examples:

* Group Near Capacity  
* Low Attendance  
* Trainer Schedule Conflict

---

### **Critical Alert**

High-priority operational alerts.

Examples:

* Facility Double Booking  
* Mirror Conflict  
* Medical Certificate Expired  
* Failed Treasury Synchronization

---

# **26.3 Notification Recipients**

Notifications may be sent to:

* Reception Employees  
* Trainers  
* Medical Staff  
* Treasury Employees  
* Sports Managers  
* System Administrators  
* Players  
* Parents/Guardians  
* Academies  
* Institutions

Recipients shall be determined automatically according to the event type.

---

# **26.4 Notification Channels**

The system shall support multiple delivery channels.

Internal ERP Notification Center (Mandatory)

Optional channels:

* Email  
* SMS  
* WhatsApp  
* Mobile Push Notifications

Channel availability shall depend on the club's configured integrations.

**Added to make the idea better.**

---

# **26.5 Notification Center**

Every user shall have access to a Notification Center displaying:

* Unread Notifications  
* Read Notifications  
* Archived Notifications

Each notification shall display:

* Title  
* Description  
* Priority  
* Date & Time  
* Related Record  
* Action Button (if applicable)

Example:

"Player Ahmed Mohamed's subscription expires in 7 days."

↓

Open Player Profile

---

# **26.6 Automatic Notifications**

The system shall automatically generate notifications for events including:

### **Registration**

* New Player Registered  
* New Trainer Registered  
* New Academy Registered

---

### **Assignment**

* Player Assigned  
* Trainer Assigned  
* Group Changed

---

### **Medical**

* Certificate Submitted  
* Certificate Approved  
* Certificate Rejected  
* Certificate Expiring  
* Grace Period Ending

---

### **Attendance**

* Attendance Not Recorded  
* Low Attendance  
* Consecutive Absences  
* Make-up Session Eligible

---

### **Financial**

* Payment Pending  
* Payment Completed  
* Refund Approved  
* Subscription Renewal Due

---

### **Mirror**

* Scheduling Conflict  
* Facility Maintenance  
* Booking Conflict

---

### **Recreational**

* Booking Confirmed  
* Booking Cancelled  
* Booking Reminder

---

### **Institution**

* Reservation Confirmed  
* Reservation Expiring

---

# **26.7 Manual Notifications**

Authorized users may create manual notifications.

Users shall specify:

* Title  
* Message  
* Recipients  
* Priority  
* Delivery Channel  
* Expiration Date (Optional)

Manual notifications may be scheduled for future delivery.

**Added to make the idea better.**

---

# **26.8 Bulk Notifications**

The system shall support sending notifications to groups of recipients.

Examples:

* All Swimming Players  
* All Trainers  
* All Parents  
* Players in a Specific Program  
* Members with Expiring Subscriptions

Filters shall determine the final recipient list.

---

# **26.9 Notification Preferences**

Users may configure personal notification preferences.

Examples:

Receive:

* Email  
* Push Notification  
* Internal Notification

Mute:

* Informational Messages  
* Promotional Messages

Critical alerts shall always be delivered regardless of user preferences.

**Added to make the idea better.**

---

# **26.10 Search & Filters**

Search:

* Notification Title  
* Recipient  
* Related Record

Filters:

* Priority  
* Read  
* Unread  
* Notification Type  
* Date Range

Sorting:

* Date  
* Priority

---

# **26.11 Business Rules**

* Notifications shall be generated automatically by system events.  
* Critical alerts cannot be disabled.  
* Deleted records shall not remove historical notifications.  
* Notification delivery failures shall be logged.  
* Notification templates shall be reusable.

**Added to make the idea better.**

---

# **26.12 Permissions**

Reception Employees may:

* View assigned notifications.

Sports Employees may:

* Send manual notifications to players under their responsibility.

Sports Managers may:

* Send bulk notifications.  
* Configure notification templates.

System Administrators shall have unrestricted access.

---

# **26.13 Audit Log**

Every notification action shall be recorded.

The Audit Log shall include:

* User  
* Date and Time  
* Notification Type  
* Recipient Count  
* Delivery Channel  
* Delivery Status

---

# **Chapter 27 — Security, Permissions & Audit Trail**

## **27.1 Introduction**

The Security & Permissions module ensures that every operation within the Sports Activity Module is protected through role-based access control (RBAC), detailed audit logging, and configurable permission management.

Every user shall only access the information and operations necessary for their role.

No operation affecting operational or financial data shall occur without being recorded in the Audit Log.

---

# **27.2 User Roles**

The system shall support predefined roles, including:

* Reception Employee  
* Sports Employee  
* Trainer  
* Medical Employee  
* Treasury Employee  
* Sports Manager  
* Club Manager  
* System Administrator

Additional custom roles may be created by administrators.

**Added to make the idea better.**

---

# **27.3 Permission Types**

Permissions shall be configurable for every module.

Supported permission types:

* View  
* Create  
* Edit  
* Delete  
* Approve  
* Cancel  
* Print  
* Export  
* Override  
* Archive

Permissions shall be assignable independently.

Example:

A user may View and Export Players without being able to Edit them.

---

# **27.4 Module Permissions**

Permissions shall be configurable for:

* Dashboard  
* Sports  
* Facilities  
* Programs  
* Groups  
* Players  
* Trainers  
* Academies  
* Medical  
* Attendance  
* Make-up Sessions  
* Mirror  
* Recreational Sports  
* Institution Bookings  
* Treasury Integration  
* Reports  
* Notifications  
* System Settings

Each module shall maintain its own permission matrix.

---

# **27.5 Record Ownership**

The system may optionally support ownership restrictions.

Examples:

A Trainer may only view:

* Their own Groups  
* Their own Players  
* Their own Attendance

A Medical Employee may only access:

* Medical Records

A Treasury Employee may only access:

* Financial Information

**Added to make the idea better.**

---

# **27.6 Approval Permissions**

Certain operations shall require approval.

Examples:

* Manual Discounts  
* Refund Requests  
* Program Overrides  
* Capacity Overrides  
* Mirror Conflict Overrides  
* Booking Cancellation After Payment

Approval workflows shall be configurable.

---

# **27.7 Password & Authentication**

Authentication shall follow the ERP's global authentication system.

If supported, additional features may include:

* Multi-Factor Authentication (MFA)  
* Password Expiration  
* Session Timeout  
* Device Verification

These settings shall be inherited from the ERP.

**Added to make the idea better.**

---

# **27.8 Audit Trail**

Every significant action shall generate an audit record.

Recorded information shall include:

* User  
* Date  
* Time  
* Module  
* Action  
* Record Identifier  
* Previous Values  
* New Values  
* IP Address (Optional)  
* Device Information (Optional)

Optional fields depend on ERP-wide audit settings.

**Added to make the idea better.**

---

# **27.9 Logged Operations**

Examples of operations that shall always be audited:

* Player Registration  
* Trainer Registration  
* Academy Registration  
* Program Assignment  
* Attendance Modification  
* Medical Approval  
* Subscription Renewal  
* Booking Creation  
* Booking Cancellation  
* Mirror Assignment  
* Price Override  
* Discount Approval  
* Refund Approval  
* Permission Changes

---

# **27.10 Search & Filters**

Audit logs shall support:

Search by:

* User  
* Module  
* Record ID

Filters:

* Date Range  
* Action Type  
* Module  
* User Role

Sorting:

* Date  
* User  
* Module

---

# **27.11 Data Protection**

The system shall ensure:

* Role-based access to sensitive information.  
* Secure storage of uploaded documents.  
* Protection against unauthorized modifications.  
* Compliance with the ERP's global security policies.

**Added to make the idea better.**

---

# **27.12 Business Rules**

* Every operation modifying data shall be audited.  
* Audit records shall never be edited.  
* Permissions shall be evaluated before every operation.  
* Deleted records shall remain visible within audit logs.  
* Administrators may not delete audit records.

---

# **27.13 Permissions**

Only System Administrators (or ERP Security Administrators) may:

* Create roles.  
* Edit permissions.  
* View complete audit logs.  
* Configure approval workflows.

Managers may only access audit logs related to modules they supervise.

---

# **27.14 Audit Log**

The Audit Log module itself shall also record:

* Login attempts.  
* Failed login attempts.  
* Permission changes.  
* Role assignments.  
* User activation/deactivation.  
* Audit log exports.

This ensures full traceability of security-related operations.

---

