Руководство пользователя (руководство оператора и спецификация форматов взаимодействия)

1.16.Импорт проектов договоров е-ОСАГО

1. Запрос на загрузку проекта договора позволяет загружать информацию только по одному проекту договора е-ОСАГО в рамках одного запроса.

2. В поле «DateRevision» родительского элемента DraftPolicyRequest, указывается дата регистрации проекта договора е-ОСАГО в учетной системе КИС СК;

3. В Системе предусмотрено два режима обработки запросов на загрузку проектов договоров е-ОСАГО – без пролонгации и с пролонгацией. Режим обработки проектов договоров е-ОСАГО устанавливается в РСА администратором Системы.

4. В режиме загрузки проектов договоров без пролонгации подсистема «Электронный полис» производит:

• 
  проверку на соответствие запроса установленным правилам ФЛК, описанным в Разделе 7
  
• 
  настоящего руководства;
  
• 
  проверку на действительность направленных в запросе идентификаторов проверки субъектов/ТС, полученных СК в соответствии с п. 1.14-1.15 настоящего руководства;
  
• 
  проверку успешного прохождения проверок субъектов/ТС в ДиКБМ;
  
• 
  проверку совпадения всех данных из запросов на проверку субъектов/ТС с данными, направленными в проекте договора е-ОСАГО;
  
• 
  проверку на действительность идентификатора расчета КБМ путем обращения к соответствующему сервису ДиКБМ;
  
• 
  расчет КБМ, путем обращения к соответствующему сервису ДиКБМ;
  
• 
  при наличии идентификатора загрузки проекта заявления е-ОСАГО осуществляется проверка на то, что ранее данной СК был загружен указанный проект заявления е-ОСАГО.
  

1. В режиме загрузки проектов договоров с пролонгацией подсистема «Электронный полис» обращается к сервису ДиКБМ для поиска пролонгируемого договора ОСАГО. Поиск пролонгируемого договора в ДиКБМ осуществляется среди договоров ОСАГО данной СК по указанным в проекте договора идентификаторам ТС и с учетом даты окончания действия пролонгируемого договора ОСАГО (она должна быть позже или равной дате, предшествующей дате направления проекта е-ОСАГО в Систему).

2. В режиме загрузки проектов договоров в режиме пролонгации подсистема «Электронный полис» производит:

• 
  сохранение проекта договора е-ОСАГО в Системе и обращение к подсистеме ДиКБМ для поиска пролонгируемого договора ОСАГО;
  
• 
  проверку на соответствие запроса установленным правилам ФЛК, описанным в Разделе 7 настоящего руководства;
  
• 
  проверку на действительность направленных в запросе идентификаторов проверки субъектов/ТС;
  
• 
  проверку успешного прохождения проверок субъектов/ТС в ДиКБМ;
  
• 
  проверку совпадения идентифицирующих данных из запросов на проверку субъектов/ТС с идентифицирующими данными субъектов/ТС, направленными в проекте договора е-ОСАГО;
  
• 
  проверку совпадения данных из проекта договора е-ОСАГО с данными найденного в ДиКБМ пролонгируемого договора ОСАГО. Осуществляется проверка данных субъектов/ТС, их наличие в одном пролонгируемом договоре ОСАГО, включая перечень ЛДУ на совпадение данных субъектов из пролонгируемого договора с данными субъектов из проекта договора. Полный перечень сверяемых полей указан в описании ФЛК для режима с пролонгацией;
  
• 
  проверка, что дата начала действия договора е-ОСАГО является следующей датой после даты окончания действия/досрочного прекращения предыдущего договора (дата начала действия договора должна быть следующим днем после даты окончания предыдущего договора);
  
• 
  если проверки на пролонгацию не пройдены, проекту договора е-ОСАГО в Системе автоматически присваивается статус «Аннулирован»;
  
• 
  проверку на действительность идентификатора расчета КБМ путем обращения к соответствующему сервису ДиКБМ;
  
• 
  расчет КБМ, путем обращения к соответствующему сервису ДиКБМ.
  

1. В режиме пролонгации допускается продление договора ОСАГО с увеличением количества лиц, допущенных к управлению транспортным средством в предыдущем договоре ОСАГО. К расширению круга лиц, допущенных к управлению транспортным средством, не относятся:

• исключение ЛДУ из списка лиц, допущенных к управлению транспортным средством в предыдущем договоре ОСАГО;

• замена ЛДУ (замена одного ЛДУ на другого) в списке лиц, допущенных к управлению транспортным средством в предыдущем договоре ОСАГО;

• изменение условий (по сравнению с условиями, предусмотренными в предыдущем договоре ОСАГО), предусматривающих управление транспортным средством только указанными страхователем ЛДУ, на условие страхования без ограничения лиц, допущенных к управлению транспортным средством, и наоборот.

