دورة حياة طلب الإجازة المقترحة
================================

الغرض من الوثيقة
----------------

توضح هذه الوثيقة دورة حياة طلب الإجازة منذ إنشائه وحتى أرشفته، وكيفية التعامل مع رصيد الموظف في كل مرحلة. الهدف هو ضمان عدم خصم الإجازة قبل استحقاقها، وعدم تكرار الحجز أو الخصم، والمحافظة على سجل يومي واضح يمكن مراجعته لاحقًا.


أولًا: المفاهيم الأساسية للرصيد
--------------------------------

1. الرصيد الافتتاحي:
   الرصيد الممنوح للموظف في بداية سنة الإجازة.

2. الأيام المستخدمة:
   أيام الإجازة التي مضى تاريخها وتمت معالجتها فعليًا.

3. الأيام المحجوزة:
   أيام طلبات الإجازة المعتمدة التي لم يحن موعدها أو لم تتم معالجتها بعد.

4. أيام التعديل:
   الزيادة أو النقصان الإداري الذي يطبق على رصيد الموظف.

5. الرصيد المتبقي:

   الرصيد المتبقي = الرصيد الافتتاحي - (الأيام المستخدمة + أيام التعديل)

   الأيام المحجوزة لا تخصم من الرصيد المتبقي، لكنها تؤخذ في الاعتبار عند التحقق من إمكانية اعتماد طلب جديد.

6. الرصيد المتاح لطلب جديد:

   الرصيد المتاح = الرصيد المتبقي - الأيام المحجوزة


ثانيًا: دور جدول أيام طلب الإجازة
---------------------------------

ينشأ لكل تاريخ داخل مدة الطلب سجل مستقل في جدول vacation_request_days.

يسجل كل يوم المعلومات الآتية:

- تاريخ اليوم.
- يوم الأسبوع.
- هل اليوم عطلة أسبوعية أم يوم عمل.
- هل اليوم عطلة رسمية.
- اسم العطلة الرسمية المرتبطة به، إن وجدت.
- قيمة اليوم التي تخصم من الرصيد.
- هل يؤثر اليوم على رصيد الإجازة.
- وقت حجز اليوم عند اعتماد الطلب.
- وقت تحويل اليوم من محجوز إلى مستخدم.
- وقت تحرير اليوم عند إلغاء الجزء المستقبلي من الطلب.

هذا الجدول هو المرجع الأساسي لحساب أيام العمل، والحجز، والاستخدام، والإلغاء. ولا يعتمد النظام على عدد أيام يدخله المستخدم يدويًا.


ثالثًا: قواعد احتساب أيام الطلب
-------------------------------

1. يوم عمل عادي:
   قيمة اليوم = 1، ويؤثر على الرصيد.

2. عطلة أسبوعية:
   قيمة اليوم = 0، ولا تؤثر على الرصيد.

3. عطلة رسمية مستثناة من احتساب الإجازة:
   قيمة اليوم = 0، ولا تؤثر على الرصيد.

4. نصف يوم، في حال دعمه مستقبلًا:
   قيمة اليوم = 0.5، ويؤثر على الرصيد.

5. يحسب عدد أيام عمل الطلب من مجموع قيم الأيام المؤثرة على الرصيد داخل جدول أيام الطلب.


رابعًا: حالات طلب الإجازة
-------------------------

الحالات الأساسية المقترحة هي:

1. مقدم: تم إنشاء الطلب وإرساله.
2. قيد المراجعة: تم فتح الطلب للمراجعة الرسمية أو طباعته.
3. معتمد: تمت الموافقة على الطلب وحجز أيامه المؤهلة.
4. مرفوض: تم رفض الطلب قبل اعتماده.
5. ملغي: تم إلغاء الطلب، مع معالجة أي حجز سابق حسب حالة الأيام.
6. مؤرشف: انتهت مدة الطلب وتمت معالجة جميع أيامه المؤثرة على الرصيد.

وتكون حالة الموافقة:

- قيد الانتظار أثناء التقديم والمراجعة.
- معتمد عند الموافقة.
- مرفوض عند الرفض.


خامسًا: دورة حياة الطلب بالتفصيل
--------------------------------

المرحلة 1: إنشاء الطلب وتقديمه
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

عند إنشاء طلب جديد، ينفذ النظام ما يلي:

1. التحقق من صحة بيانات الطلب، مثل الموظف ونوع الإجازة والتواريخ.
2. إنشاء رقم طلب تلقائي مرتبط بالسنة الحالية.
3. إنشاء سجل مستقل لكل يوم من تاريخ البداية إلى تاريخ النهاية.
4. تحديد العطل الأسبوعية والرسمية لكل يوم.
5. تحديد الأيام التي تؤثر على الرصيد وقيمة كل يوم.
6. احتساب أيام العمل تلقائيًا من سجلات أيام الطلب.
7. ضبط حالة الطلب على "مقدم".
8. ضبط حالة الموافقة على "قيد الانتظار".
9. تسجيل تاريخ ووقت التقديم.

تأثير الرصيد في هذه المرحلة:

- لا يتم حجز أي أيام.
- لا يتم إضافة أي أيام إلى المستخدم.
- لا يتغير الرصيد المتبقي.

السبب:

الطلب لم يعتمد بعد، لذلك لا يجب أن يؤثر على رصيد الموظف.


المرحلة 2: تحويل الطلب إلى قيد المراجعة
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

عند فتح الطلب للمراجعة الرسمية أو طباعته:

1. تتغير حالة الطلب من "مقدم" إلى "قيد المراجعة".
2. تبقى حالة الموافقة "قيد الانتظار".
3. لا يحدث أي تغيير على رصيد الموظف.

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


المرحلة 3: رفض الطلب قبل الاعتماد
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

يمكن رفض الطلب عندما تكون حالته "مقدم" أو "قيد المراجعة".

عند الرفض:

1. تتغير حالة الطلب إلى "مرفوض".
2. تتغير حالة الموافقة إلى "مرفوض".
3. يسجل تاريخ ووقت الرفض.
4. يمكن حفظ سبب الرفض إذا كان النظام يدعمه.

تأثير الرصيد:

- لا يتم تعديل الرصيد لأن الطلب لم يكن معتمدًا ولم يحجز أي أيام.


المرحلة 4: إلغاء الطلب قبل الاعتماد
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

يمكن إلغاء الطلب عندما تكون حالته "مقدم" أو "قيد المراجعة".

عند الإلغاء:

1. تتغير حالة الطلب إلى "ملغي".
2. يسجل تاريخ ووقت الإلغاء.
3. يمكن حفظ سبب الإلغاء إذا كان النظام يدعمه.

تأثير الرصيد:

- لا يتم تعديل الرصيد لأنه لم يتم حجز أي أيام بعد.


المرحلة 5: اعتماد الطلب
~~~~~~~~~~~~~~~~~~~~~~~

قبل الاعتماد يجب على النظام التحقق من الآتي:

1. أن الطلب في حالة تسمح بالاعتماد.
2. أن جميع أيام الطلب محسوبة ومحدثة.
3. عدم وجود طلب إجازة معتمد آخر للموظف يتداخل مع الأيام المؤثرة نفسها.
4. وجود رصيد للسنة ونوع الإجازة والموظف.
5. أن الرصيد المتاح يكفي لتغطية الأيام المطلوب اعتمادها.

طريقة التحقق من الرصيد:

الأيام المطلوبة = مجموع قيم أيام الطلب التي تؤثر على الرصيد ولم تعالج أو تحرر سابقًا.

الرصيد المتاح = الرصيد المتبقي - الأيام المحجوزة.

إذا كانت الأيام المطلوبة أكبر من الرصيد المتاح، يرفض النظام عملية الاعتماد برسالة واضحة.

عند نجاح الاعتماد:

1. تضاف الأيام المطلوبة إلى الأيام المحجوزة للموظف.
2. يسجل وقت الحجز في كل يوم مؤثر من أيام الطلب.
3. تتغير حالة الطلب إلى "معتمد".
4. تتغير حالة الموافقة إلى "معتمد".
5. يسجل تاريخ ووقت الاعتماد.

تأثير الرصيد:

- الأيام المحجوزة تزيد بمجموع الأيام المؤهلة.
- الأيام المستخدمة لا تتغير.
- الرصيد المتبقي لا يتغير.

يجب تنفيذ الاعتماد داخل معاملة قاعدة بيانات واحدة مع قفل سجلات الطلب والأيام والرصيد، لمنع اعتماد طلبين في اللحظة نفسها على الرصيد ذاته.


المرحلة 6: المعالجة اليومية للإجازات المعتمدة
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

تنفذ مهمة مجدولة يوميًا بعد منتصف الليل، مثل الساعة 00:10.

تعالج المهمة أيام الإجازة التي تنطبق عليها جميع الشروط التالية:

1. الطلب معتمد.
2. تاريخ يوم الإجازة أصبح قبل تاريخ اليوم الحالي.
3. اليوم يؤثر على الرصيد.
4. اليوم محجوز.
5. اليوم لم يعالج سابقًا.
6. اليوم لم يحرر بسبب الإلغاء.

لكل يوم مؤهل تنفذ العملية التالية:

1. تنقص قيمة اليوم من الأيام المحجوزة.
2. تضاف قيمة اليوم إلى الأيام المستخدمة.
3. يعاد احتساب الرصيد المتبقي:

   الرصيد المتبقي = الرصيد الافتتاحي - (الأيام المستخدمة + أيام التعديل)

4. يسجل وقت معالجة اليوم.

مثال:

إذا كان الطلب المعتمد يحتوي على خمسة أيام عمل، فإن الخمسة أيام تحجز عند الاعتماد. بعد انتهاء كل يوم، ينقل النظام قيمة ذلك اليوم فقط من المحجوز إلى المستخدم، إلى أن تتم معالجة جميع أيام الطلب.

ضمان عدم التكرار:

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


المرحلة 7: أرشفة الطلب تلقائيًا
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

بعد انتهاء مدة الطلب، يؤرشف النظام الطلب عندما تتحقق الشروط التالية:

1. تاريخ نهاية الطلب أصبح قبل تاريخ اليوم الحالي.
2. لا يوجد يوم مؤثر على الرصيد ما زال محجوزًا دون معالجة أو تحرير.

عندها تتغير حالة الطلب من "معتمد" إلى "مؤرشف".

العطل الأسبوعية والعطل الرسمية التي لا تؤثر على الرصيد لا تمنع الأرشفة.

الأرشفة لا تغير الرصيد؛ فهي تثبت فقط أن دورة الطلب انتهت بالكامل.


سادسًا: إلغاء طلب بعد اعتماده
-----------------------------

إذا ألغي طلب معتمد، يجب التفريق بين الأيام الماضية والأيام المستقبلية:

1. الأيام التي عولجت سابقًا:
   تبقى ضمن الأيام المستخدمة، ولا تعاد تلقائيًا إلى الرصيد.

2. الأيام المحجوزة التي لم تعالج بعد:
   تحرر من الحجز، وتنقص قيمتها من الأيام المحجوزة.

3. يسجل وقت التحرير في كل يوم تم تحريره.

4. تتغير حالة الطلب إلى "ملغي".

5. يسجل تاريخ ووقت الإلغاء.

مثال:

طلب معتمد مدته خمسة أيام عمل. تمت معالجة يومين وألغي الطلب قبل الأيام الثلاثة المتبقية:

- يبقى اليومان ضمن الأيام المستخدمة.
- تحرر الأيام الثلاثة من المحجوز.
- لا يعاد اليومان الماضيان إلى الرصيد بشكل تلقائي.

إذا تقرر إداريًا إعادة يوم مستخدم، فيجب تنفيذ ذلك من خلال تسوية أو تعديل رصيد مستقل ومسجل، وليس من خلال إلغاء الطلب مباشرة.


سابعًا: قواعد تعديل الطلب وحذفه
-------------------------------

1. الطلب المقدم أو قيد المراجعة:

- يمكن تعديل بياناته حسب الصلاحيات.
- عند تغيير الموظف أو نوع الإجازة أو تاريخ البداية أو النهاية، تعاد عملية توليد أيام الطلب واحتساب أيام العمل.

2. الطلب المعتمد:

- يمنع تعديله بالطريقة العادية.
- يجب إلغاؤه أو استخدام مسار تعديل معتمد ومستقل مستقبلًا.

3. الطلب المرفوض أو الملغي أو المؤرشف:

- يحتفظ به كسجل تاريخي.
- يمنع حذفه حذفًا نهائيًا إذا كان مرتبطًا بحركات رصيد أو أيام معالجة.

4. يوم طلب تمت معالجته:

- لا يعدل ولا يحذف.


ثامنًا: الانتقالات المسموحة بين الحالات
--------------------------------------

1. مقدم -> قيد المراجعة.
2. مقدم -> مرفوض.
3. مقدم -> ملغي.
4. قيد المراجعة -> معتمد.
5. قيد المراجعة -> مرفوض.
6. قيد المراجعة -> ملغي.
7. معتمد -> مؤرشف تلقائيًا بعد انتهاء جميع الأيام ومعالجتها.
8. معتمد -> ملغي مع تحرير الأيام المستقبلية غير المعالجة فقط.

لا يسمح بالانتقال المباشر من مرفوض أو ملغي أو مؤرشف إلى معتمد. إذا احتاج الموظف إلى الإجازة بعد رفض الطلب أو إلغائه، ينشأ طلب جديد لضمان سلامة السجل الرقابي.


تاسعًا: الضوابط الرقابية والتقنية
---------------------------------

