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


Назначение и цели разработки системы



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

Назначение и цели разработки системы

1.8.Назначение Системы


В рамках работ по разработке программного обеспечения для реализации возможности заключения договора ОСАГО в виде электронного документа и обеспечения МВД доступа к АИС РСА в части предоставления информации о действующих договорах ОСАГО будут проведены следующие работы:

  • Разработка Подсистемы «Электронный полис» АИС РСА;

  • Доработка Подсистем «Договоры и КБМ» АИС РСА;

  • Доработка Модуля регистрации запросов СМЭВ АИС РСА.

Разрабатываемая Подсистема «Электронный полис» имеет следующее назначение:

  • Обработка следующих поступающих от КИС СК запросов:

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

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

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

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

    • Запрос на проверку транспортного средства;

    • Запрос статуса проверки транспортного средства;

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

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

    • Запрос количества свободных номеров проектов договоров е-ОСАГО для СК;

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

  • Передача запросов на проверку субъектов и ТС в ДиКБМ;

  • Консолидация информации о проектах договоров е-ОСАГО и статусов к ним;

  • Перегрузка действующих договоров е-ОСАГО в ДиКБМ;

  • Предоставление и учет номеров проектов договоров е-ОСАГО.

Доработка Подсистем «Договоры и КБМ» имеет следующее назначение:

  • Обработка запросов от Системы на проверку информации о субъектах и ТС;

  • Обработка запросов от Модуля СМЭВ о наличии договора ОСАГО в ДиКБМ;

  • Консолидация информации о действующих договорах е-ОСАГО.

Доработка Модуля СМЭВ имеет следующее назначение:

  • Принятие от МВД через СМЭВ запроса на проверку наличия договора ОСАГО в ДиКБМ;

  • Передача запроса на проверку наличия договора ОСАГО в ДиКБМ;

  • Принятие от ДиКБМ результата обработки запроса на проверку наличия договора ОСАГО в ДиКБМ;

  • Передача результата обработки запроса на проверку наличия договора ОСАГО в МВД через СМЭВ.

1.9.Цели разработки


Целью разработки Системы является обеспечение выполнения требований статьи 15 Закона об ОСАГО, согласно которым договор ОСАГО может быть составлен в виде электронного документа, а также требований документа «Функциональные требования к программному обеспечению для реализации возможности заключения договора ОСАГО в виде электронного документа и обеспечения МВД России доступа к АИС РСА в части предоставления информации о действующих договорах ОСАГО», одобренные на заседании Правления РСА от 26.02.2015 года.

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

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



Характеристика объекта автоматизации

1.10.Краткие сведения об объекте автоматизации


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

1.11.Описание существующих процессов


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

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

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

1.12.Описание будущих процессов

1.12.1.Участники информационного взаимодействия


Участниками информационного взаимодействия являются:

  • РСА.

  • СК– члены РСА, осуществляющие на территории РФ обязательное страхование гражданской ответственности владельцев транспортных средств согласно Закону об ОСАГО.

  • МВД.

1.12.2.Функции РСА


В рамках информационного взаимодействия РСА выполняет следующие функции:

  • Предоставление сервисов СК и МВД для обмена сообщениями.

  • Обработка поступающих от СК сообщений и передача результатов обработки в СК.

  • Обработка поступающих от МВД сообщений и передача результатов обработки в МВД.

  • Сбор и хранение информации о проектах договоров е-ОСАГО.

  • Сбор и хранение информации о договорах е-ОСАГО.

  • Хранение информации о приеме сообщений от СК и МВД и о результатах их обработки.

  • Разрешение нештатных ситуаций, возникающих в процессе обмена сообщениями.

1.12.3.Функции СК


