ناجز وناجز للمطورينNajiz and Najiz Developers

بوابة الخدمات العدلية الإلكترونية (القضايا، الجلسات، الأحكام، الوكالات، التنفيذ). «ناجز للمطورين» منصة رسمية لربط الجهات بالخدمات العدلية؛ لكل منتج موافقة مستقلة، والحقول الفعلية لا تُعرف إلا بعد التسجيل (خطة ناجز ص2-3).

1ما المنصة، ومن الجهة المالكة، وما اختصاصها؟

منصة وزارة العدل للخدمات العدلية. «ناجز للمطورين» أُطلقت وفق الخطة في 30 يونيو 2025 وتضم منتجات للقضاء والتوثيق والتنفيذ والمصالحة والمحامين، ومنتجات لجهات أخرى (خطة ناجز ص3). الأعداد المذكورة (174 و153) من مصدر صحفي في الخطة غير مثبت؛ وعند فتح المنصة في 2026-11-04 عرضت أقسامًا بأعداد مختلفة (القضاء +63، التنفيذ +21، البورصة العقارية +27، التوثيق +49)، فالكتالوج يتغير ويُراجع عند التسجيل.

2ما الإجراء الذي ينفذه المحامي فيها؟

يقيد الدعوى، يقدم المذكرات، يحضر الجلسات عن بعد، يطلع على الأحكام، يصدر الوكالات، يقدم الاعتراض إلكترونيًا.

3متى يحتاج إليها المحامي؟

في كل مراحل القضية B04 مراحل التقاضي ودورة حياة القضية.

4ميزات ERPOS المرتبطة بها

ربط الملف B45 ربط الملفات بناجز، المراحل B04 مراحل التقاضي ودورة حياة القضية، الوكالات B07 سجل الوكالات الشرعية، الجلسات B09 الجلسات والتقويم المزدوج ومنع التعارض الزمني، تقارير الجلسات B10 تقارير الجلسات ومخرجاتها، الأحكام والمهل B11 الأحكام وطرق الاعتراض، الإشعارات B28 قارئ الإشعارات الحكومية.

5الخدمة المحددة المطلوبة من المنصة

المصدر: (خطة ناجز ص5-8). دليل المطور يذكر بيئات مختلفة لبعض منتجات الوكالات (Staging) (دليل المطور ص21): تعارض يُحسم من الكتالوج عند التسجيل.

6نوع الحاجة: قراءة أو إرسال أو مزامنة أو إشعارات

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

7البيانات الداخلة والخارجة وحساسيتها ومصدرها

8هل يوجد API رسمي موثق لهذه الخدمة تحديدًا؟

نعم بشروط: المنصة توفر لكل منتج ملفًا تقنيًا (endpoints، أمثلة، Postman، SDK) بعد التسجيل، ومفاتيح لكل تطبيق (خطة ناجز ص3). المسارات والحقول وحدود الاستخدام والرسوم غير معروفة حتى التسجيل، لذلك لا يحتوي هذا التوثيق أي endpoint لناجز. دليل المطور يذكر مفتاح API أو OAuth لكل منتج بحسب الأسئلة الشائعة (دليل المطور ص21) (تعارض مع «مفاتيح لكل تطبيق»).

9المصدر الرسمي وتاريخ التحقق

الدعم بحسب الخطة عبر تذاكر المنصة والبريد المذكور فيها (خطة ناجز ص3).

10حالة التحقق

REQUIRES_APPROVAL

REQUIRES_APPROVAL: المسار الرسمي موجود في المصادر، لكن الوصول يتطلب حساب أعمال معتمدًا وموافقة لكل منتج، وقد يتطلب اتفاقية تبادل بيانات (خطة ناجز ص10-11).

11ما الذي يثبته المصدر الرسمي وما الذي لا يثبته؟

يثبت (بحسب الخطة): وجود منصة مطورين ومنتجات بأسماء وبيئات. لا يثبت: أهلية ERPOS أو المكتب لأي منتج، ولا نموذج الربط المسموح (A أو B)، ولا الرسوم، ولا جواز تحليل الأحكام بالذكاء الاصطناعي (خطة ناجز ص11).

12التسجيل والاعتماد والتفويض والمصادقة وبيئة الاختبار

