الرئيسية›فهرس المنصات›نافذ — منصة السندات التنفيذية

نافذ — منصة السندات التنفيذيةNafith (enforceable instruments)

MANUAL_ONLYمنصة نافذ (الجهة المالكة غير مذكورة في صفحتها الرئيسية)متطلب وارد في الملفات يحتاج تحققًا أو موافقة رسمية

«نافذ» منصة السندات التنفيذية. يذكر الدليل أن عقد الأتعاب الموحد المسجل في خدمة العقود فيها يكتسب صفة السند التنفيذي ويُنفذ عبر محاكم التنفيذ دون دعوى (دليل المطور ص35). ليست «نفاذ» (الهوية الرقمية).

تنبيه

«نافذ» (Nafith) ≠ «نفاذ» (Nafath). الأولى للسندات التنفيذية، والثانية للهوية الوطنية الرقمية نفاذ — النفاذ الوطني الموحد.

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

منصة لتوثيق السندات التنفيذية الإلكترونية. يذكر الدليل إطلاق عقد الأتعاب الموحد في 4 مايو 2025، وأن التسجيل غير إلزامي حاليًا مع تفضيل الهيئة السعودية للمحامين (دليل المطور ص35) يحتاج تحققًا أو موافقة رسمية.

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

يسجل عقد الأتعاب الموحد بنفسه في المنصة.

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

عند رغبة المكتب في أن يكون عقد الأتعاب سندًا تنفيذيًا.

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

B22 العقود الإلكترونية واتفاقيات الأتعاب والتوقيع العقود؛ B04 مراحل التقاضي ودورة حياة القضية مسار التنفيذ.

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

خدمة العقود (عقد الأتعاب الموحد).

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

لا أتمتة: ERPOS يجهز البيانات بترتيب العقد الموحد ويسجل المرجع والحالة يدويًا.

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

بيانات العقد: الأطراف، النطاق، الأتعاب، الدفعات. حساسية عالية.

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

يذكر الدليل: «لا API عامًا معروفًا لنافذ» (دليل المطور ص35). لم نجد في الملفات ولا في المصادر التي رُوجعت واجهة برمجية رسمية موثقة لهذه الخدمة تحديدًا: غير مثبت في المصادر التي تمت مراجعتها. لا نكتب endpoints أو حقولًا.

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

المصدر	الرابط	ما تحقّقنا منه	تاريخ التحقق
نافذ	https://www.nafith.sa	تفتح: «إدارة السندات والعقود التنفيذية»، وتذكر الربط المباشر مع نظام التنفيذ في وزارة العدل، والتحقق عبر النفاذ الوطني الموحد، وحسابات شركات وأفراد. لا توثيق API ظاهر في الصفحة الرئيسية، ولا تذكر الصفحة الجهة المالكة	2026-11-04

10حالة التحقق

MANUAL_ONLY

MANUAL_ONLY.

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

الدليل ينقل عن مصادر صحفية؛ تفاصيل الخدمة وشروطها تُراجع من المنصة نفسها قبل الاعتماد يحتاج تحققًا أو موافقة رسمية.

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

بحساب المحامي أو المكتب في المنصة نفسها؛ خارج ERPOS.

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

زر «تجهيز لنافذ» يصدّر ملخص العقد بترتيب الحقول.
المحامي يسجل في نافذ.
يدخل المرجع والحالة في nafith_ref وnafith_status.

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

واجهة NafithAdapter مستقلة في legal_erp/integrations/nafith.py ترث النمط الموحد نمط موصل التكامل بعمليات: prepare_unified_contract، record_reference. تنفيذان: يدوي (يفتح نموذج إدخال للموظف ويسجل المصدر «يدوي») ورسمي (لا يُكتب قبل استلام توثيق رسمي وموافقة)، ويُختار من الإعداد لكل مكتب اقتراح هندسي.

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

مخطط تسلسل من جهة ERPOS؛ لا يمثّل واجهة حكومية موثقة ما لم يُذكر ذلك صراحة.

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

لا يوجد (يدوي).

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

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

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

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

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

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

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

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

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

المعرّف	النوع	السيناريو	النتيجة المتوقعة
`INT-NFT-01`	تكامل	بيئة وهمية تعيد نجاحًا	تُحفظ القيمة بمصدرها ووقتها.
`INT-NFT-02`	فشل	مهلة ثم نجاح	إعادة واحدة بلا تكرار.
`INT-NFT-03`	تفويض	مفتاح أو تفويض غير صالح	فشل دائم وتنبيه، لا إعادة.
`INT-NFT-04`	تكرار	إرسال الحدث نفسه مرتين	يُعالج مرة.
`INT-NFT-05`	عزل	مكتبان على الخادم نفسه	لا يرى أحدهما بيانات الآخر ولا مفتاحه.

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

تغير الخدمة أو إلزاميتها؛ يُراجع دوريًا يحتاج تحققًا أو موافقة رسمية.