В рамках информационного взаимодействия СК выполняет следующие функции:

  • Запрос проверки в РСА информации о субъектах/ТС.

  • Предоставление в РСА информации о проектах договоров е-ОСАГО.

  • Предоставление в РСА информации о статусе проекта договора е-ОСАГО.

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

  • Запрос проверки в РСА количества свободных номеров для проектов договоров е-ОСАГО.

1.12.4.Функции МВД


В рамках информационного взаимодействия МВД выполняет следующие функции:

  • Запрос в РСА информации о наличии договора ОСАГО.

1.12.5.Процессы взаимодействия СК и РСА


Основные процессы информационного взаимодействия между СК и РСА осуществляются по схемам, описанными в п.п. 1.12.7-1.12.10 настоящего ТЗ, посредством обмена сообщениями (запросы и ответы на запросы) согласованного формата.

Основными процессами информационного взаимодействия между СК и РСА являются:



  • Запрос СК на проверку в РСА информации о субъектах/ТС.

  • Предоставление РСА в СК информации о результатах произведенных проверок субъектов/ТС и идентификаторов произведенных проверок.

  • Предоставление СК в РСА информации о проектах договоров е-ОСАГО.

  • Предоставление РСА в СК информации о статусе обработки проекта договора е-ОСАГО.

  • Предоставление РСА в СК информации о назначенном номере проекту договора е-ОСАГО.

  • Предоставление СК в РСА информации о статусах проектов договоров е-ОСАГО («Действующий»/«Аннулирован»).

  • Предоставление РСА в СК подтверждения о присвоении статуса проекту договора.

  • Предоставление РСА в СК информации о статусе сохранения договора е-ОСАГО в ДиКБМ.

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

  • Предоставление РСА в СК списка номеров проектов договоров е-ОСАГО, которым не присвоены статусы «Действующий»/ «Аннулирован».

  • Запрос СК в РСА количества свободных номеров для проектов договоров е-ОСАГО.

  • Предоставление РСА в СК информации о количестве свободных номеров для проектов договоров е-ОСАГО.

1.12.6.Процессы взаимодействия МВД и РСА


Основные процессы информационного взаимодействия между МВД и РСА осуществляются по единой схеме посредством обмена сообщениями (запросы и ответы на запросы) согласованного формата, описанной в п.1.12.11 настоящего ТЗ.

Основными процессами информационного взаимодействия между МВД и РСА являются:



  • Запрос МВД в РСА информации о наличии договора ОСАГО.

  • Предоставление РСА в МВД информации о наличии договора ОСАГО в ДиКБМ.

1.12.7.Схема взаимодействия СК и РСА в части проверки субъектов/ТС


Система должна обеспечивать принятие и обработку запросов от СК на проверку субъектов – физических лиц (страхователей, собственников ТС, ЛДУ) и ТС.

Диаграммы последовательности запросов на проверку субъектов/ТС, направляемые посредством Адаптера WS и посредством веб-сервиса напрямую (без использования Адаптера WS), представлены на рис. 1-рис. 8.

Участниками процессов являются:


  • КИС СК –инициатор запросов на проверку субъектов/ТС;

  • Система – подсистема, обеспечивающая взаимодействие с ДиКБМ для осуществления проверки субъектов/ТС;

  • ДиКБМ –обеспечивает проверку субъектов/ТС.

Проверка субъекта-физического лица (страхователя)



Рисунок 1 Диаграмма последовательности проверки субъекта-физического лица (страхователя договора е-ОСАГО) посредством Адаптера WS



Предусловие:

СК сформировала запрос на проверку субъекта – физического лица (страхователя договора е-ОСАГО) в Подсистему «Электронный полис» (Систему).

Основной сценарий при использовании Адаптера WS:


шага

Описание шага сценария



Страховая организация посредством Адаптера WS направила запрос на проверку субъекта – физического лица (страхователя) в Систему.



КИС СК получает идентификатор запроса на проверку субъекта – физического лица (страхователя).



Система направляет запрос на проверку субъекта – физического лица (страхователя) в ДиКБМ.



