أنا عاوز أوضح بشكل دقيق المفروض منظومة النشاط الرياضي في النادي تكون شغالة إزاي، وبعد كده يتم تحليل النظام الحالي ومقارنته بالنظام المطلوب، مع توضيح الفروقات والنواقص بشكل واضح.

1. منظومة المرافق والحجوزات الحرة
   كل نشاط رياضي داخل النادي يحتوي على مرافق مرتبطة به، وكل مرفق له:

* مواعيد تشغيل يومية.
* أسعار مختلفة للساعة حسب:

  * الوقت.
  * نوع العميل (عضو / غير عضو / مؤسسة).

لكن أسعار الساعات دي تُستخدم فقط في حالة:

* الحجز الحر.
* الحجز الفردي.
* الحجز المؤسسي.
* أي استخدام غير مرتبط ببرنامج تدريبي أو تمرين مجدول.

وفي نفس الوقت، أي حجز يتم على المرفق لازم يظهر داخل “مراية المرفق” بشكل واضح على الـ Timeline، مع توضيح:

* الوقت المحجوز.
* الجهة أو الشخص الحاجز.
* نوع الحجز.

2. منظومة الأكاديميات والبرامج التدريبية
   النادي يحتوي على أكاديميات رياضية مسؤولة عن إدارة التدريبات داخل النادي.

كل أكاديمية ممكن:

* تكون مسؤولة عن رياضة واحدة أو أكثر.
* تقدم عدة برامج تدريبية لكل رياضة.

وكل برنامج تدريبي يكون له:

* سعر للأعضاء.
* سعر لغير الأعضاء.

بعد إنشاء البرنامج التدريبي، يتم إنشاء مجموعات تدريبية مرتبطة به، وكل مجموعة:

* يتم تحديد أيام وساعات تدريبها.
* يتم حجز مواعيدها على المرفق الخاص بها.

ومن المهم جدًا إن النظام يسمح بوجود أكثر من مجموعة تدريبية في نفس الوقت على نفس المرفق إذا كانت سعة المرفق تسمح بذلك (Overlapping Groups).

ولازم مراية المرفق تعرض هذا الأمر بشكل بصري واضح واحترافي على الـ Timeline الخاص بالمرفق، مع مراعاة الـ Capacity الخاصة بالمرفق سواء كانت:

* مجموعات تدريبية.
* حجوزات فردية.
* حجوزات مؤسسية.
* حجوزات حرة.

3. مفهوم “مراية المرفق”
   المراية هي مجرد Visualization للمرافق والحجوزات، ويجب أن تكون:

* قابلة للتصنيف حسب الرياضة.
* قابلة للفلترة بشكل عملي وسريع.

على سبيل المثال:
لو موظف يريد حجز Bowling أو PlayStation، لا يصح أن يدخل على كل مرفق بشكل منفصل ليرى المتاح.
المطلوب هو عرض Visualized محترم وواضح يبين:

* كل المرافق الخاصة بالنشاط.
* المتاح والمحجوز.
* الفترات الزمنية.
* السعة الحالية.

بشكل سريع وسهل الاستخدام.

4. منظومة حمامات السباحة
   حمامات السباحة يجب أن تتبع نفس المنظومة العامة للمرافق، ولكن بطريقة عرض وحجز مختلفة.

كل حمام سباحة يعتبر “مرفق” عادي داخل النظام، لكن شاشة الحجز الخاصة به تكون بنظام Grid كامل بدل الـ Timeline التقليدي.

الهدف من الـ Grid هو دعم جميع الـ Edge Cases المطلوبة.

ويجب أن يدعم النظام:

* حجز حارات.
* حجز Cells أو مناطق محددة داخل الحمام.
* تحديد أيام ومواعيد لكل مساحة.
* تحديد نوع الإتاحة:

  * متاح للحجز الحر.
  * متاح للأعضاء فقط.
  * متاح للجميع.

وفي بعض الحالات تكون المساحة “غير محجوزة” ولكنها “متاحة للاستخدام الحر” خلال فترة معينة، بحيث أي شخص يستطيع دفع تذكرة دخول واستخدامها.

مع مراعاة:

* وجود أسعار مختلفة للأعضاء وغير الأعضاء.
* عدم وجود مفهوم “فرد يحجز حمام سباحة بالكامل لنفسه”، لأن طبيعة استخدام حمامات السباحة مختلفة عن الملاعب والمرافق الفردية.

5. Wizard مكتب التسجيل
   مطلوب تبسيط الـ Wizard الخاص بمكتب التسجيل لأقصى درجة ممكنة.

الـ Workflow المطلوب يكون كالتالي:

* الموظف يدخل بيانات اللاعب.
* يرفع صورة اللاعب.
* يرفع الشهادة الطبية (إن وجدت).
* يختار الرياضة.
* يختار البرنامج التدريبي.

بعدها النظام يقوم تلقائيًا بـ:

* حساب الرسوم.
* إضافة المبلغ على الخزنة.
* إدخال اللاعب في آخر مجموعة غير مكتملة داخل البرنامج التدريبي المختار.

ولو كل المجموعات الحالية مكتملة:

* النظام يفتح مجموعة جديدة تلقائيًا.
* ويتم إضافة اللاعب إليها مباشرة.

وفي نفس الوقت:

* المدرب يجب أن يمتلك صلاحية نقل أي لاعب يدويًا من مجموعة إلى أخرى.
* حتى لو هذا النقل تسبب في تجاوز العدد المسموح للمجموعة (Overloading Group).
في نقطة محورية مهمة جدًا لازم تكون واضحة في المنظومة، وهي إن أي مرفق داخل النادي في النهاية بيكون محجوز لواحدة من 3 حالات فقط:

* فرد / حجز حر.
* مجموعة تدريبية.
* مؤسسة أو جهة.

لكن حتى في حالة “الحجز الفردي” أو “حجز المؤسسة”، الحجز في الحقيقة لا يخص شخصًا واحدًا فقط، بل يخص عددًا معينًا من الأشخاص المسموح لهم بالدخول واستخدام المرفق.

يعني مثلًا:
لو شخص قام بحجز ملعب كرة خماسي لمدة ساعة، فمن الطبيعي إن الاستخدام الفعلي للمرفق سيكون لـ 10 أفراد، وليس لشخص واحد فقط.

لذلك النظام يجب أن يدعم أكثر من طريقة لإدارة الأشخاص المرتبطين بالحجز:

1. تسجيل كامل للأفراد
   يتم إدخال:

* أسماء اللاعبين.
* أرقامهم القومية أو بياناتهم الكاملة.

وفي هذه الحالة يصبح كل شخص مسجل داخل النظام ويمكن التحقق منه عند الدخول.

2. تسجيل جزئي للأفراد
   في بعض الحالات قد لا تتوفر كل البيانات، لذلك النظام يجب أن يسمح بإدخال:

* أسماء الأشخاص فقط.

بدون الحاجة لبيانات كاملة أو رقم قومي.

3. نظام الـ Passes
   في حالة عدم توفر أي بيانات عن الأفراد، النظام يجب أن يسمح بإنشاء عدد محدد من الـ Passes المرتبطة بالحجز.

مثال:

* حجز ملعب كرة خماسي = 10 Passes.
* حجز Paddle زوجي = 4 Passes.
* حجز Bowling لحارتين = عدد محدد حسب الحجز.

وفي هذه الحالة:

* موظف البوابة يتأكد فقط إن عدد الداخلين لا يتجاوز عدد الـ Passes المسموح بها.
* لا يجوز دخول عدد أكبر من العدد المحدد.
* ويُفضل أيضًا تسجيل عدد من تم استخدامه فعليًا من الـ Passes.

وهذا المفهوم يجب أن يطبق على:

* الملاعب.
* حمامات السباحة.
* البولينج.
* البادل.
* البلايستيشن.
* أي مرفق ترفيهي أو رياضي داخل النادي.

لأن الحجز في النهاية ليس “حجز شخص”، بل هو:
“حجز Capacity / حق استخدام لمجموعة من الأشخاص خلال فترة زمنية محددة”.

ولذلك يجب أن تكون منظومة:

* الحجوزات.
* البوابات.
* الـ Access Control.
* والمرايات الخاصة بالمرافق.

كلها مترابطة مع مفهوم:
عدد الأشخاص المسموح لهم بالدخول الفعلي بناءً على نوع الحجز وسعته.
لازم يكون في مفهوم أساسي داخل تعريف أي مرفق في النظام وهو:

* Expected Capacity
  أو
* Perfect Capacity

وهو العدد الطبيعي أو المتوقع للأشخاص الذين يستخدمون هذا المرفق في الحجز الواحد.

القيمة دي يتم تحديدها أثناء إنشاء المرفق نفسه، وتصبح جزء أساسي من إعداداته.

أمثلة:

* ملعب كرة خماسي → Expected Capacity = 10
* جهاز PlayStation → Expected Capacity = 2
* حارة Bowling → Expected Capacity = 6
* ملعب Paddle → Expected Capacity = 4
* طاولة Billiard → Expected Capacity = 2

وأهمية الرقم ده إنه يستخدم تلقائيًا داخل النظام في حالات الحجز الحر أو الحجز غير التدريبي.

يعني:
لو عميل قام بحجز ملعب كرة خماسي لمدة ساعة، فالنظام تلقائيًا:

* يتوقع دخول 10 أفراد.
* يطلب إما:

  * تسجيل أسماء اللاعبين.
  * أو إنشاء 10 Passes للدخول.

ولو تم تسجيل عدد أقل أو أكبر من الـ Expected Capacity، النظام:

* إما يعطي Warning.
* أو يطلب تأكيد إداري حسب صلاحيات المستخدم.

أما في حالة البرامج التدريبية والمجموعات:
فالـ Expected Capacity لا يكون شرطًا ثابتًا، لأن:

* المدرب قد يسمح بزيادة العدد.
* بعض المرافق تتحمل أكثر من مجموعة في نفس الوقت.
* وبعض التدريبات طبيعتها مختلفة.

لذلك:
الـ Expected Capacity الخاصة بالمرفق تستخدم بشكل أساسي في:

* الحجوزات الحرة.
* الحجوزات الفردية.
* الحجوزات المؤسسية.
* وتنظيم الدخول من البوابات.

ويجب أن تكون القيمة:

* قابلة للتعديل.
* ظاهرة بوضوح داخل إعدادات المرفق.
* ومستخدمة تلقائيًا في الـ Wizard الخاص بالحجز وإنشاء الـ Passes.
