Техническое задание на разработку программного обеспечения для реализации возможности заключения договора осаго в виде электронного документа и обеспечения мвд россии доступа к аис рса в части предоставления информации о действующих договорах


Требования к функциям (задачам), выполняемым системой



страница5/10
Дата01.12.2017
Размер1.17 Mb.
ТипТехническое задание
1   2   3   4   5   6   7   8   9   10

1.14.Требования к функциям (задачам), выполняемым системой

1.14.1.Требования к Подсистеме «Электронный полис»

Требования к Сервису ЭП проверки субъектов/ТС




Требование



Сервис должен обеспечивать авторизацию и аутентификацию клиента.



Сервис должен принимать следующие виды запросов:

  • Запрос на проверку субъекта – страхователя/собственника ТС;

  • Запрос статуса проверки субъекта (страхователя, собственника ТС);

  • Запрос на проверку субъекта – ЛДУ;

  • Запрос статуса проверки субъекта (ЛДУ);

  • Запрос на проверку ТС;

  • Запрос статуса проверки ТС.



Формат запросов и ответов на запросы к Сервису должен быть стандартизирован и описан на этапе технического проектирования.



Перечень данных запроса на проверку субъекта – страхователя или собственника ТС должен соответствовать перечню данных, приведенному в приложении к настоящему ТЗ (ПРИЛОЖЕНИЕ 1., Таблица 6).



Ответ на корректный запрос на проверку субъекта – страхователя или собственника ТС должен содержать:

  1. одно из следующих информационных сообщений:

  • Субъект найден;

  • Субъект не найден.

2) перечень параметров, не совпавших с данными в ДиКБМ.



Запрос на проверку субъекта – страхователя или собственника ТС должен позволять запрашивать информацию только по одному страхователю/собственнику ТС в рамках одного запроса.



Перечень данных запроса на проверку субъекта – ЛДУ должен соответствовать перечню данных, приведенному в в приложении к настоящему ТЗ (ПРИЛОЖЕНИЕ 1., Таблица 7).



Ответ на корректный запрос на проверку субъекта – ЛДУ должен содержать:

  1. одно из следующих информационных сообщений:

  • Водитель найден;

  • Водитель не найден.

  1. перечень параметров, не совпавших с данными в ДиКБМ.



Запрос на проверку субъекта – ЛДУ должен позволять запрашивать информацию только по одному водителю в рамках одного запроса.



Перечень данных запроса на проверку ТС должен соответствовать перечню данных, приведенному в приложении к настоящему ТЗ (ПРИЛОЖЕНИЕ 1., Таблица 8).



Ответ на корректный запрос на проверку ТС должен содержать:

  1. одно из следующих информационных сообщений:

  • Транспортное средство найдено;

  • Транспортное средство не найдено.

  1. перечень параметров, не совпавших с данными в ДиКБМ.



Запрос на проверку ТС должен позволять запрашивать информацию только по одному ТС в рамках одного запроса.


Требования к Модулю обработки запросов на проверку субъекта/ТС




Требование



Модуль при получении запроса на проверку субъекта/ТС должен сформировать и передать запрос сервису ДиКБМ проверки субъектов/ТС.



Направленные в запросе данные субъекта/ТС модуль должен сравнивать с наиболее актуальными данными из ДиКБМ.



Модуль при получении от ДиКБМ ответа на запрос на проверку субъекта/ТС должен сформировать и передать ответ на запрос Сервису ЭП проверки субъектов/ТС.



Модуль должен обеспечивать возможность отключения проверок ФЛК для запросов на проверку субъекта/ТС.


Требования к Сервису загрузки проектов договоров е-ОСАГО и статусов проектов договоров




Требование



Сервис должен обеспечивать авторизацию и аутентификацию клиента.



Сервис должен принимать следующие виды запросов:

  • Запрос на загрузку проекта договора е-ОСАГО;

  • Запрос на загрузку статуса проекта договора е-ОСАГО.



Формат запросов и ответов на запросы к Сервису должен быть стандартизирован и описан на этапе технического проектирования.



Перечень данных запроса на загрузку проекта договора е-ОСАГО должен соответствовать перечню данных, приведенному в приложении к настоящему ТЗ (ПРИЛОЖЕНИЕ 2., Таблица 9).



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



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



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



Перечень данных запроса на загрузку статуса проекта договора е-ОСАГО должен соответствовать перечню данных, приведенному в приложении к настоящему ТЗ (ПРИЛОЖЕНИЕ 2., Таблица 10).



Ответ на запрос на загрузку статуса проекта договора е-ОСАГО должен содержать статус обработки, включая результат проверки расчета КБМ.



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


Требования к Модулю обработки запросов на загрузку проектов договоров е-ОСАГО и статусов проектов договоров




Требование



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



Модуль должен при загрузке проекта договора е-ОСАГО проверять наличие данных о проверке субъекта/ТС:

  • идентификатора проверки субъекта – страхователя;

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

  • идентификатора проверки субъекта – водителя (для проектов договоров с ограничением ЛДУ);

  • идентификатора проверки ТС.

