> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# إدارة الحالات - الحالات ودورة حياتها

> افتح الحالات الاستقصائية وعالجها وأغلقها في Didit، مرتبطةً بمستخدم أو شركة واحدة، مع العروض المحفوظة وتواريخ استحقاق SLA والإجراءات الجماعية.

إدارة الحالات هي مركز التحقيق في Didit Console. يمكن أن تتحول كل نتيجة AML، وكل عملية تحقق مُعلَّمة، وكل معاملة مشبوهة إلى **حالة** يعمل عليها فريق الامتثال من الفتح حتى الحل، مع سجل تدقيق كامل.

***

## دورة الحياة

تمرّ الحالة عبر ثلاث حالات بالضبط:

| الحالة | المعنى |
| - | - |
| `Open` | قيد التحقيق النشط |
| `Awaiting user` | متوقفة مؤقتًا بينما تُجمع مزيد من المعلومات من المستخدم الموثَّق |
| `Resolved` | اكتمل التحقيق مع تسجيل الحل |

يتطلب حلّ الحالة تحديد حل:

| الحل | المعنى |
| - | - |
| `False positive` | كان النشاط مشروعًا |
| `Valid threat` | تأكّد وجود نشاط مشبوه أو احتيالي |

تحمل كل حالة أيضًا **الأولوية** (`Low` و`Medium` و`High`، والافتراضي هو `Medium`) و**تاريخ استحقاق** اختياري، وهو ما يُستخدم للترتيب وفق SLA ومؤشرات التأخير.

> [!NOTE]
>
> لا توجد حالات `Under review` أو `On hold` أو `Pending approval`، ولا مستوى خطورة `Critical`، ولا محور لنوع الحالة. دورة الحياة ثابتة عن قصد لتبقى التحليلات واتفاقيات SLA والأذونات واضحة لكل حالة، بغض النظر عن طريقة إنشائها.

## طرف واحد لكل حالة

ترتبط كل حالة بـ**طرف واحد فقط**، أي بمستخدم واحد أو شركة واحدة. لا يمكنك خلط أطراف مختلفة في حالة واحدة، ولا يمكنك إرفاق جلسة أو جلسة شركة أو معاملة تنتمي إلى طرف غير طرف الحالة، وإذا حاولت ذلك يُعاد خطأ واضح.

هذا يُبقي كل صفحة حالة مركّزة: فبطاقة الطرف ونظرة عامة على المخاطر والمستندات والبيانات المالية تصف كلها الشخص أو الشركة نفسها التي تحقق فيها الحالة. لمراجعة كيان ثانٍ، افتح حالة منفصلة أو أنشئ واحدة.

## سياق المصدر في Fraud Check

عند إنشاء حالة من جلسة Fraud Check، يُحفظ معرّف الفحص ومعرّف الطلب والقسم الذي فتحه المراجِع.
كما تسجّل بطاقة المصدر حالة المحلل في الجلسة وقت إنشاء الحالة.
يبقى قرار الحالة وقرار المصدر منفصلين.

يمكن لعملاء API تمرير `source_context` مع `check_id` و`request_id` و`source_section` عند إنشاء حالة.
أضف هذا الطلب كعنصر `session` في `links`.
يجب أن ينتمي الفحص والجلسة المرتبطة به إلى التطبيق المحدد، وأن يكونا مرتبطين بعضهما ببعض.
تقرأ الواجهة البرمجية حالة المحلل بنفسها، وترفض في هذا السياق الحقول التي يرسلها المستدعي لحالة أو توصية أو نوع مصدر.

## القوائم

تُبقي إدارة الحالات **الحالات** و**نظرة عامة** و**التعيين** متاحة في شريط التنقل العلوي.
تتيح مساحة عمل الحالات عروض الحالة **فتح** و**في انتظار المستخدم** و**محلولة** و**الكل**.
عند فتح حالة، تبقى قائمة الحالات بجانب تفاصيلها على سطح المكتب.
على الهاتف، استخدم مسار التنقل للعودة إلى القائمة.

يطابق البحث اسم الطرف أو معرّفه، والوسم، ورقم الحالة، وعنوانها، ومعرّف الجلسة المرتبطة، ومعرّف المعاملة المرتبطة، لذا يمكنك لصق UUID لجلسة أو معاملة والوصول مباشرة إلى حالتها.

