تقرير تشخيص فنّي — برنامج الحسابات (ERP / PHP 5.6)

الخلاصة السريعة

المشكلة الأولى: مخزون المنتج رقم 8 لا يتأثر حرِجة

ما هو المنتج 8؟

من بين 44 منتجاً في النظام، يوجد منتجان فقط مُعرّفان كخدمة: المنتج 8 (نشِط — وهو محلّ المشكلة)، والمنتج 6 (محذوف/غير نشط).

السبب الجذري

الدليل من الكود (مواضع دقيقة)

دالة فحص الخدمة في controllers/selllfunction.php:1593:

function isService($id) {
    global $myProductRecord;
    $pro = $myProductRecord->load($id);
    return $pro->isService;
}

مسار البيع في controllers/sellbillController.php — السطر يُسجّل الفاتورة دائماً، ثم يشترط المخزون:

// سطر 6072 — سطر الفاتورة يُسجَّل دائماً (خارج الشرط):
$detailId = $mySellbilldetailRecord->insert($mySellbilldetail);
...
// سطر 6101 — تحديث المخزون فقط لو لم يكن خدمة:
$isService = isService($productId);
if ($isService == 0) {        // إذا كان صنفاً (وليس خدمة)
    $productquantityAfter = decreaseProductQuantity(...);   // تحديث storedetail
    insertStorereportupdate($productId, $sellbillstoreId, ...,
        "اضافة فاتورة مبيعات", "sellbillController.php", ...); // تسجيل storereport
}

نفس الشرط متكرّر في كل المسارات المؤثّرة على المخزون:

• البيع: sellbillController.php الأسطر 5448، 5624، 6101، 6466، 8163، 8329، 8765، 9107، 9709، 11151، 11605، 12103 — وselllfunction.php الأسطر 457، 658، 778، 999، 1106، 1221.
• الشراء: buyBillController.php:2998 (وتكرارات لاحقة) وbillsfunctionsbuy.php:632 بصيغة if ($product->isService != 1).
• المرتجعات: مرتجع بيع returnsellbillController.php:1455، ومرتجع شراء returnBuyBillController.php:795.

الدليل من البيانات — هنا يظهر الانقطاع بوضوح

بينما باقي المنتجات (9، 10، 32 …) مخزونها يتحرّك حتى اليوم 2026-06-21 — المشكلة منحصرة في المنتج 8 وحده.

الأثر المالي

الحلّ (خطوتان — كلاهما ضروري)

1. إلغاء صفة «خدمة»: افتح بطاقة المنتج 8 ← أزِل علامة «خدمة» ← احفظ (لتصبح isService = 0). هذا يُعيد تأثير المخزون لكل العمليات المستقبلية فوراً.
2. عمل تسوية مخزون (تسوية بالنقص): إلغاء الصفة لا يُعيد حركات فبراير–يونيو المفقودة بأثر رجعي. الرصيد ما زال مجمّداً عند 625. لذلك بعد إلغاء الصفة: اعمل جرد فعلي للصنف، ثم سجّل تسوية من شاشة settlementstoreController.php (نفس الأداة المستخدمة بتاريخ 18 يناير «تسوية مخزن بالنقص») لضبط الرصيد على الكمية الحقيقية. لا تُعدّل جدول storedetail يدوياً — استخدم شاشة التسوية حتى يبقى سجل المخزون متّسقاً.

المشكلة الثانية: «حذف فواتير البيع لا يعمل» الحذف يعمل فعلياً

إثبات أن الحذف يعمل (من قاعدة البيانات)

أحدث عمليات الحذف الناجحة (بواسطة المستخدم رقم 1 = admin):

الحذف هنا «حذف ناعم» (Soft delete): الفاتورة تُعلَّم conditions = 1 مع تسجيل من حذفها، وتُعكَس قيودها اليومية ومخزونها (حركة «حذف فاتورة مبيعات» في storereport). وجود هذه القيود العكسية يؤكّد أن الحذف تمّ عبر منطق البرنامج الصحيح، لا بحذف مباشر.

مسار الحذف في الكود

إعدادات التحكّم في الحذف (كلها حالياً على «السماح»)

لماذا يبدو أحياناً أن «الحذف لا يعمل»؟ (الأسباب المحتملة الحقيقية)

الخطوة التالية لتحديد سبب حالتك بدقّة

1. كرّر المشكلة بحساب المستخدم الفعلي وسجّل: رقم الفاتورة بالضبط + ماذا يظهر؟ (لا يوجد زر / «سدّد الفاتورة أولاً» / رسالة الخزنة / صفحة خطأ / لا شيء عند الضغط على «نعم»). هذه الملاحظة الواحدة تحسم السبب.
2. تأكّد من إعدادات مجموعة صلاحيات هذا المستخدم تحديداً:
   SELECT allowEditDelInBills, noBillEditIfTheirIsPayments, billDeletePassword FROM usergroup WHERE usergroupid = <مجموعته>;
3. لو الزر يختفي للفواتير غير المسدّدة ← السبب إعداد noBillEditTillPay أو عدم تطابق الدفع.

تحسينات مقترحة للكود (عند السماح بالتعديل لاحقاً)

• في delete() (الأسطر 9620–9636): إمّا تفعيل فحص الخزنة بإيقاف حقيقي، أو إزالة الرسالة المُضلِّلة، حتى تتطابق الرسالة مع النتيجة الفعلية.
• استبدال المسار النسبي fopen("backup/...") مع die() في selllfunction.php:1602 بمسار مطلق ومعالجة أخطاء سليمة.
• إظهار سبب الخطأ الفعلي من الخادم (flag=2) في الواجهة بدل صفحة خطأ عامة.

خطة العمل المختصرة