пример технического задания. Техническое задание (3). 1. 1Полное наименование работ 3 2Сокращенное наименование работ 4

• Название: 1. 1Полное наименование работ 3 2Сокращенное наименование работ 4
• Анкор: пример технического задания
• Дата: 03.09.2021
• Размер: 1.97 Mb.
• Имя файла: Техническое задание (3).docx
• Тип: Документы; #229137
• страница: 12 из 25

Требования к содержанию работ по развитию системы

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

Работы должны быть реализованы в порядке и в сроки, определенные в заявке на выполнение работ по развитию Системы, если это не противоречит условиям ТЗ и Контракта.

В случае принятия Заказчиком соответствующего решения любая из указанных задач может быть заменена на равнозначную в отношении другой подсистемы.

Состав работ определяется заявкой на выполнение работ по развитию Системы. Заказчик направляет с официальным сопроводительным письмом Подрядчику заявку на выполнение работ по развитию Системы, согласованную Пользователем в Единой системе электронного документооборота Правительства Москвы по форме, представленной в Приложении В к ТЗ, при этом одна заявка на выполнение работ по развитию Системы может содержать в себе несколько задач различных по сложности. Объем выполняемых работ определяется сторонами дополнительно на этапе разработки ЧТЗ. Стоимость выполненных работ определяется в порядке, определенном в пункте 6.8 ТЗ и на основании Расчета стоимости реализации решений, являющимся приложением к Протоколу обработки заявки на выполнение работ по развитию Системы.

Планируемое количество задач определяется стоимостью Контракта. Должна быть обеспечена возможность реализации 131 задачи, в том числе 36 задач в соответствии с пунктами 4.2.2.1-4.2.2.9 ТЗ.

1. Требования по развитию подсистемы «Инспекционная деятельность»

   1. Развитие функции изменения порядка контроля дат документов

В рамках выполнения работ по реализации функции по изменению порядка контроля дат документов должны быть реализованы следующие функциональные возможности:

• 
  Система должна ограничивать выбор дат в экранных формах связанных документов с целью проверки корректности ввода дат - даты должны быть ограничены периодом: один год до текущей даты и один год после. 
  

Требования к ограничениям по выбору дат, в зависимости от типа документа, могут быть уточнены и детализированы в ЧТЗ.

2. Развитие функции отображения результатов поиска в журналах и реестрах

В целях удобства просмотра результатов поиска необходима доработка отображения результатов поиска в части возможности выбора пользователем Системы количества записей, выводимых на одной странице. Необходимо выполнить доработку в экранных формах с результатами поиска в журналах, реестрах и модальных окнах выбора данных подсистемы «Инспекционная деятельность».

Требования к настройке отображения сведений должны быть уточнены и детализированы в ЧТЗ.

3. Развитие функции добавления прикрепленных файлов

В рамках доработки функции во всех документах инспекционной деятельности и административного производства необходимо вынести блок «Прикрепленные файлы» в отдельную вкладку.

Требования к функции добавления прикрепленных файлов должны быть уточнены и детализированы в ЧТЗ.

4. Развитие функции отображения данных о документах

В рамках дорабатываемой функции требуется доработка алгоритмов отбора документов с учетом подразделения для вывода данных в блок «Обратите внимание» главной страницы подсистемы «Инспекционная деятельность». В блоке «Обратите внимание» необходимо выводить только документы, относящиеся к инспекционному подразделению авторизованного пользователя Системы.

Требования к функции отбора и вывода данных должны быть уточнены и детализированы в ЧТЗ.

5. Создание функции формирования и учета предостережений

   1. Создание функции формирования и учета предостережений о недопустимости нарушения обязательных требований

В рамках выполнения работ должны быть реализованы следующие функциональные возможности по формированию и учету предостережений о недопустимости нарушения обязательных требований:

• 
  создание предостережения из акта осмотра;
  
• 
  отображение предостережения в реестре предостережений вместе со связанными с ним документами (акт, протокол, постановление и пр.);
  
• 
  формирование возражения;
  
• 
  формирования ответа на возражение;
  
• 
  должна быть реализована печатная форма предостережения с последующим выводом на печать;
  
• 
  прикрепление документов: предостережения и ответов на предостережения.
  

Требования к функции формирования и учета предостережений должны быть уточнены и детализированы в ЧТЗ.

2. Создание функции контроля сроков поступления ответов на предостережения

В рамках выполнения работ должны быть реализованы следующие функциональные возможности:

• 
  Система должна обеспечивать контроль за соблюдением сроков поступления ответов на предостережения посредством формирования системных уведомлений о выполнении предостережений и уведомлений об истечении срока формирования ответа на возражение.
  
• 
  Система должна обеспечивать формирование отчета по выданным предостережениям, а также принятым мерам по их выполнению.
  
• 
  Должна быть реализована возможность составления протокола за непредставление ответа на предостережение (ст.19.7 КоАП РФ) и ввода (размещения) результатов рассмотрения данного дела.
  

Требования к составу отчета по выданным предостережениям должны быть уточнены и детализированы в ЧТЗ.

6. Требования к развитию функций модуля «Административное производство»

   1. Развитие функции формирования и учета писем в ФССП

Система должна поддерживать функцию повторного отправления писем в ФССП после отказа в возбуждении исполнительного производства, окончания исполнительного производства или отзыва исполнительного документа.

В рамках выполнения работ должно быть произведено:

• 
  доработка статусной модели сопроводительного письма в ФССП;
  
• 
  доработка статусной модели Исполнительного производства в Деле об АП и в Деле об АП, поступившем по подведомственности;
  
• 
  доработка экранных форм вкладки «Исполнительное производство» в Деле об АП и в Деле об АП, поступившем по подведомственности;
  
• 
  доработка экранных форм сопроводительного письма в ФССП;
  
• 
  доработка печатной формы сопроводительного письма в ФССП.
  

Требования к функции повторного отправления писем в ФССП должны быть уточнены и детализированы в ЧТЗ.

2. Развитие функции учета действий по взысканию задолженности

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

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

• 
  дата действия;
  
• 
  исполнитель;
  
• 
  вид действия;
  
• 
  посещенные инстанции;
  
• 
  полученный результат;
  
• 
  вложенный документ.
  

Требования функции учета действий по взысканию задолженности должны быть уточнены и детализированы в ЧТЗ.

3. Развитие статусных моделей модуля «Административное производство»

В рамках доработки статусных моделей должно быть реализовано:

• 
  новая статусная модель Протокола (2 статуса: «Проект», «Оформлен»);
  
• 
  изменение статусной модели дела (вместо «Передано в ОАП» и «Передано по подведомственности» использовать «Передано на рассмотрение», переименовать «Вынесено решение» в «Рассмотрено»);
  

• 
  доработаны взаимосвязи между всеми сущностями в режиме каждая с каждой:
  

• 
  Протокол;
  
• 
  Дело об административном производстве;
  
• 
  Определение о передаче дела по подведомственности;
  
• 
  Определение о прекращении дела до передачи на рассмотрение;
  
• 
  Определение о возврате протокола на доработку;
  
• 
  Постановление о назначении административного наказания;
  
• 
  Реестр передачи протоколов;
  
• 
  Реестр решений по административным делам;
  
• 
  Постановление о прекращении производства по результатам рассмотрения;
  
• 
  Жалоба;
  
• 
  Постановление о прекращении исполнения постановления;
  
• 
  Исполнительное производство.
  

• 
  учет новых статусов в ПФ дела, протокола, журналов дела и протокола, реестров передачи дел об АП и реестра решений;
  
• 
  учет новых статусов в ЭФ фильтров журналов дел и протоколов, реестров передачи дел и решений доработаны в части учета новых статусов;
  
• 
  учет изменений статусных моделей в отчетах ИД и Отчетной подсистемы (не более 25 отчетов).
  

Требования к доработке журналов протоколов и дел должны быть уточнены и детализированы в ЧТЗ.

7. Требования к развитию функций модуля «Финансовый контроль»

   1. Создание функции формирования и учета приложений к платежным поручениям

В рамках разрабатываемой функции должна быть реализована загрузка приложений к платежным поручениям на общую сумму от физических лиц и индивидуальных предпринимателей. Загрузка файлов, содержащих приложения к платежным поручениям от физических лиц и индивидуальных предпринимателей, должна осуществляться в ручном режиме в модуле Финансового контроля подсистемы Инспекционной деятельности.

Платежи от физических лиц и индивидуальных предпринимателей должны автоматически распределяться по УИН и сумме платежа в приложении к платежному поручению.

Требования к функции формирования и учета приложений к платежным поручениям должны быть уточнены и детализированы в ЧТЗ.

2. Требования по развитию подсистемы «Судебное представительство»

С целью обеспечения полноценной информационной составляющей деятельности МЖИ в части судебного представительства необходимо выполнить доработку подсистемы «Судебное представительство» в части:

• 
  реализации новой статусной модели гражданского дела;
  
• 
  актуализации справочников «Статус МЖИ» и «Предмет исковых требований ЕИС МЖИ»;
  
• 
  изменения экранной формы гражданского дела:
  

• 
  добавления полей «Номер судебного дела» и «Судебная инстанция»;
  
• 
  удаления полей «Дата начала», «Дата завершения», «Заказчик иска от МЖИ» и «Основание участия», «Иск согласован с отделом правового обеспечения»;
  
• 
  добавления системного поля «Дата ввода» во вкладку «Журнал», поле заполняется для каждой стадии процесса;
  
• 
  добавления дополнительных полей «Дата документа» и «Реквизиты» рядом с полем «Предмет исковых требований»;
  
• 
  реализации группы полей «Участники процесса»: тип участника (Истец, Ответчик, 3-е лицо и Иное) и выбор субъекта;
  
• 
  изменения названия поля «Адрес состава правонарушения» на «Связанный адрес».
  
• 
  удаления вкладок «Исполнение», «Исполнительные листы», «Согласование», «Ответственные» и изменения названия вкладки «Инспекционные документы» на «Документы МЖИ».
  

• 
  разработки функции передачи данных об отмене решений, зафиксированных в подсистеме «Судебное представительство», и учета фактов отмены решений в статусных моделях документов в подсистемах Инспекционной деятельности и Переустройство и перепланировка;
  
• 
  добавления фильтра «Статус МЖИ» в текущих отчетах:
  

• 
  Дела в работе: на дату;
  
• 
  Дела в работе: за период;
  
• 
  Отчет по судебным заседаниям;
  
• 
  Отчет по результатам рассмотрения;
  
• 
  Отчет по предметам иска;
  
• 
  Отчет по исполнению;
  

• 
  Доработки Журнала дел:
  

