```html
- شنو هو تتبع المدفوعات؟
تتبع المدفوعات هو المحرك الأساسي للمعلومات المالية للوحدة الخاصة بالتقارير.
يجمع كل المدفوعات الواردة، بصرف النظر عن المصدر أو الطريقة أو نوع المستند، ويعرضها في مخطط زمني تقدر تبحث فيه وتفلتره وتسوي له تدقيق.
هذي الوحدة للقراءة فقط بشكل افتراضي، إلا في الحالات التالية:
-
عمليات استرجاع المبالغ
-
التعامل مع الحالات
-
ربط الإيداعات
- نظرة عامة على الهيكل (مفهوم بصري)
documents_payments
│
├─ contactus → هوية العميل
├─ user_detail → عضو الفريق (اللي سوى عملية الخصم)
├─ documents → فاتورة / إيصال / GI-IR
├─ invoices_settings→ إعدادات الشركة والفواتير
├─ deposit_bank → حالة الإيداع البنكي
│
▼
وحدة تحكم المدفوعات
(loadrecord_payment)
│
▼
HTML + Chart JSON
│
▼
واجهة المستخدم لتتبع المدفوعات
ليش تتبع المدفوعات موجود (الهدف التجاري)
تتبع المدفوعات موجود عشان يحل محل عدم اليقين المحاسبي اليدوي من خلال:
✅ شفافية كاملة
✅ رؤية في الوقت الفعلي
✅ مطابقة دقيقة
✅ سجلات جاهزة للتدقيق
✅ تقارير تلقائية
يعتبر مصدر وحيد للحقيقة لـ:
-
فرق المالية
-
الإدارة
-
المدققين
-
دعم العملاء
- وين مكان تتبع المدفوعات في النظام
عميل
│
▼
فاتورة / طلب
│
▼
محاولة دفع
│
├─► نجاح ──► إيداع ──► تقارير محاسبية
│
└─► فشل ──► إعادة محاولة / تدقيق / دعم
تتبع المدفوعات موجود بين العمليات التشغيلية والمحاسبة، ويضمن أن ما في أي عملية مالية تكون مو مخفية.
- دورة حياة الدفع – شرح مرئي
1️⃣ مرحلة الإنشاء – النية تتحول إلى فعل
يتم إنشاء سجل دفعة كل ما:
-
عميل يدفع من خلال بوابة الدفع (بطاقة، بيت، تحويل، إلخ)
-
صراف يسجل نقد أو شيك
-
اشتراك يتجدد تلقائيًا
-
واجهة برمجة تطبيقات خارجية ترسل معاملة
-
في هذي اللحظة، النظام يلتقط:
-
هوية العميل
-
مبلغ الدفع والعملة
-
طريقة الدفع
-
المستندات ذات الصلة
-
عضو فريق التنفيذ
-
الاستجابة الفنية لبوابة الدفع
-
هذا يضمن تتبع من أول ثانية.
2️⃣ مرحلة المعالجة – فحص الواقع
مو كل المدفوعات تكون “فلوس حقيقية” على طول.
خلال هذي المرحلة، النظام يقيم:
-
موافقة بوابة الدفع مقابل التسوية
-
تحصيل الشيكات
-
ممكن تكون المدفوعات في حالات مؤقتة، اللي تسمح للنظام بـ:
-
يعيد المحاولة بأمان
-
يعرض الإخفاقات بشفافية
-
يمنع الإبلاغ المبكر عن الإيرادات
-
3️⃣ مرحلة الإنجاز – حقيقة محاسبية
بس لما يتم تأكيد الدفعة، تصير:
-
تتغير حالتها إلى محوّل
-
تظهر في حسابات الإيرادات
-
تصير مؤهلة للإيداع واسترجاع المبلغ
-
تتدفق لتقارير التدفق النقدي والالتزامات
-
هذا يحمي سلامة مسك الدفاتر.
- نظام حالة الدفع (ليش هو مهم)
✅ محوّل (نجح)
يمثل فلوس مؤكدة.
-
يتضمن في التقارير المالية
-
مؤهل لاسترجاع المبلغ
-
يمكن إيداعه في البنك
-
يعتبر آمن محاسبيًا
-
❌ ما تحوّل (فشل)
يمثل فلوس حاولوا يستلمونها بس ما تمت.
-
أبد ما ينمسح
-
المدفوعات اللي فشلت تعتبر أدلة تجارية، مو أخطاء لازم نخفيها.
- منطق الفلترة – مصمم عشان الأسئلة التجارية الحقيقية
كل فلتر موجود لأن شخص ما في فريق المالية أو الدعم يحتاجه جدًا.
- فلاتر التواريخ
المحاسبين يشتغلون حسب الفترات، مو بالتخمين.
الفلاتر تشتغل على تاريخ إنشاء الدفعة، وتضمن تقارير دقيقة بناءً على أساس نقدي.
- نطاق المبالغ
يستخدم لـ:
-
كشف الاحتيال
-
تدقيقات القيم العالية
-
تحليل الاستثناءات
-
- عميل، إيميل، جوال
فرق الدعم تدور بناءً على الذاكرة البشرية، مو حسب المعرفات.
هذا يسمح بحل سريع للمشاكل.
- طرق الدفع
كل طريقة لها أشياء مختلفة:
-
رسوم
-
مخاطر
-
تأخيرات التسوية
-
فصلها يسمح بـ:
-
تقييم أداء بوابة الدفع
-
تحسين التكاليف
-
تخطيط مطابقة البنوك
-
- مدفوعات متعددة وطرق مدمجة (محاسبة في العالم الحقيقي)
فاتورة وحدة ممكن تدفعها بـ:
-
نقد
-
بطاقة ائتمان
-
تحويل بنكي
-
كلهم مع بعض
-
بدل ما تتكرر الفواتير، النظام يخزن بيانات إيصالات متعددة ومنظمة، وهالشي يضمن:
-
دقة ضريبة القيمة المضافة
-
استردادات صحيحة
-
الامتثال للمتطلبات القانونية
-
- الوعي بالإيداع – جسر بين البرامج والبنوك
دفع ناجح ≠ فلوس في البنك.
تتبع المدفوعات يتابع بشكل صريح:
-
نجاح الدفع
-
حالة الإيداع
-
تاريخ الإيداع
-
ربط بالبنك
-
هذا يسمح بـ:
-
توقعات تدفق نقدي دقيقة
-
مطابقة الإيداعات
-
تقارير جاهزة للتدقيق
- طبقة الأمان والتدقيق والثقة
كل دفعة:
-
مقتصرة على المنظمة
-
دوره تم التحقق منه
-
هذا يضمن:
-
القدرة على الدفاع القانوني
-
ثقة المدققين
-
مساءلة داخلية
-
ما يمكن إزالتها بصمت
-
ممكن تتبعها للمستخدم