Если данные о проверке субъекта/ТС отсутствуют, проект договора не должен быть сохранен в Системе, а СК должно вернуться соответствующее сообщение.



Модуль должен при загрузке проекта договора е-ОСАГО проверять на совпадение идентифицирующие параметры субъекта/ТС из проекта договора с идентифицирующими параметрами субъекта/ТС из запросов на проверку субъектов/ТС. Если параметры не совпадают, проект договора не должен быть сохранен в Системе, а СК должно вернуться соответствующее сообщение.



Направленные в запросе на загрузку проекта договора е-ОСАГО не идентифицирующие данные субъекта/ТС модуль должен сравнивать с полученными на этапе проверки субъекта/ТС данными из ДиКБМ. Если данные не совпадают, то проект договора не должен быть сохранен в Системе, а СК должно вернуться соответствующее сообщение.



Проект договора е-ОСАГО с субъектом/ТС, который ранее, при проверке в ДиКБМ, не был найден (или найдено более одного ТС), не должен быть сохранен в Системе, а СК должно вернуться соответствующее сообщение.



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



Модуль должен при загрузке проекта договора е-ОСАГО проверять наличие для СК, от которой поступил запрос на загрузку проекта договора, свободного номера для проекта договора. Если свободных номеров для СК нет, то ей должно вернуться соответствующее сообщение.



Модуль должен при загрузке корректного проекта договора е-ОСАГО назначать ему номер и возвращать его в ответе на запрос.



В Модуле должна быть обеспечена возможность для Администратора изменения параметра с ограничением по времени действия запросов на проверку субъектов/ТС стандартными средствами СУБД.



Модуль должен при загрузке проекта договора е-ОСАГО проверять время действия идентификаторов запросов на проверку субъектов/ТС. Если превышено время действия хотя бы одного идентификатора запроса на проверку субъекта/ТС, то проект договора не должен быть сохранен в Системе, а СК должно вернуться соответствующее сообщение.



Модуль должен при загрузке проекта договора е-ОСАГО обеспечивать проверку наличия обособленных структурных подразделений (филиалов) СК на территории субъекта РФ, в котором расположен адрес места регистрации физического лица) собственника ТС и страхователя из проекта договора. Если отсутствуют обособленных структурных подразделений (филиалов) СК на территории такого субъекта, то проект договора не должен быть сохранен в Системе, а СК должно вернуться соответствующее сообщение.



Модуль должен при загрузке проекта договора е-ОСАГО обеспечивать проверку наличия КЛАДР для страхователя/собственника. Если значения отсутствуют или некорректны, то проект договора не должен быть сохранен в Системе, а СК должно вернуться соответствующее сообщение.



Модуль должен при загрузке статуса проекта договора проверять наличие указанного проекта договора в Системе. Если в Системе отсутствует указанный в запросе проект договора, статус не должен быть сохранен в Системе, а СК должно вернуться соответствующее сообщение.



Модуль должен при загрузке статуса проекта договора проверять отсутствие у указанного в запросе договора уже назначенного статуса. Если в Системе у указанного договора уже есть статус, то существующий статус не должен быть изменен, а СК должно вернуться соответствующее сообщение.



Модуль должен при загрузке статуса проекта договора «Действует» направлять запрос на загрузку данных этого проекта договора в ДиКБМ через сервис загрузки договоров/убытков ОСАГО ДиКБМ.



Модуль должен при загрузке статуса проекта договора «Действует» обеспечить передачу этого проекта договора от имени СК, которая загрузила проект договора в Систему.



Модуль должен при получении ответа от ДиКБМ о статусе обработки договора е-ОСАГО формировать ответ для СК, содержащий всю информацию об обработке договора е-ОСАГО из ДиКБМ.



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



При загрузке проектов договоров е-ОСАГО модуль должен осуществлять проверки ФЛК направляемых данных. Перечень проверок ФЛК для проектов договоров е-ОСАГО должен минимально содержать в себе перечень проверок ФЛК договоров ОСАГО.



Модуль должен обеспечивать возможность отключения проверок ФЛК для запросов на загрузку проектов договоров е-ОСАГО.



Модуль должен поддерживать возможность, минуя все проверки, принять и сохранить проект договора е-ОСАГО, назначить ему номер и автоматически перевести в статус «Действует».


Требования к Сервису запроса списка номеров проектов договоров е-ОСАГО




Требование



Сервис должен обеспечивать авторизацию и аутентификацию клиента.



Формат запросов и ответов на запросы к Сервису должен быть стандартизирован и описан на этапе технического проектирования.



Запрос списка номеров проектов договоров должен содержать в себе информацию о запрашивающей СК.



Ответ на запрос списка номеров проектов договоров е-ОСАГО должен содержать перечень номеров проектов договоров е-ОСАГО, у которых нет статуса «Действует» или «Аннулирован» на момент запроса и которые ранее были загружены СК, направившей запрос списка проектов договоров.