• 
  реализации в журнале дел панелей фильтров с разбивкой по темам, например, «Номер документа», «Свойства документа», «Адрес нарушения» и т.д. При поиске по субъекту дополнительно выводить ИНН и ОГРН;
  
• 
  добавления полей «Дата ввода», «Номер судебного дела» в журнале дел;
  
• 
  реализации группы фильтров «Участники процесса»: тип участника (Истец, Ответчик, 3-е лицо и Иное) и выбор субъекта;
  
• 
  добавления дополнительных полей «Дата документа» и «Реквизиты» рядом с полем «Предмет исковых требований»;
  
• 
  изменения названия поля «Адрес состава правонарушения» на «Связанный адрес».
  

Требования к функциям модернизируемой подсистемы «Судебное представительство» должны быть уточнены и детализированы в ЧТЗ.

3. Требования по развитию подсистемы «Реестр ТСН г.Москвы»

   1. Развитие функции фильтрации на вкладке «Заключения»

На вкладке «Заключения» фильтр-поле «Округ/Район» разделить на два, с целью фильтрации по каждому полю отдельно:

• 
  фильтр-поле «Округ/Район» переименовать в «Район» и оставить логику фильтрации только по значению Района;
  
• 
  добавить новое фильтр-поле «Округ» с логикой фильтрации по значению Округа.
  

2. Развитие функции фильтрации на вкладке «Паспорт объекта»

На вкладке «Паспорт объекта»:

• 
  удалить фильтр-поле «Форма собственности»;
  
• 
  добавить фильтр-поле «Управляющая организация» с логикой фильтрации по значению Управляющей организации;
  
• 
  изменить фильтр-поле «Дата заключения» с возможностью установки значений «с» и «по» и доработать логику фильтрации записей с учетом заданного периода;
  
• 
  изменить фильтр-поле «Этажность» с возможностью установки значений «с» и «по» и доработать логику фильтрации записей с учетом заданной этажности.
  

3. Развитие функции добавления файлов на форме «Паспорт объекта»

В ЭФ «Паспорт объекта» раздела «Фото здания» реализовать:

• 
  множественное добавление файлов и сохранение Даты добавления файла;
  
• 
  для роли «Редактор фотографий» добавить разграничение прав на удаление файлов: всех файлов, только своих файлов (загруженных авторизованным пользователем Системы).
  

4. Требования к экранной форме «Импорт объекта»

В ЭФ «Импорт объектов БТИ» раздела «Справочники» добавить отражение полей:

• 
  УНОМ;
  
• 
  Период действия с;
  
• 
  Период действия по.
  

4. Требования по развитию подсистемы «Мониторинг зданий с большепролетными конструкциями»

   1. Развитие функции формирования обследования

В рамках доработки функции необходимо:

• 
  реализовать возможность при создании очередного обследования предзаполнять форму данными последнего обследования;
  
• 
  реализовать возможность открыть обследование в отдельной странице браузера;
  
• 
  добавить вертикальную прокрутку «дерева» этапов обследований.
  

2. Создание функции учета типа документов

В рамках разрабатываемой функции необходимо:

• 
  добавить в подсистему справочник «Типы документов»;
  
• 
  на ЭФ отчета об обследовании в блоке «Документы» добавить поле «Тип документа», обязательное для заполнения;
  
• 
  реализовать выбор значения поля «Тип документа» из справочника;
  
• 
  на форме реализовать сортировку вложений по Типам документов и Дате загрузки вложения;
  
• 
  доработать контроль обязательности вложения документов.
  

3. Создание функции обмена данными с адресными справочниками

В рамках разработки функции должен быть реализован механизм взаимодействия с подсистемой «Информационного взаимодействия» и подсистемы НСИ в части обновления и корректировки связей адресов объектов и их кодов БТИ Объектов МЗБК.

Взаимодействие должно осуществляться с использованием справочников подсистемы НСИ.

Требования к функции обмена данными должны быть уточнены и детализированы в ЧТЗ.

5. Требования по развитию подсистемы «Переустройство и перепланировка»

   1. Развитие статусной модели дела

В Подсистеме ПП должно быть разработано автоматическое изменение статуса с «Приостановлено» в «На рассмотрении» при поступлении документов с Портала ГУ, истечении срока приостановки по причине запроса недостающих документов (15 дней) в случае предоставления для заявления Оформление акта о завершенном переустройстве и (или) перепланировке помещения в многоквартирном доме на ранее выполненные работы без решения о согласовании переустройства и (или) перепланировки помещения в многоквартирном доме, если такое решение требуется, Согласование переустройства и (или) перепланировки помещения в многоквартирном доме необходимо реализовать возможность параллельной обработки заявлений Оформление приемочной комиссией акта о завершенном переустройстве и (или) перепланировке помещения в многоквартирном доме.

В рамках данной доработки должны быть доработаны:

• 
  статусная модель для указанных Заявлений;
  
• 
  учет изменения статусной модели в отчетах подсистемы «Переустройства и перепланировка»;
  
• 
  доработка алгоритмов сбора данных для формирования исходящих сообщений о смене статуса.
  

Требования к доработке статусной модели должны быть уточнены в ЧТЗ.

2. Развитие начального окна фильтров