1. В случае если в режиме пролонгации Система получила от ДиКБМ более одного найденного действующего договора ОСАГО для данного ТС и СК, то подсистема «Электронный полис» проверяет каждый из них на возможность пролонгации.

2. Начиная с доработки по ЧТЗ на доработку ДиКБМ и Е-ОСАГО в части внесения изменений в электронном виде в договоры ОСАГО, заключенные в виде электронного документа, в подсистему «Электронный полис» добавлены следующие алгоритмы обработки данных договоров:

• 
  New – новый проект договора е-ОСАГО;
  
• 
  CorrectError – техническая коррекция к договору е-ОСАГО;
  
• 
  ChangeObject – изменение договора е-ОСАГО (дополнительное соглашение в электронном виде);
  
• 
  Recall – отзыв договора е-ОСАГО;
  
• 
  RecallAddAgr – отзыв дополнительного соглашения е-ОСАГО.
  
• 
  Начиная с доработки ДиКБМ и ПО е-ОСАГО в части заключения договоров ОСАГО в виде электронных документов при определении страховщика по номеру паспорта транспортного средства страхователя, добавлен алгоритм отработки «Application»- проект заявления е-ОСАГО.
  

1. При алгоритмах обработки «New», «ChangeObject», при корректно заполненных полях MobileNumber (мобильный номер) и/или Email (электронный адрес), страхователю направляется соответствующее уведомление на указанный мобильный номер телефона/электронный адрес о заключении им договора/доп.соглашения е-ОСАГО.

2. При алгоритме обработки «Application» не производиться запрос в ДиКБМ к методу для автоматического расчета КБМ и методу проверки идентификатора расчета класса КБМ по договору. А так же при алгоритме обработки «Application» и заполненных полях «Мобильный номер страхователя» (поле MobileNumber)/ «Электронный адрес страхователя» (поле Email) страхователю не осуществляется отправка sms/e-mail уведомление о заключении е-полиса.

3. При успешной загрузке проекта заявления е-ОСАГО ему автоматически присваивается статус «3» (Заявление). При этом у СК1, загрузившей проект заявления е-ОСАГО, не изменяется счетчик израсходованных номеров.

4. В ответ на запрос загрузки проекта заявления, СК1 возвращается «Идентификатор загрузки проекта заявления е-ОСАГО», необходимый для использования в качестве параметра для гиперссылки из запроса на получение данных об СК2.Загрузка дополнительных соглашений, технических коррекций к договору е-ОСАГО и отзывов договора/дополнительного соглашения е-ОСАГО осуществляется в соответствии со схемой PolicyEOSAGORequest.xsd с указанием соответствующих алгоритмов обработки в теге DraftPolicyHandle (Алгоритм обработки проекта договора е-ОСАГО): New, CorrectError, ChangeObject, Recall, RecallAddAgr.

5. Направление дополнительных соглашений/технических коррекций/отзывов к е-полисам (CorrectError, ChangeObject, Recall, RecallAddAgr) только для действующих е-полисов.

6. При загрузке данных с указанием алгоритмов обработки CorrectError, ChangeObject, осуществляется запрос к методу для поиска в ДиКБМ е-полисов, для которых запрещено оформление доп. соглашений.

7. Если оформление дополнительного соглашения/технической коррекции разрешено, то Системой выполняется следующая последовательность действий:

• 
  Для дополнительного соглашения/технической коррекции (алгоритмы CorrectError, ChangeObject) выполняется логическая проверка данных.
  
• 
  При успешной загрузке тех. коррекции/досрочного прекращения, им не присваиваются новая серия и номер, серия и номер указываются из договора/дополнительного соглашения, на который была прислана данная тех. коррекция, либо из предыдущей последней действующей версии договора/доп.соглашения при досрочном прекращении.
  
• 
  Если при успешной загрузке досрочного прекращения, были найдены ранее загруженные доп. соглашения к данному договору, которые не были переведены в статус «действующий», либо «аннулирован», то такие доп. соглашения будут автоматически аннулированы.
  

1. 
   Доп.соглашения, которым не был ранее присвоен статус «Действующий» или «Аннулирован», и у которых наступила дата начала действия автоматически аннулированы в Системе.
   
2. 
   При отзыве договоров/доп.соглашений, направляемых при алгоритмах обработки Recall, RecallAddAgr, Системой выполняется следующая последовательность действий:
   

• 
  Выполняется логическая проверка данных.
  
• 
  При успешной загрузке отзыва в Подсистему «Электронный полис», ему автоматически присваивается статус «действующий», и осуществляется загрузка отзыва в ДиКБМ.
  
• 
  При загрузке отзывов, не выделяется новая серия и номер.
  