ДиКБМ осуществляет проверку субъекта – физического лица (страхователя) в БД.



Система получает результаты проверки субъекта – физического лица (страхователя) из ДиКБМ.



Система передает страховой организации информацию о проведенной проверке (уведомление о том, что проверка пройдена и номер проверки).

Завершение сценария.

Альтернативные сценарии:

А1

  • на шаге 3 основного сценария подсистемы ДиКБМ недоступны.

4. Завершение альтернативного сценария А1.
А2

  • на шаге 4 основного сценария произошла ошибка – направленный субъект не прошел проверку в ДиКБМ.

5. Система передает страховой организации уведомление о том, что проверка не пройдена.

6. Завершение альтернативного сценария А1.

Диаграмма последовательности запроса на проверку субъекта-физического лица (страхователя), направляемого без использования Адаптера WS представлена на рис. 2.

Рисунок 2 Диаграмма последовательности проверки субъекта-физического лица (страхователя договора е-ОСАГО) без использования Адаптера WS

Основной сценарий без использования Адаптера WS:


шага

Описание шага сценария



Страховая организация направила запрос на проверку субъекта – физического лица (страхователя) в Систему.



КИС СК получает идентификатор запроса на проверку субъекта – физического лица (страхователя).



Страховая организация направляет запрос в Систему на проверку статуса обработки запроса из шага 1.



Система направляет запрос на проверку субъекта – физического лица (страхователя) в ДиКБМ.



ДиКБМ осуществляет проверку субъекта – физического лица (страхователя) в БД.



Система получает результаты проверки субъекта – физического лица (страхователя) из ДиКБМ.



Система передает страховой организации информацию о проведенной проверке (уведомление о том, что проверка пройдена и номер проверки).

Завершение сценария.


Проверка субъекта-физического лица (собственника ТС)





Рисунок 3 Диаграмма последовательности проверки субъекта-физического лица (собственника ТС по договору е-ОСАГО) посредством Адаптера WS

Предусловие:

Страховая организация сформировала запрос на проверку субъекта – физического лица (собственника ТС по договору е-ОСАГО) в Подсистему «Электронный полис» (Систему).

Основной сценарий при использовании Адаптера WS:


шага

Описание шага сценария



Страховая организация посредством Адаптера WS направила запрос на проверку субъекта – физического лица (собственника ТС) в Систему.



КИС СК получает идентификатор запроса на проверку субъекта – физического лица (собственника ТС).



Система направляет запрос на проверку субъекта – физического лица (собственника ТС) в ДиКБМ.



ДиКБМ осуществляет проверку субъекта – физического лица (собственника ТС) в БД.



Система получает результаты проверки субъекта – физического лица (собственника ТС) из ДиКБМ.



Система передает страховой организации информацию о проведенной проверке (уведомление о том, что проверка пройдена и номер проверки).

Завершение сценария.

Альтернативные сценарии:

А1

  • на шаге 3 основного сценария подсистемы ДиКБМ недоступны.

4. Завершение альтернативного сценария А1.

А2

  • на шаге 4 основного сценария произошла ошибка – направленный субъект не прошел проверку в ДиКБМ.

5. Система передает страховой организации уведомление о том, что проверка не пройдена.

6. Завершение альтернативного сценария А1.

Диаграмма последовательности запроса на проверку субъекта-физического лица (собственника ТС), направляемого без использования Адаптера WS представлена на рис.4.

Рисунок 4 Диаграмма последовательности проверки субъекта-физического лица (собственника ТС) без использования Адаптера WS

Основной сценарий без использования Адаптера WS:


шага

Описание шага сценария



Страховая организация направила запрос на проверку субъекта – физического лица (собственника ТС) в Систему.



КИС СК получает идентификатор запроса на проверку субъекта – физического лица (собственника ТС).



Страховая организация направляет запрос в Систему на проверку статуса обработки запроса из шага 1.