رقائق التصفية: **المخطط** و**تاريخ الإنشاء** و**المصدر** و**المكلف** و**العلامة**، إضافة إلى **إضافة عامل تصفية** لـ**الأولوية** و**الاستحقاق**.

الأعمدة: تاريخ الإنشاء (التاريخ والمنشئ)، وتفاصيل الحالة (العنوان)، والحالة، والمخطط، والطرف (الاسم والمعرّف)، ووسوم الطرف، والمكلف، والأولوية، وتاريخ الاستحقاق، وتتوفر أعمدة أخرى عبر التمرير الأفقي وإعداد الأعمدة.

### الترتيب و SLA

رتّب حسب **تاريخ الإنشاء** (الافتراضي) أو **تاريخ الاستحقاق**. يؤدي الترتيب حسب تاريخ الاستحقاق إلى عرض الحالات المتأخرة أولًا. تُعد الحالة متأخرة بعد انقضاء تاريخ استحقاقها وهي ما تزال **مفتوحة** أو **في انتظار المستخدم**، وتظهر برقاقة استحقاق حمراء.

### العروض المحفوظة

احفظ المجموعة الحالية من عوامل التصفية والأعمدة كعرض مسمّى باستخدام **حفظ العرض**، وبدّل بين العروض باستخدام **اختر عرضًا**، وأعد الضبط باستخدام **مسح عوامل التصفية**. العروض شخصية، وتُحفظ بالطريقة نفسها التي تُحفظ بها تفضيلات الجداول الأخرى في وحدة التحكم.

### الإجراءات الجماعية

حدّد عدة حالات من أجل:

* **إسناد إلى** مسؤول. يجب أن تشترك جميع الحالات المحددة في المخطط نفسه، وتحذّر وحدة التحكم قبل الإرسال إذا لم تكن كذلك.
* **تعيين الحالة** إلى في انتظار المستخدم، أو إعادة الفتح، أو الحل (مع تحديد حل وملاحظة اختيارية). يُقيَّم كل حالة بشكل مستقل، فتُبلَّغ الحالة المتوقفة بسبب قائمة تحقق غير مكتملة أو ملاحظة إلزامية مفقودة بشكل فردي، دون أن يفشل باقي الدفعة.

### عمليات التصدير