• 
  Направляемый отзыв аннулирует доп. соглашение на которое он был направлен, либо договор, на который он был направлен и все связанные с этим договором доп. соглашения.
  
• 
  При каждом аннулировании договора/дополнительного соглашения СК, значение параметра «Количество использованных СК номеров» уменьшается на «1».
  

1. 
   На данный момент заблокирована возможность загрузки в Подсистему «Электронный полис» тех.коррекций к договорам/доп.соглашениям е-ОСАГО. При направлении данных с указанием алгоритма обработки CorrectError (техническая коррекция к договору е-ОСАГО), выводится статусное сообщение об ошибке №200 «Ошибка валидации. (Запрещена загрузка тех.коррекции к е-полисам)».
   

2. Логика проверки и сохранения проектов договоров/доп.соглашений е-ОСАГО идентична логике сохранения и проверки договоров в ДиКБМ (т.е. проект договора е-ОСАГО может быть сохранен с ошибками валидации и, в дальнейшем, после перегрузки его в ДиКБМ, не участвовать в расчете КБМ).

3. Подсистема «Электронный полис» при загрузке проекта договора е-ОСАГО проверяет наличие для СК, от которой поступил запрос на загрузку проекта договора, свободного номера для проекта договора. Если свободных номеров для СК нет, то ей возвращается соответствующее сообщение об ошибке. Если при загрузке проекта договора е-ОСАГО с заполненным значением идентификатора загрузки проекта заявления е-ОСАГО, у СК2 исчерпан лимит выделенных номеров договоров, то в ответном сообщении СК не возвращается ошибка «Исчерпан лимит выделенных СК номеров договоров» и проект договора е-ОСАГО при отсутствии других ошибок, препятствующих загрузке, успешно загружается в Подсистему «Электронный полис», при этом, в для найденной записи таблицы Счётчик номеров договоров е-ОСАГО за 01 число текущего месяца загрузки проекта договора е-ОСАГО увеличивается на «1» количество номеров, потраченных СК сверх выделенного лимита. При этом количество использованных номеров не изменяется. Если у СК2 на дату загрузки проекта договора е-ОСАГО не исчерпан лимит свободных номеров, то счетчик использованных номеров увеличивается на единицу, а количество номеров, потраченных СК сверх выделенного лимита не изменяется.

4. Подсистема «Электронный полис» обеспечивает проверку наличия обособленных структурных подразделений (филиалов) СК на территории субъекта РФ, в котором расположен адрес места регистрации физического лица – собственника ТС и страхователя из проекта договора. Если обособленные структурные подразделения (филиалы) СК на территории такого субъекта отсутствуют, то Подсистема «Электронный полис» отказывает в сохранении такого проекта договора в Системе и СК передается соответствующее сообщение об ошибке.

5. В случае если по инициативе РСА в режиме пролонгации было произведено комплексное отключение проверок ФЛК при загрузке проекта договора е-ОСАГО, то проект договора е-ОСАГО сохраняется в Системе при условии успешного прохождения проверок ФЛК, за исключением следующих проверок:

• идентификаторов проверок субъектов/ТС;

• идентификатора расчета КБМ;

• расчета КБМ;

• данных в проекте с данными, направленными при запросах на проверку субъектов/ТС (в случае пролонгации – с данными пролонгируемого договора).

После этого проекту договора е-ОСАГО автоматически назначается статус «Действующий» и подсистема «Электронный полис» направляет запрос на загрузку данных этого проекта договора в ДиКБМ. Стандартная процедура направления статусов проектам договоров е-ОСАГО описана в п.п. 1.18-1.19 настоящего руководства.

39. В случае соответствия запроса установленным правилам ФЛК подсистема «Электронный полис» формирует ответ СК об успешной постановке запроса в очередь с указанием идентификатора записи в очередь обработки проектов договоров. Ответное сообщение СК формируется в соответствие со схемой PolicyEOSAGOResponse.xsd, состав которой приведен в Приложении 3 «Спецификация форматов взаимодействия» настоящего руководства.

40. В случае возникновения ошибок при обработке запроса Система формирует ответ СК с перечнем выявленных ошибок валидации запроса, передаваемым в теге ErrorList ответного сообщения СК. Коды ошибок, их описание и поведение Системы при их получении приведены в Приложении 1 настоящего документа.

41. При использовании Адаптера WS Система автоматически после получения окончательного результата обработки запроса возвращает СК файл, содержащий результаты загрузки проекта договора е-ОСАГО, либо ошибки в обработке запроса в соответствии с п. 1.17 настоящего руководства. В случае если запрос направлялся без использования Адаптера WS, для получения результатов загрузки проекта договора е-ОСАГО необходимо осуществить запрос статуса обработки, порядок направления которого описан в п. 1.17 настоящего руководства.