اللوجيك الكامل للرواتب

1

أنواع العمليات المالية على الراتب

كل عملية مالية بتأثر على الراتب لازم تتسجل بشكل صحيح — مش مجرد خصم من الراتب، لأن فيه فلوس بتتحرك فعلياً.

⚡ العملية الأساسية = السحب من المرتب (تحت حساب)
دي العملية الوحيدة اللي فلوس فعلاً بتتسحب من الخزنة — يعني لازم يتعملها قيد محاسبي فوراً وقت الصرف.
باقي العمليات (خصم إتلاف، جزاء، خصم تأخير...) دي خصومات حسابية فقط — مفيش فلوس بتتحرك — بتظهر بس في قيد المسير آخر الشهر.

النوع	الشرح	فلوس بتتحرك؟	من فين؟	التأثير على الراتب
سحب تحت حساب	الموظف ياخد فلوس كاش من الخزنة أو تحويل قبل آخر الشهر	نعم — فوراً	الخزنة أو البنك	يتخصم من الراتب آخر الشهر
سلفة مقدمة	مبلغ كبير يتسدد على أقساط	نعم — فوراً	الخزنة أو البنك	قسط شهري يتخصم تلقائي
خصم إتلاف / جزاء	خصم بسبب إتلاف ممتلكات أو مخالفة	لا — خصم فقط	—	يتخصم من الراتب
حافز / مكافأة	مبلغ إضافي لمرة واحدة	حسب — ممكن نقدي أو مع الراتب	مع الراتب أو من الخزنة	يتضاف على الراتب
خصم تأخير / غياب	خصم تلقائي من الحضور	لا — تلقائي	—	يتخصم تلقائي
بدلات ثابتة	سكن، مواصلات، طعام (كل شهر)	لا — مع الراتب	—	يتضاف تلقائي
استقطاعات ثابتة	تأمينات، ضريبة (كل شهر)	لا — مع الراتب	—	يتخصم تلقائي

2

تعديلات المسير — Payroll Adjustments (جدول جديد)

جدول جديد لتسجيل أي خصم أو إضافة لمرة واحدة على مسير محدد — بدل ما تعدل هيكل الراتب.

الفرق بين هيكل الراتب والتعديلات:

	هيكل الراتب (Salary Structure)	تعديلات المسير (Payroll Adjustments)
التكرار	كل شهر (دائم)	مرة واحدة على مسير محدد
الأمثلة	بدل سكن، تأمينات	سحب تحت حساب، خصم إتلاف، حافز
التعديل	من شاشة هيكل الراتب	من شاشة المسير مباشرة
الربط	مرتبط بالموظف	مرتبط بالموظف والمسير

جدول `payroll_adjustments`:

الحقل	النوع	الشرح
id	bigint PK
payroll_id	FK → payrolls	المسير
employee_id	FK → employees	الموظف
type	enum(earning, deduction)	إضافة أو خصم
category	enum(advance, penalty, damage, bonus, incentive, other)	تصنيف العملية
amount	decimal(12,3)	المبلغ (موجب دائماً)
description	text	الوصف / السبب
reference_number	varchar nullable	رقم مرجعي (إيصال، أمر صرف)
payment_method	enum(cash, bank, from_salary) nullable	كيف اتصرف المبلغ
cash_account_id	FK → accounts nullable	حساب الخزنة/البنك اللي اتصرف منه
journal_entry_id	FK → journal_entries nullable	القيد المحاسبي (لو فيه فلوس اتحركت)
is_paid_out	boolean default false	هل الفلوس اتصرفت فعلاً (للسحبات)
paid_at	timestamp nullable	تاريخ الصرف الفعلي
status	enum(pending, approved, rejected) default 'approved'	حالة الموافقة — لو `approval_required = false` يتعمل approved مباشرة
approved_by	FK → users nullable	مين وافق
company_id	FK
created_by / updated_by	FK
timestamps

