# H11.0-P10.4 — أتمتة الإيراد اليومي للمرضى المنومين

## 1. الهدف
إضافة صفحة مستقلة في Hospital Executive Dashboard تعرض الإيراد اليومي المحسوب لكل مريض منوم موجود حاليًا في غرفة، مع إلغاء العمل اليدوي على عمود `Daily Revenue` وتوفير تصدير مباشر لملف `final.xlsx`.

## 2. سير العمل القديم الذي تمت مراجعته
1. تنفيذ الاستعلام الموجود في `file1.txt` لإنتاج بيانات التعداد الأولية كما في `file1.xlsx`.
2. تحويل البيانات بواسطة كود Mirth الموجود في `file2.txt` إلى ملف `file2.xlsx` مع ترك `Daily Revenue` فارغًا.
3. تعبئة `Daily Revenue` يدويًا وفق الشركة ومدة الإقامة أو عبر استدعاء الإجراء القديم لكل مريض للحصول على حصة المريض أو حصة الشركة.

هذا الأسلوب يجمع بين العمل اليدوي والاستدعاءات الثقيلة المتكررة، ولا يناسب المرضى المقيمين حاليًا لأن منطق الإجراء القديم يعتمد على `VISIT_END_DATE` أو `MERGE_VISIT_END_DATE` ضمن اختيار زيارات المرضى الداخليين.

## 3. السبب الجذري للمشكلة
المشكلة ليست مجرد بطء استدعاء واحد؛ بل إن الإجراء القديم مصمم كتقرير إيرادات واسع ومفصل، ويقوم بتجهيز جداول مؤقتة وتجميع مصادر متعددة وإجراء عمليات إضافية تخص الفواتير والضريبة والمطالبات. تشغيله مرة لكل مريض يؤدي إلى تكرار نفس العمل الثقيل عدة مرات.

كذلك فإن اختيار المرضى الداخليين داخل الإجراء القديم مقيد بتاريخ نهاية الزيارة، وهو شرط غير متوافر بطبيعته للمريض الذي ما زال منومًا حاليًا.

## 4. الحل الجديد
تم إنشاء محرك قراءة واحد `set-based` يبدأ بقائمة المرضى الذين لديهم حركة سرير نشطة (`RCP_BED_TRANS.ENDDATE IS NULL`) ثم يجمع الإيرادات لكل `PATFINANACCOUNT` من مصادر الإيراد الأصلية مباشرة في استعلام واحد.

لا يتم استدعاء `SP_IPD_OPD_VAT_REVENUE` ولا `SP_INPATIENT_REVENUE_DATA` من الصفحة الجديدة.

## 5. مصادر الإيراد التي تمت إعادة بنائها
المحرك الجديد يجمع عشر فئات مطابقة لبنية المنطق القديم:

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

تم الحفاظ على خصم `bill_discount_val` والخصومات الفرعية للإقامة في المواضع التي يستخدمها المنطق القديم.

## 6. قواعد Daily Revenue المعتمدة في هذه المرحلة

### الشركة 365 — CENTER FOR NATIONAL HEALTH INSURANCE
- `Total LOS <= 30` → `4,746.87 SR`.
- `Total LOS > 30` → `2,373.00 SR`.
- مصدر `Total LOS`: تاريخ أول دخول `first admission date` فقط لهذه الشركة.

### الشركة 170 — TCS
- `LOS 1–3` → `2,250 SR`.
- `LOS 4–8` → `1,950 SR`.
- `LOS 9+` → `1,750 SR`.
- مصدر `LOS`: `RCP_VISIT.VISIT_START_DATE`.

### الشركة 1 — CASH
`Daily Revenue = accumulated patient share / LOS`

ومصدر `LOS` هو `RCP_VISIT.VISIT_START_DATE`.

### بقية شركات التأمين
`Daily Revenue = accumulated company share / LOS`

ومصدر `LOS` هو `RCP_VISIT.VISIT_START_DATE`.

## 7. تصحيح Total LOS
في التقرير القديم كان `Total LOS` محسوبًا من `first_Admission_date` لكل الشركات. في التنفيذ الجديد:

- الشركة 365 فقط تستخدم تاريخ أول دخول.
- كل الشركات الأخرى تستخدم `RCP_VISIT.VISIT_START_DATE`.

## 8. تصميم الصفحة الجديدة
الصفحة تحتوي على:

- Hero تنفيذي يوضح الفرع ووقت اللقطة وزر تصدير `final.xlsx`.
- خمس بطاقات KPI: عدد المرضى الحاليين، إجمالي الإيراد اليومي، المتوسط لكل مريض، نسبة الحساب التلقائي، وعدد الحالات التي تحتاج مراجعة.
- لوحة واضحة لقواعد الحساب الأربع.
- رسم تركيز جهات الدفع لأعلى خمس شركات حسب الإيراد اليومي.
- رسم الإيراد اليومي والإشغال حسب الوحدة.
- جدول تفصيلي لكل مريض مع البحث والفلترة، ويعرض LOS وTotal LOS والحصة المتراكمة والإيراد وطريقة الحساب والحالة.

## 9. ملف Excel النهائي
زر التصدير ينتج ملفًا حقيقيًا باسم `final.xlsx` يحتوي على:

- ورقة `Summary` للمؤشرات والوحدات وجهات الدفع.
- ورقة `Daily Revenue` للتفاصيل الكاملة لكل مريض.

المصدر نفسه هو بيانات الصفحة المحسوبة، لذلك لا توجد مرحلة تعبئة يدوية منفصلة بعد التصدير.

## 10. الأداء
التحسين الأساسي هو الانتقال من نمط `N patients × one heavy procedure call per patient` إلى قراءة واحدة set-based لجميع المرضى الحاليين، مع تنفيذ دالة أول دخول فقط على المرضى النشطين من الشركة 365، وتنفيذ دالة عدد الأسرة مرة لكل وحدة مميزة بدلًا من مرة لكل صف.

## 11. الحماية والتوافق
- لا توجد أي عمليات كتابة إلى Oracle.
- لا توجد تغييرات في الجداول أو الإجراءات القديمة.
- الصفحة مقيدة بصلاحية الإيرادات الحالية `dashboard_role_revenue`.
- الفرع المفعّل في هذه المرحلة هو `NJCH` برقم Oracle branch `1` لأن الحزمة المرجعية والاستعلام القديم خاصان بهذا الفرع.
- الفروع الأخرى تعرض حالة غير متاحة بدل تنفيذ استعلام برقم فرع مفترض.

## 12. فجوة مرجعية يجب تسجيلها
في ملف `final.xlsx` القديم توجد أمثلة للشركة 365 بعد 30 يومًا بقيمة `2373.44`، بينما القاعدة المطلوبة صراحة في هذه المرحلة هي `2373.00`.

تم تنفيذ `2373.00` وفق الطلب الحالي، مع إبقاء الاختلاف مسجلًا للتحقق المالي النهائي وعدم إخفائه.

## 13. خطة الاختبار قبل اعتماد الإنتاج
1. اختبار قواعد 365 عند 30 و31 يومًا.
2. اختبار حدود TCS عند الأيام 3 و4 و8 و9.
3. مقارنة حالات CASH مختارة مع إجمالي Patient Share الظاهر في النظام.
4. مقارنة حالات تأمين مختارة مع إجمالي Company Share الظاهر في النظام.
5. مقارنة 10–20 مريضًا حاليًا مع الحساب اليدوي أو المرجع القديم حيث يمكن ذلك.
6. فحص حالات multi-finance، الباقات، مرتجعات الأدوية، العمليات، والإقامة.
7. قياس زمن التنفيذ على قاعدة NJCH الحية ومقارنته بزمن الاستدعاء المتكرر القديم.
8. اختبار تصدير `final.xlsx` وفتحه في Excel والتحقق من الصفوف والإجماليات.

## 14. حالة التحقق الحالية
تم تنفيذ اختبارات syntax وقواعد الحساب والتصدير محليًا. لا توجد وصلة مباشرة بقاعدة Oracle الحية داخل بيئة إعداد الحزمة، لذلك لا يجوز اعتبار المطابقة الرقمية النهائية مع بيانات المستشفى الحية مكتملة قبل تشغيل اختبار المقارنة على بيئة NJCH.