Необходимо реализовать функционал создания новых и редактирования уже созданных фильтров, отображаемых на начальном окне Подсистемы ПП. При создании нового фильтра должно быть реализовано присвоение наименования фильтра и настройка отображаемых данных по таким полям как: количество дней до истечения максимального срока предоставления государственной услуги, тип заявления, тип проекта заявления, детализированный статус. Настроенные фильтры должны отображаться для подсистемы ПП в целом, а результат отображения должен учитывать права пользователя Системы в Подсистеме ПП.

Требования к доработке и созданию алгоритмов фильтров должны быть уточнены в ЧТЗ.

3. Развитие атрибутов поиска Заявлений

В Подсистеме ПП необходимо реализовать отображение полей «Проектная организация», «ИНН проектной организации», «Доверенное лицо», «Тип разработанного документа».

Поля «Проектная организация», «ИНН проектной организации», «Доверенное лицо» должны обеспечивать ввод значения вручную. Поле «Тип разработанного документа» должно обеспечивать выбор значения из справочника.

Необходимо разработать справочник «Тип разработанного документа», справочник должен включать следующие параметры:

• 
  Проект;
  
• 
  ТЗ о состоянии несущих конструкций и возможности производства работ;
  
• 
  ТЗ о безопасности и допустимости произведённых работ.
  

В Подсистеме ПП необходимо реализовать алгоритм поиска заявлений по параметрам «Проектная организация», «ИНН проектной организации», «Доверенное лицо», предусмотрев возможность выборки по типу разработанного документа:

• 
  Проект;
  
• 
  ТЗ о состоянии несущих конструкций и возможности производства работ;
  
• 
  ТЗ о безопасности и допустимости произведённых работ.
  

Необходимо обеспечить алгоритм поиска заявлений по типу проекта:

• 
  Индивидуальный;
  
• 
  Типовой.
  

Требования к функции поиска документов, к внешнему виду экранной формы, а также наполнению справочников должны быть уточнены в ЧТЗ.

4. Развитие функционала использования средств ЭП

В Подсистеме ПП необходимо реализовать отображение признака наличия ЭП уполномоченного сотрудника МЖИ на исходящем документе, направляемом заявителю на Портал ГУ.

5. Развитие формы Заявления

   1. Развитие атрибутивного состава экранной формы Заявления

В Подсистеме ПП необходимо реализовать расширение атрибутивного состава экранной формы Заявлений:

• 
  Оформление акта о завершенном переустройстве и (или) перепланировке помещения в многоквартирном доме на ранее выполненные работы без решения о согласовании переустройства и (или) перепланировки помещения в многоквартирном доме, если такое решение требуется,
  
• 
  Согласование переустройства и (или) перепланировки помещения в многоквартирном доме необходимо реализовать возможность параллельной обработки заявлений
  
• 
  Оформление приемочной комиссией акта о завершенном переустройстве и (или) перепланировке помещения в многоквартирном доме.
  

В части добавления атрибутов:

• 
  поля ввода «Наименование проектной организации», «ИНН Проектной организации», «Доверенное лицо», справочник «Тип разрабатываемого документа» со следующими значениями: Проект, ТЗ о состоянии несущих конструкций и возможности производства работ, ТЗ о безопасности и допустимости произведённых работ,
  
• 
  раздел: «Договор на размещение некапитальных объектов» с полями «Номер договора» и «Дата договора». Данные поля должны заполняться автоматически на основании заявления с Портала ГУ;
  
• 
  добавить для заявлений на оформление акта о завершенном переустройстве название полей ввода «Организация, осуществляющая авторский надзор» и «ИНН организации, осуществляющей авторский надзор» с обеспечением вывода этих полей на печатные формы результатов госуслуги.
  

Состав атрибутов на каждой экранной форме должен быть определен в ЧТЗ.

В Подсистеме ПП необходимо реализовать получение Заявлений только от Портал ГУ, в связи с переходом госуслуги в исключительно электронный вид. В рамках данного требования должны быть:

• 
  расширен атрибутивный состав экранных форм для учета добавляемых атрибутов;
  
• 
  атрибуты добавлены в соответствующие справочники в соответствии с добавляемыми атрибутами;
  
• 
  созданы новые справочники в соответствии с добавляемыми атрибутами;
  
• 
  доработаны связи между сущностями добавляемыми и существующими атрибутами;
  
• 
  доработан алгоритм обработки и разбора данных из входящего сообщения с Портал ГУ.
  

Требования к внешнему виду экранной формы и к необходимым доработкам справочников должны быть уточнены в ЧТЗ.

2. Создание вкладки в форме Заявления

Необходимо разработать вкладку, на которой будут отображаться ссылки на все Заявления, зафиксированные по идентичному адресу, и их статус.

Требования к атрибутному составу экранной формы быть уточнены в ЧТЗ.

6. Развитие процессов

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

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

Необходимо реализовать возможность отображения связанных заявлений в едином интерфейсном пространстве с отображением текущего статуса обработки заявки.

В рамках указанных требований необходимо:

• 
  Разработать и согласовать макеты интерфейса и разработать интерфейс для отображения связанных заявлений с указанием текущего статуса связанных заявлений Согласование переустройства и (или) перепланировки помещения в многоквартирном доме, Оформление приемочной комиссией акта о завершенном переустройстве и (или) перепланировке помещения в многоквартирном доме, Продление решения о согласовании переустройства и (или) перепланировки помещения в многоквартирном доме, Отзыв решения о согласовании переустройства и (или) перепланировки помещения в многоквартирном доме (не менее пяти макетов и девяти экранных форм);
  
