للحصول على حالة معالجة طلب لتنزيل حالة مسودة عقد e-MTPL ، يشير CIS CK إلى خدمة ProjectPolicyService للنظام ، طريقة getSetStatusResult ، ويستخدم مخطط StatusPolicyEOSAGOStatusRequest.xsd للطلب.
يتم توفير تكوين الطلب المقابل للنظام المحدد في الملحق 3 "مواصفات تنسيقات التفاعل" من هذا الدليل.
عند طلب حالة معالجة طلب تحميل حالة مسودة اتفاقية e-CMTPL ، ينبغي مراعاة الجوانب التالية:
5.8.1. يحتوي طلب حالة معالجة طلب تحميل مسودة اتفاقية e-CMTPL على معرف الإدخال في قائمة الانتظار لمعالجة حالات مسودات الاتفاقيات ، التي تم إنشاؤها بعد التحميل الناجح للطلب لتعيين الحالة إلى المسودة اتفاقية e-CMTPL في النظام (وفقًا للفقرة 5.7 من هذا الدليل).
5.8.2. عند إرسال الحالة "ملغاة" إلى مسودة اتفاقية e-CMTPL وإذا طلب تحميل حالة مسودة اتفاقية e-CMTPL لقواعد FLC المعمول بها ، فإن النظام الفرعي "السياسة الإلكترونية" يولد استجابة IC مع إشعار بنجاح التنازل عن اتفاقية CMTPL الإلكترونية لمسودة الاتفاقية.
5.8.3. يتم تكوين رسالة استجابة SC وفقًا لمخطط StatusPolicyEOSAGOStatusResponse.xsd ، والذي تم تقديم تكوينه في الملحق 3 "مواصفات تنسيقات التفاعل" لهذا الدليل.
5.8.4. عند إرسال مسودة اتفاقية e-MTPL بالحالة "صالحة" وفي حالة المعالجة الناجحة لطلب تنزيل حالة مسودة الاتفاقية في النظام ، يرسل النظام الفرعي "السياسة الإلكترونية" طلبًا لتنزيل بيانات هذه المسودة الموافقة على DCMC من خلال خدمة تنزيل اتفاقيات / خسائر OSAGO DCBM.
5.8.5. بعد تلقي رد حول حالة معالجة اتفاقية e-CMTPL من DCBM ، يقوم النظام بإنشاء استجابة لـ IC ، تحتوي على جميع المعلومات حول نتائج معالجة اتفاقية CMTPL الإلكترونية في DCBM.
5.8.6. في حالة المعالجة الناجحة للعقد في MCBM ، يقوم النظام الفرعي "السياسة الإلكترونية" بإنشاء استجابة من IC برسالة حول التخصيص الناجح للحالة "نشطة" لمشروع عقد e-MTPL.
5.8.7. إذا لم تجتز اتفاقية e-CMTPL فحوصات FLC DCBM ولم يتم حفظها في DCBM ، فوفقًا للمسودة المقابلة لاتفاقية e-CMTPL ، فإن النظام الفرعي "السياسة الإلكترونية" يولد استجابة من IC مع رسالة تفيد بأن الحالة "صالحة" لم يتم تعيينها (في علامة IsStatusAssign ستعيد خطأ) ، وقائمة بالأخطاء من DCBM.
5.8.8. في حالة حدوث أخطاء أثناء معالجة الطلب ، يقوم النظام بإنشاء استجابة لـ CK بقائمة بأخطاء التحقق من صحة الطلب المكتشفة ، والتي يتم إرسالها في علامة ErrorList لرسالة استجابة CK. ترد رموز الأخطاء ووصفها وسلوك النظام عند الاستلام في الملحق 1 "أخطاء التحقق من الصحة" من هذا المستند.
5.8.9. يتم سرد أخطاء التحقق من الصحة التي حدثت أثناء معالجة طلب في DCSM في علامة ErorrDKBMList لرسالة استجابة SC. وترد رموز هذه الأخطاء ووصفها في وثيقة "عقود دليل مشغل النظام الفرعي و MSC AIS RSA".
5.8.10. ترد قائمة حالات معالجة الطلب في الملحق 2 "حالات الطلب" من هذا المستند.
طلب عدد الغرف المجانية لمشروع عقود e-MTPL
لإنشاء طلب لعدد من الأرقام المجانية لمسودات عقود e-MTPL ، يشير CIS CK إلى خدمة ProjectPolicyCountService ، طريقة getFreeNumbers ؛ ويستخدم مخطط NumberFreeRequest.xsd للطلب.
عند إرسال طلب للحصول على عدد أرقام SK المجانية الخاصة بمسودة عقود e-CMTPL ، يجب مراعاة الجوانب التالية:
5.9.1. يتم تخصيص الحد الأقصى لعدد مسودات اتفاقيات e-CMTPL ، المتاحة لتشكيل مسودة اتفاقيات e-CMTPL ، في PCA وإدخالها في الجدول المقابل لـ e-CMTPL DB بواسطة مسؤول PCA في بداية الفترة لكل IC.
5.9.2. يوفر النظام خوارزمية داخلية لحساب عدد الأرقام المجانية لكل شركة تأمين ، والتي تتمثل في تحديد الفرق بين عدد مسودات اتفاقيات MTPL الإلكترونية لبداية الفترة وعدد الأرقام المستهلكة من المسودة e. - اتفاقيات MTPL لكل شركة تأمين.
5.9.3. إذا تم حفظ مسودة الاتفاقية بنجاح في النظام ، فإن عدد الأرقام المستهلكة من IC التي أرسلت طلبًا لتنزيل مسودة اتفاقية e-OSAGO تزداد بمقدار واحد.
5.9.4. عند تعيين الحالة "ملغاة" لمسودة اتفاقية e-CMTPL ، يتم تقليل عدد أرقام SK المستخدمة بمقدار واحد.
5.9.5. يتم تشكيل الرد على طلب عدد الأرقام المجانية لشركة التأمين وفقًا لنظام NumberFreeResponse.xsd ، والذي تم تقديم تكوينه في الملحق 3 "مواصفات تنسيقات التفاعل" لهذا الدليل ، ويحتوي على عدد التطبيقات المجانية أرقام عقود e-CMTPL وقت تقديم الطلب لشركة التأمين التي أرسلت الطلب.
5.9.6. لا ينص النظام على إمكانية إعادة استخدام الأرقام التي تم تخصيصها مسبقًا لمسودة اتفاقيات CMTPL الإلكترونية.
طلب قائمة بأرقام مشاريع اتفاقيات OSAGO الإلكترونية
لإنشاء طلب للحصول على قائمة بأرقام مسودات اتفاقيات e-CMTPL التي لم يتم تخصيص حالة مقابلة لها سابقًا ، تشير CIS IC إلى خدمة ProjectPolicyListService ، طريقة getList ؛ يتم استخدام مخطط ListPolicyEOSAGORequest.xsd للطلب.
يتم توفير تكوين الطلب في الملحق 3 "مواصفات تنسيقات التفاعل" من هذا الدليل.
عند طلب قائمة بأرقام مسودات اتفاقيات e-CMTPL بدون حالات ، يجب مراعاة الجوانب التالية:
5.10.1. بعد معالجة الطلب ، يُنشئ النظام الفرعي "السياسة الإلكترونية" استجابة من IC تحتوي على قائمة بأرقام مسودات اتفاقيات e-CMTPL التي ليس لها الحالة "صالحة" أو "ملغاة" في وقت الطلب والتي كانت تم تحميله مسبقًا بواسطة IC الذي أرسل الطلب.
5.10.2. يتم تشكيل رسالة استجابة SC وفقًا لمخطط ListPolicyEOSAGOResponse.xsd ، والذي تم تقديم تكوينه في الملحق 3 "مواصفات تنسيقات التفاعل" لهذا الدليل.
تحديد الكائن
ترد قواعد تحديد الكائنات في النظام في الجدول 4.
الجدول 4 قواعد تحديد الكائن
| شيء | تحديد التفاصيل | عناصر XML |
| مشروع اتفاقية e-OSAGO | كود CK + معرف عقد CK | معرف المؤمن + معرف المسودة |
| الكيان الفردي (حامل الوثيقة ، مالك السيارة) | HASH (الاسم الكامل + تاريخ الميلاد) + نوع المستند + سلسلة المستندات + رقم المستند | PersonNameBirthHash + DocPerson + الرقم التسلسلي |
| الشخص الطبيعي الموضوع - LDU | HASH (الاسم الكامل + تاريخ الميلاد) + سلسلة VU + رقم VU + نوع المستند | PersonNameBirthHash + Serial + Number + (DocPerson = 20) |
| الكيان القانوني (المؤمن عليه ومالك السيارة) | للمواضيع - سكان الاتحاد الروسي: "INN" للمواضيع - غير المقيمين في الاتحاد الروسي: "الاسم الكامل" (وفقًا لشهادة التسجيل (في نموذج مفتوح غير مجزأ) | للمقيمين في الاتحاد الروسي: الأسماء الدولية غير المقيمين في الاتحاد الروسي: OrgName |
| وثيقة الموضوع | نوع المستند + سلسلة المستندات + رقم المستند | DocPerson + المسلسل + الرقم |
| مركبة | يتم توفير تعريف السيارة من خلال الجمع بين قيمة حقل "بلد تسجيل السيارة" وحقول إحدى الطرق التالية: 1) يتم تحديد المعرف من خلال قيمة أحد التفاصيل التالية أو مجموعتها (إذا تم ملء العديد منها ):
| البلد السيارة 1) VIN الجسم رقم الهيكل رقم 2) الترخيص |
إجراء الشيكات
يتم إجراء الفحوصات الفنية عند استلام طلب من النظام الفرعي "السياسة الإلكترونية" ، عند التحقق من الامتثال لمخططات xsd. يتم توفير بنية مخططات xsd للنظام في الملحق 3 "مواصفات تنسيقات التفاعل" بهذا الدليل.
بعد التحقق الأولي من الطلبات المقدمة للامتثال لمخططات xsd ، يتم إجراء فحص منطقي للطلبات المقدمة ، بما في ذلك التحقق من ملء سمات الطلب اعتمادًا على قيمة السمات الأخرى.
وفقًا لمنطق التحقق من الصحة ، يتم إجراء الفحوصات الأولى للعناصر الأصلية ، ثم إذا كان هناك عنصر أصلي ، يتم إجراء الفحوصات لأبنائه ، لذلك إذا تم تحديد عنصر اختياري للعنصر الأصل في الخصائص ، وإلزامي لعنصره الأطفال ، إذا لم يكن هناك عنصر أصل في الملف ، فسيتم اعتبار الاختبار ناجحًا.
يقوم النظام بتنفيذ القدرة على تكوين تعطيل عمليات الفحص التي تم إجراؤها ، والتي بدأها PCA ، بما في ذلك النظام الفرعي "السياسة الإلكترونية" الذي يوفر القدرة على تعطيل عمليات فحص FLC بشكل شامل عند تحميل مسودة عقد e-OSAGO.
إذا تم تعطيل الفحص ، فسيستمر إجراء الفحص ، ولكن في حالة تلقي خطأ في هذا الفحص ، تظل مسودة اتفاقية e-MTPL محفوظة في قاعدة بيانات النظام الفرعي "السياسة الإلكترونية". استجابة لطلب الحالة ، ستتلقى المملكة المتحدة رسالة حول ما إذا كان قد تم حفظ مسودة الاتفاقية في قاعدة البيانات وقائمة بأخطاء التحقق من الصحة.
قائمة كاملة بأخطاء التحقق من الصحة ، بالإضافة إلى إجراءات النظام مع الشيكات المعطلة ، موجودة في الملحق 1 "أخطاء التحقق من الصحة". يحتوي الملحق 2 "حالات الطلب" على قائمة بحالات الطلب للنظام الفرعي "السياسة الإلكترونية".
الجدول 5 طلب التحقق من بيانات الشخص المعني - حامل وثيقة التأمين ، مالك السيارة (المؤمن المالك ، طلب ، xsd)
| العنصر الأصل | الاسم المنطقي | تحقق منطقي | |
| المؤمِّن المالك الطلب | المؤمِّن المالك طلب القيمة | التحقق من بيانات الموضوع (حامل الوثيقة / مالك السيارة) | مطلوب لملء. |
| المؤمِّن المالك طلب القيمة | معرف المؤمن | ||
| PhysicalPersonInfoRequest | البيانات الفردية للتحقق | مطلوب أحد العنصرين. | |
| JuridicalPersonInfoRequest | بيانات الكيان القانوني للتحقق منها | ||
| DateRequest | تاريخ + وقت الطلب | مطلوب لملء. | |
| PhysicalPersonInfoRequest | دولة | رمز الدولة في OKSM | مطلوب لملء. |
| بيرسونامبيرثهاش | تجزئة الاسم الكامل + تاريخ الميلاد | مطلوب لملء. | |
| الشخصالمستند | نوع وسلسلة ورقم وثيقة الهوية | مطلوب لملء. | |
| العنوان | |||
| الشخصالمستند | DocPerson | نوع وثيقة الهوية | مطلوب لملء. التحقق من الامتثال للرموز من دليل "أنواع المستندات". |
| مسلسل | سلسلة من الوثائق | مطلوب ، إذا كان متاحًا. عند التعبئة - تحقق من عدم وجود أحرف غير صالحة. | |
| عدد | رقم المستند | ||
| JuridicalPersonInfoRequest | دولة | رمز الدولة في OKSM | مطلوب لملء. |
| معرف المنظمة | الاسم الكامل (وفقًا لشهادة التسجيل) + TIN (للمقيمين في الاتحاد الروسي) | مطلوب لملء. | |
| العنوان | العنوان - رمز من دليل RSA-KLADR | مطلوب لملء. التحقق من الامتثال للرموز من الكتاب المرجعي KLADR | |
| معرف المنظمة | مقيم | علامة RF / non RF | مطلوب لملء. |
| خمارة | رقم التعريف الضريبي للكيان القانوني | إلزامي لسكان الاتحاد الروسي. | |
| اسم OrgName | الاسم الكامل للكيان القانوني (حسب شهادة التسجيل) | مطلوب لملء. |
| العنصر الأصل | سمة العنصر الأصل | الاسم المنطقي | تحقق منطقي |
| السائقطلب | DriverRequestValue | فحص بيانات LDU | مطلوب لملء. |
| DriverRequestValue | معرف المؤمن | رقم تعريف شركة التأمين | مطلوب لملء. التحقق من الامتثال للأكواد من دليل "شركات التأمين". التحقق من التوافق مع معرف SK المحدد في رأس الرسالة. |
| DriverInfoRequest | بيانات LDU للتحقق | مطلوب لملء. | |
| DateRequest | تاريخ + وقت الطلب | مطلوب لملء. | |
| DriverInfoRequest | |||
| بيرسونامبيرثهاش | تجزئة الاسم الكامل + تاريخ الميلاد | مطلوب لملء. | |
| DriverDocument | سلسلة رخصة القيادة ورقمها | مطلوب لملء. | |
| الفئات سائق رخصة | فئات المركبات المسموح بها لرخصة القيادة | ||
| DriverDocDate | تاريخ إصدار أول رخصة قيادة | مطلوب لملء. يتم فحص هذا الحقل بدقة تصل إلى عام. | |
| DriverDocument | مسلسل | سلسلة من الوثائق | مطلوب ، إذا كان متاحًا. عند التعبئة - تحقق من عدم وجود أحرف غير صالحة. |
| عدد | رقم المستند | مطلوب لملء. التحقق من عدم وجود أحرف غير صالحة. | |
| الفئات سائق رخصة | CatDriverLicense | فئة المركبة حسب VU | مطلوب لملء. حدد رمز فئة السيارة من الكتاب المرجعي لتعديلات الطراز. يتم تعطيل الاختيار حتى تنفيذ المراجعة المقابلة لـ DMCS. |
| العنصر الأصل | سمة العنصر الأصل | الاسم المنطقي | تحقق منطقي |
| طلب TS | TSRequestValue | فحص بيانات المركبة | مطلوب لملء. |
| TSRequestValue | معرف المؤمن | رقم تعريف شركة التأمين | مطلوب لملء. التحقق من الامتثال للأكواد من دليل "شركات التأمين". التحقق من التوافق مع معرف SK المحدد في رأس الرسالة. |
| TSInfoRequest | بيانات المركبة للتحقق منها | مطلوب لملء. | |
| DateRequest | تاريخ + وقت الطلب | مطلوب لملء. | |
| TSInfoRequest | البلد | بلد تسجيل السيارة | مطلوب لملء. التحقق من التوافق مع القيمتين "0" و "1" (1 - RF ؛ 0 - ليس RF) |
| معرف السيارة | معرفات السيارة | مطلوب لملء. | |
| MarkModelCarRSACode | رمز العلامة التجارية النموذجي من كتيب PCA | مطلوب لملء. التحقق من التوافق مع القيم من الكتاب المرجعي "تعديلات النموذج". إذا لم يكن النموذج المطلوب موجودًا في الكتاب المرجعي ، فيجب إرسال رمز إدخال الرمز المرجعي ، والذي يبدأ اسمه بكلمات "طراز آخر" والذي يتوافق مع الفئة المطلوبة ونوع السيارة | |
| السنة | سنة الصنع | إلزامي للتعبئة ، باستثناء المركبات المسجلة في الدول الأجنبية. | |
| النوعسيارة | نوع السيارة | إلزامي للتعبئة ، باستثناء المركبات المسجلة في الدول الأجنبية. يشار إلى رمز نوع السيارة من الكتاب المرجعي "تعديلات الطراز". | |
| كاتكار | فئة السيارة | إلزامي للتعبئة ، إذا تم ملء رمز فئة السيارة في كتاب مرجع PCA "تعديلات الطراز" ، باستثناء المركبات المسجلة في دول أجنبية. حدد رمز فئة السيارة من الكتاب المرجعي لتعديلات الطراز. إذا لم يتم ملء رمز فئة السيارة في مرجع RSA "تعديلات الطراز" ، فلن يتم ملء علامة CatCar عند فحص السيارة. | |
| DocumentCar | وثيقة نوع المركبة | إلزامي للتعبئة ، باستثناء المركبات المسجلة في الدول الأجنبية. التحقق من الامتثال للرموز من دليل "أنواع المستندات". | |
| DocCarSerial | سلسلة وثائق TS | ||
| DocCarNumber | رقم وثيقة المركبة | إلزامي للتعبئة ، باستثناء المركبات المسجلة في الدول الأجنبية. التحقق من عدم وجود أحرف غير صالحة. | |
| تاريخ الوثيقة | تاريخ إصدار وثيقة المركبة | إلزامي للتعبئة ، باستثناء المركبات المسجلة في الدول الأجنبية. يتم تعطيل الاختيار حتى تنفيذ المراجعة المقابلة لـ DMCS. | |
| إنج كاب | قوة المحرك للفئة B ، h.p. | إلزامي لـ CatCar = "B" ، باستثناء المركبات المسجلة في دول أجنبية. | |
| ماكس ماس | الكتلة القصوى المسموح بها بالكيلوجرام للفئة ج | إلزامي لـ CatCar = "C" ، باستثناء المركبات المسجلة في بلدان أجنبية. | |
| غير محملة | الوزن الصافي بالكيلوجرام للفئة ج | إلزامي لـ CatCar = "C" ، باستثناء المركبات المسجلة في بلدان أجنبية. يتم تعطيل الاختيار حتى تنفيذ المراجعة المقابلة لـ DMCS. | |
| باسكوانت | عدد مقاعد الركاب للفئة د | إلزامي لـ CatCar = "D" ، باستثناء المركبات المسجلة في بلدان أجنبية. | |
| معرف السيارة | رخصة | ولاية مجال | مطلوب أحد العناصر الأربعة. التحقق من عدم وجود أحرف غير صالحة. عند ملء علامات VIN / BodyNumber / Cha chassisNumber - تحقق من عدم ملء علامة LicensePlate. عند ملء بطاقة LicensePlate - تأكد من عدم ملء أي معرفات أخرى للمركبة. يتم إجراء البحث عن مركبة والتحقق منها في نظام DKBM الفرعي وفقًا للمصادفة الكاملة لمعرفات المركبات (وفقًا لعدد محدد من المعرفات وقيمها). يتم إجراء فحص رقم الحالة بين أرقام الولاية - معرفات السيارة الوحيدة. |
| فين | فين | ||
| رقم الجسم | رقم الجسم | ||
| رقم الهيكل | رقم الهيكل |
أوضح الاتحاد الروسي لشركات التأمين على السيارات (RSA) إجراءات إبرام اتفاقية OSAGO في شكل وثيقة إلكترونية.
- "يتقدم مالكو السيارات بطلب إلى RSA بشأن إبرام اتفاقيات e-CMTPL. العديد من الأسئلة التي يهتم بها المواطنون هي أسئلة نموذجية. لقد نشرنا مذكرة على موقعنا لشرح النقاط الرئيسية عند إبرام مثل هذه الاتفاقيات ، "قال إيغور يورجنز ، رئيس PCA و ARU ، في إصدار CORINS.
اعتبارًا من 1 يناير 2017 ، دخلت تعديلات القانون الاتحادي الصادر في 25 أبريل 2002 رقم 40-FZ "بشأن التأمين الإجباري ضد المسؤولية المدنية لمالكي المركبات" (قانون MTPL) حيز التنفيذ ، والتي بموجبها تلتزم شركات التأمين بضمان إمكانية إبرام اتفاقية MTPL في شكل مستند إلكتروني مع كل شخص تقدم بطلب لإبرام مثل هذه الاتفاقية.
لإبرام عقد OSAGO إلكتروني ، يجب عليك اتباع الخطوات التالية:
انتقل إلى حسابك الشخصي على موقع شركة التأمين (سجل على موقع شركة التأمين أو انتقل إلى بوابة خدمات الدولة في الاتحاد الروسي) ؛
- تعبئة طلب إبرام اتفاقية في حسابك الشخصي.
بعد ملء الطلب ، يتم فحص البيانات المحددة فيه من خلال نظام المعلومات الآلي RSA (AIS RSA).
إذا أظهر الشيك أن المعلومات الواردة في التطبيق لا تتوافق مع المعلومات الواردة في AIS RSA أو كانت غائبة في AIS RSA ، فإن شركة التأمين ترسل إخطارًا إلى عنوان البريد الإلكتروني المشار إليه من قبل المؤمن عليه بإدراج غير مناسب (مفقود في معلومات AIS RSA). تعرض شركة التأمين أيضًا هذه المعلومات على موقعها على الإنترنت في الوقت الفعلي.
بالإضافة إلى ذلك ، تبلغ شركة التأمين عن الحاجة إلى تقديم نسخ إلكترونية من المستندات المحددة في الفقرات الفرعية "ب" - "و" من الفقرة 3 من المادة 15 من قانون MTPL. تلفت RSA الانتباه إلى حقيقة أنه بدون تقديم نسخ إلكترونية من المستندات ، لن تتمكن شركة التأمين من حساب قسط التأمين. يجب أن تستنسخ نسخ المستندات المقدمة بشكل كامل معلومات المستند الأصلي ، ويجب أن يكون نص المستندات قابلاً للقراءة بحرية (يجب أن تكون التواريخ والتفاصيل والنقوش والطوابع وما إلى ذلك مرئية بوضوح أو توهج أو قطع من المستندات التي تقوم بعمل نسخ غير قابلة للقراءة غير مسموح بها).
إذا تم تزويد المؤمن بمعلومات غير دقيقة ، مما أدى إلى انخفاض غير مبرر في مبلغ قسط التأمين ، يحق للمؤمن أن يسترد من المؤمن عليه مبلغ دفعة التأمين بعد تنفيذه للضحية.
بعد التأكد من امتثال المعلومات المقدمة مع المعلومات الواردة في AIS RSA ، أو التحقق من النسخ الإلكترونية للوثائق ، تعرض شركة التأمين حساب قسط التأمين على الموقع الإلكتروني. بعد دفع قسط التأمين ، يتم إرسال الوثيقة الإلكترونية إلى عنوان البريد الإلكتروني لحامل البوليصة ويتم نشرها في حسابه الشخصي.
يجب طباعة سياسة CTP الإلكترونية الناتجة وتنفيذها معك أثناء القيادة. تتمتع بوليصة OSAGO الإلكترونية بنفس القوة القانونية لبوليصة التأمين الصادرة على نموذج إبلاغ صارم في مكتب شركة التأمين.
- "إذا كان من المستحيل إبرام اتفاقية CMTPL إلكترونية من قبل شركة التأمين التي تقدمت إليها ، فسيُطلب منك الانتقال إلى موقع الويب الخاص بشركة تأمين أخرى (شركة تأمين بديلة) لإبرام اتفاقية CMTPL إلكترونية ،" أشار إيغور يورجنز.
في موقع شركة التأمين البديلة ، يجب اتخاذ الخطوات التالية:
إنشاء حساب شخصي ؛
- املأ طلبًا لإبرام عقد (بموافقتك ، سيتم تلقائيًا نقل البيانات التي حددتها مسبقًا عند ملء طلب على الموقع الإلكتروني لشركة التأمين المحددة أصلاً إلى شركة التأمين البديلة).
الإجراءات الإضافية لإبرام عقد OSAGO الإلكتروني على موقع شركة التأمين البديلة تشبه الإجراءات المذكورة أعلاه. | المؤسس
أوضح RSA الإجراء الخاص بإبرام اتفاقية e-CMTPL
أوضح الاتحاد الروسي لشركات التأمين على السيارات (RSA) إجراءات إبرام اتفاقية OSAGO في شكل وثيقة إلكترونية.
يتقدم مالكو السيارات بطلب إلى RSA فيما يتعلق بإبرام اتفاقيات e-CMTPL. العديد من الأسئلة التي يهتم بها المواطنون هي أسئلة نموذجية. لقد نشرنا مذكرة على موقعنا على الإنترنت تشرح النقاط الرئيسية عند إبرام مثل هذه الاتفاقيات ".
اعتبارًا من 1 يناير 2017 ، دخلت التعديلات على القانون الاتحادي الصادر في 25 أبريل 2002 رقم 40-FZ "بشأن التأمين الإجباري ضد المسؤولية المدنية لمالكي المركبات" (المشار إليه فيما يلي باسم قانون MTPL) حيز التنفيذ ، والتي بموجبها تكون شركات التأمين ملزم بضمان إمكانية إبرام اتفاقية MTPL في شكل مستند إلكتروني مع كل شخص تقدم بطلب لإبرام مثل هذه الاتفاقية.
لإبرام عقد OSAGO إلكتروني ، يجب عليك اتباع الخطوات التالية:
انتقل إلى حسابك الشخصي على موقع شركة التأمين (سجل على موقع شركة التأمين أو انتقل إلى بوابة خدمات الدولة في الاتحاد الروسي) ؛
في حسابك الشخصي ، املأ طلبًا لإبرام اتفاقية.
بعد ملء الطلب ، يتم فحص البيانات المحددة فيه من خلال نظام المعلومات الآلي RSA (المشار إليه فيما يلي - AIS RSA).
إذا أظهر الشيك أن المعلومات الواردة في التطبيق لا تتوافق مع المعلومات الواردة في AIS RSA أو كانت غائبة في AIS RSA ، فإن شركة التأمين ترسل إخطارًا إلى عنوان البريد الإلكتروني المشار إليه من قبل المؤمن عليه بإدراج غير مناسب (مفقود في معلومات AIS RSA). تعرض شركة التأمين أيضًا هذه المعلومات على موقعها على الإنترنت في الوقت الفعلي.
بالإضافة إلى ذلك ، تبلغ شركة التأمين عن الحاجة إلى تقديم نسخ إلكترونية من المستندات المحددة في الفقرات الفرعية "ب" - "و" من الفقرة 3 من المادة 15 من قانون MTPL. تلفت RSA الانتباه إلى حقيقة أنه بدون تقديم نسخ إلكترونية من المستندات ، لن تتمكن شركة التأمين من حساب قسط التأمين. يجب أن تستنسخ نسخ المستندات المقدمة بشكل كامل معلومات المستند الأصلي ، ويجب أن يكون نص المستندات قابلاً للقراءة بحرية (يجب أن تكون التواريخ والتفاصيل والنقوش والطوابع وما إلى ذلك مرئية بوضوح أو توهج أو قطع من المستندات التي تقوم بعمل نسخ غير قابلة للقراءة غير مسموح بها).
إذا تم تزويد المؤمن بمعلومات غير دقيقة ، مما أدى إلى انخفاض غير مبرر في مبلغ قسط التأمين ، يحق للمؤمن أن يسترد من المؤمن عليه مبلغ دفعة التأمين بعد تنفيذه للضحية.
بعد التأكد من امتثال المعلومات المقدمة مع المعلومات الواردة في AIS RSA ، أو التحقق من النسخ الإلكترونية للوثائق ، تعرض شركة التأمين حساب قسط التأمين على الموقع الإلكتروني. بعد دفع قسط التأمين ، يتم إرسال الوثيقة الإلكترونية إلى عنوان البريد الإلكتروني لحامل البوليصة ويتم نشرها في حسابه الشخصي.
يجب طباعة سياسة CTP الإلكترونية الناتجة وتنفيذها معك أثناء القيادة. تتمتع بوليصة OSAGO الإلكترونية بنفس القوة القانونية لبوليصة التأمين الصادرة على نموذج إبلاغ صارم في مكتب شركة التأمين.
"إذا كان من المستحيل إبرام عقد OSAGO إلكتروني من قبل شركة التأمين التي تقدمت إليها ، فسيُطلب منك الانتقال إلى موقع الويب الخاص بشركة تأمين أخرى (شركة تأمين بديلة) لإبرام عقد OSAGO إلكتروني" ، قال I. Yurgens. في موقع شركة التأمين البديلة ، يجب اتخاذ الخطوات التالية:
إنشاء حساب شخصي ؛
املأ طلبًا لإبرام عقد (بموافقتك ، سيتم تلقائيًا نقل البيانات التي حددتها مسبقًا عند ملء طلب على الموقع الإلكتروني لشركة التأمين المحددة أصلاً إلى شركة التأمين البديلة).
الإجراءات الإضافية لإبرام عقد OSAGO الإلكتروني على موقع شركة التأمين البديلة تشبه الإجراءات المذكورة أعلاه.
يعد التحقق من PCA في سياسات OSAGO الإلكترونية إجراءً إلزاميًا. تقوم بإدخال معلومات حول سيارتك ونفسك (بيانات جواز السفر) والسائقين الذين سيسمح لهم بالقيادة. ترسل شركة التأمين هذه المعلومات بشكل مشفر إلى قاعدة بيانات PCA.
يتم فحص قاعدة بيانات PCA تلقائيًا. الغرض الرئيسي منه هو التحقق مما إذا كان لديك سياسات من قبل ، وما هو تاريخ التأمين لهم (عدد الحوادث) ولحساب تكلفة البوليصة بشكل صحيح.
يتم إطلاق فحص قاعدة بيانات PCA بعد أن تملأ طلب تأمين لوثيقة MTPL الإلكترونية في حسابك الشخصي على موقع شركة التأمين.
بدون النجاح الإيجابي لعملية التحقق ، لن تتمكن من المضي قدمًا في دفع البوليصة.
التحقق ليس دائما ناجحا. ليس من غير المألوف أن يفشل نظام شركة التأمين.
أسباب الفشل مختلفة. يعد الفشل الفني ونقص المعلومات عنك وعن سيارتك في قاعدة البيانات أكثرها شيوعًا.
في بعض الأحيان يكون هناك حظر مقصود لنتائج الفحص. وبالتالي تحاول الشركات عديمة الضمير تنظيم تدفق العملاء والتخلص من العملاء غير المربحين - من المناطق "السامة" والتي تعرضت لخسائر في السنوات السابقة. مثل هذه الإجراءات محظورة ويمكن أن تؤدي إلى عقوبات مؤلمة لشركات التأمين من PCA والبنك المركزي للاتحاد الروسي.
عند تسجيل سياسة MTPL الإلكترونية على الموقع الإلكتروني لشركة التأمين ، قد يتم إعلامك بأن فحص PCA التلقائي لم ينجح.
على سبيل المثال ، في Rosgosstrakh يبدو كما يلي:
لتصحيح الموقف ، سيُعرض عليك تحميل نسخ إلكترونية من المستندات التالية على الموقع:
هل هو آمن؟ الى حد كبير. يتم الوصول إلى حسابك الشخصي لتسجيل E-OSAGO عبر بروتوكول https الآمن (فقط في حالة التحقق منه في شريط العنوان في متصفحك). ستذهب المعلومات الواردة في المستندات إلى شركة التأمين فقط ، والتي لا يحق لها نقلها إلى أطراف ثالثة.
سيتحقق متخصصو شركة التأمين يدويًا من بيانات المستند الخاصة بك في قاعدة بيانات PCA. وفي غضون 30 دقيقة ، سيتم إرسال تعليمات أخرى عبر البريد الإلكتروني. يختلف الوقت من شركة إلى أخرى ، ولكن في المتوسط لن تضطر إلى الانتظار أكثر من نصف ساعة.
ستكون نتيجة التحقق اليدوي من المستندات من قبل موظفي شركة التأمين رسالة.
على سبيل المثال ، يأتي خطاب من Rosgosstrakh بالمحتوى التالي.
في الرسالة ، سيتم إخبارك أنه وفقًا لمستنداتك ، كل شيء على ما يرام ، وقمت بملء كل شيء بشكل صحيح في طلب E-CMTPL.
لراحة العملاء ، يتم حفظ جميع البيانات المدخلة في الحساب الشخصي. بما في ذلك معلومات عن حامل الوثيقة والمركبة والسائقين.
كل ما تبقى هو الذهاب إلى قسم الدفع ودفع ثمن الوثيقة ببطاقة مصرفية.
1.19. تلقي حالات المعالجة لطلبات تنزيل حالات مسودة اتفاقيات CMTPL الإلكترونية للحصول على حالة معالجة طلب تنزيل حالة مسودة اتفاقية e-CMTPL ، تستدعي CIS IC خدمة ProjectPolicyService للنظام ، طريقة getSetStatusResult ، للطلب ، يتم استخدام مخطط StatusPolicyEOSAGOStatusRequest.xsd.
يتم توفير تكوين الطلب المقابل للنظام المحدد في الملحق 3 "مواصفات تنسيقات التفاعل" من هذا الدليل.
عند طلب حالة معالجة طلب تحميل حالة مسودة اتفاقية e-CMTPL ، ينبغي مراعاة الجوانب التالية:
يتم توفير تكوين الطلب في الملحق 3 "مواصفات تنسيقات التفاعل" من هذا الدليل.
عند إرسال طلب للحصول على عدد أرقام SK المجانية الخاصة بمسودة عقود e-CMTPL ، يجب مراعاة الجوانب التالية:
