Номер извещения: 0158300007826000175

Общая информация о закупке

Внимание! За нарушение требований антимонопольного законодательства Российской Федерации о запрете участия в ограничивающих конкуренцию соглашениях, осуществления ограничивающих конкуренцию согласованных действий предусмотрена ответственность в соответствии со ст. 14.32 КоАП РФ и ст. 178 УК РФ

Способ определения поставщика (подрядчика, исполнителя): Электронный аукцион

Наименование электронной площадки в информационно-телекоммуникационной сети «Интернет»: РТС-тендер

Адрес электронной площадки в информационно-телекоммуникационной сети «Интернет»: http://www.rts-tender.ru

Размещение осуществляет: Уполномоченный орган АДМИНИСТРАЦИЯ ГОРОДА ТАГАНРОГА

Наименование объекта закупки: Передача прав на автоматизированную систему управления имущественно-земельным комплексом и комплекс услуг по ее внедрению.

Этап закупки: Подача заявок

Сведения о связи с позицией плана-графика: 202601583000061001000112

Контактная информация

Размещение осуществляет: Уполномоченный орган

Организация, осуществляющая размещение: АДМИНИСТРАЦИЯ ГОРОДА ТАГАНРОГА

Почтовый адрес: Российская Федерация, 347900, Ростовская обл, Таганрог г, Петровская ул, Д.73

Место нахождения: Российская Федерация, 347900, Ростовская обл, Таганрог г, Петровская ул, Д.73

Ответственное должностное лицо: Чумаколенко Н. Н.

Адрес электронной почты: omz@tagancity.ru

Номер контактного телефона: 7-8634-312791

Дополнительная информация: Заказчик : Комитет по управлению имуществом г. Таганрога, 347900, Российская Федерация, Ростовская область, г. Таганрог, ул. Греческая, 58. ИНН: 6154005874. тел. +7(8634) 613-980. Адрес электронной почты: kui@tagancity.ru Ответственное должностное лицо заказчика: Пономаренко Юлия Васильевна - председатель Комитета по управлению имуществом г. Таганрога. Контактное лицо Заказчика: Логунова Эльвира Алексеевна / начальник планово-организационного отдела Комитета по управлению имуществом г. Таганрога / сотрудник контрактной службы ответственный за закупку / тел. +7(8634) 613-406

Регион: Ростовская обл

Информация о процедуре закупки

Дата и время начала срока подачи заявок: 28.04.2026 10:19 (МСК)

Дата и время окончания срока подачи заявок: 07.05.2026 10:00 (МСК)

Дата проведения процедуры подачи предложений о цене контракта либо о сумме цен единиц товара, работы, услуги: 07.05.2026

Дата подведения итогов определения поставщика (подрядчика, исполнителя): 12.05.2026

Начальная (максимальная) цена контракта

Начальная (максимальная) цена контракта: 8 200 000,00

Валюта: РОССИЙСКИЙ РУБЛЬ

Идентификационный код закупки (ИКЗ): 263615400587461540100103490010000244

Информация об объекте закупки

Код позиции - Наименование товара, работы, услуги - Товарный знак - Ед. измерения - Количество (объем работы, услуги) - Цена за ед., ? - Стоимость, ?

- 58.29.11.000 58.29.11.000-00000003 - Программное обеспечение Передача неисключительных прав на Автоматизированную систему управления имущественно-земельным комплексом:1. Требования к структуре Системы: 1.1. Система должна быть построена по 3х-звенной архитектуре и состоять из следующих компонентов: 1.1.1. Системы управления базами данных (СУБД) – предназначены для хранения и управления информацией базы данных Системы. 1.1.2. Сервер приложений – промежуточное звено обеспечения взаимодействия клиентских мест и СУБД. 1.1.3. Клиентские места – «тонкий» (Desktop) клиент - пользовательские приложения, устанавливаемые на рабочих местах пользователей для предоставления доступа пользователей к функциям Системы Соответствие 2. Требования к используемым СУБД: 2.1. Система должна быть совместима с СУБД PostgreSQL версии не менее 14.10. 2.2. СУБД не должна иметь ограничений по размеру базы данных и не должна требовать дополнительных обязательных расходов на сопровождение Соответствие 60. Средства формирования межведомственных запросов из карточки объекта Системы: 60.1. Формирование межведомственных запросов из карточки объекта Системы подразумевает возможность автоматического формирования запроса в системе СМЭВ. Параметры, необходимые для формирования запроса в автоматическом режиме должны заполняться на основе данных, размещенных в соответствующей карточке объекта учета, из которой формируется запрос. 60.2. При формировании запроса пользователь должен предварительно выбрать услугу (сервис), для которой формируется запрос. Выбор должен производиться из перечня услуг (сервисов), для которых доступно формирование запроса из карточки объекта данного типа. 60.3. Формирование запроса должно быть реализовано с использованием динамически формируемого перечня пунктов подменю пункта «СМЭВ» меню карточки (или кнопки СМЭВ). 60.4. Динамически формируемый перечень подменю должна соответствовать перечню доступных для запроса услуг/сервисов с отбивкой сепаратором услуг/сервисов различных организаций (услуги/сервисы различных организаций визуально должны быть отделены друг от друга) Соответствие - Программный комплекс «ЕДИНАЯ РЕЕСТРОВАЯ ИНФОРМАЦИОННО-АНАЛИТИЧЕСКАЯ СИСТЕМА» Допускается поставка эквивалента - Штука - 1,00 - 3 948 350,00 - 3 948 350,00

КОМИТЕТ ПО УПРАВЛЕНИЮ ИМУЩЕСТВОМ Г. ТАГАНРОГА - 1 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Передача неисключительных прав на Автоматизированную систему управления имущественно-земельным комплексом:1. Требования к структуре Системы: 1.1. Система должна быть построена по 3х-звенной архитектуре и состоять из следующих компонентов: 1.1.1. Системы управления базами данных (СУБД) – предназначены для хранения и управления информацией базы данных Системы. 1.1.2. Сервер приложений – промежуточное звено обеспечения взаимодействия клиентских мест и СУБД. 1.1.3. Клиентские места – «тонкий» (Desktop) клиент - пользовательские приложения, устанавливаемые на рабочих местах пользователей для предоставления доступа пользователей к функциям Системы Соответствие Значение характеристики не может изменяться участником закупки 2. Требования к используемым СУБД: 2.1. Система должна быть совместима с СУБД PostgreSQL версии не менее 14.10. 2.2. СУБД не должна иметь ограничений по размеру базы данных и не должна требовать дополнительных обязательных расходов на сопровождение Соответствие Значение характеристики не может изменяться участником закупки 60. Средства формирования межведомственных запросов из карточки объекта Системы: 60.1. Формирование межведомственных запросов из карточки объекта Системы подразумевает возможность автоматического формирования запроса в системе СМЭВ. Параметры, необходимые для формирования запроса в автоматическом режиме должны заполняться на основе данных, размещенных в соответствующей карточке объекта учета, из которой формируется запрос. 60.2. При формировании запроса пользователь должен предварительно выбрать услугу (сервис), для которой формируется запрос. Выбор должен производиться из перечня услуг (сервисов), для которых доступно формирование запроса из карточки объекта данного типа. 60.3. Формирование запроса должно быть реализовано с использованием динамически формируемого перечня пунктов подменю пункта «СМЭВ» меню карточки (или кнопки СМЭВ). 60.4. Динамически формируемый перечень подменю должна соответствовать перечню доступных для запроса услуг/сервисов с отбивкой сепаратором услуг/сервисов различных организаций (услуги/сервисы различных организаций визуально должны быть отделены друг от друга) Соответствие Значение характеристики не может изменяться участником закупки 60.5. В случае, если карточка объекта учета не содержит всей необходимой для формирования запроса информации, пользователь должен быть в развернутой форме информирован о характере возникшей ошибки с указанием конкретных реквизитов объекта, которые должны быть заполнены для корректного формирования запроса. 60.6. Должна быть предусмотрен режим ручного формирования запроса из карточки объекта. В данном режиме Система инициирует ручное создание запроса, а также производит автоматическое заполнение параметров запроса сведениями, содержащимися в карточке соответствующего объекта учета. 60.7. После этого пользователю предоставляется возможность самостоятельной корректировки сведений (параметров запроса) и ручного формирования межведомственного запроса. 60.8. После формирования запроса пользователю должно быть выведено соответствующее сообщение с указанием кода сформированного запроса в журнале запросов Соответствие Значение характеристики не может изменяться участником закупки 61. Средства формирования межведомственных запросов в режиме массовой операции: 61.1. Для формирования межведомственных запросов в режиме массовой операции должен быть задействован стандартный механизм Системы работы с массовыми операциями (выбора объектов для выполнения массовой операции). 61.2. Выбор объектов для массовой операции должен производиться с использованием следующих средств: 61.2.1. Из списка объектов учета любых типов основного окна Системы. 61.2.2. Из экранных форм Системы, отображающих списки объектов учета произвольных типов. 61.2.3. Из окна результата запроса подсистемы «Библиотека запросов». 61.3. Выбор услуги (сервиса) для формирования запроса должен быть реализован путем динамического создания пунктов подменю пункта СМЭВ. Пункты подменю должны содержать полный перечень всех услуг/сервисов, доступных для формирования из карточек объектов учета, доступных для выполнения массовой операции в текущем режиме работы. 61.4. Выполнение массовой операции должно производиться пообъектно способом, аналогичным формированию запроса из карточки объекта учета соответствующего типа (описание приведено выше). 61.5.В случае, если операция формирования запроса для данного вида объекта учета недоступна (в соответствии с настройками) или для формирования запроса недостаточно информации, по таким объектам формируется ошибка по правилам функционирования функционала массовых операций (объект помечается красным фоном, формируется развернутое сообщение об ошибке (содержит четкое описание сути ошибки), объект пропускается, происходит переход к обработке следующего объекта). 61.6.Операции, выполняемые в режиме массовой операции, должны протоколироваться по общим принципам (индивидуальное протоколирование каждого сформированного в режиме массовой операции межведомственного запроса) Соответствие Значение характеристики не может изменяться участником закупки 62. Средства формирования межведомственных запросов в режиме регламентной операции: 62.1. Регламентная операция представляет собой выполнение некоторого запроса по определенному расписанию, межведомственные запросы формируются в автоматическом режиме для каждого объекта, информация по которому возвращена запросом. 62.2. Средства формирования межведомственных запросов в режиме регламентных операций должны обеспечивать ведение библиотеки регламентных операций, средства добавления, изменения, удаления регламентных операций, приостановки выполнения регламентных операций. 62.3. Библиотека регламентных операций должна представлять собой список регламентных операций, содержащий следующие атрибуты: 62.3.1. Код идентификатор (код) регламентной операции. 62.3.2. Наименование - наименование регламентной операции. 62.3.3. Организация – наименование организации, предоставляющей услугу/сервис. 62.3.4. Сервис наименование услуги/сервиса для формирования запроса в режиме регламентной операции. 62.3.5. Признак успешности предыдущего выполнения. 62.3.6. Дата, время следующего выполнения. 62.3.7. Состояние (запланировано, приостановлено). 62.3.8. Приостановленные регламентные операции или регламентные операции, для которых не определено время следующего запуска должно визуально выделяться (серый текст шрифта). 62.3.9. Регламентные операции, по которым предыдущий вызов был завершен ошибкой должны визуально выделяться (розовый фон). 62.3.10. Для каждой регламентной операции должны быть определены: 62.3.10.1. Код – присваивается автоматически. 62.3.10.2. Наименование регламентной операции. 62.3.10.3. Описание регламентной операции – текст произвольного размера. 62.3.10.4. Услуга/сервис – выбор из списка услуг/сервисов, доступных для формирования запросов в режиме регламентной операции. 62.4. Расписание выполнения операции (стандартный функционал для формирования расписаний) – в определенное время разово, ежечасно, ежедневно, еженедельно в определенные дни Соответствие Значение характеристики не может изменяться участником закупки 63. Средства подписания запросов электронной подписью: 63.1. С целью обеспечения возможности автоматизированного формирования запросов в пакетном режиме, а также автоматического формирования запросов в режиме массовой операции в Подсистеме должны быть реализованы средства централизованного (серверного) принципа подписания запросов электронной подписью. Для этого в составе подсистемы должен быть реализован сервер ЭП (сервер электронной подписи). Это означает, что в подсистеме должна быть реализована возможность добавления одной или более учетных записей организаций/пользователей организаций, настройки и реквизиты которых будут использоваться для формирования межведомственных запросов и подписания их электронной подписью. Для каждой учетной записи должна быть обеспечена возможность сопоставления с ЭП-ОВ (электронной подписи органа власти) и ЭП-СП – электронная подпись служебного пользования уполномоченного лица (руководителя), которые загружены на сервер ЭП. 63.2. Для каждого пользователя Системы, в должностные обязанности которого входит возможность формирования межведомственных запросов, должна быть предусмотрена возможность указать учетную запись организации/уполномоченного лица организации, электронные подписи которой будут использоваться для автоматического подписания запросов, сформированных соответствующим пользователем. 63.3. Запросы, формируемые средствами подсистемы в любом из описанных выше режимов, должны подписываться ЭП-ОВ и/или ЭП-СП в зависимости от методических рекомендаций для соответствующего вида сведений Соответствие Значение характеристики не может изменяться участником закупки 64. Средства ручного внесения результатов запросов, которые не формировались средствами: подсистемы 64.1. В подсистеме должны быть предусмотрены средства внесения результатов запросов, полученных из внешних источников, то есть без использования средств подсистемы. 64.2. При ручной загрузке результата подсистема должно быть инициировано автоматическое занесение соответствующего запроса в журнал запросов. Дальнейшая обработка загруженного вручную результата должна производиться стандартным способом (загрузка результата в интегрированное хранилище, применение результата (внесение изменений в единую база данных 64.3. Системы на основе полученных сведений)). 64.4. В протокол работы с запросом автоматически должна быть добавлена запись, что результат загружен вручную без использования межведомственного взаимодействия Соответствие Значение характеристики не может изменяться участником закупки 65. Средства ручного внесения результатов запросов, которые не формировались средствами подсистемы: 65.1. В подсистеме должны быть предусмотрены средства внесения результатов запросов, полученных из внешних источников, то есть без использования средств подсистемы. 65.2. При ручной загрузке результата подсистема должно быть инициировано автоматическое занесение соответствующего запроса в журнал запросов. Дальнейшая обработка загруженного вручную результата должна производиться стандартным способом (загрузка результата в интегрированное хранилище, применение результата (внесение изменений в единую база данных Системы на основе полученных сведений)). 65.3. В протокол работы с запросом автоматически должна быть добавлена запись, что результат загружен вручную без использования межведомственного взаимодействия Соответствие Значение характеристики не может изменяться участником закупки 66. Средства предотвращения повторного формирования запросов: 66.1. Подсистема должна содержать средства повторного формирования запросов на одни и те же объекты учета. 66.2. Под повторным формированием запроса понимается формирование запроса на объект, на который уже был ранее сформирован межведомственный запрос на получение сведений по этой же услуге (сервису), по которому сведения получены, но еще не использованы (запрос не «закрыт»), или запрос находится в состоянии ожидания сведений (ответа), то есть по запрос не был отклонен (не находится в состоянии ошибки), сведения еще не получены. 66.3. В ходе проверки на наличие предыдущих запросов следует учесть, что запрос на данный объект учета мог быть сформирован не из текущей карточки, например, текущий запрос получения выписки из ЕГРН на объект имущества формируется из карточки договора приватизации этого объекта имущества, однако ранее был сформирован запрос на этот же объект, но из карточки другого договора или самого объекта. Должна быть предусмотрена возможность определения возможности проверки на наличие сформированных ранее запросов в ручном режиме – возможность должна быть определена на этапе реализации. При наличии возможности указанный функционал подлежит реализации. 66.4. Для каждого сервиса/услуги должна быть предусмотрена возможность настройки количества дней, в течение которых результат предыдущего запроса можно считать актуальным. В случае, если такая настройка произведена, то при ручном формировании запроса или формировании запроса из карточки объекта, при наличии ранее полученного ответа подсистема должна предупреждать пользователя, что уже получен результат на соответствующий запрос с указанием даты его получения и возможностью открытия результата предыдущего запроса. В режиме массовой и регламентной операции формирование таких повторных запросов должно быть заблокировано с указанием причины (по объекту имеется актуальные сведения на запрос, полученные такого-то числа) Соответствие Значение характеристики не может изменяться участником закупки 67. Средства опроса системы СМЭВ на предмет уточнения состояния запроса, загрузка полученных сведений: 67.1. Основным режимом получения/обновления сведений о сформированных ранее межведомственных запросов из системы СМЭВ является режим периодического опроса (пингования) системы СМЭВ. 67.2. При наличии изменений с момента последнего опроса (пингования) системы СМЭВ (изменение даты и времени последнего изменения запроса в системе СМЭВ с аналогичными данными в интегрированном хранилище Системы), полученная информация должна быть занесена в интегрированное хранилище Системы: 67.2.1. Дата и время последнего изменения состояния или сведений запроса в системе СМЭВ. 67.2.2. Текущий статус (состояние) запроса. 67.2.3. При изменении статуса (состояния) запроса – информация по изменению состояния (см. требования к интегрированному хранилищу данных). 67.3. При получении сведений за межведомственный запрос (XML-файл, содержащий сведения), подсистема должна выполнять чтение файла и должна разместить полученную из XML-файла информацию в соответствующих субтаблицах запроса в виде, пригодном для формирования SQL-запросов с использованием полученных сведений Соответствие Значение характеристики не может изменяться участником закупки 67.4. Все операции по опросу (пингованию) системы СМЭВ вне зависимости от наличия изменений должны протоколироваться. Требования к протоколированию приведены в пункте «Интегрированное хранилище данных». 67.5. Должна быть предусмотрена возможность опроса (пингования) по всем сформированным межведомственным запросам, обработка которых еще не завершена (запрос не находится в состоянии ошибки и сведения по нему еще не получены), а также по межведомственным запросам определенной (выбранной пользователем) услуги (сервиса). Операция должна выполняться из основного окна Системы с использованием соответствующих пунктов меню. 67.6. В некоторых случаях сведения, содержащиеся в ответе на межведомственный запрос, не передаются в ходе межведомственного взаимодействия, а должны скачиваться пользователем вручную с использованием сети интернет. Такая ситуация возникает, например, из-за большого объема полученных сведений. Соответствие Значение характеристики не может изменяться участником закупки 68. Средства загрузки полученных сведений в интегрированное хранилище: 68.1. Полученные в результате межведомственного запроса сведения содержат XML-файл заданной в спецификациях к конкретной услуге (сервису) структуры. 68.2. В момент получения XML-файла должно быть обеспечено чтение всех данных XML-файла и размещение их в интегрированном хранилище Системы (единой базе данных Системы) в структурированном виде, пригодном для использования в SQL-запросах (см. требования к интегрированному хранилищу). 68.3. Чтение данных XML-файла и размещение их в интегрированном хранилище должно осуществляться с использованием алгоритма из библиотеки алгоритмов парсинга (разбора) результатов запросов, полученных в машиночитаемом виде (xml). 68.4. Должна быть предусмотрена возможность разработки новых алгоритмов и включение их в библиотеку алгоритмов силами обученных пользователей Системы Заказчика. 68.5. Должно быть предусмотрено обязательное протоколирование выполнения указанной процедуры. Требования к протоколированию приведены в пункте «Интегрированное хранилище данных»). 68.6. Загрузка полученных сведений в интегрированное хранилище должно производиться вне зависимости от способа загрузки сведений (автоматическая загрузка при получении ответа на сформированный ранее запрос), ручная загрузка результата, направленного ранее запроса, ручная загрузка результата на запрос, который не был отправлен средствами подсистемы Соответствие Значение характеристики не может изменяться участником закупки 69. Средства автоматического внесения изменений в единую БД Системы на основе полученных сведений: 69.1. Автоматическое внесение изменений в единую базу данных Системы на основе полученных сведений должно производится в момент получения сведений на межведомственный запрос после размещения полученных данных в реляционных субтаблицах. 69.2. Автоматическое внесение изменений должно производиться путем вызова соответствующего алгоритма из библиотеки алгоритмов, наименование которого настраивается для каждой услуги (сервиса). 69.3. Должна быть предусмотрена возможность разработки новых алгоритмов и включение их в библиотеку алгоритмов силами обученных пользователей Системы Заказчика. 69.4. По завершении автоматического внесения информации в интегрированном хранилище для данного запроса должны быть установлены дата и время автоматического внесения изменений на основе полученных сведений, признак завершения отработки запроса, а также вид операции – «Автоматическое внесение информации». 69.5. Должно быть предусмотрено обязательное протоколирование выполнения указанной процедуры. Протоколированию подлежит также факт невыполнения автоматической операции в связи с отсутствием имени алгоритма, выполняющего соответствующее действие. 69.6. Автоматическое внесение сведений может быть отключено настройками подсистемы (такая настройка должна быть предусмотрена индивидуально для каждого типа объектов учета, а также сервиса/услуги). В случае, если автоматическое внесение изменений отключено, должна быть предусмотрена возможность ручного запуска средств автоматического внесения изменений из окна просмотра результатов запроса. Факт ручного запуска средств автоматического внесения информации должен быть внесен в протокол Соответствие Значение характеристики не может изменяться участником закупки 70. Средства автоматического внесения изменений в единую БД Системы на основе полученных сведений: 70.1.1. Автоматическое внесение изменений в единую базу данных Системы на основе полученных сведений должно производится в момент получения сведений на межведомственный запрос после размещения полученных данных в реляционных субтаблицах. 70.1.2. Автоматическое внесение изменений должно производиться путем вызова соответствующего алгоритма из библиотеки алгоритмов, наименование которого настраивается для каждой услуги (сервиса). 70.1.3. Должна быть предусмотрена возможность разработки новых алгоритмов и включение их в библиотеку алгоритмов силами обученных пользователей Системы Заказчика. 70.1.4. По завершении автоматического внесения информации в интегрированном хранилище для данного запроса должны быть установлены дата и время автоматического внесения изменений на основе полученных сведений, признак завершения отработки запроса, а также вид операции – «Автоматическое внесение информации». 70.1.5. Должно быть предусмотрено обязательное протоколирование выполнения указанной процедуры. Протоколированию подлежит также факт невыполнения автоматической операции в связи с отсутствием имени алгоритма, выполняющего соответствующее действие. 70.1.6. Автоматическое внесение сведений может быть отключено настройками подсистемы (такая настройка должна быть предусмотрена индивидуально для каждого типа объектов учета, а также сервиса/услуги). В случае, если автоматическое внесение изменений отключено, должна быть предусмотрена возможность ручного запуска средств автоматического внесения изменений из окна просмотра результатов запроса. Факт ручного запуска средств автоматического внесения информации должен быть внесен в протокол Соответствие Значение характеристики не может изменяться участником закупки 56. Интегрированное хранилище данных в составе единой базы данных Системы: 56.1. Интегрированное хранилище данных должно быть предназначено для обеспечения хранения взаимосвязанной между собой информации подсистемы в составе единой базы данных Системы. 56.2.Интегрированное хранилище данных должно обеспечивать хранение информации без дублирования, повторного внесения информации, которая уже содержится в единой базе данных Системы. 56.3. Интегрированное хранилище должно содержать ссылки на объекты, субъекты и договоры единой базы данных Системы. 56.4. Интегрированное хранилище должно обеспечивать хранение в единой базе данных Системы следующей информации: 56.4.1. Нормативно-справочная информация подсистемы (содержимое справочников и классификаторов, использующихся в подсистеме). 56.4.2. Информацию о настройках функционирования подсистемы. 56.4.3. Информация по сформированным запросам, полученным в ходе запросов сведениям. 56.4.4. Протоколы всех действий, выполняемых средствами подсистемы в автоматическом, полуавтоматическом и ручном режимах. 56.4.5. По каждому запросу должна быть размещена следующая информация: 56.4.5.1. Идентификатор вида сведений версии 3.х. 56.4.5.2. Вид операции из соответствующего классификатора (ручной, из карточки объекта Системы, из массовой операции, регламентная операция, на основе результатов, полученных из других источников), для массовой и регламентной операции – идентификатор операции. 56.4.5.3. Дата и время формирования запроса, идентификатор пользователя (если операция инициирована пользователем). 56.4.5.4. Информация, переданная в систему СМЭВ в ходе формирования запроса. 56.4.5.5. Идентификатор запроса, присвоенный системой СМЭВ. 56.4.5.6. Идентификатор карточки Системы, из которой (для которой) сформирован запрос Соответствие Значение характеристики не может изменяться участником закупки 56.4.5.7. Идентификаторы объекта (помещение или земельный участок), субъекта (юридическое или физическое лицо, ИП), договора, по которым сформирован запрос. Заполняются те идентификаторы, которые применимы для конкретного вида запроса. Примечание. Например, запрос информации из ЕГРН для определения даты перехода права в ходе приватизации теоретически может быть сформирован как из договора приватизации, так и из объекта. В этом случае идентификаторы карточки Системы, из которой сформирован запрос, должны быть разные, но идентификатор объекта в обоих запросах должен быть один. Это должно потенциально позволить предотвратить повторные запросы на основе анализа идентификатора объекта. 56.4.5.8. Дата и время автоматического или полуавтоматического внесения информации, по полученным сведениям, в единую базу данных. 56.4.5.9. Режим внесения изменений (автоматический, полуавтоматический «мастер», ручной) – см. пункт «Интегрированные средства ведения нормативно-справочной информации». 56.4.5.10. Идентификатор пользователя, внесшего изменения в ручном или полуавтоматическом режиме – «мастер». 56.4.5.11. Признак отработки результатов запроса (да или нет). 56.4.5.12. Текущий статус (состояние) запроса в системе СМЭВ. 56.4.5.13. Дата и время изменения сведений запроса в системе СМЭВ (по данным СМЭВ). 56.4.5.14. Дата и время внесения изменений из системы СМЭВ (изменения статуса запроса). 56.4.5.15. Дату и время последнего успешного опроса системы СМЭВ по данному запросу. 56.4.5.16. Полную информация обо всех изменениях статусов (состояний) запросов, включая дату и время смены состояния, текстовое описание причины смены состояния, и другие сведения, полученные из системы СМЭВ в ходе информационного обмена Соответствие Значение характеристики не может изменяться участником закупки 71. Алгоритмы автоматического внесения изменений в единую БД Системы на основе полученных сведений: 71.1. Алгоритм автоматического внесения изменений в единую БД Системы на основе полученных сведений должен быть определен индивидуально для каждого типа объектов учета и каждого сервиса/услуги с возможностью его настройки. 71.2. Алгоритм должен функционировать по следующему принципу: 71.2.1. Если запрос был сформирован вручную, то на основе полученных сведений должен быть выполнен поиск соответствующего объекта в единой базе данных Системы, при успешном поиске запрос должен быть автоматически прикреплен к соответствующему объекту, соответствующее действие должно быть внесено в протокол. 71.2.2. Если найти объект не удалось, то в зависимости от настройки (такая настройка должна быть предусмотрена) подсистема автоматически создаст соответствующий объект в единой базе данных Системы и заполнит электронную карточку объекта сведениями, содержащимися в полученных данных. Соответствующие действия должны быть внесены в протокол. 71.2.3. Если получены сведения на запрос по объекту, который уже находится в базе данных Системы, то алгоритм опционально (такая настройка должна быть предусмотрена индивидуально для каждого типа объектов учета, сервиса/услуги и действия из перечисленного ниже списка) должен иметь возможность выполнить следующие действия: 71.2.3.1. Для каждого реквизита полученных сведений должна быть выполнена сверка с соответствующим реквизитом в электронной карточке соответствующего объекта учета. Возможны следующие варианты: 71.2.3.1.1. Если реквизит не заполнен, он подлежит заполнению на основе полученных сведений (должно настраиваться) Соответствие Значение характеристики не может изменяться участником закупки 71.2.3.1.2. Если реквизит заполнен, и он отличен от соответствующего реквизита в полученных сведениях, то в зависимости от настройки либо реквизит подлежит изменению (с протоколированием каждого действия), либо для запроса должно быть сформировано предупреждение (состояние запроса сменится на «Предупреждение») с внесением в текст предупреждения развернутой информации о выявленных различиях. 71.2.4. Информация о полученных сведениях должна быть занесена в документы по объекту учета (опционально). 71.3. Для выписок из Росреестра о правах на объекты имущества дополнительно (опционально) должны быть предусмотрены следующие возможности: 71.3.1. Сверка с единой БД Системы на предмет наличия объекта в реестре муниципальной собственности (если в Системы объект включен в реестр, а по данным Росреестра – нет или наоборот, то должно быть сформировано соответствующее предупреждение). 71.3.2. В случае, если в выписке обнаружена информация о регистрации права на объект имущества Системы, которое перешло новому владельцу на основании документов, фигурирующих в единой БД Системы (например, в ходе продажи или приватизации объекта), то опционально должна быть предусмотрена возможность автоматического исключения объекта из реестра муниципальной собственности датой, предшествующей дате регистрации объекта на нового собственника с автоматическим внесением информации о документе-основании исключения. 71.4. Автоматические изменения в соответствии с алгоритмами и настройками Системы могут быть инициированы пользователем вручную. В этом случае пользователь должен быть проинформирован о всех произведенных действиях подсистемы (открыт протокол соответствующих действий) с возможностью быстрого доступа (в один клик мыши) к карточке объекта учета для анализа и возможной корректировки соответствующих действий Соответствие Значение характеристики не может изменяться участником закупки 56.4.6. Информация, полученная в ходе исполнения межведомственного запроса должна быть представлена в структурированном виде и размещаться ее в реляционных структурах (таблицах) единой базы данных Системы. Информация должна быть представлена в виде, пригодном для формирования SQL-запросов с ее использованием. Должны быть предусмотрены средства заполнения данных в структурированном, реляционном виде на основе информации, размещенной в XML-файле полученного результата запроса. Хранение данных только в XML-файле результата запроса недопустимо. Полученную информацию необходимо вносить в интегрированное хранилище. 56.5. В интегрированном хранилище должны быть размещены протоколы всех действий, выполняемых средствами подсистемы в автоматическом, полуавтоматическом и ручном режимах, в том числе: 56.5.1. Протокол взаимодействия с подсистемой СМЭВ (формирование запроса, опросы с целью получения статуса запроса (пингование), загрузка результата в интегрированное хранилище, парсинг результата, размещение данных результата в реляционных таблицах). 56.5.2. Протокол применения результата к объектам базы данных (поиск объектов в базе данных для ручных запросов, автоматическое добавление объектов в базу данных по результатам запросов, внесение изменений в электронные карточки объектов учета на основе полученных данных (индивидуально для каждого выполненного изменения)). 56.6. Протоколы должны содержать следующую информацию: 56.6.1. Дата и время выполнения операции или действия. 56.6.2. Имя пользователя, инициировавшего операцию (если операцию инициировал пользователь). 56.6.3. Вид операции из соответствующего классификатора (ручной, из карточки объекта Системы, из массовой операции, регламентная операция, опрос (пингование) запроса в системе СМЭВ, получение события из системы СМЭВ), для массовой и регламентной операции – идентификатор операции Соответствие Значение характеристики не может изменяться участником закупки 56.6.4. Признак успешности выполнения операции из соответствующего классификатора (успешно, не успешно). 56.6.5. Выполненное действие (из соответствующего классификатора). 56.6.6. Данные, связанные с действием (в текстовом виде), например, при вводе кадастрового номера объекта на основе полученных данных – кадастровый номер. 56.6.7. Дополнительная текстовая информация (в случае ошибки – причина ошибки). 56.7. Интерфейс для работы пользователей с данными, размещенными в интегрированном хранилище, должен быть обеспечен непосредственно Системой с использованием экранных форм, разработанных по общим принципам, принятым для Системы, с использованием единого визуального стиля, оформления Системы Соответствие Значение характеристики не может изменяться участником закупки 57. Интегрированные средства ведения справочников и классификаторов: 57.1. Средства должны быть предназначены для управления работой со справочниками и классификаторами подсистемы и обеспечивать единое пространство справочной информации в процессе использования учетных данных и документов. 57.2. Средства должны обеспечивать выполнение функций: 57.2.1. Редактирование справочников и классификаторов. 57.2.2. Просмотр справочников и классификаторов Соответствие Значение характеристики не может изменяться участником закупки 72. Средства «закрытия» запросов: 72.1. Под «закрытием» запроса помечается возможность пометки запроса в качестве отработанного, то есть запроса, не требующего дальнейшего анализа или использования пользователем. 72.2. Должна быть предусмотрена возможность автоматического и ручного «закрытия» запросов. 72.3. Автоматическое «закрытие» запросов должно производиться по настройке (такая настройка должна быть предусмотрена индивидуально для каждого типа объектов учета и услуге/сервису) после успешного получения результатов запроса и автоматического успешного внесения изменений в единой базе данных Системы, предусмотренных соответствующим алгоритмом. Должна быть предусмотрена возможность отключения автоматического «закрытия» запросов индивидуально для каждого пользователя. 72.4. Ручное «закрытие» должно производится пользователем самостоятельно после изучения и/или использования результатов запроса. 72.5. «Закрытые» запросы не должно изыматься из единой базы данных Системы, последующий доступ к ним должен быть обеспечен по запросам пользователей. 72.6. По умолчанию для журнала запросов должна быть предусмотрена возможность отображения не закрытых запросов – см. требования к функционированию журнала запросов Соответствие Значение характеристики не может изменяться участником закупки 73. Средства работы с журналом межведомственных запросов: 73.1. Журнал запросов должен представлять собой список запросов, содержащий всю основную информацию по каждому запросу, а также средства открытия карточки запроса и выполнения основных действий над запросом. 73.2. Журнал запросов должен быть доступен в следующих режимах: 73.2.1. Из карточки объекта Системы – журнал размещается на вкладке «СМЭВ» карточки объекта и содержит все межведомственные запросы, которые были сформированы для данного объекта. 73.2.1. Из основного окна Системы для всех услуг/сервисов, а также индивидуально для каждого из сервисов/услуг в режиме отображения «моих» запросов. Под «моими» запросами понимаются запросы, сформированные текущим пользователем Системы. 73.2.2. Из основного окна Системы для всех услуг/сервисов, а также индивидуально для каждого из сервисов/услуг в режиме отображения всех запросов. 73.3. Для журнала межведомственных запросов должны быть предусмотрены средства поиска/фильтрации запросов в соответствии с требованиями к функционированию подсистемы поиска и анализа информации Системы: 73.3.1. Должны быть предусмотрены возможности поиска запросов по любым параметрам запроса, в том числе: 73.3.1.1. Сервис/услуга. 73.3.1.2. Код запроса. 73.3.1.3. Дата формирования запроса. 73.3.1.4. Состояние запроса (с возможностью множественного выбора из справочника состояний). 73.3.1.5. Статус запроса (текстовый статус сервисов межведомственного взаимодействия). 73.3.1.6. Сообщение протокола прохождения (выполнения) запроса. 73.3.1.7. Сообщения протокола применения результатов запроса (внесения изменений в базу Системы по результатам запроса). 73.3.1.8. Номер заявки. 73.3.1.9. GUID запроса в Системы. 73.3.1.10. Признак «закрытия» запроса. 73.3.1.11. Тип операции создания запроса (вручную, из карточки объекта, массовая операция, регламентная операция) – множественный выбор из справочника. 73.3.1.12. Источник операции создания запроса – множественный выбор из соответствующего справочника Соответствие Значение характеристики не может изменяться участником закупки 58. Средства настройки: 58.1. Подсистема должна обеспечивать максимально широкие возможности по настройке, изменению технологии работы подсистемы силами обученных пользователей Системы без привлечения программистов Исполнителя. 58.2. Должны быть предусмотрены следующие средства настройки, изменения технологии работы подсистемы силами обученных пользователей Системы: 58.2.1. Средства настройки перечня доступных сервисов и/или видов сведений для формирования межведомственных запросов в ручном режиме. 58.2.2. Средства настройки перечня доступных для каждого из типов объектов учета Системы сервисов и/или видов сведений. 58.2.3. Перечень регламентных операций для формирования запросов по расписанию, настройка расписания выполнения регламентных операций. 58.2.4. Средства/Алгоритмы чтения полученных в результате межведомственного запроса сведений и размещения их в реляционных субтаблицах интегрированного хранилища (единой базы данных Системы). 58.2.5. Средства/Алгоритмы внесения изменений в электронные карточки объектов учета на основе полученных данных. 58.2.6. Средства/Алгоритмы создания объектов учета, отсутствующих в базе данных, на основе сведений, содержащихся в полученных ответах. 58.2.7. Средства/Алгоритмы связи запросов, выполненных в ручном режиме, с объектами, которые уже есть в базе данных Системы на основе сведений, содержащихся в полученных ответах. 58.2.8. Средства/Алгоритмы автоматического «закрытия» межведомственных запросов после получения и использования (применения, внесения в базу данных) полученных сведений, возможность индивидуального отключения автоматического «закрытия» запросов. 58.2.9. Создание шаблонов автоматического частичного заполнения формы формирования ручного запроса Соответствие Значение характеристики не может изменяться участником закупки 59. Средства ручного формирования межведомственных запросов: 59.1. При ручном формировании запроса пользователь должен предварительно выбирать услугу (сервис), для которой формируется запрос. Выбор должен производиться из перечня услуг (сервисов), для которых доступно ручное формирование запроса. 59.2. В случае, если для некоторого сервиса/услуги предусмотрена возможность формирования запросов по нескольким вариантам параметров (например, по кадастровому номеру или адресу объекта), то должна быть предусмотрена возможность ввода параметров запроса для каждого варианта. 59.3. При проектировании должна быть предусмотрена возможность создания шаблонов автоматического заполнения одного или нескольких параметров запросов. 59.4. Должна быть предусмотрена возможность индивидуального создания шаблонов каждым пользователем. 59.5. Технология создания шаблонов должна быть реализована по следующему принципу – пользователь заполняет те параметры экранной формы ручного формирования запросов, которые должны быть включены в шаблон. Далее пользователь инициирует создание шаблона и вводит его наименование/описание. После этого шаблон автоматически появляется в списке доступных для данного пользователя шаблонов для данной услуги/сервиса. Для одного из шаблонов каждого сервиса/услуги должна быть предусмотрена возможность выбора шаблона по умолчанию. 59.6. Если для некоторого сервиса и/или вида сведений указан шаблон по умолчанию, то при ручном создании запроса соответствующего сервиса и/или вида сведений параметры запроса должны быть заполнены автоматически на основе данных шаблона по умолчанию. 59.7. Пользователь может выбрать любой доступный для данного сервиса/услуги шаблон, в этом случае соответствующие параметры из шаблона автоматически должны заполнять поля экранной формы ручного формирования запроса Соответствие Значение характеристики не может изменяться участником закупки 73.3.1.13. Пользователь, инициировавший запрос. 73.3.1.14. Дата последнего изменения информации. 73.3.1.15. Код регламентной операции. 73.3.1.16. Дата получения результата. 73.3.1.17. Дата загрузки результата. 73.3.1.17. Дата применения результата. 73.3.1.19. Тип операции применения результата – из соответствующего справочника. 73.3.1.20. Источник операции применения результата – из соответствующего справочника. 73.3.1.21. Пользователь, применивший результат. 73.3.1.22. Признак автоматического создания запроса при ручной загрузке результата, полученного из внешних источников. 73.3.1.23. Признак необходимости ручной загрузки результатов запроса. 73.3.1.24. Признак необходимости ручного применения результатов. 73.3.1.25. Признак включения в план повторных запросов. 73.3.2. Должны быть предусмотрена возможность поиска запросов по любым параметрам объектов единой базы данных Системы с использованием экранных форм поиска/фильтрации объектов, предусмотренных для соответствующих объектов в Системы. 73.3.3. Должны быть предусмотрена возможность просмотра/корректировки (для администратора) SQL-запроса на выборку запросов в соответствии с параметрами поиска. 73.3.4. Должны быть предусмотрен фильтр по умолчанию на отображение запросов, требующих внимания пользователей, то есть запрос не «закрыт» и результат получен (состояние запроса – «Успех, «Предупреждение» или «Ошибка») Соответствие Значение характеристики не может изменяться участником закупки 74. Средства работы с карточкой межведомственного запроса: 74.1. Карточка межведомственного запроса должна открываться из журнала запросов в любом из режимов его отображения и содержать следующую информацию/средства управления: 74.1. 1. Основную информацию по запросу: 74.1. 1.1. Код запроса. 74.1. 1.2. Текущее состояние запроса. 74.1. 1.3. Текстовый статус запроса. 74.1. 1.4. Дата и время формирования запроса. 74.1. 1.5. Пользователь, сформировавший запрос. 74.1. 1.6. Дата и время получения результата запроса. 74.1. 1.7. Информация по объекту Системы, связанного с данным запросом. 74.1. 1.8. Сведения о загрузке результата в базу данных. 74.1. 1.9. Сведения о применении результата (внесении изменений в базу данных). 74.1. 2. Средства просмотра протоколов работы с запросом. 74.1. 3. Средства просмотра файлов, полученных в результате запроса (в разархивированном виде). 74.1. 4. Средства выгрузки файлов результатов запроса на внешний носитель. 74.1. 5. Средства открытия файлов результатов запросов стандартными средствами операционной системы. 74.1. 6. Средства просмотра xml-файла результата запроса в виде документа (с применением соответствующих стилей отображения XML в оффлайн-режиме – без требования наличия сети интернет). 74.1. 7. Печать и выгрузка XML-файла в виде документа. 74.1. 8. Средства «Закрытия запроса». 74.1. 9. Средства ручного применения результатов запроса. 74.1. 10. Средства доступа к карточке объекта учета в Системе (в один клик). 74.1. 11. Средства загрузки результатов запроса (для запросов, требующих ручную загрузку результатов). 74.1. 12. Средства открытия запроса в системе СМЭВ Соответствие Значение характеристики не может изменяться участником закупки 75. Средства поиска объектов Системы по параметрам межведомственных запросов: 75.1. Для объектов базы данных Системы должны быть предусмотрены средства поиска объектов по параметрам межведомственных запросов. 75.2. Средства указания параметров поиска/фильтрации должны быть интегрированы непосредственно в стандартные окна поиска/фильтрации объектов Системы и должны быть размещены на отдельной вкладке «СМЭВ». 75.3. Средства поиска должны обладать следующими возможностями: 75.3.1. Поиск объектов по наличию или отсутствию межведомственных запросов указанного сервиса/услуги (если не указано, то для любых сервисов/услуг) в заданном диапазоне дат (если не указано, то на любую дату). 75.3.2. Поиск объектов по любым параметрам запросов с использованием формы поиска/фильтрации журнала межведомственных запросов Соответствие Значение характеристики не может изменяться участником закупки 59.8. После успешного формирования запроса пользователю должно быть выведено соответствующее сообщение с указанием кода сформированного запроса в журнале запросов. 59.9. Для запросов по кадастровому номеру или кадастровому кварталу должна быть предусмотрена возможность пакетного формирования ручных запросов на основе кадастровых номеров (или кварталов), определенных в текстовом файле (в столбик) – для каждого кадастрового номера (квартала) автоматически должен быть сформирован запрос. 59.10. Аналогичная возможность должна быть предусмотрена для запросов по ИНН, ОГРН и другим классификационным кодам юридических, физических лиц, индивидуальных предпринимателей Соответствие Значение характеристики не может изменяться участником закупки 77. Средства администрирования и разграничения прав пользователей: 77.1. Все операции подсистемы, которые могут быть инициированы пользователем, должны подлежать администрированию и разграничению прав доступа. 77.2. Администрированию должны подлежать: 77.2.1. Операции ручного формирования запросов – индивидуально для каждого вида услуги (сервиса) – по справочнику услуг (сервисов). 77.2.2. Операции формирования запросов из карточек объектов учета – индивидуально для каждого вида объекта и услуги (сервиса). 77.2.3. Операции формирования запросов в режиме массовой операции – индивидуально для каждого вида объекта в массовой операции и услуги (сервиса). 77.2.4. Операции ручной загрузки сведений, полученных из сторонних источников – индивидуально для каждого вида объекта и услуги (сервиса). 77.2.5. Операции ручного инициирования автоматического внесения изменений на основе полученных сведений – индивидуально для каждого вида объекта и услуги (сервиса). 6. Просмотр, печать, экспорт результатов, сформированных ранее запросов – индивидуально для каждого вида объекта и услуги (сервиса) Соответствие Значение характеристики не может изменяться участником закупки 78. Требования к подсистеме «Межведомственное электронное взаимодействие с ГИС ГМП»: 78.1. В рамках данного технического задания должны быть настроены адаптеры СМЭВ к следующим видам сведений Федерального Казначейства: 78.1.1. Предоставление необходимой для уплаты информации - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/dd08daa2-d9cd-11eb-87f2-6dd2d98a56b1. 78.1.2. Прием необходимой для уплаты информации (начисления) - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/dd0976e8-d9cd-11eb-87f2-6dd2d98a56b1. 78.1.3. Прием информации о погашении начисления - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/dd0928c6-d9cd-11eb-87f2-6dd2d98a56b1. 78.1.4. Предоставление информации об уплате - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/dd08daa3-d9cd-11eb-87f2-6dd2d98a56b1. 78.1.5. Прием информации о погашении начисления - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/dd0928c6-d9cd-11eb-87f2-6dd2d98a56b1. 78.2. Подсистема должна обеспечивать автоматический сбор и передачу информации по начислениям из Системы в Государственную информационную систему государственных и муниципальных платежей (ГИС ГМП) с использованием протоколов СМЭВ в форматах и порядке, утвержденных приказом Федерального казначейства от 12 мая 2017 г. N 11н «Об утверждении Порядка ведения Государственной информационной системы о государственных платежах». 78.3. Подсистема должна быть реализована в виде сервисов ОС, которые выполняют следующие функции: 78.3.1. Формирование и присвоение УИН (уникальный идентификатор) начислениям всех типов (в соответствии с методическими и форматными требованиями ГИС ГМП). 78.3.2. Автоматический сбор информации по начислениям, а также корректировкам и аннулированиям начислений из Системы. 78.3.3. Формирование сообщений в утверждённых форматах ГИС ГМП, заверение их электронной подписью (ЭП) и передача сообщений по протоколам СМЭВ, формирование протокола отправки и подтверждения получения из ГИС ГМП Соответствие Значение характеристики не может изменяться участником закупки 78.3.4. Анализ полученных ответов и создание необходимых записей/протоколов в БД Системы. 78.3.5. Автоматическое распределение поступлений, в которых указан корректный УИН, по договорам Системы. 78.3.6. Автоматическое квитирование начислений на основе информации о поступлениях в соответствующих договорах. 78.4. Подсистема должна автоматизировать работу оператора начислений, снять нагрузку по ручному формированию и отправке начислений в Федеральное казначейство, а также проверки статусов начислений. Вся работа должна осуществляться в стандартном интерфейсе Системы, средства взаимодействия должны функционировать полностью автоматически и не требовать дополнительных действий от пользователей Системы. 78.5.Должна быть предусмотрена возможность квитирования начислений с отсутствующим платежом (в соответствии с технологией квитирования, предусмотренной в ГИС ГМП). 78.6.Поступления по администрируемым кодам бюджетной классификации (КБК) поступают в журнал нераспределенных поступлений финансово-аналитической подсистемы из системы электронного бюджета Федерального Казначейства (ЭБ). 78.7. В Системе должна быть предусмотрена возможность выполнения автоматических операций по автоматическому распределению поступлений на договоры с привязкой к виду начисления. 78.8. В случае, если информация о поступлении содержит УИН начисления, эта информация должна использоваться для однозначного определения договора и вида начисления путем поиска по УИН и анализа информации о соответствующем начислении. Должно быть выполнено соответствующее развитие алгоритмов автоматического распределения поступлений по договорам и видам начислений финансово-аналитической подсистемы Соответствие Значение характеристики не может изменяться участником закупки 79.Требования к подсистеме «Межведомственное электронное взаимодействие с Росреестром»: 79.1. В рамках данного технического задания должен быть настроен адаптер СМЭВ к следующему виду сведений Росреестра: Прием обращений в ФГИС ЕГРН - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/dd0b99d3-d9cd-11eb-87f2-6dd2d98a56b1. 79.2. Подсистема должна решать следующие задачи: 79.2.1. Получение необходимой информации о земельных участках, объектах недвижимости. 79.2.2. Получение информации о правах субъектов на объекты недвижимости и земельные участки. 79.2.3. Получение информации Кадастровом паспорте, Кадастровом плане территории, Кадастровой выписке и иных документах. 79.2.4. Своевременное получение информации об изменениях состояния и прав собственности на объекты недвижимости. 79.2.5. Актуализация сведений, в том числе в массовом порядке, содержащихся в информационном фонде Системы из результатов запросов к сервису Росреестра. 79.3. Должны быть предоставлены средства получения следующих сведений из Росреестра: 79.3.1. Выписка из ЕГРН об объекте недвижимости. 79.3.2. Выписка из ЕГРН о переходе прав на объект недвижимости. 79.3.3. Справки о лицах, получивших сведения об объекте недвижимости за период. 79.3.4. Выписка из ЕГРН об основных характеристиках и зарегистрированных правах на объект недвижимости. 79.3.5. Выписка о правах отдельного лица на имевшиеся/имеющиеся у него объекты недвижимости. 79.3.6. Выписка о содержании правоустанавливающих документов. 79.3.7. Выписка о признании правообладателя недееспособным или ограниченно дееспособным. 79.3.8. Копия документа. 79.3.9. Выписка о дате получения органом регистрации прав заявления о государственном кадастровом учете и (или) государственной регистрации прав и прилагаемых к нему документов. 79.3.10. Выписки о кадастровой стоимости объекта недвижимости. 79.3.11. Кадастровый план территории. 79.3.12. Выписка по зонам Соответствие Значение характеристики не может изменяться участником закупки 80.4.2. Запрос сведений о перемене имени. 80.4.3. Запрос сведений о расторжении брака. 80.4.4. Запрос сведений о рождении. 80.4.5. Запрос сведений об установлении отцовства. 80.4.6. Запрос сведений о смерти Соответствие Значение характеристики не может изменяться участником закупки 80. Подсистема «Межведомственное электронное взаимодействие с ЗАГС»: 80.1. В рамках данного технического задания должны быть настроены адаптеры СМЭВ к следующим видам сведений органов записи актов гражданского состояния (далее - ЗАГС): 80.1.1. Сведения о заключении брака - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/637a056a-ff80-11eb-ba23-33408f10c8dc. 80.1.2. Сведения о перемене имени - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/637a0597-ff80-11eb-ba23-33408f10c8dc. 80.1.3. Сведения о расторжение брака - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/637a0564-ff80-11eb-ba23-33408f10c8dc. 80.1.4. Сведения о рождении - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/637a059f-ff80-11eb-ba23-33408f10c8dc. 80.1.5. Сведения об установлении отцовства - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/637a0594-ff80-11eb-ba23-33408f10c8dc. 80.1.6. Сведения о смерти - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/637a0579-ff80-11eb-ba23-33408f10c8dc. 80.2. Подсистема должна решать следующие задачи: 80.2.1. Получение информации о физических лицах в объеме сведений сервисов СМЭВ ПФР. 80.2.2. Актуализация сведений, содержащихся в информационном фонде Системы на основе полученных сведений. 80.3. После получения ответов на отправленные запросы Подсистема в автоматическом или автоматизированном режиме должна позволять: 80.3.1. Направлять уведомление о получении ответа пользователям на электронную почту. 80.3.2. Автоматически прикреплять полученные сведения к карточке соответствующего объекта учета, субъекта права в Системе. 80.3.3. Обеспечивать возможность в автоматизированном режиме формировать информацию, аналитические и статистические отчеты, запросы на основе полученных в результате межведомственных запросов сведений. 80.4. Должны быть предоставлены средства получения следующих сведений из ФНС: 80.4.1. Запрос сведений о заключении брака. 80.4.2. Запрос сведений о перемене имени. 80.4.3. Запрос сведений о расторжении брака Соответствие Значение характеристики не может изменяться участником закупки 52. Средства ведения журналов проверок, информации о ходе проведения проверок: 52.1. Доступ к журналам (реестрам) проверок должен быть организован из «дерева меню» основного окна Системы. 52.2. Средства работы с журналом проверок должны быть подключены к подсистеме поиска и аналитики Системы (обладать всему функциями указанной подсистемы), быть построены по общим принципам работы со списками объектов учета Системы, в том числе: 52.2.1. Обладать возможностями поиска проверок по любым параметрам или сочетаниям параметров проверок, включая возможности поиска проверок по любым параметрам субъектов проверок, объектов проверок, договоров, в отношении которых проводится проверка, а также по информации о претензионной и исковой деятельности, которая инициирована по результатам проверки. 52.2.2. Обладать возможностью настройки табличного представления списка проверок (управление видимостью и порядка следования колонок, добавление новых колонок без ограничения количества и методики формирования информации, размещенной в колонках, добавления колонок с цветовой индикацией, управление алгоритмами цветовой индикации в колонках и т.п.). 52.2.3. Обладать аналитическими возможностями – сортировки, группировки по любой колонке или набору колонок, подведению итогов по выборке целиком или по группам (сумма, количество и т.д.) Соответствие Значение характеристики не может изменяться участником закупки 52.3. В журнале (списке, реестре) проверок должны быть отражены все основные показатели из карточки проверки, показатели стадии проверок должны быть отражены для текущей стадии или последней стадии проверки для завершенных проверок. 52.4. В Подсистеме не должно быть ограничений по количеству журналов проверок. 52.5. Журналы могут быть разделены по группам: 52.5.1. Журналы проверок по объектам имущества. 52.5.2. Журналы проверок по земельным участкам. 52.6. Должен быть предусмотрен отдельный пункт меню (автоматический журнал) – «Напоминания». В случае деления журналов по группам должна быть предусмотрена возможность отображения пункта «Напоминания» в каждой из групп. 52.7.Журнал «Напоминания» должен содержать проверки, для которых подходит или нарушен срок предупредительного контроля для текущего сотрудника, который работает в Системе. Подробно функции напоминаний описаны ниже Соответствие Значение характеристики не может изменяться участником закупки 53. Электронная карточка проверки: 53.1. Электронная карточка проверки должна содержать следующую информацию: 53.1.1. Реестр (журнал) проверки. 53.1.2. Форма проверки (выездная, документарная и т.п.). 53.1.3. Состояние проверки (в плане, в процессе, завершена). 53.1.4. Год проверки. 53.1.5. Категория. 53.1.6. Цель. 53.1.7. Перечень органов или организаций соисполнителей. 53.1.8. Субъект проверки – ссылка на субъект единой БД Системы. 53.1.9. Даты планируемого и фактического начала. 53.1.10. Даты планируемого и фактического окончания. 53.1.11. Срок проведения по регламенту с возможностью настройки автоматического определения в соответствии с регламентом для данного журнала проверок. 53.1.12. Исчерпывающая информация о форме и дате отправки уведомления о начале проверки. 53.1.13. Перечень объектов проверки (ссылки на объекты единой БД Системы), перечень обнаруженных нарушений для каждого из объектов. 53.1.14. Информация об осмотре и вынесенном решении по результатам осмотра. 53.1.15. Этапы проведения проверок с настройкой последовательности и сроков в соответствии с регламентами, определенными для каждого журнала проверок, Подрядчик каждого этапа, ссылка на документы-основания для каждого этапа, результата этапа. 53.1.16. Перечень документов по проверке (с возможностью прикрепления файла документа). 53.1.17. Перечень претензий и\или исков по результатам проверки (ссылки на реестр исков претензионно-исковой подсистемы Системы). 53.1.18. Результат проверки, ссылка на документ-основания результата Соответствие Значение характеристики не может изменяться участником закупки 54. Средства предупредительного контроля за соблюдением регламента проведения проверок: 54.1. Должна быть предусмотрена возможность настройки регламентов выполнения проверок. 54.2. Регламент может определять: 54.2.1. Общий срок в днях для проверки (с настройкой рабочие\календарные дни). 54.2.2. Перечень и последовательность типовых этапов для каждого журнала. 54.2.3. Длительность для каждого этапа. 54.2.4. Варианты результата этапа. 54.2.5. Перечень настроек напоминаний для этапа – срок в днях с момента начала или до окончания этапа, роли пользователей, для которых формировать напоминания (Подрядчик, куратор), а также фиксированный перечень пользователей, для которых формировать напоминания (например, начальник отдела). 54.3. При наступлении события для напоминания соответствующие проверки должны быть отражены в журнале: 54.3.1. Во всплывающем окне при каждом входе пользователя в Систему. 54.3.2. В журнале «Напоминания» соответствующих пользователей. 54.4. Требования по развитию Системы для интеграции средств подсистемы: 54.4.1. В электронных карточках субъектов должна размещаться информация о списках проверок в отношении этих субъектов (план проверок, текущие и завершенные проверки). 54.4.2. В электронных карточках объектов имущества и земельных участков должна размещаться информация о списках проверок в отношении этих объектов (план проверок, текущие и завершенные проверки). 54.4.3. В электронных карточках претензий и исков должна размещаться информация о проверке, по результатам которой начата претензионная или исковая. 54.4.4. Должна быть организована возможность поиска субъектов, объектов, претензий и исков по всем параметрам проводимых в отношении них проверок (связанных проверок) Соответствие Значение характеристики не может изменяться участником закупки 54.5. Разграничение прав пользователей по доступу к журналам проверок, электронным карточкам проверок, операциям, производимых с проверками, ведение аудита и журнала действия пользователей должны обеспечиваться стандартными средствами подсистемы администрирования и разграничения прав пользователей Системы. 54.6. Подсистема должна быть подключена к подсистемам «Библиотека запросов» и «Генератор отчетов» Системы. Все функции соответствующих подсистем должны быть распространены на информацию Подсистемы Соответствие Значение характеристики не может изменяться участником закупки 55. Требования к подсистеме межведомственного электронного взаимодействия (платформа СМЭВ): 55.1. Подсистема должна автоматизировать межведомственное электронное взаимодействие органов управления муниципальной собственностью в части формирования межведомственных запросов по протоколам СМЭВ в отношении объектов учета, субъектов права и договоров, зарегистрированных в единой базе данных Системы, а также автоматизации внесения изменений в единую базу данных Системы на основе полученных сведений. 55.2. Подсистема должна решать следующие задачи: 55.2.1. Формирование межведомственных запросов в ручном режиме с любого рабочего места Системы (ручное заполнение информации по запросу). 55.2.2. Формирование межведомственных запросов непосредственно из карточки объекта учета, субъекта права или договора (автоматическое формирование запроса в «один клик»). 55.2.3. Формирование межведомственных запросов по вручную определенному пользователем перечню объектов учета, субъектов права или договоров в режиме массовой операции (полностью автоматическое формирование запросов без ограничения количества). 55.2.4. Автоматическое формирование межведомственных запросов по определенному перечню объектов учета, субъектов права или договоров в режиме регламентной операции (автоматически по расписанию без ограничения количества). Например, автоматическое формирование запроса на получение выписки из ЕГРН через месяц после подписания договора приватизации с целью определения даты перехода права на приватизированный объект (даты регистрации права собственности на нового собственника и исключения объекта из муниципальной доли). 55.3. После получения ответов на отправленные запросы подсистема в автоматическом или автоматизированном режиме должна позволять: 55.3.1. Обеспечивать возможность автоматического и автоматизированного (автоматического по требованию пользователя) внесения изменений в единую базу данных Системы на основе полученных сведений. Соответствие Значение характеристики не может изменяться участником закупки 55.3.2. Автоматически прикреплять полученные сведения к карточке соответствующего объекта учета, субъекта права или договора в базе Системы с обеспечением возможности автоматизированного внесения изменений в карточку объекта учета, субъекта права или договора на основе этих сведений. 55.3.3. Обеспечивать возможность в автоматизированном режиме формировать информацию, аналитические и статистические отчеты, запросы на основе полученных в результате межведомственных запросов сведений, например, формировать уведомления о необходимости регистрации права собственности на приобретаемые в собственность объекты муниципальной собственности (покупке, приватизация) лицам или организациям, нарушившим сроки регистрации. 55.4. Функции подсистемы должны быть использованы для автоматизации выполнения следующих задач: 55.4.1. Определения даты исключения объекта из муниципальной собственности в ходе продажи/приватизации объекта. 55.4.2. Определения периода нахождения объекта в муниципальной казне, обеспечения корректного бюджетного учета движения объектов в казне. 55.4.3. Определения даты расторжения договоров аренды на объекты муниципальной собственности в ходе выкупа из аренды. 55.4.4. Определения даты передачи муниципальной собственности на праве оперативного управления или хозяйственного ведения. 55.4.5. Уточнения сведений по объектам муниципальной собственности, подлежащим продаже, приватизации, наложению других обременений и/или вещных прав. 55.4.6. Уточнения площадных, стоимостных и других характеристик объектов муниципальной собственности. 55.4.7. Уточнение сведений по зарегистрированным правам на объекты муниципальной собственности. 55.4.8. Определения периода оплаты взносов на капитальный ремонт объектов муниципальной собственности, расположенных в многоквартирных жилых домах, включенных в программу капитального ремонта Соответствие Значение характеристики не может изменяться участником закупки 55.5. Общей целью подсистемы должно быть обеспечение полноты и актуальности информации по объектам муниципальной собственности, земельным участкам, право собственности на которые не разграничено, вне-реестровым объектам учета, субъектам права, договорам и другим правам на объекты, подлежащие учету в рамках единого информационного фонда Системы. 55.6. Для достижения поставленных целей подсистема должна обеспечить получение информации от участников межведомственного электронного взаимодействия путем формирования запросов в соответствии с установленными методическими рекомендациям, размещенными на портале https:/info.gosuslugi.ru 55.7. Подсистема должна обеспечить: 55.7.1. Своевременное получение информации об изменении состава и/или содержания зарегистрированных на объекты учета прав, актуализацию соответствующих сведений в единой базе данных. 55.7.2. Своевременное проведение процедур, связанных с изменением информации по объектам учета, субъектам права и зарегистрированным правам. 55.7.3. Обеспечение полноты и качества ведения бюджетного учета движения объектов в муниципальной казне на основе актуальной информации по датам перехода права собственности на объекты учета, прав оперативного управления и хозяйственного ведения. 55.7.4. Обеспечение полноты и качества администрирования поступлений по администрируемым кодам бюджетной классификации на основе актуальной информации о регистрации договорных отношений. 55.7.5. Контроль за расходованием бюджетных средств на обслуживание объектов муниципальной собственности, включая оплату взносов на капитальный ремонт и др. 55.8. В составе подсистемы должны быть реализованы следующие средства: 55.8.1. Интегрированное хранилище данных в составе единой базы данных Системы. 55.8.2. Интегрированные средства ведения справочников и классификаторов. 55.8.3. Средства настройки. 55.8.4. Средства ручного формирования межведомственных запросов Соответствие Значение характеристики не может изменяться участником закупки 55.8.5. Средства формирования межведомственных запросов из карточки объекта Системы. 55.8.6. Средства формирования межведомственных запросов в режиме массовой операции. 55.8.7. Средства формирования межведомственных запросов в режиме регламентной операции. 55.8.8. Средства подписания запросов электронной подписью. 55.8.9. Средства ручного внесения результатов запросов, которые не формировались средствами подсистемы. 55.8.10. Средства предотвращения повторного формирования запросов 55.8.11. Средства опроса системы СМЭВ на предмет уточнения состояния запроса. 55.8.12. Средства загрузки полученных сведений в интегрированной хранилище данных. 55.8.13. Средства автоматического внесения изменений в единую БД Системы на основе полученных сведений. 55.8.14. Алгоритмы автоматического внесения изменений в единую БД Системы на основе полученных сведений. 55.8.15. Средства «закрытия» запросов. 55.8.16. Средства работы с журналом межведомственных запросов. 55.8.17. Средства работы с карточкой межведомственного запроса. 55.8.17. Средства поиска объектов Системы по параметрам межведомственных запросов. 55.8.19. Средства просмотра протоколов выполнения операций. 55.8.20. Средства администрирования и разграничения прав пользователей Соответствие Значение характеристики не может изменяться участником закупки 43. Средства ведения реестра специализированного жилого фонда: 43.1. Для объектов жилого фонда (квартир и комнат) будет предусмотрен признак отнесения данного объекта к специализированному жилому фонду. 43.2. Для каждого объекта будет указана категория (тип) специализированного жилого фонда: 43.2.1. Служебное жилье. 43.2.2. Маневренный фонд. 43.2.3. Жилые помещения в общежитиях. 43.2.4. Жилые помещения в домах системы социального обслуживания населения. 43.2.5. Жилые помещения для социальной защиты отдельных категорий граждан. 43.2.6. Жилые помещения для детей сирот и детей, оставшихся без попечения родителей, лиц из числа детей сирот и детей, оставшихся без попечения родителей. 43.3. Должна быть предусмотрена возможность расширения или изменения перечня категорий (типов) специализированного жилого фонда (классификатор категорий/типов). 43.4. При отнесении объекта жилого фонда к реестру специализированного жилого фонда может быть указано произвольное количество документов-оснований. 43.5. Должна быть предусмотрена возможность указания периода принадлежности объекта к специализированному жилому фонду. 43.6. В периоде нахождения объекта в реестре специализированного жилого фонда допускается только заключение договоров специализированного найма. Требования к ведению договоров специализированного найма приведены ниже. 43.7. При формировании договора приватизации или социального найма квартиры или комнаты, принадлежащей к реестру специализированного жилого фонда, будет отображено сообщение предупреждение. Операции актуализации таких договоров должны быть заблокированы (включая средства актуализации с использованием массовых операций) Соответствие Значение характеристики не может изменяться участником закупки 44. Средства управления договорами мены и выкупа аварийного жилья: 44.1. Средства управления договорами мены и выкупа аварийного жилья должны быть построены на основе стандартных средств Системы управления договорами на объекты имущества других типов (аренда, продажа). 44.2. Формирование договоров мены и выкупа аварийного жилья допускается только на объекты, не входящие в реестр муниципальной собственности. 44.3. Средства управления договорами мены дополнительно должны обеспечивать возможность указания перечня объектов, из которых производится переселение (квартир и комнат многоквартирного жилого дома), а также перечня объектов, в которые производится переселение. 44.4. Для договоров мены и выкупа аварийных помещений будет предусмотрена возможность ввода нескольких субъектов договора (собственников) с указанием доли каждого из собственников. Доля вводится в виде простой дроби (числитель и знаменатель). Суммарная доля собственников не будет превышать 100%. 44.5. Средства ввода суммы договора будет предусмотрено только для договоров выкупа Соответствие Значение характеристики не может изменяться участником закупки 45. Средства управления договорами социального и специализированного найма: 45.1. Средства управления договорами социального и специализированного найма будут построены на основе стандартных средств Системы управления договорами аренды объектов недвижимого имущества. 45.2. Формирование договоров социального и специализированного найма допускается только на объекты, находящиеся в реестре муниципальной собственности. 45.3. Заключение договора социального найма возможно только на объекты, не входящие в реестр объектов специализированного жилого фонда. При создании договора социального найма на объекты специализированного жилого фонда будет выводиться сообщение предупреждение, актуализация такого договора будет блокироваться. 45.4. Заключение договора социального найма возможно только на объекты, входящие в реестр объектов специализированного жилого фонда. При создании договора специализированного найма на объекты, не входящие в реестр специализированного жилого фонда, будет выводиться сообщение предупреждение, актуализация такого договора будет блокироваться. 45.5. При переселении нанимателей из аварийного жилого фонда для договоров социального и специализированного найма кроме перечня объектов, на которые заключается договор, будет предусмотрен перечень объектов, из которых производится переселение (аналогично соответствующим средствам договоров мены – см. выше). 45.6. Для договоров социального и специализированного найма должны быть подключены все возможности финансово-аналитической подсистемы Системы и подсистемы бюджетного учета доходов по администрируемым кодам бюджетной классификации Соответствие Значение характеристики не может изменяться участником закупки 46. Средства управления договорами социального и специализированного найма: 46.1. Средства управления договорами социального и специализированного найма должны быть построены на основе стандартных средств Системы управления договорами аренды объектов недвижимого имущества. 46.2. Формирование договоров социального и специализированного найма допускается только на объекты, находящиеся в реестре муниципальной собственности. 46.3. Заключение договора социального найма возможно только на объекты, не входящие в реестр объектов специализированного жилого фонда. При создании договора социального найма на объекты специализированного жилого фонда будет выводиться сообщение предупреждение, актуализация такого договора будет блокироваться. 46.4. Заключение договора социального найма возможно только на объекты, входящие в реестр объектов специализированного жилого фонда. При создании договора специализированного найма на объекты, не входящие в реестр специализированного жилого фонда, будет выводиться сообщение предупреждение, актуализация такого договора будет блокироваться. 46.5. При переселении нанимателей из аварийного жилого фонда для договоров социального и специализированного найма кроме перечня объектов, на которые заключается договор, будет предусмотрен перечень объектов, из которых производится переселение (аналогично соответствующим средствам договоров мены – см. выше). 46.6. Для договоров социального и специализированного найма должны быть подключены все возможности финансово-аналитической подсистемы Системы и подсистемы бюджетного учета доходов по администрируемым кодам бюджетной классификации Соответствие Значение характеристики не может изменяться участником закупки 49.1.7. Организация пообъектной сверки с региональным оператором управления взносами на капитальный ремонт или ТСЖ по суммам начисления взносов, перерасчетам. 49.1.8. Организации надлежащего контроля за расходованием бюджетных средств Соответствие Значение характеристики не может изменяться участником закупки 50.3.3. В Подсистеме должен быть расширен перечень справочников и классификаторов Системы за счёт добавления новых видов справочников и классификаторов, используемых Подсистемой Соответствие Значение характеристики не может изменяться участником закупки 47. Средства управления договорами социального и специализированного найма: 47.1. Средства управления договорами социального и специализированного найма должны быть построены на основе стандартных средств Системы управления договорами аренды объектов недвижимого имущества. 47.2. Формирование договоров социального и специализированного найма допускается только на объекты, находящиеся в реестре муниципальной собственности. 47.3. Заключение договора социального найма возможно только на объекты, не входящие в реестр объектов специализированного жилого фонда. При создании договора социального найма на объекты специализированного жилого фонда будет выводиться сообщение предупреждение, актуализация такого договора будет блокироваться. 47.4. Заключение договора социального найма возможно только на объекты, входящие в реестр объектов специализированного жилого фонда. При создании договора специализированного найма на объекты, не входящие в реестр специализированного жилого фонда, будет выводиться сообщение предупреждение, актуализация такого договора будет блокироваться. 47.5. При переселении нанимателей из аварийного жилого фонда для договоров социального и специализированного найма кроме перечня объектов, на которые заключается договор, будет предусмотрен перечень объектов, из которых производится переселение (аналогично соответствующим средствам договоров мены – см. выше). 47.6. Для договоров социального и специализированного найма должны быть подключены все возможности финансово-аналитической подсистемы Системы и подсистемы бюджетного учета доходов по администрируемым кодам бюджетной классификации Соответствие Значение характеристики не может изменяться участником закупки 48. Средства автоматизации работы с управляющими компаниями: 48.1. В карточке многоквартирного жилого дома должна быть предусмотрена возможность ввода информации по управляющей компании. Карточка управляющей компании должна заводиться в стандартном реестре юридических лиц субъектов права Системы. 48.2. Информация по управляющей компании многоквартирного жилого дома должна вводиться путем указания ссылки на карточку управляющей компании средствами работы с субъектами права многоквартирного жилого дома. Предусматривается ведение истории изменения управляющих компаний дома (дата начала и дата окончания), а также перечень ссылок на документы основания (протокол собрания жильцов, договор с управляющей компанией и любые другие документы) с возможностью прикрепления файлов документов. 48.3. На этапе, когда договор с управляющей компанией еще не подписан, однако имеется протокол жильцов с положительным решением о заключении договора с управляющей компанией, должна быть предусмотрена возможность ввода информации по управляющей компании с типом субъекта права «Управляющая компания намерение», при заключении договора с управляющей компанией тип субъекта права будет сменен на «Управляющая компания». 48.4. Информация об управляющей компании должна заноситься только в карточку многоквартирного жилого фонда, однако отображаться будет в карточках всех квартир и комнат данного многоквартирного дома (включая документы основания управляющей компании без возможности корректировки). 48.5. Информация по управляющей компании (наименование) должна отображаться в реестре объектов жилого фонда всех типов (здание, квартира, комната), а также на основной вкладке карточки объектов жилого фонда всех типов Соответствие Значение характеристики не может изменяться участником закупки 49. Требования к подсистеме «Управление взносами на капитальный ремонт»: 49.1. Подсистема «Управление взносами на капитальный ремонт» жилых и нежилых помещений, находящихся в муниципальной собственности и расположенных в многоквартирных жилых домах, включенных в программу капитального ремонта, должен автоматизировать решение следующих задач: 49.1.1. Ведение реестра многоквартирных жилых домов, включенных в программу капитального ремонта. 49.1.2. Формирования перечня жилых (квартир и комнат) и нежилых помещений, по которым подлежит уплата взносов. 49.1.3. Периодическая (ежемесячная) выгрузка изменений (с момента последней успешной выгрузки) для передачи в адрес регионального оператора управления взносами на капитальный ремонт: 49.1.3.1. Сведения об объектах, включенных в реестр муниципальной собственности, или объектов с изменившейся датой включения — с указанием даты и документа-основания включения. 49.1.3.2. Сведения об объектах, исключенных из реестра муниципальной собственности, или объектов с изменившейся датой исключения — с указанием даты и документа-основания исключения. 49.1.3.3. Сведения об объектах с изменившейся площадью — с указанием новой площади. 49.1.3.4. Сведения об объектах с изменившимся адресом — с указанием нового адреса. 49.1.4. Пообъектное начисление взносов с учетом дат включения объектов в собственность (казну), исключения объекта из собственности (казны), автоматическое формирование перерасчетов при внесении изменений в реестр муниципальной собственности. 49.1.5. Учет сумм оплат взносов, распределение суммы оплаты по объектам, учет списаний при выбытии объектов или проведении капитального ремонта. 49.1.6. Организация пообъектного бюджетного учета всех финансовых операций в соответствии с требованиями письма Министерства финансов Российской Федерации от 10.08.2015 № 02-07-07/46003 «Об отражении в бухгалтерском учете операций по перечислению взносов на капитальный ремонт в фонд капитального ремонта» Соответствие Значение характеристики не может изменяться участником закупки 50. Требования к подсистеме «Ведение проверок использования имущества и земельных участков»: 50.1. В составе подсистемы должны быть следующие средства: 50.1.1. Интегрированное хранилище данных в составе единой базы данных Системы. 50.1.2. Интегрированные средства ведения справочников и классификаторов в составе подсистемы ведения нормативно-справочной информации Системы. 50.1.3. Средства формирования плана проверок. 50.1.4. Средства ведения журналов (реестров) проверок, информации о ходе проведения проверок. 50.1.5. Средства предупредительного контроля за соблюдением регламента проведения проверок. 50.2. Интегрированное хранилище данных: 50.2.1. Интегрированное хранилище данных предназначено для обеспечения хранения взаимосвязанной между собой информации подсистемы в составе единой базы данных Системы. 50.2.2. Интегрированное хранилище данных должно обеспечивать хранение информации без дублирования, повторного внесения информации, которая уже содержится в единой базе данных Системы. 50.2.3. Интегрированное хранилище подсистемы должно содержать ссылки на объекты, субъекты, договоры, претензии и иски, информация о которых размещена в единой базе данных Системы. 50.2.4. Информация, которой оперирует Подсистема должна быть в полном составе размещена в единой базе данных Системы. 50.3 Интегрированные средства ведения справочников и классификаторов: 50.3.1. Ведение справочников и Классификаторов Подсистемы должно выполняться средствами Подсистемы управления нормативно-справочной информацией Системы, внешний вид экранных форм, а также функции по управлению справочниками и классификаторами Подсистемы должны быть аналогичными соответствующим элементам подсистемы управления нормативно-справочной информацией Системы. 50.3.2. Средства должны обеспечивать выполнение функций: 50.3.2.1. Редактирование справочников и классификаторов. 50.3.2.2. Просмотр справочников и классификаторов. Соответствие Значение характеристики не может изменяться участником закупки 51. Средства формирования плана проверок: 51.1. В подсистеме должны быть предусмотрены возможности формирования планов проверок на будущие отчетные периоды (года) в разрезе каждого из видов проверок (журналов проверок – см. ниже). 51.2. Для плана проверок должна быть предусмотрена возможность указания периода (года) плана проверок, а также перечня субъектов\объектов, подлежащих проверке в плановом порядке. 51.3. По каждому субъекту должна быть предусмотрена возможность указания планового периода проверки, а также возможность указания перечня объектов или договоров, подлежащих проверке в рамках плана. 51.4. Для плана проверок должны быть предусмотрены функции и средства работы с журналами проверок (списками или реестрами проверок), а также средства аналитики, поиска фильтрации и т.д., описанные ниже Соответствие Значение характеристики не может изменяться участником закупки 42. Требования к структуре и функционированию подсистемы «Управление объектами жилого фонда»: 42.1. В составе Подсистемы должны присутствовать следующие средства: 42.1.1. Средства ведения реестра жилых зданий, муниципальных и не муниципальных жилых квартир и комнат. 42.1.2. Средства ведения реестра специализированного жилого фонда. 42.1.3. Средства ведения информации по аварийным многоквартирным жилым домам. 42.1.4. Средства управления договорами мены и выкупа аварийного жилого фонда. 42.1.5. Средства управления договорами социального и специализированного найма. 42.1.6. Средства автоматизации работы с управляющими компаниями. 42.2. Средства должны обеспечивать формирование следующих реестров (списков) объектов учета: 42.2.1. Реестр (список) жилых домов, включая многоквартирные жилые дома. 42.2.2. Реестр (список) квартир, находящихся в многоквартирных жилых домах с обязательной привязкой к соответствующему дому. 42.2.3. Реестр (список) комнат, находящихся в квартирах с обязательной привязкой к соответствующей квартире. 42.3 Средства также должны обеспечивать возможность отображения объектов жилого фонда всех типов (жилые здания, квартиры, комнаты) единым списком. 42.4. Средства должны обеспечивать возможность отображения единым списком всех учитываемых средствами Системы объектов (реестровые и внереестровые объекты учета), включая объекты жилого фонда всех типов Соответствие Значение характеристики не может изменяться участником закупки 42.5.Средства Подсистемы должны включать в себя средства управления квартирами и комнатами, включенными в реестр объектов муниципальной собственности. Должно быть обеспечено разграничение прав пользователей по доступу на изменение к реестровой информации объектов муниципальной собственности. 42.6. Интерфейсные и функциональные решения, используемые при ведении реестра объектов жилого фонда всех типов (жилые дома, квартиры, комнаты) должны быть полностью аналогичны соответствующим средствам, используемых в Системе для управления объектами других типов (средства работы с табличным представлением данных, поиска/фильтрации, карточки объекта, составу учитываемых атрибутов, возможностям по настройке для учета расширенного набора реквизитов любых типов). 42.7. Для жилых зданий дополнительно должны быть обеспечены возможности работы со следующими показателями: 42.7.1. Управляющая компания - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. Формируется как ссылка на карточку субъекта права, размещенную в общем реестре субъектов права. Возможно указание произвольного количества документов-оснований (протокол собрания жильцов, договор). Подробно требования к средствам работы с управляющими компаниями описаны ниже. 42.7.2. Признак аварийности – требования к средствам работы с аварийными жилыми домами приведены ниже. 42.7.3. Этажность - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.4. Общее количество квартир - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.5. Перечень жилых квартир, расположенных в многоквартирном жилом здании – список отображается на одной из вкладок карточки многоквартирного жилого дома с возможностью быстрого доступа (одно действия) к карточке любой из квартир (на просмотр, изменение, добавление или удаление информации) Соответствие Значение характеристики не может изменяться участником закупки 42.7.6. Количество муниципальных объектов (квартир и комнат) – формируется автоматически на основе анализа единой базы данных с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.7. Количество квартир в единой базе данных системы – формируется автоматически на основе анализа единой базы данных с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.8. Общая площадь - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. Является реестровым показателем для объектов муниципальной собственности. 42.7.9. Общая жилая площадь - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.10. Общая полезная площадь - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.11. Год постройки - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.12. Способ передачи в собственность (поквартирно и целиком) - показатель заносится вручную с отображением в реестре (списке). 42.7.13. Документы основания – информация по произвольному количеству документов-оснований любых типов с возможностью хранения файла документа. 42.8. Для жилых квартир дополнительно будут обеспечены возможности работы со следующими показателями: 42.8.1. Ссылка на карточку многоквартирного жилого дома с быстрым доступом к карточке дома. 42.8.2. Управляющая компания - показатель определяется автоматически из карточки жилого здания с отображением в реестре (списке) и на основной вкладке карточки. Требования к средствам работы с управляющими компаниями описаны ниже. Соответствие Значение характеристики не может изменяться участником закупки 42.8.3. Собственники - показатель заносится вручную для объектов, не включенных в реестр муниципальной собственности. Формируется как ссылка на карточку субъекта права, размещенную в общем реестре субъектов права. В случае, если собственников несколько, возможно указание доли в праве собственности. Возможно указание произвольного количества документов-оснований на право собственности. Ввод собственников обязателен в случае использования средств автоматизации решения задачи переселения из аварийных жилых домов. Подробнее требования к автоматизации задачи переселения описаны ниже. 42.8.4. Наниматели - показатель заносится вручную для объектов муниципальной собственности. Формируется как ссылка на карточку субъекта права, размещенную в общем реестре субъектов права. В случае, если нанимателей несколько, возможно указание доли. Возможно указание произвольного количества документов-оснований. Ввод нанимателей обязателен в случае использования средств автоматизации решения задачи переселения из аварийных жилых домов (допустим также ввод договоров социального или специализированного найма – в этом случае перечень нанимателей определяется автоматически). Подробнее требования к автоматизации задачи переселения описаны ниже. 42.8.5. Признак аварийности – устанавливается автоматически для всех квартир жилого дома, для которого установлен признак аварийности. Требования к средствам работы с аварийными жилыми домами приведены ниже. 42.8.6. Признак невозможности для проживания – устанавливается вручную с указанием документов оснований. 42.8.7. Признак принадлежности к специализированному жилому фонду – устанавливается вручную с указанием документов оснований. Требования к ведению реестра специализированного жилого фонда приведены ниже. 42.8.8. Этаж - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки. 42.8.9. Общее количество комнат - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке Соответствие Значение характеристики не может изменяться участником закупки 42.8.10. Перечень жилых комнат, расположенных в квартире – список отображается на одной из вкладок карточки квартиры с возможностью быстрого доступа (одно действие) к карточке любой из комнат (на просмотр, изменение, добавление или удаление информации). Перечень комнат как отдельных объектов учета ведется в случае, если собственники квартиры отличаются от собственников комнат (или комнаты имеют разных собственников), например, для случая коммунальных квартир, общежитий. 42.8.11. Количество муниципальных комнат – формируется автоматически на основе анализа единой базы данных с отображением в реестре (списке) и на основной вкладке карточки. 42.8.12. Количество комнат в единой базе данных системы – формируется автоматически на основе анализа единой базы данных с отображением в реестре (списке) и на основной вкладке карточки квартиры. 42.8.13. Общая площадь - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки. Является реестровым показателем для объектов муниципальной собственности. 42.8.14. Общая жилая площадь - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.8.15. Общая полезная площадь - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.8.16. Документы основания – информация по произвольному количеству документов-оснований любых типов с возможностью хранения файла документа. 42.9. Для жилых комнат дополнительно будут обеспечены возможности работы со следующими показателями: 42.9.1. Ссылка на карточку квартиры с быстрым доступом к карточке квартиры (одно или два действия). 42.9.2. Управляющая компания - показатель определяется автоматически из карточки жилого здания с отображением в реестре (списке) и на основной вкладке карточки. Подробно требования к средствам работы с управляющими компаниями описаны ниже Соответствие Значение характеристики не может изменяться участником закупки 14. Требования к подсистеме «Ведение информации по субъектам права»: 14.1. Подсистема должна обеспечивать ведение информации по муниципальным предприятиям и учреждениям (как реестровым объектам), а также по субъектам права, участвующих в имущественно-земельных отношениях (юридические, физические лица, индивидуальные предприниматели). 14.2. Подсистема должна автоматизировать выполнение следующих основных задач: 14.2.1. Пообъектный учет субъектов права. Для каждого из субъектов права ведется следующая основная информация: 14.2.1.1. Наименование субъекта права (полное и краткая информация, с историей изменения). 14.2.1.2. ИНН. 14.2.1.3. Принадлежность к реестру, подреестру (с историей изменения и ссылкой на документ-основание). 14.2.1.4. Реестровый номер (с историей изменения и ссылкой на документ-основание). 14.2.1.5. Адрес (с возможностью ввода множественного адреса), структура адреса должна соответствовать федеральным требованиям (ФИАС). Система должна обеспечивать возможность автоматизированного обновления классификаторов адресной подсистемы на основе ФИАС. 14.2.1.6. Организационная форма, вид деятельности, вид собственности (классификаторы) Соответствие Значение характеристики не может изменяться участником закупки 14.2.1.7. Контакты - руководитель, главный бухгалтер, другие сотрудники (произвольное количество), телефоны (произвольное количество), банковские реквизиты (с историей изменения), реквизиты трудовых договоров руководителя и главного бухгалтера с возможность загрузки в систему самих договоров и дополнительных соглашений к ним, а также реквизитов документов о назначении и увольнении руководителей с возможностью загрузки в систему указанных документов. 14.2.1.8. Информация по членам семьи, родственным отношениям (для физических лиц). 14.2.1.9. Паспортные данные (для физических лиц, индивидуальных предпринимателей) – с историей изменения, дата рождения. 14.2.1.10. Субъекты права (представители, учредители) – с историей изменения и ссылками на документы-основания, возможностью расширения в части регистрации произвольного количество субъектов права произвольного типа (любого вида права, с возможностью расширения). 14.2.1.11. Экономические показатели (балансовая, остаточная стоимость объектов на балансе, среднесписочная численность сотрудников, показатели эффективности) – с историей изменения и ссылками на документы-основания. Должна быть обеспечена возможность учета произвольного количества экономических показателей любого типа с возможностью расширения средствами системы. 14.2.1.12. Классификационные коды (ОКВЭД, ОКОНХ, ОГРН, КПП) – с ведением истории и ссылками на документы-основания, с возможностью расширения перечня учитываемых кодов без участия программистов. 14.2.1.13. Информация по документам (все документы, имеющие отношение к данному объекту с делением по направлениям воздействия документов (включение/исключение, внесение изменений, правоустанавливающие, регистрирующие документа)). Должна быть обеспечена возможность учета информации по произвольному количеству документов любого типа с возможностью расширения средствами системы. 14.2.1.14. Комиссии Соответствие Значение характеристики не может изменяться участником закупки 14.2.1.15. События (даты жизненного цикла объекта) с возможностью расширения количества и типов событий средствами системы. 14.2.1.16. Признаки (принадлежности к определенным учетным категориям, группам в соответствии с технологией учета) с возможностью расширений наименований признаков средствами системы. 14.2.1.17. Перечень объектов имущества на балансе и в пользовании. 14.2.1.18. Перечень земельных участков в землепользовании и в пользовании (аренда). 14.2.1.19. Перечень договоров всех типов для объектов имущества (аренда, купля/продажа, безвозмездное пользование, социальный найм). 14.2.1.20. Перечень договоров всех типов для земельных участков (аренда, купля/продажа, безвозмездное пользование). 14.2.1.21. Полная финансовая информация по всем видам договоров (начисления, платежи, задолженность). 14.2.1.22. Информация по банкротству. 14.2.1.23. Информация по претензионной и исковой деятельности (детальная информация по поданным претензиям и искам, включая необходимую классификационную и описательную части, предметы исков, в том числе суммы с делением по видам начислений, перечень этапов претензионной и исковой деятельности с указанием ссылок на документы этапа, уточнение требований) – см. Пункт «подсистема автоматизации претензионной и исковой деятельности». 14.2.2. Управление историей изменения основных данных по субъектам права, документами-основаниями на проведение изменений Соответствие Значение характеристики не может изменяться участником закупки 14.2.3. Управление движением субъектов права в реестре и списках учета (включение, исключение, перемещение между реестрами, ведение истории реорганизации объектов (слияния, разделения)), документами-основаниями, правоустанавливающими и другими документами. 14.2.4. Использование информации по субъектам права при формировании договоров, дополнительных соглашений, других документов, при формировании информации о других имущественно-земельных отношениях с участием соответствующих субъектов права. 14.2.5. Формирование аналитики по деятельности субъекта права в рамках имущественно-земельных отношений. 14.2.6. Формирование аналитики по задолженности, работа с должниками. 14.2.7. Возможность формирования аналитической отчетности в соответствующей сфере (с использованием встроенных средств генераторов отчетов). 14.2.8. Проведение экспресс-аналитики. 14.2.9. Управления предприятиями банкротами 14.2.9.1. В Системе должна быть реализована возможность управления информацией о предприятиях банкротах, а также процессах и стадиях банкротства. В рамках данной функции должна быть предусмотрена возможность ведения следующей информации: 14.2.9.1.1. Перечень стадий банкротства (внешнее наблюдение, конкурсное управление). 14.2.9.1.2. Информацию об управляющих компаниях и саморегулирующихся организациях. 14.2.9.1.3. Перечень заседаний руководства для обсуждения текущих вопросов. 14.2.9.1.4. Сведения о публикации сведений о банкротстве. 14.2.9.1.5. Реестр требований кредиторов для реструктуризации задолженности. 14.2.9.1.6. Информация о конкурсной массе на момент открытия конкурсного производства. 14.2.9.1.7. Периоды изменения всех вышеперечисленных атрибутов. 14.2.9.1.8. Информация о всех документах, связанных со всеми процессами банкротства, а также связи данных документов с теми атрибутами, на изменение которых они направлены Соответствие Значение характеристики не может изменяться участником закупки 41. Требования к подсистеме «Управление объектами жилого фонда» включая Подсистему :«Аварийное жилье» учет и управление: 41.1. Подсистема должна обеспечивать комплексную автоматизацию решения вопросов управления объектами жилого фонда, в том числе: 41.1.1. Ведение жилых зданий: 41.1.1.1. Ведение всех характеристик жилых зданий в рамках единой базы данных, в том числе: 41.1.1.1.1. Этажность. 41.1.1.1.2. Общее количество квартир. 41.1.1.1.3. Количество муниципальных объектов (квартир и комнат). 41.1.1.1.4. Количество квартир в единой базе данных системы. 41.1.1.1.5. Общая площадь. 41.1.1.1.6. Общая жилая площадь. 41.1.1.1.7. Общая полезная площадь. 41.1.1.1.8. Год постройки. 41.1.1.1.9. Способ передачи в собственность (поквартирно и целиком). 41.1.1.1.10. Документы основания. 41.1.1.2. Ведение полной информации о признании дома аварийным, этапам процесса расселения (включая средства автоматизации приобретения жилья для нужд расселения, заключения договоров мены и социального найма в процессе переселения) и ликвидации аварийных домов. 41.1.2. Ведение информации по управляющим компаниям, средства автоматизации работы с управляющими компаниями, в том числе: 41.1.3. Работа с протоколами общих собраний жильцов. 41.1.4. Заключение договоров с управляющими компаниями. 41.1.5. Ведение полной информации по управляющей компании. 6. Ведение реестра жилых квартир с привязкой к многоквартирным жилым домам: 41.1.6.1. Ведение всех характеристик муниципальных и немуниципальных квартир в рамках единой базы данных, в том числе: 41.1.6.1.1. Этаж. 41.1.6.1.2. Общее количество комнат. 41.1.6.1.3. Количество комнат в единой базе данных системы. 41.1.6.1.4. Общая площадь. 41.1.6.1.5. Общая жилая площадь. 41.1.6.1.6. Общая полезная площадь. 41.1.6.1.7. Документы основания Соответствие Значение характеристики не может изменяться участником закупки 41.1.6.2. Ведение информации по собственникам квартир, долям в праве собственности, документам основаниям, переходе и регистрации права собственности. 41.1.6.3. Ведение информации о непригодности квартиры для проживания, документам основаниям. 41.1.7. Ведение реестра жилых комнат с привязкой к жилым квартирам: 41.1.7.1. Ведение всех характеристик комнат в рамках единой базы данных. 41.1.7.2. Ведение информации по собственникам комнат, долям в праве собственности, ментам основаниям, переходе и регистрации права собственности. 41.1.7.3. Ведение информации о непригодности для проживания, документам основаниям. 41.1.8. Ведение реестра специализированного жилого фонда (служебное жилье, маневренный фонд). Включая: 41.1.8.1. Реестр специализированного жилищного фонда также будет расширен: 41.1.8.1.1. Служебные жилые помещения. 41.1.8.1.2. Жилые помещения в общежитиях. 41.1.8.1.3. Жилые помещения маневренного фонда. 41.1.8.1.4. Жилые помещения в домах системы социального обслуживания населения. 41.1.8.1.5. Жилые помещения для социальной защиты отдельных категорий граждан. 41.1.8.1.6. Жилые помещения для детей-сирот и детей, оставшихся без попечения родителей, лиц из числа детей-сирот и детей, оставшихся без попечения родителей. 41.1.9. Ведение информации по переводам жилого (нежилого) фонда в нежилой (жилой) фонд, автоматизация ведения процесса перевода, ведение информации по документам-основаниям, разрешениям, протоколам. 41.1.10. Заключение и управление договорами социального и специализированного найма 41.1.11. Автоматизация решения вопросов приватизации и продажи муниципальных и муниципальных жилых помещений, автоматизация процесса исключения приватизированных жилых помещений из муниципальной собственности. 41.1.12. Ведение информации о приобретении жилых помещений (квартир), в том числе для нужд переселения, автоматизация решения вопросов включения, приобретаемых для нужд переселения квартир в муниципальную собственность Соответствие Значение характеристики не может изменяться участником закупки 25. Требования к подсистеме «Автоматическое обновление клиентских рабочих мест»: 25.1. Подсистема «Автоматическое обновление клиентских рабочих мест» (далее – подсистема автообновления) должна быть построена по клиент-серверной архитектуре, обновления должны распространятся по сети с использованием протокола TCP/IP. 25.2. Подсистема автообновления должна состоять из следующих компонентов (программ): 25.2.1. «Служба обновления» – серверная часть подсистемы автообновления, устанавливаемая на компьютере – сервере. 25.2.2. «Конфигуратор службы обновления» – утилита по настройке службы обновления. 25.2.3. «Клиент обновления» – клиентская часть подсистемы автообновления, устанавливаемая на компьютере пользователя. 25.3. Подсистема автообновления должна обладать следующим функционалом: 25.3.1. Автоматическое обновление клиентов обновлений на компьютерах пользователей при установке новой версии системы обновлений. Служба должна предоставлять клиентским местам Системы актуальную версию клиента обновлений. Для каждой новой версии клиента обновлений должен генерироваться уникальный идентификатор обновления. 25.3.2. Автоматическое обновление клиентских мест Системы на компьютерах пользователей при наличии обновлений программы. Служба должна предоставлять клиентским местам Системы актуальные версии файлов программы. Для каждой новой версии программы должен генерироваться уникальный идентификатор обновления. 25.3.3. Автоматическое восстановление отсутствующих файлов клиентских мест Системы на компьютерах пользователей Соответствие Значение характеристики не может изменяться участником закупки 25.3.4. При обновлении клиентских мест должна поддерживаться работа со списком исключений для удаления с клиентских мест устаревших файлов и папок. 25.3.5. Возможность обновления клиентских мест Системы из нескольких источников. Количество источников не должно быть ограничено. Для каждого источника должна быть предусмотрена возможность задать имя, путь к папке с файлами обновлений, а также путь к файлу со списком исключений. 25.3.6. Возможность сжатия пересылаемых по сети пакетов для уменьшения нагрузки на сеть. Активация данного функционала должна происходить по решению администратора. 25.3.7. Возможность контроля целостности пересылаемых по сети пакетов для предотвращения модификации пересылаемых файлов сторонним ПО, вирусами и иными внешними факторами. Файлы должны приходить на компьютеры пользователей в неизменном виде. 25.4. Служба обновления: 25.4.1. Серверная часть подсистемы автообновления должна быть представлена в виде службы ОС (далее – Служба). Служба должна отвечать на запросы «Клиентов обновления» (далее – Клиентов), предоставляя им всю необходимую информацию об обновлениях, а также сами обновления. 25.4.1. Должна быть предусмотрена возможность запустить Службу как вручную, так и с помощью конфигуратора службы. Также Служба должна запускаться автоматически при включении компьютера и не требовать входа в Систему под учетной записью какого-либо пользователя. 25.4.2. Служба обновления должна применять новые настройки конфигурации автоматически, без необходимости перезапуска. Соответствие Значение характеристики не может изменяться участником закупки 25.4.3. Служба обновления должна автоматически отслеживать наличие новой версии клиента обновлений, а также отслеживать любые изменения в папках источников обновлений. При наличии новой версии клиента обновлений служба должна сгенерировать уникальный идентификатор обновления. Этот идентификатор должен передаваться клиентам обновления на клиентских местах при их подключении к службе обновлений. При наличии изменений в папках источников обновлений служба должна сгенерировать уникальный идентификатор обновления индивидуально для каждого источника обновлений. Этот идентификатор должен передаваться клиентам обновления на клиентских местах при их подключении к службе обновлений. 25.5. Конфигуратор службы обновления (далее – Конфигуратор).: 25.5.1. Конфигуратор не должен требовать установки и должен иметь возможность быть запущенным из любого места на компьютере, где установлена служба обновления. При запуске конфигуратор должен проверять наличие установленной службы и в случае её отсутствия, сообщить об этом пользователю. Если Служба установлена, то должно открываться окно Конфигуратора, на котором должны быть представлены текущие настройки Службы. 25.5.2. Конфигуратор должен обладать следующим фунционалом по настройке службы обновления: 25.5.2.1. Отслеживать текущее состояние Службы. 25.5.2.2. Иметь средства для остановки, запуска и перезапуска службы обновления. 25.5.2.3. Позволять указывать местоположение актуальной версии клиента обновления (которая совместима со службой обновления). 25.5.2.4. Позволять управлять (активация/деактивация) опцией по сжатию пакетов, передаваемых по сети (для уменьшения нагрузки на сеть) Соответствие Значение характеристики не может изменяться участником закупки 25.5.2.5. Позволять управлять (активация/деактивация) опцией по контролю целостности пакетов, передаваемых по сети (для предотвращения модификации содержимого пакетов внешними факторами). 25.5.2.6. Позволять добавлять новые источники обновлений (без ограничения по их количеству). 25.5.2.7. Позволять редактировать сведения об источниках обновлений. В частности, настраивать следующие параметры: 25.5.2.8. Задавать имя источника обновлений. 25.5.2.9. Указывать путь к папке с файлами обновлений. 25.5.2.10. Указывать путь к файлу исключений. 25.6. Клиент обновлений: 25.6.1. Клиентская часть подсистемы автообновления должна быть представлена в виде отдельной программы – клиента обновления. 25.6.2. Клиент обновления должен быть предназначен для соединения со службой обновления, расположенной на другом или текущем компьютере, и получения от неё актуальной версии файлов обновляемой программы, а также актуальной версии самого клиента обновления. 25.6.3. Клиент обновления не должен требовать специальной установки и может быть запущен из любого места. Клиент обновления должен обладать возможностью запуска в двух режимах: 25.6.3.1. «Режим настройки» - в этом режиме должно открываться окно настройки клиента обновления. 25.6.3.2. «Режим обновления» - в этом режиме программа должна выполнять соединение с сервером обновлений, согласно выполненной настройке, и получать от сервера обновлений актуальные версии файлов обновляемой программы и самого клиента. 25.6.4. Клиент обновления в «режиме настройки» должен предоставлять возможность задавать следующие настройки: 25.6.4.1. Настройки подключения к службе обновлений (IP-адрес или имя компьютера, на котором установлена служба обновлений, порт служба обновлений). Для проверки корректности настройки должна быть предусмотрена кнопка для тестирования соединения. Соответствие Значение характеристики не может изменяться участником закупки 25.6.4.2. В случае необходимости подключения к серверу через прокси-сервер, должна быть возможность в соответствующей группе настроек указать IP-адрес прокси-сервера, порт подключения к прокси-серверу, а также логин и пароль для авторизации на прокси-сервере (при необходимости). 25.6.4.3. Источник обновления. Выбор источника обновлений должен осуществляться из выпадающего списка, а котором должны присутствовать все доступные источники обновлений. 25.6.4.4. Путь к временной папке, в которую будут загружаться обновления перед их применением. 25.6.4.5. Путь к папке, в которую необходимо сохранить загруженные обновления. 25.6.4.6. Путь к файлу программы, которую необходимо запустить после обновления. Должна присутствовать возможность настроить запрет запуска нескольких экземпляров. 25.6.4.7. Индивидуальная для клиентского места настройка сжатия пакетов, передаваемых по сети. 25.6.4.8. Индивидуальная для клиентского места настройка контроля целостности пакетов, передаваемых по сети. 25.6.4.9. Настройка протоколирования процесса обновления. 25.6.4.10.Если ip-адрес и имя сервера обновления неизвестны, то должна быть реализована возможность автоматического поиска сервера в локальной сети. Для автоматического поиска сервера должна присутствовать кнопка «Поиск сервера». После успешного поиска, настройки подключения должны быть установлены автоматически, и пользователю должно быть показано соответствующее уведомление. 25.6.5. Клиент обновления в «режиме обновления» должен осуществлять следующие действия: 25.6.5.1. Проверять наличие новой версии клиента обновления. Для этого клиент обновления должен получить текущий идентификатор обновления клиента и сравнить с ранее сохраненным идентификатором. Если идентификаторы различаются, то клиент обновления должен произвести самообновление с сохранением текущего идентификатора обновления Соответствие Значение характеристики не может изменяться участником закупки 25.6.5.2. Проверить наличие обновлений клиентского места Системы. Для этого клиент обновления должен получить текущий идентификатор обновления клиентского места и сравнить с ранее сохраненным идентификатором. Если идентификаторы различаются, то клиент обновления должен произвести загрузку измененных и новых файлов с сохранением текущего идентификатора обновления. При загрузке обновлений должны загружаться только новые и изменение файлы (сверяться контрольные суммы файлов (CRC)). 25.6.5.3. При отсутствии обновлений клиентского места Системы клиент обновления должен проверить наличие отсутствующих файлов клиентского места Системы и при необходимости восстановить их. 25.6.5.4. По завершению работы клиент обновления должен произвести обработку файла исключений. Для этого клиент обновления должен получить содержимое файла исключений и удалить файлы и папки, согласно полученного списка. 25.6.6. Процесс обновления должен отображаться в виде окна, на котором должны быть размещены следующие элементы: 25.6.6.1. Текст сообщения с описанием текущего этапа обновления. 25.6.6.2. Индикатор прогресса обновления. Клиент обновления должен поддерживать возможность протоколирования процесса обновления в текстовом файле, который должен автоматически создаваться в папке клиента обновления Соответствие Значение характеристики не может изменяться участником закупки 22. Требования к подсистеме «Формирование отчетов и печатных форм, генератор отчетов»: 22.1. Подсистема должна предоставлять возможность формирования выходных данных системы – от простейших печатных карточек объектов учета до аналитических отчетов, выборок, прогнозов произвольной сложности по состоянию на произвольную дату в пределах информационного фонда Системы. 22.2. Подсистема не должна содержать ограничений на количество шаблонов отчетов и печатных форм. 22.3. В состав подсистемы должен входить генератор отчетов «FastReport» или эквивалент с помощью которого можно самостоятельно разрабатывать и подключать к Системе отчеты и печатные формы произвольной сложности, а также производить экспресс-изменения подключенных шаблонов. Кроме того, подсистема должна обладать возможностью подключения шаблонов отчетов и печатных форм, разработанных с помощью MS Word, MS Excel и OpenOffice (LibreOffice) или эквивалент с использованием API и VBA (или эквивалент). 22.4. Подсистема должна обеспечить формирование произвольного количества отчетов и печатных форм любой сложности в рамках информационного фонда Системы. 22.5. Для каждой печатной формы должна быть предусмотрена возможность выполнения произвольных действий (алгоритмов), выполняемых до и после формирования печатной формы. 22.6. Должна быть предусмотрена библиотека соответствующих алгоритмов с возможностью выбора ранее разработанного алгоритма для любой печатной формы любому пользователю, не обладающему какими-либо специальными знаниями Соответствие Значение характеристики не может изменяться участником закупки 22.7. Должна быть предусмотрена возможность добавления, изменения или удаления отчетов и печатных форм силами обученных пользователей Системы без необходимости обновления Системы или ее компонентов. 22.8. Средства ведения журналов сформированных документов (печатных форм): 22.8.1. В подсистеме формирования отчетов и печатных форм должна быть предусмотрена возможность реализации средств сохранения информации о формировании соответствующей печатной формы с привязкой к электронной карточке объектов учета, а также фиксированием информации о времени формирования и пользователе, который выполнял формирование. 22.8.2. Должна быть предусмотрена возможность вывода журналов сформированных ранее печатных форм заданного типа в заданный промежуток времени. 22.8.3. Должна быть предусмотрена возможность по необходимости добавления в печатную форму признака необходимости включения факта формирования печатной формы в журнал. 22.9. Должна быть предусмотрена возможность добавления, изменения или удаления отчетов и печатных форм силами специалистов Системы без необходимости обновления Системы или ее компонентов. 22.10. Должна быть предусмотрена возможность реализации описанных функций силами обученных специалистов Системы без необходимости обновления Системы или ее компонентов Соответствие Значение характеристики не может изменяться участником закупки 36. Требования к созданию электронной карточки объекта учета, дизайн карточки 36.1. Требования к электронным карточкам объектов учета единой реестровой подсистемы должны соответствовать общим требованиям к электронным карточкам объектов учета. 36.2. Для карточки объекта учета Единой реестровой подсистемы должна быть предусмотрена возможность создания произвольного количества контейнеров, содержащих перечень атрибутов объекта учета, элементы управления которыми размещаются в соответствующем контейнере. 36.3. Для каждого атрибута должна быть предусмотрена возможность настройки его видимости в карточке по умолчанию: 36.3.1. Всегда отображается – пользователю предлагается только указать значение атрибута. 36.3.2. По умолчанию не отображается, но пользователь может его добавить самостоятельно. 36.3.3. Для атрибутов, значения которых выбираются из справочника, должна быть возможность создания соответствующего справочника или использование имеющегося. 36.4. Создаваемые контейнеры атрибутов должны быть размещены в любой части экранной формы электронной карточки объекта (или на создаваемой вкладке электронной карточки) в соответствии с общими принципами. 36.5. Дополнительно для электронных карточек объектов учета Единой реестровой подсистемы должны быть предусмотрены возможности размещения контейнеров, использующихся для описания объектов имущественно-земельного комплекса: 36.5.1. Адрес, с отображением адреса одной строкой. 36.5.2. Адрес, с отображением произвольного количества адресов, каждый адрес отображается с разбиением на атрибуты, его составляющие (город, улица, номер дома и т.д.). 36.5.3. Документы – контейнер работы с документами по данному объекту учета. 36.5.4. Файлы. 36.5.5. Фотографии. 36.5.6. Типы использования. 36.5.7. Зоны размещения. 36.5.8. Элементы благоустройства. 36.5.9. Субъекты права. 36.5.10. Комиссии. 36.5.11. Экономические показатели. 36.5.12. Технические показатели. 36.5.13. События. 36.5.14. Признаки. 36.5.15. Элементы классификации. Соответствие Значение характеристики не может изменяться участником закупки 26. Требования к подсистеме «Оповещение пользователей»: 26.1. Подсистема оповещения должна быть доступна из главного меню клиента Системы и из главного меню сервера приложений, в случае если сервер приложений не запущен в режиме службы. 26.2. Подсистема оповещения пользователей должна обеспечивать следующие возможности: 26.2.1. Направить подключенным пользователям (подключенным клиентским приложениям) текстовое сообщение о проведении технических работ, требующих отключения клиентских приложений от Системы. Для данного типа сообщений должна быть предусмотрена возможность указания времени (в минутах), по истечении которого клиентские приложения должны быть автоматически отключены от Системы. Данное сообщение посылается всем подключенным клиентским приложениям и должно сопровождаться отображением счетчика обратного отсчета до автоматического отключения клиентского места. Сообщение должно отображаться поверх всех окон клиентского приложения. 26.2.2. Автоматически завершить работу всех подключенных клиентских приложений по истечении заданного времени. 26.2.3. Формировать простые текстовые сообщения подключенным пользователям Системы Соответствие Значение характеристики не может изменяться участником закупки 26.2.4. Формировать текстовые сообщения всем пользователям Системы (не подключенные на момент формирования сообщения пользователи получат сообщение в момент следующего подключения). Пользователь должен получить сообщение только один раз вне зависимости от компьютера, на котором запущено клиентское приложение (в отличие от сообщений об автоматическом отключении клиентских приложений, простые текстовые сообщения должны отправляться не каждому клиентскому приложению, а пользователю, который был указан при подключении к клиентскому приложению. 26.2.5. Отзыв направленного ранее сообщения об отключении клиентских приложений. Автоматическое отключение клиентских приложений должно быть отменено, сообщение об отключении и таймер обратного отсчета на всех клиентских приложениях должны быть закрыты, должна быть возобновлена возможность подключения клиентских приложений. 26.2.6. Ведение журнала всех отправленных сообщений. 26.2.7. Ведение журнала получения сообщений пользователями. 26.3. Для оповещения должна быть предоставлена возможность выбора типа оповещения. Должна быть реализована возможность выбора следующих типов: 26.3.1. Оповещение о начале технических работ на сервере, о необходимости выхода из Системы и автоматического отключения клиента. 26.3.2. Простое оповещение только подключенным пользователям, автоматического отключения не происходит. 26.3.3. Оповещение всем пользователям, подключенным и не подключённым, неподключенные должны получить оповещение при первом входе в Систему. 26.4. Должен вестись журнал оповещений, обладающих следующими характеристиками: 26.4.1. Для каждого оповещения сохраняется информация с указанием их типа, текста сообщения, даты и времени отправки сообщения, пользователя, сформировавшего сообщения. 26.4.2. Журнал оповещений должен обладать средствами поиска сообщений по всем параметрам журнала. Реализованы фильтры по диапазону дат, пользователю, группе пользователей, текстовый поиск. 26.4.3. Невозможно удалить произвольное оповещение Соответствие Значение характеристики не может изменяться участником закупки 26.4.4. Удалить записи журнала о старых оповещениях можно только до указанной даты. Права на удаление записей имеет только администратор. 26.4.5. Ведется дополнительный лог по пользователям, прочитавшим оповещение. Просмотр лога так же доступен в интерфейсе просмотра журнала Соответствие Значение характеристики не может изменяться участником закупки 23. Требования к подсистеме «Обеспечение безопасности, администрирования и разграничения прав доступа»: 23.1. Подсистема должна: 23.1.1. Обеспечивать возможности индивидуальной настройки для каждого пользователя базовых ограничений прав и разрешений с возможностью дальнейшего расширения. 23.1.2. Возможности индивидуального ограничения просмотра реестра объектов любого из типов. 23.1.3. Возможности индивидуального ограничения просмотра данных карточек объектов учета любых типов. Предоставление прав на частичный просмотр информации по объекту (например, запрет на просмотр экономических показателей объекта, но разрешение на просмотр технических показателей). 23.1.4. Возможности ограничения доступа к персональным данным, требующим отдельной защиты. 23.1.5. Возможности индивидуального ограничения изменения данных по объектам учета всех типов. Предоставление прав на частичное изменение информации. 23.1.6. «Горизонтальное» ограничение прав на изменение множественных атрибутов объектов учета (например, пользователю предоставляются права на изменение/внесение в карточку объектов документов определенной направленности и закрываются права на правку документов иной направленности (например, реестровых документов)). 23.1.7. Ограничение прав на выполнение различных операций с объектом учета (выделение подобъектов, включение в группу). 23.1.8. Ограничение на операции с печатными формами (просмотр и печать отчетов и печатных форм, экспорт во внешние форматы (docx, xlsx), редактирование сформированных отчетов). Для печатных форм права должны назначаться индивидуально для каждого типа объектов учета, для аналитических отчетов – индивидуально для каждой темы отчета Соответствие Значение характеристики не может изменяться участником закупки 23.1.9. Ограничение прав на работу с блоками начислений и платежей за аренду недвижимости и ЗУ (индивидуально на все функции, выполнение операций в каждом из режимов (индивидуальном, массовом)). 23.1.10. Ограничение прав на работу с универсальной библиотекой запросов – права предоставляются индивидуально для каждой темы запросов и на выполнение операций блока запросов (выполнение запроса, экспорт результатов). 23.1.11. Ограничение прав на работу с НСИ (права предоставляются индивидуально для каждого справочника или классификатора). 23.1.12. Ограничение права на настройки системы (индивидуально на каждый блок настроек). 23.2. Все права и разрешения на работу с объектами учета всех типов должны предоставляться индивидуально для каждой стадии формирования объекта учета (заявка, новый, актуальный (реестровый), актуальный зарегистрированный (в Росреестре), архивный, справочный, внереестровый или объект налогового потенциала). 23.3. В Системе должны присутствовать средства объединения пользователей в группы (причем, каждый пользователь может быть включен в одну и иное количество групп) с автоматическим наследованием всех прав и разрешений групп, в которые включен пользователь. 23.4. В Системе должны быть реализованы особые механизмы хранения и проверки паролей, обеспечивающие повышенную безопасность. При установке и смене пароля, новый пароль кодируется необратимыми алгоритмами (без возможности восстановления исходного пароля). 23.5. Разграничение прав пользователей единого информационного пространства: 23.5.1. Для каждого пользователя или группы пользователей должна быть предусмотрена возможность управления правами доступа (в объеме, описанном выше) индивидуально для каждого из информационных фондов организаций-участников, составляющих единую базу данных Системы. 23.5.2. В совокупности с возможностью сопоставления пользователей с соответствующими информационными фондами, а также автоматической идентификации принадлежности объектов учета к соответствующим информационным Соответствие Значение характеристики не может изменяться участником закупки 27. Подсистема «Самодиагностика с автоматическим оповещением о выявленных аномалиях по электронной почте»: 27.1. Подсистема «Самодиагностика с автоматическим оповещением о выявленных аномалиях по электронной почте» должна быть использована в целях улучшения качества работы, уменьшения количества ошибок, уменьшения времени реагирования на появление проблемы. Должен быть сформирован набор тестов, проверяющих состояние работоспособности Системы и ее подсистем, возникновения проблем при взаимодействии Системы с внешними системами, возникновении некорректных данных в информационном фонде. Мониторинг работоспособности должен производиться непрерывно. Мониторинг целостности и непротиворечивости данных должен проверяться при помощи регламентных операций, выполняемых Системой по заданному расписанию (например, в ночное время). 27.2. Оповещения должны отправляться с использованием механизма очереди оповещений на адреса электронной почты, которые заданы при настройке подсистемы «Самодиагностика с автоматическим оповещением о выявленных аномалиях по электронной почте» Соответствие Значение характеристики не может изменяться участником закупки 28. Средства ведения электронных карточек объектов учета: 28.1. Под объектом учета понимается любой объект, информация по которому должна быть учтена в едином информационном фонде Системы. Например, объектами учета являются: земельные участки любой формы собственности, а также земельные участки, собственность на которые не разграничена, объекты движимого и недвижимого имущества, субъекты права, документы, договоры, соглашения, претензионные и исковые процессы, финансовые поступления. 28.2.Для доступа к реквизитам (атрибутам, характеристикам) объекта учета в Системе должна быть предусмотрена отдельная экранная форма. Экранная форма по умолчанию должна открываться в режиме просмотра (возможность редактирования атрибутов объекта должна быть отключена) с возможностью переключения в режим редактирования. 28.3. Экранная форма доступа к реквизитам объекта должна отображать информацию по объекту учета в соответствии с правами и разрешениями пользователя (не отображать атрибуты объекта, для которых у пользователя отсутствуют права на просмотр). 28.4. При переключении экранной формы карточки объекта учета в режим редактирования доступ на редактирование должен быть предоставлен только к тем атрибутам объекта учета, на которые активный пользователь имеет права и разрешения на изменение. Остальные атрибуты должны оставаться в режиме просмотра (без возможности внесения изменений). Соответствие Значение характеристики не может изменяться участником закупки 24. Требования к подсистеме «Ведение нормативно-справочной информации»: 24.1. Подсистема должна обеспечивает функционирование необходимого для эффективной работы Системы набора справочников и классификаторов. 24.1. Помимо федеральных справочников и классификаторов, а также справочников и классификаторов, формируемых в процессе поставки Системы, в состав Системы должен быть включен ряд дополнительных справочников, направленных на: 24.1.1. Повышение аналитических возможностей Системы. 24.1.2. Повышение возможностей Системы по расширению перечня учитываемых показателей. 24.1.3. Повышения адаптивности Системы к изменению законодательства, технологии учета, обеспечения быстрой настройки Системы под все нюансы работы органов управления имущественно-земельным комплексом. 24.2. В Системе должна быть возможность доступа к справочникам и классификаторам непосредственно в ходе редактирования параметра с выбором из справочника с целью выполнения расширенного поиска, а по необходимости и внесения изменений в классификатор. 24.3.Должна быть реализована возможность «привязки» как самих классификаторов, так и элементов классификации к видам реестров. Классификаторы и элементы классификации должно быть возможно выбрать только в тех реестрах, в которых это разрешено настройками Системы Соответствие Значение характеристики не может изменяться участником закупки 29. Требования по ведению атрибутов объектов учета 29.1. Объект учета в обязательном порядке должен содержать следующую информацию: 29.1.1. Идентификатор (реестровый номер) – числовое значение, однозначно идентифицирующее объект учета (не должно существовать любого другого объекта учета, имеющего такой же идентификатор). Идентификатор должен присваиваться Системе автоматически при создании нового объекта. 29.1.2. Наименование (описание) объекта – строковое значение, описывающее объект, заполняется вручную, не является обязательным. 29.2. Объект учета должен иметь произвольное количество атрибутов (характеристик). Каждый атрибут должен содержать: 29.2.1. Наименование (идентификатор) атрибута – выбирается из соответствующих справочников наименований атрибутов каждого из типов данных. Должен быть предусмотрен инструмент формирования допустимого перечня атрибутов, который может быть указан (выбран) в карточке каждого из типов объектов учета (инструмент индивидуального формирования перечня атрибутов для каждого типа объектов учета). 29.2.2. Значение – указывается в зависимости от типа данных атрибута. 29.2.3. Период действия – дата начала периода действия атрибута и дата окончания периода действия атрибута. Индивидуально для каждого вида (наименования) атрибута должна быть предусмотрена возможность настройки допустимости пересечения периодов действия значений этого атрибута (множественный ввод значений одноименных атрибутов в один момент времени). 29.2.4. Перечень ссылок на документы основания начала действия значения атрибута – перечень ссылок на информацию о документах с обязательным указанием основного документа основания. Соответствие Значение характеристики не может изменяться участником закупки 29.2.5. Перечень ссылок на документы основания окончания действия значения атрибута – перечень ссылок на информацию о документах с обязательным указанием основного документа основания. Индивидуально для каждого вида (наименования) атрибута должна быть предусмотрена возможность настройки использования документов оснований окончания действия (используется или нет). 29.2.6. Примечание – текстовое поле. 29.3. Система должна обеспечивать возможность ведения атрибутов объектов учета следующих типов данных: 29.3.1. Числовой тип (коэффициент). Должна быть предусмотрена возможность установки фиксированного значения величины коэффициента для каждого наименования коэффициента (наименования атрибута соответствующего типа) без возможности индивидуального изменения в карточке объекта учета (константа) или с возможностью индивидуального изменения (в этом случае значение, связанное с наименованием коэффициента, должно устанавливаться как значение по умолчанию с возможностью последующей корректировки индивидуально в карточке конкретного объекта). Такая настройка должна быть предусмотрена индивидуально для каждого вида (наименования) коэффициента. 29.3.2. Денежный тип (экономический показатель). 29.3.3. Строковый тип (технический, описательный показатель). Для каждого наименования атрибута данного типа должна быть предусмотрена возможность установки маски ввода значения атрибута Соответствие Значение характеристики не может изменяться участником закупки 29.3.4. Классификационный тип – справочник. Для каждого наименования атрибута (категории классификационных данных) должна быть предусмотрена возможность индивидуальной настройки перечня (справочника) элементов классификатора данной категории. 29.3.5. Булевый тип – признак (да/нет). Допустимо отсутствие ведения информации по периоду действия и документам-основаниям. 29.3.6. Тип даты – событие. 29.3.7. Ссылка на субъект права – с указанием типа субъекта права. 29.4. Кроме того, в карточку объекта учета дополнительно должны быть загружены: 29.4.1. Информация по адресу объекта с использованием адресной подсистемы. 29.4.2. Произвольное количество файлов любого типа. Файлы должны загружаться как по одному, так и массово, путем выделения нескольких файлов в средстве работы с файлами операционной системы (проводнике, менеджере файлов). Должна быть предусмотрена возможность загрузки в карточку объектов файлов путем использования технологии Drag-And-Drop (перетащи и отпусти). Открытие файлов должно производиться непосредственно из Системы путем использования средств операционной системы, назначенных по умолчанию (аналогично открытию файлов проводником или другим менеджером файлов). Хранение прикрепленных файлов объекта учета должно производиться на сервере в базе данных или с использованием других средств, обеспечивающих надежность и скорость работы с файлами не хуже соответствующих инструментов СУБД (транзакционный механизм доступа с возможностью автоматического отката транзакций, завершившихся аварийно, резервное копирование). 29.4.3. Произвольное количество файлов распространенных графических форматов (jpg, bmp). Функционал аналогичен работе с прикрепленными файлами. Дополнительно в Системе должны быть предусмотрены средства предварительного просмотра графических изображений без открытия файлов (средства предварительного просмотра). 29.4.4. Информация о произвольном количестве документов: Соответствие Значение характеристики не может изменяться участником закупки 29.4.4.1. Направление документа – значение из соответствующего справочника, указывающее на назначение документа в карточке объекта – определяется технологией работы с объектами соответствующего типа. 29.4.4.2. Номер документа. 29.4.4.3. Дата документа. 29.4.4.4. Тип документа – значение из классификатора типов документов. 29.4.4.5. Источник документа – значение из классификатора источников документов (организация, выпустившая документ). 29.4.4.6. Наименование документа – текстовое описание с возможностью выбора из справочника шаблонов наименований с возможностью последующего индивидуального изменения. 29.4.4.7. Примечание документа. 29.4.4.8. Ссылка на прикрепленный файл документа. 29.5. Сохранение карточки объекта учета (атрибутов, файлов, графических объектов, документов должно производиться на основе транзакционных механизмов, то есть либо вся измененная информация карточки (внесенные в карточку данные) должны быть успешно сохранены в базе данных, либо, например, в случае какой-либо ошибки, все изменения в базе данных, выполненные в процессе сохранения, должны быть отменены, и карточка вернется в состояние, предшествующее сохранению. Пользователь должен подробно быть проинформирован Системой о характере возникшей ошибки и, по возможности, Система даст рекомендации по способам исправления ошибки. После исправления пользователем причин, приведшим к ошибке, должна быть предусмотрена возможность повторного сохранения внесенных в карточку изменений. Частичное автоматическое внесение изменений в базу данных в процессе внесения изменений в карточку объектов недопустимо Соответствие Значение характеристики не может изменяться участником закупки 38. Средства выполнения массовых операций: 38.1. Система должна иметь средства выполнения однотипных операций над заданным количеством объектов учета, в том числе: 38.1.1. Передача с баланса на баланс, в казну, из казны, списание объектов. 38.1.2. Внесение документа-основания. 38.1.3. Смена адреса. 38.1.4. Смена характеристик объектов учета. 38.1.5. Изменить нумерацию объектов. 38.1.6. Слияние «двойников». 38.1.7. Включить физическое лицо в очередь и исключить из очереди. 38.1.8. Выполнение массовых запросов СМЭВ к сервисам Росреестра и другим информационным системам, с которыми предусмотрено взаимодействие по протоколам СМЭВ. 38.1.9. Массовое формирование квитанций, уведомлений, претензий и других печатных форм на основе заданных шаблонов. 38.2 .Массовые операции должны повысить эффективность управления имущественно-земельным комплексом, снизить трудозатраты специалистов на выполнение операций над объектами Соответствие Значение характеристики не может изменяться участником закупки 39. Требования к подсистеме «Бюджетный учет доходов»: 39.1. Подсистема бюджетного учета доходов должна применяться для администрирования доходов по всем администрируемым кодам бюджетной классификации, а также отражении в бухгалтерском учете активов, обязательств, фактов хозяйственной жизни, иных объектов бухгалтерского учета, возникающих при получении (предоставлении) во временное владение и пользование или во временное пользование материальных ценностей по договору аренды (имущественного найма) либо по договору безвозмездного пользования в соответствии с требованиями федеральных стандартов бухгалтерского учета для организаций муниципального сектора (в том числе бюджетный учет операций по льготной аренде, учет на забалансовых счетах бюджетного учета). 39.2. Подсистема должна быть полностью «прозрачной» для пользователей с точки зрения формирования всей необходимой бухгалтерской информации (проводок)/информации по бюджетному учету, соответствующих выполнению финансово-аналитических операций, проведению и оформлению результатов инвентаризации. Иными словами, Система автоматически должна формировать необходимую бухгалтерскую информацию (проводки) в соответствии со всеми требованиями, определенными инструкциями Министерства финансов РФ от 1 декабря 2010 года № 157н, от 6 декабря 2010 года № 162н, от 16 декабря 2010 года № 174н, № 258н от 31 декабря 2016 года, № 209н от 29 ноября 2017 года, федеральными стандартами бухгалтерского учета для организаций муниципального сектора, отслеживая эффективность работы муниципального учреждения. 39.3. Печатные формы и отчеты должны удовлетворять формам бухгалтерской отчетности организаций согласно приказу Министерства Финансов РФ № 66н от 2 июля 2010 года и № 52н от 30 марта 2015 года: 39.3.1. Бухгалтерский отчет «Информация по администрируемым доходам, обобщенный (свернутый)» и запрос-расшифровка к нему «Бухгалтерия подоговорная». 39.3.2. Оборотно-сальдовые ведомости по счетам (Счета 205, 401, 209, 210). Соответствие Значение характеристики не может изменяться участником закупки 39.3.3. Журнал операций № 2 с безналичными денежными средствами (ОКУД 504071). 39.3.4. Журнал операций № 5 расчет с дебиторами по доходам (ОКУД 504071). 39.3.5. Дебиторская и кредиторская задолженность (ОКУД 0504089). 39.3.6. Сведения о дебиторской и кредиторской задолженности учреждения (ОКУД 0503169). 39.4. Автоматическое формирование информации по бюджетному учету в соответствии с перечисленными выше требованиями должно производиться на уровне СУБД, то есть гарантировано, что соответствующие операции бюджетного учета должны быть произведены корректно даже в том случае, если внесение изменений в соответствующие финансовые операции произведены не штатными средствами Системы. Например, в ходе ручного запуска скрипта на корректировку данных непосредственно в базе данных, при регламентном обслуживании базы данных и в любых других случаях. 39.5. Подсистема бюджетного учета доходов от использования муниципальной собственности должна автоматизировать выполнение следующих основных задач: 39.5.1. Автоматизация формирования бухгалтерских проводок при выполнении финансово-аналитических операций Соответствие Значение характеристики не может изменяться участником закупки 39.5.2. Автоматизация формирования корректирующих проводок при корректировке финансово-аналитической информации «задним числом». Если операция корректировки проводится до сдачи бухгалтерской отчетности за соответствующий период, то выполняется корректировка соответствующих проводок датой проведения аналитической операции, иначе формируются дополнительные корректирующие проводки текущим числом (при изменении суммы аналитической операции в большую сторону выполняется формирование проводки по доначислению, если в меньшую – формируется соответствующая сторнирующая проводка). 39.5.3. Автоматизация работы с документами-основаниями проведения операций бюджетного учета. 39.5.4. Автоматизация формирования журнала операций за период, бухгалтерской справки по исправлениям. 39.5.5. Выгрузка консолидированной информации в электронном виде за период для передачи в бухгалтерские системы. 39.5.6. Индивидуальное «закрытие» периодов по каждому из КБК при сдаче отчетности (блокировка внесения изменений в информацию бюджетного учета «задним числом») Соответствие Значение характеристики не может изменяться участником закупки 40. Требования к подсистеме «Бюджетный учет движения объектов в казне»: 40.1. Подсистема должна применяться для автоматического формирования всей необходимой бухгалтерской информации (проводок)/информации по бюджетному учету, соответствующих выполнению финансово-аналитических операций, проведению и оформлению результатов инвентаризации. Иными словами, подсистема автоматически должна формировать необходимую бухгалтерскую информацию (проводки) в соответствии со всеми требованиями, определенными инструкциями Министерства финансов РФ от 1 декабря 2010 года № 157н, от 6 декабря 2010 года № 162н, от 16 декабря 2010 года № 174н, № 258н от 31 декабря 2016 года, № 209н от 29 ноября 2017 года, федеральными стандартами бухгалтерского учета для организаций муниципального сектора, отслеживая эффективность работы муниципального учреждения. 40.2. Печатные формы и отчеты должны удовлетворять формам бухгалтерской отчетности организаций согласно приказу Министерства Финансов РФ № 66н от 2 июля 2010 года и № 52н от 30 марта 2015 года: 40.2.1. Бухгалтерский отчет 645 «Отчет для движения (Казна, Забаланс)» и запрос-расшифровка к нему 645 «Расшифровка отчета для движения». 40.2.2. Оборотно-сальдовые ведомости по счетам (Счета 104, 108 (в разрезе аналитических счетов), 401, 25, 26). 40.2.3. Журнал операций № 7 по выбытию и перемещению нефинансовых активов (ОКУД 504071). 40.2.4. Сведения о движении нефинансовых активов (ОКУД 0503168). 40.2.5. Инвентаризационная опись основных средств (ОКУД 0317001). Соответствие Значение характеристики не может изменяться участником закупки 37. Средства поиска, отображения и анализа информации: 37.1. Средства поиска, отображения и анализа информации должны быть включены во все экранные формы работы со списками объектов учета, в том числе в экранные формы работы с объектами реестра. 37.2. Средства поиска должны обеспечивать возможности поиска объектов учета по всем характеристикам самих объектов, а также по всем характеристикам связанных объектов учета любого уровня вложенности (например, поиск объектов по параметрам связанных объектов учета, которые связаны со связанными объектами учета. – поиск объектов по параметрам договоров на них и параметрам субъектов этих договоров). 37.3. Для каждой из характеристик должны быть предусмотрены следующие логические условия поиска: 37.3.1. Равно. 37.3.2. Не равно. 37.3.3. Больше. 37.3.4. Меньше. 37.3.5. Больше или равно. 37.3.6. Меньше или равно. 7. Содержит (для текстовых характеристик). 37.3.8. Не содержит (для текстовых характеристик). 37.3.9. Начинается на (для текстовых характеристик). 37.3.10. Не начинается на (для текстовых характеристик). 37.3.11. Заполнено. 37.3.12. Не заполнено. 37.3.13. Отсутствует. 37.4. Для характеристик, имеющих историю изменения, должны быть предусмотрены средства указания даты, на которую выполняется поиск значения характеристики. 37.5. Для сложных или связанных характеристик должны быть предусмотрены возможности поиска по комбинациям значений (например, поиск по коэффициентам подразумевает возможность поиска по произвольной комбинации значений, составляющих информацию по коэффициенту – наименование коэффициента, величина, диапазон дат периода действия коэффициента) Соответствие Значение характеристики не может изменяться участником закупки 37.6. Должен быть предусмотрен поиск по отрицанию условий поиска (объекты, НЕ удовлетворяющие условиям поиска). 37.7. Должна быть предусмотрена возможность комбинации условий поиска – поиск в найденном и новый поиск в дополнение к предыдущему. 37.8. Должна быть предусмотрена возможность сохранение ранее сформированных условий поиска для последующего быстрого использования. 37.9. Для администраторов системы должна быть предусмотрена возможность формирования и отображения SQL-скрипта, соответствующего выборке объектов учета для формирования списка с учетом SQL-выражений, удовлетворяющих сформированным условиям поиска. 37.10. Администратор должен иметь возможность ручной корректировки сформированных SQL-выражений поиска с возможностью выполнения поиска на основе скорректированных SQL-выражений. 37.11. В любой списочной форме (экранной форме отображения списка объектов учета или множественных реквизитов, атрибутов, характеристик объектов учета) должны быть предусмотрены средства контекстного поиска – возможность ввода символов в любой из колонок списка с автоматическим позиционированием курсора в списке на первый объект, соответствующий условиям поиска (вводимым значениям). 37.12. В любой форме отображения списка объектов учета должна быть предусмотрена возможность отображения средств предварительного просмотра. Например, в списке договоров можно отобразить перечень кадастровых номеров земельных участков, арендуемых по текущему договору в списке, или перечень документов-оснований, перечень дополнительных соглашений, развернутую информацию о задолженности по договору Соответствие Значение характеристики не может изменяться участником закупки 17. Требования к подсистеме «Ведение договоров и дополнительных соглашений»: 17.1. Подсистема управления договорами и дополнительными соглашениями должна автоматизировать выполнение всех задач ведения соответствующих договорных отношений и претензий за фактическое использование объектов без заключения договорных отношений. 17.2. Подсистема «Имущество» автоматизирует ведение договоров и других правовых отношений следующих типов: 17.2.1. Договор социального найма жилья (для объектов жилого фонда). 17.2.2. Договор специализированного найма жилья (для объектов жилого фонда). 17.2.3. Договоры на согласовании (при заключении договора балансодержателями имущества). 17.2.4. Договор аренды. 17.2.5. Договор купли/продажи/приватизации. 17.2.6. Договор выкупа с рассрочкой. 17.2.7. Договор безвозмездного пользования объектов движимого имущества. 17.2.8. Договор безвозмездного пользования недвижимого имущества, имущественных комплексов. 17.2.9. Договор мены. 17.2.10. Договор дарения. 17.2.11. Распорядительный документ по праву постоянного бессрочного пользования. 17.3. Подсистема «Земля» автоматизирует ведение договоров и других правовых отношений следующих типов: 17.3.1. Договор аренды. 17.3.2. Соглашение о перераспределении земельных участков. 17.3.3. Договор безвозмездного пользования. 17.3.4. Соглашение о сервитуте (публичном сервитуте) Соответствие Значение характеристики не может изменяться участником закупки 17.3.5. Разрешения на использование земельного участка без его предоставления и установления сервитута. 17.3.6. Претензия за фактическое использование участка без заключения договора (расчеты в соответствии с требованиями Гражданского кодекса РФ). 17.4. Подсистема управления договорами и дополнительными соглашениями должна автоматизировать решение следующих основных задач: 17.4.1. Учет всех условий договоров и дополнительных соглашений. По каждому договору и доп. соглашению ведется следующая основная информация: 17.4.1.1. Номер и дата договора, доп. соглашения, номер и дата регистрации. 17.4.1.2. Код бюджетной классификации. 17.4.1.3. Тип использования, целевое использование. 17.4.1.4. Дата начала фактического использования объекта договора (для определения периода фактического использования). 17.4.1.5. Дата начала действия, планируемого и фактического окончания (расторжения), дата фактического освобождения объекта (для определения периода фактического использования объекта после расторжения договора). 17.4.1.6. Особые условия, ограничения. 17.4.1.7. Документы-основания, документы на льготы, другие документы. 17.4.1.8. Комиссии. 17.4.1.9. Объекты договора (может быть несколько объектов в договоре) – с возможностью указания периода нахождения объекта или его доли в договоре, доли объектов учета по договору – с историей изменения величины доли. 17.4.1.10. Формула (алгоритм) расчета планируемой платы по договору (индивидуально для каждого объекта или доли объекта в договоре) – с историей изменения. 17.4.1.11. Коэффициенты, ставки, индивидуальные показатели, другие характеристики, участвующие в автоматическом расчете планируемой арендной платы (индивидуально по каждому объекту в договоре) – с историей изменения Соответствие Значение характеристики не может изменяться участником закупки 37.13. Средства предварительного просмотра должны представлять собой печатные формы, сформированные с использованием генератора отчетов, и отображающие всю необходимую информацию по текущему объекту учета в списке без выполнения дополнительных действий со стороны пользователя. Для каждого типа объектов учета может быть настроено произвольное количество форм предварительного просмотра с возможностью выбора текущей отображаемой формы из списка доступных форм. 37.14. Средства предварительного просмотра должны обладать всеми возможностями печатных форм, включая возможность открытия карточки объекта учета путем двойного клика по информации по нему в окне предварительного просмотра (например, открытие карточки земельного участка из окна предварительного просмотра договоров, отображающего перечень земельных участков по текущему договору). 37.15. Аналитические средства элементов работы со списками объектов учета 37.15.1. Группировка данных по одному или нескольким столбцам. Например, реестр может быть сгруппирован по состоянию объектов учета, району области, разрешенному использованию. 37.15.2. Вычисление общих итогов, в том числе для каждой из групп (в случае применения группировки). Например, для приведенного примера возможна автоматическая калькуляция общей планируемой платы, площади объектов, величины задолженности в разрезе состояний договоров аренды, района расположения объекта договора, целевого использования; 37.15.3. Дополнительная оперативная фильтрация данных по значениям любого столбца\совокупности столбцов; 37.15.4. Сортировка данных по произвольному столбцу\совокупности столбцов. 5. Возможность выбора отображаемых столбцов. 37.15.6. Автоматическое сохранение настроек табличного представления для каждого типа объектов учета. 37.16. Должна быть предусмотрена возможность экспорта сформированных данных в форматы табличные форматы (xlsx, csv), текстового файла или внутренние форматы генератора отчетов. Соответствие Значение характеристики не может изменяться участником закупки 37.17. В Системе должна быть реализована возможность автоматического предварительного просмотра документа непосредственно в табличной форме реестра любого типа объектов. При переходе от одного к другому объекту в списке, форма предварительного просмотра должна обновляться автоматически. 37.18. Должна быть реализована возможность отключать данный режим, настраивать форму просмотра, выбирая нужный шаблон документа, из списка доступных для данного режима, шаблонов. Должна быть возможность создавать и редактировать шаблоны документов для данного режима наряду с любыми другими шаблонами документов Соответствие Значение характеристики не может изменяться участником закупки 15. Требования к подсистеме Подсистема «Ведение информации по акциям»: 15.1. В Системе должна быть возможность ведения информации об акциях (долях), находящихся в собственности муниципального образования. 15.2. В рамках подсистемы помимо стандартных атрибутов должна быть предусмотрена возможность ведения следующей информации: 15.2.1. Субъекты акций (сведения об эмитенте, совете директоров, ревизионных комиссиях). 15.2.2. Субъекты долей (сведения об обществе, совете директоров, ревизионных комиссиях). 15.2.3. Заседания совета директоров и общего собрания акционеров (участников), включая возможность фиксации решения собрания, загрузки протоколов. 15.2.4. Информация о стоимостях акций (долей) и количестве акций (в разрезах видов акций). 15.2.5. Сведения о собраниях советов директоров и ревизионных комиссий (включая состав совета, протокол). 15.2.6. Бюджетный учет акций (долей) в казне. 15.2.7. Сведения об эмитенте (обществе), а также возможность перехода в реестр договоров для получения информации о долговых обязательствах с расшифровкой по каждому кредитору, реквизитами заключенных договоров, существенными условиями по каждому договору, основному долгу и процентам Соответствие Значение характеристики не может изменяться участником закупки 16. Требования к подсистеме «Адресная подсистема»: 16.1. «Адресная подсистема» (средства формирования адресов объектов для реестровой подсистемы учета) должна обеспечивать возможность формирования и учета произвольного количества адресов для каждого объекта учета. 16.2. Для каждого из адресов должна быть предусмотрена возможность указания типа адреса на основе расширяемого классификатора (присвоенный адрес – официальный, юридический адрес, предыдущий адрес (при наличии) и адресного ориентира (местоположение объекта учета). 16.3. Присвоенный адрес – официальный, должен быть один. 16.4. «Адресная подсистема» должна обеспечивать возможность указания адресных реквизитов, утвержденных, постановлением Правительства РФ от 19.11.2014 № 1221 как с использованием собственных справочников и классификаторов присвоенных адресов или установленных ранее, включая адресный ориентир, так и с использованием базы федеральной информационной адресной системы (ФИАС). 16.5. «Адресная подсистема» должна обеспечивать возможность настройки шаблона вывода адреса (формирования строки адреса) для каждого из типов объектов учета (наименований реестров объектов учета). Шаблон должен обеспечивать возможность указания адресных реквизитов в соответствии с требованиями к структуре адреса, например, , , , , или , , , и т.п. 16.6. Строка адреса обязательно отображается в карточке объекта учета и в списке объектов учета соответствующего типа. 16.7. «Адресная подсистема» должна обеспечивать возможность ввода адреса любых объектов учета, включая адреса комнат, офисов, территорий и т.д. Должна быть предусмотрена возможность указания адресного ориентира. 16.8. «Адресная подсистема» должна обеспечивать возможность ввода адреса следующей структуры: 16.8.1. Наименование страны (Российская Федерация) – выбирается из справочника. 16.8.2. Наименование субъекта Российской Федерации – выбирается из справочника. Соответствие Значение характеристики не может изменяться участником закупки 17.4.1.12. Субъекты договора (с историей изменения, периодами действия для переуступки, субаренды, доверенности, ссылками на документы-основания). 17.4.1.13. Информация по субаренде с привязкой к объектам субаренды и характеристикам, коэффициентам, влияющим на расчет суммы планируемой арендной платы на субарендуемые площади (индивидуально для каждого субарендатора и субъекта субаренды) – с периодами действия. 17.4.1.14. Информация по планируемой плате по договору (с полной историей изменения) 17.4.1.15. Схема начисления в соответствии с условиями договора с историей изменения. 17.4.1.16. Индивидуальные ставки пени – с историей изменения и ссылками на документы-основаниями, а также возможностью индивидуальной настройки количества знаков после запятой для расчетов пени, а также возможности начисления процентов вместо пени. 17.4.1.17. Индивидуальные ставки процентов за пользование чужими денежными средствами – с историей изменения и ссылками на документы-основаниями, а также возможностью индивидуальной настройки количества знаков после запятой для расчетов процентов, а также возможности начисления пени вместо процентов. 17.4.2. Управление дополнительными соглашениями, изменениями условий договора по дополнительным соглашениям. 17.4.3. Управление договорами с множественностью лиц. 17.4.4. Управление договорами с множественностью объектов. 17.4.5. Переоформление, продление договоров. 17.4.6. Автоматизация процесса переуступки права по договору. 17.4.7. Переоформление договоров аренды земельных участков при разграничении собственности на объекты аренды. 17.4.8. Автоматизированный расчет суммы планируемой платы, платы за выкуп с учетом всех особых условий договора Соответствие Значение характеристики не может изменяться участником закупки 17.4.9. Автоматизация расчета суммы планируемой платы по договору с учетом истории изменения расчетных величин, изменения условий договора по доп. соглашениям, учета различных особых условий (в том числе различные виды льгот, субаренда, долевая аренда/выкуп, аренда/выкуп с разными типами использования объектов договора, автоматическим поднятием до установленных минимумов). 17.4.10. Автоматизация подготовки необходимых печатных форм (в том числе текстов договора, доп. Соглашения, проектов постановлений, распоряжений, приказов). 17.4.11. Формирование аналитики по задолженности, работа с должниками. 17.4.12. Автоматизация претензионной и исковой деятельности. 17.4.13. Формирование аналитической отчетности в соответствующей сфере. 17.4.14. Проведение экспресс-аналитики и др. 17.5. Индивидуальные ставки пени и процентов: 17.5.1. В Системе должна быть предусмотрена возможность ведения индивидуальных ставок пени для каждого договора с указанием периода действия индивидуальной ставки, а также документа-основания. 17.5.2. Средства настройки индивидуальной ставки пени должны предусматривать возможность дополнительной настройки следующих параметров: 17.5.2.1. Возможность указания конкретной величины ставки (в процентах или абсолютных единицах) или указание на ставку со значениями, задаваемыми справочником (например, ставка рефинансирования, ключевая ставка, среднебанковская ставка для вкладов физических лиц). 17.5.2.2. Доля ставки (знаменатель при указании ставки в виде простой дроби). 17.5.2.3. Количество знаков после запятой при расчете величины ставки в абсолютных единицах (по умолчанию – максимально возможное). 17.5.2.4. Признак необходимости расчета пени по методике равного количества дней в месяце (30 дней в месяце, 360 дней в году). 17.5.2.5. Признак необходимости расчета процентов за пользование чужими денежными средствами вместо пени Соответствие Значение характеристики не может изменяться участником закупки 40.3. Автоматическое формирование информации по бюджетному учету в соответствии с перечисленными выше требованиями должно производиться на уровне СУБД, то есть должно быть гарантировано, что соответствующие операции бюджетного учета должны быть произведены корректно даже в том случае, если внесение изменений в соответствующие финансовые операции произведены не штатными средствами Системы. Например, в ходе ручного запуска скрипта на корректировку данных непосредственно в базе данных, при регламентном обслуживании базы данных и в любых других случаях. 40.4. Подсистема бюджетного учета движения объектов в казне должны автоматизировать выполнение следующих основных задач: 40.4.1. Автоматизация формирования бухгалтерских проводок (балансовый и забалансовый учет) при включении/исключении объектов в казне. Проводки формируются на основе данных о балансовой и остаточной стоимостях объектов (кадастровой стоимости в случае земельных участков). Должна быть предусмотрена возможность в качестве балансовой и остаточной стоимости указывать другие виды стоимости (инвентарная, восстановительная, оценочная). 40.4.2. Автоматизация формирования корректирующих проводок при корректировке информации по стоимостям объектов в казне «задним числом». Корректировка проводится по тем же правилам, что и в случае бюджетного учета доходов. 40.4.3. Автоматизация работы с документами-основаниями проведения операций бюджетного учета движения объектов в казне. 40.4.4. Автоматизация формирования журнала операций за период, бухгалтерской справки по исправлениям. 40.4.5. Выгрузка консолидированной информации в электронном виде за период для последующей передачи в бухгалтерские системы. 40.4.6. Формирование количественной и финансовой информации по движению объектов в казне за период. 40.4.7. Формирование другой аналитической отчетности. 40.4.8. Для малоценного движимого имущества должна быть предусмотрена возможность ведения учета: Соответствие Значение характеристики не может изменяться участником закупки 40.4.8.1. Ведение всего пакета движимого имущества в казне и на балансе консолидировано единой суммой соответствующих активов. 40.4.8.2. Ведение движимого имущества пакетами одноименных объектов с указанием их количества и стоимостных характеристик единицы (например, наименование – стол, количество – 50, балансовая стоимость единицы 1000 рублей, балансовая стоимость общая 50 000 рублей). 40.4.8.3. Ведение малоценного движимого имущества пообъектно с возможностью указания (присвоения) реестровых и/или инвентарных номеров. 40.5. Бюджетный учет движения малоценного движимого имущества должен осуществляться в соответствии с требованиями, предъявляемыми к бюджетному учету имущества, вне зависимости от используемой технологии учета. 40.6. Должны быть предусмотрены средства автоматизации бюджетного учета акций в казне в соответствии с требованиями, предъявляемыми к бюджетному учету акций Соответствие Значение характеристики не может изменяться участником закупки 17.5.2.6. Признак «плавающей» ставки пени в периоде расчета («Плавающая» или фиксированная на день исполнения денежных обязательств или их части). 17.5.3. В периоде действия индивидуальных ставок пени расчет пени по договору должен производиться по общей методике, в противном случае – по технологии, определенной по умолчанию для данного вида договора и/или схеме начисления. 17.5.4. Аналогично должна быть реализована возможность для ведения индивидуальных ставок процентов за пользование чужими денежными средствами. 17.5.5. По умолчанию должна применяться методика, соответствующая 395 статье Гражданского кодекса РФ (с учетом всех редакций данной статьи, распространяющих действия до следующего внесения изменений в статью). 17.5.6. Средства настройки индивидуальной ставки процентов должны предусматривать возможность дополнительной настройки следующих параметров: 17.5.6.1. Возможность указания конкретной величины ставки (в процентах или абсолютных единицах) или указание на ставку со значениями, задаваемыми справочником (например, ставка рефинансирования, ключевая ставка, среднебанковская ставка для вкладов физических лиц); 17.5.6.2. Доля ставки (знаменатель при указании ставки в виде простой дроби); 17.5.6.3. Количество знаков после запятой при расчете величины ставки в абсолютных единицах (по умолчанию – максимально возможное). 17.5.6.4. Признак необходимости расчета пени по методике равного количества дней в месяце (30 дней в месяце, 360 дней в году). 17.5.6.5. Признак необходимости расчета пени вместо процентов за пользование чужими денежными средствами. 17.5.6.6. Признак «плавающей» ставки процентов в периоде расчета («Плавающая» или фиксированная на день исполнения денежных обязательств или их части). 17.5.7. В периоде действия индивидуальных ставок пени расчет пени по договору должен производиться по общей методике, в противном случае – по технологии, определенной по умолчанию для данного вида договора и/или схеме начисления Соответствие Значение характеристики не может изменяться участником закупки 18. Требования к подсистеме «Выкуп с рассрочкой»: 18.1. Подсистема «Выкуп с рассрочкой» необходима для ведения учета договоров выкупа с рассрочкой согласно Федерального закона «Об особенностях отчуждения недвижимого имущества, находящегося в муниципальной собственности субъектов Российской Федерации или в муниципальной собственности и арендуемого субъектами малого и среднего предпринимательства, и о внесении изменений в отдельные законодательные акты Российской Федерации» от 22.07.2008 N 159ФЗ (с изменениями от 08.06.2020). 18.2. Данная подсистема должна включать в себя как весь функционал подсистемы «Подсистема ведения договоров и дополнительных соглашений», так и специфические особенности учета договоров выкупа с рассрочкой: 18.2.1. Подсистема должна иметь возможность настройки графика платежей. Для этого необходимо указать цену выкупа объекта, количество месяцев рассрочки, сумму и дату первого взноса. После проведения настройки должна иметься возможность формирования первоначального графика платежей. Должна иметься возможность смещать график платежей на любое количество периодов (как в будущее, так и в прошлое, как первый, так и последующие календарные периоды). Ставка рефинансирования (ключевая ставка) должна определяться автоматически на дату подписания договора, при расчете начисления процентов данная ставка делится на 3. Начисления основного долга и процентов должны соответствовать дифференцированной схеме (не аннуитет). 18.2.2. При распределении платежей на договор в первую очередь должна погашаться задолженность по процентам, а оставшаяся сумма платежа покрывает задолженность по основному долгу. Данные суммы вычисляются системой автоматически. При этом после каждого распределения платежей сумма последующих начислений процентов пересчитывается автоматически. 18.2.3. Должны иметься гибкие возможности настройки данной подсистемы, в том числе: 18.2.3.1. Начисление должны производиться одной суммой или с разбивкой на основной платеж и проценты. Соответствие Значение характеристики не может изменяться участником закупки 18.2.3.2. Начисление пени должны производиться только на основной платеж или как на основной платеж, так и на проценты. 18.2.3.3. Ставку рефинансирования и график начисления платежей должна иметься возможность учитывать с даты начала договора, даты подписания договора, даты публикации договора, даты договора, с указанием конкретной даты вручную. 18.2.3.4. Начисление процентов производить на первоначальный взнос или не производить. 18.2.3.5. Платеж в первую очередь должен погашать пеню, потом процент, потом основной долг (либо в первую очередь на процент, а оставшуюся сумма платежа – на основной долг) Соответствие Значение характеристики не может изменяться участником закупки 16.8.3. Наименование муниципального района, городского округа или внутригородской территории (для городов федерального значения) в составе субъекта Российской Федерации – выбирается из справочника. 16.8.4. Наименование городского или сельского поселения в составе муниципального района (для муниципального района) или внутригородского района городского округа – выбирается из справочника. 16.8.5. Наименование населенного пункта – выбирается из справочника. 16.8.6. Наименование элемента планировочной структуры – выбирается из справочника. 16.8.7. Наименование элемента улично-дорожной сети – выбирается из справочника присвоенных наименований элементам УДС. 16.8.8. Номер земельного участка. 16.8.9. Тип и номер здания, сооружения или объекта незавершенного строительства. 16.8.10. Тип и номер помещения, расположенного в здании или сооружении. 16.9. Перечень элементов планировочной структуры (справочник), элементов улично-дорожной сети (справочник), элементов объектов адресации, типов зданий (сооружений) и помещений, используемых в качестве реквизитов адреса (справочники), а также правила сокращенного наименования адресообразующих элементов устанавливаются Министерством финансов Российской Федерации. 16.10. Для зависимых справочников должна быть предусмотрена возможность автоматической подфильтровки допустимых для выбора элементов при заполнении элементов вышестоящих классификаторов, от которых зависят данные. 16.11.Если значения вышестоящих классификаторов не заданы, то при выборе элемента некоторого зависимого справочника элементы вышестоящих справочников должны заполниться (выбраться автоматически). 16.12. Особенности работы адресной подсистемы при использовании ФИАС: 16.12.1. При использовании сведений об адресе из ФИАС ввод или изменение адреса объекта учета должно производиться в отдельной строке экранной формы объекта учета с обязательным внесением уникального номера адреса объекта адресации из государственного адресного реестра Соответствие Значение характеристики не может изменяться участником закупки 16.12.2. Структура базы данных для хранения данных ФИАС должна полностью соответствовать структуре данных ФИАС. 16.12.3. Элементы ФИАС должны быть расположены в отдельной базе данных Системы, для которой должен быть предоставлен отдельный режим обслуживания и резервного копирования. 16.12.4. В адресной подсистеме должен быть предусмотрен режим обновления во всех подсистемах Системы адресообразующих элементов, включая уникальный номер адреса объекта адресации в государственном адресном реестре базы данных ФИАС Соответствие Значение характеристики не может изменяться участником закупки 21.9. Средства подсистемы должны предоставлять возможность не только для проведения оперативных выборок, но и для выполнения запросов по индивидуальному или массовому изменению, добавлению, удалению информации в банке данных системы, например, в ходе обслуживания информационного фонда. Соответствие Значение характеристики не может изменяться участником закупки 30. Требования к элементам формы карточки объектов: 30.1. Средства работы с атрибутами каждого из доступных типов данных по умолчанию должны содержаться в экранных контейнерах (панелях экранной формы), контейнеры должны быть размещены на вкладках экранной формы. 30.2. Экранные контейнеры должны представлять собой панели прямоугольной формы, на которой размещаются элементы управления (просмотра, редактирования) атрибутами объектов учета. 30.3. Для экранных контейнеров должна быть предусмотрена возможность выполнения следующих действий: 30.3.1. Изменение размеров контейнера (высота, ширина). 30.3.2. Перемещение контейнера по экранной форме, включая перемещение контейнера на другие вкладки (на свободное место экранной формы (не занятое другими элементами управления) имеющем размеры, достаточные для вмещения контейнера). 30.4. Должна быть предусмотрена возможность для каждого типа объектов учета создания произвольного количества контейнеров с размещением в них произвольного количества логически связанных атрибутов любых типов единым списком. Для каждого атрибута, размещаемого в создаваемом контейнере, должна быть предусмотрена возможность указания признака автоматического добавления атрибута в карточку объекта учета и порядкового номера по умолчанию отображения автоматически добавленных атрибутов в контейнере. Автоматически добавляемые атрибуты должны добавляться в контейнер автоматически с последующим возможным указанием пользователем их значения. Должна быть предусмотрена возможность визуальной индикации в контейнере атрибутов, добавленных автоматически, но значение которых пользователем еще не введены (по факту такие атрибуты для объекта учета еще не определены). 30.5. Для экранной формы должны быть предусмотрены следующие возможности по работе с вкладками: 30.5.1. Добавление вкладок. 30.5.2. Изменение наименований вкладок. 30.5.3. Изменение порядка следования вкладок. 30.5.4. Удаление вкладок, не содержащих элементов управления или контейнеров Соответствие Значение характеристики не может изменяться участником закупки 31. Требования к меню доступа к объектам учета и работы со списками: 31.1. Система должна содержать в своем составе средства настройки иерархического меню доступа к объектам учета всех типов с учетом возможностей по добавлению новых объектов учета. 31.2. Доступ к меню доступа к объектам учета должен предоставляться из основного окна Системы. 31.3. Доступ к каждому пункту меню должен осуществляться за минимальное количество действий пользователя. При возобновлении сеанса работы с Системой (повторном запуске Системы) позиция текущего пункта меню в иерархическом меню должна быть восстановлена автоматически, то есть доступ к объектам учета соответствующего типа должен осуществляться путем использования одного клика мыши. 31.4. Иерархическое меню должно иметь элементы следующих типов: 31.4.1. Промежуточные узлы – нажатие на этот пункт меню должно раскрывать следующий уровень иерархии (отображать вложенные пункты меню). 31.4.2. Промежуточные узлы-реестры – нажатие на данный пункт меню должен открыть объединенный список объектов учета, соответствующий совокупности объектов учета всех конечных элементов меню, вложенных с учетом иерархии в данный пункт (узел). Для данного типа пункта меню должна быть возможность открытия вложенных пунктов меню без открытия объединенного реестра. 31.4.3. Конечный узел – открывает список объектов учета, соответствующий данному пункту меню. 31.4.4. Конечный узел объединенного реестра – открывает объединенный список объектов учета, соответствующий конечным узлам пунктов меню, находящихся на этом же уровне иерархии (имеющих единый промежуточный узел). 31.5. В иерархическом меню должна быть предусмотрена возможность добавления пунктов, для которых может быть указан дополнительный фильтр, который автоматически применяется при отображении списка объектов, отображаемых с помощью данного пункта меню Соответствие Значение характеристики не может изменяться участником закупки 19. «Финансово-аналитическая подсистема»: 19.1. «Финансово-аналитическая подсистема» является ключевой с точки зрения определения и повышения эффективности неналоговых поступлений от использования муниципальной собственности. 19.2. Подсистема должна обеспечивать широкие возможности точной настройки на все нюансы федерального, регионального и местного законодательства, особенностей технологии управления имущественно-земельным комплексом, принятым в соответствующих органах управления собственностью и земельными ресурсами региона. 19.3. «Финансово-аналитическая подсистема» должна обеспечивать автоматизацию выполнения следующих основных задач: 19.3.1. Управление финансово-аналитической информацией (начислениями всех типов, платежами, задолженностью) в разрезах договоров, кодов бюджетной классификации (аналитических уровней), видов договоров, субъектов. 19.3.2. Автоматическое формирование начислений по договору возмездного и безвозмездного пользования, платы за фактическое использование, льготной арендной платы, платы за выкуп. Система автоматически должна определять, какой из видов начисления необходимо произвести в соответствии с условиями договорных соглашений (с учетом всех доп. соглашений и других корректировок), норм Гражданского Кодекса, в тех периодах использования объектов, которые не регулируются договором (в том числе фактическое использование объектов без договора, до заключения договора, в периоде до регистрации договора, после расторжения договора до даты освобождения объекта). 19.3.3. Автоматическое начисление пени, процентов, других штрафных санкций за пользование чужими денежными средствами. Система автоматически должна определять вид начисления (штрафных санкций) исходя из условий договора или руководствуясь нормами гражданского Кодекса в периоде фактического использования объекта. 19.3.4. Автоматическое доначисление по доп. соглашениям, изменяющим условия договора «задним числом». 19.3.5. Автоматический расчет сальдо Соответствие Значение характеристики не может изменяться участником закупки 19.3.6. Автоматический перерасчет планируемой платы по договору (например, в ходе массовой индексации по уровню инфляции). 19.3.7. Импорт платежей из электронных источников (выгрузка из ЭБ и др.). 19.3.8. Автоматическое, полуавтоматическое и ручное распределение и перераспределение поступлений по субъектам договоров, договорам, видам начислений. 19.3.9. Формирование информации о задолженности в любом разрезе и на произвольную дату. 19.3.10. Формирование информации о динамике возникновения задолженности. 19.3.11. Управление начислениями по решению суда, автоматизация работы с реструктуризацией задолженности. 19.3.12. Ведение протоколов выполнения автоматических операций, возможности по эвристическому анализу информационного фонда на предмет корректности исходной информации для выполнения автоматических операций. 19.3.13. Автоматизация работы с должниками. 19.3.14. Формирование необходимых печатных форм (в том числе справки о наличии/отсутствии задолженности, формирование претензий, исковых требований, детализации всех видов начислений для суда, формирование актов сверки) Соответствие Значение характеристики не может изменяться участником закупки 20. Требования к подсистеме «Автоматизация претензионной и исковой деятельности»: 20.1. Подсистема должна автоматизировать выполнение следующих основных задач: 20.1.1. Ведение полной информации по претензиям и исковым процессам, по требованиям, предъявленным к пользователям Системы и по имуществу пользователям Системы: 20.1.1.1. Договор или иной документ, на основании которого ведется претензионно-исковая деятельность. 20.1.1.2. Претензия, иск стороны для требований, предъявленных к пользователям Системы по имуществу. 20.1.1.3. Субъект (заявитель) претензии. 20.1.1.4. Объект. 20.1.1.5. Предмет претензионно-исковых требований: 20.1.1.5.1. требования имущественного характера (сумма к взысканию по различным видам начислений); 20.1.1.5.2. требований имущественного характера, не подлежащего оценке; 20.1.1.5.3. требования неимущественного характера. 20.1.2. Возможность формировать печатные формы претензий и исковых заявлений автоматически на основе данных из учетной системы. 20.1.3. Стороны (участники) иска, категория (вид) иска, признак особой важности. 20.1.4. Состояние иска (подготовка, в процессе, завершен). 20.1.5. Учет судебных дел и претензионно-исковых этапов: претензия, подготовка иска, подача иска, наименование суда, номер судебного дела, судья, инстанция (апелляция, кассация, в порядке надзора), дата и время судебного заседания, сотрудник правового отдела – исполнитель, судебные акты по делу (решения, определения о приостановлении производства по делу, об оставлении иска без рассмотрения, об оставлении иска без движения, о возвращении искового заявления, о прекращении производства по делу, о принятии к производству встречного иска, о принятии (отмене) мер по обеспечению иска). 20.1.6. Учет исполнительного производства: дата вступления судебного акта в законную силу, дата получения исполнительного листа, дата направления исполнительного листа в отдел судебных приставов, отдел судебных приставов, судебный пристав исполнитель, постановления пристава исполнителя. Соответствие Значение характеристики не может изменяться участником закупки 20.1.7. Учет конкурсного производства: суд, номер дела, дата введения процедур в отношении предприятия банкрота (определения суда), сведения о ходе процедур банкротства. 20.1.8. Возможность формирования отчета о сроках (длительности) претензионной работы, подготовки и подачи иска, рассмотрения дела в суде, исполнительного производства, конкурсного производства. 20.1.9. Возможность поиска судебных дел по различным критериям. 20.1.10. Наличие ссылки на страницу дела на сайте kad.arbitr.ru. 20.1.11. Возможность прикрепления файлов материалов к судебному делу (претензий, исков, судебных актов), к исполнительному производству (исполнительный лист, заявление о направлении исполнительного листа, постановления приставов-исполнителей), к конкурсному производству (судебные акты дела о банкротстве, извещения о проведении собраний кредиторов). 20.1.12. Контроль за ходом иска в разрезе исполнителя, уведомление исполнителя о необходимости завершения текущего искового этапа и перехода к следующему. 20.1.13. Предусмотреть экспорт данных в табличный формат (xlsx, csv). Возможность формирования необходимых печатных форм (с использованием встроенных генераторов отчетов). 20.1.14. Предусмотреть разграничение прав доступа. 20.1.15. Постановка и контроль исполнения задач/поручений сотрудниками правового отдела. 20.1.16. Протоколирование результатов расчета пени на расчетную дату. 20.1.17. Протоколирование результатов расчета задолженности по всем видам операций на расчетную дату, для возможности отслеживания изменений и анализа их причин Соответствие Значение характеристики не может изменяться участником закупки 32. Режим добавления объекта по шаблону: 32.1. В Системе должна быть предусмотрена возможность добавления объекта по шаблону на основе любого выбранного пользователем объекта, информация о котором уже содержится в единой базе данных Системы. 32.2. В режиме добавления объекта по шаблону должна создаваться карточка нового объекта соответствующего типа (как у объекта, на основе которого производится добавление) с полным копированием информации из исходного объекта в карточку добавляемого объекта, за исключением информации, идентифицирующей объект (реестровый номер, инвентарный номер, паспортные данные, ПТС транспортного средства) Соответствие Значение характеристики не может изменяться участником закупки 33. Требования к созданию нового типа (наименования списка, реестра) объекта учета 33.1. Средствами подсистемы должна быть обеспечена возможность создания реестров (списков) объектов двух основных видов: 33.1.1. Новый реестр/список объектов произвольной структуры, состава информации, атрибутов, характеристик. 33.1.2. Реестр/список объектов, являющихся частью одного или нескольких реестров объектов имущественно-земельного комплекса. Для объектов данного типа должна быть обеспечена возможность выбора одного или нескольких типов объектов (схожих по структуре данных), на основе которых формируется данный список объектов учета, а также возможность задания произвольного условия (без каких-либо ограничений по сложности условия), по которому осуществляется фильтрация объектов учета. 33.2. Должна быть предусмотрена возможность создания собственной электронной карточки объекта учета данного реестра, отличной от электронной карточки этого же объекта учета основного реестра. Однако, если в электронной карточке объекта в создаваемом реестре объектов учета присутствуют реквизиты, заполненные в карточке этого же объекта в основном реестре (реестре имущественно-земельного комплекса), то они должны отображаться в электронной карточке объекта учета данного реестра. Иными словами, должна быть обеспечена возможность собственного дизайна электронных карточек объектов учета отдельно для каждого создаваемого пункта меню (пункта меню доступа к создаваемому списку, реестру объектов учета). Электронная карточка должна создаваться адаптированной к эффективному решению именно той задачи, для которой создавался список соответствующих объектов Соответствие Значение характеристики не может изменяться участником закупки 19.3.15. Формирование необходимой аналитической отчетности. 19.3.16. Организация массовой рассылки уведомлений о необходимости погашения задолженности, об изменении условий договора, величины планируемой платы по договору. 19.3.17. Проведение экспресс-аналитики. 19.4. Помимо стандартных функций по управлению финансово-аналитической информацией, в подсистему должен быть включен ряд функций и возможностей, направленных на дополнительное расширение возможностей подсистемы как в части расширения функционала, так и в части настройки технологии учета под особенности внутреннего регламента по управлению финансово-аналитической информацией, технологии учета, особенности местного и регионального законодательства. 19.5. Настройка уровня аналитического учета: 19.5.1. В Системе должна быть предусмотрена возможность индивидуальной настройки уровня аналитического учета платежей и начислений за аренду этих объектов. 19.5.1.1. Учет платежей и начислений должен вестись как в разрезе субъектов договоров (арендаторы), плательщиков (оплата 3-ми лицами), так и по договорам (аренда, выкуп, неосновательное обогащение, учет и т.д.). Платежи распределяются как по субъектам договоров (арендаторы), так и по договорам (аренда, выкуп, неосновательное обогащение, учет и т.д.). Пени и другие штрафные санкции и сальдо рассчитываются также в разрезе субъектов и по договорам аренды. Возможно применение смешанной технологии учета, в которой основная технология выбрана в разрезе субъектов договоров (арендаторы), но для части договоров учет ведется в разрезе договоров. 19.5.1.2. Возможно ведение технологии учета в разрезе КБК (кодов бюджетной классификации). При таком ведении учета пени и сальдо рассчитываются индивидуально для каждого кода бюджетной классификации. Данный аналитический уровень может быть применен как при ведении учета в разрезе арендаторов, так и при ведении учета в разрезе договоров. 19.5.1.3. Ведение библиотеки алгоритмов выполнения автоматических операций Соответствие Значение характеристики не может изменяться участником закупки 19.5.1.4. Ведение библиотеки схем начисления арендной платы и сроков оплаты. 19.5.1.5. Библиотека схем начисления должна предоставлять следующие возможности: 19.5.1.6. Создание произвольного количества схем начисления. Под схемой начисления подразумевается алгоритм выполнения начисления, периодичностью (квартал, месяц, полугодие, набор месяцев) и сроки начисления. 19.5.1.7. Возможность создания и настройки произвольного количества периодичностей начисления (например, помесячное начисление, поквартальное, 2 раза в год для сельхоз. земель, 2 раза в год для других земель). При этом для каждой периодичности может быть указано произвольное количество периодов произвольной длительности. Для каждого периода индивидуальное указание произвольного срока оплаты. 19.5.1.8. Для каждого договора аренды указание индивидуальной схемы начисления из библиотеки (схема по умолчанию также должна настраиваться). 19.6. Расширение функциональных и аналитических возможностей блока: 19.6.1. В Системе должна быть реализована функция определения задолженности в любом разрезе. При этом функция должна рассчитать задолженность по состоянию на любую заданную дату как по базе целиком, так и по любому из перечисленных аналитических уровней (или их произвольному сочетанию): Соответствие Значение характеристики не может изменяться участником закупки 21. Требования к аналитической и сервисной подсистеме «Библиотека запросов»: 21.1. Средства подсистемы должны предоставлять возможность для проведения оперативных выборок и для выполнения запросов по индивидуальному или массовому изменению, добавлению, удалению информации в банке данных Системы, например, в ходе обслуживания информационного фонда. 21.2.Подсистема должна предоставлять средства оперативного построения, накопления и выполнения запросов произвольной сложности и произвольного содержания к единому информационному фонду Системы. Средства подсистемы должны быть максимально интуитивны и просты в использовании, выполнение запросов не требует каких-либо специальных знаний и навыков от пользователей. 21.3. Количество запросов, которые могут быть добавлены в подсистему, должно быть не ограничено. Добавление запросов в подсистему должно выполняться средствами подсистемы, не требовать обновления Системы или ее компонентов, привлечения разработчиков Системы. 21.4. Запросы могут содержать произвольное количество параметров любых типов (даты, числа, строки, данные из любых справочников и классификаторов Системы), фактические значения которых указываются пользователем в момент выполнения выбранного запроса, что в значительной степени повышает оперативность и точность получения данных в результате выполнения запроса. 21.5. Должна быть предусмотрена возможность непосредственно из результатов выполнения запроса открыть электронную карточку объекта, по которому содержится информация в соответствующей строчке результатов выполнения запроса. 21.6. Подсистема должна предоставлять возможность дополнительного постанализа данных (анализ после получения результата выполнения запроса в табличном виде), полученных в результате выполнения запроса: Соответствие Значение характеристики не может изменяться участником закупки 21.6.1. Группировка данных по одному или нескольким полям, что в значительной степени может повысить информативность полученных данных. Например, данные по должникам можно сгруппировать по району плательщика, кодам бюджетной классификации и видам начислений. 21.6.2. Вычисление общих итогов, в том числе для каждой из групп (в случае применения группировки). Например, для приведенного примера возможна автоматическая калькуляция общей задолженности арендаторов, а также задолженности по каждому из районов, коду бюджетной классификации и виду начисления. 21.6.3. Дополнительная оперативная фильтрация данных по значениям любого поля\совокупности полей. 21.6.4. Сортировка данных по произвольному полю\совокупности полей. Должна быть предусмотрена возможность экспорта сформированных данных в табличные форматы (xlsx, csv), текстового файла, xml или внутренние форматы генератора отчетов. При этом должна быть обеспечена возможность экспорта данных, в том чисел в формат xml сложной структуры с учетом всех сортировок, группировок, итогов и прочего форматирования, которые были наложены на результат запроса в окне результата запроса. 21.7. В случае содержания в результатах запроса сведений об объектах учета единого банка данных Системы должен быть реализован быстрый доступ (двойной «щелчок мыши») к карточкам соответствующих объектов учета. 21.8. Средства подсистемы должны предоставлять возможность администратору Системы мониторинга состояния информационного фонда Системы, анализа целостности, непротиворечивости данных, регулярного обслуживания банка данных. Соответствие Значение характеристики не может изменяться участником закупки 34. Требования к созданию формы работы со списком объектов учета соответствующего типа: 34.1. Для списков работы с объектами учета новых типов (не объектов имущественно-земельного комплекса, описанных выше) должна быть предусмотрена возможность создания формы работы со списком (реестром) объектов, содержащих произвольное количество полей (колонок, столбцов) произвольной структуры без ограничений на сложность формирования данных, размещаемых в соответствующих полях (колонках, столбцах) списка объектов учета. В том числе, в полях списка могут размещаться произвольные данные из единой базы данных Системы, выведенные по любому заданному алгоритму произвольной сложности. 34.2. Форма работы со списком должна обладать всеми возможностями по дальнейшему анализу данных: 34.2.1. Группировка данных по одному или нескольким столбцам. Например, реестр может быть сгруппирован по состоянию объектов учета, району города, разрешенному использованию. 34.2.2. Вычисление общих итогов, в том числе для каждой из групп (в случае применения группировки). Например, для приведенного примера возможна автоматическая калькуляция общей планируемой платы, площади объектов, величины задолженности в разрезе состояний договоров аренды, района расположения объекта договора, целевого использования. 34.2.3. Дополнительная оперативная фильтрация данных по значениям любого столбца\совокупности столбцов. 34.2.4. Сортировка данных по произвольному столбцу\совокупности столбцов. 34.2.5. Возможность выбора отображаемых столбцов. 34.2.6. Автоматическое сохранение настроек табличного представления для каждого типа объектов учета. 34.3. Должна быть предусмотрена возможность экспорта сформированных данных в форматы xlsx, xml, текстового файла или внутренние форматы генератора отчетов Соответствие Значение характеристики не может изменяться участником закупки 35. Требования к созданию формы поиска/фильтрации 35.1. Подсистема должна обладать инструментами создания формы поиска/фильтрации объекта по любому количеству критериев следующих типов: 35.1.1. Целочисленный. 35.1.2. Число с плавающей точкой. 35.1.3. Строковый. 35.1.4. Дата. 35.1.5. Значение из справочника или списка допустимых вариантов выбора. В качестве справочника может быть использован частично (по произвольному заданному условию фильтрации) или полностью любой из классификаторов Системы, а также любой перечень допустимых элементов выбора, сформированный как вручную, так и путем выборки по задаваемому алгоритму из произвольной информации, размещенной в единой базе данных Системы. 35.2. Форма поиска должна содержать произвольное количество параметров фильтрации в заданном порядке. 35.3. Для каждого критерия поиска в форме поиска/фильтрации должны создаваться элементы управления, содержащие следующую информацию: 35.3.1. Наименование критерия поиска на русском языке. 35.3.2. Перечень допустимых логических условий поиска (равно, не равно, больше, меньше, больше или равно, меньше или равно, содержит, начинается с, не содержит, не начинается, заполнено, не заполнено и т.п.). Перечень зависим от используемого типа данных реквизита (критерия) поиска. 35.3.3. Вводимое значение для поиска. 35.4. Должна быть предусмотрена возможность формирования критериев поиска как по любому атрибуту или характеристике объекта учета, так и по любым заданным условиям произвольной сложности и алгоритмизации Соответствие Значение характеристики не может изменяться участником закупки 36.5.16. Коэффициенты. 36.5.17. Примечание. 36.5.17. Связанные объекты имущества. 36.5.19. Связанные земельные участки Соответствие Значение характеристики не может изменяться участником закупки 19.6.1.1. Вычисление задолженности по договорам определенного типа (аренда, купля/продажа земельных участков, недвижимого, движимого имущества, объектов наружной рекламы, имущественных комплексов) или по всем типам. 19.6.1.2. Вычисление общей задолженности по субъекту договора или по всем субъектам. 19.6.1.3. Вычисление задолженности по договору или всем договорам. 19.6.1.4. Вычисление общей задолженности по определенному виду начисления или по всем видам. 19.6.1.5. Вычисление общей задолженности по определенному КБК или по всем КБК 19.6.1.6. В Системе должны быть предусмотрены следующие возможности: 19.6.1.7. Возможность запуска операции автоматического начисления арендной платы по диапазону периодов, годов. 19.6.1.8. Протоколирование выполнения всех автоматических операций и эвристический анализ состояния информационного фонда на поиск ошибок и потенциальных ошибок. 19.6.1.9. Выполнение любой автоматической операции должно сопровождаться формированием подробного протокола выполнения операции, в который в текстовом, понятном пользователю виде заносятся все операции, которые были произведены системой со всеми объектами учета. Одновременно, система должна выполнять комплекс эвристических проверок состояния информационного фонда системы на поиск ошибок или потенциальных ошибок, которые потенциально могут повлиять на корректность полученного результата. 19.6.1.10. Протоколы выполнения всех автоматических операций должны хранится в базе на постоянной основе и быть доступны для анализа в любой момент времени (возможность постанализа результатов выполнения операции). 19.6.1.11. Автоматический расчет и отображение «горячих итогов» (автовычисляемая и отображаемая на экране задолженность по заданным видам начисления (настраивается) по состоянию на текущую дату) по каждому субъекту (всем договорам субъекта общей суммой) и/или договору Соответствие Значение характеристики не может изменяться участником закупки 19.6.2. В автоматическом режиме Система должна рассчитывать и отображать следующие данные: 19.6.2.1. Задолженность по арендной плате/плате за выкуп по состоянию на текущее число. 19.6.2.2. Задолженность по пене по состоянию на текущее число. 19.6.2.3. Общая задолженность (по всем видам начисления) по состоянию на текущее число. 19.6.2.4. Текущая пеня (сумма пени, рассчитанная на текущий момент). 19.6.2.5. Всего начислено с начала года. 19.6.2.6. Текущая сумма планируемой арендной платы/платы за выкуп. 19.6.3. Поля «горячих» итогов должны поддерживать настройку на отображение итогов по любому виду начисления (глобальная настройка по Системе целиком). Должна быть предусмотрена возможность настройки не менее 10 показателей «горячих итогов» Соответствие Значение характеристики не может изменяться участником закупки 12.5.1.13. Принадлежность к земельному участку (множественная связь – один объект может быть размещен на нескольких земельных участках, на одном земельном участке может быть размещено несколько объектов). 12.5.1.14. Принадлежность к другим объектам (список объектов имущества, включенных в заданный объект (размещенных в пределах заданного объекта), например, перечень объектов, составляющих объект имущественного комплекса, перечень квартир в жилом здании, перечень комнат в квартире). Должна быть предусмотрена возможность связывать объект с ранее учетными в единой базе данных Системы объектами, включенными в данных объект (размещенными в пределах данного объекта). Должна быть предусмотрена возможность указания обратной связи – для ранее учтенного в единой базе Системы объекта указать объект, в который включен (в пределах которого размещен) заданный объект. 12.5.1.15. Признак принадлежности к объектам культурного наследия, а также информация о включении объекта в реестр объектов культурного наследия (Номер в реестре, категория историко-культурного наследия – справочник, Признак принадлежности объекта к объектам религиозного значения, признак принадлежности объекта к ансамблям, ссылка на документ-основание с возможностью указания нескольких документов оснований и период нахождения объекта в реестре с возможностью учета разных периодов включения объектов и соответственно разных данных по нахождению объекта в реестре). 12.5.1.16. Информация по проводимым аукционам, торгам, конкурсам Соответствие Значение характеристики не может изменяться участником закупки 12.5.1.17. Классификация объектов учета – предусмотрена возможность учета произвольного количества категорий классификации с произвольным количеством элементов классификации в каждой из категорий, а также текстовым описанием каждого элемента – с историей изменений и ссылками на документы-основания присвоения элемента классификации и исключения объекта из классификации (множественность документов-ссылок). 12.5.1.18. События (даты) – с историей изменений и ссылкой на документ-основание. 12.5.1.19. Признаки («галочки») - принадлежность к чему-либо с текстовым описанием признака. 12.5.1.20. Договоры использования и обременения (аренды, купли-продажи, безвозмездного пользования, согласования, разрешения, размещения, сервитуты). 12.5.1.21. Информация по претензионной и исковой деятельности (детальная информация по поданным претензиям и искам, включая необходимую классификационную и описательную части, предметы исков, в том числе суммы с делением по видам начислений, перечень этапов претензионной и исковой деятельности с указанием ссылок на документы этапа, уточнение требований) – см. пункт «Подсистема автоматизации претензионной и исковой деятельности». 12.5.2. Автоматическое присвоение реестрового номера с возможностью настройки методики и структуры формирования номера, а также возможностью организации сквозной нумерации по нескольким видам объектов учета (настройка категорий нумерации, для каждой категории можно указать перечень видов объектов учета, входящих в категорию). 12.5.3. Ведение информации по подобъектам, составным частям объектов. 12.5.4. Управление историей изменения основных характеристик объектов и документами-основаниями на проведение изменений Соответствие Значение характеристики не может изменяться участником закупки 3. Требования к серверу приложений: 3.1. Сервер приложений для Системы должен обеспечивать предоставление доступа клиентских мест к данным Системы, а также содержать средства обеспечения корректности исполнения технологических процессов (бизнес-логики) функционирования Системы. 3.2. Сервер приложений не должен требовать ручного запуска перед началом работы пользователей Системы. 3.3. Сервер приложений должен обеспечивать передачу клиентским местам информацию порциями по настраиваемому количеству записей (количество записей, которое помещается на экран без прокрутки при любом из используемых разрешений экрана) по мере обращения. 3.4. Передача информации на клиентское место из используемых справочников и классификаторов должна производиться при первом обращении к справочникам и классификаторам (за исключением системных справочников и классификаторов, необходимых для функционирования Системы в целом). 3.5. Передача информации на клиентское место по открытым электронным карточкам объектов учета должна производиться только в том объеме, в котором информация отображается в соответствующий момент в карточке объекта учета Соответствие Значение характеристики не может изменяться участником закупки 12.5.5. Управление движением объектов в реестре (включение, исключение, перемещение между реестрами, ведение истории реорганизации объектов (слияния, разделения)). 12.5.6. Управление движением объектов на балансе и в казне, договорами оперативного управления и хозяйственного ведения. 12.5.7. Обеспечение информационного взаимодействия/обмена информацией по объектам муниципальной собственности с субъектами права (балансодержателями и др.) – массовое обновление стоимостных показателей (балансовая, остаточная стоимость, износ), характеристик объектов. 12.5.8. Управление движением объектов в казне (с возможностью ведения балансового и забалансового бюджетного учета движения объектов в казне). 12.5.9. Ведение документального обеспечения (документов-оснований) движения объектов, изменения характеристик объектов в реестре. 12.5.10. Ведение аукционов и торгов на право аренды или купли-продажи объектов. 12.5.11. Формирование реестров объектов муниципальной собственности. 12.5.12. Формирование выписок из реестров, справок о движении объектов, проектов приказов, постановлений, распоряжений, других необходимых печатных форм. 12.5.13. Формирование аналитической отчетности. 12.5.14. Проведение экспресс-аналитики. 12.5.15. Корректное проставление даты выбытия объекта в зависимости от выбранного документа основания (например, выбытие по исключению из реестра или из-за регистрации права собственности за иным лицом). 12.5.16. Возможность указания шаблона для вывода адреса в нужном формате Соответствие Значение характеристики не может изменяться участником закупки 12.5.17. Возможность работы со справочниками ФИАС при формировании адреса. 12.5.18. Управление историей объектов для отслеживания хронологии реорганизации, разделения, объединения объекта. 12.5.19. Протоколирование действий пользователей. 12.5.20. Возможность прикрепления к карточке объекта учета произвольного количества файлов произвольного типа. 12.5.21. Возможность ведения информации о внереестровых объектах. 12.6. Должна быть предусмотрена возможность смены типа объектов, включенных по ошибке в другие подразделы имущества (в том числе объектов прошлых периодов), например, изменить тип «нежилое здание» на «нежилое помещение» или на «сооружение» и наоборот Соответствие Значение характеристики не может изменяться участником закупки 13. Требования к подсистеме «Земля»: 13.1. Подсистема «Земля» должна автоматизировать ведение реестров земельных участков, собственность на которую разграничена, а также ведение земельных участков, собственность на которые не разграничена или с другими видами собственности, находящихся в сфере компетенции органов управления земельными ресурсами. 13.2. Подсистема должна автоматизировать выполнение следующих основных задач: 13.2.1. Пообъектный учет земельных участков (ЗУ). Для каждого из ЗУ ведется следующая основная информация: 13.2.1.1. Наименование ЗУ. 13.2.1.2. Принадлежность к реестру, подреестру (с историей изменения). 13.2.1.3. Кадастровый номер (кадастровый квартал выбирается из классификатора, не обязательный для заполнения). 13.2.1.4. Категория земель (с историей изменения и ссылками на документы-основания). 13.2.1.5. Разрешенное использование (с историей изменения и ссылками на документы-основания). 13.2.1.6. Уровень собственности (состояние) Соответствие Значение характеристики не может изменяться участником закупки 4. Требования к размещению средств обеспечения корректности исполнения технологических процессов (бизнес-логики) Системы: 4.1. Средства обеспечения корректности исполнения технологических процессов (бизнес-логики) в максимально возможном объеме должны быть реализованы на уровне базы данных (выполняться в автоматическом режиме на уровне СУБД). 4.2. На уровне СУБД должны быть реализованы следующие процессы (технологические процессы или их части): 4.2.1. Ведение аудита действий пользователей на уровне полей таблиц (конкретных атомарных атрибутов объектов учета, в том числе в составе составных характеристик). 4.2.2. Проверка прав пользователей (хранимые функции или процедуры проверки прав пользователей). 4.2.3. Поддержка функционирования средств «быстрого поиска» (по необходимости). 4.2.4. Формирование проводок бюджетного учета по администрируемым кодам бюджетной классификации при внесении изменений в данные финансово-аналитической подсистемы в соответствии с требованиями Министерства финансов РФ. 4.2.5. Расчет суммы планируемой платы по договорам. 4.2.6. Начисление арендной платы, платы за выкуп, платы за фактическое использование объектов, всех видов штрафных санкций, включая начисление пени, процентов за пользование чужими денежными средствами. 4.2.7. Расчет сальдо. 4.2.8. Расчет задолженности на произвольную дату в произвольном разрезе. 4.2.9. Пересчет задолженности на текущее число по всем видам договорных отношений. 4.2.10. Алгоритмы парсинга (разбора) сведений, получаемых по протоколам СМЭВ в машиночитаемом виде (xml). 4.2.11. Алгоритмы автоматического и полуавтоматического внесения информации в информационный фонд Системы на основе полученных сведений по протоколам СМЭВ. 4.3. Средства обеспечения технологических процессов, которые не могут быть реализованы на стороне СУБД, должны быть реализованы средствами сервера приложения. 4.4. На клиентском месте должны быть продублированы те элементы технологических процессов, которые могут определить некорректные действия Соответствие Значение характеристики не может изменяться участником закупки 5. Требования к способам и средствам связи для информационного обмена между компонентами Системы: 5.1. Система должна обеспечивать коллективную работу пользователей объекта автоматизации с использованием единого интегрированного хранилища данных по технологии «клиент-сервер» с использованием трехзвенной архитектуры. 5.2 Количество клиентских подключений к серверу не менее 30 (тридцать). Соответствие Значение характеристики не может изменяться участником закупки 6. Требования к приспособляемости Системы: 6.1. Функциональность Системы должна допускать наращивание функциональных возможностей на основе подключения дополнительных (или изменения существующих) подсистем в связи с изменением существующих и возникновением новых автоматизируемых процессов, обусловленных изменениями в нормативно-законодательной базе. 6.2. Подсистемы должны иметь программные интерфейсы, обеспечивающие возможность расширения функциональности Системы путём добавления компетентными, обученными пользователями Системы дополнительных программных модулей. 6.3. Система должна быть легко настраивающейся на изменения условий функционирования и организационной структуры объектов автоматизации Системы. 6.4. Система должна сохранять работоспособность при увеличении количества пользователей в пределах, поддерживаемых аппаратно-программной средой серверов технологического узла. 6.5. Должна быть обеспечена возможность увеличения числа пользователей Системы Соответствие Значение характеристики не может изменяться участником закупки 13.2.1.7. Реестровый номер (с историей изменения и ссылками на документы-основания). 13.2.1.8. Адрес, адресный ориентир (с возможностью ввода множественного адреса). Должна быть предусмотрена возможность указания государственного образования для обеспечения возможности дальнейшего отбора земельных участков по соответствующему показателю. 13.2.1.9. Субъекты права (землепользователи, другие субъекты права) – с историей изменения, множественностью документов-оснований возникновения и прекращения права (ссылки на документы), в том числе и права постоянного (бессрочного) пользования. 13.2.1.10. Экономические показатели (Кадастровые стоимости и др.) – с историей изменения и ссылками на документы-основания. 13.2.1.11. Технические показатели (с историей изменения и ссылками на документы-основания). 13.2.1.12. Документы (все документы, имеющие отношение к данному объекту с делением по направлениям воздействия документов (включение/исключение, внесение изменений, правоустанавливающие, регистрирующие документа)). 13.2.1.13. Комиссии. 13.2.1.14. Коэффициенты-характеристики, площадь (с историей изменения и ссылками на документы-основания). 13.2.1.15. Информация по использованию ЗУ (классификация для аналитики, ставки арендной платы, типы использования для кадастровой оценки, налоговые ставки по типам использования) с возможностью указания различных типов использования долей земельного участка (с историей изменения и ссылками на документы-основания). 13.2.1.16. Перечень объектов недвижимого имущества, размещенных на данном участке. (кадастровый номер, наименование, права) 13.2.1.17. Информация по проводимым аукционам, торгам, конкурсам Соответствие Значение характеристики не может изменяться участником закупки 13.2.1.18. Классификация объектов учета – предусмотрена возможность учета произвольного количества категорий классификации с произвольным количеством элементов классификации в каждой из категорий, а также текстовым описанием каждого элемента – с историей изменений и ссылками на документы-основания присвоения элемента классификации и исключения объекта из классификации (множественность документов-ссылок). 13.2.1.19. Информация по претензионной и исковой деятельности (детальная информация по поданным претензиям и искам, включая необходимую классификационную и описательную части, предметы исков, в том числе суммы с делением по видам начислений, перечень этапов претензионной и исковой деятельности с указанием ссылок на документы этапа, уточнение требований) – см. Пункт «Подсистема автоматизации претензионной и исковой деятельности». 13.2.1.20. События (даты) – с историей изменений и ссылкой на документ-основание. 13.2.1.21. Признаки («галочки») - принадлежность к чему-либо с текстовым описанием признака. 13.2.1.22. Договоры использования и обременения (аренды, купли-продажи, безвозмездного пользования, согласования, разрешения, размещения, сервитуты). 13.2.2. Автоматическое присвоение реестрового номера с возможностью настройки методики и структуры формирования номера, а также возможностью организации сквозной нумерации по нескольким видам объектов учета (настройка категорий нумерации, для каждой категории можно указать перечень видов объектов учета, входящих в категорию). 13.2.3. Управление историей изменения основных характеристик ЗУ, документами-основаниями на проведение изменений. 13.2.4. Управление движением ЗУ в реестре (включение, исключение, перемещение между реестрами, ведение истории реорганизации объектов (слияния, разделения)). 13.2.5. Управление движением ЗУ по субъектам права. 13.2.6. Управление движением ЗУ в казне (с возможностью ведения балансового и забалансового бюджетного учета движения объектов в казне) Соответствие Значение характеристики не может изменяться участником закупки 7. Требования к защите информации от несанкционированного доступа: 7.1. Система должна обеспечивать идентификацию и аутентификацию пользователя, обратившегося для получения доступа к функциям Системы. В Системе должны быть обеспечены разграничение и администрирование доступа к компонентам Системы. 7.2. Механизмы безопасности Системы должны позволять ограничивать круг лиц, принимающих участие в работе с данными, и позволять контролировать процесс работы с защищенными документами и знать, откуда возможна утечка информации. 7.3. Защита информации от несанкционированного доступа в Системе должна обеспечиваться реализацией следующих функций Системы: 7.3.1. Предоставление доступа к Системе должно предоставляться только предварительно зарегистрированным пользователям. 7.3.2. Возможность разграничения доступа к подсистемам для каждого пользователя. 7.3.3. Возможность для каждого пользователя установить уровень доступа, обеспечивающий только просмотр или редактирование информации. 7.3.4. Управление разграничением и/или уровнями доступа пользователей должно осуществляться через группы доступа. 7.3.5. Разграничение по доступу к данным Системы должно быть согласно утвержденным полномочиям пользователей Системы. 7.3.6. Регистрация входа (выхода) пользователей в Систему (из Системы) должна фиксироваться в журнале действий пользователей. 7.3.7. Должна быть возможность функционального разграничения действий пользователей при обработке информации. 7.3.8. Ведение справочника пользователей Системы. 7.3.9. Журналирование действий пользователей, которое должно обеспечиваться путем ведения в Системе «журнала событий», доступного только с автоматизированного рабочего места администратора и включающего в себя следующие данные: 7.3.9.1. Системные действия: дата, событие, пользователь. 7.3.9.2. Действия над пользователями Системы: дата, событие, администратор. 7.3.9.3. Действия пользователей. 7.4. «Журнал событий» должен быть недоступен к внесению изменений Соответствие Значение характеристики не может изменяться участником закупки 7.5. Система должна обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях Система должна выдавать пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных. 7.6. Должна быть предусмотрена возможность резервного копирования и ручного восстановления стандартными средствами системы управления базой данных (далее – СУБД) администраторами Системы обрабатываемой информации из резервной копии в следующих аварийных ситуациях: 7.6.1. Ошибочные действия пользователей (администраторов), приведшие к утрате или искажению данных Системы. 7.6.2. Отказ Системы, связанный с фатальным нарушением целостности файловой системы или структуры баз данных. 7.7. Для резервного копирования должны использоваться штатные средства системной программной платформы, причем организация баз данных Системы должна обеспечивать сохранение: 7.7.1. Всех параметров настройки Системы, включая учетные записи и персональные настройки пользователей. 7.7.2. Всей информации Системы Соответствие Значение характеристики не может изменяться участником закупки 8. Требования к патентной чистоте: 8.1. По результату исполнения контракта Система должна отвечать требованиям по патентной чистоте согласно действующему законодательству Российской Федерации, в Системе не должны использоваться решения, приводящие к нарушению смежных прав и прав третьих лиц, защищенные патентами или иными действующими на территории Российской Федерации документами, удостоверяющими авторские права на них, без соответствующего лицензионного соглашения с авторами данных решений. Выполнение требований по обеспечению лицензионной чистоты Системы возлагается на Исполнителя Соответствие Значение характеристики не может изменяться участником закупки 13.2.7. Ведение документального обеспечения (документов-оснований) движения ЗУ, изменения характеристик объектов в реестре. 13.2.8. Ведение аукционов и торгов на право аренды или купли-продажи ЗУ. 13.2.9. Формирование реестров земельных участков. 13.2.10. Формирование выписок из реестра, справок о движении ЗУ, проектов приказов, постановлений, распоряжений, других необходимых печатных форм. 13.2.11. Формирование аналитической отчетности в соответствующей сфере. 13.2.12. Проведение экспресс-аналитики. 13.2.13. Корректное проставление даты выбытия объекта в зависимости от выбранного документа основания (например, выбытие по исключению из реестра или из-за регистрации права собственности за иным лицом). 13.2.14. Возможность указания шаблона для вывода адреса в нужном формате. 13.2.15. Возможность работы со справочниками ФИАС при формировании адреса. 13.2.16. Управление историей объектов для отслеживания хронологии реорганизации, разделения, объединения объекта. 13.2.17. Протоколирование действий пользователей. 13.2.18. Возможность прикрепления к карточке объекта учета произвольного количества файлов произвольного типа. 13.2.19. Возможность ведения информации о внереестровых объектах Соответствие Значение характеристики не может изменяться участником закупки 9. Требования к контролю, хранению, обновлению и восстановлению данных: 9.1. Контроль корректности данных должен обеспечиваться реализацией функций форматного, логического контроля на уровне пользовательских форм. 9.2. Для хранения данных Системы должна использоваться СУБД, средствами которой выполняются действия записи, обновления, журналирования изменений, резервного копирования и восстановления данных Соответствие Значение характеристики не может изменяться участником закупки 10. Требования к лингвистическому обеспечению 10.1. В системных диалогах с пользователями в текстах сообщений должен применяться русский язык, за исключением сообщений общесистемного ПО, не подлежащих переводу на русский язык. 10.2. Содержание используемых в Системе справочников должно быть реализовано на русском языке Соответствие Значение характеристики не может изменяться участником закупки 11. Состав Системы: 11.1. Система состоит из следующих подсистем, средств и других элементов, выполняющих соответствующие функции: 11.1.1. Подсистемы и средства Системы, входящие в базовую конфигурацию: 11.1.2. Подсистема «Имущество» 11.1.2. Подсистема «Земля». 11.1.3. Подсистема «Ведение информации по субъектам права». 11.1.4. Подсистема «Ведение информации по акциям, долям». 11.1.5. «Адресная подсистема». 11.1.6. Подсистема «Ведение договоров и дополнительных соглашений» 11.1.7. Подсистема «Выкуп с рассрочкой». 11.1.8. «Финансово-аналитическая подсистема». 11.1.9. Подсистема «Автоматизация претензионной и исковой деятельности». 11.1.10. Аналитическая и сервисная подсистема «Библиотека запросов». 11.1.11. Подсистема «Формирование отчетов и печатных форм, генератор отчетов». 11.1.12. Подсистема «Обеспечение безопасности, администрирования и разграничения прав доступа». 11.1.13. Подсистема «Ведение нормативно-справочной информации». 11.1.14. Подсистема «Автоматическое обновление клиентских рабочих мест». 11.1.15. Подсистема «Оповещение пользователей». 11.1.16. Подсистема «Самодиагностика с оповещением о выявленных аномалиях по электронной почте». 11.1.17. Средства ведения электронных карточек объектов учета. 11.1.18. Средства поиска, отображения и анализа информации. 11.1.19. Средства предварительного просмотра. 11.1.20. Средства выполнения массовых операций. 11.2. Дополнительные подсистемы Системы: 11.2.1. Подсистема «Бюджетный учёт доходов». 11.2.2. Подсистема «Бюджетный учёт движения объектов в казне». 11.2.3. Подсистема «Управление объектами жилого фонда», включая подсистему «Аварийное жилье - учет и управление». 11.2.4. Подсистема «Управление взносами на капитальный ремонт». 11.2.5. Подсистема «Ведение проверок использования имущества и земельных участков». 11.2.6. Подсистема межведомственного электронного взаимодействия (платформа СМЭВ). 11.2.7. Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» Соответствие Значение характеристики не может изменяться участником закупки 11.2.8. Подсистема «Межведомственное электронное взаимодействие с Росреестром». 11.2.9. Подсистема «Межведомственное электронное взаимодействие с ЗАГС» Соответствие Значение характеристики не может изменяться участником закупки 12. Требования к подсистеме «Имущество»: 12.1. Подсистема «Имущество» должна автоматизировать ведение реестра объектов муниципальной собственности, а также внереестровых объектов всех учитываемых типов. 12.2. Доступ к объектам имущества должен осуществляться из основного окна Системы с использованием иерархического меню. 12.3. Перечень учитываемых типов и конкретная настройка иерархического меню доступа к объектам должны быть определены на этапе обследования организации. Например, иерархическое меню доступа и перечень учитываемых типов объектов могут быть настроены в ручном режиме, например, в соответствии со схемой: 12.3.1. Недвижимое имущество: 12.3.1.1. Жилой фонд: 12.3.1.1.1. Жилые здания. 12.3.1.1.2. Жилые квартиры, помещения. 12.3.1.1.3. Жилые комнаты. 12.3.1.2. Нежилые здания. 12.3.1.3. Нежилые помещения. 12.3.1.4. Объекты незавершенного строительства. 12.3.1.5. Объекты инженерной инфраструктуры, сооружения. 12.3.1.6. Объекты внешнего благоустройства. 12.3.1.7. Доли. 12.3.1.8. Нематериальные активы, объекты интеллектуальной собственности. 12.3.1.9. Воздушные и морские суда, суда внутреннего плавания. 12.3.1.10. Космические объекты. 12.3.1.11. Прочие объекты, не включенные в указанные группировки Соответствие Значение характеристики не может изменяться участником закупки 12.3.2. Движимое имущество: 12.3.2.1. Особо ценное движимое имущество. 12.3.2.2. Малоценное (прочее) движимое имущество. 12.3.2.3. Транспортные средства. 12.3.2.4. Объекты инженерной инфраструктуры. 12.3.2.5. Прочее движимое имущество, не относящиеся к указанным выше. 12.3.3. Акции, паи, доли. 12.3.4. Имущественные комплексы. 12.3.5. Муниципальные предприятия и учреждения. 12.4. Должна быть предусмотрена возможность скрытия неиспользуемых на момент внедрения пунктов меню (видов объектов учета). 12.5. Подсистема должна автоматизировать выполнение следующих основных задач: 12.5.1. Учет объектов. Для каждого из объектов должна вестись следующая основная информация: 12.5.1.1. Наименование объекта. 12.5.1.2. Принадлежность к реестру, подреестру (с историей изменения и ссылками на документы-основания). 12.5.1.3. Реестровый номер (с историей изменения и ссылками на документы-основания). 12.5.1.4. Кадастровый номер (не обязательный для заполнения, при наличии – обязательный для заполнения), условный номер. 12.5.1.5. Адрес (с возможностью ввода множественного адреса). 12.5.1.6. Субъекты права (движение на балансе, другие субъекты права) – с историей изменения, множественностью документов-оснований возникновения и прекращения права (ссылки на документы) Соответствие Значение характеристики не может изменяться участником закупки 12.5.1.7. Экономические показатели (балансовые, остаточные стоимости и др.) – с историей изменения и ссылками на документы-основания. 12.5.1.8. Технические показатели (с историей изменения и ссылками на документы-основания). 12.5.1.9. Документы (все документы, имеющие отношение к данному объекту с делением по направлениям воздействия документов (включение/исключение, внесение изменений, правоустанавливающие, регистрирующие документа) – без ограничения количества и типов регистрируемых документов). 12.5.1.10. Комиссии. 12.5.1.11. Коэффициенты-характеристики, площадь (с историей изменения и ссылками на документы-основания). 12.5.1.12. Части помещений (подвал, полуподвал, этажи): 12.5.1.12.1. Коэффициенты-характеристики частей помещений, площадь (с историей изменения и ссылками на документы-основания). 12.5.1.12.2. Типы использования частей помещений (с историей изменения и ссылками на документы-основания). 12.5.1.12.3. Материал стен, варианты входа, уровни благоустройства, высота потолков – произвольное количество категорий благоустройства с произвольным количеством выбираемых элементов благоустройства в каждой категории, предусмотрена возможность указания уровней благоустройства объекта целиком и каждой из частей помещения отдельно Соответствие Значение характеристики не может изменяться участником закупки Класс программ для электронных вычислительных машин и баз данных (12.20) Информационные системы для решения специфических отраслевых задач Значение характеристики не может изменяться участником закупки Способ предоставления Экземпляр на материальном носителе Значение характеристики не может изменяться участником закупки Вид лицензии Простая (неисключительная) Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Передача неисключительных прав на Автоматизированную систему управления имущественно-земельным комплексом:1. Требования к структуре Системы: 1.1. Система должна быть построена по 3х-звенной архитектуре и состоять из следующих компонентов: 1.1.1. Системы управления базами данных (СУБД) – предназначены для хранения и управления информацией базы данных Системы. 1.1.2. Сервер приложений – промежуточное звено обеспечения взаимодействия клиентских мест и СУБД. 1.1.3. Клиентские места – «тонкий» (Desktop) клиент - пользовательские приложения, устанавливаемые на рабочих местах пользователей для предоставления доступа пользователей к функциям Системы - Соответствие - - Значение характеристики не может изменяться участником закупки - 2. Требования к используемым СУБД: 2.1. Система должна быть совместима с СУБД PostgreSQL версии не менее 14.10. 2.2. СУБД не должна иметь ограничений по размеру базы данных и не должна требовать дополнительных обязательных расходов на сопровождение - Соответствие - - Значение характеристики не может изменяться участником закупки - 60. Средства формирования межведомственных запросов из карточки объекта Системы: 60.1. Формирование межведомственных запросов из карточки объекта Системы подразумевает возможность автоматического формирования запроса в системе СМЭВ. Параметры, необходимые для формирования запроса в автоматическом режиме должны заполняться на основе данных, размещенных в соответствующей карточке объекта учета, из которой формируется запрос. 60.2. При формировании запроса пользователь должен предварительно выбрать услугу (сервис), для которой формируется запрос. Выбор должен производиться из перечня услуг (сервисов), для которых доступно формирование запроса из карточки объекта данного типа. 60.3. Формирование запроса должно быть реализовано с использованием динамически формируемого перечня пунктов подменю пункта «СМЭВ» меню карточки (или кнопки СМЭВ). 60.4. Динамически формируемый перечень подменю должна соответствовать перечню доступных для запроса услуг/сервисов с отбивкой сепаратором услуг/сервисов различных организаций (услуги/сервисы различных организаций визуально должны быть отделены друг от друга) - Соответствие - - Значение характеристики не может изменяться участником закупки - 60.5. В случае, если карточка объекта учета не содержит всей необходимой для формирования запроса информации, пользователь должен быть в развернутой форме информирован о характере возникшей ошибки с указанием конкретных реквизитов объекта, которые должны быть заполнены для корректного формирования запроса. 60.6. Должна быть предусмотрен режим ручного формирования запроса из карточки объекта. В данном режиме Система инициирует ручное создание запроса, а также производит автоматическое заполнение параметров запроса сведениями, содержащимися в карточке соответствующего объекта учета. 60.7. После этого пользователю предоставляется возможность самостоятельной корректировки сведений (параметров запроса) и ручного формирования межведомственного запроса. 60.8. После формирования запроса пользователю должно быть выведено соответствующее сообщение с указанием кода сформированного запроса в журнале запросов - Соответствие - - Значение характеристики не может изменяться участником закупки - 61. Средства формирования межведомственных запросов в режиме массовой операции: 61.1. Для формирования межведомственных запросов в режиме массовой операции должен быть задействован стандартный механизм Системы работы с массовыми операциями (выбора объектов для выполнения массовой операции). 61.2. Выбор объектов для массовой операции должен производиться с использованием следующих средств: 61.2.1. Из списка объектов учета любых типов основного окна Системы. 61.2.2. Из экранных форм Системы, отображающих списки объектов учета произвольных типов. 61.2.3. Из окна результата запроса подсистемы «Библиотека запросов». 61.3. Выбор услуги (сервиса) для формирования запроса должен быть реализован путем динамического создания пунктов подменю пункта СМЭВ. Пункты подменю должны содержать полный перечень всех услуг/сервисов, доступных для формирования из карточек объектов учета, доступных для выполнения массовой операции в текущем режиме работы. 61.4. Выполнение массовой операции должно производиться пообъектно способом, аналогичным формированию запроса из карточки объекта учета соответствующего типа (описание приведено выше). 61.5.В случае, если операция формирования запроса для данного вида объекта учета недоступна (в соответствии с настройками) или для формирования запроса недостаточно информации, по таким объектам формируется ошибка по правилам функционирования функционала массовых операций (объект помечается красным фоном, формируется развернутое сообщение об ошибке (содержит четкое описание сути ошибки), объект пропускается, происходит переход к обработке следующего объекта). 61.6.Операции, выполняемые в режиме массовой операции, должны протоколироваться по общим принципам (индивидуальное протоколирование каждого сформированного в режиме массовой операции межведомственного запроса) - Соответствие - - Значение характеристики не может изменяться участником закупки - 62. Средства формирования межведомственных запросов в режиме регламентной операции: 62.1. Регламентная операция представляет собой выполнение некоторого запроса по определенному расписанию, межведомственные запросы формируются в автоматическом режиме для каждого объекта, информация по которому возвращена запросом. 62.2. Средства формирования межведомственных запросов в режиме регламентных операций должны обеспечивать ведение библиотеки регламентных операций, средства добавления, изменения, удаления регламентных операций, приостановки выполнения регламентных операций. 62.3. Библиотека регламентных операций должна представлять собой список регламентных операций, содержащий следующие атрибуты: 62.3.1. Код идентификатор (код) регламентной операции. 62.3.2. Наименование - наименование регламентной операции. 62.3.3. Организация – наименование организации, предоставляющей услугу/сервис. 62.3.4. Сервис наименование услуги/сервиса для формирования запроса в режиме регламентной операции. 62.3.5. Признак успешности предыдущего выполнения. 62.3.6. Дата, время следующего выполнения. 62.3.7. Состояние (запланировано, приостановлено). 62.3.8. Приостановленные регламентные операции или регламентные операции, для которых не определено время следующего запуска должно визуально выделяться (серый текст шрифта). 62.3.9. Регламентные операции, по которым предыдущий вызов был завершен ошибкой должны визуально выделяться (розовый фон). 62.3.10. Для каждой регламентной операции должны быть определены: 62.3.10.1. Код – присваивается автоматически. 62.3.10.2. Наименование регламентной операции. 62.3.10.3. Описание регламентной операции – текст произвольного размера. 62.3.10.4. Услуга/сервис – выбор из списка услуг/сервисов, доступных для формирования запросов в режиме регламентной операции. 62.4. Расписание выполнения операции (стандартный функционал для формирования расписаний) – в определенное время разово, ежечасно, ежедневно, еженедельно в определенные дни - Соответствие - - Значение характеристики не может изменяться участником закупки - 63. Средства подписания запросов электронной подписью: 63.1. С целью обеспечения возможности автоматизированного формирования запросов в пакетном режиме, а также автоматического формирования запросов в режиме массовой операции в Подсистеме должны быть реализованы средства централизованного (серверного) принципа подписания запросов электронной подписью. Для этого в составе подсистемы должен быть реализован сервер ЭП (сервер электронной подписи). Это означает, что в подсистеме должна быть реализована возможность добавления одной или более учетных записей организаций/пользователей организаций, настройки и реквизиты которых будут использоваться для формирования межведомственных запросов и подписания их электронной подписью. Для каждой учетной записи должна быть обеспечена возможность сопоставления с ЭП-ОВ (электронной подписи органа власти) и ЭП-СП – электронная подпись служебного пользования уполномоченного лица (руководителя), которые загружены на сервер ЭП. 63.2. Для каждого пользователя Системы, в должностные обязанности которого входит возможность формирования межведомственных запросов, должна быть предусмотрена возможность указать учетную запись организации/уполномоченного лица организации, электронные подписи которой будут использоваться для автоматического подписания запросов, сформированных соответствующим пользователем. 63.3. Запросы, формируемые средствами подсистемы в любом из описанных выше режимов, должны подписываться ЭП-ОВ и/или ЭП-СП в зависимости от методических рекомендаций для соответствующего вида сведений - Соответствие - - Значение характеристики не может изменяться участником закупки - 64. Средства ручного внесения результатов запросов, которые не формировались средствами: подсистемы 64.1. В подсистеме должны быть предусмотрены средства внесения результатов запросов, полученных из внешних источников, то есть без использования средств подсистемы. 64.2. При ручной загрузке результата подсистема должно быть инициировано автоматическое занесение соответствующего запроса в журнал запросов. Дальнейшая обработка загруженного вручную результата должна производиться стандартным способом (загрузка результата в интегрированное хранилище, применение результата (внесение изменений в единую база данных 64.3. Системы на основе полученных сведений)). 64.4. В протокол работы с запросом автоматически должна быть добавлена запись, что результат загружен вручную без использования межведомственного взаимодействия - Соответствие - - Значение характеристики не может изменяться участником закупки - 65. Средства ручного внесения результатов запросов, которые не формировались средствами подсистемы: 65.1. В подсистеме должны быть предусмотрены средства внесения результатов запросов, полученных из внешних источников, то есть без использования средств подсистемы. 65.2. При ручной загрузке результата подсистема должно быть инициировано автоматическое занесение соответствующего запроса в журнал запросов. Дальнейшая обработка загруженного вручную результата должна производиться стандартным способом (загрузка результата в интегрированное хранилище, применение результата (внесение изменений в единую база данных Системы на основе полученных сведений)). 65.3. В протокол работы с запросом автоматически должна быть добавлена запись, что результат загружен вручную без использования межведомственного взаимодействия - Соответствие - - Значение характеристики не может изменяться участником закупки - 66. Средства предотвращения повторного формирования запросов: 66.1. Подсистема должна содержать средства повторного формирования запросов на одни и те же объекты учета. 66.2. Под повторным формированием запроса понимается формирование запроса на объект, на который уже был ранее сформирован межведомственный запрос на получение сведений по этой же услуге (сервису), по которому сведения получены, но еще не использованы (запрос не «закрыт»), или запрос находится в состоянии ожидания сведений (ответа), то есть по запрос не был отклонен (не находится в состоянии ошибки), сведения еще не получены. 66.3. В ходе проверки на наличие предыдущих запросов следует учесть, что запрос на данный объект учета мог быть сформирован не из текущей карточки, например, текущий запрос получения выписки из ЕГРН на объект имущества формируется из карточки договора приватизации этого объекта имущества, однако ранее был сформирован запрос на этот же объект, но из карточки другого договора или самого объекта. Должна быть предусмотрена возможность определения возможности проверки на наличие сформированных ранее запросов в ручном режиме – возможность должна быть определена на этапе реализации. При наличии возможности указанный функционал подлежит реализации. 66.4. Для каждого сервиса/услуги должна быть предусмотрена возможность настройки количества дней, в течение которых результат предыдущего запроса можно считать актуальным. В случае, если такая настройка произведена, то при ручном формировании запроса или формировании запроса из карточки объекта, при наличии ранее полученного ответа подсистема должна предупреждать пользователя, что уже получен результат на соответствующий запрос с указанием даты его получения и возможностью открытия результата предыдущего запроса. В режиме массовой и регламентной операции формирование таких повторных запросов должно быть заблокировано с указанием причины (по объекту имеется актуальные сведения на запрос, полученные такого-то числа) - Соответствие - - Значение характеристики не может изменяться участником закупки - 67. Средства опроса системы СМЭВ на предмет уточнения состояния запроса, загрузка полученных сведений: 67.1. Основным режимом получения/обновления сведений о сформированных ранее межведомственных запросов из системы СМЭВ является режим периодического опроса (пингования) системы СМЭВ. 67.2. При наличии изменений с момента последнего опроса (пингования) системы СМЭВ (изменение даты и времени последнего изменения запроса в системе СМЭВ с аналогичными данными в интегрированном хранилище Системы), полученная информация должна быть занесена в интегрированное хранилище Системы: 67.2.1. Дата и время последнего изменения состояния или сведений запроса в системе СМЭВ. 67.2.2. Текущий статус (состояние) запроса. 67.2.3. При изменении статуса (состояния) запроса – информация по изменению состояния (см. требования к интегрированному хранилищу данных). 67.3. При получении сведений за межведомственный запрос (XML-файл, содержащий сведения), подсистема должна выполнять чтение файла и должна разместить полученную из XML-файла информацию в соответствующих субтаблицах запроса в виде, пригодном для формирования SQL-запросов с использованием полученных сведений - Соответствие - - Значение характеристики не может изменяться участником закупки - 67.4. Все операции по опросу (пингованию) системы СМЭВ вне зависимости от наличия изменений должны протоколироваться. Требования к протоколированию приведены в пункте «Интегрированное хранилище данных». 67.5. Должна быть предусмотрена возможность опроса (пингования) по всем сформированным межведомственным запросам, обработка которых еще не завершена (запрос не находится в состоянии ошибки и сведения по нему еще не получены), а также по межведомственным запросам определенной (выбранной пользователем) услуги (сервиса). Операция должна выполняться из основного окна Системы с использованием соответствующих пунктов меню. 67.6. В некоторых случаях сведения, содержащиеся в ответе на межведомственный запрос, не передаются в ходе межведомственного взаимодействия, а должны скачиваться пользователем вручную с использованием сети интернет. Такая ситуация возникает, например, из-за большого объема полученных сведений. - Соответствие - - Значение характеристики не может изменяться участником закупки - 68. Средства загрузки полученных сведений в интегрированное хранилище: 68.1. Полученные в результате межведомственного запроса сведения содержат XML-файл заданной в спецификациях к конкретной услуге (сервису) структуры. 68.2. В момент получения XML-файла должно быть обеспечено чтение всех данных XML-файла и размещение их в интегрированном хранилище Системы (единой базе данных Системы) в структурированном виде, пригодном для использования в SQL-запросах (см. требования к интегрированному хранилищу). 68.3. Чтение данных XML-файла и размещение их в интегрированном хранилище должно осуществляться с использованием алгоритма из библиотеки алгоритмов парсинга (разбора) результатов запросов, полученных в машиночитаемом виде (xml). 68.4. Должна быть предусмотрена возможность разработки новых алгоритмов и включение их в библиотеку алгоритмов силами обученных пользователей Системы Заказчика. 68.5. Должно быть предусмотрено обязательное протоколирование выполнения указанной процедуры. Требования к протоколированию приведены в пункте «Интегрированное хранилище данных»). 68.6. Загрузка полученных сведений в интегрированное хранилище должно производиться вне зависимости от способа загрузки сведений (автоматическая загрузка при получении ответа на сформированный ранее запрос), ручная загрузка результата, направленного ранее запроса, ручная загрузка результата на запрос, который не был отправлен средствами подсистемы - Соответствие - - Значение характеристики не может изменяться участником закупки - 69. Средства автоматического внесения изменений в единую БД Системы на основе полученных сведений: 69.1. Автоматическое внесение изменений в единую базу данных Системы на основе полученных сведений должно производится в момент получения сведений на межведомственный запрос после размещения полученных данных в реляционных субтаблицах. 69.2. Автоматическое внесение изменений должно производиться путем вызова соответствующего алгоритма из библиотеки алгоритмов, наименование которого настраивается для каждой услуги (сервиса). 69.3. Должна быть предусмотрена возможность разработки новых алгоритмов и включение их в библиотеку алгоритмов силами обученных пользователей Системы Заказчика. 69.4. По завершении автоматического внесения информации в интегрированном хранилище для данного запроса должны быть установлены дата и время автоматического внесения изменений на основе полученных сведений, признак завершения отработки запроса, а также вид операции – «Автоматическое внесение информации». 69.5. Должно быть предусмотрено обязательное протоколирование выполнения указанной процедуры. Протоколированию подлежит также факт невыполнения автоматической операции в связи с отсутствием имени алгоритма, выполняющего соответствующее действие. 69.6. Автоматическое внесение сведений может быть отключено настройками подсистемы (такая настройка должна быть предусмотрена индивидуально для каждого типа объектов учета, а также сервиса/услуги). В случае, если автоматическое внесение изменений отключено, должна быть предусмотрена возможность ручного запуска средств автоматического внесения изменений из окна просмотра результатов запроса. Факт ручного запуска средств автоматического внесения информации должен быть внесен в протокол - Соответствие - - Значение характеристики не может изменяться участником закупки - 70. Средства автоматического внесения изменений в единую БД Системы на основе полученных сведений: 70.1.1. Автоматическое внесение изменений в единую базу данных Системы на основе полученных сведений должно производится в момент получения сведений на межведомственный запрос после размещения полученных данных в реляционных субтаблицах. 70.1.2. Автоматическое внесение изменений должно производиться путем вызова соответствующего алгоритма из библиотеки алгоритмов, наименование которого настраивается для каждой услуги (сервиса). 70.1.3. Должна быть предусмотрена возможность разработки новых алгоритмов и включение их в библиотеку алгоритмов силами обученных пользователей Системы Заказчика. 70.1.4. По завершении автоматического внесения информации в интегрированном хранилище для данного запроса должны быть установлены дата и время автоматического внесения изменений на основе полученных сведений, признак завершения отработки запроса, а также вид операции – «Автоматическое внесение информации». 70.1.5. Должно быть предусмотрено обязательное протоколирование выполнения указанной процедуры. Протоколированию подлежит также факт невыполнения автоматической операции в связи с отсутствием имени алгоритма, выполняющего соответствующее действие. 70.1.6. Автоматическое внесение сведений может быть отключено настройками подсистемы (такая настройка должна быть предусмотрена индивидуально для каждого типа объектов учета, а также сервиса/услуги). В случае, если автоматическое внесение изменений отключено, должна быть предусмотрена возможность ручного запуска средств автоматического внесения изменений из окна просмотра результатов запроса. Факт ручного запуска средств автоматического внесения информации должен быть внесен в протокол - Соответствие - - Значение характеристики не может изменяться участником закупки - 56. Интегрированное хранилище данных в составе единой базы данных Системы: 56.1. Интегрированное хранилище данных должно быть предназначено для обеспечения хранения взаимосвязанной между собой информации подсистемы в составе единой базы данных Системы. 56.2.Интегрированное хранилище данных должно обеспечивать хранение информации без дублирования, повторного внесения информации, которая уже содержится в единой базе данных Системы. 56.3. Интегрированное хранилище должно содержать ссылки на объекты, субъекты и договоры единой базы данных Системы. 56.4. Интегрированное хранилище должно обеспечивать хранение в единой базе данных Системы следующей информации: 56.4.1. Нормативно-справочная информация подсистемы (содержимое справочников и классификаторов, использующихся в подсистеме). 56.4.2. Информацию о настройках функционирования подсистемы. 56.4.3. Информация по сформированным запросам, полученным в ходе запросов сведениям. 56.4.4. Протоколы всех действий, выполняемых средствами подсистемы в автоматическом, полуавтоматическом и ручном режимах. 56.4.5. По каждому запросу должна быть размещена следующая информация: 56.4.5.1. Идентификатор вида сведений версии 3.х. 56.4.5.2. Вид операции из соответствующего классификатора (ручной, из карточки объекта Системы, из массовой операции, регламентная операция, на основе результатов, полученных из других источников), для массовой и регламентной операции – идентификатор операции. 56.4.5.3. Дата и время формирования запроса, идентификатор пользователя (если операция инициирована пользователем). 56.4.5.4. Информация, переданная в систему СМЭВ в ходе формирования запроса. 56.4.5.5. Идентификатор запроса, присвоенный системой СМЭВ. 56.4.5.6. Идентификатор карточки Системы, из которой (для которой) сформирован запрос - Соответствие - - Значение характеристики не может изменяться участником закупки - 56.4.5.7. Идентификаторы объекта (помещение или земельный участок), субъекта (юридическое или физическое лицо, ИП), договора, по которым сформирован запрос. Заполняются те идентификаторы, которые применимы для конкретного вида запроса. Примечание. Например, запрос информации из ЕГРН для определения даты перехода права в ходе приватизации теоретически может быть сформирован как из договора приватизации, так и из объекта. В этом случае идентификаторы карточки Системы, из которой сформирован запрос, должны быть разные, но идентификатор объекта в обоих запросах должен быть один. Это должно потенциально позволить предотвратить повторные запросы на основе анализа идентификатора объекта. 56.4.5.8. Дата и время автоматического или полуавтоматического внесения информации, по полученным сведениям, в единую базу данных. 56.4.5.9. Режим внесения изменений (автоматический, полуавтоматический «мастер», ручной) – см. пункт «Интегрированные средства ведения нормативно-справочной информации». 56.4.5.10. Идентификатор пользователя, внесшего изменения в ручном или полуавтоматическом режиме – «мастер». 56.4.5.11. Признак отработки результатов запроса (да или нет). 56.4.5.12. Текущий статус (состояние) запроса в системе СМЭВ. 56.4.5.13. Дата и время изменения сведений запроса в системе СМЭВ (по данным СМЭВ). 56.4.5.14. Дата и время внесения изменений из системы СМЭВ (изменения статуса запроса). 56.4.5.15. Дату и время последнего успешного опроса системы СМЭВ по данному запросу. 56.4.5.16. Полную информация обо всех изменениях статусов (состояний) запросов, включая дату и время смены состояния, текстовое описание причины смены состояния, и другие сведения, полученные из системы СМЭВ в ходе информационного обмена - Соответствие - - Значение характеристики не может изменяться участником закупки - 71. Алгоритмы автоматического внесения изменений в единую БД Системы на основе полученных сведений: 71.1. Алгоритм автоматического внесения изменений в единую БД Системы на основе полученных сведений должен быть определен индивидуально для каждого типа объектов учета и каждого сервиса/услуги с возможностью его настройки. 71.2. Алгоритм должен функционировать по следующему принципу: 71.2.1. Если запрос был сформирован вручную, то на основе полученных сведений должен быть выполнен поиск соответствующего объекта в единой базе данных Системы, при успешном поиске запрос должен быть автоматически прикреплен к соответствующему объекту, соответствующее действие должно быть внесено в протокол. 71.2.2. Если найти объект не удалось, то в зависимости от настройки (такая настройка должна быть предусмотрена) подсистема автоматически создаст соответствующий объект в единой базе данных Системы и заполнит электронную карточку объекта сведениями, содержащимися в полученных данных. Соответствующие действия должны быть внесены в протокол. 71.2.3. Если получены сведения на запрос по объекту, который уже находится в базе данных Системы, то алгоритм опционально (такая настройка должна быть предусмотрена индивидуально для каждого типа объектов учета, сервиса/услуги и действия из перечисленного ниже списка) должен иметь возможность выполнить следующие действия: 71.2.3.1. Для каждого реквизита полученных сведений должна быть выполнена сверка с соответствующим реквизитом в электронной карточке соответствующего объекта учета. Возможны следующие варианты: 71.2.3.1.1. Если реквизит не заполнен, он подлежит заполнению на основе полученных сведений (должно настраиваться) - Соответствие - - Значение характеристики не может изменяться участником закупки - 71.2.3.1.2. Если реквизит заполнен, и он отличен от соответствующего реквизита в полученных сведениях, то в зависимости от настройки либо реквизит подлежит изменению (с протоколированием каждого действия), либо для запроса должно быть сформировано предупреждение (состояние запроса сменится на «Предупреждение») с внесением в текст предупреждения развернутой информации о выявленных различиях. 71.2.4. Информация о полученных сведениях должна быть занесена в документы по объекту учета (опционально). 71.3. Для выписок из Росреестра о правах на объекты имущества дополнительно (опционально) должны быть предусмотрены следующие возможности: 71.3.1. Сверка с единой БД Системы на предмет наличия объекта в реестре муниципальной собственности (если в Системы объект включен в реестр, а по данным Росреестра – нет или наоборот, то должно быть сформировано соответствующее предупреждение). 71.3.2. В случае, если в выписке обнаружена информация о регистрации права на объект имущества Системы, которое перешло новому владельцу на основании документов, фигурирующих в единой БД Системы (например, в ходе продажи или приватизации объекта), то опционально должна быть предусмотрена возможность автоматического исключения объекта из реестра муниципальной собственности датой, предшествующей дате регистрации объекта на нового собственника с автоматическим внесением информации о документе-основании исключения. 71.4. Автоматические изменения в соответствии с алгоритмами и настройками Системы могут быть инициированы пользователем вручную. В этом случае пользователь должен быть проинформирован о всех произведенных действиях подсистемы (открыт протокол соответствующих действий) с возможностью быстрого доступа (в один клик мыши) к карточке объекта учета для анализа и возможной корректировки соответствующих действий - Соответствие - - Значение характеристики не может изменяться участником закупки - 56.4.6. Информация, полученная в ходе исполнения межведомственного запроса должна быть представлена в структурированном виде и размещаться ее в реляционных структурах (таблицах) единой базы данных Системы. Информация должна быть представлена в виде, пригодном для формирования SQL-запросов с ее использованием. Должны быть предусмотрены средства заполнения данных в структурированном, реляционном виде на основе информации, размещенной в XML-файле полученного результата запроса. Хранение данных только в XML-файле результата запроса недопустимо. Полученную информацию необходимо вносить в интегрированное хранилище. 56.5. В интегрированном хранилище должны быть размещены протоколы всех действий, выполняемых средствами подсистемы в автоматическом, полуавтоматическом и ручном режимах, в том числе: 56.5.1. Протокол взаимодействия с подсистемой СМЭВ (формирование запроса, опросы с целью получения статуса запроса (пингование), загрузка результата в интегрированное хранилище, парсинг результата, размещение данных результата в реляционных таблицах). 56.5.2. Протокол применения результата к объектам базы данных (поиск объектов в базе данных для ручных запросов, автоматическое добавление объектов в базу данных по результатам запросов, внесение изменений в электронные карточки объектов учета на основе полученных данных (индивидуально для каждого выполненного изменения)). 56.6. Протоколы должны содержать следующую информацию: 56.6.1. Дата и время выполнения операции или действия. 56.6.2. Имя пользователя, инициировавшего операцию (если операцию инициировал пользователь). 56.6.3. Вид операции из соответствующего классификатора (ручной, из карточки объекта Системы, из массовой операции, регламентная операция, опрос (пингование) запроса в системе СМЭВ, получение события из системы СМЭВ), для массовой и регламентной операции – идентификатор операции - Соответствие - - Значение характеристики не может изменяться участником закупки - 56.6.4. Признак успешности выполнения операции из соответствующего классификатора (успешно, не успешно). 56.6.5. Выполненное действие (из соответствующего классификатора). 56.6.6. Данные, связанные с действием (в текстовом виде), например, при вводе кадастрового номера объекта на основе полученных данных – кадастровый номер. 56.6.7. Дополнительная текстовая информация (в случае ошибки – причина ошибки). 56.7. Интерфейс для работы пользователей с данными, размещенными в интегрированном хранилище, должен быть обеспечен непосредственно Системой с использованием экранных форм, разработанных по общим принципам, принятым для Системы, с использованием единого визуального стиля, оформления Системы - Соответствие - - Значение характеристики не может изменяться участником закупки - 57. Интегрированные средства ведения справочников и классификаторов: 57.1. Средства должны быть предназначены для управления работой со справочниками и классификаторами подсистемы и обеспечивать единое пространство справочной информации в процессе использования учетных данных и документов. 57.2. Средства должны обеспечивать выполнение функций: 57.2.1. Редактирование справочников и классификаторов. 57.2.2. Просмотр справочников и классификаторов - Соответствие - - Значение характеристики не может изменяться участником закупки - 72. Средства «закрытия» запросов: 72.1. Под «закрытием» запроса помечается возможность пометки запроса в качестве отработанного, то есть запроса, не требующего дальнейшего анализа или использования пользователем. 72.2. Должна быть предусмотрена возможность автоматического и ручного «закрытия» запросов. 72.3. Автоматическое «закрытие» запросов должно производиться по настройке (такая настройка должна быть предусмотрена индивидуально для каждого типа объектов учета и услуге/сервису) после успешного получения результатов запроса и автоматического успешного внесения изменений в единой базе данных Системы, предусмотренных соответствующим алгоритмом. Должна быть предусмотрена возможность отключения автоматического «закрытия» запросов индивидуально для каждого пользователя. 72.4. Ручное «закрытие» должно производится пользователем самостоятельно после изучения и/или использования результатов запроса. 72.5. «Закрытые» запросы не должно изыматься из единой базы данных Системы, последующий доступ к ним должен быть обеспечен по запросам пользователей. 72.6. По умолчанию для журнала запросов должна быть предусмотрена возможность отображения не закрытых запросов – см. требования к функционированию журнала запросов - Соответствие - - Значение характеристики не может изменяться участником закупки - 73. Средства работы с журналом межведомственных запросов: 73.1. Журнал запросов должен представлять собой список запросов, содержащий всю основную информацию по каждому запросу, а также средства открытия карточки запроса и выполнения основных действий над запросом. 73.2. Журнал запросов должен быть доступен в следующих режимах: 73.2.1. Из карточки объекта Системы – журнал размещается на вкладке «СМЭВ» карточки объекта и содержит все межведомственные запросы, которые были сформированы для данного объекта. 73.2.1. Из основного окна Системы для всех услуг/сервисов, а также индивидуально для каждого из сервисов/услуг в режиме отображения «моих» запросов. Под «моими» запросами понимаются запросы, сформированные текущим пользователем Системы. 73.2.2. Из основного окна Системы для всех услуг/сервисов, а также индивидуально для каждого из сервисов/услуг в режиме отображения всех запросов. 73.3. Для журнала межведомственных запросов должны быть предусмотрены средства поиска/фильтрации запросов в соответствии с требованиями к функционированию подсистемы поиска и анализа информации Системы: 73.3.1. Должны быть предусмотрены возможности поиска запросов по любым параметрам запроса, в том числе: 73.3.1.1. Сервис/услуга. 73.3.1.2. Код запроса. 73.3.1.3. Дата формирования запроса. 73.3.1.4. Состояние запроса (с возможностью множественного выбора из справочника состояний). 73.3.1.5. Статус запроса (текстовый статус сервисов межведомственного взаимодействия). 73.3.1.6. Сообщение протокола прохождения (выполнения) запроса. 73.3.1.7. Сообщения протокола применения результатов запроса (внесения изменений в базу Системы по результатам запроса). 73.3.1.8. Номер заявки. 73.3.1.9. GUID запроса в Системы. 73.3.1.10. Признак «закрытия» запроса. 73.3.1.11. Тип операции создания запроса (вручную, из карточки объекта, массовая операция, регламентная операция) – множественный выбор из справочника. 73.3.1.12. Источник операции создания запроса – множественный выбор из соответствующего справочника - Соответствие - - Значение характеристики не может изменяться участником закупки - 58. Средства настройки: 58.1. Подсистема должна обеспечивать максимально широкие возможности по настройке, изменению технологии работы подсистемы силами обученных пользователей Системы без привлечения программистов Исполнителя. 58.2. Должны быть предусмотрены следующие средства настройки, изменения технологии работы подсистемы силами обученных пользователей Системы: 58.2.1. Средства настройки перечня доступных сервисов и/или видов сведений для формирования межведомственных запросов в ручном режиме. 58.2.2. Средства настройки перечня доступных для каждого из типов объектов учета Системы сервисов и/или видов сведений. 58.2.3. Перечень регламентных операций для формирования запросов по расписанию, настройка расписания выполнения регламентных операций. 58.2.4. Средства/Алгоритмы чтения полученных в результате межведомственного запроса сведений и размещения их в реляционных субтаблицах интегрированного хранилища (единой базы данных Системы). 58.2.5. Средства/Алгоритмы внесения изменений в электронные карточки объектов учета на основе полученных данных. 58.2.6. Средства/Алгоритмы создания объектов учета, отсутствующих в базе данных, на основе сведений, содержащихся в полученных ответах. 58.2.7. Средства/Алгоритмы связи запросов, выполненных в ручном режиме, с объектами, которые уже есть в базе данных Системы на основе сведений, содержащихся в полученных ответах. 58.2.8. Средства/Алгоритмы автоматического «закрытия» межведомственных запросов после получения и использования (применения, внесения в базу данных) полученных сведений, возможность индивидуального отключения автоматического «закрытия» запросов. 58.2.9. Создание шаблонов автоматического частичного заполнения формы формирования ручного запроса - Соответствие - - Значение характеристики не может изменяться участником закупки - 59. Средства ручного формирования межведомственных запросов: 59.1. При ручном формировании запроса пользователь должен предварительно выбирать услугу (сервис), для которой формируется запрос. Выбор должен производиться из перечня услуг (сервисов), для которых доступно ручное формирование запроса. 59.2. В случае, если для некоторого сервиса/услуги предусмотрена возможность формирования запросов по нескольким вариантам параметров (например, по кадастровому номеру или адресу объекта), то должна быть предусмотрена возможность ввода параметров запроса для каждого варианта. 59.3. При проектировании должна быть предусмотрена возможность создания шаблонов автоматического заполнения одного или нескольких параметров запросов. 59.4. Должна быть предусмотрена возможность индивидуального создания шаблонов каждым пользователем. 59.5. Технология создания шаблонов должна быть реализована по следующему принципу – пользователь заполняет те параметры экранной формы ручного формирования запросов, которые должны быть включены в шаблон. Далее пользователь инициирует создание шаблона и вводит его наименование/описание. После этого шаблон автоматически появляется в списке доступных для данного пользователя шаблонов для данной услуги/сервиса. Для одного из шаблонов каждого сервиса/услуги должна быть предусмотрена возможность выбора шаблона по умолчанию. 59.6. Если для некоторого сервиса и/или вида сведений указан шаблон по умолчанию, то при ручном создании запроса соответствующего сервиса и/или вида сведений параметры запроса должны быть заполнены автоматически на основе данных шаблона по умолчанию. 59.7. Пользователь может выбрать любой доступный для данного сервиса/услуги шаблон, в этом случае соответствующие параметры из шаблона автоматически должны заполнять поля экранной формы ручного формирования запроса - Соответствие - - Значение характеристики не может изменяться участником закупки - 73.3.1.13. Пользователь, инициировавший запрос. 73.3.1.14. Дата последнего изменения информации. 73.3.1.15. Код регламентной операции. 73.3.1.16. Дата получения результата. 73.3.1.17. Дата загрузки результата. 73.3.1.17. Дата применения результата. 73.3.1.19. Тип операции применения результата – из соответствующего справочника. 73.3.1.20. Источник операции применения результата – из соответствующего справочника. 73.3.1.21. Пользователь, применивший результат. 73.3.1.22. Признак автоматического создания запроса при ручной загрузке результата, полученного из внешних источников. 73.3.1.23. Признак необходимости ручной загрузки результатов запроса. 73.3.1.24. Признак необходимости ручного применения результатов. 73.3.1.25. Признак включения в план повторных запросов. 73.3.2. Должны быть предусмотрена возможность поиска запросов по любым параметрам объектов единой базы данных Системы с использованием экранных форм поиска/фильтрации объектов, предусмотренных для соответствующих объектов в Системы. 73.3.3. Должны быть предусмотрена возможность просмотра/корректировки (для администратора) SQL-запроса на выборку запросов в соответствии с параметрами поиска. 73.3.4. Должны быть предусмотрен фильтр по умолчанию на отображение запросов, требующих внимания пользователей, то есть запрос не «закрыт» и результат получен (состояние запроса – «Успех, «Предупреждение» или «Ошибка») - Соответствие - - Значение характеристики не может изменяться участником закупки - 74. Средства работы с карточкой межведомственного запроса: 74.1. Карточка межведомственного запроса должна открываться из журнала запросов в любом из режимов его отображения и содержать следующую информацию/средства управления: 74.1. 1. Основную информацию по запросу: 74.1. 1.1. Код запроса. 74.1. 1.2. Текущее состояние запроса. 74.1. 1.3. Текстовый статус запроса. 74.1. 1.4. Дата и время формирования запроса. 74.1. 1.5. Пользователь, сформировавший запрос. 74.1. 1.6. Дата и время получения результата запроса. 74.1. 1.7. Информация по объекту Системы, связанного с данным запросом. 74.1. 1.8. Сведения о загрузке результата в базу данных. 74.1. 1.9. Сведения о применении результата (внесении изменений в базу данных). 74.1. 2. Средства просмотра протоколов работы с запросом. 74.1. 3. Средства просмотра файлов, полученных в результате запроса (в разархивированном виде). 74.1. 4. Средства выгрузки файлов результатов запроса на внешний носитель. 74.1. 5. Средства открытия файлов результатов запросов стандартными средствами операционной системы. 74.1. 6. Средства просмотра xml-файла результата запроса в виде документа (с применением соответствующих стилей отображения XML в оффлайн-режиме – без требования наличия сети интернет). 74.1. 7. Печать и выгрузка XML-файла в виде документа. 74.1. 8. Средства «Закрытия запроса». 74.1. 9. Средства ручного применения результатов запроса. 74.1. 10. Средства доступа к карточке объекта учета в Системе (в один клик). 74.1. 11. Средства загрузки результатов запроса (для запросов, требующих ручную загрузку результатов). 74.1. 12. Средства открытия запроса в системе СМЭВ - Соответствие - - Значение характеристики не может изменяться участником закупки - 75. Средства поиска объектов Системы по параметрам межведомственных запросов: 75.1. Для объектов базы данных Системы должны быть предусмотрены средства поиска объектов по параметрам межведомственных запросов. 75.2. Средства указания параметров поиска/фильтрации должны быть интегрированы непосредственно в стандартные окна поиска/фильтрации объектов Системы и должны быть размещены на отдельной вкладке «СМЭВ». 75.3. Средства поиска должны обладать следующими возможностями: 75.3.1. Поиск объектов по наличию или отсутствию межведомственных запросов указанного сервиса/услуги (если не указано, то для любых сервисов/услуг) в заданном диапазоне дат (если не указано, то на любую дату). 75.3.2. Поиск объектов по любым параметрам запросов с использованием формы поиска/фильтрации журнала межведомственных запросов - Соответствие - - Значение характеристики не может изменяться участником закупки - 59.8. После успешного формирования запроса пользователю должно быть выведено соответствующее сообщение с указанием кода сформированного запроса в журнале запросов. 59.9. Для запросов по кадастровому номеру или кадастровому кварталу должна быть предусмотрена возможность пакетного формирования ручных запросов на основе кадастровых номеров (или кварталов), определенных в текстовом файле (в столбик) – для каждого кадастрового номера (квартала) автоматически должен быть сформирован запрос. 59.10. Аналогичная возможность должна быть предусмотрена для запросов по ИНН, ОГРН и другим классификационным кодам юридических, физических лиц, индивидуальных предпринимателей - Соответствие - - Значение характеристики не может изменяться участником закупки - 77. Средства администрирования и разграничения прав пользователей: 77.1. Все операции подсистемы, которые могут быть инициированы пользователем, должны подлежать администрированию и разграничению прав доступа. 77.2. Администрированию должны подлежать: 77.2.1. Операции ручного формирования запросов – индивидуально для каждого вида услуги (сервиса) – по справочнику услуг (сервисов). 77.2.2. Операции формирования запросов из карточек объектов учета – индивидуально для каждого вида объекта и услуги (сервиса). 77.2.3. Операции формирования запросов в режиме массовой операции – индивидуально для каждого вида объекта в массовой операции и услуги (сервиса). 77.2.4. Операции ручной загрузки сведений, полученных из сторонних источников – индивидуально для каждого вида объекта и услуги (сервиса). 77.2.5. Операции ручного инициирования автоматического внесения изменений на основе полученных сведений – индивидуально для каждого вида объекта и услуги (сервиса). 6. Просмотр, печать, экспорт результатов, сформированных ранее запросов – индивидуально для каждого вида объекта и услуги (сервиса) - Соответствие - - Значение характеристики не может изменяться участником закупки - 78. Требования к подсистеме «Межведомственное электронное взаимодействие с ГИС ГМП»: 78.1. В рамках данного технического задания должны быть настроены адаптеры СМЭВ к следующим видам сведений Федерального Казначейства: 78.1.1. Предоставление необходимой для уплаты информации - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/dd08daa2-d9cd-11eb-87f2-6dd2d98a56b1. 78.1.2. Прием необходимой для уплаты информации (начисления) - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/dd0976e8-d9cd-11eb-87f2-6dd2d98a56b1. 78.1.3. Прием информации о погашении начисления - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/dd0928c6-d9cd-11eb-87f2-6dd2d98a56b1. 78.1.4. Предоставление информации об уплате - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/dd08daa3-d9cd-11eb-87f2-6dd2d98a56b1. 78.1.5. Прием информации о погашении начисления - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/dd0928c6-d9cd-11eb-87f2-6dd2d98a56b1. 78.2. Подсистема должна обеспечивать автоматический сбор и передачу информации по начислениям из Системы в Государственную информационную систему государственных и муниципальных платежей (ГИС ГМП) с использованием протоколов СМЭВ в форматах и порядке, утвержденных приказом Федерального казначейства от 12 мая 2017 г. N 11н «Об утверждении Порядка ведения Государственной информационной системы о государственных платежах». 78.3. Подсистема должна быть реализована в виде сервисов ОС, которые выполняют следующие функции: 78.3.1. Формирование и присвоение УИН (уникальный идентификатор) начислениям всех типов (в соответствии с методическими и форматными требованиями ГИС ГМП). 78.3.2. Автоматический сбор информации по начислениям, а также корректировкам и аннулированиям начислений из Системы. 78.3.3. Формирование сообщений в утверждённых форматах ГИС ГМП, заверение их электронной подписью (ЭП) и передача сообщений по протоколам СМЭВ, формирование протокола отправки и подтверждения получения из ГИС ГМП - Соответствие - - Значение характеристики не может изменяться участником закупки - 78.3.4. Анализ полученных ответов и создание необходимых записей/протоколов в БД Системы. 78.3.5. Автоматическое распределение поступлений, в которых указан корректный УИН, по договорам Системы. 78.3.6. Автоматическое квитирование начислений на основе информации о поступлениях в соответствующих договорах. 78.4. Подсистема должна автоматизировать работу оператора начислений, снять нагрузку по ручному формированию и отправке начислений в Федеральное казначейство, а также проверки статусов начислений. Вся работа должна осуществляться в стандартном интерфейсе Системы, средства взаимодействия должны функционировать полностью автоматически и не требовать дополнительных действий от пользователей Системы. 78.5.Должна быть предусмотрена возможность квитирования начислений с отсутствующим платежом (в соответствии с технологией квитирования, предусмотренной в ГИС ГМП). 78.6.Поступления по администрируемым кодам бюджетной классификации (КБК) поступают в журнал нераспределенных поступлений финансово-аналитической подсистемы из системы электронного бюджета Федерального Казначейства (ЭБ). 78.7. В Системе должна быть предусмотрена возможность выполнения автоматических операций по автоматическому распределению поступлений на договоры с привязкой к виду начисления. 78.8. В случае, если информация о поступлении содержит УИН начисления, эта информация должна использоваться для однозначного определения договора и вида начисления путем поиска по УИН и анализа информации о соответствующем начислении. Должно быть выполнено соответствующее развитие алгоритмов автоматического распределения поступлений по договорам и видам начислений финансово-аналитической подсистемы - Соответствие - - Значение характеристики не может изменяться участником закупки - 79.Требования к подсистеме «Межведомственное электронное взаимодействие с Росреестром»: 79.1. В рамках данного технического задания должен быть настроен адаптер СМЭВ к следующему виду сведений Росреестра: Прием обращений в ФГИС ЕГРН - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/dd0b99d3-d9cd-11eb-87f2-6dd2d98a56b1. 79.2. Подсистема должна решать следующие задачи: 79.2.1. Получение необходимой информации о земельных участках, объектах недвижимости. 79.2.2. Получение информации о правах субъектов на объекты недвижимости и земельные участки. 79.2.3. Получение информации Кадастровом паспорте, Кадастровом плане территории, Кадастровой выписке и иных документах. 79.2.4. Своевременное получение информации об изменениях состояния и прав собственности на объекты недвижимости. 79.2.5. Актуализация сведений, в том числе в массовом порядке, содержащихся в информационном фонде Системы из результатов запросов к сервису Росреестра. 79.3. Должны быть предоставлены средства получения следующих сведений из Росреестра: 79.3.1. Выписка из ЕГРН об объекте недвижимости. 79.3.2. Выписка из ЕГРН о переходе прав на объект недвижимости. 79.3.3. Справки о лицах, получивших сведения об объекте недвижимости за период. 79.3.4. Выписка из ЕГРН об основных характеристиках и зарегистрированных правах на объект недвижимости. 79.3.5. Выписка о правах отдельного лица на имевшиеся/имеющиеся у него объекты недвижимости. 79.3.6. Выписка о содержании правоустанавливающих документов. 79.3.7. Выписка о признании правообладателя недееспособным или ограниченно дееспособным. 79.3.8. Копия документа. 79.3.9. Выписка о дате получения органом регистрации прав заявления о государственном кадастровом учете и (или) государственной регистрации прав и прилагаемых к нему документов. 79.3.10. Выписки о кадастровой стоимости объекта недвижимости. 79.3.11. Кадастровый план территории. 79.3.12. Выписка по зонам - Соответствие - - Значение характеристики не может изменяться участником закупки - 80.4.2. Запрос сведений о перемене имени. 80.4.3. Запрос сведений о расторжении брака. 80.4.4. Запрос сведений о рождении. 80.4.5. Запрос сведений об установлении отцовства. 80.4.6. Запрос сведений о смерти - Соответствие - - Значение характеристики не может изменяться участником закупки - 80. Подсистема «Межведомственное электронное взаимодействие с ЗАГС»: 80.1. В рамках данного технического задания должны быть настроены адаптеры СМЭВ к следующим видам сведений органов записи актов гражданского состояния (далее - ЗАГС): 80.1.1. Сведения о заключении брака - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/637a056a-ff80-11eb-ba23-33408f10c8dc. 80.1.2. Сведения о перемене имени - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/637a0597-ff80-11eb-ba23-33408f10c8dc. 80.1.3. Сведения о расторжение брака - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/637a0564-ff80-11eb-ba23-33408f10c8dc. 80.1.4. Сведения о рождении - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/637a059f-ff80-11eb-ba23-33408f10c8dc. 80.1.5. Сведения об установлении отцовства - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/637a0594-ff80-11eb-ba23-33408f10c8dc. 80.1.6. Сведения о смерти - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/637a0579-ff80-11eb-ba23-33408f10c8dc. 80.2. Подсистема должна решать следующие задачи: 80.2.1. Получение информации о физических лицах в объеме сведений сервисов СМЭВ ПФР. 80.2.2. Актуализация сведений, содержащихся в информационном фонде Системы на основе полученных сведений. 80.3. После получения ответов на отправленные запросы Подсистема в автоматическом или автоматизированном режиме должна позволять: 80.3.1. Направлять уведомление о получении ответа пользователям на электронную почту. 80.3.2. Автоматически прикреплять полученные сведения к карточке соответствующего объекта учета, субъекта права в Системе. 80.3.3. Обеспечивать возможность в автоматизированном режиме формировать информацию, аналитические и статистические отчеты, запросы на основе полученных в результате межведомственных запросов сведений. 80.4. Должны быть предоставлены средства получения следующих сведений из ФНС: 80.4.1. Запрос сведений о заключении брака. 80.4.2. Запрос сведений о перемене имени. 80.4.3. Запрос сведений о расторжении брака - Соответствие - - Значение характеристики не может изменяться участником закупки - 52. Средства ведения журналов проверок, информации о ходе проведения проверок: 52.1. Доступ к журналам (реестрам) проверок должен быть организован из «дерева меню» основного окна Системы. 52.2. Средства работы с журналом проверок должны быть подключены к подсистеме поиска и аналитики Системы (обладать всему функциями указанной подсистемы), быть построены по общим принципам работы со списками объектов учета Системы, в том числе: 52.2.1. Обладать возможностями поиска проверок по любым параметрам или сочетаниям параметров проверок, включая возможности поиска проверок по любым параметрам субъектов проверок, объектов проверок, договоров, в отношении которых проводится проверка, а также по информации о претензионной и исковой деятельности, которая инициирована по результатам проверки. 52.2.2. Обладать возможностью настройки табличного представления списка проверок (управление видимостью и порядка следования колонок, добавление новых колонок без ограничения количества и методики формирования информации, размещенной в колонках, добавления колонок с цветовой индикацией, управление алгоритмами цветовой индикации в колонках и т.п.). 52.2.3. Обладать аналитическими возможностями – сортировки, группировки по любой колонке или набору колонок, подведению итогов по выборке целиком или по группам (сумма, количество и т.д.) - Соответствие - - Значение характеристики не может изменяться участником закупки - 52.3. В журнале (списке, реестре) проверок должны быть отражены все основные показатели из карточки проверки, показатели стадии проверок должны быть отражены для текущей стадии или последней стадии проверки для завершенных проверок. 52.4. В Подсистеме не должно быть ограничений по количеству журналов проверок. 52.5. Журналы могут быть разделены по группам: 52.5.1. Журналы проверок по объектам имущества. 52.5.2. Журналы проверок по земельным участкам. 52.6. Должен быть предусмотрен отдельный пункт меню (автоматический журнал) – «Напоминания». В случае деления журналов по группам должна быть предусмотрена возможность отображения пункта «Напоминания» в каждой из групп. 52.7.Журнал «Напоминания» должен содержать проверки, для которых подходит или нарушен срок предупредительного контроля для текущего сотрудника, который работает в Системе. Подробно функции напоминаний описаны ниже - Соответствие - - Значение характеристики не может изменяться участником закупки - 53. Электронная карточка проверки: 53.1. Электронная карточка проверки должна содержать следующую информацию: 53.1.1. Реестр (журнал) проверки. 53.1.2. Форма проверки (выездная, документарная и т.п.). 53.1.3. Состояние проверки (в плане, в процессе, завершена). 53.1.4. Год проверки. 53.1.5. Категория. 53.1.6. Цель. 53.1.7. Перечень органов или организаций соисполнителей. 53.1.8. Субъект проверки – ссылка на субъект единой БД Системы. 53.1.9. Даты планируемого и фактического начала. 53.1.10. Даты планируемого и фактического окончания. 53.1.11. Срок проведения по регламенту с возможностью настройки автоматического определения в соответствии с регламентом для данного журнала проверок. 53.1.12. Исчерпывающая информация о форме и дате отправки уведомления о начале проверки. 53.1.13. Перечень объектов проверки (ссылки на объекты единой БД Системы), перечень обнаруженных нарушений для каждого из объектов. 53.1.14. Информация об осмотре и вынесенном решении по результатам осмотра. 53.1.15. Этапы проведения проверок с настройкой последовательности и сроков в соответствии с регламентами, определенными для каждого журнала проверок, Подрядчик каждого этапа, ссылка на документы-основания для каждого этапа, результата этапа. 53.1.16. Перечень документов по проверке (с возможностью прикрепления файла документа). 53.1.17. Перечень претензий и\или исков по результатам проверки (ссылки на реестр исков претензионно-исковой подсистемы Системы). 53.1.18. Результат проверки, ссылка на документ-основания результата - Соответствие - - Значение характеристики не может изменяться участником закупки - 54. Средства предупредительного контроля за соблюдением регламента проведения проверок: 54.1. Должна быть предусмотрена возможность настройки регламентов выполнения проверок. 54.2. Регламент может определять: 54.2.1. Общий срок в днях для проверки (с настройкой рабочие\календарные дни). 54.2.2. Перечень и последовательность типовых этапов для каждого журнала. 54.2.3. Длительность для каждого этапа. 54.2.4. Варианты результата этапа. 54.2.5. Перечень настроек напоминаний для этапа – срок в днях с момента начала или до окончания этапа, роли пользователей, для которых формировать напоминания (Подрядчик, куратор), а также фиксированный перечень пользователей, для которых формировать напоминания (например, начальник отдела). 54.3. При наступлении события для напоминания соответствующие проверки должны быть отражены в журнале: 54.3.1. Во всплывающем окне при каждом входе пользователя в Систему. 54.3.2. В журнале «Напоминания» соответствующих пользователей. 54.4. Требования по развитию Системы для интеграции средств подсистемы: 54.4.1. В электронных карточках субъектов должна размещаться информация о списках проверок в отношении этих субъектов (план проверок, текущие и завершенные проверки). 54.4.2. В электронных карточках объектов имущества и земельных участков должна размещаться информация о списках проверок в отношении этих объектов (план проверок, текущие и завершенные проверки). 54.4.3. В электронных карточках претензий и исков должна размещаться информация о проверке, по результатам которой начата претензионная или исковая. 54.4.4. Должна быть организована возможность поиска субъектов, объектов, претензий и исков по всем параметрам проводимых в отношении них проверок (связанных проверок) - Соответствие - - Значение характеристики не может изменяться участником закупки - 54.5. Разграничение прав пользователей по доступу к журналам проверок, электронным карточкам проверок, операциям, производимых с проверками, ведение аудита и журнала действия пользователей должны обеспечиваться стандартными средствами подсистемы администрирования и разграничения прав пользователей Системы. 54.6. Подсистема должна быть подключена к подсистемам «Библиотека запросов» и «Генератор отчетов» Системы. Все функции соответствующих подсистем должны быть распространены на информацию Подсистемы - Соответствие - - Значение характеристики не может изменяться участником закупки - 55. Требования к подсистеме межведомственного электронного взаимодействия (платформа СМЭВ): 55.1. Подсистема должна автоматизировать межведомственное электронное взаимодействие органов управления муниципальной собственностью в части формирования межведомственных запросов по протоколам СМЭВ в отношении объектов учета, субъектов права и договоров, зарегистрированных в единой базе данных Системы, а также автоматизации внесения изменений в единую базу данных Системы на основе полученных сведений. 55.2. Подсистема должна решать следующие задачи: 55.2.1. Формирование межведомственных запросов в ручном режиме с любого рабочего места Системы (ручное заполнение информации по запросу). 55.2.2. Формирование межведомственных запросов непосредственно из карточки объекта учета, субъекта права или договора (автоматическое формирование запроса в «один клик»). 55.2.3. Формирование межведомственных запросов по вручную определенному пользователем перечню объектов учета, субъектов права или договоров в режиме массовой операции (полностью автоматическое формирование запросов без ограничения количества). 55.2.4. Автоматическое формирование межведомственных запросов по определенному перечню объектов учета, субъектов права или договоров в режиме регламентной операции (автоматически по расписанию без ограничения количества). Например, автоматическое формирование запроса на получение выписки из ЕГРН через месяц после подписания договора приватизации с целью определения даты перехода права на приватизированный объект (даты регистрации права собственности на нового собственника и исключения объекта из муниципальной доли). 55.3. После получения ответов на отправленные запросы подсистема в автоматическом или автоматизированном режиме должна позволять: 55.3.1. Обеспечивать возможность автоматического и автоматизированного (автоматического по требованию пользователя) внесения изменений в единую базу данных Системы на основе полученных сведений. - Соответствие - - Значение характеристики не может изменяться участником закупки - 55.3.2. Автоматически прикреплять полученные сведения к карточке соответствующего объекта учета, субъекта права или договора в базе Системы с обеспечением возможности автоматизированного внесения изменений в карточку объекта учета, субъекта права или договора на основе этих сведений. 55.3.3. Обеспечивать возможность в автоматизированном режиме формировать информацию, аналитические и статистические отчеты, запросы на основе полученных в результате межведомственных запросов сведений, например, формировать уведомления о необходимости регистрации права собственности на приобретаемые в собственность объекты муниципальной собственности (покупке, приватизация) лицам или организациям, нарушившим сроки регистрации. 55.4. Функции подсистемы должны быть использованы для автоматизации выполнения следующих задач: 55.4.1. Определения даты исключения объекта из муниципальной собственности в ходе продажи/приватизации объекта. 55.4.2. Определения периода нахождения объекта в муниципальной казне, обеспечения корректного бюджетного учета движения объектов в казне. 55.4.3. Определения даты расторжения договоров аренды на объекты муниципальной собственности в ходе выкупа из аренды. 55.4.4. Определения даты передачи муниципальной собственности на праве оперативного управления или хозяйственного ведения. 55.4.5. Уточнения сведений по объектам муниципальной собственности, подлежащим продаже, приватизации, наложению других обременений и/или вещных прав. 55.4.6. Уточнения площадных, стоимостных и других характеристик объектов муниципальной собственности. 55.4.7. Уточнение сведений по зарегистрированным правам на объекты муниципальной собственности. 55.4.8. Определения периода оплаты взносов на капитальный ремонт объектов муниципальной собственности, расположенных в многоквартирных жилых домах, включенных в программу капитального ремонта - Соответствие - - Значение характеристики не может изменяться участником закупки - 55.5. Общей целью подсистемы должно быть обеспечение полноты и актуальности информации по объектам муниципальной собственности, земельным участкам, право собственности на которые не разграничено, вне-реестровым объектам учета, субъектам права, договорам и другим правам на объекты, подлежащие учету в рамках единого информационного фонда Системы. 55.6. Для достижения поставленных целей подсистема должна обеспечить получение информации от участников межведомственного электронного взаимодействия путем формирования запросов в соответствии с установленными методическими рекомендациям, размещенными на портале https:/info.gosuslugi.ru 55.7. Подсистема должна обеспечить: 55.7.1. Своевременное получение информации об изменении состава и/или содержания зарегистрированных на объекты учета прав, актуализацию соответствующих сведений в единой базе данных. 55.7.2. Своевременное проведение процедур, связанных с изменением информации по объектам учета, субъектам права и зарегистрированным правам. 55.7.3. Обеспечение полноты и качества ведения бюджетного учета движения объектов в муниципальной казне на основе актуальной информации по датам перехода права собственности на объекты учета, прав оперативного управления и хозяйственного ведения. 55.7.4. Обеспечение полноты и качества администрирования поступлений по администрируемым кодам бюджетной классификации на основе актуальной информации о регистрации договорных отношений. 55.7.5. Контроль за расходованием бюджетных средств на обслуживание объектов муниципальной собственности, включая оплату взносов на капитальный ремонт и др. 55.8. В составе подсистемы должны быть реализованы следующие средства: 55.8.1. Интегрированное хранилище данных в составе единой базы данных Системы. 55.8.2. Интегрированные средства ведения справочников и классификаторов. 55.8.3. Средства настройки. 55.8.4. Средства ручного формирования межведомственных запросов - Соответствие - - Значение характеристики не может изменяться участником закупки - 55.8.5. Средства формирования межведомственных запросов из карточки объекта Системы. 55.8.6. Средства формирования межведомственных запросов в режиме массовой операции. 55.8.7. Средства формирования межведомственных запросов в режиме регламентной операции. 55.8.8. Средства подписания запросов электронной подписью. 55.8.9. Средства ручного внесения результатов запросов, которые не формировались средствами подсистемы. 55.8.10. Средства предотвращения повторного формирования запросов 55.8.11. Средства опроса системы СМЭВ на предмет уточнения состояния запроса. 55.8.12. Средства загрузки полученных сведений в интегрированной хранилище данных. 55.8.13. Средства автоматического внесения изменений в единую БД Системы на основе полученных сведений. 55.8.14. Алгоритмы автоматического внесения изменений в единую БД Системы на основе полученных сведений. 55.8.15. Средства «закрытия» запросов. 55.8.16. Средства работы с журналом межведомственных запросов. 55.8.17. Средства работы с карточкой межведомственного запроса. 55.8.17. Средства поиска объектов Системы по параметрам межведомственных запросов. 55.8.19. Средства просмотра протоколов выполнения операций. 55.8.20. Средства администрирования и разграничения прав пользователей - Соответствие - - Значение характеристики не может изменяться участником закупки - 43. Средства ведения реестра специализированного жилого фонда: 43.1. Для объектов жилого фонда (квартир и комнат) будет предусмотрен признак отнесения данного объекта к специализированному жилому фонду. 43.2. Для каждого объекта будет указана категория (тип) специализированного жилого фонда: 43.2.1. Служебное жилье. 43.2.2. Маневренный фонд. 43.2.3. Жилые помещения в общежитиях. 43.2.4. Жилые помещения в домах системы социального обслуживания населения. 43.2.5. Жилые помещения для социальной защиты отдельных категорий граждан. 43.2.6. Жилые помещения для детей сирот и детей, оставшихся без попечения родителей, лиц из числа детей сирот и детей, оставшихся без попечения родителей. 43.3. Должна быть предусмотрена возможность расширения или изменения перечня категорий (типов) специализированного жилого фонда (классификатор категорий/типов). 43.4. При отнесении объекта жилого фонда к реестру специализированного жилого фонда может быть указано произвольное количество документов-оснований. 43.5. Должна быть предусмотрена возможность указания периода принадлежности объекта к специализированному жилому фонду. 43.6. В периоде нахождения объекта в реестре специализированного жилого фонда допускается только заключение договоров специализированного найма. Требования к ведению договоров специализированного найма приведены ниже. 43.7. При формировании договора приватизации или социального найма квартиры или комнаты, принадлежащей к реестру специализированного жилого фонда, будет отображено сообщение предупреждение. Операции актуализации таких договоров должны быть заблокированы (включая средства актуализации с использованием массовых операций) - Соответствие - - Значение характеристики не может изменяться участником закупки - 44. Средства управления договорами мены и выкупа аварийного жилья: 44.1. Средства управления договорами мены и выкупа аварийного жилья должны быть построены на основе стандартных средств Системы управления договорами на объекты имущества других типов (аренда, продажа). 44.2. Формирование договоров мены и выкупа аварийного жилья допускается только на объекты, не входящие в реестр муниципальной собственности. 44.3. Средства управления договорами мены дополнительно должны обеспечивать возможность указания перечня объектов, из которых производится переселение (квартир и комнат многоквартирного жилого дома), а также перечня объектов, в которые производится переселение. 44.4. Для договоров мены и выкупа аварийных помещений будет предусмотрена возможность ввода нескольких субъектов договора (собственников) с указанием доли каждого из собственников. Доля вводится в виде простой дроби (числитель и знаменатель). Суммарная доля собственников не будет превышать 100%. 44.5. Средства ввода суммы договора будет предусмотрено только для договоров выкупа - Соответствие - - Значение характеристики не может изменяться участником закупки - 45. Средства управления договорами социального и специализированного найма: 45.1. Средства управления договорами социального и специализированного найма будут построены на основе стандартных средств Системы управления договорами аренды объектов недвижимого имущества. 45.2. Формирование договоров социального и специализированного найма допускается только на объекты, находящиеся в реестре муниципальной собственности. 45.3. Заключение договора социального найма возможно только на объекты, не входящие в реестр объектов специализированного жилого фонда. При создании договора социального найма на объекты специализированного жилого фонда будет выводиться сообщение предупреждение, актуализация такого договора будет блокироваться. 45.4. Заключение договора социального найма возможно только на объекты, входящие в реестр объектов специализированного жилого фонда. При создании договора специализированного найма на объекты, не входящие в реестр специализированного жилого фонда, будет выводиться сообщение предупреждение, актуализация такого договора будет блокироваться. 45.5. При переселении нанимателей из аварийного жилого фонда для договоров социального и специализированного найма кроме перечня объектов, на которые заключается договор, будет предусмотрен перечень объектов, из которых производится переселение (аналогично соответствующим средствам договоров мены – см. выше). 45.6. Для договоров социального и специализированного найма должны быть подключены все возможности финансово-аналитической подсистемы Системы и подсистемы бюджетного учета доходов по администрируемым кодам бюджетной классификации - Соответствие - - Значение характеристики не может изменяться участником закупки - 46. Средства управления договорами социального и специализированного найма: 46.1. Средства управления договорами социального и специализированного найма должны быть построены на основе стандартных средств Системы управления договорами аренды объектов недвижимого имущества. 46.2. Формирование договоров социального и специализированного найма допускается только на объекты, находящиеся в реестре муниципальной собственности. 46.3. Заключение договора социального найма возможно только на объекты, не входящие в реестр объектов специализированного жилого фонда. При создании договора социального найма на объекты специализированного жилого фонда будет выводиться сообщение предупреждение, актуализация такого договора будет блокироваться. 46.4. Заключение договора социального найма возможно только на объекты, входящие в реестр объектов специализированного жилого фонда. При создании договора специализированного найма на объекты, не входящие в реестр специализированного жилого фонда, будет выводиться сообщение предупреждение, актуализация такого договора будет блокироваться. 46.5. При переселении нанимателей из аварийного жилого фонда для договоров социального и специализированного найма кроме перечня объектов, на которые заключается договор, будет предусмотрен перечень объектов, из которых производится переселение (аналогично соответствующим средствам договоров мены – см. выше). 46.6. Для договоров социального и специализированного найма должны быть подключены все возможности финансово-аналитической подсистемы Системы и подсистемы бюджетного учета доходов по администрируемым кодам бюджетной классификации - Соответствие - - Значение характеристики не может изменяться участником закупки - 49.1.7. Организация пообъектной сверки с региональным оператором управления взносами на капитальный ремонт или ТСЖ по суммам начисления взносов, перерасчетам. 49.1.8. Организации надлежащего контроля за расходованием бюджетных средств - Соответствие - - Значение характеристики не может изменяться участником закупки - 50.3.3. В Подсистеме должен быть расширен перечень справочников и классификаторов Системы за счёт добавления новых видов справочников и классификаторов, используемых Подсистемой - Соответствие - - Значение характеристики не может изменяться участником закупки - 47. Средства управления договорами социального и специализированного найма: 47.1. Средства управления договорами социального и специализированного найма должны быть построены на основе стандартных средств Системы управления договорами аренды объектов недвижимого имущества. 47.2. Формирование договоров социального и специализированного найма допускается только на объекты, находящиеся в реестре муниципальной собственности. 47.3. Заключение договора социального найма возможно только на объекты, не входящие в реестр объектов специализированного жилого фонда. При создании договора социального найма на объекты специализированного жилого фонда будет выводиться сообщение предупреждение, актуализация такого договора будет блокироваться. 47.4. Заключение договора социального найма возможно только на объекты, входящие в реестр объектов специализированного жилого фонда. При создании договора специализированного найма на объекты, не входящие в реестр специализированного жилого фонда, будет выводиться сообщение предупреждение, актуализация такого договора будет блокироваться. 47.5. При переселении нанимателей из аварийного жилого фонда для договоров социального и специализированного найма кроме перечня объектов, на которые заключается договор, будет предусмотрен перечень объектов, из которых производится переселение (аналогично соответствующим средствам договоров мены – см. выше). 47.6. Для договоров социального и специализированного найма должны быть подключены все возможности финансово-аналитической подсистемы Системы и подсистемы бюджетного учета доходов по администрируемым кодам бюджетной классификации - Соответствие - - Значение характеристики не может изменяться участником закупки - 48. Средства автоматизации работы с управляющими компаниями: 48.1. В карточке многоквартирного жилого дома должна быть предусмотрена возможность ввода информации по управляющей компании. Карточка управляющей компании должна заводиться в стандартном реестре юридических лиц субъектов права Системы. 48.2. Информация по управляющей компании многоквартирного жилого дома должна вводиться путем указания ссылки на карточку управляющей компании средствами работы с субъектами права многоквартирного жилого дома. Предусматривается ведение истории изменения управляющих компаний дома (дата начала и дата окончания), а также перечень ссылок на документы основания (протокол собрания жильцов, договор с управляющей компанией и любые другие документы) с возможностью прикрепления файлов документов. 48.3. На этапе, когда договор с управляющей компанией еще не подписан, однако имеется протокол жильцов с положительным решением о заключении договора с управляющей компанией, должна быть предусмотрена возможность ввода информации по управляющей компании с типом субъекта права «Управляющая компания намерение», при заключении договора с управляющей компанией тип субъекта права будет сменен на «Управляющая компания». 48.4. Информация об управляющей компании должна заноситься только в карточку многоквартирного жилого фонда, однако отображаться будет в карточках всех квартир и комнат данного многоквартирного дома (включая документы основания управляющей компании без возможности корректировки). 48.5. Информация по управляющей компании (наименование) должна отображаться в реестре объектов жилого фонда всех типов (здание, квартира, комната), а также на основной вкладке карточки объектов жилого фонда всех типов - Соответствие - - Значение характеристики не может изменяться участником закупки - 49. Требования к подсистеме «Управление взносами на капитальный ремонт»: 49.1. Подсистема «Управление взносами на капитальный ремонт» жилых и нежилых помещений, находящихся в муниципальной собственности и расположенных в многоквартирных жилых домах, включенных в программу капитального ремонта, должен автоматизировать решение следующих задач: 49.1.1. Ведение реестра многоквартирных жилых домов, включенных в программу капитального ремонта. 49.1.2. Формирования перечня жилых (квартир и комнат) и нежилых помещений, по которым подлежит уплата взносов. 49.1.3. Периодическая (ежемесячная) выгрузка изменений (с момента последней успешной выгрузки) для передачи в адрес регионального оператора управления взносами на капитальный ремонт: 49.1.3.1. Сведения об объектах, включенных в реестр муниципальной собственности, или объектов с изменившейся датой включения — с указанием даты и документа-основания включения. 49.1.3.2. Сведения об объектах, исключенных из реестра муниципальной собственности, или объектов с изменившейся датой исключения — с указанием даты и документа-основания исключения. 49.1.3.3. Сведения об объектах с изменившейся площадью — с указанием новой площади. 49.1.3.4. Сведения об объектах с изменившимся адресом — с указанием нового адреса. 49.1.4. Пообъектное начисление взносов с учетом дат включения объектов в собственность (казну), исключения объекта из собственности (казны), автоматическое формирование перерасчетов при внесении изменений в реестр муниципальной собственности. 49.1.5. Учет сумм оплат взносов, распределение суммы оплаты по объектам, учет списаний при выбытии объектов или проведении капитального ремонта. 49.1.6. Организация пообъектного бюджетного учета всех финансовых операций в соответствии с требованиями письма Министерства финансов Российской Федерации от 10.08.2015 № 02-07-07/46003 «Об отражении в бухгалтерском учете операций по перечислению взносов на капитальный ремонт в фонд капитального ремонта» - Соответствие - - Значение характеристики не может изменяться участником закупки - 50. Требования к подсистеме «Ведение проверок использования имущества и земельных участков»: 50.1. В составе подсистемы должны быть следующие средства: 50.1.1. Интегрированное хранилище данных в составе единой базы данных Системы. 50.1.2. Интегрированные средства ведения справочников и классификаторов в составе подсистемы ведения нормативно-справочной информации Системы. 50.1.3. Средства формирования плана проверок. 50.1.4. Средства ведения журналов (реестров) проверок, информации о ходе проведения проверок. 50.1.5. Средства предупредительного контроля за соблюдением регламента проведения проверок. 50.2. Интегрированное хранилище данных: 50.2.1. Интегрированное хранилище данных предназначено для обеспечения хранения взаимосвязанной между собой информации подсистемы в составе единой базы данных Системы. 50.2.2. Интегрированное хранилище данных должно обеспечивать хранение информации без дублирования, повторного внесения информации, которая уже содержится в единой базе данных Системы. 50.2.3. Интегрированное хранилище подсистемы должно содержать ссылки на объекты, субъекты, договоры, претензии и иски, информация о которых размещена в единой базе данных Системы. 50.2.4. Информация, которой оперирует Подсистема должна быть в полном составе размещена в единой базе данных Системы. 50.3 Интегрированные средства ведения справочников и классификаторов: 50.3.1. Ведение справочников и Классификаторов Подсистемы должно выполняться средствами Подсистемы управления нормативно-справочной информацией Системы, внешний вид экранных форм, а также функции по управлению справочниками и классификаторами Подсистемы должны быть аналогичными соответствующим элементам подсистемы управления нормативно-справочной информацией Системы. 50.3.2. Средства должны обеспечивать выполнение функций: 50.3.2.1. Редактирование справочников и классификаторов. 50.3.2.2. Просмотр справочников и классификаторов. - Соответствие - - Значение характеристики не может изменяться участником закупки - 51. Средства формирования плана проверок: 51.1. В подсистеме должны быть предусмотрены возможности формирования планов проверок на будущие отчетные периоды (года) в разрезе каждого из видов проверок (журналов проверок – см. ниже). 51.2. Для плана проверок должна быть предусмотрена возможность указания периода (года) плана проверок, а также перечня субъектов\объектов, подлежащих проверке в плановом порядке. 51.3. По каждому субъекту должна быть предусмотрена возможность указания планового периода проверки, а также возможность указания перечня объектов или договоров, подлежащих проверке в рамках плана. 51.4. Для плана проверок должны быть предусмотрены функции и средства работы с журналами проверок (списками или реестрами проверок), а также средства аналитики, поиска фильтрации и т.д., описанные ниже - Соответствие - - Значение характеристики не может изменяться участником закупки - 42. Требования к структуре и функционированию подсистемы «Управление объектами жилого фонда»: 42.1. В составе Подсистемы должны присутствовать следующие средства: 42.1.1. Средства ведения реестра жилых зданий, муниципальных и не муниципальных жилых квартир и комнат. 42.1.2. Средства ведения реестра специализированного жилого фонда. 42.1.3. Средства ведения информации по аварийным многоквартирным жилым домам. 42.1.4. Средства управления договорами мены и выкупа аварийного жилого фонда. 42.1.5. Средства управления договорами социального и специализированного найма. 42.1.6. Средства автоматизации работы с управляющими компаниями. 42.2. Средства должны обеспечивать формирование следующих реестров (списков) объектов учета: 42.2.1. Реестр (список) жилых домов, включая многоквартирные жилые дома. 42.2.2. Реестр (список) квартир, находящихся в многоквартирных жилых домах с обязательной привязкой к соответствующему дому. 42.2.3. Реестр (список) комнат, находящихся в квартирах с обязательной привязкой к соответствующей квартире. 42.3 Средства также должны обеспечивать возможность отображения объектов жилого фонда всех типов (жилые здания, квартиры, комнаты) единым списком. 42.4. Средства должны обеспечивать возможность отображения единым списком всех учитываемых средствами Системы объектов (реестровые и внереестровые объекты учета), включая объекты жилого фонда всех типов - Соответствие - - Значение характеристики не может изменяться участником закупки - 42.5.Средства Подсистемы должны включать в себя средства управления квартирами и комнатами, включенными в реестр объектов муниципальной собственности. Должно быть обеспечено разграничение прав пользователей по доступу на изменение к реестровой информации объектов муниципальной собственности. 42.6. Интерфейсные и функциональные решения, используемые при ведении реестра объектов жилого фонда всех типов (жилые дома, квартиры, комнаты) должны быть полностью аналогичны соответствующим средствам, используемых в Системе для управления объектами других типов (средства работы с табличным представлением данных, поиска/фильтрации, карточки объекта, составу учитываемых атрибутов, возможностям по настройке для учета расширенного набора реквизитов любых типов). 42.7. Для жилых зданий дополнительно должны быть обеспечены возможности работы со следующими показателями: 42.7.1. Управляющая компания - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. Формируется как ссылка на карточку субъекта права, размещенную в общем реестре субъектов права. Возможно указание произвольного количества документов-оснований (протокол собрания жильцов, договор). Подробно требования к средствам работы с управляющими компаниями описаны ниже. 42.7.2. Признак аварийности – требования к средствам работы с аварийными жилыми домами приведены ниже. 42.7.3. Этажность - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.4. Общее количество квартир - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.5. Перечень жилых квартир, расположенных в многоквартирном жилом здании – список отображается на одной из вкладок карточки многоквартирного жилого дома с возможностью быстрого доступа (одно действия) к карточке любой из квартир (на просмотр, изменение, добавление или удаление информации) - Соответствие - - Значение характеристики не может изменяться участником закупки - 42.7.6. Количество муниципальных объектов (квартир и комнат) – формируется автоматически на основе анализа единой базы данных с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.7. Количество квартир в единой базе данных системы – формируется автоматически на основе анализа единой базы данных с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.8. Общая площадь - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. Является реестровым показателем для объектов муниципальной собственности. 42.7.9. Общая жилая площадь - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.10. Общая полезная площадь - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.11. Год постройки - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.12. Способ передачи в собственность (поквартирно и целиком) - показатель заносится вручную с отображением в реестре (списке). 42.7.13. Документы основания – информация по произвольному количеству документов-оснований любых типов с возможностью хранения файла документа. 42.8. Для жилых квартир дополнительно будут обеспечены возможности работы со следующими показателями: 42.8.1. Ссылка на карточку многоквартирного жилого дома с быстрым доступом к карточке дома. 42.8.2. Управляющая компания - показатель определяется автоматически из карточки жилого здания с отображением в реестре (списке) и на основной вкладке карточки. Требования к средствам работы с управляющими компаниями описаны ниже. - Соответствие - - Значение характеристики не может изменяться участником закупки - 42.8.3. Собственники - показатель заносится вручную для объектов, не включенных в реестр муниципальной собственности. Формируется как ссылка на карточку субъекта права, размещенную в общем реестре субъектов права. В случае, если собственников несколько, возможно указание доли в праве собственности. Возможно указание произвольного количества документов-оснований на право собственности. Ввод собственников обязателен в случае использования средств автоматизации решения задачи переселения из аварийных жилых домов. Подробнее требования к автоматизации задачи переселения описаны ниже. 42.8.4. Наниматели - показатель заносится вручную для объектов муниципальной собственности. Формируется как ссылка на карточку субъекта права, размещенную в общем реестре субъектов права. В случае, если нанимателей несколько, возможно указание доли. Возможно указание произвольного количества документов-оснований. Ввод нанимателей обязателен в случае использования средств автоматизации решения задачи переселения из аварийных жилых домов (допустим также ввод договоров социального или специализированного найма – в этом случае перечень нанимателей определяется автоматически). Подробнее требования к автоматизации задачи переселения описаны ниже. 42.8.5. Признак аварийности – устанавливается автоматически для всех квартир жилого дома, для которого установлен признак аварийности. Требования к средствам работы с аварийными жилыми домами приведены ниже. 42.8.6. Признак невозможности для проживания – устанавливается вручную с указанием документов оснований. 42.8.7. Признак принадлежности к специализированному жилому фонду – устанавливается вручную с указанием документов оснований. Требования к ведению реестра специализированного жилого фонда приведены ниже. 42.8.8. Этаж - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки. 42.8.9. Общее количество комнат - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке - Соответствие - - Значение характеристики не может изменяться участником закупки - 42.8.10. Перечень жилых комнат, расположенных в квартире – список отображается на одной из вкладок карточки квартиры с возможностью быстрого доступа (одно действие) к карточке любой из комнат (на просмотр, изменение, добавление или удаление информации). Перечень комнат как отдельных объектов учета ведется в случае, если собственники квартиры отличаются от собственников комнат (или комнаты имеют разных собственников), например, для случая коммунальных квартир, общежитий. 42.8.11. Количество муниципальных комнат – формируется автоматически на основе анализа единой базы данных с отображением в реестре (списке) и на основной вкладке карточки. 42.8.12. Количество комнат в единой базе данных системы – формируется автоматически на основе анализа единой базы данных с отображением в реестре (списке) и на основной вкладке карточки квартиры. 42.8.13. Общая площадь - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки. Является реестровым показателем для объектов муниципальной собственности. 42.8.14. Общая жилая площадь - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.8.15. Общая полезная площадь - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.8.16. Документы основания – информация по произвольному количеству документов-оснований любых типов с возможностью хранения файла документа. 42.9. Для жилых комнат дополнительно будут обеспечены возможности работы со следующими показателями: 42.9.1. Ссылка на карточку квартиры с быстрым доступом к карточке квартиры (одно или два действия). 42.9.2. Управляющая компания - показатель определяется автоматически из карточки жилого здания с отображением в реестре (списке) и на основной вкладке карточки. Подробно требования к средствам работы с управляющими компаниями описаны ниже - Соответствие - - Значение характеристики не может изменяться участником закупки - 14. Требования к подсистеме «Ведение информации по субъектам права»: 14.1. Подсистема должна обеспечивать ведение информации по муниципальным предприятиям и учреждениям (как реестровым объектам), а также по субъектам права, участвующих в имущественно-земельных отношениях (юридические, физические лица, индивидуальные предприниматели). 14.2. Подсистема должна автоматизировать выполнение следующих основных задач: 14.2.1. Пообъектный учет субъектов права. Для каждого из субъектов права ведется следующая основная информация: 14.2.1.1. Наименование субъекта права (полное и краткая информация, с историей изменения). 14.2.1.2. ИНН. 14.2.1.3. Принадлежность к реестру, подреестру (с историей изменения и ссылкой на документ-основание). 14.2.1.4. Реестровый номер (с историей изменения и ссылкой на документ-основание). 14.2.1.5. Адрес (с возможностью ввода множественного адреса), структура адреса должна соответствовать федеральным требованиям (ФИАС). Система должна обеспечивать возможность автоматизированного обновления классификаторов адресной подсистемы на основе ФИАС. 14.2.1.6. Организационная форма, вид деятельности, вид собственности (классификаторы) - Соответствие - - Значение характеристики не может изменяться участником закупки - 14.2.1.7. Контакты - руководитель, главный бухгалтер, другие сотрудники (произвольное количество), телефоны (произвольное количество), банковские реквизиты (с историей изменения), реквизиты трудовых договоров руководителя и главного бухгалтера с возможность загрузки в систему самих договоров и дополнительных соглашений к ним, а также реквизитов документов о назначении и увольнении руководителей с возможностью загрузки в систему указанных документов. 14.2.1.8. Информация по членам семьи, родственным отношениям (для физических лиц). 14.2.1.9. Паспортные данные (для физических лиц, индивидуальных предпринимателей) – с историей изменения, дата рождения. 14.2.1.10. Субъекты права (представители, учредители) – с историей изменения и ссылками на документы-основания, возможностью расширения в части регистрации произвольного количество субъектов права произвольного типа (любого вида права, с возможностью расширения). 14.2.1.11. Экономические показатели (балансовая, остаточная стоимость объектов на балансе, среднесписочная численность сотрудников, показатели эффективности) – с историей изменения и ссылками на документы-основания. Должна быть обеспечена возможность учета произвольного количества экономических показателей любого типа с возможностью расширения средствами системы. 14.2.1.12. Классификационные коды (ОКВЭД, ОКОНХ, ОГРН, КПП) – с ведением истории и ссылками на документы-основания, с возможностью расширения перечня учитываемых кодов без участия программистов. 14.2.1.13. Информация по документам (все документы, имеющие отношение к данному объекту с делением по направлениям воздействия документов (включение/исключение, внесение изменений, правоустанавливающие, регистрирующие документа)). Должна быть обеспечена возможность учета информации по произвольному количеству документов любого типа с возможностью расширения средствами системы. 14.2.1.14. Комиссии - Соответствие - - Значение характеристики не может изменяться участником закупки - 14.2.1.15. События (даты жизненного цикла объекта) с возможностью расширения количества и типов событий средствами системы. 14.2.1.16. Признаки (принадлежности к определенным учетным категориям, группам в соответствии с технологией учета) с возможностью расширений наименований признаков средствами системы. 14.2.1.17. Перечень объектов имущества на балансе и в пользовании. 14.2.1.18. Перечень земельных участков в землепользовании и в пользовании (аренда). 14.2.1.19. Перечень договоров всех типов для объектов имущества (аренда, купля/продажа, безвозмездное пользование, социальный найм). 14.2.1.20. Перечень договоров всех типов для земельных участков (аренда, купля/продажа, безвозмездное пользование). 14.2.1.21. Полная финансовая информация по всем видам договоров (начисления, платежи, задолженность). 14.2.1.22. Информация по банкротству. 14.2.1.23. Информация по претензионной и исковой деятельности (детальная информация по поданным претензиям и искам, включая необходимую классификационную и описательную части, предметы исков, в том числе суммы с делением по видам начислений, перечень этапов претензионной и исковой деятельности с указанием ссылок на документы этапа, уточнение требований) – см. Пункт «подсистема автоматизации претензионной и исковой деятельности». 14.2.2. Управление историей изменения основных данных по субъектам права, документами-основаниями на проведение изменений - Соответствие - - Значение характеристики не может изменяться участником закупки - 14.2.3. Управление движением субъектов права в реестре и списках учета (включение, исключение, перемещение между реестрами, ведение истории реорганизации объектов (слияния, разделения)), документами-основаниями, правоустанавливающими и другими документами. 14.2.4. Использование информации по субъектам права при формировании договоров, дополнительных соглашений, других документов, при формировании информации о других имущественно-земельных отношениях с участием соответствующих субъектов права. 14.2.5. Формирование аналитики по деятельности субъекта права в рамках имущественно-земельных отношений. 14.2.6. Формирование аналитики по задолженности, работа с должниками. 14.2.7. Возможность формирования аналитической отчетности в соответствующей сфере (с использованием встроенных средств генераторов отчетов). 14.2.8. Проведение экспресс-аналитики. 14.2.9. Управления предприятиями банкротами 14.2.9.1. В Системе должна быть реализована возможность управления информацией о предприятиях банкротах, а также процессах и стадиях банкротства. В рамках данной функции должна быть предусмотрена возможность ведения следующей информации: 14.2.9.1.1. Перечень стадий банкротства (внешнее наблюдение, конкурсное управление). 14.2.9.1.2. Информацию об управляющих компаниях и саморегулирующихся организациях. 14.2.9.1.3. Перечень заседаний руководства для обсуждения текущих вопросов. 14.2.9.1.4. Сведения о публикации сведений о банкротстве. 14.2.9.1.5. Реестр требований кредиторов для реструктуризации задолженности. 14.2.9.1.6. Информация о конкурсной массе на момент открытия конкурсного производства. 14.2.9.1.7. Периоды изменения всех вышеперечисленных атрибутов. 14.2.9.1.8. Информация о всех документах, связанных со всеми процессами банкротства, а также связи данных документов с теми атрибутами, на изменение которых они направлены - Соответствие - - Значение характеристики не может изменяться участником закупки - 41. Требования к подсистеме «Управление объектами жилого фонда» включая Подсистему :«Аварийное жилье» учет и управление: 41.1. Подсистема должна обеспечивать комплексную автоматизацию решения вопросов управления объектами жилого фонда, в том числе: 41.1.1. Ведение жилых зданий: 41.1.1.1. Ведение всех характеристик жилых зданий в рамках единой базы данных, в том числе: 41.1.1.1.1. Этажность. 41.1.1.1.2. Общее количество квартир. 41.1.1.1.3. Количество муниципальных объектов (квартир и комнат). 41.1.1.1.4. Количество квартир в единой базе данных системы. 41.1.1.1.5. Общая площадь. 41.1.1.1.6. Общая жилая площадь. 41.1.1.1.7. Общая полезная площадь. 41.1.1.1.8. Год постройки. 41.1.1.1.9. Способ передачи в собственность (поквартирно и целиком). 41.1.1.1.10. Документы основания. 41.1.1.2. Ведение полной информации о признании дома аварийным, этапам процесса расселения (включая средства автоматизации приобретения жилья для нужд расселения, заключения договоров мены и социального найма в процессе переселения) и ликвидации аварийных домов. 41.1.2. Ведение информации по управляющим компаниям, средства автоматизации работы с управляющими компаниями, в том числе: 41.1.3. Работа с протоколами общих собраний жильцов. 41.1.4. Заключение договоров с управляющими компаниями. 41.1.5. Ведение полной информации по управляющей компании. 6. Ведение реестра жилых квартир с привязкой к многоквартирным жилым домам: 41.1.6.1. Ведение всех характеристик муниципальных и немуниципальных квартир в рамках единой базы данных, в том числе: 41.1.6.1.1. Этаж. 41.1.6.1.2. Общее количество комнат. 41.1.6.1.3. Количество комнат в единой базе данных системы. 41.1.6.1.4. Общая площадь. 41.1.6.1.5. Общая жилая площадь. 41.1.6.1.6. Общая полезная площадь. 41.1.6.1.7. Документы основания - Соответствие - - Значение характеристики не может изменяться участником закупки - 41.1.6.2. Ведение информации по собственникам квартир, долям в праве собственности, документам основаниям, переходе и регистрации права собственности. 41.1.6.3. Ведение информации о непригодности квартиры для проживания, документам основаниям. 41.1.7. Ведение реестра жилых комнат с привязкой к жилым квартирам: 41.1.7.1. Ведение всех характеристик комнат в рамках единой базы данных. 41.1.7.2. Ведение информации по собственникам комнат, долям в праве собственности, ментам основаниям, переходе и регистрации права собственности. 41.1.7.3. Ведение информации о непригодности для проживания, документам основаниям. 41.1.8. Ведение реестра специализированного жилого фонда (служебное жилье, маневренный фонд). Включая: 41.1.8.1. Реестр специализированного жилищного фонда также будет расширен: 41.1.8.1.1. Служебные жилые помещения. 41.1.8.1.2. Жилые помещения в общежитиях. 41.1.8.1.3. Жилые помещения маневренного фонда. 41.1.8.1.4. Жилые помещения в домах системы социального обслуживания населения. 41.1.8.1.5. Жилые помещения для социальной защиты отдельных категорий граждан. 41.1.8.1.6. Жилые помещения для детей-сирот и детей, оставшихся без попечения родителей, лиц из числа детей-сирот и детей, оставшихся без попечения родителей. 41.1.9. Ведение информации по переводам жилого (нежилого) фонда в нежилой (жилой) фонд, автоматизация ведения процесса перевода, ведение информации по документам-основаниям, разрешениям, протоколам. 41.1.10. Заключение и управление договорами социального и специализированного найма 41.1.11. Автоматизация решения вопросов приватизации и продажи муниципальных и муниципальных жилых помещений, автоматизация процесса исключения приватизированных жилых помещений из муниципальной собственности. 41.1.12. Ведение информации о приобретении жилых помещений (квартир), в том числе для нужд переселения, автоматизация решения вопросов включения, приобретаемых для нужд переселения квартир в муниципальную собственность - Соответствие - - Значение характеристики не может изменяться участником закупки - 25. Требования к подсистеме «Автоматическое обновление клиентских рабочих мест»: 25.1. Подсистема «Автоматическое обновление клиентских рабочих мест» (далее – подсистема автообновления) должна быть построена по клиент-серверной архитектуре, обновления должны распространятся по сети с использованием протокола TCP/IP. 25.2. Подсистема автообновления должна состоять из следующих компонентов (программ): 25.2.1. «Служба обновления» – серверная часть подсистемы автообновления, устанавливаемая на компьютере – сервере. 25.2.2. «Конфигуратор службы обновления» – утилита по настройке службы обновления. 25.2.3. «Клиент обновления» – клиентская часть подсистемы автообновления, устанавливаемая на компьютере пользователя. 25.3. Подсистема автообновления должна обладать следующим функционалом: 25.3.1. Автоматическое обновление клиентов обновлений на компьютерах пользователей при установке новой версии системы обновлений. Служба должна предоставлять клиентским местам Системы актуальную версию клиента обновлений. Для каждой новой версии клиента обновлений должен генерироваться уникальный идентификатор обновления. 25.3.2. Автоматическое обновление клиентских мест Системы на компьютерах пользователей при наличии обновлений программы. Служба должна предоставлять клиентским местам Системы актуальные версии файлов программы. Для каждой новой версии программы должен генерироваться уникальный идентификатор обновления. 25.3.3. Автоматическое восстановление отсутствующих файлов клиентских мест Системы на компьютерах пользователей - Соответствие - - Значение характеристики не может изменяться участником закупки - 25.3.4. При обновлении клиентских мест должна поддерживаться работа со списком исключений для удаления с клиентских мест устаревших файлов и папок. 25.3.5. Возможность обновления клиентских мест Системы из нескольких источников. Количество источников не должно быть ограничено. Для каждого источника должна быть предусмотрена возможность задать имя, путь к папке с файлами обновлений, а также путь к файлу со списком исключений. 25.3.6. Возможность сжатия пересылаемых по сети пакетов для уменьшения нагрузки на сеть. Активация данного функционала должна происходить по решению администратора. 25.3.7. Возможность контроля целостности пересылаемых по сети пакетов для предотвращения модификации пересылаемых файлов сторонним ПО, вирусами и иными внешними факторами. Файлы должны приходить на компьютеры пользователей в неизменном виде. 25.4. Служба обновления: 25.4.1. Серверная часть подсистемы автообновления должна быть представлена в виде службы ОС (далее – Служба). Служба должна отвечать на запросы «Клиентов обновления» (далее – Клиентов), предоставляя им всю необходимую информацию об обновлениях, а также сами обновления. 25.4.1. Должна быть предусмотрена возможность запустить Службу как вручную, так и с помощью конфигуратора службы. Также Служба должна запускаться автоматически при включении компьютера и не требовать входа в Систему под учетной записью какого-либо пользователя. 25.4.2. Служба обновления должна применять новые настройки конфигурации автоматически, без необходимости перезапуска. - Соответствие - - Значение характеристики не может изменяться участником закупки - 25.4.3. Служба обновления должна автоматически отслеживать наличие новой версии клиента обновлений, а также отслеживать любые изменения в папках источников обновлений. При наличии новой версии клиента обновлений служба должна сгенерировать уникальный идентификатор обновления. Этот идентификатор должен передаваться клиентам обновления на клиентских местах при их подключении к службе обновлений. При наличии изменений в папках источников обновлений служба должна сгенерировать уникальный идентификатор обновления индивидуально для каждого источника обновлений. Этот идентификатор должен передаваться клиентам обновления на клиентских местах при их подключении к службе обновлений. 25.5. Конфигуратор службы обновления (далее – Конфигуратор).: 25.5.1. Конфигуратор не должен требовать установки и должен иметь возможность быть запущенным из любого места на компьютере, где установлена служба обновления. При запуске конфигуратор должен проверять наличие установленной службы и в случае её отсутствия, сообщить об этом пользователю. Если Служба установлена, то должно открываться окно Конфигуратора, на котором должны быть представлены текущие настройки Службы. 25.5.2. Конфигуратор должен обладать следующим фунционалом по настройке службы обновления: 25.5.2.1. Отслеживать текущее состояние Службы. 25.5.2.2. Иметь средства для остановки, запуска и перезапуска службы обновления. 25.5.2.3. Позволять указывать местоположение актуальной версии клиента обновления (которая совместима со службой обновления). 25.5.2.4. Позволять управлять (активация/деактивация) опцией по сжатию пакетов, передаваемых по сети (для уменьшения нагрузки на сеть) - Соответствие - - Значение характеристики не может изменяться участником закупки - 25.5.2.5. Позволять управлять (активация/деактивация) опцией по контролю целостности пакетов, передаваемых по сети (для предотвращения модификации содержимого пакетов внешними факторами). 25.5.2.6. Позволять добавлять новые источники обновлений (без ограничения по их количеству). 25.5.2.7. Позволять редактировать сведения об источниках обновлений. В частности, настраивать следующие параметры: 25.5.2.8. Задавать имя источника обновлений. 25.5.2.9. Указывать путь к папке с файлами обновлений. 25.5.2.10. Указывать путь к файлу исключений. 25.6. Клиент обновлений: 25.6.1. Клиентская часть подсистемы автообновления должна быть представлена в виде отдельной программы – клиента обновления. 25.6.2. Клиент обновления должен быть предназначен для соединения со службой обновления, расположенной на другом или текущем компьютере, и получения от неё актуальной версии файлов обновляемой программы, а также актуальной версии самого клиента обновления. 25.6.3. Клиент обновления не должен требовать специальной установки и может быть запущен из любого места. Клиент обновления должен обладать возможностью запуска в двух режимах: 25.6.3.1. «Режим настройки» - в этом режиме должно открываться окно настройки клиента обновления. 25.6.3.2. «Режим обновления» - в этом режиме программа должна выполнять соединение с сервером обновлений, согласно выполненной настройке, и получать от сервера обновлений актуальные версии файлов обновляемой программы и самого клиента. 25.6.4. Клиент обновления в «режиме настройки» должен предоставлять возможность задавать следующие настройки: 25.6.4.1. Настройки подключения к службе обновлений (IP-адрес или имя компьютера, на котором установлена служба обновлений, порт служба обновлений). Для проверки корректности настройки должна быть предусмотрена кнопка для тестирования соединения. - Соответствие - - Значение характеристики не может изменяться участником закупки - 25.6.4.2. В случае необходимости подключения к серверу через прокси-сервер, должна быть возможность в соответствующей группе настроек указать IP-адрес прокси-сервера, порт подключения к прокси-серверу, а также логин и пароль для авторизации на прокси-сервере (при необходимости). 25.6.4.3. Источник обновления. Выбор источника обновлений должен осуществляться из выпадающего списка, а котором должны присутствовать все доступные источники обновлений. 25.6.4.4. Путь к временной папке, в которую будут загружаться обновления перед их применением. 25.6.4.5. Путь к папке, в которую необходимо сохранить загруженные обновления. 25.6.4.6. Путь к файлу программы, которую необходимо запустить после обновления. Должна присутствовать возможность настроить запрет запуска нескольких экземпляров. 25.6.4.7. Индивидуальная для клиентского места настройка сжатия пакетов, передаваемых по сети. 25.6.4.8. Индивидуальная для клиентского места настройка контроля целостности пакетов, передаваемых по сети. 25.6.4.9. Настройка протоколирования процесса обновления. 25.6.4.10.Если ip-адрес и имя сервера обновления неизвестны, то должна быть реализована возможность автоматического поиска сервера в локальной сети. Для автоматического поиска сервера должна присутствовать кнопка «Поиск сервера». После успешного поиска, настройки подключения должны быть установлены автоматически, и пользователю должно быть показано соответствующее уведомление. 25.6.5. Клиент обновления в «режиме обновления» должен осуществлять следующие действия: 25.6.5.1. Проверять наличие новой версии клиента обновления. Для этого клиент обновления должен получить текущий идентификатор обновления клиента и сравнить с ранее сохраненным идентификатором. Если идентификаторы различаются, то клиент обновления должен произвести самообновление с сохранением текущего идентификатора обновления - Соответствие - - Значение характеристики не может изменяться участником закупки - 25.6.5.2. Проверить наличие обновлений клиентского места Системы. Для этого клиент обновления должен получить текущий идентификатор обновления клиентского места и сравнить с ранее сохраненным идентификатором. Если идентификаторы различаются, то клиент обновления должен произвести загрузку измененных и новых файлов с сохранением текущего идентификатора обновления. При загрузке обновлений должны загружаться только новые и изменение файлы (сверяться контрольные суммы файлов (CRC)). 25.6.5.3. При отсутствии обновлений клиентского места Системы клиент обновления должен проверить наличие отсутствующих файлов клиентского места Системы и при необходимости восстановить их. 25.6.5.4. По завершению работы клиент обновления должен произвести обработку файла исключений. Для этого клиент обновления должен получить содержимое файла исключений и удалить файлы и папки, согласно полученного списка. 25.6.6. Процесс обновления должен отображаться в виде окна, на котором должны быть размещены следующие элементы: 25.6.6.1. Текст сообщения с описанием текущего этапа обновления. 25.6.6.2. Индикатор прогресса обновления. Клиент обновления должен поддерживать возможность протоколирования процесса обновления в текстовом файле, который должен автоматически создаваться в папке клиента обновления - Соответствие - - Значение характеристики не может изменяться участником закупки - 22. Требования к подсистеме «Формирование отчетов и печатных форм, генератор отчетов»: 22.1. Подсистема должна предоставлять возможность формирования выходных данных системы – от простейших печатных карточек объектов учета до аналитических отчетов, выборок, прогнозов произвольной сложности по состоянию на произвольную дату в пределах информационного фонда Системы. 22.2. Подсистема не должна содержать ограничений на количество шаблонов отчетов и печатных форм. 22.3. В состав подсистемы должен входить генератор отчетов «FastReport» или эквивалент с помощью которого можно самостоятельно разрабатывать и подключать к Системе отчеты и печатные формы произвольной сложности, а также производить экспресс-изменения подключенных шаблонов. Кроме того, подсистема должна обладать возможностью подключения шаблонов отчетов и печатных форм, разработанных с помощью MS Word, MS Excel и OpenOffice (LibreOffice) или эквивалент с использованием API и VBA (или эквивалент). 22.4. Подсистема должна обеспечить формирование произвольного количества отчетов и печатных форм любой сложности в рамках информационного фонда Системы. 22.5. Для каждой печатной формы должна быть предусмотрена возможность выполнения произвольных действий (алгоритмов), выполняемых до и после формирования печатной формы. 22.6. Должна быть предусмотрена библиотека соответствующих алгоритмов с возможностью выбора ранее разработанного алгоритма для любой печатной формы любому пользователю, не обладающему какими-либо специальными знаниями - Соответствие - - Значение характеристики не может изменяться участником закупки - 22.7. Должна быть предусмотрена возможность добавления, изменения или удаления отчетов и печатных форм силами обученных пользователей Системы без необходимости обновления Системы или ее компонентов. 22.8. Средства ведения журналов сформированных документов (печатных форм): 22.8.1. В подсистеме формирования отчетов и печатных форм должна быть предусмотрена возможность реализации средств сохранения информации о формировании соответствующей печатной формы с привязкой к электронной карточке объектов учета, а также фиксированием информации о времени формирования и пользователе, который выполнял формирование. 22.8.2. Должна быть предусмотрена возможность вывода журналов сформированных ранее печатных форм заданного типа в заданный промежуток времени. 22.8.3. Должна быть предусмотрена возможность по необходимости добавления в печатную форму признака необходимости включения факта формирования печатной формы в журнал. 22.9. Должна быть предусмотрена возможность добавления, изменения или удаления отчетов и печатных форм силами специалистов Системы без необходимости обновления Системы или ее компонентов. 22.10. Должна быть предусмотрена возможность реализации описанных функций силами обученных специалистов Системы без необходимости обновления Системы или ее компонентов - Соответствие - - Значение характеристики не может изменяться участником закупки - 36. Требования к созданию электронной карточки объекта учета, дизайн карточки 36.1. Требования к электронным карточкам объектов учета единой реестровой подсистемы должны соответствовать общим требованиям к электронным карточкам объектов учета. 36.2. Для карточки объекта учета Единой реестровой подсистемы должна быть предусмотрена возможность создания произвольного количества контейнеров, содержащих перечень атрибутов объекта учета, элементы управления которыми размещаются в соответствующем контейнере. 36.3. Для каждого атрибута должна быть предусмотрена возможность настройки его видимости в карточке по умолчанию: 36.3.1. Всегда отображается – пользователю предлагается только указать значение атрибута. 36.3.2. По умолчанию не отображается, но пользователь может его добавить самостоятельно. 36.3.3. Для атрибутов, значения которых выбираются из справочника, должна быть возможность создания соответствующего справочника или использование имеющегося. 36.4. Создаваемые контейнеры атрибутов должны быть размещены в любой части экранной формы электронной карточки объекта (или на создаваемой вкладке электронной карточки) в соответствии с общими принципами. 36.5. Дополнительно для электронных карточек объектов учета Единой реестровой подсистемы должны быть предусмотрены возможности размещения контейнеров, использующихся для описания объектов имущественно-земельного комплекса: 36.5.1. Адрес, с отображением адреса одной строкой. 36.5.2. Адрес, с отображением произвольного количества адресов, каждый адрес отображается с разбиением на атрибуты, его составляющие (город, улица, номер дома и т.д.). 36.5.3. Документы – контейнер работы с документами по данному объекту учета. 36.5.4. Файлы. 36.5.5. Фотографии. 36.5.6. Типы использования. 36.5.7. Зоны размещения. 36.5.8. Элементы благоустройства. 36.5.9. Субъекты права. 36.5.10. Комиссии. 36.5.11. Экономические показатели. 36.5.12. Технические показатели. 36.5.13. События. 36.5.14. Признаки. 36.5.15. Элементы классификации. - Соответствие - - Значение характеристики не может изменяться участником закупки - 26. Требования к подсистеме «Оповещение пользователей»: 26.1. Подсистема оповещения должна быть доступна из главного меню клиента Системы и из главного меню сервера приложений, в случае если сервер приложений не запущен в режиме службы. 26.2. Подсистема оповещения пользователей должна обеспечивать следующие возможности: 26.2.1. Направить подключенным пользователям (подключенным клиентским приложениям) текстовое сообщение о проведении технических работ, требующих отключения клиентских приложений от Системы. Для данного типа сообщений должна быть предусмотрена возможность указания времени (в минутах), по истечении которого клиентские приложения должны быть автоматически отключены от Системы. Данное сообщение посылается всем подключенным клиентским приложениям и должно сопровождаться отображением счетчика обратного отсчета до автоматического отключения клиентского места. Сообщение должно отображаться поверх всех окон клиентского приложения. 26.2.2. Автоматически завершить работу всех подключенных клиентских приложений по истечении заданного времени. 26.2.3. Формировать простые текстовые сообщения подключенным пользователям Системы - Соответствие - - Значение характеристики не может изменяться участником закупки - 26.2.4. Формировать текстовые сообщения всем пользователям Системы (не подключенные на момент формирования сообщения пользователи получат сообщение в момент следующего подключения). Пользователь должен получить сообщение только один раз вне зависимости от компьютера, на котором запущено клиентское приложение (в отличие от сообщений об автоматическом отключении клиентских приложений, простые текстовые сообщения должны отправляться не каждому клиентскому приложению, а пользователю, который был указан при подключении к клиентскому приложению. 26.2.5. Отзыв направленного ранее сообщения об отключении клиентских приложений. Автоматическое отключение клиентских приложений должно быть отменено, сообщение об отключении и таймер обратного отсчета на всех клиентских приложениях должны быть закрыты, должна быть возобновлена возможность подключения клиентских приложений. 26.2.6. Ведение журнала всех отправленных сообщений. 26.2.7. Ведение журнала получения сообщений пользователями. 26.3. Для оповещения должна быть предоставлена возможность выбора типа оповещения. Должна быть реализована возможность выбора следующих типов: 26.3.1. Оповещение о начале технических работ на сервере, о необходимости выхода из Системы и автоматического отключения клиента. 26.3.2. Простое оповещение только подключенным пользователям, автоматического отключения не происходит. 26.3.3. Оповещение всем пользователям, подключенным и не подключённым, неподключенные должны получить оповещение при первом входе в Систему. 26.4. Должен вестись журнал оповещений, обладающих следующими характеристиками: 26.4.1. Для каждого оповещения сохраняется информация с указанием их типа, текста сообщения, даты и времени отправки сообщения, пользователя, сформировавшего сообщения. 26.4.2. Журнал оповещений должен обладать средствами поиска сообщений по всем параметрам журнала. Реализованы фильтры по диапазону дат, пользователю, группе пользователей, текстовый поиск. 26.4.3. Невозможно удалить произвольное оповещение - Соответствие - - Значение характеристики не может изменяться участником закупки - 26.4.4. Удалить записи журнала о старых оповещениях можно только до указанной даты. Права на удаление записей имеет только администратор. 26.4.5. Ведется дополнительный лог по пользователям, прочитавшим оповещение. Просмотр лога так же доступен в интерфейсе просмотра журнала - Соответствие - - Значение характеристики не может изменяться участником закупки - 23. Требования к подсистеме «Обеспечение безопасности, администрирования и разграничения прав доступа»: 23.1. Подсистема должна: 23.1.1. Обеспечивать возможности индивидуальной настройки для каждого пользователя базовых ограничений прав и разрешений с возможностью дальнейшего расширения. 23.1.2. Возможности индивидуального ограничения просмотра реестра объектов любого из типов. 23.1.3. Возможности индивидуального ограничения просмотра данных карточек объектов учета любых типов. Предоставление прав на частичный просмотр информации по объекту (например, запрет на просмотр экономических показателей объекта, но разрешение на просмотр технических показателей). 23.1.4. Возможности ограничения доступа к персональным данным, требующим отдельной защиты. 23.1.5. Возможности индивидуального ограничения изменения данных по объектам учета всех типов. Предоставление прав на частичное изменение информации. 23.1.6. «Горизонтальное» ограничение прав на изменение множественных атрибутов объектов учета (например, пользователю предоставляются права на изменение/внесение в карточку объектов документов определенной направленности и закрываются права на правку документов иной направленности (например, реестровых документов)). 23.1.7. Ограничение прав на выполнение различных операций с объектом учета (выделение подобъектов, включение в группу). 23.1.8. Ограничение на операции с печатными формами (просмотр и печать отчетов и печатных форм, экспорт во внешние форматы (docx, xlsx), редактирование сформированных отчетов). Для печатных форм права должны назначаться индивидуально для каждого типа объектов учета, для аналитических отчетов – индивидуально для каждой темы отчета - Соответствие - - Значение характеристики не может изменяться участником закупки - 23.1.9. Ограничение прав на работу с блоками начислений и платежей за аренду недвижимости и ЗУ (индивидуально на все функции, выполнение операций в каждом из режимов (индивидуальном, массовом)). 23.1.10. Ограничение прав на работу с универсальной библиотекой запросов – права предоставляются индивидуально для каждой темы запросов и на выполнение операций блока запросов (выполнение запроса, экспорт результатов). 23.1.11. Ограничение прав на работу с НСИ (права предоставляются индивидуально для каждого справочника или классификатора). 23.1.12. Ограничение права на настройки системы (индивидуально на каждый блок настроек). 23.2. Все права и разрешения на работу с объектами учета всех типов должны предоставляться индивидуально для каждой стадии формирования объекта учета (заявка, новый, актуальный (реестровый), актуальный зарегистрированный (в Росреестре), архивный, справочный, внереестровый или объект налогового потенциала). 23.3. В Системе должны присутствовать средства объединения пользователей в группы (причем, каждый пользователь может быть включен в одну и иное количество групп) с автоматическим наследованием всех прав и разрешений групп, в которые включен пользователь. 23.4. В Системе должны быть реализованы особые механизмы хранения и проверки паролей, обеспечивающие повышенную безопасность. При установке и смене пароля, новый пароль кодируется необратимыми алгоритмами (без возможности восстановления исходного пароля). 23.5. Разграничение прав пользователей единого информационного пространства: 23.5.1. Для каждого пользователя или группы пользователей должна быть предусмотрена возможность управления правами доступа (в объеме, описанном выше) индивидуально для каждого из информационных фондов организаций-участников, составляющих единую базу данных Системы. 23.5.2. В совокупности с возможностью сопоставления пользователей с соответствующими информационными фондами, а также автоматической идентификации принадлежности объектов учета к соответствующим информационным - Соответствие - - Значение характеристики не может изменяться участником закупки - 27. Подсистема «Самодиагностика с автоматическим оповещением о выявленных аномалиях по электронной почте»: 27.1. Подсистема «Самодиагностика с автоматическим оповещением о выявленных аномалиях по электронной почте» должна быть использована в целях улучшения качества работы, уменьшения количества ошибок, уменьшения времени реагирования на появление проблемы. Должен быть сформирован набор тестов, проверяющих состояние работоспособности Системы и ее подсистем, возникновения проблем при взаимодействии Системы с внешними системами, возникновении некорректных данных в информационном фонде. Мониторинг работоспособности должен производиться непрерывно. Мониторинг целостности и непротиворечивости данных должен проверяться при помощи регламентных операций, выполняемых Системой по заданному расписанию (например, в ночное время). 27.2. Оповещения должны отправляться с использованием механизма очереди оповещений на адреса электронной почты, которые заданы при настройке подсистемы «Самодиагностика с автоматическим оповещением о выявленных аномалиях по электронной почте» - Соответствие - - Значение характеристики не может изменяться участником закупки - 28. Средства ведения электронных карточек объектов учета: 28.1. Под объектом учета понимается любой объект, информация по которому должна быть учтена в едином информационном фонде Системы. Например, объектами учета являются: земельные участки любой формы собственности, а также земельные участки, собственность на которые не разграничена, объекты движимого и недвижимого имущества, субъекты права, документы, договоры, соглашения, претензионные и исковые процессы, финансовые поступления. 28.2.Для доступа к реквизитам (атрибутам, характеристикам) объекта учета в Системе должна быть предусмотрена отдельная экранная форма. Экранная форма по умолчанию должна открываться в режиме просмотра (возможность редактирования атрибутов объекта должна быть отключена) с возможностью переключения в режим редактирования. 28.3. Экранная форма доступа к реквизитам объекта должна отображать информацию по объекту учета в соответствии с правами и разрешениями пользователя (не отображать атрибуты объекта, для которых у пользователя отсутствуют права на просмотр). 28.4. При переключении экранной формы карточки объекта учета в режим редактирования доступ на редактирование должен быть предоставлен только к тем атрибутам объекта учета, на которые активный пользователь имеет права и разрешения на изменение. Остальные атрибуты должны оставаться в режиме просмотра (без возможности внесения изменений). - Соответствие - - Значение характеристики не может изменяться участником закупки - 24. Требования к подсистеме «Ведение нормативно-справочной информации»: 24.1. Подсистема должна обеспечивает функционирование необходимого для эффективной работы Системы набора справочников и классификаторов. 24.1. Помимо федеральных справочников и классификаторов, а также справочников и классификаторов, формируемых в процессе поставки Системы, в состав Системы должен быть включен ряд дополнительных справочников, направленных на: 24.1.1. Повышение аналитических возможностей Системы. 24.1.2. Повышение возможностей Системы по расширению перечня учитываемых показателей. 24.1.3. Повышения адаптивности Системы к изменению законодательства, технологии учета, обеспечения быстрой настройки Системы под все нюансы работы органов управления имущественно-земельным комплексом. 24.2. В Системе должна быть возможность доступа к справочникам и классификаторам непосредственно в ходе редактирования параметра с выбором из справочника с целью выполнения расширенного поиска, а по необходимости и внесения изменений в классификатор. 24.3.Должна быть реализована возможность «привязки» как самих классификаторов, так и элементов классификации к видам реестров. Классификаторы и элементы классификации должно быть возможно выбрать только в тех реестрах, в которых это разрешено настройками Системы - Соответствие - - Значение характеристики не может изменяться участником закупки - 29. Требования по ведению атрибутов объектов учета 29.1. Объект учета в обязательном порядке должен содержать следующую информацию: 29.1.1. Идентификатор (реестровый номер) – числовое значение, однозначно идентифицирующее объект учета (не должно существовать любого другого объекта учета, имеющего такой же идентификатор). Идентификатор должен присваиваться Системе автоматически при создании нового объекта. 29.1.2. Наименование (описание) объекта – строковое значение, описывающее объект, заполняется вручную, не является обязательным. 29.2. Объект учета должен иметь произвольное количество атрибутов (характеристик). Каждый атрибут должен содержать: 29.2.1. Наименование (идентификатор) атрибута – выбирается из соответствующих справочников наименований атрибутов каждого из типов данных. Должен быть предусмотрен инструмент формирования допустимого перечня атрибутов, который может быть указан (выбран) в карточке каждого из типов объектов учета (инструмент индивидуального формирования перечня атрибутов для каждого типа объектов учета). 29.2.2. Значение – указывается в зависимости от типа данных атрибута. 29.2.3. Период действия – дата начала периода действия атрибута и дата окончания периода действия атрибута. Индивидуально для каждого вида (наименования) атрибута должна быть предусмотрена возможность настройки допустимости пересечения периодов действия значений этого атрибута (множественный ввод значений одноименных атрибутов в один момент времени). 29.2.4. Перечень ссылок на документы основания начала действия значения атрибута – перечень ссылок на информацию о документах с обязательным указанием основного документа основания. - Соответствие - - Значение характеристики не может изменяться участником закупки - 29.2.5. Перечень ссылок на документы основания окончания действия значения атрибута – перечень ссылок на информацию о документах с обязательным указанием основного документа основания. Индивидуально для каждого вида (наименования) атрибута должна быть предусмотрена возможность настройки использования документов оснований окончания действия (используется или нет). 29.2.6. Примечание – текстовое поле. 29.3. Система должна обеспечивать возможность ведения атрибутов объектов учета следующих типов данных: 29.3.1. Числовой тип (коэффициент). Должна быть предусмотрена возможность установки фиксированного значения величины коэффициента для каждого наименования коэффициента (наименования атрибута соответствующего типа) без возможности индивидуального изменения в карточке объекта учета (константа) или с возможностью индивидуального изменения (в этом случае значение, связанное с наименованием коэффициента, должно устанавливаться как значение по умолчанию с возможностью последующей корректировки индивидуально в карточке конкретного объекта). Такая настройка должна быть предусмотрена индивидуально для каждого вида (наименования) коэффициента. 29.3.2. Денежный тип (экономический показатель). 29.3.3. Строковый тип (технический, описательный показатель). Для каждого наименования атрибута данного типа должна быть предусмотрена возможность установки маски ввода значения атрибута - Соответствие - - Значение характеристики не может изменяться участником закупки - 29.3.4. Классификационный тип – справочник. Для каждого наименования атрибута (категории классификационных данных) должна быть предусмотрена возможность индивидуальной настройки перечня (справочника) элементов классификатора данной категории. 29.3.5. Булевый тип – признак (да/нет). Допустимо отсутствие ведения информации по периоду действия и документам-основаниям. 29.3.6. Тип даты – событие. 29.3.7. Ссылка на субъект права – с указанием типа субъекта права. 29.4. Кроме того, в карточку объекта учета дополнительно должны быть загружены: 29.4.1. Информация по адресу объекта с использованием адресной подсистемы. 29.4.2. Произвольное количество файлов любого типа. Файлы должны загружаться как по одному, так и массово, путем выделения нескольких файлов в средстве работы с файлами операционной системы (проводнике, менеджере файлов). Должна быть предусмотрена возможность загрузки в карточку объектов файлов путем использования технологии Drag-And-Drop (перетащи и отпусти). Открытие файлов должно производиться непосредственно из Системы путем использования средств операционной системы, назначенных по умолчанию (аналогично открытию файлов проводником или другим менеджером файлов). Хранение прикрепленных файлов объекта учета должно производиться на сервере в базе данных или с использованием других средств, обеспечивающих надежность и скорость работы с файлами не хуже соответствующих инструментов СУБД (транзакционный механизм доступа с возможностью автоматического отката транзакций, завершившихся аварийно, резервное копирование). 29.4.3. Произвольное количество файлов распространенных графических форматов (jpg, bmp). Функционал аналогичен работе с прикрепленными файлами. Дополнительно в Системе должны быть предусмотрены средства предварительного просмотра графических изображений без открытия файлов (средства предварительного просмотра). 29.4.4. Информация о произвольном количестве документов: - Соответствие - - Значение характеристики не может изменяться участником закупки - 29.4.4.1. Направление документа – значение из соответствующего справочника, указывающее на назначение документа в карточке объекта – определяется технологией работы с объектами соответствующего типа. 29.4.4.2. Номер документа. 29.4.4.3. Дата документа. 29.4.4.4. Тип документа – значение из классификатора типов документов. 29.4.4.5. Источник документа – значение из классификатора источников документов (организация, выпустившая документ). 29.4.4.6. Наименование документа – текстовое описание с возможностью выбора из справочника шаблонов наименований с возможностью последующего индивидуального изменения. 29.4.4.7. Примечание документа. 29.4.4.8. Ссылка на прикрепленный файл документа. 29.5. Сохранение карточки объекта учета (атрибутов, файлов, графических объектов, документов должно производиться на основе транзакционных механизмов, то есть либо вся измененная информация карточки (внесенные в карточку данные) должны быть успешно сохранены в базе данных, либо, например, в случае какой-либо ошибки, все изменения в базе данных, выполненные в процессе сохранения, должны быть отменены, и карточка вернется в состояние, предшествующее сохранению. Пользователь должен подробно быть проинформирован Системой о характере возникшей ошибки и, по возможности, Система даст рекомендации по способам исправления ошибки. После исправления пользователем причин, приведшим к ошибке, должна быть предусмотрена возможность повторного сохранения внесенных в карточку изменений. Частичное автоматическое внесение изменений в базу данных в процессе внесения изменений в карточку объектов недопустимо - Соответствие - - Значение характеристики не может изменяться участником закупки - 38. Средства выполнения массовых операций: 38.1. Система должна иметь средства выполнения однотипных операций над заданным количеством объектов учета, в том числе: 38.1.1. Передача с баланса на баланс, в казну, из казны, списание объектов. 38.1.2. Внесение документа-основания. 38.1.3. Смена адреса. 38.1.4. Смена характеристик объектов учета. 38.1.5. Изменить нумерацию объектов. 38.1.6. Слияние «двойников». 38.1.7. Включить физическое лицо в очередь и исключить из очереди. 38.1.8. Выполнение массовых запросов СМЭВ к сервисам Росреестра и другим информационным системам, с которыми предусмотрено взаимодействие по протоколам СМЭВ. 38.1.9. Массовое формирование квитанций, уведомлений, претензий и других печатных форм на основе заданных шаблонов. 38.2 .Массовые операции должны повысить эффективность управления имущественно-земельным комплексом, снизить трудозатраты специалистов на выполнение операций над объектами - Соответствие - - Значение характеристики не может изменяться участником закупки - 39. Требования к подсистеме «Бюджетный учет доходов»: 39.1. Подсистема бюджетного учета доходов должна применяться для администрирования доходов по всем администрируемым кодам бюджетной классификации, а также отражении в бухгалтерском учете активов, обязательств, фактов хозяйственной жизни, иных объектов бухгалтерского учета, возникающих при получении (предоставлении) во временное владение и пользование или во временное пользование материальных ценностей по договору аренды (имущественного найма) либо по договору безвозмездного пользования в соответствии с требованиями федеральных стандартов бухгалтерского учета для организаций муниципального сектора (в том числе бюджетный учет операций по льготной аренде, учет на забалансовых счетах бюджетного учета). 39.2. Подсистема должна быть полностью «прозрачной» для пользователей с точки зрения формирования всей необходимой бухгалтерской информации (проводок)/информации по бюджетному учету, соответствующих выполнению финансово-аналитических операций, проведению и оформлению результатов инвентаризации. Иными словами, Система автоматически должна формировать необходимую бухгалтерскую информацию (проводки) в соответствии со всеми требованиями, определенными инструкциями Министерства финансов РФ от 1 декабря 2010 года № 157н, от 6 декабря 2010 года № 162н, от 16 декабря 2010 года № 174н, № 258н от 31 декабря 2016 года, № 209н от 29 ноября 2017 года, федеральными стандартами бухгалтерского учета для организаций муниципального сектора, отслеживая эффективность работы муниципального учреждения. 39.3. Печатные формы и отчеты должны удовлетворять формам бухгалтерской отчетности организаций согласно приказу Министерства Финансов РФ № 66н от 2 июля 2010 года и № 52н от 30 марта 2015 года: 39.3.1. Бухгалтерский отчет «Информация по администрируемым доходам, обобщенный (свернутый)» и запрос-расшифровка к нему «Бухгалтерия подоговорная». 39.3.2. Оборотно-сальдовые ведомости по счетам (Счета 205, 401, 209, 210). - Соответствие - - Значение характеристики не может изменяться участником закупки - 39.3.3. Журнал операций № 2 с безналичными денежными средствами (ОКУД 504071). 39.3.4. Журнал операций № 5 расчет с дебиторами по доходам (ОКУД 504071). 39.3.5. Дебиторская и кредиторская задолженность (ОКУД 0504089). 39.3.6. Сведения о дебиторской и кредиторской задолженности учреждения (ОКУД 0503169). 39.4. Автоматическое формирование информации по бюджетному учету в соответствии с перечисленными выше требованиями должно производиться на уровне СУБД, то есть гарантировано, что соответствующие операции бюджетного учета должны быть произведены корректно даже в том случае, если внесение изменений в соответствующие финансовые операции произведены не штатными средствами Системы. Например, в ходе ручного запуска скрипта на корректировку данных непосредственно в базе данных, при регламентном обслуживании базы данных и в любых других случаях. 39.5. Подсистема бюджетного учета доходов от использования муниципальной собственности должна автоматизировать выполнение следующих основных задач: 39.5.1. Автоматизация формирования бухгалтерских проводок при выполнении финансово-аналитических операций - Соответствие - - Значение характеристики не может изменяться участником закупки - 39.5.2. Автоматизация формирования корректирующих проводок при корректировке финансово-аналитической информации «задним числом». Если операция корректировки проводится до сдачи бухгалтерской отчетности за соответствующий период, то выполняется корректировка соответствующих проводок датой проведения аналитической операции, иначе формируются дополнительные корректирующие проводки текущим числом (при изменении суммы аналитической операции в большую сторону выполняется формирование проводки по доначислению, если в меньшую – формируется соответствующая сторнирующая проводка). 39.5.3. Автоматизация работы с документами-основаниями проведения операций бюджетного учета. 39.5.4. Автоматизация формирования журнала операций за период, бухгалтерской справки по исправлениям. 39.5.5. Выгрузка консолидированной информации в электронном виде за период для передачи в бухгалтерские системы. 39.5.6. Индивидуальное «закрытие» периодов по каждому из КБК при сдаче отчетности (блокировка внесения изменений в информацию бюджетного учета «задним числом») - Соответствие - - Значение характеристики не может изменяться участником закупки - 40. Требования к подсистеме «Бюджетный учет движения объектов в казне»: 40.1. Подсистема должна применяться для автоматического формирования всей необходимой бухгалтерской информации (проводок)/информации по бюджетному учету, соответствующих выполнению финансово-аналитических операций, проведению и оформлению результатов инвентаризации. Иными словами, подсистема автоматически должна формировать необходимую бухгалтерскую информацию (проводки) в соответствии со всеми требованиями, определенными инструкциями Министерства финансов РФ от 1 декабря 2010 года № 157н, от 6 декабря 2010 года № 162н, от 16 декабря 2010 года № 174н, № 258н от 31 декабря 2016 года, № 209н от 29 ноября 2017 года, федеральными стандартами бухгалтерского учета для организаций муниципального сектора, отслеживая эффективность работы муниципального учреждения. 40.2. Печатные формы и отчеты должны удовлетворять формам бухгалтерской отчетности организаций согласно приказу Министерства Финансов РФ № 66н от 2 июля 2010 года и № 52н от 30 марта 2015 года: 40.2.1. Бухгалтерский отчет 645 «Отчет для движения (Казна, Забаланс)» и запрос-расшифровка к нему 645 «Расшифровка отчета для движения». 40.2.2. Оборотно-сальдовые ведомости по счетам (Счета 104, 108 (в разрезе аналитических счетов), 401, 25, 26). 40.2.3. Журнал операций № 7 по выбытию и перемещению нефинансовых активов (ОКУД 504071). 40.2.4. Сведения о движении нефинансовых активов (ОКУД 0503168). 40.2.5. Инвентаризационная опись основных средств (ОКУД 0317001). - Соответствие - - Значение характеристики не может изменяться участником закупки - 37. Средства поиска, отображения и анализа информации: 37.1. Средства поиска, отображения и анализа информации должны быть включены во все экранные формы работы со списками объектов учета, в том числе в экранные формы работы с объектами реестра. 37.2. Средства поиска должны обеспечивать возможности поиска объектов учета по всем характеристикам самих объектов, а также по всем характеристикам связанных объектов учета любого уровня вложенности (например, поиск объектов по параметрам связанных объектов учета, которые связаны со связанными объектами учета. – поиск объектов по параметрам договоров на них и параметрам субъектов этих договоров). 37.3. Для каждой из характеристик должны быть предусмотрены следующие логические условия поиска: 37.3.1. Равно. 37.3.2. Не равно. 37.3.3. Больше. 37.3.4. Меньше. 37.3.5. Больше или равно. 37.3.6. Меньше или равно. 7. Содержит (для текстовых характеристик). 37.3.8. Не содержит (для текстовых характеристик). 37.3.9. Начинается на (для текстовых характеристик). 37.3.10. Не начинается на (для текстовых характеристик). 37.3.11. Заполнено. 37.3.12. Не заполнено. 37.3.13. Отсутствует. 37.4. Для характеристик, имеющих историю изменения, должны быть предусмотрены средства указания даты, на которую выполняется поиск значения характеристики. 37.5. Для сложных или связанных характеристик должны быть предусмотрены возможности поиска по комбинациям значений (например, поиск по коэффициентам подразумевает возможность поиска по произвольной комбинации значений, составляющих информацию по коэффициенту – наименование коэффициента, величина, диапазон дат периода действия коэффициента) - Соответствие - - Значение характеристики не может изменяться участником закупки - 37.6. Должен быть предусмотрен поиск по отрицанию условий поиска (объекты, НЕ удовлетворяющие условиям поиска). 37.7. Должна быть предусмотрена возможность комбинации условий поиска – поиск в найденном и новый поиск в дополнение к предыдущему. 37.8. Должна быть предусмотрена возможность сохранение ранее сформированных условий поиска для последующего быстрого использования. 37.9. Для администраторов системы должна быть предусмотрена возможность формирования и отображения SQL-скрипта, соответствующего выборке объектов учета для формирования списка с учетом SQL-выражений, удовлетворяющих сформированным условиям поиска. 37.10. Администратор должен иметь возможность ручной корректировки сформированных SQL-выражений поиска с возможностью выполнения поиска на основе скорректированных SQL-выражений. 37.11. В любой списочной форме (экранной форме отображения списка объектов учета или множественных реквизитов, атрибутов, характеристик объектов учета) должны быть предусмотрены средства контекстного поиска – возможность ввода символов в любой из колонок списка с автоматическим позиционированием курсора в списке на первый объект, соответствующий условиям поиска (вводимым значениям). 37.12. В любой форме отображения списка объектов учета должна быть предусмотрена возможность отображения средств предварительного просмотра. Например, в списке договоров можно отобразить перечень кадастровых номеров земельных участков, арендуемых по текущему договору в списке, или перечень документов-оснований, перечень дополнительных соглашений, развернутую информацию о задолженности по договору - Соответствие - - Значение характеристики не может изменяться участником закупки - 17. Требования к подсистеме «Ведение договоров и дополнительных соглашений»: 17.1. Подсистема управления договорами и дополнительными соглашениями должна автоматизировать выполнение всех задач ведения соответствующих договорных отношений и претензий за фактическое использование объектов без заключения договорных отношений. 17.2. Подсистема «Имущество» автоматизирует ведение договоров и других правовых отношений следующих типов: 17.2.1. Договор социального найма жилья (для объектов жилого фонда). 17.2.2. Договор специализированного найма жилья (для объектов жилого фонда). 17.2.3. Договоры на согласовании (при заключении договора балансодержателями имущества). 17.2.4. Договор аренды. 17.2.5. Договор купли/продажи/приватизации. 17.2.6. Договор выкупа с рассрочкой. 17.2.7. Договор безвозмездного пользования объектов движимого имущества. 17.2.8. Договор безвозмездного пользования недвижимого имущества, имущественных комплексов. 17.2.9. Договор мены. 17.2.10. Договор дарения. 17.2.11. Распорядительный документ по праву постоянного бессрочного пользования. 17.3. Подсистема «Земля» автоматизирует ведение договоров и других правовых отношений следующих типов: 17.3.1. Договор аренды. 17.3.2. Соглашение о перераспределении земельных участков. 17.3.3. Договор безвозмездного пользования. 17.3.4. Соглашение о сервитуте (публичном сервитуте) - Соответствие - - Значение характеристики не может изменяться участником закупки - 17.3.5. Разрешения на использование земельного участка без его предоставления и установления сервитута. 17.3.6. Претензия за фактическое использование участка без заключения договора (расчеты в соответствии с требованиями Гражданского кодекса РФ). 17.4. Подсистема управления договорами и дополнительными соглашениями должна автоматизировать решение следующих основных задач: 17.4.1. Учет всех условий договоров и дополнительных соглашений. По каждому договору и доп. соглашению ведется следующая основная информация: 17.4.1.1. Номер и дата договора, доп. соглашения, номер и дата регистрации. 17.4.1.2. Код бюджетной классификации. 17.4.1.3. Тип использования, целевое использование. 17.4.1.4. Дата начала фактического использования объекта договора (для определения периода фактического использования). 17.4.1.5. Дата начала действия, планируемого и фактического окончания (расторжения), дата фактического освобождения объекта (для определения периода фактического использования объекта после расторжения договора). 17.4.1.6. Особые условия, ограничения. 17.4.1.7. Документы-основания, документы на льготы, другие документы. 17.4.1.8. Комиссии. 17.4.1.9. Объекты договора (может быть несколько объектов в договоре) – с возможностью указания периода нахождения объекта или его доли в договоре, доли объектов учета по договору – с историей изменения величины доли. 17.4.1.10. Формула (алгоритм) расчета планируемой платы по договору (индивидуально для каждого объекта или доли объекта в договоре) – с историей изменения. 17.4.1.11. Коэффициенты, ставки, индивидуальные показатели, другие характеристики, участвующие в автоматическом расчете планируемой арендной платы (индивидуально по каждому объекту в договоре) – с историей изменения - Соответствие - - Значение характеристики не может изменяться участником закупки - 37.13. Средства предварительного просмотра должны представлять собой печатные формы, сформированные с использованием генератора отчетов, и отображающие всю необходимую информацию по текущему объекту учета в списке без выполнения дополнительных действий со стороны пользователя. Для каждого типа объектов учета может быть настроено произвольное количество форм предварительного просмотра с возможностью выбора текущей отображаемой формы из списка доступных форм. 37.14. Средства предварительного просмотра должны обладать всеми возможностями печатных форм, включая возможность открытия карточки объекта учета путем двойного клика по информации по нему в окне предварительного просмотра (например, открытие карточки земельного участка из окна предварительного просмотра договоров, отображающего перечень земельных участков по текущему договору). 37.15. Аналитические средства элементов работы со списками объектов учета 37.15.1. Группировка данных по одному или нескольким столбцам. Например, реестр может быть сгруппирован по состоянию объектов учета, району области, разрешенному использованию. 37.15.2. Вычисление общих итогов, в том числе для каждой из групп (в случае применения группировки). Например, для приведенного примера возможна автоматическая калькуляция общей планируемой платы, площади объектов, величины задолженности в разрезе состояний договоров аренды, района расположения объекта договора, целевого использования; 37.15.3. Дополнительная оперативная фильтрация данных по значениям любого столбца\совокупности столбцов; 37.15.4. Сортировка данных по произвольному столбцу\совокупности столбцов. 5. Возможность выбора отображаемых столбцов. 37.15.6. Автоматическое сохранение настроек табличного представления для каждого типа объектов учета. 37.16. Должна быть предусмотрена возможность экспорта сформированных данных в форматы табличные форматы (xlsx, csv), текстового файла или внутренние форматы генератора отчетов. - Соответствие - - Значение характеристики не может изменяться участником закупки - 37.17. В Системе должна быть реализована возможность автоматического предварительного просмотра документа непосредственно в табличной форме реестра любого типа объектов. При переходе от одного к другому объекту в списке, форма предварительного просмотра должна обновляться автоматически. 37.18. Должна быть реализована возможность отключать данный режим, настраивать форму просмотра, выбирая нужный шаблон документа, из списка доступных для данного режима, шаблонов. Должна быть возможность создавать и редактировать шаблоны документов для данного режима наряду с любыми другими шаблонами документов - Соответствие - - Значение характеристики не может изменяться участником закупки - 15. Требования к подсистеме Подсистема «Ведение информации по акциям»: 15.1. В Системе должна быть возможность ведения информации об акциях (долях), находящихся в собственности муниципального образования. 15.2. В рамках подсистемы помимо стандартных атрибутов должна быть предусмотрена возможность ведения следующей информации: 15.2.1. Субъекты акций (сведения об эмитенте, совете директоров, ревизионных комиссиях). 15.2.2. Субъекты долей (сведения об обществе, совете директоров, ревизионных комиссиях). 15.2.3. Заседания совета директоров и общего собрания акционеров (участников), включая возможность фиксации решения собрания, загрузки протоколов. 15.2.4. Информация о стоимостях акций (долей) и количестве акций (в разрезах видов акций). 15.2.5. Сведения о собраниях советов директоров и ревизионных комиссий (включая состав совета, протокол). 15.2.6. Бюджетный учет акций (долей) в казне. 15.2.7. Сведения об эмитенте (обществе), а также возможность перехода в реестр договоров для получения информации о долговых обязательствах с расшифровкой по каждому кредитору, реквизитами заключенных договоров, существенными условиями по каждому договору, основному долгу и процентам - Соответствие - - Значение характеристики не может изменяться участником закупки - 16. Требования к подсистеме «Адресная подсистема»: 16.1. «Адресная подсистема» (средства формирования адресов объектов для реестровой подсистемы учета) должна обеспечивать возможность формирования и учета произвольного количества адресов для каждого объекта учета. 16.2. Для каждого из адресов должна быть предусмотрена возможность указания типа адреса на основе расширяемого классификатора (присвоенный адрес – официальный, юридический адрес, предыдущий адрес (при наличии) и адресного ориентира (местоположение объекта учета). 16.3. Присвоенный адрес – официальный, должен быть один. 16.4. «Адресная подсистема» должна обеспечивать возможность указания адресных реквизитов, утвержденных, постановлением Правительства РФ от 19.11.2014 № 1221 как с использованием собственных справочников и классификаторов присвоенных адресов или установленных ранее, включая адресный ориентир, так и с использованием базы федеральной информационной адресной системы (ФИАС). 16.5. «Адресная подсистема» должна обеспечивать возможность настройки шаблона вывода адреса (формирования строки адреса) для каждого из типов объектов учета (наименований реестров объектов учета). Шаблон должен обеспечивать возможность указания адресных реквизитов в соответствии с требованиями к структуре адреса, например, , , , , или , , , и т.п. 16.6. Строка адреса обязательно отображается в карточке объекта учета и в списке объектов учета соответствующего типа. 16.7. «Адресная подсистема» должна обеспечивать возможность ввода адреса любых объектов учета, включая адреса комнат, офисов, территорий и т.д. Должна быть предусмотрена возможность указания адресного ориентира. 16.8. «Адресная подсистема» должна обеспечивать возможность ввода адреса следующей структуры: 16.8.1. Наименование страны (Российская Федерация) – выбирается из справочника. 16.8.2. Наименование субъекта Российской Федерации – выбирается из справочника. - Соответствие - - Значение характеристики не может изменяться участником закупки - 17.4.1.12. Субъекты договора (с историей изменения, периодами действия для переуступки, субаренды, доверенности, ссылками на документы-основания). 17.4.1.13. Информация по субаренде с привязкой к объектам субаренды и характеристикам, коэффициентам, влияющим на расчет суммы планируемой арендной платы на субарендуемые площади (индивидуально для каждого субарендатора и субъекта субаренды) – с периодами действия. 17.4.1.14. Информация по планируемой плате по договору (с полной историей изменения) 17.4.1.15. Схема начисления в соответствии с условиями договора с историей изменения. 17.4.1.16. Индивидуальные ставки пени – с историей изменения и ссылками на документы-основаниями, а также возможностью индивидуальной настройки количества знаков после запятой для расчетов пени, а также возможности начисления процентов вместо пени. 17.4.1.17. Индивидуальные ставки процентов за пользование чужими денежными средствами – с историей изменения и ссылками на документы-основаниями, а также возможностью индивидуальной настройки количества знаков после запятой для расчетов процентов, а также возможности начисления пени вместо процентов. 17.4.2. Управление дополнительными соглашениями, изменениями условий договора по дополнительным соглашениям. 17.4.3. Управление договорами с множественностью лиц. 17.4.4. Управление договорами с множественностью объектов. 17.4.5. Переоформление, продление договоров. 17.4.6. Автоматизация процесса переуступки права по договору. 17.4.7. Переоформление договоров аренды земельных участков при разграничении собственности на объекты аренды. 17.4.8. Автоматизированный расчет суммы планируемой платы, платы за выкуп с учетом всех особых условий договора - Соответствие - - Значение характеристики не может изменяться участником закупки - 17.4.9. Автоматизация расчета суммы планируемой платы по договору с учетом истории изменения расчетных величин, изменения условий договора по доп. соглашениям, учета различных особых условий (в том числе различные виды льгот, субаренда, долевая аренда/выкуп, аренда/выкуп с разными типами использования объектов договора, автоматическим поднятием до установленных минимумов). 17.4.10. Автоматизация подготовки необходимых печатных форм (в том числе текстов договора, доп. Соглашения, проектов постановлений, распоряжений, приказов). 17.4.11. Формирование аналитики по задолженности, работа с должниками. 17.4.12. Автоматизация претензионной и исковой деятельности. 17.4.13. Формирование аналитической отчетности в соответствующей сфере. 17.4.14. Проведение экспресс-аналитики и др. 17.5. Индивидуальные ставки пени и процентов: 17.5.1. В Системе должна быть предусмотрена возможность ведения индивидуальных ставок пени для каждого договора с указанием периода действия индивидуальной ставки, а также документа-основания. 17.5.2. Средства настройки индивидуальной ставки пени должны предусматривать возможность дополнительной настройки следующих параметров: 17.5.2.1. Возможность указания конкретной величины ставки (в процентах или абсолютных единицах) или указание на ставку со значениями, задаваемыми справочником (например, ставка рефинансирования, ключевая ставка, среднебанковская ставка для вкладов физических лиц). 17.5.2.2. Доля ставки (знаменатель при указании ставки в виде простой дроби). 17.5.2.3. Количество знаков после запятой при расчете величины ставки в абсолютных единицах (по умолчанию – максимально возможное). 17.5.2.4. Признак необходимости расчета пени по методике равного количества дней в месяце (30 дней в месяце, 360 дней в году). 17.5.2.5. Признак необходимости расчета процентов за пользование чужими денежными средствами вместо пени - Соответствие - - Значение характеристики не может изменяться участником закупки - 40.3. Автоматическое формирование информации по бюджетному учету в соответствии с перечисленными выше требованиями должно производиться на уровне СУБД, то есть должно быть гарантировано, что соответствующие операции бюджетного учета должны быть произведены корректно даже в том случае, если внесение изменений в соответствующие финансовые операции произведены не штатными средствами Системы. Например, в ходе ручного запуска скрипта на корректировку данных непосредственно в базе данных, при регламентном обслуживании базы данных и в любых других случаях. 40.4. Подсистема бюджетного учета движения объектов в казне должны автоматизировать выполнение следующих основных задач: 40.4.1. Автоматизация формирования бухгалтерских проводок (балансовый и забалансовый учет) при включении/исключении объектов в казне. Проводки формируются на основе данных о балансовой и остаточной стоимостях объектов (кадастровой стоимости в случае земельных участков). Должна быть предусмотрена возможность в качестве балансовой и остаточной стоимости указывать другие виды стоимости (инвентарная, восстановительная, оценочная). 40.4.2. Автоматизация формирования корректирующих проводок при корректировке информации по стоимостям объектов в казне «задним числом». Корректировка проводится по тем же правилам, что и в случае бюджетного учета доходов. 40.4.3. Автоматизация работы с документами-основаниями проведения операций бюджетного учета движения объектов в казне. 40.4.4. Автоматизация формирования журнала операций за период, бухгалтерской справки по исправлениям. 40.4.5. Выгрузка консолидированной информации в электронном виде за период для последующей передачи в бухгалтерские системы. 40.4.6. Формирование количественной и финансовой информации по движению объектов в казне за период. 40.4.7. Формирование другой аналитической отчетности. 40.4.8. Для малоценного движимого имущества должна быть предусмотрена возможность ведения учета: - Соответствие - - Значение характеристики не может изменяться участником закупки - 40.4.8.1. Ведение всего пакета движимого имущества в казне и на балансе консолидировано единой суммой соответствующих активов. 40.4.8.2. Ведение движимого имущества пакетами одноименных объектов с указанием их количества и стоимостных характеристик единицы (например, наименование – стол, количество – 50, балансовая стоимость единицы 1000 рублей, балансовая стоимость общая 50 000 рублей). 40.4.8.3. Ведение малоценного движимого имущества пообъектно с возможностью указания (присвоения) реестровых и/или инвентарных номеров. 40.5. Бюджетный учет движения малоценного движимого имущества должен осуществляться в соответствии с требованиями, предъявляемыми к бюджетному учету имущества, вне зависимости от используемой технологии учета. 40.6. Должны быть предусмотрены средства автоматизации бюджетного учета акций в казне в соответствии с требованиями, предъявляемыми к бюджетному учету акций - Соответствие - - Значение характеристики не может изменяться участником закупки - 17.5.2.6. Признак «плавающей» ставки пени в периоде расчета («Плавающая» или фиксированная на день исполнения денежных обязательств или их части). 17.5.3. В периоде действия индивидуальных ставок пени расчет пени по договору должен производиться по общей методике, в противном случае – по технологии, определенной по умолчанию для данного вида договора и/или схеме начисления. 17.5.4. Аналогично должна быть реализована возможность для ведения индивидуальных ставок процентов за пользование чужими денежными средствами. 17.5.5. По умолчанию должна применяться методика, соответствующая 395 статье Гражданского кодекса РФ (с учетом всех редакций данной статьи, распространяющих действия до следующего внесения изменений в статью). 17.5.6. Средства настройки индивидуальной ставки процентов должны предусматривать возможность дополнительной настройки следующих параметров: 17.5.6.1. Возможность указания конкретной величины ставки (в процентах или абсолютных единицах) или указание на ставку со значениями, задаваемыми справочником (например, ставка рефинансирования, ключевая ставка, среднебанковская ставка для вкладов физических лиц); 17.5.6.2. Доля ставки (знаменатель при указании ставки в виде простой дроби); 17.5.6.3. Количество знаков после запятой при расчете величины ставки в абсолютных единицах (по умолчанию – максимально возможное). 17.5.6.4. Признак необходимости расчета пени по методике равного количества дней в месяце (30 дней в месяце, 360 дней в году). 17.5.6.5. Признак необходимости расчета пени вместо процентов за пользование чужими денежными средствами. 17.5.6.6. Признак «плавающей» ставки процентов в периоде расчета («Плавающая» или фиксированная на день исполнения денежных обязательств или их части). 17.5.7. В периоде действия индивидуальных ставок пени расчет пени по договору должен производиться по общей методике, в противном случае – по технологии, определенной по умолчанию для данного вида договора и/или схеме начисления - Соответствие - - Значение характеристики не может изменяться участником закупки - 18. Требования к подсистеме «Выкуп с рассрочкой»: 18.1. Подсистема «Выкуп с рассрочкой» необходима для ведения учета договоров выкупа с рассрочкой согласно Федерального закона «Об особенностях отчуждения недвижимого имущества, находящегося в муниципальной собственности субъектов Российской Федерации или в муниципальной собственности и арендуемого субъектами малого и среднего предпринимательства, и о внесении изменений в отдельные законодательные акты Российской Федерации» от 22.07.2008 N 159ФЗ (с изменениями от 08.06.2020). 18.2. Данная подсистема должна включать в себя как весь функционал подсистемы «Подсистема ведения договоров и дополнительных соглашений», так и специфические особенности учета договоров выкупа с рассрочкой: 18.2.1. Подсистема должна иметь возможность настройки графика платежей. Для этого необходимо указать цену выкупа объекта, количество месяцев рассрочки, сумму и дату первого взноса. После проведения настройки должна иметься возможность формирования первоначального графика платежей. Должна иметься возможность смещать график платежей на любое количество периодов (как в будущее, так и в прошлое, как первый, так и последующие календарные периоды). Ставка рефинансирования (ключевая ставка) должна определяться автоматически на дату подписания договора, при расчете начисления процентов данная ставка делится на 3. Начисления основного долга и процентов должны соответствовать дифференцированной схеме (не аннуитет). 18.2.2. При распределении платежей на договор в первую очередь должна погашаться задолженность по процентам, а оставшаяся сумма платежа покрывает задолженность по основному долгу. Данные суммы вычисляются системой автоматически. При этом после каждого распределения платежей сумма последующих начислений процентов пересчитывается автоматически. 18.2.3. Должны иметься гибкие возможности настройки данной подсистемы, в том числе: 18.2.3.1. Начисление должны производиться одной суммой или с разбивкой на основной платеж и проценты. - Соответствие - - Значение характеристики не может изменяться участником закупки - 18.2.3.2. Начисление пени должны производиться только на основной платеж или как на основной платеж, так и на проценты. 18.2.3.3. Ставку рефинансирования и график начисления платежей должна иметься возможность учитывать с даты начала договора, даты подписания договора, даты публикации договора, даты договора, с указанием конкретной даты вручную. 18.2.3.4. Начисление процентов производить на первоначальный взнос или не производить. 18.2.3.5. Платеж в первую очередь должен погашать пеню, потом процент, потом основной долг (либо в первую очередь на процент, а оставшуюся сумма платежа – на основной долг) - Соответствие - - Значение характеристики не может изменяться участником закупки - 16.8.3. Наименование муниципального района, городского округа или внутригородской территории (для городов федерального значения) в составе субъекта Российской Федерации – выбирается из справочника. 16.8.4. Наименование городского или сельского поселения в составе муниципального района (для муниципального района) или внутригородского района городского округа – выбирается из справочника. 16.8.5. Наименование населенного пункта – выбирается из справочника. 16.8.6. Наименование элемента планировочной структуры – выбирается из справочника. 16.8.7. Наименование элемента улично-дорожной сети – выбирается из справочника присвоенных наименований элементам УДС. 16.8.8. Номер земельного участка. 16.8.9. Тип и номер здания, сооружения или объекта незавершенного строительства. 16.8.10. Тип и номер помещения, расположенного в здании или сооружении. 16.9. Перечень элементов планировочной структуры (справочник), элементов улично-дорожной сети (справочник), элементов объектов адресации, типов зданий (сооружений) и помещений, используемых в качестве реквизитов адреса (справочники), а также правила сокращенного наименования адресообразующих элементов устанавливаются Министерством финансов Российской Федерации. 16.10. Для зависимых справочников должна быть предусмотрена возможность автоматической подфильтровки допустимых для выбора элементов при заполнении элементов вышестоящих классификаторов, от которых зависят данные. 16.11.Если значения вышестоящих классификаторов не заданы, то при выборе элемента некоторого зависимого справочника элементы вышестоящих справочников должны заполниться (выбраться автоматически). 16.12. Особенности работы адресной подсистемы при использовании ФИАС: 16.12.1. При использовании сведений об адресе из ФИАС ввод или изменение адреса объекта учета должно производиться в отдельной строке экранной формы объекта учета с обязательным внесением уникального номера адреса объекта адресации из государственного адресного реестра - Соответствие - - Значение характеристики не может изменяться участником закупки - 16.12.2. Структура базы данных для хранения данных ФИАС должна полностью соответствовать структуре данных ФИАС. 16.12.3. Элементы ФИАС должны быть расположены в отдельной базе данных Системы, для которой должен быть предоставлен отдельный режим обслуживания и резервного копирования. 16.12.4. В адресной подсистеме должен быть предусмотрен режим обновления во всех подсистемах Системы адресообразующих элементов, включая уникальный номер адреса объекта адресации в государственном адресном реестре базы данных ФИАС - Соответствие - - Значение характеристики не может изменяться участником закупки - 21.9. Средства подсистемы должны предоставлять возможность не только для проведения оперативных выборок, но и для выполнения запросов по индивидуальному или массовому изменению, добавлению, удалению информации в банке данных системы, например, в ходе обслуживания информационного фонда. - Соответствие - - Значение характеристики не может изменяться участником закупки - 30. Требования к элементам формы карточки объектов: 30.1. Средства работы с атрибутами каждого из доступных типов данных по умолчанию должны содержаться в экранных контейнерах (панелях экранной формы), контейнеры должны быть размещены на вкладках экранной формы. 30.2. Экранные контейнеры должны представлять собой панели прямоугольной формы, на которой размещаются элементы управления (просмотра, редактирования) атрибутами объектов учета. 30.3. Для экранных контейнеров должна быть предусмотрена возможность выполнения следующих действий: 30.3.1. Изменение размеров контейнера (высота, ширина). 30.3.2. Перемещение контейнера по экранной форме, включая перемещение контейнера на другие вкладки (на свободное место экранной формы (не занятое другими элементами управления) имеющем размеры, достаточные для вмещения контейнера). 30.4. Должна быть предусмотрена возможность для каждого типа объектов учета создания произвольного количества контейнеров с размещением в них произвольного количества логически связанных атрибутов любых типов единым списком. Для каждого атрибута, размещаемого в создаваемом контейнере, должна быть предусмотрена возможность указания признака автоматического добавления атрибута в карточку объекта учета и порядкового номера по умолчанию отображения автоматически добавленных атрибутов в контейнере. Автоматически добавляемые атрибуты должны добавляться в контейнер автоматически с последующим возможным указанием пользователем их значения. Должна быть предусмотрена возможность визуальной индикации в контейнере атрибутов, добавленных автоматически, но значение которых пользователем еще не введены (по факту такие атрибуты для объекта учета еще не определены). 30.5. Для экранной формы должны быть предусмотрены следующие возможности по работе с вкладками: 30.5.1. Добавление вкладок. 30.5.2. Изменение наименований вкладок. 30.5.3. Изменение порядка следования вкладок. 30.5.4. Удаление вкладок, не содержащих элементов управления или контейнеров - Соответствие - - Значение характеристики не может изменяться участником закупки - 31. Требования к меню доступа к объектам учета и работы со списками: 31.1. Система должна содержать в своем составе средства настройки иерархического меню доступа к объектам учета всех типов с учетом возможностей по добавлению новых объектов учета. 31.2. Доступ к меню доступа к объектам учета должен предоставляться из основного окна Системы. 31.3. Доступ к каждому пункту меню должен осуществляться за минимальное количество действий пользователя. При возобновлении сеанса работы с Системой (повторном запуске Системы) позиция текущего пункта меню в иерархическом меню должна быть восстановлена автоматически, то есть доступ к объектам учета соответствующего типа должен осуществляться путем использования одного клика мыши. 31.4. Иерархическое меню должно иметь элементы следующих типов: 31.4.1. Промежуточные узлы – нажатие на этот пункт меню должно раскрывать следующий уровень иерархии (отображать вложенные пункты меню). 31.4.2. Промежуточные узлы-реестры – нажатие на данный пункт меню должен открыть объединенный список объектов учета, соответствующий совокупности объектов учета всех конечных элементов меню, вложенных с учетом иерархии в данный пункт (узел). Для данного типа пункта меню должна быть возможность открытия вложенных пунктов меню без открытия объединенного реестра. 31.4.3. Конечный узел – открывает список объектов учета, соответствующий данному пункту меню. 31.4.4. Конечный узел объединенного реестра – открывает объединенный список объектов учета, соответствующий конечным узлам пунктов меню, находящихся на этом же уровне иерархии (имеющих единый промежуточный узел). 31.5. В иерархическом меню должна быть предусмотрена возможность добавления пунктов, для которых может быть указан дополнительный фильтр, который автоматически применяется при отображении списка объектов, отображаемых с помощью данного пункта меню - Соответствие - - Значение характеристики не может изменяться участником закупки - 19. «Финансово-аналитическая подсистема»: 19.1. «Финансово-аналитическая подсистема» является ключевой с точки зрения определения и повышения эффективности неналоговых поступлений от использования муниципальной собственности. 19.2. Подсистема должна обеспечивать широкие возможности точной настройки на все нюансы федерального, регионального и местного законодательства, особенностей технологии управления имущественно-земельным комплексом, принятым в соответствующих органах управления собственностью и земельными ресурсами региона. 19.3. «Финансово-аналитическая подсистема» должна обеспечивать автоматизацию выполнения следующих основных задач: 19.3.1. Управление финансово-аналитической информацией (начислениями всех типов, платежами, задолженностью) в разрезах договоров, кодов бюджетной классификации (аналитических уровней), видов договоров, субъектов. 19.3.2. Автоматическое формирование начислений по договору возмездного и безвозмездного пользования, платы за фактическое использование, льготной арендной платы, платы за выкуп. Система автоматически должна определять, какой из видов начисления необходимо произвести в соответствии с условиями договорных соглашений (с учетом всех доп. соглашений и других корректировок), норм Гражданского Кодекса, в тех периодах использования объектов, которые не регулируются договором (в том числе фактическое использование объектов без договора, до заключения договора, в периоде до регистрации договора, после расторжения договора до даты освобождения объекта). 19.3.3. Автоматическое начисление пени, процентов, других штрафных санкций за пользование чужими денежными средствами. Система автоматически должна определять вид начисления (штрафных санкций) исходя из условий договора или руководствуясь нормами гражданского Кодекса в периоде фактического использования объекта. 19.3.4. Автоматическое доначисление по доп. соглашениям, изменяющим условия договора «задним числом». 19.3.5. Автоматический расчет сальдо - Соответствие - - Значение характеристики не может изменяться участником закупки - 19.3.6. Автоматический перерасчет планируемой платы по договору (например, в ходе массовой индексации по уровню инфляции). 19.3.7. Импорт платежей из электронных источников (выгрузка из ЭБ и др.). 19.3.8. Автоматическое, полуавтоматическое и ручное распределение и перераспределение поступлений по субъектам договоров, договорам, видам начислений. 19.3.9. Формирование информации о задолженности в любом разрезе и на произвольную дату. 19.3.10. Формирование информации о динамике возникновения задолженности. 19.3.11. Управление начислениями по решению суда, автоматизация работы с реструктуризацией задолженности. 19.3.12. Ведение протоколов выполнения автоматических операций, возможности по эвристическому анализу информационного фонда на предмет корректности исходной информации для выполнения автоматических операций. 19.3.13. Автоматизация работы с должниками. 19.3.14. Формирование необходимых печатных форм (в том числе справки о наличии/отсутствии задолженности, формирование претензий, исковых требований, детализации всех видов начислений для суда, формирование актов сверки) - Соответствие - - Значение характеристики не может изменяться участником закупки - 20. Требования к подсистеме «Автоматизация претензионной и исковой деятельности»: 20.1. Подсистема должна автоматизировать выполнение следующих основных задач: 20.1.1. Ведение полной информации по претензиям и исковым процессам, по требованиям, предъявленным к пользователям Системы и по имуществу пользователям Системы: 20.1.1.1. Договор или иной документ, на основании которого ведется претензионно-исковая деятельность. 20.1.1.2. Претензия, иск стороны для требований, предъявленных к пользователям Системы по имуществу. 20.1.1.3. Субъект (заявитель) претензии. 20.1.1.4. Объект. 20.1.1.5. Предмет претензионно-исковых требований: 20.1.1.5.1. требования имущественного характера (сумма к взысканию по различным видам начислений); 20.1.1.5.2. требований имущественного характера, не подлежащего оценке; 20.1.1.5.3. требования неимущественного характера. 20.1.2. Возможность формировать печатные формы претензий и исковых заявлений автоматически на основе данных из учетной системы. 20.1.3. Стороны (участники) иска, категория (вид) иска, признак особой важности. 20.1.4. Состояние иска (подготовка, в процессе, завершен). 20.1.5. Учет судебных дел и претензионно-исковых этапов: претензия, подготовка иска, подача иска, наименование суда, номер судебного дела, судья, инстанция (апелляция, кассация, в порядке надзора), дата и время судебного заседания, сотрудник правового отдела – исполнитель, судебные акты по делу (решения, определения о приостановлении производства по делу, об оставлении иска без рассмотрения, об оставлении иска без движения, о возвращении искового заявления, о прекращении производства по делу, о принятии к производству встречного иска, о принятии (отмене) мер по обеспечению иска). 20.1.6. Учет исполнительного производства: дата вступления судебного акта в законную силу, дата получения исполнительного листа, дата направления исполнительного листа в отдел судебных приставов, отдел судебных приставов, судебный пристав исполнитель, постановления пристава исполнителя. - Соответствие - - Значение характеристики не может изменяться участником закупки - 20.1.7. Учет конкурсного производства: суд, номер дела, дата введения процедур в отношении предприятия банкрота (определения суда), сведения о ходе процедур банкротства. 20.1.8. Возможность формирования отчета о сроках (длительности) претензионной работы, подготовки и подачи иска, рассмотрения дела в суде, исполнительного производства, конкурсного производства. 20.1.9. Возможность поиска судебных дел по различным критериям. 20.1.10. Наличие ссылки на страницу дела на сайте kad.arbitr.ru. 20.1.11. Возможность прикрепления файлов материалов к судебному делу (претензий, исков, судебных актов), к исполнительному производству (исполнительный лист, заявление о направлении исполнительного листа, постановления приставов-исполнителей), к конкурсному производству (судебные акты дела о банкротстве, извещения о проведении собраний кредиторов). 20.1.12. Контроль за ходом иска в разрезе исполнителя, уведомление исполнителя о необходимости завершения текущего искового этапа и перехода к следующему. 20.1.13. Предусмотреть экспорт данных в табличный формат (xlsx, csv). Возможность формирования необходимых печатных форм (с использованием встроенных генераторов отчетов). 20.1.14. Предусмотреть разграничение прав доступа. 20.1.15. Постановка и контроль исполнения задач/поручений сотрудниками правового отдела. 20.1.16. Протоколирование результатов расчета пени на расчетную дату. 20.1.17. Протоколирование результатов расчета задолженности по всем видам операций на расчетную дату, для возможности отслеживания изменений и анализа их причин - Соответствие - - Значение характеристики не может изменяться участником закупки - 32. Режим добавления объекта по шаблону: 32.1. В Системе должна быть предусмотрена возможность добавления объекта по шаблону на основе любого выбранного пользователем объекта, информация о котором уже содержится в единой базе данных Системы. 32.2. В режиме добавления объекта по шаблону должна создаваться карточка нового объекта соответствующего типа (как у объекта, на основе которого производится добавление) с полным копированием информации из исходного объекта в карточку добавляемого объекта, за исключением информации, идентифицирующей объект (реестровый номер, инвентарный номер, паспортные данные, ПТС транспортного средства) - Соответствие - - Значение характеристики не может изменяться участником закупки - 33. Требования к созданию нового типа (наименования списка, реестра) объекта учета 33.1. Средствами подсистемы должна быть обеспечена возможность создания реестров (списков) объектов двух основных видов: 33.1.1. Новый реестр/список объектов произвольной структуры, состава информации, атрибутов, характеристик. 33.1.2. Реестр/список объектов, являющихся частью одного или нескольких реестров объектов имущественно-земельного комплекса. Для объектов данного типа должна быть обеспечена возможность выбора одного или нескольких типов объектов (схожих по структуре данных), на основе которых формируется данный список объектов учета, а также возможность задания произвольного условия (без каких-либо ограничений по сложности условия), по которому осуществляется фильтрация объектов учета. 33.2. Должна быть предусмотрена возможность создания собственной электронной карточки объекта учета данного реестра, отличной от электронной карточки этого же объекта учета основного реестра. Однако, если в электронной карточке объекта в создаваемом реестре объектов учета присутствуют реквизиты, заполненные в карточке этого же объекта в основном реестре (реестре имущественно-земельного комплекса), то они должны отображаться в электронной карточке объекта учета данного реестра. Иными словами, должна быть обеспечена возможность собственного дизайна электронных карточек объектов учета отдельно для каждого создаваемого пункта меню (пункта меню доступа к создаваемому списку, реестру объектов учета). Электронная карточка должна создаваться адаптированной к эффективному решению именно той задачи, для которой создавался список соответствующих объектов - Соответствие - - Значение характеристики не может изменяться участником закупки - 19.3.15. Формирование необходимой аналитической отчетности. 19.3.16. Организация массовой рассылки уведомлений о необходимости погашения задолженности, об изменении условий договора, величины планируемой платы по договору. 19.3.17. Проведение экспресс-аналитики. 19.4. Помимо стандартных функций по управлению финансово-аналитической информацией, в подсистему должен быть включен ряд функций и возможностей, направленных на дополнительное расширение возможностей подсистемы как в части расширения функционала, так и в части настройки технологии учета под особенности внутреннего регламента по управлению финансово-аналитической информацией, технологии учета, особенности местного и регионального законодательства. 19.5. Настройка уровня аналитического учета: 19.5.1. В Системе должна быть предусмотрена возможность индивидуальной настройки уровня аналитического учета платежей и начислений за аренду этих объектов. 19.5.1.1. Учет платежей и начислений должен вестись как в разрезе субъектов договоров (арендаторы), плательщиков (оплата 3-ми лицами), так и по договорам (аренда, выкуп, неосновательное обогащение, учет и т.д.). Платежи распределяются как по субъектам договоров (арендаторы), так и по договорам (аренда, выкуп, неосновательное обогащение, учет и т.д.). Пени и другие штрафные санкции и сальдо рассчитываются также в разрезе субъектов и по договорам аренды. Возможно применение смешанной технологии учета, в которой основная технология выбрана в разрезе субъектов договоров (арендаторы), но для части договоров учет ведется в разрезе договоров. 19.5.1.2. Возможно ведение технологии учета в разрезе КБК (кодов бюджетной классификации). При таком ведении учета пени и сальдо рассчитываются индивидуально для каждого кода бюджетной классификации. Данный аналитический уровень может быть применен как при ведении учета в разрезе арендаторов, так и при ведении учета в разрезе договоров. 19.5.1.3. Ведение библиотеки алгоритмов выполнения автоматических операций - Соответствие - - Значение характеристики не может изменяться участником закупки - 19.5.1.4. Ведение библиотеки схем начисления арендной платы и сроков оплаты. 19.5.1.5. Библиотека схем начисления должна предоставлять следующие возможности: 19.5.1.6. Создание произвольного количества схем начисления. Под схемой начисления подразумевается алгоритм выполнения начисления, периодичностью (квартал, месяц, полугодие, набор месяцев) и сроки начисления. 19.5.1.7. Возможность создания и настройки произвольного количества периодичностей начисления (например, помесячное начисление, поквартальное, 2 раза в год для сельхоз. земель, 2 раза в год для других земель). При этом для каждой периодичности может быть указано произвольное количество периодов произвольной длительности. Для каждого периода индивидуальное указание произвольного срока оплаты. 19.5.1.8. Для каждого договора аренды указание индивидуальной схемы начисления из библиотеки (схема по умолчанию также должна настраиваться). 19.6. Расширение функциональных и аналитических возможностей блока: 19.6.1. В Системе должна быть реализована функция определения задолженности в любом разрезе. При этом функция должна рассчитать задолженность по состоянию на любую заданную дату как по базе целиком, так и по любому из перечисленных аналитических уровней (или их произвольному сочетанию): - Соответствие - - Значение характеристики не может изменяться участником закупки - 21. Требования к аналитической и сервисной подсистеме «Библиотека запросов»: 21.1. Средства подсистемы должны предоставлять возможность для проведения оперативных выборок и для выполнения запросов по индивидуальному или массовому изменению, добавлению, удалению информации в банке данных Системы, например, в ходе обслуживания информационного фонда. 21.2.Подсистема должна предоставлять средства оперативного построения, накопления и выполнения запросов произвольной сложности и произвольного содержания к единому информационному фонду Системы. Средства подсистемы должны быть максимально интуитивны и просты в использовании, выполнение запросов не требует каких-либо специальных знаний и навыков от пользователей. 21.3. Количество запросов, которые могут быть добавлены в подсистему, должно быть не ограничено. Добавление запросов в подсистему должно выполняться средствами подсистемы, не требовать обновления Системы или ее компонентов, привлечения разработчиков Системы. 21.4. Запросы могут содержать произвольное количество параметров любых типов (даты, числа, строки, данные из любых справочников и классификаторов Системы), фактические значения которых указываются пользователем в момент выполнения выбранного запроса, что в значительной степени повышает оперативность и точность получения данных в результате выполнения запроса. 21.5. Должна быть предусмотрена возможность непосредственно из результатов выполнения запроса открыть электронную карточку объекта, по которому содержится информация в соответствующей строчке результатов выполнения запроса. 21.6. Подсистема должна предоставлять возможность дополнительного постанализа данных (анализ после получения результата выполнения запроса в табличном виде), полученных в результате выполнения запроса: - Соответствие - - Значение характеристики не может изменяться участником закупки - 21.6.1. Группировка данных по одному или нескольким полям, что в значительной степени может повысить информативность полученных данных. Например, данные по должникам можно сгруппировать по району плательщика, кодам бюджетной классификации и видам начислений. 21.6.2. Вычисление общих итогов, в том числе для каждой из групп (в случае применения группировки). Например, для приведенного примера возможна автоматическая калькуляция общей задолженности арендаторов, а также задолженности по каждому из районов, коду бюджетной классификации и виду начисления. 21.6.3. Дополнительная оперативная фильтрация данных по значениям любого поля\совокупности полей. 21.6.4. Сортировка данных по произвольному полю\совокупности полей. Должна быть предусмотрена возможность экспорта сформированных данных в табличные форматы (xlsx, csv), текстового файла, xml или внутренние форматы генератора отчетов. При этом должна быть обеспечена возможность экспорта данных, в том чисел в формат xml сложной структуры с учетом всех сортировок, группировок, итогов и прочего форматирования, которые были наложены на результат запроса в окне результата запроса. 21.7. В случае содержания в результатах запроса сведений об объектах учета единого банка данных Системы должен быть реализован быстрый доступ (двойной «щелчок мыши») к карточкам соответствующих объектов учета. 21.8. Средства подсистемы должны предоставлять возможность администратору Системы мониторинга состояния информационного фонда Системы, анализа целостности, непротиворечивости данных, регулярного обслуживания банка данных. - Соответствие - - Значение характеристики не может изменяться участником закупки - 34. Требования к созданию формы работы со списком объектов учета соответствующего типа: 34.1. Для списков работы с объектами учета новых типов (не объектов имущественно-земельного комплекса, описанных выше) должна быть предусмотрена возможность создания формы работы со списком (реестром) объектов, содержащих произвольное количество полей (колонок, столбцов) произвольной структуры без ограничений на сложность формирования данных, размещаемых в соответствующих полях (колонках, столбцах) списка объектов учета. В том числе, в полях списка могут размещаться произвольные данные из единой базы данных Системы, выведенные по любому заданному алгоритму произвольной сложности. 34.2. Форма работы со списком должна обладать всеми возможностями по дальнейшему анализу данных: 34.2.1. Группировка данных по одному или нескольким столбцам. Например, реестр может быть сгруппирован по состоянию объектов учета, району города, разрешенному использованию. 34.2.2. Вычисление общих итогов, в том числе для каждой из групп (в случае применения группировки). Например, для приведенного примера возможна автоматическая калькуляция общей планируемой платы, площади объектов, величины задолженности в разрезе состояний договоров аренды, района расположения объекта договора, целевого использования. 34.2.3. Дополнительная оперативная фильтрация данных по значениям любого столбца\совокупности столбцов. 34.2.4. Сортировка данных по произвольному столбцу\совокупности столбцов. 34.2.5. Возможность выбора отображаемых столбцов. 34.2.6. Автоматическое сохранение настроек табличного представления для каждого типа объектов учета. 34.3. Должна быть предусмотрена возможность экспорта сформированных данных в форматы xlsx, xml, текстового файла или внутренние форматы генератора отчетов - Соответствие - - Значение характеристики не может изменяться участником закупки - 35. Требования к созданию формы поиска/фильтрации 35.1. Подсистема должна обладать инструментами создания формы поиска/фильтрации объекта по любому количеству критериев следующих типов: 35.1.1. Целочисленный. 35.1.2. Число с плавающей точкой. 35.1.3. Строковый. 35.1.4. Дата. 35.1.5. Значение из справочника или списка допустимых вариантов выбора. В качестве справочника может быть использован частично (по произвольному заданному условию фильтрации) или полностью любой из классификаторов Системы, а также любой перечень допустимых элементов выбора, сформированный как вручную, так и путем выборки по задаваемому алгоритму из произвольной информации, размещенной в единой базе данных Системы. 35.2. Форма поиска должна содержать произвольное количество параметров фильтрации в заданном порядке. 35.3. Для каждого критерия поиска в форме поиска/фильтрации должны создаваться элементы управления, содержащие следующую информацию: 35.3.1. Наименование критерия поиска на русском языке. 35.3.2. Перечень допустимых логических условий поиска (равно, не равно, больше, меньше, больше или равно, меньше или равно, содержит, начинается с, не содержит, не начинается, заполнено, не заполнено и т.п.). Перечень зависим от используемого типа данных реквизита (критерия) поиска. 35.3.3. Вводимое значение для поиска. 35.4. Должна быть предусмотрена возможность формирования критериев поиска как по любому атрибуту или характеристике объекта учета, так и по любым заданным условиям произвольной сложности и алгоритмизации - Соответствие - - Значение характеристики не может изменяться участником закупки - 36.5.16. Коэффициенты. 36.5.17. Примечание. 36.5.17. Связанные объекты имущества. 36.5.19. Связанные земельные участки - Соответствие - - Значение характеристики не может изменяться участником закупки - 19.6.1.1. Вычисление задолженности по договорам определенного типа (аренда, купля/продажа земельных участков, недвижимого, движимого имущества, объектов наружной рекламы, имущественных комплексов) или по всем типам. 19.6.1.2. Вычисление общей задолженности по субъекту договора или по всем субъектам. 19.6.1.3. Вычисление задолженности по договору или всем договорам. 19.6.1.4. Вычисление общей задолженности по определенному виду начисления или по всем видам. 19.6.1.5. Вычисление общей задолженности по определенному КБК или по всем КБК 19.6.1.6. В Системе должны быть предусмотрены следующие возможности: 19.6.1.7. Возможность запуска операции автоматического начисления арендной платы по диапазону периодов, годов. 19.6.1.8. Протоколирование выполнения всех автоматических операций и эвристический анализ состояния информационного фонда на поиск ошибок и потенциальных ошибок. 19.6.1.9. Выполнение любой автоматической операции должно сопровождаться формированием подробного протокола выполнения операции, в который в текстовом, понятном пользователю виде заносятся все операции, которые были произведены системой со всеми объектами учета. Одновременно, система должна выполнять комплекс эвристических проверок состояния информационного фонда системы на поиск ошибок или потенциальных ошибок, которые потенциально могут повлиять на корректность полученного результата. 19.6.1.10. Протоколы выполнения всех автоматических операций должны хранится в базе на постоянной основе и быть доступны для анализа в любой момент времени (возможность постанализа результатов выполнения операции). 19.6.1.11. Автоматический расчет и отображение «горячих итогов» (автовычисляемая и отображаемая на экране задолженность по заданным видам начисления (настраивается) по состоянию на текущую дату) по каждому субъекту (всем договорам субъекта общей суммой) и/или договору - Соответствие - - Значение характеристики не может изменяться участником закупки - 19.6.2. В автоматическом режиме Система должна рассчитывать и отображать следующие данные: 19.6.2.1. Задолженность по арендной плате/плате за выкуп по состоянию на текущее число. 19.6.2.2. Задолженность по пене по состоянию на текущее число. 19.6.2.3. Общая задолженность (по всем видам начисления) по состоянию на текущее число. 19.6.2.4. Текущая пеня (сумма пени, рассчитанная на текущий момент). 19.6.2.5. Всего начислено с начала года. 19.6.2.6. Текущая сумма планируемой арендной платы/платы за выкуп. 19.6.3. Поля «горячих» итогов должны поддерживать настройку на отображение итогов по любому виду начисления (глобальная настройка по Системе целиком). Должна быть предусмотрена возможность настройки не менее 10 показателей «горячих итогов» - Соответствие - - Значение характеристики не может изменяться участником закупки - 12.5.1.13. Принадлежность к земельному участку (множественная связь – один объект может быть размещен на нескольких земельных участках, на одном земельном участке может быть размещено несколько объектов). 12.5.1.14. Принадлежность к другим объектам (список объектов имущества, включенных в заданный объект (размещенных в пределах заданного объекта), например, перечень объектов, составляющих объект имущественного комплекса, перечень квартир в жилом здании, перечень комнат в квартире). Должна быть предусмотрена возможность связывать объект с ранее учетными в единой базе данных Системы объектами, включенными в данных объект (размещенными в пределах данного объекта). Должна быть предусмотрена возможность указания обратной связи – для ранее учтенного в единой базе Системы объекта указать объект, в который включен (в пределах которого размещен) заданный объект. 12.5.1.15. Признак принадлежности к объектам культурного наследия, а также информация о включении объекта в реестр объектов культурного наследия (Номер в реестре, категория историко-культурного наследия – справочник, Признак принадлежности объекта к объектам религиозного значения, признак принадлежности объекта к ансамблям, ссылка на документ-основание с возможностью указания нескольких документов оснований и период нахождения объекта в реестре с возможностью учета разных периодов включения объектов и соответственно разных данных по нахождению объекта в реестре). 12.5.1.16. Информация по проводимым аукционам, торгам, конкурсам - Соответствие - - Значение характеристики не может изменяться участником закупки - 12.5.1.17. Классификация объектов учета – предусмотрена возможность учета произвольного количества категорий классификации с произвольным количеством элементов классификации в каждой из категорий, а также текстовым описанием каждого элемента – с историей изменений и ссылками на документы-основания присвоения элемента классификации и исключения объекта из классификации (множественность документов-ссылок). 12.5.1.18. События (даты) – с историей изменений и ссылкой на документ-основание. 12.5.1.19. Признаки («галочки») - принадлежность к чему-либо с текстовым описанием признака. 12.5.1.20. Договоры использования и обременения (аренды, купли-продажи, безвозмездного пользования, согласования, разрешения, размещения, сервитуты). 12.5.1.21. Информация по претензионной и исковой деятельности (детальная информация по поданным претензиям и искам, включая необходимую классификационную и описательную части, предметы исков, в том числе суммы с делением по видам начислений, перечень этапов претензионной и исковой деятельности с указанием ссылок на документы этапа, уточнение требований) – см. пункт «Подсистема автоматизации претензионной и исковой деятельности». 12.5.2. Автоматическое присвоение реестрового номера с возможностью настройки методики и структуры формирования номера, а также возможностью организации сквозной нумерации по нескольким видам объектов учета (настройка категорий нумерации, для каждой категории можно указать перечень видов объектов учета, входящих в категорию). 12.5.3. Ведение информации по подобъектам, составным частям объектов. 12.5.4. Управление историей изменения основных характеристик объектов и документами-основаниями на проведение изменений - Соответствие - - Значение характеристики не может изменяться участником закупки - 3. Требования к серверу приложений: 3.1. Сервер приложений для Системы должен обеспечивать предоставление доступа клиентских мест к данным Системы, а также содержать средства обеспечения корректности исполнения технологических процессов (бизнес-логики) функционирования Системы. 3.2. Сервер приложений не должен требовать ручного запуска перед началом работы пользователей Системы. 3.3. Сервер приложений должен обеспечивать передачу клиентским местам информацию порциями по настраиваемому количеству записей (количество записей, которое помещается на экран без прокрутки при любом из используемых разрешений экрана) по мере обращения. 3.4. Передача информации на клиентское место из используемых справочников и классификаторов должна производиться при первом обращении к справочникам и классификаторам (за исключением системных справочников и классификаторов, необходимых для функционирования Системы в целом). 3.5. Передача информации на клиентское место по открытым электронным карточкам объектов учета должна производиться только в том объеме, в котором информация отображается в соответствующий момент в карточке объекта учета - Соответствие - - Значение характеристики не может изменяться участником закупки - 12.5.5. Управление движением объектов в реестре (включение, исключение, перемещение между реестрами, ведение истории реорганизации объектов (слияния, разделения)). 12.5.6. Управление движением объектов на балансе и в казне, договорами оперативного управления и хозяйственного ведения. 12.5.7. Обеспечение информационного взаимодействия/обмена информацией по объектам муниципальной собственности с субъектами права (балансодержателями и др.) – массовое обновление стоимостных показателей (балансовая, остаточная стоимость, износ), характеристик объектов. 12.5.8. Управление движением объектов в казне (с возможностью ведения балансового и забалансового бюджетного учета движения объектов в казне). 12.5.9. Ведение документального обеспечения (документов-оснований) движения объектов, изменения характеристик объектов в реестре. 12.5.10. Ведение аукционов и торгов на право аренды или купли-продажи объектов. 12.5.11. Формирование реестров объектов муниципальной собственности. 12.5.12. Формирование выписок из реестров, справок о движении объектов, проектов приказов, постановлений, распоряжений, других необходимых печатных форм. 12.5.13. Формирование аналитической отчетности. 12.5.14. Проведение экспресс-аналитики. 12.5.15. Корректное проставление даты выбытия объекта в зависимости от выбранного документа основания (например, выбытие по исключению из реестра или из-за регистрации права собственности за иным лицом). 12.5.16. Возможность указания шаблона для вывода адреса в нужном формате - Соответствие - - Значение характеристики не может изменяться участником закупки - 12.5.17. Возможность работы со справочниками ФИАС при формировании адреса. 12.5.18. Управление историей объектов для отслеживания хронологии реорганизации, разделения, объединения объекта. 12.5.19. Протоколирование действий пользователей. 12.5.20. Возможность прикрепления к карточке объекта учета произвольного количества файлов произвольного типа. 12.5.21. Возможность ведения информации о внереестровых объектах. 12.6. Должна быть предусмотрена возможность смены типа объектов, включенных по ошибке в другие подразделы имущества (в том числе объектов прошлых периодов), например, изменить тип «нежилое здание» на «нежилое помещение» или на «сооружение» и наоборот - Соответствие - - Значение характеристики не может изменяться участником закупки - 13. Требования к подсистеме «Земля»: 13.1. Подсистема «Земля» должна автоматизировать ведение реестров земельных участков, собственность на которую разграничена, а также ведение земельных участков, собственность на которые не разграничена или с другими видами собственности, находящихся в сфере компетенции органов управления земельными ресурсами. 13.2. Подсистема должна автоматизировать выполнение следующих основных задач: 13.2.1. Пообъектный учет земельных участков (ЗУ). Для каждого из ЗУ ведется следующая основная информация: 13.2.1.1. Наименование ЗУ. 13.2.1.2. Принадлежность к реестру, подреестру (с историей изменения). 13.2.1.3. Кадастровый номер (кадастровый квартал выбирается из классификатора, не обязательный для заполнения). 13.2.1.4. Категория земель (с историей изменения и ссылками на документы-основания). 13.2.1.5. Разрешенное использование (с историей изменения и ссылками на документы-основания). 13.2.1.6. Уровень собственности (состояние) - Соответствие - - Значение характеристики не может изменяться участником закупки - 4. Требования к размещению средств обеспечения корректности исполнения технологических процессов (бизнес-логики) Системы: 4.1. Средства обеспечения корректности исполнения технологических процессов (бизнес-логики) в максимально возможном объеме должны быть реализованы на уровне базы данных (выполняться в автоматическом режиме на уровне СУБД). 4.2. На уровне СУБД должны быть реализованы следующие процессы (технологические процессы или их части): 4.2.1. Ведение аудита действий пользователей на уровне полей таблиц (конкретных атомарных атрибутов объектов учета, в том числе в составе составных характеристик). 4.2.2. Проверка прав пользователей (хранимые функции или процедуры проверки прав пользователей). 4.2.3. Поддержка функционирования средств «быстрого поиска» (по необходимости). 4.2.4. Формирование проводок бюджетного учета по администрируемым кодам бюджетной классификации при внесении изменений в данные финансово-аналитической подсистемы в соответствии с требованиями Министерства финансов РФ. 4.2.5. Расчет суммы планируемой платы по договорам. 4.2.6. Начисление арендной платы, платы за выкуп, платы за фактическое использование объектов, всех видов штрафных санкций, включая начисление пени, процентов за пользование чужими денежными средствами. 4.2.7. Расчет сальдо. 4.2.8. Расчет задолженности на произвольную дату в произвольном разрезе. 4.2.9. Пересчет задолженности на текущее число по всем видам договорных отношений. 4.2.10. Алгоритмы парсинга (разбора) сведений, получаемых по протоколам СМЭВ в машиночитаемом виде (xml). 4.2.11. Алгоритмы автоматического и полуавтоматического внесения информации в информационный фонд Системы на основе полученных сведений по протоколам СМЭВ. 4.3. Средства обеспечения технологических процессов, которые не могут быть реализованы на стороне СУБД, должны быть реализованы средствами сервера приложения. 4.4. На клиентском месте должны быть продублированы те элементы технологических процессов, которые могут определить некорректные действия - Соответствие - - Значение характеристики не может изменяться участником закупки - 5. Требования к способам и средствам связи для информационного обмена между компонентами Системы: 5.1. Система должна обеспечивать коллективную работу пользователей объекта автоматизации с использованием единого интегрированного хранилища данных по технологии «клиент-сервер» с использованием трехзвенной архитектуры. 5.2 Количество клиентских подключений к серверу не менее 30 (тридцать). - Соответствие - - Значение характеристики не может изменяться участником закупки - 6. Требования к приспособляемости Системы: 6.1. Функциональность Системы должна допускать наращивание функциональных возможностей на основе подключения дополнительных (или изменения существующих) подсистем в связи с изменением существующих и возникновением новых автоматизируемых процессов, обусловленных изменениями в нормативно-законодательной базе. 6.2. Подсистемы должны иметь программные интерфейсы, обеспечивающие возможность расширения функциональности Системы путём добавления компетентными, обученными пользователями Системы дополнительных программных модулей. 6.3. Система должна быть легко настраивающейся на изменения условий функционирования и организационной структуры объектов автоматизации Системы. 6.4. Система должна сохранять работоспособность при увеличении количества пользователей в пределах, поддерживаемых аппаратно-программной средой серверов технологического узла. 6.5. Должна быть обеспечена возможность увеличения числа пользователей Системы - Соответствие - - Значение характеристики не может изменяться участником закупки - 13.2.1.7. Реестровый номер (с историей изменения и ссылками на документы-основания). 13.2.1.8. Адрес, адресный ориентир (с возможностью ввода множественного адреса). Должна быть предусмотрена возможность указания государственного образования для обеспечения возможности дальнейшего отбора земельных участков по соответствующему показателю. 13.2.1.9. Субъекты права (землепользователи, другие субъекты права) – с историей изменения, множественностью документов-оснований возникновения и прекращения права (ссылки на документы), в том числе и права постоянного (бессрочного) пользования. 13.2.1.10. Экономические показатели (Кадастровые стоимости и др.) – с историей изменения и ссылками на документы-основания. 13.2.1.11. Технические показатели (с историей изменения и ссылками на документы-основания). 13.2.1.12. Документы (все документы, имеющие отношение к данному объекту с делением по направлениям воздействия документов (включение/исключение, внесение изменений, правоустанавливающие, регистрирующие документа)). 13.2.1.13. Комиссии. 13.2.1.14. Коэффициенты-характеристики, площадь (с историей изменения и ссылками на документы-основания). 13.2.1.15. Информация по использованию ЗУ (классификация для аналитики, ставки арендной платы, типы использования для кадастровой оценки, налоговые ставки по типам использования) с возможностью указания различных типов использования долей земельного участка (с историей изменения и ссылками на документы-основания). 13.2.1.16. Перечень объектов недвижимого имущества, размещенных на данном участке. (кадастровый номер, наименование, права) 13.2.1.17. Информация по проводимым аукционам, торгам, конкурсам - Соответствие - - Значение характеристики не может изменяться участником закупки - 13.2.1.18. Классификация объектов учета – предусмотрена возможность учета произвольного количества категорий классификации с произвольным количеством элементов классификации в каждой из категорий, а также текстовым описанием каждого элемента – с историей изменений и ссылками на документы-основания присвоения элемента классификации и исключения объекта из классификации (множественность документов-ссылок). 13.2.1.19. Информация по претензионной и исковой деятельности (детальная информация по поданным претензиям и искам, включая необходимую классификационную и описательную части, предметы исков, в том числе суммы с делением по видам начислений, перечень этапов претензионной и исковой деятельности с указанием ссылок на документы этапа, уточнение требований) – см. Пункт «Подсистема автоматизации претензионной и исковой деятельности». 13.2.1.20. События (даты) – с историей изменений и ссылкой на документ-основание. 13.2.1.21. Признаки («галочки») - принадлежность к чему-либо с текстовым описанием признака. 13.2.1.22. Договоры использования и обременения (аренды, купли-продажи, безвозмездного пользования, согласования, разрешения, размещения, сервитуты). 13.2.2. Автоматическое присвоение реестрового номера с возможностью настройки методики и структуры формирования номера, а также возможностью организации сквозной нумерации по нескольким видам объектов учета (настройка категорий нумерации, для каждой категории можно указать перечень видов объектов учета, входящих в категорию). 13.2.3. Управление историей изменения основных характеристик ЗУ, документами-основаниями на проведение изменений. 13.2.4. Управление движением ЗУ в реестре (включение, исключение, перемещение между реестрами, ведение истории реорганизации объектов (слияния, разделения)). 13.2.5. Управление движением ЗУ по субъектам права. 13.2.6. Управление движением ЗУ в казне (с возможностью ведения балансового и забалансового бюджетного учета движения объектов в казне) - Соответствие - - Значение характеристики не может изменяться участником закупки - 7. Требования к защите информации от несанкционированного доступа: 7.1. Система должна обеспечивать идентификацию и аутентификацию пользователя, обратившегося для получения доступа к функциям Системы. В Системе должны быть обеспечены разграничение и администрирование доступа к компонентам Системы. 7.2. Механизмы безопасности Системы должны позволять ограничивать круг лиц, принимающих участие в работе с данными, и позволять контролировать процесс работы с защищенными документами и знать, откуда возможна утечка информации. 7.3. Защита информации от несанкционированного доступа в Системе должна обеспечиваться реализацией следующих функций Системы: 7.3.1. Предоставление доступа к Системе должно предоставляться только предварительно зарегистрированным пользователям. 7.3.2. Возможность разграничения доступа к подсистемам для каждого пользователя. 7.3.3. Возможность для каждого пользователя установить уровень доступа, обеспечивающий только просмотр или редактирование информации. 7.3.4. Управление разграничением и/или уровнями доступа пользователей должно осуществляться через группы доступа. 7.3.5. Разграничение по доступу к данным Системы должно быть согласно утвержденным полномочиям пользователей Системы. 7.3.6. Регистрация входа (выхода) пользователей в Систему (из Системы) должна фиксироваться в журнале действий пользователей. 7.3.7. Должна быть возможность функционального разграничения действий пользователей при обработке информации. 7.3.8. Ведение справочника пользователей Системы. 7.3.9. Журналирование действий пользователей, которое должно обеспечиваться путем ведения в Системе «журнала событий», доступного только с автоматизированного рабочего места администратора и включающего в себя следующие данные: 7.3.9.1. Системные действия: дата, событие, пользователь. 7.3.9.2. Действия над пользователями Системы: дата, событие, администратор. 7.3.9.3. Действия пользователей. 7.4. «Журнал событий» должен быть недоступен к внесению изменений - Соответствие - - Значение характеристики не может изменяться участником закупки - 7.5. Система должна обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях Система должна выдавать пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных. 7.6. Должна быть предусмотрена возможность резервного копирования и ручного восстановления стандартными средствами системы управления базой данных (далее – СУБД) администраторами Системы обрабатываемой информации из резервной копии в следующих аварийных ситуациях: 7.6.1. Ошибочные действия пользователей (администраторов), приведшие к утрате или искажению данных Системы. 7.6.2. Отказ Системы, связанный с фатальным нарушением целостности файловой системы или структуры баз данных. 7.7. Для резервного копирования должны использоваться штатные средства системной программной платформы, причем организация баз данных Системы должна обеспечивать сохранение: 7.7.1. Всех параметров настройки Системы, включая учетные записи и персональные настройки пользователей. 7.7.2. Всей информации Системы - Соответствие - - Значение характеристики не может изменяться участником закупки - 8. Требования к патентной чистоте: 8.1. По результату исполнения контракта Система должна отвечать требованиям по патентной чистоте согласно действующему законодательству Российской Федерации, в Системе не должны использоваться решения, приводящие к нарушению смежных прав и прав третьих лиц, защищенные патентами или иными действующими на территории Российской Федерации документами, удостоверяющими авторские права на них, без соответствующего лицензионного соглашения с авторами данных решений. Выполнение требований по обеспечению лицензионной чистоты Системы возлагается на Исполнителя - Соответствие - - Значение характеристики не может изменяться участником закупки - 13.2.7. Ведение документального обеспечения (документов-оснований) движения ЗУ, изменения характеристик объектов в реестре. 13.2.8. Ведение аукционов и торгов на право аренды или купли-продажи ЗУ. 13.2.9. Формирование реестров земельных участков. 13.2.10. Формирование выписок из реестра, справок о движении ЗУ, проектов приказов, постановлений, распоряжений, других необходимых печатных форм. 13.2.11. Формирование аналитической отчетности в соответствующей сфере. 13.2.12. Проведение экспресс-аналитики. 13.2.13. Корректное проставление даты выбытия объекта в зависимости от выбранного документа основания (например, выбытие по исключению из реестра или из-за регистрации права собственности за иным лицом). 13.2.14. Возможность указания шаблона для вывода адреса в нужном формате. 13.2.15. Возможность работы со справочниками ФИАС при формировании адреса. 13.2.16. Управление историей объектов для отслеживания хронологии реорганизации, разделения, объединения объекта. 13.2.17. Протоколирование действий пользователей. 13.2.18. Возможность прикрепления к карточке объекта учета произвольного количества файлов произвольного типа. 13.2.19. Возможность ведения информации о внереестровых объектах - Соответствие - - Значение характеристики не может изменяться участником закупки - 9. Требования к контролю, хранению, обновлению и восстановлению данных: 9.1. Контроль корректности данных должен обеспечиваться реализацией функций форматного, логического контроля на уровне пользовательских форм. 9.2. Для хранения данных Системы должна использоваться СУБД, средствами которой выполняются действия записи, обновления, журналирования изменений, резервного копирования и восстановления данных - Соответствие - - Значение характеристики не может изменяться участником закупки - 10. Требования к лингвистическому обеспечению 10.1. В системных диалогах с пользователями в текстах сообщений должен применяться русский язык, за исключением сообщений общесистемного ПО, не подлежащих переводу на русский язык. 10.2. Содержание используемых в Системе справочников должно быть реализовано на русском языке - Соответствие - - Значение характеристики не может изменяться участником закупки - 11. Состав Системы: 11.1. Система состоит из следующих подсистем, средств и других элементов, выполняющих соответствующие функции: 11.1.1. Подсистемы и средства Системы, входящие в базовую конфигурацию: 11.1.2. Подсистема «Имущество» 11.1.2. Подсистема «Земля». 11.1.3. Подсистема «Ведение информации по субъектам права». 11.1.4. Подсистема «Ведение информации по акциям, долям». 11.1.5. «Адресная подсистема». 11.1.6. Подсистема «Ведение договоров и дополнительных соглашений» 11.1.7. Подсистема «Выкуп с рассрочкой». 11.1.8. «Финансово-аналитическая подсистема». 11.1.9. Подсистема «Автоматизация претензионной и исковой деятельности». 11.1.10. Аналитическая и сервисная подсистема «Библиотека запросов». 11.1.11. Подсистема «Формирование отчетов и печатных форм, генератор отчетов». 11.1.12. Подсистема «Обеспечение безопасности, администрирования и разграничения прав доступа». 11.1.13. Подсистема «Ведение нормативно-справочной информации». 11.1.14. Подсистема «Автоматическое обновление клиентских рабочих мест». 11.1.15. Подсистема «Оповещение пользователей». 11.1.16. Подсистема «Самодиагностика с оповещением о выявленных аномалиях по электронной почте». 11.1.17. Средства ведения электронных карточек объектов учета. 11.1.18. Средства поиска, отображения и анализа информации. 11.1.19. Средства предварительного просмотра. 11.1.20. Средства выполнения массовых операций. 11.2. Дополнительные подсистемы Системы: 11.2.1. Подсистема «Бюджетный учёт доходов». 11.2.2. Подсистема «Бюджетный учёт движения объектов в казне». 11.2.3. Подсистема «Управление объектами жилого фонда», включая подсистему «Аварийное жилье - учет и управление». 11.2.4. Подсистема «Управление взносами на капитальный ремонт». 11.2.5. Подсистема «Ведение проверок использования имущества и земельных участков». 11.2.6. Подсистема межведомственного электронного взаимодействия (платформа СМЭВ). 11.2.7. Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» - Соответствие - - Значение характеристики не может изменяться участником закупки - 11.2.8. Подсистема «Межведомственное электронное взаимодействие с Росреестром». 11.2.9. Подсистема «Межведомственное электронное взаимодействие с ЗАГС» - Соответствие - - Значение характеристики не может изменяться участником закупки - 12. Требования к подсистеме «Имущество»: 12.1. Подсистема «Имущество» должна автоматизировать ведение реестра объектов муниципальной собственности, а также внереестровых объектов всех учитываемых типов. 12.2. Доступ к объектам имущества должен осуществляться из основного окна Системы с использованием иерархического меню. 12.3. Перечень учитываемых типов и конкретная настройка иерархического меню доступа к объектам должны быть определены на этапе обследования организации. Например, иерархическое меню доступа и перечень учитываемых типов объектов могут быть настроены в ручном режиме, например, в соответствии со схемой: 12.3.1. Недвижимое имущество: 12.3.1.1. Жилой фонд: 12.3.1.1.1. Жилые здания. 12.3.1.1.2. Жилые квартиры, помещения. 12.3.1.1.3. Жилые комнаты. 12.3.1.2. Нежилые здания. 12.3.1.3. Нежилые помещения. 12.3.1.4. Объекты незавершенного строительства. 12.3.1.5. Объекты инженерной инфраструктуры, сооружения. 12.3.1.6. Объекты внешнего благоустройства. 12.3.1.7. Доли. 12.3.1.8. Нематериальные активы, объекты интеллектуальной собственности. 12.3.1.9. Воздушные и морские суда, суда внутреннего плавания. 12.3.1.10. Космические объекты. 12.3.1.11. Прочие объекты, не включенные в указанные группировки - Соответствие - - Значение характеристики не может изменяться участником закупки - 12.3.2. Движимое имущество: 12.3.2.1. Особо ценное движимое имущество. 12.3.2.2. Малоценное (прочее) движимое имущество. 12.3.2.3. Транспортные средства. 12.3.2.4. Объекты инженерной инфраструктуры. 12.3.2.5. Прочее движимое имущество, не относящиеся к указанным выше. 12.3.3. Акции, паи, доли. 12.3.4. Имущественные комплексы. 12.3.5. Муниципальные предприятия и учреждения. 12.4. Должна быть предусмотрена возможность скрытия неиспользуемых на момент внедрения пунктов меню (видов объектов учета). 12.5. Подсистема должна автоматизировать выполнение следующих основных задач: 12.5.1. Учет объектов. Для каждого из объектов должна вестись следующая основная информация: 12.5.1.1. Наименование объекта. 12.5.1.2. Принадлежность к реестру, подреестру (с историей изменения и ссылками на документы-основания). 12.5.1.3. Реестровый номер (с историей изменения и ссылками на документы-основания). 12.5.1.4. Кадастровый номер (не обязательный для заполнения, при наличии – обязательный для заполнения), условный номер. 12.5.1.5. Адрес (с возможностью ввода множественного адреса). 12.5.1.6. Субъекты права (движение на балансе, другие субъекты права) – с историей изменения, множественностью документов-оснований возникновения и прекращения права (ссылки на документы) - Соответствие - - Значение характеристики не может изменяться участником закупки - 12.5.1.7. Экономические показатели (балансовые, остаточные стоимости и др.) – с историей изменения и ссылками на документы-основания. 12.5.1.8. Технические показатели (с историей изменения и ссылками на документы-основания). 12.5.1.9. Документы (все документы, имеющие отношение к данному объекту с делением по направлениям воздействия документов (включение/исключение, внесение изменений, правоустанавливающие, регистрирующие документа) – без ограничения количества и типов регистрируемых документов). 12.5.1.10. Комиссии. 12.5.1.11. Коэффициенты-характеристики, площадь (с историей изменения и ссылками на документы-основания). 12.5.1.12. Части помещений (подвал, полуподвал, этажи): 12.5.1.12.1. Коэффициенты-характеристики частей помещений, площадь (с историей изменения и ссылками на документы-основания). 12.5.1.12.2. Типы использования частей помещений (с историей изменения и ссылками на документы-основания). 12.5.1.12.3. Материал стен, варианты входа, уровни благоустройства, высота потолков – произвольное количество категорий благоустройства с произвольным количеством выбираемых элементов благоустройства в каждой категории, предусмотрена возможность указания уровней благоустройства объекта целиком и каждой из частей помещения отдельно - Соответствие - - Значение характеристики не может изменяться участником закупки - Класс программ для электронных вычислительных машин и баз данных - (12.20) Информационные системы для решения специфических отраслевых задач - - Значение характеристики не может изменяться участником закупки - Способ предоставления - Экземпляр на материальном носителе - - Значение характеристики не может изменяться участником закупки - Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки

Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке

Передача неисключительных прав на Автоматизированную систему управления имущественно-земельным комплексом:1. Требования к структуре Системы: 1.1. Система должна быть построена по 3х-звенной архитектуре и состоять из следующих компонентов: 1.1.1. Системы управления базами данных (СУБД) – предназначены для хранения и управления информацией базы данных Системы. 1.1.2. Сервер приложений – промежуточное звено обеспечения взаимодействия клиентских мест и СУБД. 1.1.3. Клиентские места – «тонкий» (Desktop) клиент - пользовательские приложения, устанавливаемые на рабочих местах пользователей для предоставления доступа пользователей к функциям Системы - Соответствие - - Значение характеристики не может изменяться участником закупки

2. Требования к используемым СУБД: 2.1. Система должна быть совместима с СУБД PostgreSQL версии не менее 14.10. 2.2. СУБД не должна иметь ограничений по размеру базы данных и не должна требовать дополнительных обязательных расходов на сопровождение - Соответствие - - Значение характеристики не может изменяться участником закупки

60. Средства формирования межведомственных запросов из карточки объекта Системы: 60.1. Формирование межведомственных запросов из карточки объекта Системы подразумевает возможность автоматического формирования запроса в системе СМЭВ. Параметры, необходимые для формирования запроса в автоматическом режиме должны заполняться на основе данных, размещенных в соответствующей карточке объекта учета, из которой формируется запрос. 60.2. При формировании запроса пользователь должен предварительно выбрать услугу (сервис), для которой формируется запрос. Выбор должен производиться из перечня услуг (сервисов), для которых доступно формирование запроса из карточки объекта данного типа. 60.3. Формирование запроса должно быть реализовано с использованием динамически формируемого перечня пунктов подменю пункта «СМЭВ» меню карточки (или кнопки СМЭВ). 60.4. Динамически формируемый перечень подменю должна соответствовать перечню доступных для запроса услуг/сервисов с отбивкой сепаратором услуг/сервисов различных организаций (услуги/сервисы различных организаций визуально должны быть отделены друг от друга) - Соответствие - - Значение характеристики не может изменяться участником закупки

60.5. В случае, если карточка объекта учета не содержит всей необходимой для формирования запроса информации, пользователь должен быть в развернутой форме информирован о характере возникшей ошибки с указанием конкретных реквизитов объекта, которые должны быть заполнены для корректного формирования запроса. 60.6. Должна быть предусмотрен режим ручного формирования запроса из карточки объекта. В данном режиме Система инициирует ручное создание запроса, а также производит автоматическое заполнение параметров запроса сведениями, содержащимися в карточке соответствующего объекта учета. 60.7. После этого пользователю предоставляется возможность самостоятельной корректировки сведений (параметров запроса) и ручного формирования межведомственного запроса. 60.8. После формирования запроса пользователю должно быть выведено соответствующее сообщение с указанием кода сформированного запроса в журнале запросов - Соответствие - - Значение характеристики не может изменяться участником закупки

61. Средства формирования межведомственных запросов в режиме массовой операции: 61.1. Для формирования межведомственных запросов в режиме массовой операции должен быть задействован стандартный механизм Системы работы с массовыми операциями (выбора объектов для выполнения массовой операции). 61.2. Выбор объектов для массовой операции должен производиться с использованием следующих средств: 61.2.1. Из списка объектов учета любых типов основного окна Системы. 61.2.2. Из экранных форм Системы, отображающих списки объектов учета произвольных типов. 61.2.3. Из окна результата запроса подсистемы «Библиотека запросов». 61.3. Выбор услуги (сервиса) для формирования запроса должен быть реализован путем динамического создания пунктов подменю пункта СМЭВ. Пункты подменю должны содержать полный перечень всех услуг/сервисов, доступных для формирования из карточек объектов учета, доступных для выполнения массовой операции в текущем режиме работы. 61.4. Выполнение массовой операции должно производиться пообъектно способом, аналогичным формированию запроса из карточки объекта учета соответствующего типа (описание приведено выше). 61.5.В случае, если операция формирования запроса для данного вида объекта учета недоступна (в соответствии с настройками) или для формирования запроса недостаточно информации, по таким объектам формируется ошибка по правилам функционирования функционала массовых операций (объект помечается красным фоном, формируется развернутое сообщение об ошибке (содержит четкое описание сути ошибки), объект пропускается, происходит переход к обработке следующего объекта). 61.6.Операции, выполняемые в режиме массовой операции, должны протоколироваться по общим принципам (индивидуальное протоколирование каждого сформированного в режиме массовой операции межведомственного запроса) - Соответствие - - Значение характеристики не может изменяться участником закупки

62. Средства формирования межведомственных запросов в режиме регламентной операции: 62.1. Регламентная операция представляет собой выполнение некоторого запроса по определенному расписанию, межведомственные запросы формируются в автоматическом режиме для каждого объекта, информация по которому возвращена запросом. 62.2. Средства формирования межведомственных запросов в режиме регламентных операций должны обеспечивать ведение библиотеки регламентных операций, средства добавления, изменения, удаления регламентных операций, приостановки выполнения регламентных операций. 62.3. Библиотека регламентных операций должна представлять собой список регламентных операций, содержащий следующие атрибуты: 62.3.1. Код идентификатор (код) регламентной операции. 62.3.2. Наименование - наименование регламентной операции. 62.3.3. Организация – наименование организации, предоставляющей услугу/сервис. 62.3.4. Сервис наименование услуги/сервиса для формирования запроса в режиме регламентной операции. 62.3.5. Признак успешности предыдущего выполнения. 62.3.6. Дата, время следующего выполнения. 62.3.7. Состояние (запланировано, приостановлено). 62.3.8. Приостановленные регламентные операции или регламентные операции, для которых не определено время следующего запуска должно визуально выделяться (серый текст шрифта). 62.3.9. Регламентные операции, по которым предыдущий вызов был завершен ошибкой должны визуально выделяться (розовый фон). 62.3.10. Для каждой регламентной операции должны быть определены: 62.3.10.1. Код – присваивается автоматически. 62.3.10.2. Наименование регламентной операции. 62.3.10.3. Описание регламентной операции – текст произвольного размера. 62.3.10.4. Услуга/сервис – выбор из списка услуг/сервисов, доступных для формирования запросов в режиме регламентной операции. 62.4. Расписание выполнения операции (стандартный функционал для формирования расписаний) – в определенное время разово, ежечасно, ежедневно, еженедельно в определенные дни - Соответствие - - Значение характеристики не может изменяться участником закупки

63. Средства подписания запросов электронной подписью: 63.1. С целью обеспечения возможности автоматизированного формирования запросов в пакетном режиме, а также автоматического формирования запросов в режиме массовой операции в Подсистеме должны быть реализованы средства централизованного (серверного) принципа подписания запросов электронной подписью. Для этого в составе подсистемы должен быть реализован сервер ЭП (сервер электронной подписи). Это означает, что в подсистеме должна быть реализована возможность добавления одной или более учетных записей организаций/пользователей организаций, настройки и реквизиты которых будут использоваться для формирования межведомственных запросов и подписания их электронной подписью. Для каждой учетной записи должна быть обеспечена возможность сопоставления с ЭП-ОВ (электронной подписи органа власти) и ЭП-СП – электронная подпись служебного пользования уполномоченного лица (руководителя), которые загружены на сервер ЭП. 63.2. Для каждого пользователя Системы, в должностные обязанности которого входит возможность формирования межведомственных запросов, должна быть предусмотрена возможность указать учетную запись организации/уполномоченного лица организации, электронные подписи которой будут использоваться для автоматического подписания запросов, сформированных соответствующим пользователем. 63.3. Запросы, формируемые средствами подсистемы в любом из описанных выше режимов, должны подписываться ЭП-ОВ и/или ЭП-СП в зависимости от методических рекомендаций для соответствующего вида сведений - Соответствие - - Значение характеристики не может изменяться участником закупки

64. Средства ручного внесения результатов запросов, которые не формировались средствами: подсистемы 64.1. В подсистеме должны быть предусмотрены средства внесения результатов запросов, полученных из внешних источников, то есть без использования средств подсистемы. 64.2. При ручной загрузке результата подсистема должно быть инициировано автоматическое занесение соответствующего запроса в журнал запросов. Дальнейшая обработка загруженного вручную результата должна производиться стандартным способом (загрузка результата в интегрированное хранилище, применение результата (внесение изменений в единую база данных 64.3. Системы на основе полученных сведений)). 64.4. В протокол работы с запросом автоматически должна быть добавлена запись, что результат загружен вручную без использования межведомственного взаимодействия - Соответствие - - Значение характеристики не может изменяться участником закупки

65. Средства ручного внесения результатов запросов, которые не формировались средствами подсистемы: 65.1. В подсистеме должны быть предусмотрены средства внесения результатов запросов, полученных из внешних источников, то есть без использования средств подсистемы. 65.2. При ручной загрузке результата подсистема должно быть инициировано автоматическое занесение соответствующего запроса в журнал запросов. Дальнейшая обработка загруженного вручную результата должна производиться стандартным способом (загрузка результата в интегрированное хранилище, применение результата (внесение изменений в единую база данных Системы на основе полученных сведений)). 65.3. В протокол работы с запросом автоматически должна быть добавлена запись, что результат загружен вручную без использования межведомственного взаимодействия - Соответствие - - Значение характеристики не может изменяться участником закупки

66. Средства предотвращения повторного формирования запросов: 66.1. Подсистема должна содержать средства повторного формирования запросов на одни и те же объекты учета. 66.2. Под повторным формированием запроса понимается формирование запроса на объект, на который уже был ранее сформирован межведомственный запрос на получение сведений по этой же услуге (сервису), по которому сведения получены, но еще не использованы (запрос не «закрыт»), или запрос находится в состоянии ожидания сведений (ответа), то есть по запрос не был отклонен (не находится в состоянии ошибки), сведения еще не получены. 66.3. В ходе проверки на наличие предыдущих запросов следует учесть, что запрос на данный объект учета мог быть сформирован не из текущей карточки, например, текущий запрос получения выписки из ЕГРН на объект имущества формируется из карточки договора приватизации этого объекта имущества, однако ранее был сформирован запрос на этот же объект, но из карточки другого договора или самого объекта. Должна быть предусмотрена возможность определения возможности проверки на наличие сформированных ранее запросов в ручном режиме – возможность должна быть определена на этапе реализации. При наличии возможности указанный функционал подлежит реализации. 66.4. Для каждого сервиса/услуги должна быть предусмотрена возможность настройки количества дней, в течение которых результат предыдущего запроса можно считать актуальным. В случае, если такая настройка произведена, то при ручном формировании запроса или формировании запроса из карточки объекта, при наличии ранее полученного ответа подсистема должна предупреждать пользователя, что уже получен результат на соответствующий запрос с указанием даты его получения и возможностью открытия результата предыдущего запроса. В режиме массовой и регламентной операции формирование таких повторных запросов должно быть заблокировано с указанием причины (по объекту имеется актуальные сведения на запрос, полученные такого-то числа) - Соответствие - - Значение характеристики не может изменяться участником закупки

67. Средства опроса системы СМЭВ на предмет уточнения состояния запроса, загрузка полученных сведений: 67.1. Основным режимом получения/обновления сведений о сформированных ранее межведомственных запросов из системы СМЭВ является режим периодического опроса (пингования) системы СМЭВ. 67.2. При наличии изменений с момента последнего опроса (пингования) системы СМЭВ (изменение даты и времени последнего изменения запроса в системе СМЭВ с аналогичными данными в интегрированном хранилище Системы), полученная информация должна быть занесена в интегрированное хранилище Системы: 67.2.1. Дата и время последнего изменения состояния или сведений запроса в системе СМЭВ. 67.2.2. Текущий статус (состояние) запроса. 67.2.3. При изменении статуса (состояния) запроса – информация по изменению состояния (см. требования к интегрированному хранилищу данных). 67.3. При получении сведений за межведомственный запрос (XML-файл, содержащий сведения), подсистема должна выполнять чтение файла и должна разместить полученную из XML-файла информацию в соответствующих субтаблицах запроса в виде, пригодном для формирования SQL-запросов с использованием полученных сведений - Соответствие - - Значение характеристики не может изменяться участником закупки

67.4. Все операции по опросу (пингованию) системы СМЭВ вне зависимости от наличия изменений должны протоколироваться. Требования к протоколированию приведены в пункте «Интегрированное хранилище данных». 67.5. Должна быть предусмотрена возможность опроса (пингования) по всем сформированным межведомственным запросам, обработка которых еще не завершена (запрос не находится в состоянии ошибки и сведения по нему еще не получены), а также по межведомственным запросам определенной (выбранной пользователем) услуги (сервиса). Операция должна выполняться из основного окна Системы с использованием соответствующих пунктов меню. 67.6. В некоторых случаях сведения, содержащиеся в ответе на межведомственный запрос, не передаются в ходе межведомственного взаимодействия, а должны скачиваться пользователем вручную с использованием сети интернет. Такая ситуация возникает, например, из-за большого объема полученных сведений. - Соответствие - - Значение характеристики не может изменяться участником закупки

68. Средства загрузки полученных сведений в интегрированное хранилище: 68.1. Полученные в результате межведомственного запроса сведения содержат XML-файл заданной в спецификациях к конкретной услуге (сервису) структуры. 68.2. В момент получения XML-файла должно быть обеспечено чтение всех данных XML-файла и размещение их в интегрированном хранилище Системы (единой базе данных Системы) в структурированном виде, пригодном для использования в SQL-запросах (см. требования к интегрированному хранилищу). 68.3. Чтение данных XML-файла и размещение их в интегрированном хранилище должно осуществляться с использованием алгоритма из библиотеки алгоритмов парсинга (разбора) результатов запросов, полученных в машиночитаемом виде (xml). 68.4. Должна быть предусмотрена возможность разработки новых алгоритмов и включение их в библиотеку алгоритмов силами обученных пользователей Системы Заказчика. 68.5. Должно быть предусмотрено обязательное протоколирование выполнения указанной процедуры. Требования к протоколированию приведены в пункте «Интегрированное хранилище данных»). 68.6. Загрузка полученных сведений в интегрированное хранилище должно производиться вне зависимости от способа загрузки сведений (автоматическая загрузка при получении ответа на сформированный ранее запрос), ручная загрузка результата, направленного ранее запроса, ручная загрузка результата на запрос, который не был отправлен средствами подсистемы - Соответствие - - Значение характеристики не может изменяться участником закупки

69. Средства автоматического внесения изменений в единую БД Системы на основе полученных сведений: 69.1. Автоматическое внесение изменений в единую базу данных Системы на основе полученных сведений должно производится в момент получения сведений на межведомственный запрос после размещения полученных данных в реляционных субтаблицах. 69.2. Автоматическое внесение изменений должно производиться путем вызова соответствующего алгоритма из библиотеки алгоритмов, наименование которого настраивается для каждой услуги (сервиса). 69.3. Должна быть предусмотрена возможность разработки новых алгоритмов и включение их в библиотеку алгоритмов силами обученных пользователей Системы Заказчика. 69.4. По завершении автоматического внесения информации в интегрированном хранилище для данного запроса должны быть установлены дата и время автоматического внесения изменений на основе полученных сведений, признак завершения отработки запроса, а также вид операции – «Автоматическое внесение информации». 69.5. Должно быть предусмотрено обязательное протоколирование выполнения указанной процедуры. Протоколированию подлежит также факт невыполнения автоматической операции в связи с отсутствием имени алгоритма, выполняющего соответствующее действие. 69.6. Автоматическое внесение сведений может быть отключено настройками подсистемы (такая настройка должна быть предусмотрена индивидуально для каждого типа объектов учета, а также сервиса/услуги). В случае, если автоматическое внесение изменений отключено, должна быть предусмотрена возможность ручного запуска средств автоматического внесения изменений из окна просмотра результатов запроса. Факт ручного запуска средств автоматического внесения информации должен быть внесен в протокол - Соответствие - - Значение характеристики не может изменяться участником закупки

70. Средства автоматического внесения изменений в единую БД Системы на основе полученных сведений: 70.1.1. Автоматическое внесение изменений в единую базу данных Системы на основе полученных сведений должно производится в момент получения сведений на межведомственный запрос после размещения полученных данных в реляционных субтаблицах. 70.1.2. Автоматическое внесение изменений должно производиться путем вызова соответствующего алгоритма из библиотеки алгоритмов, наименование которого настраивается для каждой услуги (сервиса). 70.1.3. Должна быть предусмотрена возможность разработки новых алгоритмов и включение их в библиотеку алгоритмов силами обученных пользователей Системы Заказчика. 70.1.4. По завершении автоматического внесения информации в интегрированном хранилище для данного запроса должны быть установлены дата и время автоматического внесения изменений на основе полученных сведений, признак завершения отработки запроса, а также вид операции – «Автоматическое внесение информации». 70.1.5. Должно быть предусмотрено обязательное протоколирование выполнения указанной процедуры. Протоколированию подлежит также факт невыполнения автоматической операции в связи с отсутствием имени алгоритма, выполняющего соответствующее действие. 70.1.6. Автоматическое внесение сведений может быть отключено настройками подсистемы (такая настройка должна быть предусмотрена индивидуально для каждого типа объектов учета, а также сервиса/услуги). В случае, если автоматическое внесение изменений отключено, должна быть предусмотрена возможность ручного запуска средств автоматического внесения изменений из окна просмотра результатов запроса. Факт ручного запуска средств автоматического внесения информации должен быть внесен в протокол - Соответствие - - Значение характеристики не может изменяться участником закупки

56. Интегрированное хранилище данных в составе единой базы данных Системы: 56.1. Интегрированное хранилище данных должно быть предназначено для обеспечения хранения взаимосвязанной между собой информации подсистемы в составе единой базы данных Системы. 56.2.Интегрированное хранилище данных должно обеспечивать хранение информации без дублирования, повторного внесения информации, которая уже содержится в единой базе данных Системы. 56.3. Интегрированное хранилище должно содержать ссылки на объекты, субъекты и договоры единой базы данных Системы. 56.4. Интегрированное хранилище должно обеспечивать хранение в единой базе данных Системы следующей информации: 56.4.1. Нормативно-справочная информация подсистемы (содержимое справочников и классификаторов, использующихся в подсистеме). 56.4.2. Информацию о настройках функционирования подсистемы. 56.4.3. Информация по сформированным запросам, полученным в ходе запросов сведениям. 56.4.4. Протоколы всех действий, выполняемых средствами подсистемы в автоматическом, полуавтоматическом и ручном режимах. 56.4.5. По каждому запросу должна быть размещена следующая информация: 56.4.5.1. Идентификатор вида сведений версии 3.х. 56.4.5.2. Вид операции из соответствующего классификатора (ручной, из карточки объекта Системы, из массовой операции, регламентная операция, на основе результатов, полученных из других источников), для массовой и регламентной операции – идентификатор операции. 56.4.5.3. Дата и время формирования запроса, идентификатор пользователя (если операция инициирована пользователем). 56.4.5.4. Информация, переданная в систему СМЭВ в ходе формирования запроса. 56.4.5.5. Идентификатор запроса, присвоенный системой СМЭВ. 56.4.5.6. Идентификатор карточки Системы, из которой (для которой) сформирован запрос - Соответствие - - Значение характеристики не может изменяться участником закупки

56.4.5.7. Идентификаторы объекта (помещение или земельный участок), субъекта (юридическое или физическое лицо, ИП), договора, по которым сформирован запрос. Заполняются те идентификаторы, которые применимы для конкретного вида запроса. Примечание. Например, запрос информации из ЕГРН для определения даты перехода права в ходе приватизации теоретически может быть сформирован как из договора приватизации, так и из объекта. В этом случае идентификаторы карточки Системы, из которой сформирован запрос, должны быть разные, но идентификатор объекта в обоих запросах должен быть один. Это должно потенциально позволить предотвратить повторные запросы на основе анализа идентификатора объекта. 56.4.5.8. Дата и время автоматического или полуавтоматического внесения информации, по полученным сведениям, в единую базу данных. 56.4.5.9. Режим внесения изменений (автоматический, полуавтоматический «мастер», ручной) – см. пункт «Интегрированные средства ведения нормативно-справочной информации». 56.4.5.10. Идентификатор пользователя, внесшего изменения в ручном или полуавтоматическом режиме – «мастер». 56.4.5.11. Признак отработки результатов запроса (да или нет). 56.4.5.12. Текущий статус (состояние) запроса в системе СМЭВ. 56.4.5.13. Дата и время изменения сведений запроса в системе СМЭВ (по данным СМЭВ). 56.4.5.14. Дата и время внесения изменений из системы СМЭВ (изменения статуса запроса). 56.4.5.15. Дату и время последнего успешного опроса системы СМЭВ по данному запросу. 56.4.5.16. Полную информация обо всех изменениях статусов (состояний) запросов, включая дату и время смены состояния, текстовое описание причины смены состояния, и другие сведения, полученные из системы СМЭВ в ходе информационного обмена - Соответствие - - Значение характеристики не может изменяться участником закупки

71. Алгоритмы автоматического внесения изменений в единую БД Системы на основе полученных сведений: 71.1. Алгоритм автоматического внесения изменений в единую БД Системы на основе полученных сведений должен быть определен индивидуально для каждого типа объектов учета и каждого сервиса/услуги с возможностью его настройки. 71.2. Алгоритм должен функционировать по следующему принципу: 71.2.1. Если запрос был сформирован вручную, то на основе полученных сведений должен быть выполнен поиск соответствующего объекта в единой базе данных Системы, при успешном поиске запрос должен быть автоматически прикреплен к соответствующему объекту, соответствующее действие должно быть внесено в протокол. 71.2.2. Если найти объект не удалось, то в зависимости от настройки (такая настройка должна быть предусмотрена) подсистема автоматически создаст соответствующий объект в единой базе данных Системы и заполнит электронную карточку объекта сведениями, содержащимися в полученных данных. Соответствующие действия должны быть внесены в протокол. 71.2.3. Если получены сведения на запрос по объекту, который уже находится в базе данных Системы, то алгоритм опционально (такая настройка должна быть предусмотрена индивидуально для каждого типа объектов учета, сервиса/услуги и действия из перечисленного ниже списка) должен иметь возможность выполнить следующие действия: 71.2.3.1. Для каждого реквизита полученных сведений должна быть выполнена сверка с соответствующим реквизитом в электронной карточке соответствующего объекта учета. Возможны следующие варианты: 71.2.3.1.1. Если реквизит не заполнен, он подлежит заполнению на основе полученных сведений (должно настраиваться) - Соответствие - - Значение характеристики не может изменяться участником закупки

71.2.3.1.2. Если реквизит заполнен, и он отличен от соответствующего реквизита в полученных сведениях, то в зависимости от настройки либо реквизит подлежит изменению (с протоколированием каждого действия), либо для запроса должно быть сформировано предупреждение (состояние запроса сменится на «Предупреждение») с внесением в текст предупреждения развернутой информации о выявленных различиях. 71.2.4. Информация о полученных сведениях должна быть занесена в документы по объекту учета (опционально). 71.3. Для выписок из Росреестра о правах на объекты имущества дополнительно (опционально) должны быть предусмотрены следующие возможности: 71.3.1. Сверка с единой БД Системы на предмет наличия объекта в реестре муниципальной собственности (если в Системы объект включен в реестр, а по данным Росреестра – нет или наоборот, то должно быть сформировано соответствующее предупреждение). 71.3.2. В случае, если в выписке обнаружена информация о регистрации права на объект имущества Системы, которое перешло новому владельцу на основании документов, фигурирующих в единой БД Системы (например, в ходе продажи или приватизации объекта), то опционально должна быть предусмотрена возможность автоматического исключения объекта из реестра муниципальной собственности датой, предшествующей дате регистрации объекта на нового собственника с автоматическим внесением информации о документе-основании исключения. 71.4. Автоматические изменения в соответствии с алгоритмами и настройками Системы могут быть инициированы пользователем вручную. В этом случае пользователь должен быть проинформирован о всех произведенных действиях подсистемы (открыт протокол соответствующих действий) с возможностью быстрого доступа (в один клик мыши) к карточке объекта учета для анализа и возможной корректировки соответствующих действий - Соответствие - - Значение характеристики не может изменяться участником закупки

56.4.6. Информация, полученная в ходе исполнения межведомственного запроса должна быть представлена в структурированном виде и размещаться ее в реляционных структурах (таблицах) единой базы данных Системы. Информация должна быть представлена в виде, пригодном для формирования SQL-запросов с ее использованием. Должны быть предусмотрены средства заполнения данных в структурированном, реляционном виде на основе информации, размещенной в XML-файле полученного результата запроса. Хранение данных только в XML-файле результата запроса недопустимо. Полученную информацию необходимо вносить в интегрированное хранилище. 56.5. В интегрированном хранилище должны быть размещены протоколы всех действий, выполняемых средствами подсистемы в автоматическом, полуавтоматическом и ручном режимах, в том числе: 56.5.1. Протокол взаимодействия с подсистемой СМЭВ (формирование запроса, опросы с целью получения статуса запроса (пингование), загрузка результата в интегрированное хранилище, парсинг результата, размещение данных результата в реляционных таблицах). 56.5.2. Протокол применения результата к объектам базы данных (поиск объектов в базе данных для ручных запросов, автоматическое добавление объектов в базу данных по результатам запросов, внесение изменений в электронные карточки объектов учета на основе полученных данных (индивидуально для каждого выполненного изменения)). 56.6. Протоколы должны содержать следующую информацию: 56.6.1. Дата и время выполнения операции или действия. 56.6.2. Имя пользователя, инициировавшего операцию (если операцию инициировал пользователь). 56.6.3. Вид операции из соответствующего классификатора (ручной, из карточки объекта Системы, из массовой операции, регламентная операция, опрос (пингование) запроса в системе СМЭВ, получение события из системы СМЭВ), для массовой и регламентной операции – идентификатор операции - Соответствие - - Значение характеристики не может изменяться участником закупки

56.6.4. Признак успешности выполнения операции из соответствующего классификатора (успешно, не успешно). 56.6.5. Выполненное действие (из соответствующего классификатора). 56.6.6. Данные, связанные с действием (в текстовом виде), например, при вводе кадастрового номера объекта на основе полученных данных – кадастровый номер. 56.6.7. Дополнительная текстовая информация (в случае ошибки – причина ошибки). 56.7. Интерфейс для работы пользователей с данными, размещенными в интегрированном хранилище, должен быть обеспечен непосредственно Системой с использованием экранных форм, разработанных по общим принципам, принятым для Системы, с использованием единого визуального стиля, оформления Системы - Соответствие - - Значение характеристики не может изменяться участником закупки

57. Интегрированные средства ведения справочников и классификаторов: 57.1. Средства должны быть предназначены для управления работой со справочниками и классификаторами подсистемы и обеспечивать единое пространство справочной информации в процессе использования учетных данных и документов. 57.2. Средства должны обеспечивать выполнение функций: 57.2.1. Редактирование справочников и классификаторов. 57.2.2. Просмотр справочников и классификаторов - Соответствие - - Значение характеристики не может изменяться участником закупки

72. Средства «закрытия» запросов: 72.1. Под «закрытием» запроса помечается возможность пометки запроса в качестве отработанного, то есть запроса, не требующего дальнейшего анализа или использования пользователем. 72.2. Должна быть предусмотрена возможность автоматического и ручного «закрытия» запросов. 72.3. Автоматическое «закрытие» запросов должно производиться по настройке (такая настройка должна быть предусмотрена индивидуально для каждого типа объектов учета и услуге/сервису) после успешного получения результатов запроса и автоматического успешного внесения изменений в единой базе данных Системы, предусмотренных соответствующим алгоритмом. Должна быть предусмотрена возможность отключения автоматического «закрытия» запросов индивидуально для каждого пользователя. 72.4. Ручное «закрытие» должно производится пользователем самостоятельно после изучения и/или использования результатов запроса. 72.5. «Закрытые» запросы не должно изыматься из единой базы данных Системы, последующий доступ к ним должен быть обеспечен по запросам пользователей. 72.6. По умолчанию для журнала запросов должна быть предусмотрена возможность отображения не закрытых запросов – см. требования к функционированию журнала запросов - Соответствие - - Значение характеристики не может изменяться участником закупки

73. Средства работы с журналом межведомственных запросов: 73.1. Журнал запросов должен представлять собой список запросов, содержащий всю основную информацию по каждому запросу, а также средства открытия карточки запроса и выполнения основных действий над запросом. 73.2. Журнал запросов должен быть доступен в следующих режимах: 73.2.1. Из карточки объекта Системы – журнал размещается на вкладке «СМЭВ» карточки объекта и содержит все межведомственные запросы, которые были сформированы для данного объекта. 73.2.1. Из основного окна Системы для всех услуг/сервисов, а также индивидуально для каждого из сервисов/услуг в режиме отображения «моих» запросов. Под «моими» запросами понимаются запросы, сформированные текущим пользователем Системы. 73.2.2. Из основного окна Системы для всех услуг/сервисов, а также индивидуально для каждого из сервисов/услуг в режиме отображения всех запросов. 73.3. Для журнала межведомственных запросов должны быть предусмотрены средства поиска/фильтрации запросов в соответствии с требованиями к функционированию подсистемы поиска и анализа информации Системы: 73.3.1. Должны быть предусмотрены возможности поиска запросов по любым параметрам запроса, в том числе: 73.3.1.1. Сервис/услуга. 73.3.1.2. Код запроса. 73.3.1.3. Дата формирования запроса. 73.3.1.4. Состояние запроса (с возможностью множественного выбора из справочника состояний). 73.3.1.5. Статус запроса (текстовый статус сервисов межведомственного взаимодействия). 73.3.1.6. Сообщение протокола прохождения (выполнения) запроса. 73.3.1.7. Сообщения протокола применения результатов запроса (внесения изменений в базу Системы по результатам запроса). 73.3.1.8. Номер заявки. 73.3.1.9. GUID запроса в Системы. 73.3.1.10. Признак «закрытия» запроса. 73.3.1.11. Тип операции создания запроса (вручную, из карточки объекта, массовая операция, регламентная операция) – множественный выбор из справочника. 73.3.1.12. Источник операции создания запроса – множественный выбор из соответствующего справочника - Соответствие - - Значение характеристики не может изменяться участником закупки

58. Средства настройки: 58.1. Подсистема должна обеспечивать максимально широкие возможности по настройке, изменению технологии работы подсистемы силами обученных пользователей Системы без привлечения программистов Исполнителя. 58.2. Должны быть предусмотрены следующие средства настройки, изменения технологии работы подсистемы силами обученных пользователей Системы: 58.2.1. Средства настройки перечня доступных сервисов и/или видов сведений для формирования межведомственных запросов в ручном режиме. 58.2.2. Средства настройки перечня доступных для каждого из типов объектов учета Системы сервисов и/или видов сведений. 58.2.3. Перечень регламентных операций для формирования запросов по расписанию, настройка расписания выполнения регламентных операций. 58.2.4. Средства/Алгоритмы чтения полученных в результате межведомственного запроса сведений и размещения их в реляционных субтаблицах интегрированного хранилища (единой базы данных Системы). 58.2.5. Средства/Алгоритмы внесения изменений в электронные карточки объектов учета на основе полученных данных. 58.2.6. Средства/Алгоритмы создания объектов учета, отсутствующих в базе данных, на основе сведений, содержащихся в полученных ответах. 58.2.7. Средства/Алгоритмы связи запросов, выполненных в ручном режиме, с объектами, которые уже есть в базе данных Системы на основе сведений, содержащихся в полученных ответах. 58.2.8. Средства/Алгоритмы автоматического «закрытия» межведомственных запросов после получения и использования (применения, внесения в базу данных) полученных сведений, возможность индивидуального отключения автоматического «закрытия» запросов. 58.2.9. Создание шаблонов автоматического частичного заполнения формы формирования ручного запроса - Соответствие - - Значение характеристики не может изменяться участником закупки

59. Средства ручного формирования межведомственных запросов: 59.1. При ручном формировании запроса пользователь должен предварительно выбирать услугу (сервис), для которой формируется запрос. Выбор должен производиться из перечня услуг (сервисов), для которых доступно ручное формирование запроса. 59.2. В случае, если для некоторого сервиса/услуги предусмотрена возможность формирования запросов по нескольким вариантам параметров (например, по кадастровому номеру или адресу объекта), то должна быть предусмотрена возможность ввода параметров запроса для каждого варианта. 59.3. При проектировании должна быть предусмотрена возможность создания шаблонов автоматического заполнения одного или нескольких параметров запросов. 59.4. Должна быть предусмотрена возможность индивидуального создания шаблонов каждым пользователем. 59.5. Технология создания шаблонов должна быть реализована по следующему принципу – пользователь заполняет те параметры экранной формы ручного формирования запросов, которые должны быть включены в шаблон. Далее пользователь инициирует создание шаблона и вводит его наименование/описание. После этого шаблон автоматически появляется в списке доступных для данного пользователя шаблонов для данной услуги/сервиса. Для одного из шаблонов каждого сервиса/услуги должна быть предусмотрена возможность выбора шаблона по умолчанию. 59.6. Если для некоторого сервиса и/или вида сведений указан шаблон по умолчанию, то при ручном создании запроса соответствующего сервиса и/или вида сведений параметры запроса должны быть заполнены автоматически на основе данных шаблона по умолчанию. 59.7. Пользователь может выбрать любой доступный для данного сервиса/услуги шаблон, в этом случае соответствующие параметры из шаблона автоматически должны заполнять поля экранной формы ручного формирования запроса - Соответствие - - Значение характеристики не может изменяться участником закупки

73.3.1.13. Пользователь, инициировавший запрос. 73.3.1.14. Дата последнего изменения информации. 73.3.1.15. Код регламентной операции. 73.3.1.16. Дата получения результата. 73.3.1.17. Дата загрузки результата. 73.3.1.17. Дата применения результата. 73.3.1.19. Тип операции применения результата – из соответствующего справочника. 73.3.1.20. Источник операции применения результата – из соответствующего справочника. 73.3.1.21. Пользователь, применивший результат. 73.3.1.22. Признак автоматического создания запроса при ручной загрузке результата, полученного из внешних источников. 73.3.1.23. Признак необходимости ручной загрузки результатов запроса. 73.3.1.24. Признак необходимости ручного применения результатов. 73.3.1.25. Признак включения в план повторных запросов. 73.3.2. Должны быть предусмотрена возможность поиска запросов по любым параметрам объектов единой базы данных Системы с использованием экранных форм поиска/фильтрации объектов, предусмотренных для соответствующих объектов в Системы. 73.3.3. Должны быть предусмотрена возможность просмотра/корректировки (для администратора) SQL-запроса на выборку запросов в соответствии с параметрами поиска. 73.3.4. Должны быть предусмотрен фильтр по умолчанию на отображение запросов, требующих внимания пользователей, то есть запрос не «закрыт» и результат получен (состояние запроса – «Успех, «Предупреждение» или «Ошибка») - Соответствие - - Значение характеристики не может изменяться участником закупки

74. Средства работы с карточкой межведомственного запроса: 74.1. Карточка межведомственного запроса должна открываться из журнала запросов в любом из режимов его отображения и содержать следующую информацию/средства управления: 74.1. 1. Основную информацию по запросу: 74.1. 1.1. Код запроса. 74.1. 1.2. Текущее состояние запроса. 74.1. 1.3. Текстовый статус запроса. 74.1. 1.4. Дата и время формирования запроса. 74.1. 1.5. Пользователь, сформировавший запрос. 74.1. 1.6. Дата и время получения результата запроса. 74.1. 1.7. Информация по объекту Системы, связанного с данным запросом. 74.1. 1.8. Сведения о загрузке результата в базу данных. 74.1. 1.9. Сведения о применении результата (внесении изменений в базу данных). 74.1. 2. Средства просмотра протоколов работы с запросом. 74.1. 3. Средства просмотра файлов, полученных в результате запроса (в разархивированном виде). 74.1. 4. Средства выгрузки файлов результатов запроса на внешний носитель. 74.1. 5. Средства открытия файлов результатов запросов стандартными средствами операционной системы. 74.1. 6. Средства просмотра xml-файла результата запроса в виде документа (с применением соответствующих стилей отображения XML в оффлайн-режиме – без требования наличия сети интернет). 74.1. 7. Печать и выгрузка XML-файла в виде документа. 74.1. 8. Средства «Закрытия запроса». 74.1. 9. Средства ручного применения результатов запроса. 74.1. 10. Средства доступа к карточке объекта учета в Системе (в один клик). 74.1. 11. Средства загрузки результатов запроса (для запросов, требующих ручную загрузку результатов). 74.1. 12. Средства открытия запроса в системе СМЭВ - Соответствие - - Значение характеристики не может изменяться участником закупки

75. Средства поиска объектов Системы по параметрам межведомственных запросов: 75.1. Для объектов базы данных Системы должны быть предусмотрены средства поиска объектов по параметрам межведомственных запросов. 75.2. Средства указания параметров поиска/фильтрации должны быть интегрированы непосредственно в стандартные окна поиска/фильтрации объектов Системы и должны быть размещены на отдельной вкладке «СМЭВ». 75.3. Средства поиска должны обладать следующими возможностями: 75.3.1. Поиск объектов по наличию или отсутствию межведомственных запросов указанного сервиса/услуги (если не указано, то для любых сервисов/услуг) в заданном диапазоне дат (если не указано, то на любую дату). 75.3.2. Поиск объектов по любым параметрам запросов с использованием формы поиска/фильтрации журнала межведомственных запросов - Соответствие - - Значение характеристики не может изменяться участником закупки

59.8. После успешного формирования запроса пользователю должно быть выведено соответствующее сообщение с указанием кода сформированного запроса в журнале запросов. 59.9. Для запросов по кадастровому номеру или кадастровому кварталу должна быть предусмотрена возможность пакетного формирования ручных запросов на основе кадастровых номеров (или кварталов), определенных в текстовом файле (в столбик) – для каждого кадастрового номера (квартала) автоматически должен быть сформирован запрос. 59.10. Аналогичная возможность должна быть предусмотрена для запросов по ИНН, ОГРН и другим классификационным кодам юридических, физических лиц, индивидуальных предпринимателей - Соответствие - - Значение характеристики не может изменяться участником закупки

77. Средства администрирования и разграничения прав пользователей: 77.1. Все операции подсистемы, которые могут быть инициированы пользователем, должны подлежать администрированию и разграничению прав доступа. 77.2. Администрированию должны подлежать: 77.2.1. Операции ручного формирования запросов – индивидуально для каждого вида услуги (сервиса) – по справочнику услуг (сервисов). 77.2.2. Операции формирования запросов из карточек объектов учета – индивидуально для каждого вида объекта и услуги (сервиса). 77.2.3. Операции формирования запросов в режиме массовой операции – индивидуально для каждого вида объекта в массовой операции и услуги (сервиса). 77.2.4. Операции ручной загрузки сведений, полученных из сторонних источников – индивидуально для каждого вида объекта и услуги (сервиса). 77.2.5. Операции ручного инициирования автоматического внесения изменений на основе полученных сведений – индивидуально для каждого вида объекта и услуги (сервиса). 6. Просмотр, печать, экспорт результатов, сформированных ранее запросов – индивидуально для каждого вида объекта и услуги (сервиса) - Соответствие - - Значение характеристики не может изменяться участником закупки

78. Требования к подсистеме «Межведомственное электронное взаимодействие с ГИС ГМП»: 78.1. В рамках данного технического задания должны быть настроены адаптеры СМЭВ к следующим видам сведений Федерального Казначейства: 78.1.1. Предоставление необходимой для уплаты информации - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/dd08daa2-d9cd-11eb-87f2-6dd2d98a56b1. 78.1.2. Прием необходимой для уплаты информации (начисления) - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/dd0976e8-d9cd-11eb-87f2-6dd2d98a56b1. 78.1.3. Прием информации о погашении начисления - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/dd0928c6-d9cd-11eb-87f2-6dd2d98a56b1. 78.1.4. Предоставление информации об уплате - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/dd08daa3-d9cd-11eb-87f2-6dd2d98a56b1. 78.1.5. Прием информации о погашении начисления - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/dd0928c6-d9cd-11eb-87f2-6dd2d98a56b1. 78.2. Подсистема должна обеспечивать автоматический сбор и передачу информации по начислениям из Системы в Государственную информационную систему государственных и муниципальных платежей (ГИС ГМП) с использованием протоколов СМЭВ в форматах и порядке, утвержденных приказом Федерального казначейства от 12 мая 2017 г. N 11н «Об утверждении Порядка ведения Государственной информационной системы о государственных платежах». 78.3. Подсистема должна быть реализована в виде сервисов ОС, которые выполняют следующие функции: 78.3.1. Формирование и присвоение УИН (уникальный идентификатор) начислениям всех типов (в соответствии с методическими и форматными требованиями ГИС ГМП). 78.3.2. Автоматический сбор информации по начислениям, а также корректировкам и аннулированиям начислений из Системы. 78.3.3. Формирование сообщений в утверждённых форматах ГИС ГМП, заверение их электронной подписью (ЭП) и передача сообщений по протоколам СМЭВ, формирование протокола отправки и подтверждения получения из ГИС ГМП - Соответствие - - Значение характеристики не может изменяться участником закупки

78.3.4. Анализ полученных ответов и создание необходимых записей/протоколов в БД Системы. 78.3.5. Автоматическое распределение поступлений, в которых указан корректный УИН, по договорам Системы. 78.3.6. Автоматическое квитирование начислений на основе информации о поступлениях в соответствующих договорах. 78.4. Подсистема должна автоматизировать работу оператора начислений, снять нагрузку по ручному формированию и отправке начислений в Федеральное казначейство, а также проверки статусов начислений. Вся работа должна осуществляться в стандартном интерфейсе Системы, средства взаимодействия должны функционировать полностью автоматически и не требовать дополнительных действий от пользователей Системы. 78.5.Должна быть предусмотрена возможность квитирования начислений с отсутствующим платежом (в соответствии с технологией квитирования, предусмотренной в ГИС ГМП). 78.6.Поступления по администрируемым кодам бюджетной классификации (КБК) поступают в журнал нераспределенных поступлений финансово-аналитической подсистемы из системы электронного бюджета Федерального Казначейства (ЭБ). 78.7. В Системе должна быть предусмотрена возможность выполнения автоматических операций по автоматическому распределению поступлений на договоры с привязкой к виду начисления. 78.8. В случае, если информация о поступлении содержит УИН начисления, эта информация должна использоваться для однозначного определения договора и вида начисления путем поиска по УИН и анализа информации о соответствующем начислении. Должно быть выполнено соответствующее развитие алгоритмов автоматического распределения поступлений по договорам и видам начислений финансово-аналитической подсистемы - Соответствие - - Значение характеристики не может изменяться участником закупки

79.Требования к подсистеме «Межведомственное электронное взаимодействие с Росреестром»: 79.1. В рамках данного технического задания должен быть настроен адаптер СМЭВ к следующему виду сведений Росреестра: Прием обращений в ФГИС ЕГРН - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/dd0b99d3-d9cd-11eb-87f2-6dd2d98a56b1. 79.2. Подсистема должна решать следующие задачи: 79.2.1. Получение необходимой информации о земельных участках, объектах недвижимости. 79.2.2. Получение информации о правах субъектов на объекты недвижимости и земельные участки. 79.2.3. Получение информации Кадастровом паспорте, Кадастровом плане территории, Кадастровой выписке и иных документах. 79.2.4. Своевременное получение информации об изменениях состояния и прав собственности на объекты недвижимости. 79.2.5. Актуализация сведений, в том числе в массовом порядке, содержащихся в информационном фонде Системы из результатов запросов к сервису Росреестра. 79.3. Должны быть предоставлены средства получения следующих сведений из Росреестра: 79.3.1. Выписка из ЕГРН об объекте недвижимости. 79.3.2. Выписка из ЕГРН о переходе прав на объект недвижимости. 79.3.3. Справки о лицах, получивших сведения об объекте недвижимости за период. 79.3.4. Выписка из ЕГРН об основных характеристиках и зарегистрированных правах на объект недвижимости. 79.3.5. Выписка о правах отдельного лица на имевшиеся/имеющиеся у него объекты недвижимости. 79.3.6. Выписка о содержании правоустанавливающих документов. 79.3.7. Выписка о признании правообладателя недееспособным или ограниченно дееспособным. 79.3.8. Копия документа. 79.3.9. Выписка о дате получения органом регистрации прав заявления о государственном кадастровом учете и (или) государственной регистрации прав и прилагаемых к нему документов. 79.3.10. Выписки о кадастровой стоимости объекта недвижимости. 79.3.11. Кадастровый план территории. 79.3.12. Выписка по зонам - Соответствие - - Значение характеристики не может изменяться участником закупки

80.4.2. Запрос сведений о перемене имени. 80.4.3. Запрос сведений о расторжении брака. 80.4.4. Запрос сведений о рождении. 80.4.5. Запрос сведений об установлении отцовства. 80.4.6. Запрос сведений о смерти - Соответствие - - Значение характеристики не может изменяться участником закупки

80. Подсистема «Межведомственное электронное взаимодействие с ЗАГС»: 80.1. В рамках данного технического задания должны быть настроены адаптеры СМЭВ к следующим видам сведений органов записи актов гражданского состояния (далее - ЗАГС): 80.1.1. Сведения о заключении брака - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/637a056a-ff80-11eb-ba23-33408f10c8dc. 80.1.2. Сведения о перемене имени - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/637a0597-ff80-11eb-ba23-33408f10c8dc. 80.1.3. Сведения о расторжение брака - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/637a0564-ff80-11eb-ba23-33408f10c8dc. 80.1.4. Сведения о рождении - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/637a059f-ff80-11eb-ba23-33408f10c8dc. 80.1.5. Сведения об установлении отцовства - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/637a0594-ff80-11eb-ba23-33408f10c8dc. 80.1.6. Сведения о смерти - https://lkuv.gosuslugi.ru/paip-portal/#/inquiries/card/637a0579-ff80-11eb-ba23-33408f10c8dc. 80.2. Подсистема должна решать следующие задачи: 80.2.1. Получение информации о физических лицах в объеме сведений сервисов СМЭВ ПФР. 80.2.2. Актуализация сведений, содержащихся в информационном фонде Системы на основе полученных сведений. 80.3. После получения ответов на отправленные запросы Подсистема в автоматическом или автоматизированном режиме должна позволять: 80.3.1. Направлять уведомление о получении ответа пользователям на электронную почту. 80.3.2. Автоматически прикреплять полученные сведения к карточке соответствующего объекта учета, субъекта права в Системе. 80.3.3. Обеспечивать возможность в автоматизированном режиме формировать информацию, аналитические и статистические отчеты, запросы на основе полученных в результате межведомственных запросов сведений. 80.4. Должны быть предоставлены средства получения следующих сведений из ФНС: 80.4.1. Запрос сведений о заключении брака. 80.4.2. Запрос сведений о перемене имени. 80.4.3. Запрос сведений о расторжении брака - Соответствие - - Значение характеристики не может изменяться участником закупки

52. Средства ведения журналов проверок, информации о ходе проведения проверок: 52.1. Доступ к журналам (реестрам) проверок должен быть организован из «дерева меню» основного окна Системы. 52.2. Средства работы с журналом проверок должны быть подключены к подсистеме поиска и аналитики Системы (обладать всему функциями указанной подсистемы), быть построены по общим принципам работы со списками объектов учета Системы, в том числе: 52.2.1. Обладать возможностями поиска проверок по любым параметрам или сочетаниям параметров проверок, включая возможности поиска проверок по любым параметрам субъектов проверок, объектов проверок, договоров, в отношении которых проводится проверка, а также по информации о претензионной и исковой деятельности, которая инициирована по результатам проверки. 52.2.2. Обладать возможностью настройки табличного представления списка проверок (управление видимостью и порядка следования колонок, добавление новых колонок без ограничения количества и методики формирования информации, размещенной в колонках, добавления колонок с цветовой индикацией, управление алгоритмами цветовой индикации в колонках и т.п.). 52.2.3. Обладать аналитическими возможностями – сортировки, группировки по любой колонке или набору колонок, подведению итогов по выборке целиком или по группам (сумма, количество и т.д.) - Соответствие - - Значение характеристики не может изменяться участником закупки

52.3. В журнале (списке, реестре) проверок должны быть отражены все основные показатели из карточки проверки, показатели стадии проверок должны быть отражены для текущей стадии или последней стадии проверки для завершенных проверок. 52.4. В Подсистеме не должно быть ограничений по количеству журналов проверок. 52.5. Журналы могут быть разделены по группам: 52.5.1. Журналы проверок по объектам имущества. 52.5.2. Журналы проверок по земельным участкам. 52.6. Должен быть предусмотрен отдельный пункт меню (автоматический журнал) – «Напоминания». В случае деления журналов по группам должна быть предусмотрена возможность отображения пункта «Напоминания» в каждой из групп. 52.7.Журнал «Напоминания» должен содержать проверки, для которых подходит или нарушен срок предупредительного контроля для текущего сотрудника, который работает в Системе. Подробно функции напоминаний описаны ниже - Соответствие - - Значение характеристики не может изменяться участником закупки

53. Электронная карточка проверки: 53.1. Электронная карточка проверки должна содержать следующую информацию: 53.1.1. Реестр (журнал) проверки. 53.1.2. Форма проверки (выездная, документарная и т.п.). 53.1.3. Состояние проверки (в плане, в процессе, завершена). 53.1.4. Год проверки. 53.1.5. Категория. 53.1.6. Цель. 53.1.7. Перечень органов или организаций соисполнителей. 53.1.8. Субъект проверки – ссылка на субъект единой БД Системы. 53.1.9. Даты планируемого и фактического начала. 53.1.10. Даты планируемого и фактического окончания. 53.1.11. Срок проведения по регламенту с возможностью настройки автоматического определения в соответствии с регламентом для данного журнала проверок. 53.1.12. Исчерпывающая информация о форме и дате отправки уведомления о начале проверки. 53.1.13. Перечень объектов проверки (ссылки на объекты единой БД Системы), перечень обнаруженных нарушений для каждого из объектов. 53.1.14. Информация об осмотре и вынесенном решении по результатам осмотра. 53.1.15. Этапы проведения проверок с настройкой последовательности и сроков в соответствии с регламентами, определенными для каждого журнала проверок, Подрядчик каждого этапа, ссылка на документы-основания для каждого этапа, результата этапа. 53.1.16. Перечень документов по проверке (с возможностью прикрепления файла документа). 53.1.17. Перечень претензий и\или исков по результатам проверки (ссылки на реестр исков претензионно-исковой подсистемы Системы). 53.1.18. Результат проверки, ссылка на документ-основания результата - Соответствие - - Значение характеристики не может изменяться участником закупки

54. Средства предупредительного контроля за соблюдением регламента проведения проверок: 54.1. Должна быть предусмотрена возможность настройки регламентов выполнения проверок. 54.2. Регламент может определять: 54.2.1. Общий срок в днях для проверки (с настройкой рабочие\календарные дни). 54.2.2. Перечень и последовательность типовых этапов для каждого журнала. 54.2.3. Длительность для каждого этапа. 54.2.4. Варианты результата этапа. 54.2.5. Перечень настроек напоминаний для этапа – срок в днях с момента начала или до окончания этапа, роли пользователей, для которых формировать напоминания (Подрядчик, куратор), а также фиксированный перечень пользователей, для которых формировать напоминания (например, начальник отдела). 54.3. При наступлении события для напоминания соответствующие проверки должны быть отражены в журнале: 54.3.1. Во всплывающем окне при каждом входе пользователя в Систему. 54.3.2. В журнале «Напоминания» соответствующих пользователей. 54.4. Требования по развитию Системы для интеграции средств подсистемы: 54.4.1. В электронных карточках субъектов должна размещаться информация о списках проверок в отношении этих субъектов (план проверок, текущие и завершенные проверки). 54.4.2. В электронных карточках объектов имущества и земельных участков должна размещаться информация о списках проверок в отношении этих объектов (план проверок, текущие и завершенные проверки). 54.4.3. В электронных карточках претензий и исков должна размещаться информация о проверке, по результатам которой начата претензионная или исковая. 54.4.4. Должна быть организована возможность поиска субъектов, объектов, претензий и исков по всем параметрам проводимых в отношении них проверок (связанных проверок) - Соответствие - - Значение характеристики не может изменяться участником закупки

54.5. Разграничение прав пользователей по доступу к журналам проверок, электронным карточкам проверок, операциям, производимых с проверками, ведение аудита и журнала действия пользователей должны обеспечиваться стандартными средствами подсистемы администрирования и разграничения прав пользователей Системы. 54.6. Подсистема должна быть подключена к подсистемам «Библиотека запросов» и «Генератор отчетов» Системы. Все функции соответствующих подсистем должны быть распространены на информацию Подсистемы - Соответствие - - Значение характеристики не может изменяться участником закупки

55. Требования к подсистеме межведомственного электронного взаимодействия (платформа СМЭВ): 55.1. Подсистема должна автоматизировать межведомственное электронное взаимодействие органов управления муниципальной собственностью в части формирования межведомственных запросов по протоколам СМЭВ в отношении объектов учета, субъектов права и договоров, зарегистрированных в единой базе данных Системы, а также автоматизации внесения изменений в единую базу данных Системы на основе полученных сведений. 55.2. Подсистема должна решать следующие задачи: 55.2.1. Формирование межведомственных запросов в ручном режиме с любого рабочего места Системы (ручное заполнение информации по запросу). 55.2.2. Формирование межведомственных запросов непосредственно из карточки объекта учета, субъекта права или договора (автоматическое формирование запроса в «один клик»). 55.2.3. Формирование межведомственных запросов по вручную определенному пользователем перечню объектов учета, субъектов права или договоров в режиме массовой операции (полностью автоматическое формирование запросов без ограничения количества). 55.2.4. Автоматическое формирование межведомственных запросов по определенному перечню объектов учета, субъектов права или договоров в режиме регламентной операции (автоматически по расписанию без ограничения количества). Например, автоматическое формирование запроса на получение выписки из ЕГРН через месяц после подписания договора приватизации с целью определения даты перехода права на приватизированный объект (даты регистрации права собственности на нового собственника и исключения объекта из муниципальной доли). 55.3. После получения ответов на отправленные запросы подсистема в автоматическом или автоматизированном режиме должна позволять: 55.3.1. Обеспечивать возможность автоматического и автоматизированного (автоматического по требованию пользователя) внесения изменений в единую базу данных Системы на основе полученных сведений. - Соответствие - - Значение характеристики не может изменяться участником закупки

55.3.2. Автоматически прикреплять полученные сведения к карточке соответствующего объекта учета, субъекта права или договора в базе Системы с обеспечением возможности автоматизированного внесения изменений в карточку объекта учета, субъекта права или договора на основе этих сведений. 55.3.3. Обеспечивать возможность в автоматизированном режиме формировать информацию, аналитические и статистические отчеты, запросы на основе полученных в результате межведомственных запросов сведений, например, формировать уведомления о необходимости регистрации права собственности на приобретаемые в собственность объекты муниципальной собственности (покупке, приватизация) лицам или организациям, нарушившим сроки регистрации. 55.4. Функции подсистемы должны быть использованы для автоматизации выполнения следующих задач: 55.4.1. Определения даты исключения объекта из муниципальной собственности в ходе продажи/приватизации объекта. 55.4.2. Определения периода нахождения объекта в муниципальной казне, обеспечения корректного бюджетного учета движения объектов в казне. 55.4.3. Определения даты расторжения договоров аренды на объекты муниципальной собственности в ходе выкупа из аренды. 55.4.4. Определения даты передачи муниципальной собственности на праве оперативного управления или хозяйственного ведения. 55.4.5. Уточнения сведений по объектам муниципальной собственности, подлежащим продаже, приватизации, наложению других обременений и/или вещных прав. 55.4.6. Уточнения площадных, стоимостных и других характеристик объектов муниципальной собственности. 55.4.7. Уточнение сведений по зарегистрированным правам на объекты муниципальной собственности. 55.4.8. Определения периода оплаты взносов на капитальный ремонт объектов муниципальной собственности, расположенных в многоквартирных жилых домах, включенных в программу капитального ремонта - Соответствие - - Значение характеристики не может изменяться участником закупки

55.5. Общей целью подсистемы должно быть обеспечение полноты и актуальности информации по объектам муниципальной собственности, земельным участкам, право собственности на которые не разграничено, вне-реестровым объектам учета, субъектам права, договорам и другим правам на объекты, подлежащие учету в рамках единого информационного фонда Системы. 55.6. Для достижения поставленных целей подсистема должна обеспечить получение информации от участников межведомственного электронного взаимодействия путем формирования запросов в соответствии с установленными методическими рекомендациям, размещенными на портале https:/info.gosuslugi.ru 55.7. Подсистема должна обеспечить: 55.7.1. Своевременное получение информации об изменении состава и/или содержания зарегистрированных на объекты учета прав, актуализацию соответствующих сведений в единой базе данных. 55.7.2. Своевременное проведение процедур, связанных с изменением информации по объектам учета, субъектам права и зарегистрированным правам. 55.7.3. Обеспечение полноты и качества ведения бюджетного учета движения объектов в муниципальной казне на основе актуальной информации по датам перехода права собственности на объекты учета, прав оперативного управления и хозяйственного ведения. 55.7.4. Обеспечение полноты и качества администрирования поступлений по администрируемым кодам бюджетной классификации на основе актуальной информации о регистрации договорных отношений. 55.7.5. Контроль за расходованием бюджетных средств на обслуживание объектов муниципальной собственности, включая оплату взносов на капитальный ремонт и др. 55.8. В составе подсистемы должны быть реализованы следующие средства: 55.8.1. Интегрированное хранилище данных в составе единой базы данных Системы. 55.8.2. Интегрированные средства ведения справочников и классификаторов. 55.8.3. Средства настройки. 55.8.4. Средства ручного формирования межведомственных запросов - Соответствие - - Значение характеристики не может изменяться участником закупки

55.8.5. Средства формирования межведомственных запросов из карточки объекта Системы. 55.8.6. Средства формирования межведомственных запросов в режиме массовой операции. 55.8.7. Средства формирования межведомственных запросов в режиме регламентной операции. 55.8.8. Средства подписания запросов электронной подписью. 55.8.9. Средства ручного внесения результатов запросов, которые не формировались средствами подсистемы. 55.8.10. Средства предотвращения повторного формирования запросов 55.8.11. Средства опроса системы СМЭВ на предмет уточнения состояния запроса. 55.8.12. Средства загрузки полученных сведений в интегрированной хранилище данных. 55.8.13. Средства автоматического внесения изменений в единую БД Системы на основе полученных сведений. 55.8.14. Алгоритмы автоматического внесения изменений в единую БД Системы на основе полученных сведений. 55.8.15. Средства «закрытия» запросов. 55.8.16. Средства работы с журналом межведомственных запросов. 55.8.17. Средства работы с карточкой межведомственного запроса. 55.8.17. Средства поиска объектов Системы по параметрам межведомственных запросов. 55.8.19. Средства просмотра протоколов выполнения операций. 55.8.20. Средства администрирования и разграничения прав пользователей - Соответствие - - Значение характеристики не может изменяться участником закупки

43. Средства ведения реестра специализированного жилого фонда: 43.1. Для объектов жилого фонда (квартир и комнат) будет предусмотрен признак отнесения данного объекта к специализированному жилому фонду. 43.2. Для каждого объекта будет указана категория (тип) специализированного жилого фонда: 43.2.1. Служебное жилье. 43.2.2. Маневренный фонд. 43.2.3. Жилые помещения в общежитиях. 43.2.4. Жилые помещения в домах системы социального обслуживания населения. 43.2.5. Жилые помещения для социальной защиты отдельных категорий граждан. 43.2.6. Жилые помещения для детей сирот и детей, оставшихся без попечения родителей, лиц из числа детей сирот и детей, оставшихся без попечения родителей. 43.3. Должна быть предусмотрена возможность расширения или изменения перечня категорий (типов) специализированного жилого фонда (классификатор категорий/типов). 43.4. При отнесении объекта жилого фонда к реестру специализированного жилого фонда может быть указано произвольное количество документов-оснований. 43.5. Должна быть предусмотрена возможность указания периода принадлежности объекта к специализированному жилому фонду. 43.6. В периоде нахождения объекта в реестре специализированного жилого фонда допускается только заключение договоров специализированного найма. Требования к ведению договоров специализированного найма приведены ниже. 43.7. При формировании договора приватизации или социального найма квартиры или комнаты, принадлежащей к реестру специализированного жилого фонда, будет отображено сообщение предупреждение. Операции актуализации таких договоров должны быть заблокированы (включая средства актуализации с использованием массовых операций) - Соответствие - - Значение характеристики не может изменяться участником закупки

44. Средства управления договорами мены и выкупа аварийного жилья: 44.1. Средства управления договорами мены и выкупа аварийного жилья должны быть построены на основе стандартных средств Системы управления договорами на объекты имущества других типов (аренда, продажа). 44.2. Формирование договоров мены и выкупа аварийного жилья допускается только на объекты, не входящие в реестр муниципальной собственности. 44.3. Средства управления договорами мены дополнительно должны обеспечивать возможность указания перечня объектов, из которых производится переселение (квартир и комнат многоквартирного жилого дома), а также перечня объектов, в которые производится переселение. 44.4. Для договоров мены и выкупа аварийных помещений будет предусмотрена возможность ввода нескольких субъектов договора (собственников) с указанием доли каждого из собственников. Доля вводится в виде простой дроби (числитель и знаменатель). Суммарная доля собственников не будет превышать 100%. 44.5. Средства ввода суммы договора будет предусмотрено только для договоров выкупа - Соответствие - - Значение характеристики не может изменяться участником закупки

45. Средства управления договорами социального и специализированного найма: 45.1. Средства управления договорами социального и специализированного найма будут построены на основе стандартных средств Системы управления договорами аренды объектов недвижимого имущества. 45.2. Формирование договоров социального и специализированного найма допускается только на объекты, находящиеся в реестре муниципальной собственности. 45.3. Заключение договора социального найма возможно только на объекты, не входящие в реестр объектов специализированного жилого фонда. При создании договора социального найма на объекты специализированного жилого фонда будет выводиться сообщение предупреждение, актуализация такого договора будет блокироваться. 45.4. Заключение договора социального найма возможно только на объекты, входящие в реестр объектов специализированного жилого фонда. При создании договора специализированного найма на объекты, не входящие в реестр специализированного жилого фонда, будет выводиться сообщение предупреждение, актуализация такого договора будет блокироваться. 45.5. При переселении нанимателей из аварийного жилого фонда для договоров социального и специализированного найма кроме перечня объектов, на которые заключается договор, будет предусмотрен перечень объектов, из которых производится переселение (аналогично соответствующим средствам договоров мены – см. выше). 45.6. Для договоров социального и специализированного найма должны быть подключены все возможности финансово-аналитической подсистемы Системы и подсистемы бюджетного учета доходов по администрируемым кодам бюджетной классификации - Соответствие - - Значение характеристики не может изменяться участником закупки

46. Средства управления договорами социального и специализированного найма: 46.1. Средства управления договорами социального и специализированного найма должны быть построены на основе стандартных средств Системы управления договорами аренды объектов недвижимого имущества. 46.2. Формирование договоров социального и специализированного найма допускается только на объекты, находящиеся в реестре муниципальной собственности. 46.3. Заключение договора социального найма возможно только на объекты, не входящие в реестр объектов специализированного жилого фонда. При создании договора социального найма на объекты специализированного жилого фонда будет выводиться сообщение предупреждение, актуализация такого договора будет блокироваться. 46.4. Заключение договора социального найма возможно только на объекты, входящие в реестр объектов специализированного жилого фонда. При создании договора специализированного найма на объекты, не входящие в реестр специализированного жилого фонда, будет выводиться сообщение предупреждение, актуализация такого договора будет блокироваться. 46.5. При переселении нанимателей из аварийного жилого фонда для договоров социального и специализированного найма кроме перечня объектов, на которые заключается договор, будет предусмотрен перечень объектов, из которых производится переселение (аналогично соответствующим средствам договоров мены – см. выше). 46.6. Для договоров социального и специализированного найма должны быть подключены все возможности финансово-аналитической подсистемы Системы и подсистемы бюджетного учета доходов по администрируемым кодам бюджетной классификации - Соответствие - - Значение характеристики не может изменяться участником закупки

49.1.7. Организация пообъектной сверки с региональным оператором управления взносами на капитальный ремонт или ТСЖ по суммам начисления взносов, перерасчетам. 49.1.8. Организации надлежащего контроля за расходованием бюджетных средств - Соответствие - - Значение характеристики не может изменяться участником закупки

50.3.3. В Подсистеме должен быть расширен перечень справочников и классификаторов Системы за счёт добавления новых видов справочников и классификаторов, используемых Подсистемой - Соответствие - - Значение характеристики не может изменяться участником закупки

47. Средства управления договорами социального и специализированного найма: 47.1. Средства управления договорами социального и специализированного найма должны быть построены на основе стандартных средств Системы управления договорами аренды объектов недвижимого имущества. 47.2. Формирование договоров социального и специализированного найма допускается только на объекты, находящиеся в реестре муниципальной собственности. 47.3. Заключение договора социального найма возможно только на объекты, не входящие в реестр объектов специализированного жилого фонда. При создании договора социального найма на объекты специализированного жилого фонда будет выводиться сообщение предупреждение, актуализация такого договора будет блокироваться. 47.4. Заключение договора социального найма возможно только на объекты, входящие в реестр объектов специализированного жилого фонда. При создании договора специализированного найма на объекты, не входящие в реестр специализированного жилого фонда, будет выводиться сообщение предупреждение, актуализация такого договора будет блокироваться. 47.5. При переселении нанимателей из аварийного жилого фонда для договоров социального и специализированного найма кроме перечня объектов, на которые заключается договор, будет предусмотрен перечень объектов, из которых производится переселение (аналогично соответствующим средствам договоров мены – см. выше). 47.6. Для договоров социального и специализированного найма должны быть подключены все возможности финансово-аналитической подсистемы Системы и подсистемы бюджетного учета доходов по администрируемым кодам бюджетной классификации - Соответствие - - Значение характеристики не может изменяться участником закупки

48. Средства автоматизации работы с управляющими компаниями: 48.1. В карточке многоквартирного жилого дома должна быть предусмотрена возможность ввода информации по управляющей компании. Карточка управляющей компании должна заводиться в стандартном реестре юридических лиц субъектов права Системы. 48.2. Информация по управляющей компании многоквартирного жилого дома должна вводиться путем указания ссылки на карточку управляющей компании средствами работы с субъектами права многоквартирного жилого дома. Предусматривается ведение истории изменения управляющих компаний дома (дата начала и дата окончания), а также перечень ссылок на документы основания (протокол собрания жильцов, договор с управляющей компанией и любые другие документы) с возможностью прикрепления файлов документов. 48.3. На этапе, когда договор с управляющей компанией еще не подписан, однако имеется протокол жильцов с положительным решением о заключении договора с управляющей компанией, должна быть предусмотрена возможность ввода информации по управляющей компании с типом субъекта права «Управляющая компания намерение», при заключении договора с управляющей компанией тип субъекта права будет сменен на «Управляющая компания». 48.4. Информация об управляющей компании должна заноситься только в карточку многоквартирного жилого фонда, однако отображаться будет в карточках всех квартир и комнат данного многоквартирного дома (включая документы основания управляющей компании без возможности корректировки). 48.5. Информация по управляющей компании (наименование) должна отображаться в реестре объектов жилого фонда всех типов (здание, квартира, комната), а также на основной вкладке карточки объектов жилого фонда всех типов - Соответствие - - Значение характеристики не может изменяться участником закупки

49. Требования к подсистеме «Управление взносами на капитальный ремонт»: 49.1. Подсистема «Управление взносами на капитальный ремонт» жилых и нежилых помещений, находящихся в муниципальной собственности и расположенных в многоквартирных жилых домах, включенных в программу капитального ремонта, должен автоматизировать решение следующих задач: 49.1.1. Ведение реестра многоквартирных жилых домов, включенных в программу капитального ремонта. 49.1.2. Формирования перечня жилых (квартир и комнат) и нежилых помещений, по которым подлежит уплата взносов. 49.1.3. Периодическая (ежемесячная) выгрузка изменений (с момента последней успешной выгрузки) для передачи в адрес регионального оператора управления взносами на капитальный ремонт: 49.1.3.1. Сведения об объектах, включенных в реестр муниципальной собственности, или объектов с изменившейся датой включения — с указанием даты и документа-основания включения. 49.1.3.2. Сведения об объектах, исключенных из реестра муниципальной собственности, или объектов с изменившейся датой исключения — с указанием даты и документа-основания исключения. 49.1.3.3. Сведения об объектах с изменившейся площадью — с указанием новой площади. 49.1.3.4. Сведения об объектах с изменившимся адресом — с указанием нового адреса. 49.1.4. Пообъектное начисление взносов с учетом дат включения объектов в собственность (казну), исключения объекта из собственности (казны), автоматическое формирование перерасчетов при внесении изменений в реестр муниципальной собственности. 49.1.5. Учет сумм оплат взносов, распределение суммы оплаты по объектам, учет списаний при выбытии объектов или проведении капитального ремонта. 49.1.6. Организация пообъектного бюджетного учета всех финансовых операций в соответствии с требованиями письма Министерства финансов Российской Федерации от 10.08.2015 № 02-07-07/46003 «Об отражении в бухгалтерском учете операций по перечислению взносов на капитальный ремонт в фонд капитального ремонта» - Соответствие - - Значение характеристики не может изменяться участником закупки

50. Требования к подсистеме «Ведение проверок использования имущества и земельных участков»: 50.1. В составе подсистемы должны быть следующие средства: 50.1.1. Интегрированное хранилище данных в составе единой базы данных Системы. 50.1.2. Интегрированные средства ведения справочников и классификаторов в составе подсистемы ведения нормативно-справочной информации Системы. 50.1.3. Средства формирования плана проверок. 50.1.4. Средства ведения журналов (реестров) проверок, информации о ходе проведения проверок. 50.1.5. Средства предупредительного контроля за соблюдением регламента проведения проверок. 50.2. Интегрированное хранилище данных: 50.2.1. Интегрированное хранилище данных предназначено для обеспечения хранения взаимосвязанной между собой информации подсистемы в составе единой базы данных Системы. 50.2.2. Интегрированное хранилище данных должно обеспечивать хранение информации без дублирования, повторного внесения информации, которая уже содержится в единой базе данных Системы. 50.2.3. Интегрированное хранилище подсистемы должно содержать ссылки на объекты, субъекты, договоры, претензии и иски, информация о которых размещена в единой базе данных Системы. 50.2.4. Информация, которой оперирует Подсистема должна быть в полном составе размещена в единой базе данных Системы. 50.3 Интегрированные средства ведения справочников и классификаторов: 50.3.1. Ведение справочников и Классификаторов Подсистемы должно выполняться средствами Подсистемы управления нормативно-справочной информацией Системы, внешний вид экранных форм, а также функции по управлению справочниками и классификаторами Подсистемы должны быть аналогичными соответствующим элементам подсистемы управления нормативно-справочной информацией Системы. 50.3.2. Средства должны обеспечивать выполнение функций: 50.3.2.1. Редактирование справочников и классификаторов. 50.3.2.2. Просмотр справочников и классификаторов. - Соответствие - - Значение характеристики не может изменяться участником закупки

51. Средства формирования плана проверок: 51.1. В подсистеме должны быть предусмотрены возможности формирования планов проверок на будущие отчетные периоды (года) в разрезе каждого из видов проверок (журналов проверок – см. ниже). 51.2. Для плана проверок должна быть предусмотрена возможность указания периода (года) плана проверок, а также перечня субъектов\объектов, подлежащих проверке в плановом порядке. 51.3. По каждому субъекту должна быть предусмотрена возможность указания планового периода проверки, а также возможность указания перечня объектов или договоров, подлежащих проверке в рамках плана. 51.4. Для плана проверок должны быть предусмотрены функции и средства работы с журналами проверок (списками или реестрами проверок), а также средства аналитики, поиска фильтрации и т.д., описанные ниже - Соответствие - - Значение характеристики не может изменяться участником закупки

42. Требования к структуре и функционированию подсистемы «Управление объектами жилого фонда»: 42.1. В составе Подсистемы должны присутствовать следующие средства: 42.1.1. Средства ведения реестра жилых зданий, муниципальных и не муниципальных жилых квартир и комнат. 42.1.2. Средства ведения реестра специализированного жилого фонда. 42.1.3. Средства ведения информации по аварийным многоквартирным жилым домам. 42.1.4. Средства управления договорами мены и выкупа аварийного жилого фонда. 42.1.5. Средства управления договорами социального и специализированного найма. 42.1.6. Средства автоматизации работы с управляющими компаниями. 42.2. Средства должны обеспечивать формирование следующих реестров (списков) объектов учета: 42.2.1. Реестр (список) жилых домов, включая многоквартирные жилые дома. 42.2.2. Реестр (список) квартир, находящихся в многоквартирных жилых домах с обязательной привязкой к соответствующему дому. 42.2.3. Реестр (список) комнат, находящихся в квартирах с обязательной привязкой к соответствующей квартире. 42.3 Средства также должны обеспечивать возможность отображения объектов жилого фонда всех типов (жилые здания, квартиры, комнаты) единым списком. 42.4. Средства должны обеспечивать возможность отображения единым списком всех учитываемых средствами Системы объектов (реестровые и внереестровые объекты учета), включая объекты жилого фонда всех типов - Соответствие - - Значение характеристики не может изменяться участником закупки

42.5.Средства Подсистемы должны включать в себя средства управления квартирами и комнатами, включенными в реестр объектов муниципальной собственности. Должно быть обеспечено разграничение прав пользователей по доступу на изменение к реестровой информации объектов муниципальной собственности. 42.6. Интерфейсные и функциональные решения, используемые при ведении реестра объектов жилого фонда всех типов (жилые дома, квартиры, комнаты) должны быть полностью аналогичны соответствующим средствам, используемых в Системе для управления объектами других типов (средства работы с табличным представлением данных, поиска/фильтрации, карточки объекта, составу учитываемых атрибутов, возможностям по настройке для учета расширенного набора реквизитов любых типов). 42.7. Для жилых зданий дополнительно должны быть обеспечены возможности работы со следующими показателями: 42.7.1. Управляющая компания - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. Формируется как ссылка на карточку субъекта права, размещенную в общем реестре субъектов права. Возможно указание произвольного количества документов-оснований (протокол собрания жильцов, договор). Подробно требования к средствам работы с управляющими компаниями описаны ниже. 42.7.2. Признак аварийности – требования к средствам работы с аварийными жилыми домами приведены ниже. 42.7.3. Этажность - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.4. Общее количество квартир - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.5. Перечень жилых квартир, расположенных в многоквартирном жилом здании – список отображается на одной из вкладок карточки многоквартирного жилого дома с возможностью быстрого доступа (одно действия) к карточке любой из квартир (на просмотр, изменение, добавление или удаление информации) - Соответствие - - Значение характеристики не может изменяться участником закупки

42.7.6. Количество муниципальных объектов (квартир и комнат) – формируется автоматически на основе анализа единой базы данных с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.7. Количество квартир в единой базе данных системы – формируется автоматически на основе анализа единой базы данных с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.8. Общая площадь - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. Является реестровым показателем для объектов муниципальной собственности. 42.7.9. Общая жилая площадь - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.10. Общая полезная площадь - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.11. Год постройки - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.7.12. Способ передачи в собственность (поквартирно и целиком) - показатель заносится вручную с отображением в реестре (списке). 42.7.13. Документы основания – информация по произвольному количеству документов-оснований любых типов с возможностью хранения файла документа. 42.8. Для жилых квартир дополнительно будут обеспечены возможности работы со следующими показателями: 42.8.1. Ссылка на карточку многоквартирного жилого дома с быстрым доступом к карточке дома. 42.8.2. Управляющая компания - показатель определяется автоматически из карточки жилого здания с отображением в реестре (списке) и на основной вкладке карточки. Требования к средствам работы с управляющими компаниями описаны ниже. - Соответствие - - Значение характеристики не может изменяться участником закупки

42.8.3. Собственники - показатель заносится вручную для объектов, не включенных в реестр муниципальной собственности. Формируется как ссылка на карточку субъекта права, размещенную в общем реестре субъектов права. В случае, если собственников несколько, возможно указание доли в праве собственности. Возможно указание произвольного количества документов-оснований на право собственности. Ввод собственников обязателен в случае использования средств автоматизации решения задачи переселения из аварийных жилых домов. Подробнее требования к автоматизации задачи переселения описаны ниже. 42.8.4. Наниматели - показатель заносится вручную для объектов муниципальной собственности. Формируется как ссылка на карточку субъекта права, размещенную в общем реестре субъектов права. В случае, если нанимателей несколько, возможно указание доли. Возможно указание произвольного количества документов-оснований. Ввод нанимателей обязателен в случае использования средств автоматизации решения задачи переселения из аварийных жилых домов (допустим также ввод договоров социального или специализированного найма – в этом случае перечень нанимателей определяется автоматически). Подробнее требования к автоматизации задачи переселения описаны ниже. 42.8.5. Признак аварийности – устанавливается автоматически для всех квартир жилого дома, для которого установлен признак аварийности. Требования к средствам работы с аварийными жилыми домами приведены ниже. 42.8.6. Признак невозможности для проживания – устанавливается вручную с указанием документов оснований. 42.8.7. Признак принадлежности к специализированному жилому фонду – устанавливается вручную с указанием документов оснований. Требования к ведению реестра специализированного жилого фонда приведены ниже. 42.8.8. Этаж - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки. 42.8.9. Общее количество комнат - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке - Соответствие - - Значение характеристики не может изменяться участником закупки

42.8.10. Перечень жилых комнат, расположенных в квартире – список отображается на одной из вкладок карточки квартиры с возможностью быстрого доступа (одно действие) к карточке любой из комнат (на просмотр, изменение, добавление или удаление информации). Перечень комнат как отдельных объектов учета ведется в случае, если собственники квартиры отличаются от собственников комнат (или комнаты имеют разных собственников), например, для случая коммунальных квартир, общежитий. 42.8.11. Количество муниципальных комнат – формируется автоматически на основе анализа единой базы данных с отображением в реестре (списке) и на основной вкладке карточки. 42.8.12. Количество комнат в единой базе данных системы – формируется автоматически на основе анализа единой базы данных с отображением в реестре (списке) и на основной вкладке карточки квартиры. 42.8.13. Общая площадь - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки. Является реестровым показателем для объектов муниципальной собственности. 42.8.14. Общая жилая площадь - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.8.15. Общая полезная площадь - показатель заносится вручную с отображением в реестре (списке) и на основной вкладке карточки жилого здания. 42.8.16. Документы основания – информация по произвольному количеству документов-оснований любых типов с возможностью хранения файла документа. 42.9. Для жилых комнат дополнительно будут обеспечены возможности работы со следующими показателями: 42.9.1. Ссылка на карточку квартиры с быстрым доступом к карточке квартиры (одно или два действия). 42.9.2. Управляющая компания - показатель определяется автоматически из карточки жилого здания с отображением в реестре (списке) и на основной вкладке карточки. Подробно требования к средствам работы с управляющими компаниями описаны ниже - Соответствие - - Значение характеристики не может изменяться участником закупки

14. Требования к подсистеме «Ведение информации по субъектам права»: 14.1. Подсистема должна обеспечивать ведение информации по муниципальным предприятиям и учреждениям (как реестровым объектам), а также по субъектам права, участвующих в имущественно-земельных отношениях (юридические, физические лица, индивидуальные предприниматели). 14.2. Подсистема должна автоматизировать выполнение следующих основных задач: 14.2.1. Пообъектный учет субъектов права. Для каждого из субъектов права ведется следующая основная информация: 14.2.1.1. Наименование субъекта права (полное и краткая информация, с историей изменения). 14.2.1.2. ИНН. 14.2.1.3. Принадлежность к реестру, подреестру (с историей изменения и ссылкой на документ-основание). 14.2.1.4. Реестровый номер (с историей изменения и ссылкой на документ-основание). 14.2.1.5. Адрес (с возможностью ввода множественного адреса), структура адреса должна соответствовать федеральным требованиям (ФИАС). Система должна обеспечивать возможность автоматизированного обновления классификаторов адресной подсистемы на основе ФИАС. 14.2.1.6. Организационная форма, вид деятельности, вид собственности (классификаторы) - Соответствие - - Значение характеристики не может изменяться участником закупки

14.2.1.7. Контакты - руководитель, главный бухгалтер, другие сотрудники (произвольное количество), телефоны (произвольное количество), банковские реквизиты (с историей изменения), реквизиты трудовых договоров руководителя и главного бухгалтера с возможность загрузки в систему самих договоров и дополнительных соглашений к ним, а также реквизитов документов о назначении и увольнении руководителей с возможностью загрузки в систему указанных документов. 14.2.1.8. Информация по членам семьи, родственным отношениям (для физических лиц). 14.2.1.9. Паспортные данные (для физических лиц, индивидуальных предпринимателей) – с историей изменения, дата рождения. 14.2.1.10. Субъекты права (представители, учредители) – с историей изменения и ссылками на документы-основания, возможностью расширения в части регистрации произвольного количество субъектов права произвольного типа (любого вида права, с возможностью расширения). 14.2.1.11. Экономические показатели (балансовая, остаточная стоимость объектов на балансе, среднесписочная численность сотрудников, показатели эффективности) – с историей изменения и ссылками на документы-основания. Должна быть обеспечена возможность учета произвольного количества экономических показателей любого типа с возможностью расширения средствами системы. 14.2.1.12. Классификационные коды (ОКВЭД, ОКОНХ, ОГРН, КПП) – с ведением истории и ссылками на документы-основания, с возможностью расширения перечня учитываемых кодов без участия программистов. 14.2.1.13. Информация по документам (все документы, имеющие отношение к данному объекту с делением по направлениям воздействия документов (включение/исключение, внесение изменений, правоустанавливающие, регистрирующие документа)). Должна быть обеспечена возможность учета информации по произвольному количеству документов любого типа с возможностью расширения средствами системы. 14.2.1.14. Комиссии - Соответствие - - Значение характеристики не может изменяться участником закупки

14.2.1.15. События (даты жизненного цикла объекта) с возможностью расширения количества и типов событий средствами системы. 14.2.1.16. Признаки (принадлежности к определенным учетным категориям, группам в соответствии с технологией учета) с возможностью расширений наименований признаков средствами системы. 14.2.1.17. Перечень объектов имущества на балансе и в пользовании. 14.2.1.18. Перечень земельных участков в землепользовании и в пользовании (аренда). 14.2.1.19. Перечень договоров всех типов для объектов имущества (аренда, купля/продажа, безвозмездное пользование, социальный найм). 14.2.1.20. Перечень договоров всех типов для земельных участков (аренда, купля/продажа, безвозмездное пользование). 14.2.1.21. Полная финансовая информация по всем видам договоров (начисления, платежи, задолженность). 14.2.1.22. Информация по банкротству. 14.2.1.23. Информация по претензионной и исковой деятельности (детальная информация по поданным претензиям и искам, включая необходимую классификационную и описательную части, предметы исков, в том числе суммы с делением по видам начислений, перечень этапов претензионной и исковой деятельности с указанием ссылок на документы этапа, уточнение требований) – см. Пункт «подсистема автоматизации претензионной и исковой деятельности». 14.2.2. Управление историей изменения основных данных по субъектам права, документами-основаниями на проведение изменений - Соответствие - - Значение характеристики не может изменяться участником закупки

14.2.3. Управление движением субъектов права в реестре и списках учета (включение, исключение, перемещение между реестрами, ведение истории реорганизации объектов (слияния, разделения)), документами-основаниями, правоустанавливающими и другими документами. 14.2.4. Использование информации по субъектам права при формировании договоров, дополнительных соглашений, других документов, при формировании информации о других имущественно-земельных отношениях с участием соответствующих субъектов права. 14.2.5. Формирование аналитики по деятельности субъекта права в рамках имущественно-земельных отношений. 14.2.6. Формирование аналитики по задолженности, работа с должниками. 14.2.7. Возможность формирования аналитической отчетности в соответствующей сфере (с использованием встроенных средств генераторов отчетов). 14.2.8. Проведение экспресс-аналитики. 14.2.9. Управления предприятиями банкротами 14.2.9.1. В Системе должна быть реализована возможность управления информацией о предприятиях банкротах, а также процессах и стадиях банкротства. В рамках данной функции должна быть предусмотрена возможность ведения следующей информации: 14.2.9.1.1. Перечень стадий банкротства (внешнее наблюдение, конкурсное управление). 14.2.9.1.2. Информацию об управляющих компаниях и саморегулирующихся организациях. 14.2.9.1.3. Перечень заседаний руководства для обсуждения текущих вопросов. 14.2.9.1.4. Сведения о публикации сведений о банкротстве. 14.2.9.1.5. Реестр требований кредиторов для реструктуризации задолженности. 14.2.9.1.6. Информация о конкурсной массе на момент открытия конкурсного производства. 14.2.9.1.7. Периоды изменения всех вышеперечисленных атрибутов. 14.2.9.1.8. Информация о всех документах, связанных со всеми процессами банкротства, а также связи данных документов с теми атрибутами, на изменение которых они направлены - Соответствие - - Значение характеристики не может изменяться участником закупки

41. Требования к подсистеме «Управление объектами жилого фонда» включая Подсистему :«Аварийное жилье» учет и управление: 41.1. Подсистема должна обеспечивать комплексную автоматизацию решения вопросов управления объектами жилого фонда, в том числе: 41.1.1. Ведение жилых зданий: 41.1.1.1. Ведение всех характеристик жилых зданий в рамках единой базы данных, в том числе: 41.1.1.1.1. Этажность. 41.1.1.1.2. Общее количество квартир. 41.1.1.1.3. Количество муниципальных объектов (квартир и комнат). 41.1.1.1.4. Количество квартир в единой базе данных системы. 41.1.1.1.5. Общая площадь. 41.1.1.1.6. Общая жилая площадь. 41.1.1.1.7. Общая полезная площадь. 41.1.1.1.8. Год постройки. 41.1.1.1.9. Способ передачи в собственность (поквартирно и целиком). 41.1.1.1.10. Документы основания. 41.1.1.2. Ведение полной информации о признании дома аварийным, этапам процесса расселения (включая средства автоматизации приобретения жилья для нужд расселения, заключения договоров мены и социального найма в процессе переселения) и ликвидации аварийных домов. 41.1.2. Ведение информации по управляющим компаниям, средства автоматизации работы с управляющими компаниями, в том числе: 41.1.3. Работа с протоколами общих собраний жильцов. 41.1.4. Заключение договоров с управляющими компаниями. 41.1.5. Ведение полной информации по управляющей компании. 6. Ведение реестра жилых квартир с привязкой к многоквартирным жилым домам: 41.1.6.1. Ведение всех характеристик муниципальных и немуниципальных квартир в рамках единой базы данных, в том числе: 41.1.6.1.1. Этаж. 41.1.6.1.2. Общее количество комнат. 41.1.6.1.3. Количество комнат в единой базе данных системы. 41.1.6.1.4. Общая площадь. 41.1.6.1.5. Общая жилая площадь. 41.1.6.1.6. Общая полезная площадь. 41.1.6.1.7. Документы основания - Соответствие - - Значение характеристики не может изменяться участником закупки

41.1.6.2. Ведение информации по собственникам квартир, долям в праве собственности, документам основаниям, переходе и регистрации права собственности. 41.1.6.3. Ведение информации о непригодности квартиры для проживания, документам основаниям. 41.1.7. Ведение реестра жилых комнат с привязкой к жилым квартирам: 41.1.7.1. Ведение всех характеристик комнат в рамках единой базы данных. 41.1.7.2. Ведение информации по собственникам комнат, долям в праве собственности, ментам основаниям, переходе и регистрации права собственности. 41.1.7.3. Ведение информации о непригодности для проживания, документам основаниям. 41.1.8. Ведение реестра специализированного жилого фонда (служебное жилье, маневренный фонд). Включая: 41.1.8.1. Реестр специализированного жилищного фонда также будет расширен: 41.1.8.1.1. Служебные жилые помещения. 41.1.8.1.2. Жилые помещения в общежитиях. 41.1.8.1.3. Жилые помещения маневренного фонда. 41.1.8.1.4. Жилые помещения в домах системы социального обслуживания населения. 41.1.8.1.5. Жилые помещения для социальной защиты отдельных категорий граждан. 41.1.8.1.6. Жилые помещения для детей-сирот и детей, оставшихся без попечения родителей, лиц из числа детей-сирот и детей, оставшихся без попечения родителей. 41.1.9. Ведение информации по переводам жилого (нежилого) фонда в нежилой (жилой) фонд, автоматизация ведения процесса перевода, ведение информации по документам-основаниям, разрешениям, протоколам. 41.1.10. Заключение и управление договорами социального и специализированного найма 41.1.11. Автоматизация решения вопросов приватизации и продажи муниципальных и муниципальных жилых помещений, автоматизация процесса исключения приватизированных жилых помещений из муниципальной собственности. 41.1.12. Ведение информации о приобретении жилых помещений (квартир), в том числе для нужд переселения, автоматизация решения вопросов включения, приобретаемых для нужд переселения квартир в муниципальную собственность - Соответствие - - Значение характеристики не может изменяться участником закупки

25. Требования к подсистеме «Автоматическое обновление клиентских рабочих мест»: 25.1. Подсистема «Автоматическое обновление клиентских рабочих мест» (далее – подсистема автообновления) должна быть построена по клиент-серверной архитектуре, обновления должны распространятся по сети с использованием протокола TCP/IP. 25.2. Подсистема автообновления должна состоять из следующих компонентов (программ): 25.2.1. «Служба обновления» – серверная часть подсистемы автообновления, устанавливаемая на компьютере – сервере. 25.2.2. «Конфигуратор службы обновления» – утилита по настройке службы обновления. 25.2.3. «Клиент обновления» – клиентская часть подсистемы автообновления, устанавливаемая на компьютере пользователя. 25.3. Подсистема автообновления должна обладать следующим функционалом: 25.3.1. Автоматическое обновление клиентов обновлений на компьютерах пользователей при установке новой версии системы обновлений. Служба должна предоставлять клиентским местам Системы актуальную версию клиента обновлений. Для каждой новой версии клиента обновлений должен генерироваться уникальный идентификатор обновления. 25.3.2. Автоматическое обновление клиентских мест Системы на компьютерах пользователей при наличии обновлений программы. Служба должна предоставлять клиентским местам Системы актуальные версии файлов программы. Для каждой новой версии программы должен генерироваться уникальный идентификатор обновления. 25.3.3. Автоматическое восстановление отсутствующих файлов клиентских мест Системы на компьютерах пользователей - Соответствие - - Значение характеристики не может изменяться участником закупки

25.3.4. При обновлении клиентских мест должна поддерживаться работа со списком исключений для удаления с клиентских мест устаревших файлов и папок. 25.3.5. Возможность обновления клиентских мест Системы из нескольких источников. Количество источников не должно быть ограничено. Для каждого источника должна быть предусмотрена возможность задать имя, путь к папке с файлами обновлений, а также путь к файлу со списком исключений. 25.3.6. Возможность сжатия пересылаемых по сети пакетов для уменьшения нагрузки на сеть. Активация данного функционала должна происходить по решению администратора. 25.3.7. Возможность контроля целостности пересылаемых по сети пакетов для предотвращения модификации пересылаемых файлов сторонним ПО, вирусами и иными внешними факторами. Файлы должны приходить на компьютеры пользователей в неизменном виде. 25.4. Служба обновления: 25.4.1. Серверная часть подсистемы автообновления должна быть представлена в виде службы ОС (далее – Служба). Служба должна отвечать на запросы «Клиентов обновления» (далее – Клиентов), предоставляя им всю необходимую информацию об обновлениях, а также сами обновления. 25.4.1. Должна быть предусмотрена возможность запустить Службу как вручную, так и с помощью конфигуратора службы. Также Служба должна запускаться автоматически при включении компьютера и не требовать входа в Систему под учетной записью какого-либо пользователя. 25.4.2. Служба обновления должна применять новые настройки конфигурации автоматически, без необходимости перезапуска. - Соответствие - - Значение характеристики не может изменяться участником закупки

25.4.3. Служба обновления должна автоматически отслеживать наличие новой версии клиента обновлений, а также отслеживать любые изменения в папках источников обновлений. При наличии новой версии клиента обновлений служба должна сгенерировать уникальный идентификатор обновления. Этот идентификатор должен передаваться клиентам обновления на клиентских местах при их подключении к службе обновлений. При наличии изменений в папках источников обновлений служба должна сгенерировать уникальный идентификатор обновления индивидуально для каждого источника обновлений. Этот идентификатор должен передаваться клиентам обновления на клиентских местах при их подключении к службе обновлений. 25.5. Конфигуратор службы обновления (далее – Конфигуратор).: 25.5.1. Конфигуратор не должен требовать установки и должен иметь возможность быть запущенным из любого места на компьютере, где установлена служба обновления. При запуске конфигуратор должен проверять наличие установленной службы и в случае её отсутствия, сообщить об этом пользователю. Если Служба установлена, то должно открываться окно Конфигуратора, на котором должны быть представлены текущие настройки Службы. 25.5.2. Конфигуратор должен обладать следующим фунционалом по настройке службы обновления: 25.5.2.1. Отслеживать текущее состояние Службы. 25.5.2.2. Иметь средства для остановки, запуска и перезапуска службы обновления. 25.5.2.3. Позволять указывать местоположение актуальной версии клиента обновления (которая совместима со службой обновления). 25.5.2.4. Позволять управлять (активация/деактивация) опцией по сжатию пакетов, передаваемых по сети (для уменьшения нагрузки на сеть) - Соответствие - - Значение характеристики не может изменяться участником закупки

25.5.2.5. Позволять управлять (активация/деактивация) опцией по контролю целостности пакетов, передаваемых по сети (для предотвращения модификации содержимого пакетов внешними факторами). 25.5.2.6. Позволять добавлять новые источники обновлений (без ограничения по их количеству). 25.5.2.7. Позволять редактировать сведения об источниках обновлений. В частности, настраивать следующие параметры: 25.5.2.8. Задавать имя источника обновлений. 25.5.2.9. Указывать путь к папке с файлами обновлений. 25.5.2.10. Указывать путь к файлу исключений. 25.6. Клиент обновлений: 25.6.1. Клиентская часть подсистемы автообновления должна быть представлена в виде отдельной программы – клиента обновления. 25.6.2. Клиент обновления должен быть предназначен для соединения со службой обновления, расположенной на другом или текущем компьютере, и получения от неё актуальной версии файлов обновляемой программы, а также актуальной версии самого клиента обновления. 25.6.3. Клиент обновления не должен требовать специальной установки и может быть запущен из любого места. Клиент обновления должен обладать возможностью запуска в двух режимах: 25.6.3.1. «Режим настройки» - в этом режиме должно открываться окно настройки клиента обновления. 25.6.3.2. «Режим обновления» - в этом режиме программа должна выполнять соединение с сервером обновлений, согласно выполненной настройке, и получать от сервера обновлений актуальные версии файлов обновляемой программы и самого клиента. 25.6.4. Клиент обновления в «режиме настройки» должен предоставлять возможность задавать следующие настройки: 25.6.4.1. Настройки подключения к службе обновлений (IP-адрес или имя компьютера, на котором установлена служба обновлений, порт служба обновлений). Для проверки корректности настройки должна быть предусмотрена кнопка для тестирования соединения. - Соответствие - - Значение характеристики не может изменяться участником закупки

25.6.4.2. В случае необходимости подключения к серверу через прокси-сервер, должна быть возможность в соответствующей группе настроек указать IP-адрес прокси-сервера, порт подключения к прокси-серверу, а также логин и пароль для авторизации на прокси-сервере (при необходимости). 25.6.4.3. Источник обновления. Выбор источника обновлений должен осуществляться из выпадающего списка, а котором должны присутствовать все доступные источники обновлений. 25.6.4.4. Путь к временной папке, в которую будут загружаться обновления перед их применением. 25.6.4.5. Путь к папке, в которую необходимо сохранить загруженные обновления. 25.6.4.6. Путь к файлу программы, которую необходимо запустить после обновления. Должна присутствовать возможность настроить запрет запуска нескольких экземпляров. 25.6.4.7. Индивидуальная для клиентского места настройка сжатия пакетов, передаваемых по сети. 25.6.4.8. Индивидуальная для клиентского места настройка контроля целостности пакетов, передаваемых по сети. 25.6.4.9. Настройка протоколирования процесса обновления. 25.6.4.10.Если ip-адрес и имя сервера обновления неизвестны, то должна быть реализована возможность автоматического поиска сервера в локальной сети. Для автоматического поиска сервера должна присутствовать кнопка «Поиск сервера». После успешного поиска, настройки подключения должны быть установлены автоматически, и пользователю должно быть показано соответствующее уведомление. 25.6.5. Клиент обновления в «режиме обновления» должен осуществлять следующие действия: 25.6.5.1. Проверять наличие новой версии клиента обновления. Для этого клиент обновления должен получить текущий идентификатор обновления клиента и сравнить с ранее сохраненным идентификатором. Если идентификаторы различаются, то клиент обновления должен произвести самообновление с сохранением текущего идентификатора обновления - Соответствие - - Значение характеристики не может изменяться участником закупки

25.6.5.2. Проверить наличие обновлений клиентского места Системы. Для этого клиент обновления должен получить текущий идентификатор обновления клиентского места и сравнить с ранее сохраненным идентификатором. Если идентификаторы различаются, то клиент обновления должен произвести загрузку измененных и новых файлов с сохранением текущего идентификатора обновления. При загрузке обновлений должны загружаться только новые и изменение файлы (сверяться контрольные суммы файлов (CRC)). 25.6.5.3. При отсутствии обновлений клиентского места Системы клиент обновления должен проверить наличие отсутствующих файлов клиентского места Системы и при необходимости восстановить их. 25.6.5.4. По завершению работы клиент обновления должен произвести обработку файла исключений. Для этого клиент обновления должен получить содержимое файла исключений и удалить файлы и папки, согласно полученного списка. 25.6.6. Процесс обновления должен отображаться в виде окна, на котором должны быть размещены следующие элементы: 25.6.6.1. Текст сообщения с описанием текущего этапа обновления. 25.6.6.2. Индикатор прогресса обновления. Клиент обновления должен поддерживать возможность протоколирования процесса обновления в текстовом файле, который должен автоматически создаваться в папке клиента обновления - Соответствие - - Значение характеристики не может изменяться участником закупки

22. Требования к подсистеме «Формирование отчетов и печатных форм, генератор отчетов»: 22.1. Подсистема должна предоставлять возможность формирования выходных данных системы – от простейших печатных карточек объектов учета до аналитических отчетов, выборок, прогнозов произвольной сложности по состоянию на произвольную дату в пределах информационного фонда Системы. 22.2. Подсистема не должна содержать ограничений на количество шаблонов отчетов и печатных форм. 22.3. В состав подсистемы должен входить генератор отчетов «FastReport» или эквивалент с помощью которого можно самостоятельно разрабатывать и подключать к Системе отчеты и печатные формы произвольной сложности, а также производить экспресс-изменения подключенных шаблонов. Кроме того, подсистема должна обладать возможностью подключения шаблонов отчетов и печатных форм, разработанных с помощью MS Word, MS Excel и OpenOffice (LibreOffice) или эквивалент с использованием API и VBA (или эквивалент). 22.4. Подсистема должна обеспечить формирование произвольного количества отчетов и печатных форм любой сложности в рамках информационного фонда Системы. 22.5. Для каждой печатной формы должна быть предусмотрена возможность выполнения произвольных действий (алгоритмов), выполняемых до и после формирования печатной формы. 22.6. Должна быть предусмотрена библиотека соответствующих алгоритмов с возможностью выбора ранее разработанного алгоритма для любой печатной формы любому пользователю, не обладающему какими-либо специальными знаниями - Соответствие - - Значение характеристики не может изменяться участником закупки

22.7. Должна быть предусмотрена возможность добавления, изменения или удаления отчетов и печатных форм силами обученных пользователей Системы без необходимости обновления Системы или ее компонентов. 22.8. Средства ведения журналов сформированных документов (печатных форм): 22.8.1. В подсистеме формирования отчетов и печатных форм должна быть предусмотрена возможность реализации средств сохранения информации о формировании соответствующей печатной формы с привязкой к электронной карточке объектов учета, а также фиксированием информации о времени формирования и пользователе, который выполнял формирование. 22.8.2. Должна быть предусмотрена возможность вывода журналов сформированных ранее печатных форм заданного типа в заданный промежуток времени. 22.8.3. Должна быть предусмотрена возможность по необходимости добавления в печатную форму признака необходимости включения факта формирования печатной формы в журнал. 22.9. Должна быть предусмотрена возможность добавления, изменения или удаления отчетов и печатных форм силами специалистов Системы без необходимости обновления Системы или ее компонентов. 22.10. Должна быть предусмотрена возможность реализации описанных функций силами обученных специалистов Системы без необходимости обновления Системы или ее компонентов - Соответствие - - Значение характеристики не может изменяться участником закупки

36. Требования к созданию электронной карточки объекта учета, дизайн карточки 36.1. Требования к электронным карточкам объектов учета единой реестровой подсистемы должны соответствовать общим требованиям к электронным карточкам объектов учета. 36.2. Для карточки объекта учета Единой реестровой подсистемы должна быть предусмотрена возможность создания произвольного количества контейнеров, содержащих перечень атрибутов объекта учета, элементы управления которыми размещаются в соответствующем контейнере. 36.3. Для каждого атрибута должна быть предусмотрена возможность настройки его видимости в карточке по умолчанию: 36.3.1. Всегда отображается – пользователю предлагается только указать значение атрибута. 36.3.2. По умолчанию не отображается, но пользователь может его добавить самостоятельно. 36.3.3. Для атрибутов, значения которых выбираются из справочника, должна быть возможность создания соответствующего справочника или использование имеющегося. 36.4. Создаваемые контейнеры атрибутов должны быть размещены в любой части экранной формы электронной карточки объекта (или на создаваемой вкладке электронной карточки) в соответствии с общими принципами. 36.5. Дополнительно для электронных карточек объектов учета Единой реестровой подсистемы должны быть предусмотрены возможности размещения контейнеров, использующихся для описания объектов имущественно-земельного комплекса: 36.5.1. Адрес, с отображением адреса одной строкой. 36.5.2. Адрес, с отображением произвольного количества адресов, каждый адрес отображается с разбиением на атрибуты, его составляющие (город, улица, номер дома и т.д.). 36.5.3. Документы – контейнер работы с документами по данному объекту учета. 36.5.4. Файлы. 36.5.5. Фотографии. 36.5.6. Типы использования. 36.5.7. Зоны размещения. 36.5.8. Элементы благоустройства. 36.5.9. Субъекты права. 36.5.10. Комиссии. 36.5.11. Экономические показатели. 36.5.12. Технические показатели. 36.5.13. События. 36.5.14. Признаки. 36.5.15. Элементы классификации. - Соответствие - - Значение характеристики не может изменяться участником закупки

26. Требования к подсистеме «Оповещение пользователей»: 26.1. Подсистема оповещения должна быть доступна из главного меню клиента Системы и из главного меню сервера приложений, в случае если сервер приложений не запущен в режиме службы. 26.2. Подсистема оповещения пользователей должна обеспечивать следующие возможности: 26.2.1. Направить подключенным пользователям (подключенным клиентским приложениям) текстовое сообщение о проведении технических работ, требующих отключения клиентских приложений от Системы. Для данного типа сообщений должна быть предусмотрена возможность указания времени (в минутах), по истечении которого клиентские приложения должны быть автоматически отключены от Системы. Данное сообщение посылается всем подключенным клиентским приложениям и должно сопровождаться отображением счетчика обратного отсчета до автоматического отключения клиентского места. Сообщение должно отображаться поверх всех окон клиентского приложения. 26.2.2. Автоматически завершить работу всех подключенных клиентских приложений по истечении заданного времени. 26.2.3. Формировать простые текстовые сообщения подключенным пользователям Системы - Соответствие - - Значение характеристики не может изменяться участником закупки

26.2.4. Формировать текстовые сообщения всем пользователям Системы (не подключенные на момент формирования сообщения пользователи получат сообщение в момент следующего подключения). Пользователь должен получить сообщение только один раз вне зависимости от компьютера, на котором запущено клиентское приложение (в отличие от сообщений об автоматическом отключении клиентских приложений, простые текстовые сообщения должны отправляться не каждому клиентскому приложению, а пользователю, который был указан при подключении к клиентскому приложению. 26.2.5. Отзыв направленного ранее сообщения об отключении клиентских приложений. Автоматическое отключение клиентских приложений должно быть отменено, сообщение об отключении и таймер обратного отсчета на всех клиентских приложениях должны быть закрыты, должна быть возобновлена возможность подключения клиентских приложений. 26.2.6. Ведение журнала всех отправленных сообщений. 26.2.7. Ведение журнала получения сообщений пользователями. 26.3. Для оповещения должна быть предоставлена возможность выбора типа оповещения. Должна быть реализована возможность выбора следующих типов: 26.3.1. Оповещение о начале технических работ на сервере, о необходимости выхода из Системы и автоматического отключения клиента. 26.3.2. Простое оповещение только подключенным пользователям, автоматического отключения не происходит. 26.3.3. Оповещение всем пользователям, подключенным и не подключённым, неподключенные должны получить оповещение при первом входе в Систему. 26.4. Должен вестись журнал оповещений, обладающих следующими характеристиками: 26.4.1. Для каждого оповещения сохраняется информация с указанием их типа, текста сообщения, даты и времени отправки сообщения, пользователя, сформировавшего сообщения. 26.4.2. Журнал оповещений должен обладать средствами поиска сообщений по всем параметрам журнала. Реализованы фильтры по диапазону дат, пользователю, группе пользователей, текстовый поиск. 26.4.3. Невозможно удалить произвольное оповещение - Соответствие - - Значение характеристики не может изменяться участником закупки

26.4.4. Удалить записи журнала о старых оповещениях можно только до указанной даты. Права на удаление записей имеет только администратор. 26.4.5. Ведется дополнительный лог по пользователям, прочитавшим оповещение. Просмотр лога так же доступен в интерфейсе просмотра журнала - Соответствие - - Значение характеристики не может изменяться участником закупки

23. Требования к подсистеме «Обеспечение безопасности, администрирования и разграничения прав доступа»: 23.1. Подсистема должна: 23.1.1. Обеспечивать возможности индивидуальной настройки для каждого пользователя базовых ограничений прав и разрешений с возможностью дальнейшего расширения. 23.1.2. Возможности индивидуального ограничения просмотра реестра объектов любого из типов. 23.1.3. Возможности индивидуального ограничения просмотра данных карточек объектов учета любых типов. Предоставление прав на частичный просмотр информации по объекту (например, запрет на просмотр экономических показателей объекта, но разрешение на просмотр технических показателей). 23.1.4. Возможности ограничения доступа к персональным данным, требующим отдельной защиты. 23.1.5. Возможности индивидуального ограничения изменения данных по объектам учета всех типов. Предоставление прав на частичное изменение информации. 23.1.6. «Горизонтальное» ограничение прав на изменение множественных атрибутов объектов учета (например, пользователю предоставляются права на изменение/внесение в карточку объектов документов определенной направленности и закрываются права на правку документов иной направленности (например, реестровых документов)). 23.1.7. Ограничение прав на выполнение различных операций с объектом учета (выделение подобъектов, включение в группу). 23.1.8. Ограничение на операции с печатными формами (просмотр и печать отчетов и печатных форм, экспорт во внешние форматы (docx, xlsx), редактирование сформированных отчетов). Для печатных форм права должны назначаться индивидуально для каждого типа объектов учета, для аналитических отчетов – индивидуально для каждой темы отчета - Соответствие - - Значение характеристики не может изменяться участником закупки

23.1.9. Ограничение прав на работу с блоками начислений и платежей за аренду недвижимости и ЗУ (индивидуально на все функции, выполнение операций в каждом из режимов (индивидуальном, массовом)). 23.1.10. Ограничение прав на работу с универсальной библиотекой запросов – права предоставляются индивидуально для каждой темы запросов и на выполнение операций блока запросов (выполнение запроса, экспорт результатов). 23.1.11. Ограничение прав на работу с НСИ (права предоставляются индивидуально для каждого справочника или классификатора). 23.1.12. Ограничение права на настройки системы (индивидуально на каждый блок настроек). 23.2. Все права и разрешения на работу с объектами учета всех типов должны предоставляться индивидуально для каждой стадии формирования объекта учета (заявка, новый, актуальный (реестровый), актуальный зарегистрированный (в Росреестре), архивный, справочный, внереестровый или объект налогового потенциала). 23.3. В Системе должны присутствовать средства объединения пользователей в группы (причем, каждый пользователь может быть включен в одну и иное количество групп) с автоматическим наследованием всех прав и разрешений групп, в которые включен пользователь. 23.4. В Системе должны быть реализованы особые механизмы хранения и проверки паролей, обеспечивающие повышенную безопасность. При установке и смене пароля, новый пароль кодируется необратимыми алгоритмами (без возможности восстановления исходного пароля). 23.5. Разграничение прав пользователей единого информационного пространства: 23.5.1. Для каждого пользователя или группы пользователей должна быть предусмотрена возможность управления правами доступа (в объеме, описанном выше) индивидуально для каждого из информационных фондов организаций-участников, составляющих единую базу данных Системы. 23.5.2. В совокупности с возможностью сопоставления пользователей с соответствующими информационными фондами, а также автоматической идентификации принадлежности объектов учета к соответствующим информационным - Соответствие - - Значение характеристики не может изменяться участником закупки

27. Подсистема «Самодиагностика с автоматическим оповещением о выявленных аномалиях по электронной почте»: 27.1. Подсистема «Самодиагностика с автоматическим оповещением о выявленных аномалиях по электронной почте» должна быть использована в целях улучшения качества работы, уменьшения количества ошибок, уменьшения времени реагирования на появление проблемы. Должен быть сформирован набор тестов, проверяющих состояние работоспособности Системы и ее подсистем, возникновения проблем при взаимодействии Системы с внешними системами, возникновении некорректных данных в информационном фонде. Мониторинг работоспособности должен производиться непрерывно. Мониторинг целостности и непротиворечивости данных должен проверяться при помощи регламентных операций, выполняемых Системой по заданному расписанию (например, в ночное время). 27.2. Оповещения должны отправляться с использованием механизма очереди оповещений на адреса электронной почты, которые заданы при настройке подсистемы «Самодиагностика с автоматическим оповещением о выявленных аномалиях по электронной почте» - Соответствие - - Значение характеристики не может изменяться участником закупки

28. Средства ведения электронных карточек объектов учета: 28.1. Под объектом учета понимается любой объект, информация по которому должна быть учтена в едином информационном фонде Системы. Например, объектами учета являются: земельные участки любой формы собственности, а также земельные участки, собственность на которые не разграничена, объекты движимого и недвижимого имущества, субъекты права, документы, договоры, соглашения, претензионные и исковые процессы, финансовые поступления. 28.2.Для доступа к реквизитам (атрибутам, характеристикам) объекта учета в Системе должна быть предусмотрена отдельная экранная форма. Экранная форма по умолчанию должна открываться в режиме просмотра (возможность редактирования атрибутов объекта должна быть отключена) с возможностью переключения в режим редактирования. 28.3. Экранная форма доступа к реквизитам объекта должна отображать информацию по объекту учета в соответствии с правами и разрешениями пользователя (не отображать атрибуты объекта, для которых у пользователя отсутствуют права на просмотр). 28.4. При переключении экранной формы карточки объекта учета в режим редактирования доступ на редактирование должен быть предоставлен только к тем атрибутам объекта учета, на которые активный пользователь имеет права и разрешения на изменение. Остальные атрибуты должны оставаться в режиме просмотра (без возможности внесения изменений). - Соответствие - - Значение характеристики не может изменяться участником закупки

24. Требования к подсистеме «Ведение нормативно-справочной информации»: 24.1. Подсистема должна обеспечивает функционирование необходимого для эффективной работы Системы набора справочников и классификаторов. 24.1. Помимо федеральных справочников и классификаторов, а также справочников и классификаторов, формируемых в процессе поставки Системы, в состав Системы должен быть включен ряд дополнительных справочников, направленных на: 24.1.1. Повышение аналитических возможностей Системы. 24.1.2. Повышение возможностей Системы по расширению перечня учитываемых показателей. 24.1.3. Повышения адаптивности Системы к изменению законодательства, технологии учета, обеспечения быстрой настройки Системы под все нюансы работы органов управления имущественно-земельным комплексом. 24.2. В Системе должна быть возможность доступа к справочникам и классификаторам непосредственно в ходе редактирования параметра с выбором из справочника с целью выполнения расширенного поиска, а по необходимости и внесения изменений в классификатор. 24.3.Должна быть реализована возможность «привязки» как самих классификаторов, так и элементов классификации к видам реестров. Классификаторы и элементы классификации должно быть возможно выбрать только в тех реестрах, в которых это разрешено настройками Системы - Соответствие - - Значение характеристики не может изменяться участником закупки

29. Требования по ведению атрибутов объектов учета 29.1. Объект учета в обязательном порядке должен содержать следующую информацию: 29.1.1. Идентификатор (реестровый номер) – числовое значение, однозначно идентифицирующее объект учета (не должно существовать любого другого объекта учета, имеющего такой же идентификатор). Идентификатор должен присваиваться Системе автоматически при создании нового объекта. 29.1.2. Наименование (описание) объекта – строковое значение, описывающее объект, заполняется вручную, не является обязательным. 29.2. Объект учета должен иметь произвольное количество атрибутов (характеристик). Каждый атрибут должен содержать: 29.2.1. Наименование (идентификатор) атрибута – выбирается из соответствующих справочников наименований атрибутов каждого из типов данных. Должен быть предусмотрен инструмент формирования допустимого перечня атрибутов, который может быть указан (выбран) в карточке каждого из типов объектов учета (инструмент индивидуального формирования перечня атрибутов для каждого типа объектов учета). 29.2.2. Значение – указывается в зависимости от типа данных атрибута. 29.2.3. Период действия – дата начала периода действия атрибута и дата окончания периода действия атрибута. Индивидуально для каждого вида (наименования) атрибута должна быть предусмотрена возможность настройки допустимости пересечения периодов действия значений этого атрибута (множественный ввод значений одноименных атрибутов в один момент времени). 29.2.4. Перечень ссылок на документы основания начала действия значения атрибута – перечень ссылок на информацию о документах с обязательным указанием основного документа основания. - Соответствие - - Значение характеристики не может изменяться участником закупки

29.2.5. Перечень ссылок на документы основания окончания действия значения атрибута – перечень ссылок на информацию о документах с обязательным указанием основного документа основания. Индивидуально для каждого вида (наименования) атрибута должна быть предусмотрена возможность настройки использования документов оснований окончания действия (используется или нет). 29.2.6. Примечание – текстовое поле. 29.3. Система должна обеспечивать возможность ведения атрибутов объектов учета следующих типов данных: 29.3.1. Числовой тип (коэффициент). Должна быть предусмотрена возможность установки фиксированного значения величины коэффициента для каждого наименования коэффициента (наименования атрибута соответствующего типа) без возможности индивидуального изменения в карточке объекта учета (константа) или с возможностью индивидуального изменения (в этом случае значение, связанное с наименованием коэффициента, должно устанавливаться как значение по умолчанию с возможностью последующей корректировки индивидуально в карточке конкретного объекта). Такая настройка должна быть предусмотрена индивидуально для каждого вида (наименования) коэффициента. 29.3.2. Денежный тип (экономический показатель). 29.3.3. Строковый тип (технический, описательный показатель). Для каждого наименования атрибута данного типа должна быть предусмотрена возможность установки маски ввода значения атрибута - Соответствие - - Значение характеристики не может изменяться участником закупки

29.3.4. Классификационный тип – справочник. Для каждого наименования атрибута (категории классификационных данных) должна быть предусмотрена возможность индивидуальной настройки перечня (справочника) элементов классификатора данной категории. 29.3.5. Булевый тип – признак (да/нет). Допустимо отсутствие ведения информации по периоду действия и документам-основаниям. 29.3.6. Тип даты – событие. 29.3.7. Ссылка на субъект права – с указанием типа субъекта права. 29.4. Кроме того, в карточку объекта учета дополнительно должны быть загружены: 29.4.1. Информация по адресу объекта с использованием адресной подсистемы. 29.4.2. Произвольное количество файлов любого типа. Файлы должны загружаться как по одному, так и массово, путем выделения нескольких файлов в средстве работы с файлами операционной системы (проводнике, менеджере файлов). Должна быть предусмотрена возможность загрузки в карточку объектов файлов путем использования технологии Drag-And-Drop (перетащи и отпусти). Открытие файлов должно производиться непосредственно из Системы путем использования средств операционной системы, назначенных по умолчанию (аналогично открытию файлов проводником или другим менеджером файлов). Хранение прикрепленных файлов объекта учета должно производиться на сервере в базе данных или с использованием других средств, обеспечивающих надежность и скорость работы с файлами не хуже соответствующих инструментов СУБД (транзакционный механизм доступа с возможностью автоматического отката транзакций, завершившихся аварийно, резервное копирование). 29.4.3. Произвольное количество файлов распространенных графических форматов (jpg, bmp). Функционал аналогичен работе с прикрепленными файлами. Дополнительно в Системе должны быть предусмотрены средства предварительного просмотра графических изображений без открытия файлов (средства предварительного просмотра). 29.4.4. Информация о произвольном количестве документов: - Соответствие - - Значение характеристики не может изменяться участником закупки

29.4.4.1. Направление документа – значение из соответствующего справочника, указывающее на назначение документа в карточке объекта – определяется технологией работы с объектами соответствующего типа. 29.4.4.2. Номер документа. 29.4.4.3. Дата документа. 29.4.4.4. Тип документа – значение из классификатора типов документов. 29.4.4.5. Источник документа – значение из классификатора источников документов (организация, выпустившая документ). 29.4.4.6. Наименование документа – текстовое описание с возможностью выбора из справочника шаблонов наименований с возможностью последующего индивидуального изменения. 29.4.4.7. Примечание документа. 29.4.4.8. Ссылка на прикрепленный файл документа. 29.5. Сохранение карточки объекта учета (атрибутов, файлов, графических объектов, документов должно производиться на основе транзакционных механизмов, то есть либо вся измененная информация карточки (внесенные в карточку данные) должны быть успешно сохранены в базе данных, либо, например, в случае какой-либо ошибки, все изменения в базе данных, выполненные в процессе сохранения, должны быть отменены, и карточка вернется в состояние, предшествующее сохранению. Пользователь должен подробно быть проинформирован Системой о характере возникшей ошибки и, по возможности, Система даст рекомендации по способам исправления ошибки. После исправления пользователем причин, приведшим к ошибке, должна быть предусмотрена возможность повторного сохранения внесенных в карточку изменений. Частичное автоматическое внесение изменений в базу данных в процессе внесения изменений в карточку объектов недопустимо - Соответствие - - Значение характеристики не может изменяться участником закупки

38. Средства выполнения массовых операций: 38.1. Система должна иметь средства выполнения однотипных операций над заданным количеством объектов учета, в том числе: 38.1.1. Передача с баланса на баланс, в казну, из казны, списание объектов. 38.1.2. Внесение документа-основания. 38.1.3. Смена адреса. 38.1.4. Смена характеристик объектов учета. 38.1.5. Изменить нумерацию объектов. 38.1.6. Слияние «двойников». 38.1.7. Включить физическое лицо в очередь и исключить из очереди. 38.1.8. Выполнение массовых запросов СМЭВ к сервисам Росреестра и другим информационным системам, с которыми предусмотрено взаимодействие по протоколам СМЭВ. 38.1.9. Массовое формирование квитанций, уведомлений, претензий и других печатных форм на основе заданных шаблонов. 38.2 .Массовые операции должны повысить эффективность управления имущественно-земельным комплексом, снизить трудозатраты специалистов на выполнение операций над объектами - Соответствие - - Значение характеристики не может изменяться участником закупки

39. Требования к подсистеме «Бюджетный учет доходов»: 39.1. Подсистема бюджетного учета доходов должна применяться для администрирования доходов по всем администрируемым кодам бюджетной классификации, а также отражении в бухгалтерском учете активов, обязательств, фактов хозяйственной жизни, иных объектов бухгалтерского учета, возникающих при получении (предоставлении) во временное владение и пользование или во временное пользование материальных ценностей по договору аренды (имущественного найма) либо по договору безвозмездного пользования в соответствии с требованиями федеральных стандартов бухгалтерского учета для организаций муниципального сектора (в том числе бюджетный учет операций по льготной аренде, учет на забалансовых счетах бюджетного учета). 39.2. Подсистема должна быть полностью «прозрачной» для пользователей с точки зрения формирования всей необходимой бухгалтерской информации (проводок)/информации по бюджетному учету, соответствующих выполнению финансово-аналитических операций, проведению и оформлению результатов инвентаризации. Иными словами, Система автоматически должна формировать необходимую бухгалтерскую информацию (проводки) в соответствии со всеми требованиями, определенными инструкциями Министерства финансов РФ от 1 декабря 2010 года № 157н, от 6 декабря 2010 года № 162н, от 16 декабря 2010 года № 174н, № 258н от 31 декабря 2016 года, № 209н от 29 ноября 2017 года, федеральными стандартами бухгалтерского учета для организаций муниципального сектора, отслеживая эффективность работы муниципального учреждения. 39.3. Печатные формы и отчеты должны удовлетворять формам бухгалтерской отчетности организаций согласно приказу Министерства Финансов РФ № 66н от 2 июля 2010 года и № 52н от 30 марта 2015 года: 39.3.1. Бухгалтерский отчет «Информация по администрируемым доходам, обобщенный (свернутый)» и запрос-расшифровка к нему «Бухгалтерия подоговорная». 39.3.2. Оборотно-сальдовые ведомости по счетам (Счета 205, 401, 209, 210). - Соответствие - - Значение характеристики не может изменяться участником закупки

39.3.3. Журнал операций № 2 с безналичными денежными средствами (ОКУД 504071). 39.3.4. Журнал операций № 5 расчет с дебиторами по доходам (ОКУД 504071). 39.3.5. Дебиторская и кредиторская задолженность (ОКУД 0504089). 39.3.6. Сведения о дебиторской и кредиторской задолженности учреждения (ОКУД 0503169). 39.4. Автоматическое формирование информации по бюджетному учету в соответствии с перечисленными выше требованиями должно производиться на уровне СУБД, то есть гарантировано, что соответствующие операции бюджетного учета должны быть произведены корректно даже в том случае, если внесение изменений в соответствующие финансовые операции произведены не штатными средствами Системы. Например, в ходе ручного запуска скрипта на корректировку данных непосредственно в базе данных, при регламентном обслуживании базы данных и в любых других случаях. 39.5. Подсистема бюджетного учета доходов от использования муниципальной собственности должна автоматизировать выполнение следующих основных задач: 39.5.1. Автоматизация формирования бухгалтерских проводок при выполнении финансово-аналитических операций - Соответствие - - Значение характеристики не может изменяться участником закупки

39.5.2. Автоматизация формирования корректирующих проводок при корректировке финансово-аналитической информации «задним числом». Если операция корректировки проводится до сдачи бухгалтерской отчетности за соответствующий период, то выполняется корректировка соответствующих проводок датой проведения аналитической операции, иначе формируются дополнительные корректирующие проводки текущим числом (при изменении суммы аналитической операции в большую сторону выполняется формирование проводки по доначислению, если в меньшую – формируется соответствующая сторнирующая проводка). 39.5.3. Автоматизация работы с документами-основаниями проведения операций бюджетного учета. 39.5.4. Автоматизация формирования журнала операций за период, бухгалтерской справки по исправлениям. 39.5.5. Выгрузка консолидированной информации в электронном виде за период для передачи в бухгалтерские системы. 39.5.6. Индивидуальное «закрытие» периодов по каждому из КБК при сдаче отчетности (блокировка внесения изменений в информацию бюджетного учета «задним числом») - Соответствие - - Значение характеристики не может изменяться участником закупки

40. Требования к подсистеме «Бюджетный учет движения объектов в казне»: 40.1. Подсистема должна применяться для автоматического формирования всей необходимой бухгалтерской информации (проводок)/информации по бюджетному учету, соответствующих выполнению финансово-аналитических операций, проведению и оформлению результатов инвентаризации. Иными словами, подсистема автоматически должна формировать необходимую бухгалтерскую информацию (проводки) в соответствии со всеми требованиями, определенными инструкциями Министерства финансов РФ от 1 декабря 2010 года № 157н, от 6 декабря 2010 года № 162н, от 16 декабря 2010 года № 174н, № 258н от 31 декабря 2016 года, № 209н от 29 ноября 2017 года, федеральными стандартами бухгалтерского учета для организаций муниципального сектора, отслеживая эффективность работы муниципального учреждения. 40.2. Печатные формы и отчеты должны удовлетворять формам бухгалтерской отчетности организаций согласно приказу Министерства Финансов РФ № 66н от 2 июля 2010 года и № 52н от 30 марта 2015 года: 40.2.1. Бухгалтерский отчет 645 «Отчет для движения (Казна, Забаланс)» и запрос-расшифровка к нему 645 «Расшифровка отчета для движения». 40.2.2. Оборотно-сальдовые ведомости по счетам (Счета 104, 108 (в разрезе аналитических счетов), 401, 25, 26). 40.2.3. Журнал операций № 7 по выбытию и перемещению нефинансовых активов (ОКУД 504071). 40.2.4. Сведения о движении нефинансовых активов (ОКУД 0503168). 40.2.5. Инвентаризационная опись основных средств (ОКУД 0317001). - Соответствие - - Значение характеристики не может изменяться участником закупки

37. Средства поиска, отображения и анализа информации: 37.1. Средства поиска, отображения и анализа информации должны быть включены во все экранные формы работы со списками объектов учета, в том числе в экранные формы работы с объектами реестра. 37.2. Средства поиска должны обеспечивать возможности поиска объектов учета по всем характеристикам самих объектов, а также по всем характеристикам связанных объектов учета любого уровня вложенности (например, поиск объектов по параметрам связанных объектов учета, которые связаны со связанными объектами учета. – поиск объектов по параметрам договоров на них и параметрам субъектов этих договоров). 37.3. Для каждой из характеристик должны быть предусмотрены следующие логические условия поиска: 37.3.1. Равно. 37.3.2. Не равно. 37.3.3. Больше. 37.3.4. Меньше. 37.3.5. Больше или равно. 37.3.6. Меньше или равно. 7. Содержит (для текстовых характеристик). 37.3.8. Не содержит (для текстовых характеристик). 37.3.9. Начинается на (для текстовых характеристик). 37.3.10. Не начинается на (для текстовых характеристик). 37.3.11. Заполнено. 37.3.12. Не заполнено. 37.3.13. Отсутствует. 37.4. Для характеристик, имеющих историю изменения, должны быть предусмотрены средства указания даты, на которую выполняется поиск значения характеристики. 37.5. Для сложных или связанных характеристик должны быть предусмотрены возможности поиска по комбинациям значений (например, поиск по коэффициентам подразумевает возможность поиска по произвольной комбинации значений, составляющих информацию по коэффициенту – наименование коэффициента, величина, диапазон дат периода действия коэффициента) - Соответствие - - Значение характеристики не может изменяться участником закупки

37.6. Должен быть предусмотрен поиск по отрицанию условий поиска (объекты, НЕ удовлетворяющие условиям поиска). 37.7. Должна быть предусмотрена возможность комбинации условий поиска – поиск в найденном и новый поиск в дополнение к предыдущему. 37.8. Должна быть предусмотрена возможность сохранение ранее сформированных условий поиска для последующего быстрого использования. 37.9. Для администраторов системы должна быть предусмотрена возможность формирования и отображения SQL-скрипта, соответствующего выборке объектов учета для формирования списка с учетом SQL-выражений, удовлетворяющих сформированным условиям поиска. 37.10. Администратор должен иметь возможность ручной корректировки сформированных SQL-выражений поиска с возможностью выполнения поиска на основе скорректированных SQL-выражений. 37.11. В любой списочной форме (экранной форме отображения списка объектов учета или множественных реквизитов, атрибутов, характеристик объектов учета) должны быть предусмотрены средства контекстного поиска – возможность ввода символов в любой из колонок списка с автоматическим позиционированием курсора в списке на первый объект, соответствующий условиям поиска (вводимым значениям). 37.12. В любой форме отображения списка объектов учета должна быть предусмотрена возможность отображения средств предварительного просмотра. Например, в списке договоров можно отобразить перечень кадастровых номеров земельных участков, арендуемых по текущему договору в списке, или перечень документов-оснований, перечень дополнительных соглашений, развернутую информацию о задолженности по договору - Соответствие - - Значение характеристики не может изменяться участником закупки

17. Требования к подсистеме «Ведение договоров и дополнительных соглашений»: 17.1. Подсистема управления договорами и дополнительными соглашениями должна автоматизировать выполнение всех задач ведения соответствующих договорных отношений и претензий за фактическое использование объектов без заключения договорных отношений. 17.2. Подсистема «Имущество» автоматизирует ведение договоров и других правовых отношений следующих типов: 17.2.1. Договор социального найма жилья (для объектов жилого фонда). 17.2.2. Договор специализированного найма жилья (для объектов жилого фонда). 17.2.3. Договоры на согласовании (при заключении договора балансодержателями имущества). 17.2.4. Договор аренды. 17.2.5. Договор купли/продажи/приватизации. 17.2.6. Договор выкупа с рассрочкой. 17.2.7. Договор безвозмездного пользования объектов движимого имущества. 17.2.8. Договор безвозмездного пользования недвижимого имущества, имущественных комплексов. 17.2.9. Договор мены. 17.2.10. Договор дарения. 17.2.11. Распорядительный документ по праву постоянного бессрочного пользования. 17.3. Подсистема «Земля» автоматизирует ведение договоров и других правовых отношений следующих типов: 17.3.1. Договор аренды. 17.3.2. Соглашение о перераспределении земельных участков. 17.3.3. Договор безвозмездного пользования. 17.3.4. Соглашение о сервитуте (публичном сервитуте) - Соответствие - - Значение характеристики не может изменяться участником закупки

17.3.5. Разрешения на использование земельного участка без его предоставления и установления сервитута. 17.3.6. Претензия за фактическое использование участка без заключения договора (расчеты в соответствии с требованиями Гражданского кодекса РФ). 17.4. Подсистема управления договорами и дополнительными соглашениями должна автоматизировать решение следующих основных задач: 17.4.1. Учет всех условий договоров и дополнительных соглашений. По каждому договору и доп. соглашению ведется следующая основная информация: 17.4.1.1. Номер и дата договора, доп. соглашения, номер и дата регистрации. 17.4.1.2. Код бюджетной классификации. 17.4.1.3. Тип использования, целевое использование. 17.4.1.4. Дата начала фактического использования объекта договора (для определения периода фактического использования). 17.4.1.5. Дата начала действия, планируемого и фактического окончания (расторжения), дата фактического освобождения объекта (для определения периода фактического использования объекта после расторжения договора). 17.4.1.6. Особые условия, ограничения. 17.4.1.7. Документы-основания, документы на льготы, другие документы. 17.4.1.8. Комиссии. 17.4.1.9. Объекты договора (может быть несколько объектов в договоре) – с возможностью указания периода нахождения объекта или его доли в договоре, доли объектов учета по договору – с историей изменения величины доли. 17.4.1.10. Формула (алгоритм) расчета планируемой платы по договору (индивидуально для каждого объекта или доли объекта в договоре) – с историей изменения. 17.4.1.11. Коэффициенты, ставки, индивидуальные показатели, другие характеристики, участвующие в автоматическом расчете планируемой арендной платы (индивидуально по каждому объекту в договоре) – с историей изменения - Соответствие - - Значение характеристики не может изменяться участником закупки

37.13. Средства предварительного просмотра должны представлять собой печатные формы, сформированные с использованием генератора отчетов, и отображающие всю необходимую информацию по текущему объекту учета в списке без выполнения дополнительных действий со стороны пользователя. Для каждого типа объектов учета может быть настроено произвольное количество форм предварительного просмотра с возможностью выбора текущей отображаемой формы из списка доступных форм. 37.14. Средства предварительного просмотра должны обладать всеми возможностями печатных форм, включая возможность открытия карточки объекта учета путем двойного клика по информации по нему в окне предварительного просмотра (например, открытие карточки земельного участка из окна предварительного просмотра договоров, отображающего перечень земельных участков по текущему договору). 37.15. Аналитические средства элементов работы со списками объектов учета 37.15.1. Группировка данных по одному или нескольким столбцам. Например, реестр может быть сгруппирован по состоянию объектов учета, району области, разрешенному использованию. 37.15.2. Вычисление общих итогов, в том числе для каждой из групп (в случае применения группировки). Например, для приведенного примера возможна автоматическая калькуляция общей планируемой платы, площади объектов, величины задолженности в разрезе состояний договоров аренды, района расположения объекта договора, целевого использования; 37.15.3. Дополнительная оперативная фильтрация данных по значениям любого столбца\совокупности столбцов; 37.15.4. Сортировка данных по произвольному столбцу\совокупности столбцов. 5. Возможность выбора отображаемых столбцов. 37.15.6. Автоматическое сохранение настроек табличного представления для каждого типа объектов учета. 37.16. Должна быть предусмотрена возможность экспорта сформированных данных в форматы табличные форматы (xlsx, csv), текстового файла или внутренние форматы генератора отчетов. - Соответствие - - Значение характеристики не может изменяться участником закупки

37.17. В Системе должна быть реализована возможность автоматического предварительного просмотра документа непосредственно в табличной форме реестра любого типа объектов. При переходе от одного к другому объекту в списке, форма предварительного просмотра должна обновляться автоматически. 37.18. Должна быть реализована возможность отключать данный режим, настраивать форму просмотра, выбирая нужный шаблон документа, из списка доступных для данного режима, шаблонов. Должна быть возможность создавать и редактировать шаблоны документов для данного режима наряду с любыми другими шаблонами документов - Соответствие - - Значение характеристики не может изменяться участником закупки

15. Требования к подсистеме Подсистема «Ведение информации по акциям»: 15.1. В Системе должна быть возможность ведения информации об акциях (долях), находящихся в собственности муниципального образования. 15.2. В рамках подсистемы помимо стандартных атрибутов должна быть предусмотрена возможность ведения следующей информации: 15.2.1. Субъекты акций (сведения об эмитенте, совете директоров, ревизионных комиссиях). 15.2.2. Субъекты долей (сведения об обществе, совете директоров, ревизионных комиссиях). 15.2.3. Заседания совета директоров и общего собрания акционеров (участников), включая возможность фиксации решения собрания, загрузки протоколов. 15.2.4. Информация о стоимостях акций (долей) и количестве акций (в разрезах видов акций). 15.2.5. Сведения о собраниях советов директоров и ревизионных комиссий (включая состав совета, протокол). 15.2.6. Бюджетный учет акций (долей) в казне. 15.2.7. Сведения об эмитенте (обществе), а также возможность перехода в реестр договоров для получения информации о долговых обязательствах с расшифровкой по каждому кредитору, реквизитами заключенных договоров, существенными условиями по каждому договору, основному долгу и процентам - Соответствие - - Значение характеристики не может изменяться участником закупки

16. Требования к подсистеме «Адресная подсистема»: 16.1. «Адресная подсистема» (средства формирования адресов объектов для реестровой подсистемы учета) должна обеспечивать возможность формирования и учета произвольного количества адресов для каждого объекта учета. 16.2. Для каждого из адресов должна быть предусмотрена возможность указания типа адреса на основе расширяемого классификатора (присвоенный адрес – официальный, юридический адрес, предыдущий адрес (при наличии) и адресного ориентира (местоположение объекта учета). 16.3. Присвоенный адрес – официальный, должен быть один. 16.4. «Адресная подсистема» должна обеспечивать возможность указания адресных реквизитов, утвержденных, постановлением Правительства РФ от 19.11.2014 № 1221 как с использованием собственных справочников и классификаторов присвоенных адресов или установленных ранее, включая адресный ориентир, так и с использованием базы федеральной информационной адресной системы (ФИАС). 16.5. «Адресная подсистема» должна обеспечивать возможность настройки шаблона вывода адреса (формирования строки адреса) для каждого из типов объектов учета (наименований реестров объектов учета). Шаблон должен обеспечивать возможность указания адресных реквизитов в соответствии с требованиями к структуре адреса, например, , , , , или , , , и т.п. 16.6. Строка адреса обязательно отображается в карточке объекта учета и в списке объектов учета соответствующего типа. 16.7. «Адресная подсистема» должна обеспечивать возможность ввода адреса любых объектов учета, включая адреса комнат, офисов, территорий и т.д. Должна быть предусмотрена возможность указания адресного ориентира. 16.8. «Адресная подсистема» должна обеспечивать возможность ввода адреса следующей структуры: 16.8.1. Наименование страны (Российская Федерация) – выбирается из справочника. 16.8.2. Наименование субъекта Российской Федерации – выбирается из справочника. - Соответствие - - Значение характеристики не может изменяться участником закупки

17.4.1.12. Субъекты договора (с историей изменения, периодами действия для переуступки, субаренды, доверенности, ссылками на документы-основания). 17.4.1.13. Информация по субаренде с привязкой к объектам субаренды и характеристикам, коэффициентам, влияющим на расчет суммы планируемой арендной платы на субарендуемые площади (индивидуально для каждого субарендатора и субъекта субаренды) – с периодами действия. 17.4.1.14. Информация по планируемой плате по договору (с полной историей изменения) 17.4.1.15. Схема начисления в соответствии с условиями договора с историей изменения. 17.4.1.16. Индивидуальные ставки пени – с историей изменения и ссылками на документы-основаниями, а также возможностью индивидуальной настройки количества знаков после запятой для расчетов пени, а также возможности начисления процентов вместо пени. 17.4.1.17. Индивидуальные ставки процентов за пользование чужими денежными средствами – с историей изменения и ссылками на документы-основаниями, а также возможностью индивидуальной настройки количества знаков после запятой для расчетов процентов, а также возможности начисления пени вместо процентов. 17.4.2. Управление дополнительными соглашениями, изменениями условий договора по дополнительным соглашениям. 17.4.3. Управление договорами с множественностью лиц. 17.4.4. Управление договорами с множественностью объектов. 17.4.5. Переоформление, продление договоров. 17.4.6. Автоматизация процесса переуступки права по договору. 17.4.7. Переоформление договоров аренды земельных участков при разграничении собственности на объекты аренды. 17.4.8. Автоматизированный расчет суммы планируемой платы, платы за выкуп с учетом всех особых условий договора - Соответствие - - Значение характеристики не может изменяться участником закупки

17.4.9. Автоматизация расчета суммы планируемой платы по договору с учетом истории изменения расчетных величин, изменения условий договора по доп. соглашениям, учета различных особых условий (в том числе различные виды льгот, субаренда, долевая аренда/выкуп, аренда/выкуп с разными типами использования объектов договора, автоматическим поднятием до установленных минимумов). 17.4.10. Автоматизация подготовки необходимых печатных форм (в том числе текстов договора, доп. Соглашения, проектов постановлений, распоряжений, приказов). 17.4.11. Формирование аналитики по задолженности, работа с должниками. 17.4.12. Автоматизация претензионной и исковой деятельности. 17.4.13. Формирование аналитической отчетности в соответствующей сфере. 17.4.14. Проведение экспресс-аналитики и др. 17.5. Индивидуальные ставки пени и процентов: 17.5.1. В Системе должна быть предусмотрена возможность ведения индивидуальных ставок пени для каждого договора с указанием периода действия индивидуальной ставки, а также документа-основания. 17.5.2. Средства настройки индивидуальной ставки пени должны предусматривать возможность дополнительной настройки следующих параметров: 17.5.2.1. Возможность указания конкретной величины ставки (в процентах или абсолютных единицах) или указание на ставку со значениями, задаваемыми справочником (например, ставка рефинансирования, ключевая ставка, среднебанковская ставка для вкладов физических лиц). 17.5.2.2. Доля ставки (знаменатель при указании ставки в виде простой дроби). 17.5.2.3. Количество знаков после запятой при расчете величины ставки в абсолютных единицах (по умолчанию – максимально возможное). 17.5.2.4. Признак необходимости расчета пени по методике равного количества дней в месяце (30 дней в месяце, 360 дней в году). 17.5.2.5. Признак необходимости расчета процентов за пользование чужими денежными средствами вместо пени - Соответствие - - Значение характеристики не может изменяться участником закупки

40.3. Автоматическое формирование информации по бюджетному учету в соответствии с перечисленными выше требованиями должно производиться на уровне СУБД, то есть должно быть гарантировано, что соответствующие операции бюджетного учета должны быть произведены корректно даже в том случае, если внесение изменений в соответствующие финансовые операции произведены не штатными средствами Системы. Например, в ходе ручного запуска скрипта на корректировку данных непосредственно в базе данных, при регламентном обслуживании базы данных и в любых других случаях. 40.4. Подсистема бюджетного учета движения объектов в казне должны автоматизировать выполнение следующих основных задач: 40.4.1. Автоматизация формирования бухгалтерских проводок (балансовый и забалансовый учет) при включении/исключении объектов в казне. Проводки формируются на основе данных о балансовой и остаточной стоимостях объектов (кадастровой стоимости в случае земельных участков). Должна быть предусмотрена возможность в качестве балансовой и остаточной стоимости указывать другие виды стоимости (инвентарная, восстановительная, оценочная). 40.4.2. Автоматизация формирования корректирующих проводок при корректировке информации по стоимостям объектов в казне «задним числом». Корректировка проводится по тем же правилам, что и в случае бюджетного учета доходов. 40.4.3. Автоматизация работы с документами-основаниями проведения операций бюджетного учета движения объектов в казне. 40.4.4. Автоматизация формирования журнала операций за период, бухгалтерской справки по исправлениям. 40.4.5. Выгрузка консолидированной информации в электронном виде за период для последующей передачи в бухгалтерские системы. 40.4.6. Формирование количественной и финансовой информации по движению объектов в казне за период. 40.4.7. Формирование другой аналитической отчетности. 40.4.8. Для малоценного движимого имущества должна быть предусмотрена возможность ведения учета: - Соответствие - - Значение характеристики не может изменяться участником закупки

40.4.8.1. Ведение всего пакета движимого имущества в казне и на балансе консолидировано единой суммой соответствующих активов. 40.4.8.2. Ведение движимого имущества пакетами одноименных объектов с указанием их количества и стоимостных характеристик единицы (например, наименование – стол, количество – 50, балансовая стоимость единицы 1000 рублей, балансовая стоимость общая 50 000 рублей). 40.4.8.3. Ведение малоценного движимого имущества пообъектно с возможностью указания (присвоения) реестровых и/или инвентарных номеров. 40.5. Бюджетный учет движения малоценного движимого имущества должен осуществляться в соответствии с требованиями, предъявляемыми к бюджетному учету имущества, вне зависимости от используемой технологии учета. 40.6. Должны быть предусмотрены средства автоматизации бюджетного учета акций в казне в соответствии с требованиями, предъявляемыми к бюджетному учету акций - Соответствие - - Значение характеристики не может изменяться участником закупки

17.5.2.6. Признак «плавающей» ставки пени в периоде расчета («Плавающая» или фиксированная на день исполнения денежных обязательств или их части). 17.5.3. В периоде действия индивидуальных ставок пени расчет пени по договору должен производиться по общей методике, в противном случае – по технологии, определенной по умолчанию для данного вида договора и/или схеме начисления. 17.5.4. Аналогично должна быть реализована возможность для ведения индивидуальных ставок процентов за пользование чужими денежными средствами. 17.5.5. По умолчанию должна применяться методика, соответствующая 395 статье Гражданского кодекса РФ (с учетом всех редакций данной статьи, распространяющих действия до следующего внесения изменений в статью). 17.5.6. Средства настройки индивидуальной ставки процентов должны предусматривать возможность дополнительной настройки следующих параметров: 17.5.6.1. Возможность указания конкретной величины ставки (в процентах или абсолютных единицах) или указание на ставку со значениями, задаваемыми справочником (например, ставка рефинансирования, ключевая ставка, среднебанковская ставка для вкладов физических лиц); 17.5.6.2. Доля ставки (знаменатель при указании ставки в виде простой дроби); 17.5.6.3. Количество знаков после запятой при расчете величины ставки в абсолютных единицах (по умолчанию – максимально возможное). 17.5.6.4. Признак необходимости расчета пени по методике равного количества дней в месяце (30 дней в месяце, 360 дней в году). 17.5.6.5. Признак необходимости расчета пени вместо процентов за пользование чужими денежными средствами. 17.5.6.6. Признак «плавающей» ставки процентов в периоде расчета («Плавающая» или фиксированная на день исполнения денежных обязательств или их части). 17.5.7. В периоде действия индивидуальных ставок пени расчет пени по договору должен производиться по общей методике, в противном случае – по технологии, определенной по умолчанию для данного вида договора и/или схеме начисления - Соответствие - - Значение характеристики не может изменяться участником закупки

18. Требования к подсистеме «Выкуп с рассрочкой»: 18.1. Подсистема «Выкуп с рассрочкой» необходима для ведения учета договоров выкупа с рассрочкой согласно Федерального закона «Об особенностях отчуждения недвижимого имущества, находящегося в муниципальной собственности субъектов Российской Федерации или в муниципальной собственности и арендуемого субъектами малого и среднего предпринимательства, и о внесении изменений в отдельные законодательные акты Российской Федерации» от 22.07.2008 N 159ФЗ (с изменениями от 08.06.2020). 18.2. Данная подсистема должна включать в себя как весь функционал подсистемы «Подсистема ведения договоров и дополнительных соглашений», так и специфические особенности учета договоров выкупа с рассрочкой: 18.2.1. Подсистема должна иметь возможность настройки графика платежей. Для этого необходимо указать цену выкупа объекта, количество месяцев рассрочки, сумму и дату первого взноса. После проведения настройки должна иметься возможность формирования первоначального графика платежей. Должна иметься возможность смещать график платежей на любое количество периодов (как в будущее, так и в прошлое, как первый, так и последующие календарные периоды). Ставка рефинансирования (ключевая ставка) должна определяться автоматически на дату подписания договора, при расчете начисления процентов данная ставка делится на 3. Начисления основного долга и процентов должны соответствовать дифференцированной схеме (не аннуитет). 18.2.2. При распределении платежей на договор в первую очередь должна погашаться задолженность по процентам, а оставшаяся сумма платежа покрывает задолженность по основному долгу. Данные суммы вычисляются системой автоматически. При этом после каждого распределения платежей сумма последующих начислений процентов пересчитывается автоматически. 18.2.3. Должны иметься гибкие возможности настройки данной подсистемы, в том числе: 18.2.3.1. Начисление должны производиться одной суммой или с разбивкой на основной платеж и проценты. - Соответствие - - Значение характеристики не может изменяться участником закупки

18.2.3.2. Начисление пени должны производиться только на основной платеж или как на основной платеж, так и на проценты. 18.2.3.3. Ставку рефинансирования и график начисления платежей должна иметься возможность учитывать с даты начала договора, даты подписания договора, даты публикации договора, даты договора, с указанием конкретной даты вручную. 18.2.3.4. Начисление процентов производить на первоначальный взнос или не производить. 18.2.3.5. Платеж в первую очередь должен погашать пеню, потом процент, потом основной долг (либо в первую очередь на процент, а оставшуюся сумма платежа – на основной долг) - Соответствие - - Значение характеристики не может изменяться участником закупки

16.8.3. Наименование муниципального района, городского округа или внутригородской территории (для городов федерального значения) в составе субъекта Российской Федерации – выбирается из справочника. 16.8.4. Наименование городского или сельского поселения в составе муниципального района (для муниципального района) или внутригородского района городского округа – выбирается из справочника. 16.8.5. Наименование населенного пункта – выбирается из справочника. 16.8.6. Наименование элемента планировочной структуры – выбирается из справочника. 16.8.7. Наименование элемента улично-дорожной сети – выбирается из справочника присвоенных наименований элементам УДС. 16.8.8. Номер земельного участка. 16.8.9. Тип и номер здания, сооружения или объекта незавершенного строительства. 16.8.10. Тип и номер помещения, расположенного в здании или сооружении. 16.9. Перечень элементов планировочной структуры (справочник), элементов улично-дорожной сети (справочник), элементов объектов адресации, типов зданий (сооружений) и помещений, используемых в качестве реквизитов адреса (справочники), а также правила сокращенного наименования адресообразующих элементов устанавливаются Министерством финансов Российской Федерации. 16.10. Для зависимых справочников должна быть предусмотрена возможность автоматической подфильтровки допустимых для выбора элементов при заполнении элементов вышестоящих классификаторов, от которых зависят данные. 16.11.Если значения вышестоящих классификаторов не заданы, то при выборе элемента некоторого зависимого справочника элементы вышестоящих справочников должны заполниться (выбраться автоматически). 16.12. Особенности работы адресной подсистемы при использовании ФИАС: 16.12.1. При использовании сведений об адресе из ФИАС ввод или изменение адреса объекта учета должно производиться в отдельной строке экранной формы объекта учета с обязательным внесением уникального номера адреса объекта адресации из государственного адресного реестра - Соответствие - - Значение характеристики не может изменяться участником закупки

16.12.2. Структура базы данных для хранения данных ФИАС должна полностью соответствовать структуре данных ФИАС. 16.12.3. Элементы ФИАС должны быть расположены в отдельной базе данных Системы, для которой должен быть предоставлен отдельный режим обслуживания и резервного копирования. 16.12.4. В адресной подсистеме должен быть предусмотрен режим обновления во всех подсистемах Системы адресообразующих элементов, включая уникальный номер адреса объекта адресации в государственном адресном реестре базы данных ФИАС - Соответствие - - Значение характеристики не может изменяться участником закупки

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

30. Требования к элементам формы карточки объектов: 30.1. Средства работы с атрибутами каждого из доступных типов данных по умолчанию должны содержаться в экранных контейнерах (панелях экранной формы), контейнеры должны быть размещены на вкладках экранной формы. 30.2. Экранные контейнеры должны представлять собой панели прямоугольной формы, на которой размещаются элементы управления (просмотра, редактирования) атрибутами объектов учета. 30.3. Для экранных контейнеров должна быть предусмотрена возможность выполнения следующих действий: 30.3.1. Изменение размеров контейнера (высота, ширина). 30.3.2. Перемещение контейнера по экранной форме, включая перемещение контейнера на другие вкладки (на свободное место экранной формы (не занятое другими элементами управления) имеющем размеры, достаточные для вмещения контейнера). 30.4. Должна быть предусмотрена возможность для каждого типа объектов учета создания произвольного количества контейнеров с размещением в них произвольного количества логически связанных атрибутов любых типов единым списком. Для каждого атрибута, размещаемого в создаваемом контейнере, должна быть предусмотрена возможность указания признака автоматического добавления атрибута в карточку объекта учета и порядкового номера по умолчанию отображения автоматически добавленных атрибутов в контейнере. Автоматически добавляемые атрибуты должны добавляться в контейнер автоматически с последующим возможным указанием пользователем их значения. Должна быть предусмотрена возможность визуальной индикации в контейнере атрибутов, добавленных автоматически, но значение которых пользователем еще не введены (по факту такие атрибуты для объекта учета еще не определены). 30.5. Для экранной формы должны быть предусмотрены следующие возможности по работе с вкладками: 30.5.1. Добавление вкладок. 30.5.2. Изменение наименований вкладок. 30.5.3. Изменение порядка следования вкладок. 30.5.4. Удаление вкладок, не содержащих элементов управления или контейнеров - Соответствие - - Значение характеристики не может изменяться участником закупки

31. Требования к меню доступа к объектам учета и работы со списками: 31.1. Система должна содержать в своем составе средства настройки иерархического меню доступа к объектам учета всех типов с учетом возможностей по добавлению новых объектов учета. 31.2. Доступ к меню доступа к объектам учета должен предоставляться из основного окна Системы. 31.3. Доступ к каждому пункту меню должен осуществляться за минимальное количество действий пользователя. При возобновлении сеанса работы с Системой (повторном запуске Системы) позиция текущего пункта меню в иерархическом меню должна быть восстановлена автоматически, то есть доступ к объектам учета соответствующего типа должен осуществляться путем использования одного клика мыши. 31.4. Иерархическое меню должно иметь элементы следующих типов: 31.4.1. Промежуточные узлы – нажатие на этот пункт меню должно раскрывать следующий уровень иерархии (отображать вложенные пункты меню). 31.4.2. Промежуточные узлы-реестры – нажатие на данный пункт меню должен открыть объединенный список объектов учета, соответствующий совокупности объектов учета всех конечных элементов меню, вложенных с учетом иерархии в данный пункт (узел). Для данного типа пункта меню должна быть возможность открытия вложенных пунктов меню без открытия объединенного реестра. 31.4.3. Конечный узел – открывает список объектов учета, соответствующий данному пункту меню. 31.4.4. Конечный узел объединенного реестра – открывает объединенный список объектов учета, соответствующий конечным узлам пунктов меню, находящихся на этом же уровне иерархии (имеющих единый промежуточный узел). 31.5. В иерархическом меню должна быть предусмотрена возможность добавления пунктов, для которых может быть указан дополнительный фильтр, который автоматически применяется при отображении списка объектов, отображаемых с помощью данного пункта меню - Соответствие - - Значение характеристики не может изменяться участником закупки

19. «Финансово-аналитическая подсистема»: 19.1. «Финансово-аналитическая подсистема» является ключевой с точки зрения определения и повышения эффективности неналоговых поступлений от использования муниципальной собственности. 19.2. Подсистема должна обеспечивать широкие возможности точной настройки на все нюансы федерального, регионального и местного законодательства, особенностей технологии управления имущественно-земельным комплексом, принятым в соответствующих органах управления собственностью и земельными ресурсами региона. 19.3. «Финансово-аналитическая подсистема» должна обеспечивать автоматизацию выполнения следующих основных задач: 19.3.1. Управление финансово-аналитической информацией (начислениями всех типов, платежами, задолженностью) в разрезах договоров, кодов бюджетной классификации (аналитических уровней), видов договоров, субъектов. 19.3.2. Автоматическое формирование начислений по договору возмездного и безвозмездного пользования, платы за фактическое использование, льготной арендной платы, платы за выкуп. Система автоматически должна определять, какой из видов начисления необходимо произвести в соответствии с условиями договорных соглашений (с учетом всех доп. соглашений и других корректировок), норм Гражданского Кодекса, в тех периодах использования объектов, которые не регулируются договором (в том числе фактическое использование объектов без договора, до заключения договора, в периоде до регистрации договора, после расторжения договора до даты освобождения объекта). 19.3.3. Автоматическое начисление пени, процентов, других штрафных санкций за пользование чужими денежными средствами. Система автоматически должна определять вид начисления (штрафных санкций) исходя из условий договора или руководствуясь нормами гражданского Кодекса в периоде фактического использования объекта. 19.3.4. Автоматическое доначисление по доп. соглашениям, изменяющим условия договора «задним числом». 19.3.5. Автоматический расчет сальдо - Соответствие - - Значение характеристики не может изменяться участником закупки

19.3.6. Автоматический перерасчет планируемой платы по договору (например, в ходе массовой индексации по уровню инфляции). 19.3.7. Импорт платежей из электронных источников (выгрузка из ЭБ и др.). 19.3.8. Автоматическое, полуавтоматическое и ручное распределение и перераспределение поступлений по субъектам договоров, договорам, видам начислений. 19.3.9. Формирование информации о задолженности в любом разрезе и на произвольную дату. 19.3.10. Формирование информации о динамике возникновения задолженности. 19.3.11. Управление начислениями по решению суда, автоматизация работы с реструктуризацией задолженности. 19.3.12. Ведение протоколов выполнения автоматических операций, возможности по эвристическому анализу информационного фонда на предмет корректности исходной информации для выполнения автоматических операций. 19.3.13. Автоматизация работы с должниками. 19.3.14. Формирование необходимых печатных форм (в том числе справки о наличии/отсутствии задолженности, формирование претензий, исковых требований, детализации всех видов начислений для суда, формирование актов сверки) - Соответствие - - Значение характеристики не может изменяться участником закупки

20. Требования к подсистеме «Автоматизация претензионной и исковой деятельности»: 20.1. Подсистема должна автоматизировать выполнение следующих основных задач: 20.1.1. Ведение полной информации по претензиям и исковым процессам, по требованиям, предъявленным к пользователям Системы и по имуществу пользователям Системы: 20.1.1.1. Договор или иной документ, на основании которого ведется претензионно-исковая деятельность. 20.1.1.2. Претензия, иск стороны для требований, предъявленных к пользователям Системы по имуществу. 20.1.1.3. Субъект (заявитель) претензии. 20.1.1.4. Объект. 20.1.1.5. Предмет претензионно-исковых требований: 20.1.1.5.1. требования имущественного характера (сумма к взысканию по различным видам начислений); 20.1.1.5.2. требований имущественного характера, не подлежащего оценке; 20.1.1.5.3. требования неимущественного характера. 20.1.2. Возможность формировать печатные формы претензий и исковых заявлений автоматически на основе данных из учетной системы. 20.1.3. Стороны (участники) иска, категория (вид) иска, признак особой важности. 20.1.4. Состояние иска (подготовка, в процессе, завершен). 20.1.5. Учет судебных дел и претензионно-исковых этапов: претензия, подготовка иска, подача иска, наименование суда, номер судебного дела, судья, инстанция (апелляция, кассация, в порядке надзора), дата и время судебного заседания, сотрудник правового отдела – исполнитель, судебные акты по делу (решения, определения о приостановлении производства по делу, об оставлении иска без рассмотрения, об оставлении иска без движения, о возвращении искового заявления, о прекращении производства по делу, о принятии к производству встречного иска, о принятии (отмене) мер по обеспечению иска). 20.1.6. Учет исполнительного производства: дата вступления судебного акта в законную силу, дата получения исполнительного листа, дата направления исполнительного листа в отдел судебных приставов, отдел судебных приставов, судебный пристав исполнитель, постановления пристава исполнителя. - Соответствие - - Значение характеристики не может изменяться участником закупки

20.1.7. Учет конкурсного производства: суд, номер дела, дата введения процедур в отношении предприятия банкрота (определения суда), сведения о ходе процедур банкротства. 20.1.8. Возможность формирования отчета о сроках (длительности) претензионной работы, подготовки и подачи иска, рассмотрения дела в суде, исполнительного производства, конкурсного производства. 20.1.9. Возможность поиска судебных дел по различным критериям. 20.1.10. Наличие ссылки на страницу дела на сайте kad.arbitr.ru. 20.1.11. Возможность прикрепления файлов материалов к судебному делу (претензий, исков, судебных актов), к исполнительному производству (исполнительный лист, заявление о направлении исполнительного листа, постановления приставов-исполнителей), к конкурсному производству (судебные акты дела о банкротстве, извещения о проведении собраний кредиторов). 20.1.12. Контроль за ходом иска в разрезе исполнителя, уведомление исполнителя о необходимости завершения текущего искового этапа и перехода к следующему. 20.1.13. Предусмотреть экспорт данных в табличный формат (xlsx, csv). Возможность формирования необходимых печатных форм (с использованием встроенных генераторов отчетов). 20.1.14. Предусмотреть разграничение прав доступа. 20.1.15. Постановка и контроль исполнения задач/поручений сотрудниками правового отдела. 20.1.16. Протоколирование результатов расчета пени на расчетную дату. 20.1.17. Протоколирование результатов расчета задолженности по всем видам операций на расчетную дату, для возможности отслеживания изменений и анализа их причин - Соответствие - - Значение характеристики не может изменяться участником закупки

32. Режим добавления объекта по шаблону: 32.1. В Системе должна быть предусмотрена возможность добавления объекта по шаблону на основе любого выбранного пользователем объекта, информация о котором уже содержится в единой базе данных Системы. 32.2. В режиме добавления объекта по шаблону должна создаваться карточка нового объекта соответствующего типа (как у объекта, на основе которого производится добавление) с полным копированием информации из исходного объекта в карточку добавляемого объекта, за исключением информации, идентифицирующей объект (реестровый номер, инвентарный номер, паспортные данные, ПТС транспортного средства) - Соответствие - - Значение характеристики не может изменяться участником закупки

33. Требования к созданию нового типа (наименования списка, реестра) объекта учета 33.1. Средствами подсистемы должна быть обеспечена возможность создания реестров (списков) объектов двух основных видов: 33.1.1. Новый реестр/список объектов произвольной структуры, состава информации, атрибутов, характеристик. 33.1.2. Реестр/список объектов, являющихся частью одного или нескольких реестров объектов имущественно-земельного комплекса. Для объектов данного типа должна быть обеспечена возможность выбора одного или нескольких типов объектов (схожих по структуре данных), на основе которых формируется данный список объектов учета, а также возможность задания произвольного условия (без каких-либо ограничений по сложности условия), по которому осуществляется фильтрация объектов учета. 33.2. Должна быть предусмотрена возможность создания собственной электронной карточки объекта учета данного реестра, отличной от электронной карточки этого же объекта учета основного реестра. Однако, если в электронной карточке объекта в создаваемом реестре объектов учета присутствуют реквизиты, заполненные в карточке этого же объекта в основном реестре (реестре имущественно-земельного комплекса), то они должны отображаться в электронной карточке объекта учета данного реестра. Иными словами, должна быть обеспечена возможность собственного дизайна электронных карточек объектов учета отдельно для каждого создаваемого пункта меню (пункта меню доступа к создаваемому списку, реестру объектов учета). Электронная карточка должна создаваться адаптированной к эффективному решению именно той задачи, для которой создавался список соответствующих объектов - Соответствие - - Значение характеристики не может изменяться участником закупки

19.3.15. Формирование необходимой аналитической отчетности. 19.3.16. Организация массовой рассылки уведомлений о необходимости погашения задолженности, об изменении условий договора, величины планируемой платы по договору. 19.3.17. Проведение экспресс-аналитики. 19.4. Помимо стандартных функций по управлению финансово-аналитической информацией, в подсистему должен быть включен ряд функций и возможностей, направленных на дополнительное расширение возможностей подсистемы как в части расширения функционала, так и в части настройки технологии учета под особенности внутреннего регламента по управлению финансово-аналитической информацией, технологии учета, особенности местного и регионального законодательства. 19.5. Настройка уровня аналитического учета: 19.5.1. В Системе должна быть предусмотрена возможность индивидуальной настройки уровня аналитического учета платежей и начислений за аренду этих объектов. 19.5.1.1. Учет платежей и начислений должен вестись как в разрезе субъектов договоров (арендаторы), плательщиков (оплата 3-ми лицами), так и по договорам (аренда, выкуп, неосновательное обогащение, учет и т.д.). Платежи распределяются как по субъектам договоров (арендаторы), так и по договорам (аренда, выкуп, неосновательное обогащение, учет и т.д.). Пени и другие штрафные санкции и сальдо рассчитываются также в разрезе субъектов и по договорам аренды. Возможно применение смешанной технологии учета, в которой основная технология выбрана в разрезе субъектов договоров (арендаторы), но для части договоров учет ведется в разрезе договоров. 19.5.1.2. Возможно ведение технологии учета в разрезе КБК (кодов бюджетной классификации). При таком ведении учета пени и сальдо рассчитываются индивидуально для каждого кода бюджетной классификации. Данный аналитический уровень может быть применен как при ведении учета в разрезе арендаторов, так и при ведении учета в разрезе договоров. 19.5.1.3. Ведение библиотеки алгоритмов выполнения автоматических операций - Соответствие - - Значение характеристики не может изменяться участником закупки

19.5.1.4. Ведение библиотеки схем начисления арендной платы и сроков оплаты. 19.5.1.5. Библиотека схем начисления должна предоставлять следующие возможности: 19.5.1.6. Создание произвольного количества схем начисления. Под схемой начисления подразумевается алгоритм выполнения начисления, периодичностью (квартал, месяц, полугодие, набор месяцев) и сроки начисления. 19.5.1.7. Возможность создания и настройки произвольного количества периодичностей начисления (например, помесячное начисление, поквартальное, 2 раза в год для сельхоз. земель, 2 раза в год для других земель). При этом для каждой периодичности может быть указано произвольное количество периодов произвольной длительности. Для каждого периода индивидуальное указание произвольного срока оплаты. 19.5.1.8. Для каждого договора аренды указание индивидуальной схемы начисления из библиотеки (схема по умолчанию также должна настраиваться). 19.6. Расширение функциональных и аналитических возможностей блока: 19.6.1. В Системе должна быть реализована функция определения задолженности в любом разрезе. При этом функция должна рассчитать задолженность по состоянию на любую заданную дату как по базе целиком, так и по любому из перечисленных аналитических уровней (или их произвольному сочетанию): - Соответствие - - Значение характеристики не может изменяться участником закупки

21. Требования к аналитической и сервисной подсистеме «Библиотека запросов»: 21.1. Средства подсистемы должны предоставлять возможность для проведения оперативных выборок и для выполнения запросов по индивидуальному или массовому изменению, добавлению, удалению информации в банке данных Системы, например, в ходе обслуживания информационного фонда. 21.2.Подсистема должна предоставлять средства оперативного построения, накопления и выполнения запросов произвольной сложности и произвольного содержания к единому информационному фонду Системы. Средства подсистемы должны быть максимально интуитивны и просты в использовании, выполнение запросов не требует каких-либо специальных знаний и навыков от пользователей. 21.3. Количество запросов, которые могут быть добавлены в подсистему, должно быть не ограничено. Добавление запросов в подсистему должно выполняться средствами подсистемы, не требовать обновления Системы или ее компонентов, привлечения разработчиков Системы. 21.4. Запросы могут содержать произвольное количество параметров любых типов (даты, числа, строки, данные из любых справочников и классификаторов Системы), фактические значения которых указываются пользователем в момент выполнения выбранного запроса, что в значительной степени повышает оперативность и точность получения данных в результате выполнения запроса. 21.5. Должна быть предусмотрена возможность непосредственно из результатов выполнения запроса открыть электронную карточку объекта, по которому содержится информация в соответствующей строчке результатов выполнения запроса. 21.6. Подсистема должна предоставлять возможность дополнительного постанализа данных (анализ после получения результата выполнения запроса в табличном виде), полученных в результате выполнения запроса: - Соответствие - - Значение характеристики не может изменяться участником закупки

21.6.1. Группировка данных по одному или нескольким полям, что в значительной степени может повысить информативность полученных данных. Например, данные по должникам можно сгруппировать по району плательщика, кодам бюджетной классификации и видам начислений. 21.6.2. Вычисление общих итогов, в том числе для каждой из групп (в случае применения группировки). Например, для приведенного примера возможна автоматическая калькуляция общей задолженности арендаторов, а также задолженности по каждому из районов, коду бюджетной классификации и виду начисления. 21.6.3. Дополнительная оперативная фильтрация данных по значениям любого поля\совокупности полей. 21.6.4. Сортировка данных по произвольному полю\совокупности полей. Должна быть предусмотрена возможность экспорта сформированных данных в табличные форматы (xlsx, csv), текстового файла, xml или внутренние форматы генератора отчетов. При этом должна быть обеспечена возможность экспорта данных, в том чисел в формат xml сложной структуры с учетом всех сортировок, группировок, итогов и прочего форматирования, которые были наложены на результат запроса в окне результата запроса. 21.7. В случае содержания в результатах запроса сведений об объектах учета единого банка данных Системы должен быть реализован быстрый доступ (двойной «щелчок мыши») к карточкам соответствующих объектов учета. 21.8. Средства подсистемы должны предоставлять возможность администратору Системы мониторинга состояния информационного фонда Системы, анализа целостности, непротиворечивости данных, регулярного обслуживания банка данных. - Соответствие - - Значение характеристики не может изменяться участником закупки

34. Требования к созданию формы работы со списком объектов учета соответствующего типа: 34.1. Для списков работы с объектами учета новых типов (не объектов имущественно-земельного комплекса, описанных выше) должна быть предусмотрена возможность создания формы работы со списком (реестром) объектов, содержащих произвольное количество полей (колонок, столбцов) произвольной структуры без ограничений на сложность формирования данных, размещаемых в соответствующих полях (колонках, столбцах) списка объектов учета. В том числе, в полях списка могут размещаться произвольные данные из единой базы данных Системы, выведенные по любому заданному алгоритму произвольной сложности. 34.2. Форма работы со списком должна обладать всеми возможностями по дальнейшему анализу данных: 34.2.1. Группировка данных по одному или нескольким столбцам. Например, реестр может быть сгруппирован по состоянию объектов учета, району города, разрешенному использованию. 34.2.2. Вычисление общих итогов, в том числе для каждой из групп (в случае применения группировки). Например, для приведенного примера возможна автоматическая калькуляция общей планируемой платы, площади объектов, величины задолженности в разрезе состояний договоров аренды, района расположения объекта договора, целевого использования. 34.2.3. Дополнительная оперативная фильтрация данных по значениям любого столбца\совокупности столбцов. 34.2.4. Сортировка данных по произвольному столбцу\совокупности столбцов. 34.2.5. Возможность выбора отображаемых столбцов. 34.2.6. Автоматическое сохранение настроек табличного представления для каждого типа объектов учета. 34.3. Должна быть предусмотрена возможность экспорта сформированных данных в форматы xlsx, xml, текстового файла или внутренние форматы генератора отчетов - Соответствие - - Значение характеристики не может изменяться участником закупки

35. Требования к созданию формы поиска/фильтрации 35.1. Подсистема должна обладать инструментами создания формы поиска/фильтрации объекта по любому количеству критериев следующих типов: 35.1.1. Целочисленный. 35.1.2. Число с плавающей точкой. 35.1.3. Строковый. 35.1.4. Дата. 35.1.5. Значение из справочника или списка допустимых вариантов выбора. В качестве справочника может быть использован частично (по произвольному заданному условию фильтрации) или полностью любой из классификаторов Системы, а также любой перечень допустимых элементов выбора, сформированный как вручную, так и путем выборки по задаваемому алгоритму из произвольной информации, размещенной в единой базе данных Системы. 35.2. Форма поиска должна содержать произвольное количество параметров фильтрации в заданном порядке. 35.3. Для каждого критерия поиска в форме поиска/фильтрации должны создаваться элементы управления, содержащие следующую информацию: 35.3.1. Наименование критерия поиска на русском языке. 35.3.2. Перечень допустимых логических условий поиска (равно, не равно, больше, меньше, больше или равно, меньше или равно, содержит, начинается с, не содержит, не начинается, заполнено, не заполнено и т.п.). Перечень зависим от используемого типа данных реквизита (критерия) поиска. 35.3.3. Вводимое значение для поиска. 35.4. Должна быть предусмотрена возможность формирования критериев поиска как по любому атрибуту или характеристике объекта учета, так и по любым заданным условиям произвольной сложности и алгоритмизации - Соответствие - - Значение характеристики не может изменяться участником закупки

36.5.16. Коэффициенты. 36.5.17. Примечание. 36.5.17. Связанные объекты имущества. 36.5.19. Связанные земельные участки - Соответствие - - Значение характеристики не может изменяться участником закупки

19.6.1.1. Вычисление задолженности по договорам определенного типа (аренда, купля/продажа земельных участков, недвижимого, движимого имущества, объектов наружной рекламы, имущественных комплексов) или по всем типам. 19.6.1.2. Вычисление общей задолженности по субъекту договора или по всем субъектам. 19.6.1.3. Вычисление задолженности по договору или всем договорам. 19.6.1.4. Вычисление общей задолженности по определенному виду начисления или по всем видам. 19.6.1.5. Вычисление общей задолженности по определенному КБК или по всем КБК 19.6.1.6. В Системе должны быть предусмотрены следующие возможности: 19.6.1.7. Возможность запуска операции автоматического начисления арендной платы по диапазону периодов, годов. 19.6.1.8. Протоколирование выполнения всех автоматических операций и эвристический анализ состояния информационного фонда на поиск ошибок и потенциальных ошибок. 19.6.1.9. Выполнение любой автоматической операции должно сопровождаться формированием подробного протокола выполнения операции, в который в текстовом, понятном пользователю виде заносятся все операции, которые были произведены системой со всеми объектами учета. Одновременно, система должна выполнять комплекс эвристических проверок состояния информационного фонда системы на поиск ошибок или потенциальных ошибок, которые потенциально могут повлиять на корректность полученного результата. 19.6.1.10. Протоколы выполнения всех автоматических операций должны хранится в базе на постоянной основе и быть доступны для анализа в любой момент времени (возможность постанализа результатов выполнения операции). 19.6.1.11. Автоматический расчет и отображение «горячих итогов» (автовычисляемая и отображаемая на экране задолженность по заданным видам начисления (настраивается) по состоянию на текущую дату) по каждому субъекту (всем договорам субъекта общей суммой) и/или договору - Соответствие - - Значение характеристики не может изменяться участником закупки

19.6.2. В автоматическом режиме Система должна рассчитывать и отображать следующие данные: 19.6.2.1. Задолженность по арендной плате/плате за выкуп по состоянию на текущее число. 19.6.2.2. Задолженность по пене по состоянию на текущее число. 19.6.2.3. Общая задолженность (по всем видам начисления) по состоянию на текущее число. 19.6.2.4. Текущая пеня (сумма пени, рассчитанная на текущий момент). 19.6.2.5. Всего начислено с начала года. 19.6.2.6. Текущая сумма планируемой арендной платы/платы за выкуп. 19.6.3. Поля «горячих» итогов должны поддерживать настройку на отображение итогов по любому виду начисления (глобальная настройка по Системе целиком). Должна быть предусмотрена возможность настройки не менее 10 показателей «горячих итогов» - Соответствие - - Значение характеристики не может изменяться участником закупки

12.5.1.13. Принадлежность к земельному участку (множественная связь – один объект может быть размещен на нескольких земельных участках, на одном земельном участке может быть размещено несколько объектов). 12.5.1.14. Принадлежность к другим объектам (список объектов имущества, включенных в заданный объект (размещенных в пределах заданного объекта), например, перечень объектов, составляющих объект имущественного комплекса, перечень квартир в жилом здании, перечень комнат в квартире). Должна быть предусмотрена возможность связывать объект с ранее учетными в единой базе данных Системы объектами, включенными в данных объект (размещенными в пределах данного объекта). Должна быть предусмотрена возможность указания обратной связи – для ранее учтенного в единой базе Системы объекта указать объект, в который включен (в пределах которого размещен) заданный объект. 12.5.1.15. Признак принадлежности к объектам культурного наследия, а также информация о включении объекта в реестр объектов культурного наследия (Номер в реестре, категория историко-культурного наследия – справочник, Признак принадлежности объекта к объектам религиозного значения, признак принадлежности объекта к ансамблям, ссылка на документ-основание с возможностью указания нескольких документов оснований и период нахождения объекта в реестре с возможностью учета разных периодов включения объектов и соответственно разных данных по нахождению объекта в реестре). 12.5.1.16. Информация по проводимым аукционам, торгам, конкурсам - Соответствие - - Значение характеристики не может изменяться участником закупки

12.5.1.17. Классификация объектов учета – предусмотрена возможность учета произвольного количества категорий классификации с произвольным количеством элементов классификации в каждой из категорий, а также текстовым описанием каждого элемента – с историей изменений и ссылками на документы-основания присвоения элемента классификации и исключения объекта из классификации (множественность документов-ссылок). 12.5.1.18. События (даты) – с историей изменений и ссылкой на документ-основание. 12.5.1.19. Признаки («галочки») - принадлежность к чему-либо с текстовым описанием признака. 12.5.1.20. Договоры использования и обременения (аренды, купли-продажи, безвозмездного пользования, согласования, разрешения, размещения, сервитуты). 12.5.1.21. Информация по претензионной и исковой деятельности (детальная информация по поданным претензиям и искам, включая необходимую классификационную и описательную части, предметы исков, в том числе суммы с делением по видам начислений, перечень этапов претензионной и исковой деятельности с указанием ссылок на документы этапа, уточнение требований) – см. пункт «Подсистема автоматизации претензионной и исковой деятельности». 12.5.2. Автоматическое присвоение реестрового номера с возможностью настройки методики и структуры формирования номера, а также возможностью организации сквозной нумерации по нескольким видам объектов учета (настройка категорий нумерации, для каждой категории можно указать перечень видов объектов учета, входящих в категорию). 12.5.3. Ведение информации по подобъектам, составным частям объектов. 12.5.4. Управление историей изменения основных характеристик объектов и документами-основаниями на проведение изменений - Соответствие - - Значение характеристики не может изменяться участником закупки

3. Требования к серверу приложений: 3.1. Сервер приложений для Системы должен обеспечивать предоставление доступа клиентских мест к данным Системы, а также содержать средства обеспечения корректности исполнения технологических процессов (бизнес-логики) функционирования Системы. 3.2. Сервер приложений не должен требовать ручного запуска перед началом работы пользователей Системы. 3.3. Сервер приложений должен обеспечивать передачу клиентским местам информацию порциями по настраиваемому количеству записей (количество записей, которое помещается на экран без прокрутки при любом из используемых разрешений экрана) по мере обращения. 3.4. Передача информации на клиентское место из используемых справочников и классификаторов должна производиться при первом обращении к справочникам и классификаторам (за исключением системных справочников и классификаторов, необходимых для функционирования Системы в целом). 3.5. Передача информации на клиентское место по открытым электронным карточкам объектов учета должна производиться только в том объеме, в котором информация отображается в соответствующий момент в карточке объекта учета - Соответствие - - Значение характеристики не может изменяться участником закупки

12.5.5. Управление движением объектов в реестре (включение, исключение, перемещение между реестрами, ведение истории реорганизации объектов (слияния, разделения)). 12.5.6. Управление движением объектов на балансе и в казне, договорами оперативного управления и хозяйственного ведения. 12.5.7. Обеспечение информационного взаимодействия/обмена информацией по объектам муниципальной собственности с субъектами права (балансодержателями и др.) – массовое обновление стоимостных показателей (балансовая, остаточная стоимость, износ), характеристик объектов. 12.5.8. Управление движением объектов в казне (с возможностью ведения балансового и забалансового бюджетного учета движения объектов в казне). 12.5.9. Ведение документального обеспечения (документов-оснований) движения объектов, изменения характеристик объектов в реестре. 12.5.10. Ведение аукционов и торгов на право аренды или купли-продажи объектов. 12.5.11. Формирование реестров объектов муниципальной собственности. 12.5.12. Формирование выписок из реестров, справок о движении объектов, проектов приказов, постановлений, распоряжений, других необходимых печатных форм. 12.5.13. Формирование аналитической отчетности. 12.5.14. Проведение экспресс-аналитики. 12.5.15. Корректное проставление даты выбытия объекта в зависимости от выбранного документа основания (например, выбытие по исключению из реестра или из-за регистрации права собственности за иным лицом). 12.5.16. Возможность указания шаблона для вывода адреса в нужном формате - Соответствие - - Значение характеристики не может изменяться участником закупки

12.5.17. Возможность работы со справочниками ФИАС при формировании адреса. 12.5.18. Управление историей объектов для отслеживания хронологии реорганизации, разделения, объединения объекта. 12.5.19. Протоколирование действий пользователей. 12.5.20. Возможность прикрепления к карточке объекта учета произвольного количества файлов произвольного типа. 12.5.21. Возможность ведения информации о внереестровых объектах. 12.6. Должна быть предусмотрена возможность смены типа объектов, включенных по ошибке в другие подразделы имущества (в том числе объектов прошлых периодов), например, изменить тип «нежилое здание» на «нежилое помещение» или на «сооружение» и наоборот - Соответствие - - Значение характеристики не может изменяться участником закупки

13. Требования к подсистеме «Земля»: 13.1. Подсистема «Земля» должна автоматизировать ведение реестров земельных участков, собственность на которую разграничена, а также ведение земельных участков, собственность на которые не разграничена или с другими видами собственности, находящихся в сфере компетенции органов управления земельными ресурсами. 13.2. Подсистема должна автоматизировать выполнение следующих основных задач: 13.2.1. Пообъектный учет земельных участков (ЗУ). Для каждого из ЗУ ведется следующая основная информация: 13.2.1.1. Наименование ЗУ. 13.2.1.2. Принадлежность к реестру, подреестру (с историей изменения). 13.2.1.3. Кадастровый номер (кадастровый квартал выбирается из классификатора, не обязательный для заполнения). 13.2.1.4. Категория земель (с историей изменения и ссылками на документы-основания). 13.2.1.5. Разрешенное использование (с историей изменения и ссылками на документы-основания). 13.2.1.6. Уровень собственности (состояние) - Соответствие - - Значение характеристики не может изменяться участником закупки

4. Требования к размещению средств обеспечения корректности исполнения технологических процессов (бизнес-логики) Системы: 4.1. Средства обеспечения корректности исполнения технологических процессов (бизнес-логики) в максимально возможном объеме должны быть реализованы на уровне базы данных (выполняться в автоматическом режиме на уровне СУБД). 4.2. На уровне СУБД должны быть реализованы следующие процессы (технологические процессы или их части): 4.2.1. Ведение аудита действий пользователей на уровне полей таблиц (конкретных атомарных атрибутов объектов учета, в том числе в составе составных характеристик). 4.2.2. Проверка прав пользователей (хранимые функции или процедуры проверки прав пользователей). 4.2.3. Поддержка функционирования средств «быстрого поиска» (по необходимости). 4.2.4. Формирование проводок бюджетного учета по администрируемым кодам бюджетной классификации при внесении изменений в данные финансово-аналитической подсистемы в соответствии с требованиями Министерства финансов РФ. 4.2.5. Расчет суммы планируемой платы по договорам. 4.2.6. Начисление арендной платы, платы за выкуп, платы за фактическое использование объектов, всех видов штрафных санкций, включая начисление пени, процентов за пользование чужими денежными средствами. 4.2.7. Расчет сальдо. 4.2.8. Расчет задолженности на произвольную дату в произвольном разрезе. 4.2.9. Пересчет задолженности на текущее число по всем видам договорных отношений. 4.2.10. Алгоритмы парсинга (разбора) сведений, получаемых по протоколам СМЭВ в машиночитаемом виде (xml). 4.2.11. Алгоритмы автоматического и полуавтоматического внесения информации в информационный фонд Системы на основе полученных сведений по протоколам СМЭВ. 4.3. Средства обеспечения технологических процессов, которые не могут быть реализованы на стороне СУБД, должны быть реализованы средствами сервера приложения. 4.4. На клиентском месте должны быть продублированы те элементы технологических процессов, которые могут определить некорректные действия - Соответствие - - Значение характеристики не может изменяться участником закупки

5. Требования к способам и средствам связи для информационного обмена между компонентами Системы: 5.1. Система должна обеспечивать коллективную работу пользователей объекта автоматизации с использованием единого интегрированного хранилища данных по технологии «клиент-сервер» с использованием трехзвенной архитектуры. 5.2 Количество клиентских подключений к серверу не менее 30 (тридцать). - Соответствие - - Значение характеристики не может изменяться участником закупки

6. Требования к приспособляемости Системы: 6.1. Функциональность Системы должна допускать наращивание функциональных возможностей на основе подключения дополнительных (или изменения существующих) подсистем в связи с изменением существующих и возникновением новых автоматизируемых процессов, обусловленных изменениями в нормативно-законодательной базе. 6.2. Подсистемы должны иметь программные интерфейсы, обеспечивающие возможность расширения функциональности Системы путём добавления компетентными, обученными пользователями Системы дополнительных программных модулей. 6.3. Система должна быть легко настраивающейся на изменения условий функционирования и организационной структуры объектов автоматизации Системы. 6.4. Система должна сохранять работоспособность при увеличении количества пользователей в пределах, поддерживаемых аппаратно-программной средой серверов технологического узла. 6.5. Должна быть обеспечена возможность увеличения числа пользователей Системы - Соответствие - - Значение характеристики не может изменяться участником закупки

13.2.1.7. Реестровый номер (с историей изменения и ссылками на документы-основания). 13.2.1.8. Адрес, адресный ориентир (с возможностью ввода множественного адреса). Должна быть предусмотрена возможность указания государственного образования для обеспечения возможности дальнейшего отбора земельных участков по соответствующему показателю. 13.2.1.9. Субъекты права (землепользователи, другие субъекты права) – с историей изменения, множественностью документов-оснований возникновения и прекращения права (ссылки на документы), в том числе и права постоянного (бессрочного) пользования. 13.2.1.10. Экономические показатели (Кадастровые стоимости и др.) – с историей изменения и ссылками на документы-основания. 13.2.1.11. Технические показатели (с историей изменения и ссылками на документы-основания). 13.2.1.12. Документы (все документы, имеющие отношение к данному объекту с делением по направлениям воздействия документов (включение/исключение, внесение изменений, правоустанавливающие, регистрирующие документа)). 13.2.1.13. Комиссии. 13.2.1.14. Коэффициенты-характеристики, площадь (с историей изменения и ссылками на документы-основания). 13.2.1.15. Информация по использованию ЗУ (классификация для аналитики, ставки арендной платы, типы использования для кадастровой оценки, налоговые ставки по типам использования) с возможностью указания различных типов использования долей земельного участка (с историей изменения и ссылками на документы-основания). 13.2.1.16. Перечень объектов недвижимого имущества, размещенных на данном участке. (кадастровый номер, наименование, права) 13.2.1.17. Информация по проводимым аукционам, торгам, конкурсам - Соответствие - - Значение характеристики не может изменяться участником закупки

13.2.1.18. Классификация объектов учета – предусмотрена возможность учета произвольного количества категорий классификации с произвольным количеством элементов классификации в каждой из категорий, а также текстовым описанием каждого элемента – с историей изменений и ссылками на документы-основания присвоения элемента классификации и исключения объекта из классификации (множественность документов-ссылок). 13.2.1.19. Информация по претензионной и исковой деятельности (детальная информация по поданным претензиям и искам, включая необходимую классификационную и описательную части, предметы исков, в том числе суммы с делением по видам начислений, перечень этапов претензионной и исковой деятельности с указанием ссылок на документы этапа, уточнение требований) – см. Пункт «Подсистема автоматизации претензионной и исковой деятельности». 13.2.1.20. События (даты) – с историей изменений и ссылкой на документ-основание. 13.2.1.21. Признаки («галочки») - принадлежность к чему-либо с текстовым описанием признака. 13.2.1.22. Договоры использования и обременения (аренды, купли-продажи, безвозмездного пользования, согласования, разрешения, размещения, сервитуты). 13.2.2. Автоматическое присвоение реестрового номера с возможностью настройки методики и структуры формирования номера, а также возможностью организации сквозной нумерации по нескольким видам объектов учета (настройка категорий нумерации, для каждой категории можно указать перечень видов объектов учета, входящих в категорию). 13.2.3. Управление историей изменения основных характеристик ЗУ, документами-основаниями на проведение изменений. 13.2.4. Управление движением ЗУ в реестре (включение, исключение, перемещение между реестрами, ведение истории реорганизации объектов (слияния, разделения)). 13.2.5. Управление движением ЗУ по субъектам права. 13.2.6. Управление движением ЗУ в казне (с возможностью ведения балансового и забалансового бюджетного учета движения объектов в казне) - Соответствие - - Значение характеристики не может изменяться участником закупки

7. Требования к защите информации от несанкционированного доступа: 7.1. Система должна обеспечивать идентификацию и аутентификацию пользователя, обратившегося для получения доступа к функциям Системы. В Системе должны быть обеспечены разграничение и администрирование доступа к компонентам Системы. 7.2. Механизмы безопасности Системы должны позволять ограничивать круг лиц, принимающих участие в работе с данными, и позволять контролировать процесс работы с защищенными документами и знать, откуда возможна утечка информации. 7.3. Защита информации от несанкционированного доступа в Системе должна обеспечиваться реализацией следующих функций Системы: 7.3.1. Предоставление доступа к Системе должно предоставляться только предварительно зарегистрированным пользователям. 7.3.2. Возможность разграничения доступа к подсистемам для каждого пользователя. 7.3.3. Возможность для каждого пользователя установить уровень доступа, обеспечивающий только просмотр или редактирование информации. 7.3.4. Управление разграничением и/или уровнями доступа пользователей должно осуществляться через группы доступа. 7.3.5. Разграничение по доступу к данным Системы должно быть согласно утвержденным полномочиям пользователей Системы. 7.3.6. Регистрация входа (выхода) пользователей в Систему (из Системы) должна фиксироваться в журнале действий пользователей. 7.3.7. Должна быть возможность функционального разграничения действий пользователей при обработке информации. 7.3.8. Ведение справочника пользователей Системы. 7.3.9. Журналирование действий пользователей, которое должно обеспечиваться путем ведения в Системе «журнала событий», доступного только с автоматизированного рабочего места администратора и включающего в себя следующие данные: 7.3.9.1. Системные действия: дата, событие, пользователь. 7.3.9.2. Действия над пользователями Системы: дата, событие, администратор. 7.3.9.3. Действия пользователей. 7.4. «Журнал событий» должен быть недоступен к внесению изменений - Соответствие - - Значение характеристики не может изменяться участником закупки

7.5. Система должна обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях Система должна выдавать пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных. 7.6. Должна быть предусмотрена возможность резервного копирования и ручного восстановления стандартными средствами системы управления базой данных (далее – СУБД) администраторами Системы обрабатываемой информации из резервной копии в следующих аварийных ситуациях: 7.6.1. Ошибочные действия пользователей (администраторов), приведшие к утрате или искажению данных Системы. 7.6.2. Отказ Системы, связанный с фатальным нарушением целостности файловой системы или структуры баз данных. 7.7. Для резервного копирования должны использоваться штатные средства системной программной платформы, причем организация баз данных Системы должна обеспечивать сохранение: 7.7.1. Всех параметров настройки Системы, включая учетные записи и персональные настройки пользователей. 7.7.2. Всей информации Системы - Соответствие - - Значение характеристики не может изменяться участником закупки

8. Требования к патентной чистоте: 8.1. По результату исполнения контракта Система должна отвечать требованиям по патентной чистоте согласно действующему законодательству Российской Федерации, в Системе не должны использоваться решения, приводящие к нарушению смежных прав и прав третьих лиц, защищенные патентами или иными действующими на территории Российской Федерации документами, удостоверяющими авторские права на них, без соответствующего лицензионного соглашения с авторами данных решений. Выполнение требований по обеспечению лицензионной чистоты Системы возлагается на Исполнителя - Соответствие - - Значение характеристики не может изменяться участником закупки

13.2.7. Ведение документального обеспечения (документов-оснований) движения ЗУ, изменения характеристик объектов в реестре. 13.2.8. Ведение аукционов и торгов на право аренды или купли-продажи ЗУ. 13.2.9. Формирование реестров земельных участков. 13.2.10. Формирование выписок из реестра, справок о движении ЗУ, проектов приказов, постановлений, распоряжений, других необходимых печатных форм. 13.2.11. Формирование аналитической отчетности в соответствующей сфере. 13.2.12. Проведение экспресс-аналитики. 13.2.13. Корректное проставление даты выбытия объекта в зависимости от выбранного документа основания (например, выбытие по исключению из реестра или из-за регистрации права собственности за иным лицом). 13.2.14. Возможность указания шаблона для вывода адреса в нужном формате. 13.2.15. Возможность работы со справочниками ФИАС при формировании адреса. 13.2.16. Управление историей объектов для отслеживания хронологии реорганизации, разделения, объединения объекта. 13.2.17. Протоколирование действий пользователей. 13.2.18. Возможность прикрепления к карточке объекта учета произвольного количества файлов произвольного типа. 13.2.19. Возможность ведения информации о внереестровых объектах - Соответствие - - Значение характеристики не может изменяться участником закупки

9. Требования к контролю, хранению, обновлению и восстановлению данных: 9.1. Контроль корректности данных должен обеспечиваться реализацией функций форматного, логического контроля на уровне пользовательских форм. 9.2. Для хранения данных Системы должна использоваться СУБД, средствами которой выполняются действия записи, обновления, журналирования изменений, резервного копирования и восстановления данных - Соответствие - - Значение характеристики не может изменяться участником закупки

10. Требования к лингвистическому обеспечению 10.1. В системных диалогах с пользователями в текстах сообщений должен применяться русский язык, за исключением сообщений общесистемного ПО, не подлежащих переводу на русский язык. 10.2. Содержание используемых в Системе справочников должно быть реализовано на русском языке - Соответствие - - Значение характеристики не может изменяться участником закупки

11. Состав Системы: 11.1. Система состоит из следующих подсистем, средств и других элементов, выполняющих соответствующие функции: 11.1.1. Подсистемы и средства Системы, входящие в базовую конфигурацию: 11.1.2. Подсистема «Имущество» 11.1.2. Подсистема «Земля». 11.1.3. Подсистема «Ведение информации по субъектам права». 11.1.4. Подсистема «Ведение информации по акциям, долям». 11.1.5. «Адресная подсистема». 11.1.6. Подсистема «Ведение договоров и дополнительных соглашений» 11.1.7. Подсистема «Выкуп с рассрочкой». 11.1.8. «Финансово-аналитическая подсистема». 11.1.9. Подсистема «Автоматизация претензионной и исковой деятельности». 11.1.10. Аналитическая и сервисная подсистема «Библиотека запросов». 11.1.11. Подсистема «Формирование отчетов и печатных форм, генератор отчетов». 11.1.12. Подсистема «Обеспечение безопасности, администрирования и разграничения прав доступа». 11.1.13. Подсистема «Ведение нормативно-справочной информации». 11.1.14. Подсистема «Автоматическое обновление клиентских рабочих мест». 11.1.15. Подсистема «Оповещение пользователей». 11.1.16. Подсистема «Самодиагностика с оповещением о выявленных аномалиях по электронной почте». 11.1.17. Средства ведения электронных карточек объектов учета. 11.1.18. Средства поиска, отображения и анализа информации. 11.1.19. Средства предварительного просмотра. 11.1.20. Средства выполнения массовых операций. 11.2. Дополнительные подсистемы Системы: 11.2.1. Подсистема «Бюджетный учёт доходов». 11.2.2. Подсистема «Бюджетный учёт движения объектов в казне». 11.2.3. Подсистема «Управление объектами жилого фонда», включая подсистему «Аварийное жилье - учет и управление». 11.2.4. Подсистема «Управление взносами на капитальный ремонт». 11.2.5. Подсистема «Ведение проверок использования имущества и земельных участков». 11.2.6. Подсистема межведомственного электронного взаимодействия (платформа СМЭВ). 11.2.7. Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» - Соответствие - - Значение характеристики не может изменяться участником закупки

11.2.8. Подсистема «Межведомственное электронное взаимодействие с Росреестром». 11.2.9. Подсистема «Межведомственное электронное взаимодействие с ЗАГС» - Соответствие - - Значение характеристики не может изменяться участником закупки

12. Требования к подсистеме «Имущество»: 12.1. Подсистема «Имущество» должна автоматизировать ведение реестра объектов муниципальной собственности, а также внереестровых объектов всех учитываемых типов. 12.2. Доступ к объектам имущества должен осуществляться из основного окна Системы с использованием иерархического меню. 12.3. Перечень учитываемых типов и конкретная настройка иерархического меню доступа к объектам должны быть определены на этапе обследования организации. Например, иерархическое меню доступа и перечень учитываемых типов объектов могут быть настроены в ручном режиме, например, в соответствии со схемой: 12.3.1. Недвижимое имущество: 12.3.1.1. Жилой фонд: 12.3.1.1.1. Жилые здания. 12.3.1.1.2. Жилые квартиры, помещения. 12.3.1.1.3. Жилые комнаты. 12.3.1.2. Нежилые здания. 12.3.1.3. Нежилые помещения. 12.3.1.4. Объекты незавершенного строительства. 12.3.1.5. Объекты инженерной инфраструктуры, сооружения. 12.3.1.6. Объекты внешнего благоустройства. 12.3.1.7. Доли. 12.3.1.8. Нематериальные активы, объекты интеллектуальной собственности. 12.3.1.9. Воздушные и морские суда, суда внутреннего плавания. 12.3.1.10. Космические объекты. 12.3.1.11. Прочие объекты, не включенные в указанные группировки - Соответствие - - Значение характеристики не может изменяться участником закупки

12.3.2. Движимое имущество: 12.3.2.1. Особо ценное движимое имущество. 12.3.2.2. Малоценное (прочее) движимое имущество. 12.3.2.3. Транспортные средства. 12.3.2.4. Объекты инженерной инфраструктуры. 12.3.2.5. Прочее движимое имущество, не относящиеся к указанным выше. 12.3.3. Акции, паи, доли. 12.3.4. Имущественные комплексы. 12.3.5. Муниципальные предприятия и учреждения. 12.4. Должна быть предусмотрена возможность скрытия неиспользуемых на момент внедрения пунктов меню (видов объектов учета). 12.5. Подсистема должна автоматизировать выполнение следующих основных задач: 12.5.1. Учет объектов. Для каждого из объектов должна вестись следующая основная информация: 12.5.1.1. Наименование объекта. 12.5.1.2. Принадлежность к реестру, подреестру (с историей изменения и ссылками на документы-основания). 12.5.1.3. Реестровый номер (с историей изменения и ссылками на документы-основания). 12.5.1.4. Кадастровый номер (не обязательный для заполнения, при наличии – обязательный для заполнения), условный номер. 12.5.1.5. Адрес (с возможностью ввода множественного адреса). 12.5.1.6. Субъекты права (движение на балансе, другие субъекты права) – с историей изменения, множественностью документов-оснований возникновения и прекращения права (ссылки на документы) - Соответствие - - Значение характеристики не может изменяться участником закупки

12.5.1.7. Экономические показатели (балансовые, остаточные стоимости и др.) – с историей изменения и ссылками на документы-основания. 12.5.1.8. Технические показатели (с историей изменения и ссылками на документы-основания). 12.5.1.9. Документы (все документы, имеющие отношение к данному объекту с делением по направлениям воздействия документов (включение/исключение, внесение изменений, правоустанавливающие, регистрирующие документа) – без ограничения количества и типов регистрируемых документов). 12.5.1.10. Комиссии. 12.5.1.11. Коэффициенты-характеристики, площадь (с историей изменения и ссылками на документы-основания). 12.5.1.12. Части помещений (подвал, полуподвал, этажи): 12.5.1.12.1. Коэффициенты-характеристики частей помещений, площадь (с историей изменения и ссылками на документы-основания). 12.5.1.12.2. Типы использования частей помещений (с историей изменения и ссылками на документы-основания). 12.5.1.12.3. Материал стен, варианты входа, уровни благоустройства, высота потолков – произвольное количество категорий благоустройства с произвольным количеством выбираемых элементов благоустройства в каждой категории, предусмотрена возможность указания уровней благоустройства объекта целиком и каждой из частей помещения отдельно - Соответствие - - Значение характеристики не может изменяться участником закупки

Класс программ для электронных вычислительных машин и баз данных - (12.20) Информационные системы для решения специфических отраслевых задач - - Значение характеристики не может изменяться участником закупки

Способ предоставления - Экземпляр на материальном носителе - - Значение характеристики не может изменяться участником закупки

Вид лицензии - Простая (неисключительная) - - Значение характеристики не может изменяться участником закупки

- Обоснование включения дополнительной информации в сведения о товаре, работе, услуге Создание единой информационной системы, автоматизирующей функций Заказчика по учету и управлению муниципальной собственностью и земельными участками, в на базе современных программно-аппаратных средств в соответствии с приказом Министерства экономического развития Российской Федерации от 30 августа 2011 г. N 424 «Об утверждении Порядка ведения органами местного самоуправления реестров муниципального имущества», подзаконными нормативными и правовыми актами, связанными с ними, а также с учетом требований постановления Правительства Российской Федерации от 16 июля 2007 г. N 447 «О совершенствовании учета федерального имущества».

- 62.01.12.000 - Услуги по проектированию и разработке информационных технологий для сетей и систем 1.Установка сервера баз данных, сервера приложений, сервера обновлений Системы. 2. Сборка и предоставление Заказчику дистрибутива для самостоятельной установки клиентских рабочих мест Системы. 3. Настройка Системы на основе проведенного анализа рабочих процессов пользователей. 4. Настройка дополнительных подсистем Системы. 5. Конвертация данных из информационных регистров Заказчика. 6. Установка и настройка средств межведомственного электронного взаимодействия (платформы СМЭВ). 7. Инструктаж пользователей. 8. Инструктаж администраторов 9. Настройка шаблонов печатных форм, отчетов и запросов. 10. Опытная эксплуатация. 11. Запуск Системы в постоянную эксплуатацию Соответствие - - Условная единица - 1,00 - 4 251 650,00 - 4 251 650,00

КОМИТЕТ ПО УПРАВЛЕНИЮ ИМУЩЕСТВОМ Г. ТАГАНРОГА - 1 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке 1.Установка сервера баз данных, сервера приложений, сервера обновлений Системы. 2. Сборка и предоставление Заказчику дистрибутива для самостоятельной установки клиентских рабочих мест Системы. 3. Настройка Системы на основе проведенного анализа рабочих процессов пользователей. 4. Настройка дополнительных подсистем Системы. 5. Конвертация данных из информационных регистров Заказчика. 6. Установка и настройка средств межведомственного электронного взаимодействия (платформы СМЭВ). 7. Инструктаж пользователей. 8. Инструктаж администраторов 9. Настройка шаблонов печатных форм, отчетов и запросов. 10. Опытная эксплуатация. 11. Запуск Системы в постоянную эксплуатацию Соответствие Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - 1.Установка сервера баз данных, сервера приложений, сервера обновлений Системы. 2. Сборка и предоставление Заказчику дистрибутива для самостоятельной установки клиентских рабочих мест Системы. 3. Настройка Системы на основе проведенного анализа рабочих процессов пользователей. 4. Настройка дополнительных подсистем Системы. 5. Конвертация данных из информационных регистров Заказчика. 6. Установка и настройка средств межведомственного электронного взаимодействия (платформы СМЭВ). 7. Инструктаж пользователей. 8. Инструктаж администраторов 9. Настройка шаблонов печатных форм, отчетов и запросов. 10. Опытная эксплуатация. 11. Запуск Системы в постоянную эксплуатацию - Соответствие - - Значение характеристики не может изменяться участником закупки

Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке

1.Установка сервера баз данных, сервера приложений, сервера обновлений Системы. 2. Сборка и предоставление Заказчику дистрибутива для самостоятельной установки клиентских рабочих мест Системы. 3. Настройка Системы на основе проведенного анализа рабочих процессов пользователей. 4. Настройка дополнительных подсистем Системы. 5. Конвертация данных из информационных регистров Заказчика. 6. Установка и настройка средств межведомственного электронного взаимодействия (платформы СМЭВ). 7. Инструктаж пользователей. 8. Инструктаж администраторов 9. Настройка шаблонов печатных форм, отчетов и запросов. 10. Опытная эксплуатация. 11. Запуск Системы в постоянную эксплуатацию - Соответствие - - Значение характеристики не может изменяться участником закупки

Преимущества, требования к участникам

Преимущества: Преимущество в соответствии с ч. 3 ст. 30 Закона № 44-ФЗ - Размер преимущества не установлен

Требования к участникам: 1. Требования к участникам закупок в соответствии с ч. 1.1 ст. 31 Закона № 44-ФЗ 2. Единые требования к участникам закупок в соответствии с ч. 1 ст. 31 Закона № 44-ФЗ

Применение национального режима по ст. 14 Закона № 44-ФЗ

Применение национального режима по ст. 14 Закона № 44-ФЗ: Основанием для установки указания запретов, ограничений закупок товаров, происходящих из иностранных государств, выполняемых работ, оказываемых услуг иностранными лицами, а так же преимуществ в отношении товаров российского происхождения, а также товаров происходящих из стран ЕАЭС, выполняемых работ, оказываемых услуг российскими лицами, а также лицами, зарегистрированными в странах ЕАЭС, является Постановление Правительства Российской Федерации о мерах по предоставлению национального режима от 23.12.2024 № 1875.

Сведения о связи с позицией плана-графика

Сведения о связи с позицией плана-графика: 202601583000061001000112

Начальная (максимальная) цена контракта: 8 200 000,00

Валюта: РОССИЙСКИЙ РУБЛЬ

Идентификационный код закупки (ИКЗ): 263615400587461540100103490010000244

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

Дата начала исполнения контракта: с даты заключения контракта

Срок исполнения контракта: 30.12.2026

Количество этапов: 2

Закупка за счет бюджетных средств: Да

Наименование бюджета: Бюджет города Таганрога

Вид бюджета: местный бюджет

Код территории муниципального образования: 60737000: Муниципальные образования Ростовской области / Городские округа Ростовской области/ / город Таганрог

Требуется обеспечение заявки: Да

Размер обеспечения заявки: 41 000,00 РОССИЙСКИЙ РУБЛЬ

Порядок внесения денежных средств в качестве обеспечения заявки на участие в закупке, а также условия гарантии: Порядок предоставления обеспечения заявки устанавливается в соответствии со ст. 44 Федерального закона от 05.04.2013 №44-ФЗ (далее–Закон №44-ФЗ). Обеспечение заявки на участие в закупке может предоставляться путем блокирования денежных средств, внесенных участником закупки на банковский счет, открытый таким участником в банке, включенном в перечень, утвержденный распоряжением Правительства РФ от 13.07.2018 №1451-р (далее – спец.счет). В случае если обеспечение заявки на участие в закупке предоставляется в виде денежных средств, то участник закупки для подачи заявки на участие в закупке выбирает с использованием электронной площадки способ обеспечения такой заявки путем указания реквизитов спец.счета. Обеспечение заявки на участие в закупке может предоставляться путем предоставления независимой гарантии (далее - НГ), соответствующей требованиям ст. 45 Закона №44-ФЗ, а также дополнительным требованиям к НГ, утвержденным ПП РФ от 08.11.2013 №1005. Типовая форма НГ утверждена ПП РФ от 08.11.2013 №1005. Срок действия НГ должен составлять не менее месяца с даты окончания срока подачи заявок. Обязательное закрепление в НГ условия о рассмотрении споров, возникающих в связи с исполнением обязательств по НГ, в Арбитражном суде Ростовской области.

Реквизиты счета для учета операций со средствами, поступающими заказчику: p/c 03232643607370005800, л/c 05583102260, БИК 016015102, ОТДЕЛЕНИЕ РОСТОВ-НА-ДОНУ БАНКА РОССИИ// УФК по Ростовской области г. Ростов-на-Дону, к/c 40102810845370000050

Реквизиты счета для перечисления денежных средств в случае, предусмотренном ч.13 ст. 44 Закона № 44-ФЗ (в соответствующий бюджет бюджетной системы Российской Федерации): Получатель Номер единого казначейского счета Номер казначейского счета БИК ТОФК УПРАВЛЕНИЕ ФЕДЕРАЛЬНОГО КАЗНАЧЕЙСТВА ПО РОСТОВСКОЙ ОБЛАСТИ (КУИ) ИНН: 6154005874 КПП: 615401001 КБК: 91411610061040000140 ОКТМО: 60737000001 40102810845370000050 03100643000000015800 016015102

Место поставки товара, выполнения работы или оказания услуги: Российская Федерация, обл Ростовская, г.о. город Таганрог, г Таганрог, ул. Греческая, д. 58

Предусмотрена возможность одностороннего отказа от исполнения контракта в соответствии со ст. 95 Закона № 44-ФЗ: Да

Требуется обеспечение исполнения контракта: Да

Размер обеспечения исполнения контракта: 5 %

Порядок предоставления обеспечения исполнения контракта, требования к обеспечению: Порядок предоставления обеспечения исполнения контракта устанавливается в соответствии со ст. 96 Федерального закона от 05.04.2013 №44-ФЗ (далее–Закон №44-ФЗ). Контракт заключается после предоставления участником закупки, с которым заключается контракт, обеспечения исполнения контракта. Исполнение контракта может обеспечиваться предоставлением независимой гарантии (далее - НГ), соответствующей требованиям ст. 45 Закона №44-ФЗ, а также дополнительным требованиям к НГ, утвержденным ПП РФ от 08.11.2013 №1005, или внесением денежных средств на указанный заказчиком счет, на котором в соответствии с законодательством РФ учитываются операции со средствами, поступающими заказчику. Способ обеспечения исполнения контракта, срок действия НГ определяются в соответствии с требованиями Закона №44-ФЗ участником закупки, с которым заключается контракт, самостоятельно. При этом срок действия НГ должен превышать предусмотренный контрактом срок исполнения обязательств, которые должны быть обеспечены такой НГ, не менее чем на один месяц, в том числе в случае его изменения в соответствии со ст. 95 Закона №44-ФЗ. Типовая форма НГ утверждена ПП РФ от 08.11.2013 №1005.Обязательное закрепление в НГ условия о рассмотрении споров, возникающих в связи с исполнением обязательств по НГ, в Арбитражном суде Ростовской области. НГ, информация о ней и документы, предусмотренные ч. 9 ст. 45 Закона №44-ФЗ, должны быть включены в реестр НГ, размещенный в единой информационной системе (ЕИС). Положения Закона №44-ФЗ об обеспечении исполнения контракта, включая положения о предоставлении такого обеспечения с учетом положений ст. 37 Закона №44-ФЗ, не применяются в случае: 1) заключения контракта с участником закупки, который является казенным учреждением; 2) осуществления закупки услуги по предоставлению кредита; 3) заключения бюджетным учреждением, государственным, мун. унитарными предприятиями контракта, предметом которого является выдача НГ.

Платежные реквизиты для обеспечения исполнения контракта: p/c 03232643607370005800, л/c 05583102260, БИК 016015102, ОТДЕЛЕНИЕ РОСТОВ-НА-ДОНУ БАНКА РОССИИ// УФК по Ростовской области г. Ростов-на-Дону, к/c 40102810845370000050

Требуется гарантия качества товара, работы, услуги: Да

Срок, на который предоставляется гарантия и (или) требования к объему предоставления гарантий качества товара, работы, услуги: Гарантийный срок составляет 3 (три) месяца с момента подписания Сторонами документа о приемке.

Информация о требованиях к гарантийному обслуживанию товара:

Требования к гарантии производителя товара:

Банковское или казначейское сопровождение контракта не требуется

Информация о сроках исполнения контракта и источниках финансирования

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

Дата начала исполнения контракта: с даты заключения контракта

Срок исполнения контракта: 30.12.2026

Количество этапов: 2

Закупка за счет бюджетных средств: Да

Наименование бюджета: Бюджет города Таганрога

Вид бюджета: местный бюджет

Код территории муниципального образования: 60737000: Муниципальные образования Ростовской области / Городские округа Ростовской области/ / город Таганрог

Документы

Общая информация

Документы

Журнал событий