• 
  Изменить алгоритмы связывания дел, чтобы заявления на Продление решения о согласовании переустройства и (или) перепланировки помещения в многоквартирном доме, Отзыв решения о согласовании переустройства и (или) перепланировки помещения в многоквартирном доме могли связаться с Согласование переустройства и (или) перепланировки помещения в многоквартирном доме вне зависимости от статуса связанного Оформление акта о завершенном переустройстве и (или) перепланировке помещения в многоквартирном доме на ранее выполненные работы без решения о согласовании переустройства и (или) перепланировки помещения в многоквартирном доме, если такое решение требуется. После связывания заявления существовали как отдельные сущности со своими документами, статусными моделями и процессами обработки;
  
• 
  Разработать алгоритмы обработки заявлений Согласование переустройства и (или) перепланировки помещения в многоквартирном доме, Оформление приемочной комиссией акта о завершенном переустройстве и (или) перепланировке помещения в многоквартирном доме, Продление решения о согласовании переустройства и (или) перепланировки помещения в многоквартирном доме, Отзыв решения о согласовании переустройства и (или) перепланировки помещения в многоквартирном доме;
  
• 
  Разработать статусную модель обработки заявлений Согласование переустройства и (или) перепланировки помещения в многоквартирном доме, Оформление приемочной комиссией акта о завершенном переустройстве и (или) перепланировке помещения в многоквартирном доме, Продление решения о согласовании переустройства и (или) перепланировки помещения в многоквартирном доме, Отзыв решения о согласовании переустройства и (или) перепланировки помещения в многоквартирном доме;
  
• 
  Разработать алгоритмы сбора данных для формирования и отправки исходящих сообщений для обновления статусов в ЛК Заявителя Портал ГУ посредством РСМЭВ для заявлений Согласование переустройства и (или) перепланировки помещения в многоквартирном доме, Оформление приемочной комиссией акта о завершенном переустройстве и (или) перепланировке помещения в многоквартирном доме, Продление решения о согласовании переустройства и (или) перепланировки помещения в многоквартирном доме, Отзыв решения о согласовании переустройства и (или) перепланировки помещения в многоквартирном доме;
  
• 
  Доработать алгоритмы сбора данных для формирования и отправки исходящих межведомственных запросов посредством РСМЭВ для заявлений Согласование переустройства и (или) перепланировки помещения в многоквартирном доме, Оформление приемочной комиссией акта о завершенном переустройстве и (или) перепланировке помещения в многоквартирном доме;
  
• 
  Разработать логирование изменений для заявлений Согласование переустройства и (или) перепланировки помещения в многоквартирном доме, Оформление приемочной комиссией акта о завершенном переустройстве и (или) перепланировке помещения в многоквартирном доме, Продление решения о согласовании переустройства и (или) перепланировки помещения в многоквартирном доме, Отзыв решения о согласовании переустройства и (или) перепланировки помещения в многоквартирном доме с указанием измененных данных и ФИО пользователя Системы внесшего изменения;
  
• 
  Доработать алгоритмы доступности формирования печатных форм в зависимости от типа заявления статуса заявления;
  
• 
  доработать алгоритмы сбора данных в отчеты и фильтры;
  
• 
  Доработать логику заполнения печатных форм.
  

Требования модернизации функции одновременной (параллельной) доработки заявлений должны быть уточнены в ЧТЗ.

7. Создание функции получения данных от подсистемы «Информационное взаимодействие» в рамках интеграции с внутренними подсистемами ЕИС МЖИ

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

• 
  экспликации помещений всего многоквартирного дома;
  
• 
  поэтажные планы этажа, на котором расположено перепланированное помещение;
  
• 
  поэтажные планы вышерасположенного и нижерасположенного этажей при наличии;
  
• 
  наличии Договора на размещение некапитальных объектов в момент регистрации дела;
  
• 
  выписка из государственного реестра прав на недвижимое имущество.
  

Требования к получению данных от подсистемы «Информационное взаимодействие» должны быть уточнены в ЧТЗ.

8. Создание функции получения данных от подсистемы «Инспекционная деятельность»

Для Подсистемы ПП необходимо разработать алгоритм получения данных из подсистемы «Инспекционная деятельность». В Подсистеме ПП:

• 
  должна отображаться информация о наличии распоряжения о проверке и предписания в статусе «На контроль»;
  
• 
  должна отображаться информация о вынесении постановления с типом наказания «штраф» и об оплате штрафа. Учет данной информации в атрибутах карточки заявления, в статусной модели заявления. При оплате штрафа статус дела должен измениться с «Приостановлено» на статус «На рассмотрении» с перерасчетом даты оказания услуги;
  
• 
  должны подтягиваться статусы дел по одинаковым адресам объекта в связи с окончанием приостановок.
  

В рамках указанных требований необходимо доработать форму отображения информации из подсистемы ИД, вызываемая со вкладки «Ход рассмотрения». Форма отображения информации из подсистемы ИД должна отображать данные о наличии предписания и распоряжения в подсистеме «Инспекционная деятельность» при совпадении Адреса объекта в подсистемах с возможностью отобразить номер и дату предписания и распоряжения на вкладке «Ход рассмотрения».