مثال — أحمد سحب 3 مرات في أبريل:

#	التاريخ	النوع	التصنيف	المبلغ	من فين	اتصرف؟
1	5 أبريل	خصم	سحب تحت حساب	1,000	الخزنة	نعم ✅
2	12 أبريل	خصم	سحب تحت حساب	500	تحويل بنكي	نعم ✅
3	20 أبريل	خصم	خصم إتلاف	300	من الراتب	لا (يتخصم آخر الشهر)

3

فلو السحب من المرتب — خطوة بخطوة

1. الموظف يطلب سحب من المرتب

↓

2. HR يدخل التعديل على المسير
يختار: الموظف + المبلغ + السبب + من فين (خزنة/بنك/من الراتب)

↓

3. الموافقة اختياري حسب الإعداد
لو approval_required = true → المدير يوافق أولاً
لو approval_required = false → يتصرف مباشرة (مرحلة واحدة — مناسب للمؤسسات الصغيرة)

↓ لو "من الخزنة" أو "تحويل بنكي"

4. ⭐ العملية الأساسية: صرف الفلوس فعلياً + القيد المحاسبي
وضع تلقائي (auto_journal = true): القيد يتعمل مباشرة مع تسجيل السحب — عملية واحدة من مكان واحد ✅
وضع يدوي (auto_journal = false): HR يسجل السحب → المحاسب يراجع ويعمل القيد منفصل
← قيد: مدين: سلف موظفين / دائن: الخزنة أو البنك

↓

5. عند حساب المسير آخر الشهر
التعديلات تتضاف تلقائي على حساب الموظف

↓

6. الراتب النهائي = الأساسي + البدلات - الخصومات الثابتة - التعديلات - الغياب + الإضافي

3.5

دورة الموافقة — اختيارية (حسب حجم المؤسسة)

الموافقة اختيارية وليست إجبارية — بعض المؤسسات الصغيرة عايزة تصرف مباشرة بدون دورة موافقة.

إعداد في `hr_settings`:

المفتاح	النوع	القيمة الافتراضية	الشرح
`payroll_adjustment_approval_required`	boolean	`false`	هل تعديلات المسير (سحبات، خصومات...) تحتاج موافقة مدير قبل الصرف؟
`payroll_adjustment_approval_roles`	json array	`["hr_manager"]`	الأدوار اللي تقدر توافق (لو الموافقة مفعّلة)
`payroll_adjustment_auto_journal`	boolean	`true`	هل القيد المحاسبي يتعمل تلقائي مع تسجيل السحب؟ أو يحتاج المحاسب يعمله يدوي؟

السلوك حسب الإعداد:

الإعداد	الفلو	مناسب لـ
`approval_required = false`	HR يضيف التعديل → يتصرف مباشرة (بدون موافقة)	مؤسسات صغيرة، مالك واحد، فريق صغير
`approval_required = true`	HR يضيف التعديل → المدير يوافق → المحاسب يصرف	شركات كبيرة، فصل صلاحيات، رقابة مالية

سلوك القيد المحاسبي:

الإعداد	الفلو	مناسب لـ
`auto_journal = true`	HR يضيف السحب → القيد المحاسبي يتعمل أوتوماتيك فوراً — عملية واحدة من مكان واحد	مؤسسات صغيرة، بدون محاسب منفصل
`auto_journal = false`	HR يضيف السحب → المحاسب يراجع ويعمل القيد يدوي من شاشة القيود	شركات كبيرة، فصل بين HR والمحاسبة

الافتراضي (المؤسسات الصغيرة): الموافقة معطلة + القيد تلقائي = HR يضيف السحب وكل حاجة تتعمل مرة واحدة. مفيش أي blocking — المحاسب أو HR يقدر يضيف سحب ويتعمل القيد فوراً.

4

شجرة الحسابات — حساب فرعي لكل موظف

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

4.1 هيكل شجرة الحسابات:

الأصول المتداولة (1000)
├── الخزينة (1100)
├── البنك (1110)
│
├── مسحوبات موظفين — تحت حساب (1300)
│   ├── أحمد محمد (1300-EMP001)
│   ├── خالد علي (1300-EMP002)
│   └── سارة حسن (1300-EMP003)
│
├── قروض موظفين (1310)
│   ├── أحمد محمد (1310-EMP001)
│   ├── خالد علي (1310-EMP002)
│   └── سارة حسن (1310-EMP003)
│
└── ذمم موظفين — جزاءات وإتلاف (1320)
    ├── أحمد محمد (1320-EMP001)
    ├── خالد علي (1320-EMP002)
    └── سارة حسن (1320-EMP003)

المصروفات (4000)
├── مصروف رواتب وأجور (4100)
│   ├── أحمد محمد (4100-EMP001)
│   ├── خالد علي (4100-EMP002)
│   └── سارة حسن (4100-EMP003)
│
├── مصروف بدلات (4110)
│   ├── أحمد محمد (4110-EMP001)
│   ├── خالد علي (4110-EMP002)
│   └── سارة حسن (4110-EMP003)
│
├── مصروف حوافز ومكافآت (4200)
│   ├── أحمد محمد (4200-EMP001)
│   ├── خالد علي (4200-EMP002)
│   └── سارة حسن (4200-EMP003)
│
└── مصروف تأمينات (حصة الشركة) (4300)
    ├── أحمد محمد (4300-EMP001)
    ├── خالد علي (4300-EMP002)
    └── سارة حسن (4300-EMP003)

الالتزامات (2000)
├── رواتب مستحقة (2100)
│   ├── أحمد محمد (2100-EMP001)
│   ├── خالد علي (2100-EMP002)
│   └── سارة حسن (2100-EMP003)
│
├── تأمينات مستحقة (2200)
│   ├── أحمد محمد (2200-EMP001)
│   └── ...
│
└── ضرائب مستحقة (2300)
    ├── أحمد محمد (2300-EMP001)
    └── ...

الإنشاء تلقائي: لما موظف يتعمله أول عملية على أي حساب → النظام يعمل حساب فرعي تلقائي.
الكود: {parent_code}-{employee_number} — مثال: 1300-EMP001
الاسم: {اسم الحساب الرئيسي} — {اسم الموظف} — مثال: مسحوبات — أحمد محمد

4.2 الفوائد:

الفائدة	الشرح
رصيد مباشر	تفتح حساب أحمد في المسحوبات → تعرف عليه كام فوراً
تسوية نهاية خدمة	لما الموظف يمشي → الرصيد المعلق واضح في حسابه
تقارير	المدير المالي يشوف شجرة السلف ويعرف كل موظف رصيده
مراجعة	المراجع يطابق الحساب الفرعي مع كشف الموظف
ميزان المراجعة	الحساب الرئيسي = مجموع الفرعيات تلقائي

5

القيود المحاسبية لكل نوع عملية — بحساب فرعي لكل موظف

⭐ العملية الأساسية = السحب تحت حساب
دي العملية الوحيدة اللي بتتحرك فيها فلوس فعلياً من الخزنة — فلازم يتعمل قيد محاسبي فوري.

5.1 سحب تحت حساب (من الخزنة) — ⭐ العملية الأساسية:

عند الصرف — يتعمل قيد فوراً (مثال: أحمد سحب 1,000 كاش):

الحساب	مدين	دائن
مسحوبات — أحمد محمد (1300-EMP001)	1,000
الخزينة (1100)		1,000

إعداد القيد المحاسبي: حسب إعداد payroll_adjustment_auto_journal:

تلقائي (true — الافتراضي): القيد يتعمل أوتوماتيك لحظة تسجيل السحب — عملية واحدة من مكان واحد.
يدوي (false): HR يسجل السحب، والمحاسب يعمل القيد منفصل.

عند حساب الراتب (آخر الشهر):