Система направляет запрос на проверку субъекта – физического лица (собственника ТС) в ДиКБМ.



ДиКБМ осуществляет проверку субъекта – физического лица (собственника ТС) в БД.



Система получает результаты проверки субъекта – физического лица (собственника ТС) из ДиКБМ.



Система передает страховой организации информацию о проведенной проверке (уведомление о том, что проверка пройдена и номер проверки).

Завершение сценария.



Проверка субъекта-физического лица (ЛДУ)






Рисунок 5 Диаграмма последовательности проверки субъекта-физического лица (ЛДУ) посредством Адаптера WS

Предусловие:

Страховая организация сформировала запрос на проверку субъекта – физического лица (ЛДУ) в Подсистему «Электронный полис» (Систему).

Основной сценарий при использовании Адаптера WS:


шага

Описание шага сценария



Страховая организация посредством Адаптера WS направила запрос на проверку субъекта – физического лица (ЛДУ) в Систему.



КИС СК получает идентификатор запроса на проверку субъекта – физического лица (ЛДУ).



Система направляет запрос на проверку субъекта – физического лица (ЛДУ) в ДиКБМ.



ДиКБМ осуществляет проверку субъекта – физического лица (ЛДУ) в БД.



Система получает результаты проверки субъекта – физического лица (ЛДУ) из ДиКБМ.



Система передает страховой организации информацию о проведенной проверке (уведомление о том, что проверка пройдена и номер проверки).

Завершение сценария.

Альтернативные сценарии:

А1

  • на шаге 3 основного сценария подсистемы ДиКБМ недоступны.

4. Завершение альтернативного сценария А1.

А2

  • на шаге 4 основного сценария произошла ошибка – направленный субъект не прошел проверку в ДиКБМ.

5. Система передает страховой организации уведомление о том, что проверка не пройдена.

6. Завершение альтернативного сценария А1.

Диаграмма последовательности запроса на проверку субъекта-физического лица (ЛДУ), направляемого без использования Адаптера WS представлена на рис. 6.

Рисунок 6 Диаграмма последовательности проверки субъекта-физического лица (ЛДУ) без использования Адаптера WS

Основной сценарий без использования Адаптера WS:


шага

Описание шага сценария



Страховая организация направила запрос на проверку субъекта – физического лица (ЛДУ) в Систему.



КИС СК получает идентификатор запроса на проверку субъекта – физического лица (ЛДУ).



Страховая организация направляет запрос в Систему на проверку статуса обработки запроса из шага 1.



Система направляет запрос на проверку субъекта – физического лица (ЛДУ) в ДиКБМ.



ДиКБМ осуществляет проверку субъекта – физического лица (ЛДУ) в БД.



Система получает результаты проверки субъекта – физического лица (ЛДУ) из ДиКБМ.



Система передает страховой организации информацию о проведенной проверке (уведомление о том, что проверка пройдена и номер проверки).

Завершение сценария.



Проверка транспортного средства (ТС)





Рисунок 7 Диаграмма последовательности проверки транспортного средства (ТС) посредством Адаптера WS

Предусловие:

Страховая организация сформировала запрос на проверку транспортного средства (ТС) в Подсистему «Электронный полис» (Систему).

Основной сценарий при использовании Адаптера WS:


шага

Описание шага сценария



Страховая организация посредством Адаптера WS направила запрос на проверку транспортного средства (ТС) в Систему.



КИС СК получает идентификатор запроса на проверку транспортного средства (ТС).



Система направляет запрос на проверку транспортного средства (ТС) в ДиКБМ.



ДиКБМ осуществляет проверку транспортного средства (ТС) в БД.



Система получает результаты проверки транспортного средства (ТС) из ДиКБМ.



Система передает страховой организации информацию о проведенной проверке (уведомление о том, что проверка пройдена и номер проверки).

Завершение сценария.

Альтернативные сценарии:

А1

  • на шаге 3 основного сценария подсистемы ДиКБМ недоступны.

4. Завершение альтернативного сценария А1.
А2

  • на шаге 4 основного сценария произошла ошибка – направленное транспортное средство не прошло проверку в ДиКБМ.

5. Система передает страховой организации уведомление о том, что проверка не пройдена.

6. Завершение альтернативного сценария А1.

Диаграмма последовательности запроса на проверку транспортного средства (ТС), направляемого без использования Адаптера WS представлена на рис. 8.

Рисунок 8 Диаграмма последовательности проверки транспортного средства (ТС) без использования Адаптера WS

Основной сценарий без использования Адаптера WS:


шага

Описание шага сценария



Страховая организация направила запрос на проверку транспортного средства (ТС) в Систему.



КИС СК получает идентификатор запроса на проверку транспортного средства (ТС).



Страховая организация направляет запрос в Систему на проверку статуса обработки запроса из шага 1.



Система направляет запрос на проверку транспортного средства (ТС) в ДиКБМ.



ДиКБМ осуществляет проверку транспортного средства (ТС) в БД.



Система получает результаты проверки транспортного средства (ТС) из ДиКБМ.



Система передает страховой организации информацию о проведенной проверке (уведомление о том, что проверка пройдена и номер проверки).

Завершение сценария.


1.12.8.Схема взаимодействия СК и РСА в части загрузки проекта договора е-ОСАГО и направления его статуса

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

Диаграмма последовательности обработки проекта договора е-ОСАГО представлена на рис. 9.

Рисунок 9 Диаграмма последовательности создания договора е-ОСАГО

Участники процесса:


  • КИС СК –инициатор запроса на обработку проекта договора е-ОСАГО;

  • Система – подсистема, обеспечивающая обработку, проверку на корректность и консолидацию проектов договоров е-ОСАГО;

  • ДиКБМ –обеспечивает проверку проектов е-ОСАГО на корректность и консолидацию договоров е-ОСАГО.

Предусловие:

Страховая организация сформировала запрос на загрузку проекта договора е-ОСАГО в Подсистему «Электронный полис» (Систему).

Основной сценарий при использовании Адаптера WS:


шага

Описание шага сценария



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

2.1.

2.2.


Система проверяет проект договора е-ОСАГО на корректность, в том числе запрашивает в ДиКБМ проверку КБМ/ТО и идентификатора расчета КБМ.

3.1.

ДиКБМ осуществляет проверку КБМ/ТО и идентификатора расчета КБМ, направленных в проекте договора е-ОСАГО.

4.1.

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

5.

Система сохраняет прошедший проверки проект договора е-ОСАГО в БД ЭП и присваивает ему номер.

6.

Система передает страховой организации информацию о проведенной проверке (уведомление о том, что проверка пройдена и номер проекта договора е-ОСАГО).

7.

Страховая организация направляет в Систему статус проекта договора е-ОСАГО – «Действующий»

8.1.

Система присваивает проекту договора е-ОСАГО статус «Действующий» и направляет его для проверки и сохранения в ДиКБМ.

9.1.

ДиКБМ проверяет направленный проект договора е-ОСАГО и, после успешной проверки, сохраняет его в БД ДиКБМ.

10.1.

После сохранения договора е-ОСАГО в ДиКБМ Система получает уведомление об успешном сохранении договора е-ОСАГО.

11.

Система передает страховой организации информацию о присвоении статуса проекту договора е-ОСАГО («Действующий»), результаты проверок ФЛК в ДиКБМ и уведомление об успешном сохранении договора е-ОСАГО в ДиКБМ.

Завершение сценария.

Альтернативные сценарии:

А1

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

  1. Система передает страховой организации уведомление о том, что направленный проект договора не прошел проверки ФЛК и не сохранен в Системе.

  2. Завершение альтернативного сценария А1.