Необходимо доработать алгоритм получения данных о вынесении решения и об исполнении по постановлению об административном наказании с указанием суммы штрафа из подсистемы ИД. Необходимо реализовать отображение данных указанных выше в блоке «Приостановлено» на ЭФ Ход рассмотрения заявления Оформление акта о завершенном переустройстве и (или) перепланировке помещения в многоквартирном доме на ранее выполненные работы без решения о согласовании переустройства и (или) перепланировки помещения в многоквартирном доме, если такое решение требуется и обновляться по расписанию . При получении информации об исполнении такого постановления Заявление должно переходить в статус «На рассмотрении».

Данные о наличии протоколов не должны отображаться на вкладке Ход рассмотрения в блоке «Приостановлено». В блоке «Приостановление» на вкладе «Ход рассмотрения» должны отображаться Номер постановления и Дата постановления.

В рамках данного требования должна быть доработана интеграция с подсистемой ИД, статусная модель заявления и экранная форма Ход рассмотрения блок Приостановки.

9. Развитие отчетов. Развитие журнала «Список заявлений»

В рамках доработки журнала «Список заявлений» необходимо реализовать поля:

• 
  тип заявления;
  
• 
  дата приостановки (если дело находится в статусе приостановлено);
  
• 
  доверенное лицо (ФИО, если заполнены соответствующие поля Заявления);
  
• 
  согласование МКА и ДКН (требуется / не требуется);
  
• 
  право владения;
  
• 
  вид работ;
  
• 
  проект (наименование организации - разработчик проекта);
  
• 
  заключение о возможности производства работ (наименование организации - разработчик проекта);
  
• 
  техническое заключение о допустимости и безопасности (наименование организации - разработчик проекта)
  
• 
  тип проекта (индивидуальный, типовой).
  

Перечень полей и справочники, используемые при их наполнении должны быть уточнены в ЧТЗ.

6. Требования по развитию Отчетной подсистемы

   1. Развитие функций аналитического хранилища

В рамках доработки функций аналитического хранилища Отчетной подсистемы (BI) требуется реализовать ввод новых предметных областей и критериев отбора для формирования аналитических отчетов с использованием приведенных ниже атрибутов в разрезе подсистем ЕИС МЖИ:

• 
  добавить предметные области по атрибутам подсистемы «Реестр ТСН г.Москвы»:
  

• 
  «Выявленные дефекты». Информацию для формирования брать из блоков «Выявленные дефекты» раздела «Результаты обследования» документа «Заключение».
  
• 
  «Объект культурного наследия» - область в разделе «БТИ».
  
• 
  «Дополнительные данные» в разделе «Доп. информация по заключению». Информацию для формирования брать из последних одноименных полей документа «Заключение».
  

• 
  добавить предметные области по всем доступным атрибутам Подсистемы МЗБК, включая текстовые. Реализовать формирование новых регламентированных отчетов (не менее 10 и не более 15);
  
• 
  добавить предметные области по атрибутам «Подсистемы Переустройство и перепланировка».
  

Требования к функциям аналитического хранилища должны быть уточнены и детализированы в ЧТЗ.

2. Развитие функции формирования аналитического отчета по вынесенным постановлениям

В рамках дорабатываемой функции необходимо в отчете «105 Отчет по вынесенным постановлениям» реализовать отображение сведений о действиях по исполнительным производствам. Необходимо выводить данные, которые добавляются в постановлении в п. 4.2.2.1.6.2:

• 
  Дата действия;
  
• 
  Инспектор;
  
• 
  Вид действия;
  
• 
  Посещенные инстанции;
  
• 
  Полученный результат.
  

Требования к функции формирования аналитического отчета должны быть уточнены и детализированы в ЧТЗ.

7. Требования по развитию подсистемы Администрирования

   1. Развитие функции управления ролями

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

В части управления ролями пользователей подсистемы МЗБК требуется выполнить следующие доработки:

• 
  реализация Адресных списков (связи Подрядчик – Адрес объекта обследования, согласно данным гос. контракта);
  
• 
  доработка ролевого механизма в рамках разграничения прав доступа на внесение Подрядчиком отчетов об обследованиях только по своим адресным спискам;
  
• 
  доработка ролевого механизма в рамках предоставления прав доступа определенным пользователям Системы согласования и возврата на доработку Подрядчиком отчетов об обследовании с указанием ошибок.
  

Требования к функциям управления ролями должны быть уточнены и детализированы в ЧТЗ.

8. Требования по развитию подсистемы «Реестр сведений о лицензиатах»

   1. Создание функции формирования и учета электронной очереди на квалификационный экзамен

В рамках разрабатываемой функции требуется:

• 
  Разработать сервисы интеграции с Портал ГУ в части:
  

• 
  получения и отправки заявлений о допуске к квалификационному экзамену;
  
• 
  проверки на уникальность заявления о допуске к квалификационному экзамену;
  
• 
  получения и отправки статусов заявлений;
  
• 
  отправки расписания (временных слотов), доступного для выбора при подаче заявления.
  

• 
  Разработать модуль для работы с расписанием проведения квалификационных экзаменов и заявлениями о допуске к квалификационному экзамену (ЭФ расписания, ЭФ экзамена), обеспечивающий:
  

• 
  планирование экзамена (создание, редактирование, удаление);
  
• 
  утверждение экзамена и создание временных слотов утверждённого экзамена;
  
• 
  отмену утвержденного экзамена и его временных слотов;
  
• 
  подачу, регистрацию и обработку заявлений о допуске к квалификационному экзамену;
  
• 
  добавление заявителя в очередь при отсутствии свободных временных слотов;
  