السحب يتخصم من الراتب — قيد المسير يقفل حساب الموظف الفرعي:

الحساب	مدين	دائن
مصروف رواتب — أحمد (4100-EMP001)	8,000
مسحوبات — أحمد (1300-EMP001)		1,000
رواتب مستحقة — أحمد (2100-EMP001)		7,000

← كده حساب مسحوبات أحمد رصيده صفر — السحب اتقفل مع الراتب.

5.2 سحب تحت حساب (تحويل بنكي) — مثال: أحمد 500 تحويل:

الحساب	مدين	دائن
مسحوبات — أحمد محمد (1300-EMP001)	500
البنك (1110)		500

5.3 قرض / سلفة مقسطة — مثال: أحمد سلفة 6,000 على 6 أشهر:

عند صرف السلفة:

الحساب	مدين	دائن
قروض — أحمد محمد (1310-EMP001)	6,000
الخزينة (1100)		6,000

كل شهر (قسط 1,000 يتخصم من الراتب):

الحساب	مدين	دائن
مصروف رواتب — أحمد (4100-EMP001)	8,000
قروض — أحمد (1310-EMP001)		1,000
رواتب مستحقة — أحمد (2100-EMP001)		7,000

← كده كل شهر رصيد القرض بينقص 1,000 تلقائي لحد ما يخلص.

5.4 خصم إتلاف / جزاء (بدون صرف فوري):

مفيش قيد فوري — بيتخصم من الراتب آخر الشهر. مثال: أحمد عليه جزاء 300:

الحساب	مدين	دائن
مصروف رواتب — أحمد (4100-EMP001)	8,000
ذمم جزاءات — أحمد (1320-EMP001)		300
رواتب مستحقة — أحمد (2100-EMP001)		7,700

5.5 حافز / مكافأة (مع الراتب):

بيتضاف على الراتب — مثال: أحمد حافز 2,000 مع الراتب:

الحساب	مدين	دائن
مصروف رواتب — أحمد (4100-EMP001)	8,000
مصروف حوافز — أحمد (4200-EMP001)	2,000
رواتب مستحقة — أحمد (2100-EMP001)		10,000

5.6 حافز / مكافأة (نقدي فوري من الخزنة):

مثال: أحمد حافز 2,000 كاش من الخزنة:

الحساب	مدين	دائن
مصروف حوافز — أحمد (4200-EMP001)	2,000
الخزينة (1100)		2,000

5.7 قيد المسير الكامل (مثال أحمد — أبريل):

لما المسير يتحسب ويترحّل، القيد الكامل بكل التفاصيل:

الحساب	مدين	دائن	الشرح
مصروف رواتب — أحمد (4100-EMP001)	8,000		الراتب الأساسي
مصروف بدلات — أحمد (4110-EMP001)	2,500		سكن 2000 + مواصلات 500
مصروف حوافز — أحمد (4200-EMP001)	2,000		حافز مبيعات
مسحوبات — أحمد (1300-EMP001)		1,500	سحب 1000 + سحب 500 (اتصرفوا قبل كده)
قروض — أحمد (1310-EMP001)		500	قسط السلفة الشهري
ذمم جزاءات — أحمد (1320-EMP001)		300	خصم إتلاف
تأمينات مستحقة — أحمد (2200-EMP001)		780	GOSI 9.75%
تأمين طبي مستحق		200	تأمين طبي
خصم غياب		533.33	غياب يومين
رواتب مستحقة — أحمد (2100-EMP001)		7,186.67	← المبلغ الفعلي المستحق (الصافي - المسحوبات)
إجمالي مدين: 12,500		إجمالي دائن: 12,500 ✅

لاحظ: حساب "مسحوبات — أحمد" رصيده كان 1,500 مدين (من السحبات اللي اتصرفت خلال الشهر).
لما المسير اترحّل → الحساب اتدان 1,500 → الرصيد بقى صفر ← السحبات اتقفلت مع الراتب تلقائي.

