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

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

---

​

دورة الحياة

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

​

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

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

​

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

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

​

القوائم

تُبقي إدارة الحالات الحالات ونظرة عامة والتعيين متاحة في شريط التنقل العلوي. تتيح مساحة عمل الحالات عروض الحالة فتح وفي انتظار المستخدم ومحلولة والكل. عند فتح حالة، تبقى قائمة الحالات بجانب تفاصيلها على سطح المكتب. على الهاتف، استخدم مسار التنقل للعودة إلى القائمة. يطابق البحث اسم الطرف أو معرّفه، والوسم، ورقم الحالة، وعنوانها، ومعرّف الجلسة المرتبطة، ومعرّف المعاملة المرتبطة، لذا يمكنك لصق UUID لجلسة أو معاملة والوصول مباشرة إلى حالتها. رقائق التصفية: المخطط وتاريخ الإنشاء والمصدر والمكلف والعلامة، إضافة إلى إضافة عامل تصفية لـالأولوية والاستحقاق. الأعمدة: تاريخ الإنشاء (التاريخ والمنشئ)، وتفاصيل الحالة (العنوان)، والحالة، والمخطط، والطرف (الاسم والمعرّف)، ووسوم الطرف، والمكلف، والأولوية، وتاريخ الاستحقاق، وتتوفر أعمدة أخرى عبر التمرير الأفقي وإعداد الأعمدة.

​

الترتيب و SLA

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

​

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

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

​

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

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

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

​

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

تتيح قائمة الخيارات تصديرين بصيغة CSV، يُسلَّمان عبر صفحة التقارير:

• تقرير جميع الحالات، بصف واحد لكل حالة يتضمن الحالة والحل والأولوية والوسوم والمعاملات المرتبطة وآخر تقرير 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 بسلوك الاستجابة السابق.

​

الوسوم

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

​

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

​

رسائل العميل

استخدم مراسلة العميل لمعاينة طلب ثابت أو تحديث مراجعة لجهة اتصال موثّقة. راجع رسائل العميل لمعرفة حالات التسليم والردود الآمنة وسير عمل 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 الحالية التي لا تضبط هذا الخيار على سلوك الإنشاء الحالي.