Требования к Сервису запроса количества свободных номеров




Требование



Сервис должен обеспечивать авторизацию и аутентификацию клиента.



Формат запросов и ответов на запросы к Сервису должен быть стандартизирован и описан на этапе технического проектирования



Запрос количества свободных номеров должен содержать в себе информацию о запрашивающей СК.



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


Требования к Модулю учета номеров договоров е-ОСАГО




Требование



Для всех договоров е-ОСАГО должна быть установлена единая сквозная возрастающая нумерация.



В Модуле должна быть обеспечена возможность для Администратора ввода лимита номеров проектов договоров е-ОСАГО для СК стандартными средствами СУБД.



В Модуле должен быть реализован счетчик свободных номеров проектов договоров е-ОСАГО для каждой СК:

  • при сохранении проекта договора е-ОСАГО в Системе, ему должен быть назначен номер, а число на счетчике для конкретной СК должно быть уменьшен на 1;

  • при назначении проекту договора статуса «Аннулирован», число на счетчике для СК должен быть увеличено на 1.



Номера проектов договоров не должны использоваться повторно.


Требования к хранению данных в Подсистеме «Электронный полис»




Требование



Подсистема «Электронный полис» должна обеспечивать хранение информации о проектах договоров и их статусах, полученных от СК.



В Подсистеме «Электронный полис» должны храниться все запросы к Системе и от Системы и ответы на них в исходном виде.



Подсистема должна логировать запросы-ответы:

  • От СК к ЭП;

  • От ЭП к ДиКБМ.



Подсистема «Электронный полис» должна обеспечивать хранение информации о лицензии, выданной страховщику, номере, сроке действия, дате выдачи и окончания действия.


Требования к авторизации и аутентификации




Требование



Доступ к функциям сервисов для СК должен предоставляться только авторизованным СК.



Для авторизации СК должны использоваться учетные записи СК в АИС РСА.



Подсистема «Электронный полис» должна вести контроль доступа СК.



В случае ошибки авторизации СК сервисы должны запретить доступ СК и вернуть ошибку с описанием.


1.14.2.Требования к дорабатываемой части Подсистем «Договоры и КБМ»

Требования к Сервису ДиКБМ проверки субъектов/ТС




Требование



При получении запроса на проверку субъекта/ТС идентификация субъекта/ТС должна осуществляться по существующим в ДиКБМ алгоритмам.


Требования к Сервису проверки наличия договора ОСАГО




Требование



Сервис должен принимать запросы одного вида: Запрос на проверку наличия договора ОСАГО.



Формат запроса и ответа на запрос к Сервису должен быть стандартизирован и описан на этапе технического проектирования.



Перечень данных запроса на проверку наличия договора ОСАГО должен соответствовать перечню данных, приведенному в приложении к настоящему ТЗ (ПРИЛОЖЕНИЕ 3., Таблица 11).



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



Ответ на запрос проверки наличия договора ОСАГО должен, при наличии, содержать следующий перечень информации:

  • Серия и номер полиса;

  • Наименование организации страховщика;

  • Срок действия договора с (дата, время) по (дата, время);

  • Собственник ТС (наименование юр. лица, ИНН, физ. лицо хеш (ФИО и дата рождения), сведения о ЛДУ);

  • ТС, марка, модель, VIN или кузов или шасси;

  • Сведения о лицензии, выданной страховщику, номер, срок действия, дата выдачи и окончания действия.

Детальный перечень полей в ответном сообщении должен быть определен на этапе технического проектирования.


Требования к Модулю обработки запросов на проверку наличия договора ОСАГО




Требование



Модуль должен при загрузке запроса на проверку наличия договора ОСАГО производить поиск и среди договоров ОСАГО и среди договоров е-ОСАГО.



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



Поиск договора должен осуществляться по идентифицирующим параметрам ТС (с учетом существующего в ДиКБМ алгоритма идентификации ТС).:





Если при запросе на проверку наличия договора ОСАГО был найден договор с пометкой о гос. тайне, в ответе должно передаваться сообщение «Договор найден, но относится к гос. тайне».



Модуль должен логировать запросы-ответы от МВД к ДиКБМ.


Требования к хранению данных дорабатываемой части в Подсистемах «Договоры и КБМ»




Требование



БД ДиКБМ должна обеспечить возможность хранения информации о договорах е-ОСАГО.


1.14.3.Требования к дорабатываемой части Модуля регистрации запросов СМЭВ




Требование



В Модуле СМЭВ должен быть размещен Сервис проверки наличия договора ОСАГО, принимающий запросы на проверку наличия договора ОСАГО/е-ОСАГО.



Сервис проверки наличия договора ОСАГО в Модуле СМЭВ должен обеспечивать взаимодействие МВД с ДиКБМ АИС РСА через СМЭВ.



Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9   10


База данных защищена авторским правом ©vossta.ru 2019
обратиться к администрации

    Главная страница