6

حساب المسير الكامل مع التعديلات

لكل موظف نشط:

  // ===== المكاسب =====
  earnings = basic_salary                         // 8,000

  // بدلات ثابتة (من هيكل الراتب)
  + housing_allowance (25% × 8000)                // +2,000
  + transport_allowance (ثابت)                     // +500

  // ساعات إضافية (من الحضور)
  + overtime (10h × 33.33 × 1.5)                  // +500

  // تعديلات إيجابية (من payroll_adjustments)
  + حافز مبيعات                                   // +2,000
  ---
  total_earnings = 13,000

  // ===== الخصومات =====
  deductions = 0

  // خصومات ثابتة (من هيكل الراتب)
  + GOSI (9.75% × 8000)                           // +780
  + medical_insurance (ثابت)                       // +200

  // خصم الغياب (من الحضور)
  + absent_deduction (2 × 266.67)                  // +533.33

  // تعديلات سلبية (من payroll_adjustments)
  + سحب تحت حساب 1                               // +1,000
  + سحب تحت حساب 2                               // +500
  + خصم إتلاف                                     // +300

  // أقساط القروض (من loans — تلقائي)
  + قسط سلفة                                      // +500
  ---
  total_deductions = 3,813.33

  // ===== الصافي =====
  net_salary = total_earnings - total_deductions
             = 13,000 - 3,813.33
             = 9,186.67

  // ===== المستحق الفعلي (بعد خصم اللي اتصرف) =====
  already_paid_out = 1,000 + 500                   // السحبات اللي اتصرفت فعلاً
  remaining_to_pay = net_salary - already_paid_out
                   = 9,186.67 - 1,500
                   = 7,686.67  ← ده اللي يتصرف آخر الشهر

كشف راتب أحمد — أبريل 2026:

المكاسب
الراتب الأساسي	8,000.00
بدل سكن (25%)	+2,000.00
بدل مواصلات	+500.00
ساعات إضافية (10h)	+500.00
حافز مبيعات ⭐	+2,000.00
إجمالي المكاسب	13,000.00
الخصومات
تأمينات اجتماعية (9.75%)	-780.00
تأمين طبي	-200.00
خصم غياب (2 يوم)	-533.33
سحب تحت حساب (5 أبريل) ⭐	-1,000.00
سحب تحت حساب (12 أبريل) ⭐	-500.00
خصم إتلاف ⭐	-300.00
قسط سلفة	-500.00
إجمالي الخصومات	-3,813.33
صافي الراتب	9,186.67
الصرف
اتصرف مقدماً (سحبات)	-1,500.00
المستحق الفعلي (يتصرف آخر الشهر)	7,686.67

7

القبض الجزئي — صرف موظف بموظف

بدل ما تصرف كل الموظفين مرة واحدة — تقدر تصرف موظف واحد أو مجموعة.

حقول جديدة على `payroll_items`:

الحقل	النوع	الشرح
`payment_status`	enum(unpaid, paid, held)	حالة الصرف لهذا الموظف
`paid_at`	timestamp nullable	تاريخ الصرف
`hold_reason`	text nullable	سبب الإيقاف (لو held)
`already_paid_out`	decimal(12,3) default 0	المبلغ اللي اتصرف مقدماً (سحبات)
`remaining_to_pay`	decimal(12,3)	المستحق الفعلي = net_salary - already_paid_out

حالات المسير:

الحالة	المعنى
draft	مسودة — لم يُحسب بعد
calculated	محسوب — جاهز للمراجعة
approved	معتمد — جاهز للترحيل
posted	مرحّل — القيد المحاسبي اتعمل
partially_paid	جديد — بعض الموظفين اتصرفوا
paid	كل الموظفين اتصرفوا

APIs جديدة:

Method	Endpoint	الوظيفة
POST	`/payroll/{id}/pay-item`	صرف موظف واحد — body: { payroll_item_id }
POST	`/payroll/{id}/hold-item`	إيقاف صرف موظف — body: { payroll_item_id, reason }
POST	`/payroll/{id}/pay`	صرف كل المتبقي (unpaid) دفعة واحدة

8

APIs تعديلات المسير (Payroll Adjustments)

Method	Endpoint	الوظيفة
GET	`/payroll/{id}/adjustments`	قائمة التعديلات لمسير محدد
POST	`/payroll/{id}/adjustments`	إضافة تعديل (خصم/إضافة) — body: { employee_id, type, category, amount, description, payment_method, cash_account_id }
PUT	`/payroll/{id}/adjustments/{adj_id}`	تعديل
DELETE	`/payroll/{id}/adjustments/{adj_id}`	حذف (قبل الحساب فقط)
POST	`/payroll/{id}/adjustments/{adj_id}/pay-out`	صرف المبلغ فعلياً (يعمل قيد محاسبي)

تعديل منطق الحساب:

عند POST /payroll/{id}/calculate:

يحسب المكاسب والخصومات الثابتة (كالعادة)
جديد: يجمع التعديلات من payroll_adjustments لهذا المسير
التعديلات earning → تضاف على total_earnings
التعديلات deduction → تضاف على total_deductions
جديد: يحسب already_paid_out (مجموع التعديلات اللي is_paid_out = true)
جديد: يحسب remaining_to_pay = net_salary - already_paid_out

9

الشاشات المطلوبة في الفرونت إند

8.1 شاشة المسير المحسّنة:

عند الضغط على "تفاصيل" → يعرض كل موظف بالتفصيل:
- المكاسب بالاسم (بدل سكن: +2000، بدل مواصلات: +500)
- الخصومات بالاسم (تأمينات: -780، تأمين طبي: -200)
- التعديلات بالاسم (سحب: -1000، خصم إتلاف: -300، حافز: +2000)
- خصم الغياب + الإضافي
- المستحق الفعلي (بعد السحبات)
حالة الصرف لكل موظف (unpaid / paid / held)
زر "صرف" لكل موظف
زر "إيقاف" مع سبب
زر "صرف الكل" للمتبقي

8.2 شاشة تعديلات المسير (جديدة):

تفتح من داخل المسير — تاب أو dialog
جدول: الموظف | النوع (خصم/إضافة) | التصنيف | المبلغ | السبب | طريقة الصرف | اتصرف؟
زر "إضافة تعديل" → dialog: اختار موظف + النوع + التصنيف + المبلغ + السبب + من فين
زر "صرف" على كل سحب → يعمل قيد محاسبي ويعلّم كـ paid_out

8.3 تحسين كشف الراتب:

يعرض كل التفاصيل: مكاسب + خصومات ثابتة + تعديلات + غياب + إضافي
المستحق الفعلي (بعد السحبات) بشكل واضح
قابل للطباعة

10

المسير والفروع — Multi-Branch Payroll

المشكلة الحالية: المسير بيجيب كل موظفين الشركة مرة واحدة — مفيش فصل بالفرع.
لو شركة عندها 3 فروع (القاهرة 50 موظف، الإسكندرية 30، أسوان 20) → المسير بيحسب الـ 100 مع بعض.

10.1 الوضع الحالي في الباك إند:

المكان	branch_id موجود؟	التفاصيل
الموظف (employees)	نعم ✅	`branch_id` موجود ومطلوب (required)
الأقسام (departments)	نعم ✅	`branch_id` على كل قسم
المسير (payrolls)	لا ❌	مفيش `branch_id` — بيجيب كل الموظفين
الحضور (attendance)	نعم ✅	مرتبط بالموظف اللي عنده فرع

10.2 المطلوب:

أ. حقل `branch_id` على جدول `payrolls`

الحقل	النوع	الشرح
`branch_id`	FK → branches, nullable	`null` = كل الفروع (مسير شامل) قيمة محددة = فرع واحد فقط