1. تسجيل حساب قطاع أعمال بالسجل التجاري.
2. مراجعة الوزارة.
3. استكشاف المنتجات وطلب كل منتج.
4. إنشاء تطبيق في بيئة الاختبار ومفتاح.
5. بيانات اختبار عبر تذكرة.
6. تطبيق إنتاجي بمفتاح مختلف بعد الموافقة (خطة ناجز ص10).

نموذجان: (A) حساب لكل مكتب ومفتاحه في موقعه، (B) المنصة مزوّد تقني بمفتاح مركزي. التوصية: بناء الموصل على A بمصدر مفتاح قابل للتبديل، وعدم خلط النموذجين لمكتب واحد (خطة ناجز ص12). تقييم القرارات يميل إلى B (التعارض C-13، OD-06).

13خطوات الربط من جهة ERPOS

1. المرحلة 0 (أعمال): التسجيل والأسئلة الثمانية (خطة ناجز ص11).
2. 1 الهيكل: الإعدادات والسجل وطبقة الاتصال.
3. 2 الرخص.
4. 3 الوكالات.
5. 4 ربط الملفات B45 ربط الملفات بناجز.
6. 5 الأحكام.
7. 6 المحاضر.
8. 7 الإشعارات (خطة ناجز ص15).

14تصميم Adapter مستقل للمنصة

واجهة NajizAdapter مستقلة في legal_erp/integrations/najiz.py ترث النمط الموحد نمط موصل التكامل بعمليات: fetch_case، list_hearings، fetch_minutes، verify_license، verify_poa. تنفيذان: يدوي (يفتح نموذج إدخال للموظف ويسجل المصدر «يدوي») ورسمي (لا يُكتب قبل استلام توثيق رسمي وموافقة)، ويُختار من الإعداد لكل مكتب اقتراح هندسي.

15تدفق البيانات ومخطط التسلسل

لا يصل شيء من ناجز إلى الملف أو المهل إلا عبر طبقة التحقق (سجل الفروق) (خطة ناجز ص13).

16نموذج الطلب والاستجابة

لا نموذج طلب واستجابة لأن الحقول غير منشورة لنا قبل التسجيل. الطلب الداخلي من ERPOS إلى الطابور موثق في B45 ربط الملفات بناجز.

17انتهاء المهلة وانقطاع الخدمة والرفض وتضارب الحالة

• انتهاء المهلة ← فشل مؤقت ← إعادة أسية في الطابور.
• انقطاع الخدمة أو أخطاء متتالية ← إيقاف الموصل وتنبيه المدير B43 طبقة التكامل المركزية.
• رفض (صلاحية، تفويض) ← فشل دائم يظهر للمسؤول بلا إعادة.
• تضارب الحالة مع البيانات المحلية ← سجل فرق يقرره إنسان؛ لا كتابة صامتة ولا حذف محلي عند استجابة فارغة.

18منع التكرار وإعادة المحاولة الآمنة

كل عملية صادرة بمفتاح عدم تكرار يُحفظ مع السجل؛ إعادة المحاولة ترسل المفتاح نفسه، وكل حدث وارد يُتجاهل إن تكرر معرّفه أو بصمته B43 طبقة التكامل المركزية.

19حفظ المصدر ووقت الجلب وإيصال الجهة وسجل التدقيق

يُحفظ مع كل قيمة: data_source (يدوي/الجهة)، وقت الجلب، معرّف الاستدعاء أو رقم الإيصال من الجهة إن وُجد، والمستخدم أو المهمة المجدولة. سجل الاستدعاء لا يحفظ جسم الاستجابة ولا بيانات شخصية (خطة ناجز ص14).

20المسار اليدوي المصرح به

أي استعلام أو تقديم في ناجز لا يمكن أتمتته من ERPOS في الوضع الحالي. الموظف المخوّل ينفذه بنفسه في المنصة الرسمية بحسابه، ثم يسجل النتيجة والمرجع في ERPOS مع إرفاق ما يثبت. لا يُطلب من المحامي كلمة مروره ولا تُستخدم جلسته الشخصية (خطة ناجز ص17).

21اختبارات التكامل والفشل والتفويض والتكرار والعزل

22المخاطر والقرارات التي تحتاج موافقة الجهة

• النموذج A/B (السؤال 1).
• إثبات تخويل المكتب على القضية (السؤال 2).
• اتفاقية تبادل البيانات قد تكون أطول خطوة.
• منتجات Staging.
• الرسوم والحدود وشروط الاستضافة واستخدام الذكاء (خطة ناجز ص11).