تتيح قائمة الخيارات تصديرين بصيغة CSV، يُسلَّمان عبر [صفحة التقارير](https://docs.didit.me/ar/console/export-pdf-csv.md):

* **تقرير جميع الحالات**، بصف واحد لكل حالة يتضمن الحالة والحل والأولوية والوسوم والمعاملات المرتبطة وآخر تقرير FIU مُقدَّم.
* **تقرير SLA**، ويتضمن مقاييس التوقيت لكل حالة: الساعات حتى التعيين، والساعات حتى الحل، ومؤشرات التأخير، ومؤشرات استيفاء SLA.

## إجراءات الطرف وإعادة المحاولات

تتيح بطاقة الطرف للمراجعين المصرّح لهم تغيير حالة الطرف، وإضافة وسوم، وإضافة ملاحظة داخلية، أو إضافة الطرف إلى قائمة الحظر.
هذه الإجراءات منفصلة عن حل الحالة.
يسجّل قسم **إجراءات على الطرف** كل إجراء مطلوب باعتباره **مطبَّقًا** أو **فاشلًا**، ويحدد المراجِع والوقت.
استخدم **إعادة محاولة الإجراء** لإعادة محاولة إجراء فاشل بعد مراجعة الطرف الحالي.
لا يُنفَّذ الإجراء الذي تم تطبيقه مرة أخرى عند إعادة محاولة طلبه.

ينبغي لعملاء API إرسال `client_reference` فريد مع كل طلب إلى endpoint ‏`entity-actions/` الخاص بالحالة.
احتفظ بالمرجع نفسه والمدخلات نفسها عند إعادة محاولة طلب بعد خطأ في الاتصال.
تؤدي المدخلات المتغيرة مع المرجع نفسه إلى إرجاع `409`.
عند تمرير مرجع، افحص `receipt.status`: قد تحتوي استجابة `200` على إيصال فاشل، أي أن الإجراء لم يُطبَّق.
تتطلب إعادة محاولة طلب فاشل `retry: true`، أو استدعاء endpoint ‏`action-receipts/{receipt_uuid}/retry/` الخاص به.
يعيد endpoint السجل 20 إيصالًا كحد أقصى في كل صفحة، ويوفّر `next_offset` للحصول على نتائج إضافية.
يحتفظ عملاء API الحاليون الذين لا يرسلون `client_reference` بسلوك الاستجابة السابق.

## الوسوم

أضف وسومًا إلى حالة من رأسها (**إضافة وسم**) لتجميع التحقيقات المرتبطة، أو صفِّ القائمة وابحث فيها حسب الوسم. تُسجَّل تغييرات الوسوم في الخط الزمني للحالة.

## الصفحات ذات الصلة

> [card] [إنشاء الحالات](https://docs.didit.me/ar/console/case-management/creating-cases.md)
>
> كل نقاط الدخول: المستخدمون والشركات والجلسات والمعاملات والموصّلات التلقائية.

> [card] [المخططات](https://docs.didit.me/ar/console/case-management/blueprints.md)
>
> اضبط الإسناد والتصعيد والتحويل ومحتوى صفحة الحالة.

> [card] [قائمة التحقق](https://docs.didit.me/ar/console/case-management/checklist.md)
>
> اشترط إتمام خطوات التحقيق المطلوبة قبل الحل.

> [card] [المراجعة بأربع أعين](https://docs.didit.me/ar/console/case-management/four-eyes.md)
>
> اعتماد من المُنشئ والمُدقِّق للحلول الحساسة.

## رسائل العميل

استخدم **مراسلة العميل** لمعاينة طلب ثابت أو تحديث مراجعة لجهة اتصال موثّقة.
راجع [رسائل العميل](https://docs.didit.me/ar/console/case-management/customer-messages.md) لمعرفة حالات التسليم والردود الآمنة وسير عمل API.

## النقاش والملاحظات المثبّتة

افتح زر النقاش بجوار حالة الحالة لمراجعة الملاحظات مع البقاء ضمن التحقيق.
استخدم قائمة الملاحظة للرد عليها أو تثبيتها.
تظهر الملاحظات المثبّتة أولاً، وتعرض الردود مقتطفاً قصيراً من الملاحظة الأصلية.
تُسجَّل تغييرات التثبيت في نشاط الحالة ولا تغيّر قرارات المصدر.

يؤدي تأكيد الحذف إلى إزالة الملاحظة نهائياً، وكذلك مقتطفها المقتبس من الردود.
أما الردود نفسها فتبقى متاحة.
تُحذف المرفقات ما لم تكن ملاحظة أخرى ما زالت تستخدمها.

يمكن لعملاء API تمرير معرّف `client_reference` من نوع UUID عند إضافة ملاحظة.
تؤدي إعادة المحاولة بنفس المحتوى دون تغيير إلى إرجاع الملاحظة الموجودة دون تكرار الإشعارات.
أما إعادة استخدام هذا المعرّف لمحتوى مختلف أو لملاحظة محذوفة فيُرجع `409`.
مرّر `reply_to` للإشارة إلى ملاحظة نشطة في الحالة نفسها، وحدّث `is_pinned` عبر نقطة النهاية `PATCH` الخاصة بالملاحظة.

## التحقق من وجود تحقيق سابق

تتحقق نافذة إنشاء الحالة المشتركة من وجود تحقيقات سابقة للمستخدم أو الشركة أو المصدر المرتبط المحدد.
افتح الحالة الموجودة لمتابعة مراجعتها.
تبقى الحالات المغلقة ظاهرة حتى تتمكن من فتحها وتقرير ما إذا كنت ستعيد فتحها.
لإنشاء تحقيق منفصل، أدخل سبباً يوضح أن الواقعة تُعامل كحادثة مختلفة.
يُحفظ السبب مع الحالة الجديدة ويظهر في نظرة عامة عليها.
تعيد وحدة التحكم فحص التكرار عند الإرسال، بما في ذلك الحالات التي أنشأها مراجع آخر أثناء بقاء النافذة مفتوحة.

يمكن لتكاملات API استدعاء `POST .../cases/duplicates/` وضبط `review_duplicates=true` عند إنشاء الحالة.
عند العثور على تحقيق موجود، يُرجع الإنشاء `409` ما لم يُرسَل `separate_incident_reason`.
تُرجع نقطة نهاية مراجعة التكرار ما يصل إلى 20 حالة في كل صفحة، مع `next_offset` للحصول على نتائج إضافية.
تحافظ تكاملات API الحالية التي لا تضبط هذا الخيار على سلوك الإنشاء الحالي.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.