ب. تعديل `PayrollService::calculate()`

// الحالي (خطأ):
$employees = Employee::where('company_id', $companyId)
    ->active()->get();

// المطلوب:
$query = Employee::where('company_id', $companyId)->active();

if ($payroll->branch_id) {
    $query->where('branch_id', $payroll->branch_id);
}

$employees = $query->get();

ج. فلتر المسيرات بالفرع

الشاشة	الفلتر
قائمة المسيرات	filter by `branch_id` — المستخدم يشوف بس مسيرات فرعه (أو الكل لو super admin)
إنشاء مسير	اختيار الفرع (أو "كل الفروع") عند الإنشاء
التقارير	تقرير الرواتب يدعم فلتر بالفرع

د. الـ Unique Constraint

حالياً: unique(company_id, month, year) — يعني مسير واحد بس في الشهر.

المطلوب: unique(company_id, branch_id, month, year) — مسير لكل فرع في الشهر.

branch_id = null (مسير شامل) يظل unique بـ (company_id, NULL, month, year).
لو عملت مسير لفرع القاهرة ومسير لفرع الإسكندرية في نفس الشهر → مسموح.
لو عملت مسيرين لنفس الفرع في نفس الشهر → ممنوع.

10.3 السيناريوهات:

سيناريو 1 — شركة صغيرة (فرع واحد أو مش عايز يفصل):

يعمل مسير بدون اختيار فرع (branch_id = null) → كل الموظفين يتحسبوا مع بعض. نفس السلوك الحالي.

سيناريو 2 — شركة متعددة الفروع:

مسير أبريل — فرع القاهرة (50 موظف) → branch_id = 1
مسير أبريل — فرع الإسكندرية (30 موظف) → branch_id = 2
مسير أبريل — فرع أسوان (20 موظف) → branch_id = 3
كل مسير مستقل: حساب، اعتماد، ترحيل، صرف — كل فرع لوحده

سيناريو 3 — مدير فرع:

مدير فرع القاهرة يدخل يشوف بس مسيرات فرعه — مش بيشوف الإسكندرية أو أسوان.

Super admin يشوف كل المسيرات من كل الفروع.

10.4 القيد المحاسبي والفرع:

لما المسير يترحّل — القيد المحاسبي يكون مرتبط بنفس الفرع:

الحساب	مدين	دائن	الفرع
مصروف رواتب — أحمد (4100-EMP001)	8,000		القاهرة
مصروف رواتب — خالد (4100-EMP002)	6,000		القاهرة
رواتب مستحقة — أحمد (2100-EMP001)		8,000	القاهرة
رواتب مستحقة — خالد (2100-EMP002)		6,000	القاهرة

كده التقارير المالية تقدر تفصل مصروفات الرواتب بالفرع.

11

ملخص كل التغييرات المطلوبة

Backend (أحمد):

#	المهمة	الأولوية
1	جدول `payroll_adjustments` + migration	عاجل
2	CRUD APIs للتعديلات + pay-out endpoint	عاجل
3	تعديل `PayrollService::calculate()` ليشمل التعديلات + already_paid_out	عاجل
4	حقول payment_status + paid_at + hold_reason + remaining_to_pay على payroll_items	عالي
5	endpoints: pay-item + hold-item + حالة partially_paid	عالي
6	PayrollItemResource يشمل details + adjustments	عالي
7	⭐ قيد محاسبي تلقائي عند صرف السحب (pay-out) — دي العملية الأساسية. يدعم الوضعين: تلقائي (قيد فوري مع السحب) أو يدوي (المحاسب يعمله)	عاجل
8	إعدادات: `payroll_adjustment_approval_required` + `payroll_adjustment_auto_journal` + `payroll_adjustment_approval_roles`	عالي
9	حسابات فرعية لكل موظف: إنشاء تلقائي لحساب فرعي تحت (1300 مسحوبات، 1310 قروض، 1320 جزاءات، 4100 رواتب، 4110 بدلات، 4200 حوافز، 2100 مستحقات) عند أول عملية — كود: `{parent}-{emp_number}`	عاجل
10	قيد المسير يستخدم الحسابات الفرعية لكل موظف (مش حساب عام واحد)	عاجل
11	دعم الفروع في المسير: إضافة `branch_id` (nullable FK) على `payrolls` + تعديل `calculate()` ليفلتر بالفرع + تعديل unique constraint لـ `(company_id, branch_id, month, year)` + فلتر المسيرات بفرع المستخدم + القيد المحاسبي يكون مرتبط بالفرع	عاجل