• 
  регистрацию на экзамен и формирование регистрационного списка претендентов;
  
• 
  определение результатов экзамена и составление протокола;
  
• 
  уведомление о результатах экзамена, посредством отправки статуса Заявления и приложенного документа «Уведомление о результатах экзамена» в ЛК Портал ГУ;
  
• 
  фильтрацию расписания (временных слотов) проведения экзаменов;
  
• 
  фильтрацию заявлений;
  
• 
  формирование печатных форм (Уведомления о допуске или не допуске на экзамен, подписанные ЭП, Лист регистрации, Протокол результатов квалификационного экзамена).
  

Модуль должен содержать следующие экранные формы:

• 
  Расписание проведения квалификационных экзаменов (для создания и фильтрации);
  
• 
  Экзамена;
  

Примечание: на ЭФ должны быть размещены такие атрибуты, как:

• 
  Дата и время проведения экзамена:
  
• 
  Место проведения квалификационного экзамена:
  
• 
  Время начала и окончания регистрации:
  
• 
  Кол-во планируемых слотов (мест на экзамен)
  
• 
  Статус экзамена
  
• 
  Статусы слотов.
  
• 
  Документы экзамена;
  
• 
  Заявления на экзамен;
  

Примечание: на ЭФ должны быть размещены претенденты на экзамен (ссылки на поданные Заявления о допуске к квалификационному экзамену с данными о претенденте, требующимся для заполнения ПФ документов КЭ, такими как: Индивидуальный номер претендента по регистрационному списку присутствующих; Статус претендента (удален, не явился, допущен); Процент успешно выполненных тестов от максимально возможного кол-ва баллов (200); Результат квалификационного экзамена (сдан/не сдан)

• 
  Реестра Заявлений (для создания, поиска и фильтрации заявлений о допуске к квалификационному экзамену);
  
• 
  Заявления о допуске к квалификационному экзамену; (с атрибутивным составом согласно форме, утвержденной решением Лицензионной комиссии по лицензированию деятельности по управлению многоквартирными домами в городе Москве (протокол №1 от 22.01.2015))
  
• 
  МВ запросы;
  

Примечание: на ЭФ должны быть размещены такие атрибуты, как:

• 
  наименование запрашиваемого документа (в частности, «Наличие (отсутствие) информации в реестре дисквалифицированных лиц»);
  
• 
  дата запроса.
  
• 
  Документы заявления;
  
• 
  Решение по заявлению.
  

Требования к функции формирования и учета электронной очереди на квалификационный экзамен управления ролями должны быть уточнены и детализированы в ЧТЗ.

2. Требования к развитию функций модуля «Внесение изменений в Реестр лицензий»

В рамках доработки модуля требуется:

• 
  Дополнить справочник «Оснований» значениями:
  

• 
  Решение суда,
  
• 
  Решение ОГЖН.
  

• 
  Доработать логику отображения значений в поле Оснований «Решение суда» и «Решение ОГЖН». Они должны отображаться в выпадающем списке значений и быть доступными для выбора только:
  

• 
  при создании Заявления посредством «Одного окна»,
  
• 
  с целью обращения «Исключение дома из реестра».
  

• 
  Доработать ФЛК в части скрытия вкладки «Ход рассмотрения» для цели обращения «Исключение дома из реестра» и оснований «Решение суда» и «Решение ОГЖН»;
  
• 
  В закладке «Ход рассмотрения» создать блоки для ввода данных о результатах проверок на соответствие правилам Порядка (938-ПР);
  
• 
  Для каждого блока предусмотреть:
  

• 
  вставку описания нарушений из справочника;
  
• 
  возможность дополнительного ручного ввода операторского текста в поле «Описание нарушений после приостановки».
  

• 
  Реализовать ФЛК по вводу результатов первичного осмотра документов и осмотра документов после приостановки, согласно материалам, полученным от МЖИ.
  
• 
  (детальное описание поведенческих сценариев Заявления по ГФ (на вкладке «Ход рассмотрения») в ходе заполнения результатов Первичного и Дополнительного осмотров после приостановки будет уточнено и описано в отдельном ЧТЗ);
  
• 
  Реализовать логику определения Типа решения и недоступность его редактирования:
  

• 
  всегда «положительное решение» для Цели обращения «Исключение дома из реестра» на основании «Решения суда» и «Решения ОГЖН»,
  
• 
  в зависимости от результатов проведенной проверки, заполненных на форме «Ход рассмотрения», а также при изменении результатов проверки на вкладке «Ход рассмотрения» и пересохранении Заявления.
  
• 
  (детальное описание поведенческих сценариев будет уточнено и описано в отдельном ЧТЗ);
  

• 
  Обеспечить формирование печатных форм (далее - ПФ) документов с данными, указанными на форме «Ход рассмотрения».
  

Реализовать ПФ:

• 
  Заключение-1;
  
• 
  Заключение-2;
  
• 
  Распоряжение с положительным результатом;
  
• 
  Распоряжение о приостановке;
  
• 
  Распоряжение об отказе.
  

• 
  Доступность ПФ должна быть в соответствующих статусах Заявления и определенном типе решения, согласно ФЛК. (детальное описание поведенческих сценариев будет уточнено и описано в отдельном ЧТЗ).
  

9. Требования по созданию подсистемы «Информационное взаимодействие» в рамках интеграции со внешними системами

В рамках работ по данному ТЗ должна быть создана подсистема «Информационное взаимодействие».

В подсистеме должны быть реализованы интеграции со следующими смежными (в том числе межведомственными) информационными ресурсами, требования к которым приведены в соответствующих пунктах ТЗ связанных с подсистемами в интересах которых создается интеграционное взаимодействие:

• 
  ИС ПДПС, в части передачи в ИС ПДПС (Подсистема СОЭСГ) сведений о выявленных нарушениях и фотографий нарушений;
  
• 
  РСМЭВ в части отправки и получения результатов запросов в БТИ на предоставление:
  

• 
  экспликации помещений всего многоквартирного дома;
  
• 
  поэтажные планы этажа, на котором расположено перепланируемое помещение;
  
• 
  поэтажные планы вышерасположенного и нижерасположенного этажей при наличии;
  

• 
  РСМЭВ в части автоматизации отправки и получения результатов запросов в Росреестр;
  
• 
  ДГИ в части автоматизации отправки и получения результатов запросов о наличии Договора на размещение некапитальных объектов.
  

1. Развитие функции информационного обмена с ИС ПДПС

Должна быть реализована функция формирования и отправки в ИС ПДПС (Подсистема СОЭСГ) запросов, содержащих следующие сведения из актов осмотра и проверок:

• 
  ФИО автора акта осмотра или проверки;
  
• 
  адрес осмотра или проверки;
  
• 
  номер акта осмотра или проверки;
  
• 
  признак отсутствия выявленных нарушений (при наличии);
  
• 
  код нарушения (при наличии);
  
• 
  описание нарушения (при наличии);
  
• 
  фотография нарушения (при наличии).
  

Требования к функции информационного обмена должны быть уточнены и детализированы в ЧТЗ.

2. Создание функции автоматизированной отправки запросов в БТИ

Необходимо разработать процесс автоматического формирования и отправки межведомственных запросов посредством РСМЭВ на предоставление: экспликации помещений всего многоквартирного дома; поэтажные планы этажа, на котором расположено перепланированное помещение; поэтажные планы вышерасположенного и нижерасположенного этажей при наличии. Должно осуществляться получение и обработка ответов, а также отображение полученных документов в интерфейсе подсистемы ПП.

В рамках данного требования необходимо разработать следующие алгоритмы:

• 
  Алгоритмы автоматизации сбора данных для формирования исходящих межведомственных запросов и их отправки в РСМЭВ для заявлений Согласование переустройства и (или) перепланировки помещения в многоквартирном доме, Оформление приемочной комиссией акта о завершенном переустройстве и (или) перепланировке помещения в многоквартирном доме по согласованию, Оформление приемочной комиссией акта о завершенном переустройстве и (или) перепланировке помещения в многоквартирном доме по эскизу, Оформление акта о завершенном переустройстве и (или) перепланировке помещения в многоквартирном доме на ранее выполненные работы без решения о согласовании переустройства и (или) перепланировки помещения в многоквартирном доме, если такое решение требуется;
  
• 
  Получения, обработки и отображения в интерфейсе ответов на межведомственные запросы.
  

Должен быть доработан механизм автоматического формирования и отправки запросов на несколько объектов, без необходимости ручных запросов.

Требования к доработке автоматизации отправки запросов в ЕИС БТИ должны быть уточнены в ЧТЗ.

3. Создание функции автоматизированной отправки запросов в Росреестр

Необходимо разработать процесс автоматического формирования и отправки межведомственных запросов посредством РСМЭВ в Росреестр.

Необходимо реализовать требования протокола запроса в Росреестр, с учетом признаков «Кадастровый номер» и «Номер этажа».

В рамках данного требования необходимо разработать следующие алгоритмы:

• 
  Алгоритмы автоматизации сбора данных для формирования исходящих межведомственных запросов и отправки этих запросов в РСМЭВ для заявлений: Согласование переустройства и (или) перепланировки помещения в многоквартирном доме, Оформление приемочной комиссией акта о завершенном переустройстве и (или) перепланировке помещения в многоквартирном доме по согласованию, Оформление приемочной комиссией акта о завершенном переустройстве и (или) перепланировке помещения в многоквартирном доме по эскизу, Оформление акта о завершенном переустройстве и (или) перепланировке помещения в многоквартирном доме на ранее выполненные работы без решения о согласовании переустройства и (или) перепланировки помещения в многоквартирном доме, если такое решение требуется;
  
• 
  Получения, обработки и отображения в интерфейсе ответов на межведомственные запросы.
  

Должен быть доработан механизм автоматического формирования и отправки запросов на несколько объектов в одном заявлении (актуально при объединении квартир) без необходимости ручного запроса.

Требования к доработке автоматизации отправки запросов в Росреестр должны быть уточнены в ЧТЗ.

4. Создание функции автоматизированной отправки запросов в ДГИ

При наличии данных о Договоре на размещение некапитальных объектов необходимо разработать автоматическое формирование и отправку межведомственного запроса в ДГИ о наличии Договора на размещение некапитальных объектов в момент регистрации дела в ЕИС МЖИ.

В рамках автоматизации отправки запросов ДГИ должны быть реализованы алгоритмы отправки межведомственного запроса по РСМЭВ, прием ответа по межведомственному запросу по ЕПТ МВ, отображение ответа в интерфейсе подсистемы ПП.

Требования к доработке автоматизации отправки запросов в ДГИ должны быть уточнены в ЧТЗ.