А2

  • на шаге 7 основного сценария страховая организация направляет в Систему статус проекта договора е-ОСАГО – «Аннулирован».

8.2. Система присваивает проекту договора е-ОСАГО статус «Аннулирован».

9. Система передает страховой организации информацию об успешном присвоении статуса проекту договора е-ОСАГО («Аннулирован»).

10. Завершение альтернативного сценария А2.

А3


  • на шаге 9.1 основного сценария направленный проект договора е-ОСАГО со статусом «Действующий» не прошел проверки ФЛК и не был сохранен в ДиКБМ.

10.1. ДиКБМ направляет в Систему результаты проверки ФЛК и уведомление, что договор е-ОСАГО не сохранен в БД ДиКБМ.

11. Система передает страховой организации результаты проверки ФЛК и уведомление о том, что договор е-ОСАГО не был сохранен в ДиКБМ. Проекту договора е-ОСАГО не присвоен статус «Действует».

12. Завершение альтернативного сценария А3.

1.12.9.Схема взаимодействия СК и РСА в части запроса списка номеров проектов договоров е-ОСАГО без статусов


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

Диаграмма последовательности запроса списка номеров проектов договоров е-ОСАГО без статусов, представлена на рисунке 10.



Рисунок 10. Диаграмма последовательности запроса списка номеров проектов договоров е-ОСАГО

Участники процесса:


  • КИС СК –инициатор запроса на получение списка номеров проектов договоров е-ОСАГО, которым не присвоен статус;

  • Система – подсистема, обеспечивающая обработку запросов на получение списка номеров проектов договоров е-ОСАГО.

Предусловие:

Страховая организация сформировала запрос списка проектов договоров е-ОСАГО без статусов в Подсистему «Электронный полис» (Систему)

Основной сценарий:


шага

Описание шага сценария



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



Система осуществляет обработку запроса (поиск проектов договоров е-ОСАГО без статусов по запрашивающей СК).



Система передает страховой организации информацию о номерах проектов договоров е-ОСАГО без статусов по этой СК.

Завершение сценария.



1.12.10.Схема взаимодействия СК и РСА в части запроса количества свободных номеров


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

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



Рисунок 11. Диаграмма последовательности запроса количества свободных номеров СК

Участники процесса:


  • КИС СК –инициатор запроса на получение количества свободных номеров для договоров е-ОСАГО для этой СК;

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

Предусловие:

Страховая организация сформировала запрос количества свободных номеров для договоров е-ОСАГО в Подсистему «Электронный полис» (Систему).

Основной сценарий:


шага

Описание шага сценария



Страховая организация направила запрос количества свободных номеров проектов договоров е-ОСАГО.



Система осуществляет обработку запроса (проверку количества свободных номеров для данной СК).



Система передает страховой организации информацию о количестве свободных номеров для проектов договоров е-ОСАГО по этой СК.

Завершение сценария.



1.12.11.Схема взаимодействия МВД и РСА в части проверки наличия договора ОСАГО


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

Диаграмма последовательности запроса на проверку наличия договора ОСАГО, представлена на рисунке 12.



Рисунок 12. Диаграмма последовательности запроса на проверку наличия договора ОСАГО

Участники процесса:


  • ИС МВД – информационная система– инициатор запроса на проверку наличия договора ОСАГО;

  • ДиКБМ –обеспечивает проверку наличия договора ОСАГО.

Предусловие:

ИС МВД сформировала запрос на проверку наличия договора ОСАГО в ДиКБМ.

Основной сценарий:


шага

Описание шага сценария



ИС МВД направила запрос на проверку наличия договора ОСАГО.



ДиКБМ осуществляет обработку запроса (поиск среди договоров ОСАГО и е-ОСАГО).



ДиКБМ передает ИС МВД информацию о наличии/отсутствии договора ОСАГО (или е-ОСАГО).

Завершение сценария.






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


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

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