Frontend (حازم):

#	المهمة	الأولوية
1	شاشة تعديلات المسير (إضافة/حذف خصومات وإضافات)	عاجل
2	تفاصيل كشف الراتب (مكاسب + خصومات بالاسم)	عالي
3	القبض الجزئي (صرف/إيقاف لكل موظف)	عالي
4	طباعة كشف الراتب	متوسط
5	فلتر الفرع في شاشة المسير (إنشاء مسير لفرع محدد + فلتر القائمة بالفرع)	عالي

اللوجيك الكامل للرواتب — Moon HR

أنواع العمليات المالية على الراتب

تعديلات المسير — Payroll Adjustments (جدول جديد)

الفرق بين هيكل الراتب والتعديلات:

جدول payroll_adjustments:

مثال — أحمد سحب 3 مرات في أبريل:

فلو السحب من المرتب — خطوة بخطوة

دورة الموافقة — اختيارية (حسب حجم المؤسسة)

إعداد في hr_settings:

السلوك حسب الإعداد:

سلوك القيد المحاسبي:

شجرة الحسابات — حساب فرعي لكل موظف

4.1 هيكل شجرة الحسابات:

4.2 الفوائد:

القيود المحاسبية لكل نوع عملية — بحساب فرعي لكل موظف

5.1 سحب تحت حساب (من الخزنة) — ⭐ العملية الأساسية:

5.2 سحب تحت حساب (تحويل بنكي) — مثال: أحمد 500 تحويل:

5.3 قرض / سلفة مقسطة — مثال: أحمد سلفة 6,000 على 6 أشهر:

5.4 خصم إتلاف / جزاء (بدون صرف فوري):

5.5 حافز / مكافأة (مع الراتب):

5.6 حافز / مكافأة (نقدي فوري من الخزنة):

5.7 قيد المسير الكامل (مثال أحمد — أبريل):

حساب المسير الكامل مع التعديلات

كشف راتب أحمد — أبريل 2026:

القبض الجزئي — صرف موظف بموظف

حقول جديدة على payroll_items:

حالات المسير:

APIs جديدة:

APIs تعديلات المسير (Payroll Adjustments)

تعديل منطق الحساب:

الشاشات المطلوبة في الفرونت إند

8.1 شاشة المسير المحسّنة:

8.2 شاشة تعديلات المسير (جديدة):

8.3 تحسين كشف الراتب:

المسير والفروع — Multi-Branch Payroll

10.1 الوضع الحالي في الباك إند:

10.2 المطلوب:

أ. حقل branch_id على جدول payrolls

ب. تعديل PayrollService::calculate()

ج. فلتر المسيرات بالفرع

د. الـ Unique Constraint

10.3 السيناريوهات:

سيناريو 1 — شركة صغيرة (فرع واحد أو مش عايز يفصل):

سيناريو 2 — شركة متعددة الفروع:

سيناريو 3 — مدير فرع:

10.4 القيد المحاسبي والفرع:

ملخص كل التغييرات المطلوبة

Backend (أحمد):

Frontend (حازم):

جدول `payroll_adjustments`:

إعداد في `hr_settings`:

حقول جديدة على `payroll_items`:

أ. حقل `branch_id` على جدول `payrolls`

ب. تعديل `PayrollService::calculate()`