1. لا يتغير الرصيد عند إنشاء الطلب.
2. لا يتغير الرصيد عند الطباعة أو بدء المراجعة.
3. لا يتغير الرصيد عند الرفض أو الإلغاء قبل الاعتماد.
4. تحجز الأيام فقط عند الاعتماد.
5. تنتقل قيمة كل يوم من المحجوز إلى المستخدم بعد انتهاء ذلك اليوم.
6. لا تؤثر الأيام المحجوزة على معادلة الرصيد المتبقي.
7. تؤخذ الأيام المحجوزة في الاعتبار عند فحص الرصيد المتاح لطلب جديد.
8. يمنع اعتماد طلبين متداخلين للموظف على الأيام المؤثرة نفسها.
9. لا يعالج اليوم الواحد أكثر من مرة.
10. لا يصفّر النظام إجمالي المحجوز عند معالجة أو إلغاء طلب واحد.
11. تنفذ عمليات الاعتماد والمعالجة والإلغاء داخل معاملات قاعدة البيانات مع قفل الرصيد.
12. تعالج المهمة اليومية السجلات على دفعات لتفادي استهلاك الذاكرة عند وجود عدد كبير من الموظفين.
13. يحتفظ النظام بسجل تواريخ الحجز والمعالجة والتحرير لأغراض المراجعة والتدقيق.


عاشرًا: مثال كامل لدورة الطلب
-----------------------------

لدى الموظف:

- الرصيد المتبقي: 20 يومًا.
- الأيام المحجوزة من طلبات أخرى: 3 أيام.
- الرصيد المتاح: 17 يومًا.

قدم الموظف طلبًا يحتوي على 7 تواريخ، منها:

- 5 أيام عمل مؤثرة على الرصيد.
- يوم عطلة أسبوعية.
- يوم عطلة رسمية لا تخصم من الرصيد.

تكون دورة الطلب كالآتي:

1. عند التقديم:
   أيام العمل = 5، ولا يتغير الرصيد.

2. عند بدء المراجعة:
   لا يتغير الرصيد.

3. عند الاعتماد:
   تزيد الأيام المحجوزة بمقدار 5، فتصبح الحجوزات الإجمالية 8 أيام.

4. بعد انتهاء أول يوم عمل:
   ينقص المحجوز بمقدار 1، ويزيد المستخدم بمقدار 1.

5. تستمر العملية يوميًا حتى تعالج أيام العمل الخمسة.

6. لا تخصم العطلة الأسبوعية أو العطلة الرسمية من الرصيد.

7. بعد انتهاء الطلب ومعالجة جميع أيامه المؤثرة:
   تتحول حالة الطلب إلى "مؤرشف".


الحالات التي تحتاج قرارًا إداريًا
--------------------------------

يرجى اعتماد أو تحديد السياسة المطلوبة للنقاط التالية قبل الإطلاق النهائي:

1. هل يمكن اعتماد الطلب مباشرة من حالة "مقدم"، أم يجب أن يمر دائمًا بحالة "قيد المراجعة"؟
2. هل طباعة الطلب وحدها تنقله إلى "قيد المراجعة"، أم يجب وجود إجراء مستقل لبدء المراجعة؟
3. هل يسمح للموظف بإلغاء طلب معتمد بنفسه، أم يحتاج إلى موافقة الإدارة؟
4. كيف تعالج الإجازة المرضية أو الطارئة التي تسجل بعد مرور تاريخها؟
5. هل يسمح بالرصيد السالب لبعض أنواع الإجازات أو الفئات الوظيفية؟
6. هل توجد أنواع إجازات لا تحتاج إلى رصيد أصلًا؟
7. عند وجود عطلة رسمية داخل طلب معتمد ثم تعديل العطلة لاحقًا، هل يحتفظ الطلب بالحساب الأصلي أم يعاد احتسابه قبل بداية الإجازة؟
8. هل يسمح بنصف يوم، وما أنواع الإجازات التي تدعمه؟
9. هل تحتاج إعادة الأيام المستخدمة إلى مسار تسوية وموافقة منفصل؟
10. ما الصلاحيات المطلوبة لكل من الاعتماد والرفض والإلغاء والتعديل والتسوية؟


النتيجة المقترحة
----------------

تعتمد الدورة المقترحة الفصل بين ثلاث مراحل مالية واضحة:

1. التقديم والمراجعة: لا تأثير على الرصيد.
2. الاعتماد: حجز الأيام المستقبلية فقط.
3. انتهاء يوم الإجازة: نقل قيمة اليوم من المحجوز إلى المستخدم.

يوفر هذا الأسلوب رصيدًا دقيقًا، ويمنع الحجز الزائد والخصم المكرر، ويحافظ على تاريخ واضح لكل يوم إجازة منذ اعتماده وحتى استخدامه أو تحريره.