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

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

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

Способ определения поставщика (подрядчика, исполнителя): Запрос котировок в электронной форме

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

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

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

Наименование объекта закупки: На приобретение неисключительных прав автоматизированной системы управления муниципальной собственностью (АС УМС) предназначенной для автоматизации деятельности по управлению земельными участками, недвижимым и движимым имуществом, путем сбора, систематизации, хранения, обработки информации в сфере имущественно-земельных отношений и организации электронного взаимодействия между пользователями Системы.

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

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

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

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

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

Почтовый адрес: 357202, СТАВРОПОЛЬСКИЙ КРАЙ МИНЕРАЛОВОДСКИЙ, Г МИНЕРАЛЬНЫЕ ВОДЫ, ПР-КТ КАРЛА МАРКСА, ЗД. 54

Место нахождения: 357202, СТАВРОПОЛЬСКИЙ КРАЙ МИНЕРАЛОВОДСКИЙ, Г МИНЕРАЛЬНЫЕ ВОДЫ, ПР-КТ КАРЛА МАРКСА, ЗД. 54

Ответственное должностное лицо: Безрукова Е. А.

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

Номер контактного телефона: 7-87922-67638

Дополнительная информация: предупреждение в соответствии с пунктом 24 части 1 статьи 42 Федерального закона № 44-ФЗ об административной и уголовной ответственности за нарушение требований антимонопольного законодательства Российской Федерации о запрете участия в ограничивающих конкуренцию соглашениях, осуществления ограничивающих конкуренцию согласованных действий.

Регион: Ставропольский край

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

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

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

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

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

Начальная (максимальная) цена контракта: 1 665 150,00

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

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

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

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

- 58.29.11.000 58.29.11.000-00000003 - Программное обеспечение Класс программ для электронных вычислительных машин и баз данных (02.07) Средства управления базами данных Способ предоставления Копия электронного экземпляра Вид лицензии Простая (неисключительная) - Штука - 1,00 - 1 665 150,00 - 1 665 150,00

УПРАВЛЕНИЕ ИМУЩЕСТВЕННЫХ ОТНОШЕНИЙ АДМИНИСТРАЦИИ МИНЕРАЛОВОДСКОГО МУНИЦИПАЛЬНОГО ОКРУГА СТАВРОПОЛЬСКОГО КРАЯ - 1 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Класс программ для электронных вычислительных машин и баз данных (02.07) Средства управления базами данных Способ предоставления Копия электронного экземпляра Вид лицензии Простая (неисключительная) Клиентское место полного доступа, обладающее полнофункциональными возможностями всех компонентов в составе АС УМС в Управления имущественных отношений администрации Минераловодского муниципального округа Ставропольского края ? 4 Штука Клиентское место АС УМС полного доступа первое (Базовый комплект) – 1 единица наличие Клиентское место АС УМС полного доступа со 2 по 4 – 3 единицы наличие Платформа СМЭВ-Диалог – 1 единица наличие Подсистема «ГИС ГМП. Начисления, платежи, квитирование» – 1 единица наличие Назначение Система должна быть предназначена для автоматизации деятельности по управлению земельными участками, недвижимым и движимым имуществом, путем сбора, систематизации, хранения, обработки информации в сфере имущественно-земельных отношений и организации электронного взаимодействия между пользователями Системы Система должна быть построена по 3х-звенной архитектуре и состоять из следующих компонентов (1) 1. Системы управления базами данных (СУБД) – предназначены для хранения и управления информацией базы данных Системы. Система должна быть совместима с СУБД Исполнителя или эквивалентной (далее - СУБД). В случае, если предлагаемая Исполнителем для использования СУБД не является свободно распространяемым программным обеспечением, то Исполнитель передает Заказчику права на использование СУБД без каких-либо ограничений на использование, в том числе без ограничений по сроку действия лицензии, количеству подключений, размеру используемых баз данных. СУБД не должна иметь ограничений по размеру базы данных и не должна требовать дополнительных обязательных расходов на сопровождение Система должна быть построена по 3х-звенной архитектуре и состоять из следующих компонентов (2) 2. Сервер приложений – промежуточное звено обеспечения взаимодействия клиентских мест и СУБД. Сервер приложений для Системы должен обеспечивать предоставление доступа клиентских мест к данным Системы, а также содержать средства обеспечения корректности исполнения технологических процессов (бизнес-логики) функционирования Системы. Сервер приложений не должен требовать ручного запуска перед началом работы пользователей Системы. С целью минимизации сетевого траффика сервер приложения должен обеспечивать передачу клиентским местам информацию порциями по настраиваемому количеству записей (количество записей, которое помещается на экран без прокрутки при любом из используемых разрешений экрана) по мере обращения. Передача информации на клиентское место из используемых справочников и классификаторов должна производиться при первом обращении к справочникам и классификаторам (за исключением системных справочников и классификаторов, необходимых для функционирования Системы в целом). Передача информации на клиентское место по открытым электронным карточкам объектов учета должна производиться только в том объеме, в котором информация отображается в соответствующий момент в карточке объекта учета. Например, информация, размещенная на неоткрытых вкладках карточки объекта учета, должна передаваться на клиентское место непосредственно в момент перехода на соответствующую вкладку Система должна быть построена по 3х-звенной архитектуре и состоять из следующих компонентов (3) 3. Клиентские места – «тонкий» (Desktop) клиент - пользовательские приложения, устанавливаемые на рабочих местах пользователей для предоставления доступа пользователей к функциям Системы или web-клиент. Клиентские места должны обеспечивать возможность доступа ко всему объему функционала Системы, который описан в разделе «Состав Системы, функциональные требования» Требования к размещению средств обеспечения корректности исполнения технологических процессов (бизнес-логики) Системы (1) Средства обеспечения корректности исполнения технологических процессов (бизнес-логики) в максимально возможном объеме должны быть реализованы на уровне базы данных (выполняться в автоматическом режиме на уровне СУБД). Данное требование продиктовано необходимостью корректной обработки информации при ее модификации в информационном фонде Системы любым из доступных способов вплоть до корректировки средствами СУБД (запуском скриптов непосредственно в базе данных), а также обеспечением возможности изменения технологических процессов пользователями Системы путем изменения логики реализации технологических процессов на стороне SQL Требования к размещению средств обеспечения корректности исполнения технологических процессов (бизнес-логики) Системы (2) На уровне СУБД должны быть реализованы следующие процессы (технологические процессы или их части): 1. Ведение аудита действий пользователей на уровне полей таблиц (конкретных атомарных атрибутов объектов учета, в том числе в составе составных характеристик). 2. Проверка прав пользователей (хранимые функции или процедуры проверки прав пользователей). 3. Поддержка функционирования средств «быстрого поиска» (по необходимости). 4. Начисление арендной платы, платы за выкуп, платы за фактическое использование объектов, всех видов штрафных санкций, включая начисление пени, процентов за пользование чужими денежными средствами. 5. Расчет сальдо. 6. Расчет задолженности на произвольную дату в произвольном разрезе. 7. Пересчет задолженности на текущее число по всем видам договорных отношений Требования к размещению средств обеспечения корректности исполнения технологических процессов (бизнес-логики) Системы (3) Средства обеспечения технологических процессов, которые не могут быть реализованы на стороне СУБД, должны быть реализованы средствами сервера приложения. Для удобства пользователей часть технологических процессов должна быть продублирована на клиентском месте для обеспечения своевременности информирования пользователя о недопустимости производимых им изменений в момент совершения изменения (до передачи/сохранения изменений на сервер приложения или в базу данных). Например, при удалении из карточки объекта информации, которая используется в информации в карточках других объектов средства проверки допустимости операции (контроль ссылочной целостности) должны быть исполнены непосредственно в момент выполнения операции, а не в момент пакетного сохранения всех выполненных изменений в карточке объекта учета (нажатие пользователем кнопки «Сохранить изменения» или эквивалент). При этом в момент сохранения изменений соответствующая проверка должна быть выполнена повторно средствами сервера приложения или СУБД непосредственно в момент сохранения изменений карточки в рамках соответствующей транзакции. Таким образом, на клиентском месте должны быть продублированы те элементы технологических процессов, которые могут определить некорректные действия пользователя непосредственно в момент их совершения, а не в момент пакетного сохранения выполненных изменений Требования к способам и средствам связи для информационного обмена между компонентами Системы Система должна обеспечивать коллективную работу пользователей объекта автоматизации с использованием единого интегрированного хранилища данных по технологии «клиент-сервер» с использованием трехзвенной архитектуры Требования к приспособляемости Системы Функциональность Системы реализуется, как расширяемая, т.е. должна допускать наращивание функциональных возможностей на основе подключения дополнительных (или изменения существующих) подсистем в связи с изменением существующих и возникновением новых автоматизируемых процессов, обусловленных изменениями в нормативно-законодательной базе. Подсистемы должны иметь программные интерфейсы, обеспечивающие возможность расширения функциональности Системы путём добавления компетентными, обученными пользователями Системы дополнительных программных модулей. Система должна быть гибкой, т.е. легко настраивающейся на изменения условий функционирования и организационной структуры объектов автоматизации Системы. Система должна сохранять работоспособность при увеличении количества пользователей в пределах, поддерживаемых аппаратно-программной средой серверов технологического узла. Должна быть обеспечена возможность увеличения числа пользователей Системы Требования к защите информации от несанкционированного доступа (1) Подсистемы должны отвечать требованиям к защите данных от несанкционированного доступа. Система должна обеспечивать идентификацию и аутентификацию пользователя, обратившегося для получения доступа к функциям Системы. В Системе должны быть обеспечены разграничение и администрирование доступа к компонентам Системы. Применение вышеуказанных средств защиты информации должно осуществляться пользователями Системы в соответствии с ведомственными нормативными актами и регламентами. Механизмы безопасности Системы должны позволять ограничивать круг лиц, принимающих участие в работе с данными, и позволять контролировать процесс работы с защищенными документами и знать, откуда возможна утечка информации Требования к защите информации от несанкционированного доступа (2) Защита информации от несанкционированного доступа в Системе должна обеспечиваться реализацией следующих функций Системы: 1. Предоставление доступа к Системе должно предоставляться только предварительно зарегистрированным пользователям. 2. Возможность разграничения доступа к подсистемам для каждого пользователя. 3. Возможность для каждого пользователя установить уровень доступа, обеспечивающий только просмотр или редактирование информации. 4. Управление разграничением и/или уровнями доступа пользователей должно осуществляться через группы доступа. 5. Разграничение по доступу к данным Системы должно быть согласно утвержденным полномочиям пользователей Системы. 6. Регистрация входа (выхода) пользователей в Систему (из Системы) должна фиксироваться в журнале действий пользователей. 7. Должна быть возможность функционального разграничения действий пользователей при обработке информации. 8. Ведение справочника пользователей Системы. 9. Журналирование действий пользователей, которое должно обеспечиваться путем ведения в Системе «журнала событий», доступного только с автоматизированного рабочего места администратора и включающего в себя следующие данные: 9.1. Системные действия: дата, событие, пользователь. 9.2. Действия над пользователями Системы: дата, событие, администратор. 9.3. Действия пользователей. «Журнал событий» должен быть недоступен к внесению изменений Требования к защите информации от несанкционированного доступа (3) Система должна обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях Система должна выдавать пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных. Должна быть предусмотрена возможность резервного копирования и ручного восстановления стандартными средствами системы управления базой данных (далее – СУБД) администраторами Системы обрабатываемой информации из резервной копии в следующих аварийных ситуациях: 1. Ошибочные действия пользователей (администраторов), приведшие к утрате или искажению данных Системы. 2. Отказ Системы, связанный с фатальным нарушением целостности файловой системы или структуры баз данных. Для резервного копирования должны использоваться штатные средства системной программной платформы, причем организация баз данных Системы должна обеспечивать сохранение: 1. Всех параметров настройки Системы, включая учетные записи и персональные настройки пользователей. 2. Всей информации Системы Требования к патентной чистоте Система должна отвечать требованиям по патентной чистоте согласно действующему законодательству Российской Федерации, в Системе не должны использоваться решения, приводящие к нарушению смежных прав и прав третьих лиц, защищенные патентами или иными действующими на территории Российской Федерации документами, удостоверяющими авторские права на них, без соответствующего лицензионного соглашения с авторами данных решений. Выполнение требований по обеспечению лицензионной чистоты Системы возлагается на Исполнителя Требования к контролю, хранению, обновлению и восстановлению данных Контроль корректности данных должен обеспечиваться реализацией функций форматного, логического контроля на уровне пользовательских форм. Для хранения данных Системы должна использоваться СУБД, средствами которой выполняются действия записи, обновления, журналирования изменений, резервного копирования и восстановления данных Требования к лингвистическому обеспечению В системных диалогах с пользователями в текстах сообщений должен применяться русский язык. Содержание используемых в Системе справочников должно быть реализовано на русском языке Состав системы, функциональные требования Система состоит из следующих подсистем, средств и других элементов, выполняющих соответствующие функции: 1. Подсистема «Имущество». 2. Подсистема «Земля». 3. Подсистема «Ведение информации по субъектам права». 4. Подсистема «Ведение информации по акциям». 5. «Адресная подсистема». 6. Подсистема «Ведение договоров и дополнительных соглашений» 7. Подсистема «Выкуп с рассрочкой». 8. «Финансово-аналитическая подсистема». 9. Подсистема «Автоматизация претензионной и исковой деятельности». 10. Аналитическая и сервисная подсистема «Библиотека запросов». 11. Подсистема «Формирование отчетов и печатных форм, генератор отчетов». 12. Подсистема «Обеспечение безопасности, администрирования и разграничения прав доступа». 13. Подсистема «Ведение нормативно-справочной информации». 14. Подсистема «Автоматическое обновление клиентских рабочих мест». 15. Подсистема «Оповещение пользователей». 16. Подсистема «Самодиагностика с оповещением о выявленных аномалиях по электронной почте». 17. Средства ведения электронных карточек объектов учета. 18. Средства поиска, отображения и анализа информации. 19. Средства предварительного просмотра. 20. Средства выполнения массовых операций. 21. Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ. 22. Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» Подсистема «Имущество» (1) Подсистема «Имущество» должна автоматизировать ведение реестра объектов муниципальной собственности, а также внереестровых объектов всех учитываемых типов. Доступ к объектам имущества должен осуществляться из основного окна Системы с использованием иерархического меню. Перечень учитываемых типов и конкретная настройка иерархического меню доступа к объектам должны быть определены на этапе обследования организации. Например, иерархическое меню доступа и перечень учитываемых типов объектов могут быть настроены в ручном режиме, например, в соответствии со схемой: 1. Недвижимое имущество: 1.1. Жилой фонд: 1.1.1. Жилые здания. 1.1.2. Жилые квартиры, помещения. 1.1.3. Жилые комнаты. 1.2. Нежилые здания. 1.3. Нежилые помещения. 1.4. Объекты незавершенного строительства. 1.5. Объекты инженерной инфраструктуры, сооружения. 1.6. Объекты внешнего благоустройства. 1.7. Доли. 1.8. Нематериальные активы, объекты интеллектуальной собственности. 1.9. Воздушные и морские суда, суда внутреннего плавания. 1.10. Космические объекты. 1.11. Прочие объекты, не включенные в указанные группировки. 2. Движимое имущество: 2.1. Особо ценное движимое имущество. 2.2. Малоценное (прочее) движимое имущество. 2.3. Транспортные средства. 2.4. Объекты инженерной инфраструктуры. 2.5. Прочее движимое имущество, не относящиеся к указанным выше. 3. Акции, паи, доли. 4. Имущественные комплексы. 5. Муниципальные предприятия и учреждения. Должна быть предусмотрена возможность скрытия неиспользуемых на момент внедрения пунктов меню (видов объектов учета) Подсистема «Имущество» (2) Подсистема должна автоматизировать выполнение следующих основных задач. 1. Учет объектов. Для каждого из объектов должна вестись следующая основная информация: 1.1. Наименование объекта. 1.2. Принадлежность к реестру, подреестру (с историей изменения и ссылками на документы-основания). 1.3. Реестровый номер (с историей изменения и ссылками на документы-основания). 1.4. Кадастровый номер (не обязательный для заполнения, при наличии – обязательный для заполнения), условный номер. 1.5. Адрес (с возможностью ввода множественного адреса). 1.6. Субъекты права (движение на балансе, другие субъекты права) – с историей изменения, множественностью документов-оснований возникновения и прекращения права (ссылки на документы). 1.7. Экономические показатели (балансовые, остаточные стоимости и др.) – с историей изменения и ссылками на документы-основания. 1.8. Технические показатели (с историей изменения и ссылками на документы-основания). 1.9. Документы (все документы, имеющие отношение к данному объекту с делением по направлениям воздействия документов (включение/исключение, внесение изменений, правоустанавливающие, регистрирующие документа) – без ограничения количества и типов регистрируемых документов). 1.10. Комиссии. 1.11. Коэффициенты-характеристики, площадь (с историей изменения и ссылками на документы-основания). 1.12. Части помещений (подвал, полуподвал, этажи): 1.12.1. Коэффициенты-характеристики частей помещений, площадь (с историей изменения и ссылками на документы-основания). 1.12.2. Типы использования частей помещений (с историей изменения и ссылками на документы-основания). 1.12.3. Материал стен, варианты входа, уровни благоустройства, высота потолков – произвольное количество категорий благоустройства с произвольным количеством выбираемых элементов благоустройства в каждой категории, предусмотрена возможность указания уровней благоустройства объекта целиком и каждой из частей помещения отдельно. 1.13. Принадлежность к земельному участку (множественная связь – один Подсистема «Имущество» (3) 1.15. Признак принадлежности к объектам культурного наследия, а также информация о включении объекта в реестр объектов культурного наследия (Номер в реестре, категория историко-культурного наследия – справочник, Признак принадлежности объекта к объектам религиозного значения, признак принадлежности объекта к ансамблям, ссылка на документ-основание с возможностью указания нескольких документов оснований и период нахождения объекта в реестре с возможностью учета разных периодов включения объектов и соответственно разных данных по нахождению объекта в реестре). 1.16. Информация по проводимым аукционам, торгам, конкурсам. 1.17. Классификация объектов учета – предусмотрена возможность учета произвольного количества категорий классификации с произвольным количеством элементов классификации в каждой из категорий, а также текстовым описанием каждого элемента – с историей изменений и ссылками на документы-основания присвоения элемента классификации и исключения объекта из классификации (множественность документов-ссылок). 1.18. События (даты) – с историей изменений и ссылкой на документ-основание. 1.19. Признаки («галочки») - принадлежность к чему-либо с текстовым описанием признака. 1.20. Договоры использования и обременения (аренды, купли-продажи, безвозмездного пользования, согласования, разрешения, размещения, сервитуты). 1.21. Информация по претензионной и исковой деятельности (детальная информация по поданным претензиям и искам, включая необходимую классификационную и описательную части, предметы исков, в том числе суммы с делением по видам начислений, перечень этапов претензионной и исковой деятельности с указанием ссылок на документы этапа, уточнение требований) – см. пункт «Подсистема автоматизации претензионной и исковой деятельности» Подсистема «Имущество» (4) 2. Автоматическое присвоение реестрового номера с возможностью настройки методики и структуры формирования номера, а также возможностью организации сквозной нумерации по нескольким видам объектов учета (настройка категорий нумерации, для каждой категории можно указать перечень видов объектов учета, входящих в категорию). 3. Ведение информации по подобъектам, составным частям объектов. 4. Управление историей изменения основных характеристик объектов и документами-основаниями на проведение изменений. 5. Управление движением объектов в реестре (включение, исключение, перемещение между реестрами, ведение истории реорганизации объектов (слияния, разделения)). 6. Управление движением объектов на балансе и в казне, договорами оперативного управления и хозяйственного ведения. 7. Обеспечение информационного взаимодействия/обмена информацией по объектам муниципальной собственности с субъектами права (балансодержателями и др.) – массовое обновление стоимостных показателей (балансовая, остаточная стоимость, износ), характеристик объектов. 8. Управление движением объектов в казне (с возможностью ведения балансового и забалансового бюджетного учета движения объектов в казне). 9. Ведение документального обеспечения (документов-оснований) движения объектов, изменения характеристик объектов в реестре. 10. Ведение аукционов и торгов на право аренды или купли-продажи объектов. 11. Формирование реестров объектов муниципальной собственности. 12. Формирование выписок из реестров, справок о движении объектов, проектов приказов, постановлений, распоряжений, других необходимых печатных форм. 13. Формирование аналитической отчетности. 14. Проведение экспресс-аналитики. 15. Корректное проставление даты выбытия объекта в зависимости от выбранного документа основания (например, выбытие по исключению из реестра или из-за регистрации права собственности за иным лицом) Подсистема «Имущество» (5) 16. Возможность указания шаблона для вывода адреса в нужном формате. 17. Возможность работы со справочниками ФИАС при формировании адреса. 18. Управление историей объектов для отслеживания хронологии реорганизации, разделения, объединения объекта. 19. Протоколирование действий пользователей. 20. Возможность прикрепления к карточке объекта учета произвольного количества файлов произвольного типа. 21. Возможность ведения внереестровых объектов. Должна быть предусмотрена возможность смены типа объектов, включенных по ошибке в другие подразделы имущества (в том числе объектов прошлых периодов), например, изменить тип «нежилое здание» на «нежилое помещение» или на «сооружение» и наоборот Подсистема «Земля» (1) Подсистема «Земля» должна автоматизировать ведение реестров земельных участков, собственность на которую разграничена, а также ведение земельных участков, собственность на которые не разграничена или с другими видами собственности, находящихся в сфере компетенции органов управления земельными ресурсами. Подсистема должна автоматизировать выполнение следующих основных задач: 1. Пообъектный учет земельных участков (ЗУ). Для каждого из ЗУ ведется следующая основная информация: 1.1. Наименование ЗУ. 1.2. Принадлежность к реестру, подреестру (с историей изменения). 1.3. Кадастровый номер (кадастровый квартал выбирается из классификатора, не обязательный для заполнения). 1.4. Категория земель (с историей изменения и ссылками на документы-основания). 1.5. Разрешенное использование (с историей изменения и ссылками на документы-основания). 1.6. Уровень собственности (состояние). 1.7. Реестровый номер (с историей изменения и ссылками на документы-основания). 1.8. Адрес, адресный ориентир (с возможностью ввода множественного адреса). Должна быть предусмотрена возможность указания государственного образования для обеспечения возможности дальнейшего отбора земельных участков по соответствующему показателю. 1.9. Субъекты права (землепользователи, другие субъекты права) – с историей изменения, множественностью документов-оснований возникновения и прекращения права (ссылки на документы), в том числе и права постоянного (бессрочного) пользования. 1.10. Экономические показатели (Кадастровые стоимости и др.) – с историей изменения и ссылками на документы-основания. 1.11. Технические показатели (с историей изменения и ссылками на документы-основания). 1.12. Документы (все документы, имеющие отношение к данному объекту с делением по направлениям воздействия документов (включение/исключение, внесение изменений, правоустанавливающие, регистрирующие документа)). 1.13. Комиссии. 1.14. Коэффициенты-характеристики, площадь (с историей изменения и ссылками на документы-основания) Подсистема «Земля» (2) 1.15. Информация по использованию ЗУ (классификация для аналитики, ставки арендной платы, типы использования для кадастровой оценки, налоговые ставки по типам использования) с возможностью указания различных типов использования долей земельного участка (с историей изменения и ссылками на документы-основания). 1.16. Перечень объектов недвижимого имущества, размещенных на данном участке. (кадастровый номер, наименование, права) 1.17. Информация по проводимым аукционам, торгам, конкурсам. 1.18. Классификация объектов учета – предусмотрена возможность учета произвольного количества категорий классификации с произвольным количеством элементов классификации в каждой из категорий, а также текстовым описанием каждого элемента – с историей изменений и ссылками на документы-основания присвоения элемента классификации и исключения объекта из классификации (множественность документов-ссылок). 1.19. Информация по претензионной и исковой деятельности (детальная информация по поданным претензиям и искам, включая необходимую классификационную и описательную части, предметы исков, в том числе суммы с делением по видам начислений, перечень этапов претензионной и исковой деятельности с указанием ссылок на документы этапа, уточнение требований) – см. Пункт «Подсистема автоматизации претензионной и исковой деятельности». 1.20. События (даты) – с историей изменений и ссылкой на документ-основание. 1.21. Признаки («галочки») - принадлежность к чему-либо с текстовым описанием признака. 1.22. Договоры использования и обременения (аренды, купли-продажи, безвозмездного пользования, согласования, разрешения, размещения, сервитуты) Подсистема «Земля» (3) 2. Автоматическое присвоение реестрового номера с возможностью настройки методики и структуры формирования номера, а также возможностью организации сквозной нумерации по нескольким видам объектов учета (настройка категорий нумерации, для каждой категории можно указать перечень видов объектов учета, входящих в категорию). 3. Управление историей изменения основных характеристик ЗУ, документами-основаниями на проведение изменений. 4. Управление движением ЗУ в реестре (включение, исключение, перемещение между реестрами, ведение истории реорганизации объектов (слияния, разделения)). 5. Управление движением ЗУ по субъектам права. 6. Управление движением ЗУ в казне (с возможностью ведения балансового и забалансового бюджетного учета движения объектов в казне). 7. Ведение документального обеспечения (документов-оснований) движения ЗУ, изменения характеристик объектов в реестре. 8. Ведение аукционов и торгов на право аренды или купли-продажи ЗУ. 9. Формирование реестров земельных участков. 10. Формирование выписок из реестра, справок о движении ЗУ, проектов приказов, постановлений, распоряжений, других необходимых печатных форм. 11. Формирование аналитической отчетности в соответствующей сфере. 12. Проведение экспресс-аналитики. 13. Корректное проставление даты выбытия объекта в зависимости от выбранного документа основания (например, выбытие по исключению из реестра или из-за регистрации права собственности за иным лицом). 14. Возможность указания шаблона для вывода адреса в нужном формате. 15. Возможность работы со справочниками ФИАС при формировании адреса. 16. Управление историей объектов для отслеживания хронологии реорганизации, разделения, объединения объекта. 17. Протоколирование действий пользователей. 18. Возможность прикрепления к карточке объекта учета произвольного количества файлов произвольного типа. 19. Возможность ведения внереестровых объектов Подсистема «Ведение информации по субъектам права» (1) Подсистема должна обеспечивать ведение информации по муниципальным предприятиям и учреждениям (как реестровым объектам), а также по субъектам права, участвующих в имущественно-земельных отношениях (юридические, физические лица, индивидуальные предприниматели). Подсистема должна автоматизировать выполнение следующих основных задач: 1. Пообъектный учет субъектов права. Для каждого из субъектов права ведется следующая основная информация: 1.1. Наименование субъекта права (полное и краткая информация, с историей изменения). 1.2. ИНН. 1.3. Принадлежность к реестру, подреестру (с историей изменения и ссылкой на документ-основание). 1.4. Реестровый номер (с историей изменения и ссылкой на документ-основание). 1.5. Адрес (с возможностью ввода множественного адреса), структура адреса должна соответствовать федеральным требованиям (ФИАС). Система должна обеспечивать возможность автоматизированного обновления классификаторов адресной подсистемы на основе ФИАС. 1.6. Организационная форма, вид деятельности, вид собственности (классификаторы). 1.7. Контакты - руководитель, главный бухгалтер, другие сотрудники (произвольное количество), телефоны (произвольное количество), банковские реквизиты (с историей изменения), реквизиты трудовых договоров руководителя и главного бухгалтера с возможность загрузки в систему самих договоров и дополнительных соглашений к ним, а также реквизитов документов о назначении и увольнении руководителей с возможностью загрузки в систему указанных документов. 1.8. Информация по членам семьи, родственным отношениям (для физических лиц). 1.9. Паспортные данные (для физических лиц, индивидуальных предпринимателей) – с историей изменения, дата рождения. 1.10. Субъекты права (представители, учредители) – с историей изменения и ссылками на документы-основания, возможностью расширения в части регистрации произвольного количество субъектов права произвольного типа (любого вида права, с возможностью расширения) Подсистема «Ведение информации по субъектам права» (2) 1.11. Экономические показатели (балансовая, остаточная стоимость объектов на балансе, среднесписочная численность сотрудников, показатели эффективности) – с историей изменения и ссылками на документы-основания. Должна быть обеспечена возможность учета произвольного количества экономических показателей любого типа с возможностью расширения средствами системы. Минимальный набор показателей эффективности: ? основные средства; ? финансовые вложения; ? отложенные налоговые активы; ? прочие внеоборотные активы; ? запасы; ? дебиторская задолженность; ? финансовые вложения (за исключением денежных эквивалентов); ? денежные средства и денежные эквиваленты; ? прочие оборотные активы; ? уставный капитал/фонд; ? добавочный капитал (без переоценки); ? резервный капитал; ? нераспределенная прибыль (непокрытый убыток); ? чистые активы; ? заемные средства; ? отложенные налоговые обязательства; ? оценочные обязательства; ? прочие обязательства; ? заемные средства; ? кредиторская задолженность; ? доходы будущих периодов; ? оценочные обязательства; ? прочие обязательства; ? выручка; ? себестоимость продаж; ? валовая прибыль (убыток); ? коммерческие расходы; ? управленческие расходы; ? прибыль (убыток) от продаж; ? доходы от участия в других организациях; ? проценты к получению; ? проценты к уплате; ? прочие доходы; ? прочие расходы; ? прибыль (убыток) до налогообложения; ? налог на прибыль; ? в том числе: ? текущий налог на прибыль; ? отложенный налог на прибыль; ? прочее; ? чистая прибыль (убыток). Программа должна предусматривать возможность загружать скан-образы бухгалтерской (финансовой) отчетности и планов (программ) финансово-хозяйственной деятельности. Также Программа должна предусматривать возможность ведения основных плановых и фактических показателей результатов финансово-хозяйственной деятельности. Подсистема «Ведение информации по субъектам права» (3) 1.12. Классификационные коды (ОКВЭД, ОКОНХ, ОГРН, КПП) – с ведением истории и ссылками на документы-основания, с возможностью расширения перечня учитываемых кодов без участия программистов. 1.13. Информация по документам (все документы, имеющие отношение к данному объекту с делением по направлениям воздействия документов (включение/исключение, внесение изменений, правоустанавливающие, регистрирующие документа)). Должна быть обеспечена возможность учета информации по произвольному количеству документов любого типа с возможностью расширения средствами системы. 1.14. Комиссии. 1.15. События (даты жизненного цикла объекта) с возможностью расширения количества и типов событий средствами системы. 1.16. Признаки (принадлежности к определенным учетным категориям, группам в соответствии с технологией учета) с возможностью расширений наименований признаков средствами системы. 1.17. Перечень объектов имущества на балансе и в пользовании. 1.18. Перечень земельных участков в землепользовании и в пользовании (аренда). 1.19. Перечень договоров всех типов для объектов имущества (аренда, купля/продажа, безвозмездное пользование, социальный найм). 1.20. Перечень договоров всех типов для земельных участков (аренда, купля/продажа, безвозмездное пользование). 1.21. Полная финансовая информация по всем видам договоров (начисления, платежи, задолженность). Для ГУП должна содержаться следующая информация: ? о долговых обязательствах с расшифровкой по каждому кредитору, а также с возможностью перехода к реестру договоров субъекта, в котором можно получить доступ к реквизитам заключенных договоров, существенными условиями по каждому договору, основному долгу и процентам; ? о крупных сделках, в том числе с возможностью перехода в карточку сделки, для просмотра реквизитов документа, которым она согласована и ее существенных условий. С возможностью загрузки в Систему документа, которым согласована сделка Подсистема «Ведение информации по субъектам права» (4) 1.22. Информация по банкротству. 1.23. Информация по претензионной и исковой деятельности (детальная информация по поданным претензиям и искам, включая необходимую классификационную и описательную части, предметы исков, в том числе суммы с делением по видам начислений, перечень этапов претензионной и исковой деятельности с указанием ссылок на документы этапа, уточнение требований) – см. Пункт «подсистема автоматизации претензионной и исковой деятельности». 2. Управление историей изменения основных данных по субъектам права, документами-основаниями на проведение изменений. 3. Управление движением субъектов права в реестре и списках учета (включение, исключение, перемещение между реестрами, ведение истории реорганизации объектов (слияния, разделения)), документами-основаниями, правоустанавливающими и другими документами. 4. Использование информации по субъектам права при формировании договоров, дополнительных соглашений, других документов, при формировании информации о других имущественно-земельных отношениях с участием соответствующих субъектов права. 5. Формирование аналитики по деятельности субъекта права в рамках имущественно-земельных отношений. 6. Формирование аналитики по задолженности, работа с должниками. 7. Возможность формирования аналитической отчетности в соответствующей сфере (с использованием встроенных средств генераторов отчетов). 8. Проведение экспресс-аналитики Управления предприятиями банкротами В Системе должна быть реализована возможность управления информацией о предприятиях банкротах, а также процессах и стадиях банкротства. В рамках данной функции должна быть предусмотрена возможность ведения следующей информации: 1. Перечень стадий банкротства (внешнее наблюдение, конкурсное управление). 2. Информацию об управляющих компаниях и саморегулирующихся организациях. 3. Перечень заседаний руководства для обсуждения текущих вопросов. 4. Сведения о публикации сведений о банкротстве. 5. Реестр требований кредиторов для реструктуризации задолженности. 6. Информация о конкурсной массе на момент открытия конкурсного производства. 7. Периоды изменения всех вышеперечисленных атрибутов. 8. Информация о всех документах, связанных со всеми процессами банкротства, а также связи данных документов с теми атрибутами, на изменение которых они направлены. 9. Ведение данной информация позволит эффективно отслеживать все процессы, связанные с банкротством, и оперативно предпринимать меры по улучшению финансового состояния должника Подсистема «Ведение информации по акциям» В Системе должна быть возможность ведения информации об акциях (долях), находящихся в собственности муниципального образования. В рамках подсистемы помимо стандартных атрибутов должна быть предусмотрена возможность ведения следующей информации: 1. Субъекты акций (сведения об эмитенте, совете директоров, ревизионных комиссиях). 2. Субъекты долей (сведения об обществе, совете директоров, ревизионных комиссиях). 3. Заседания совета директоров и общего собрания акционеров (участников), включая возможность фиксации решения собрания, загрузки протоколов. 4. Информация о стоимостях акций (долей) и количестве акций (в разрезах видов акций). 5. Сведения о собраниях советов директоров и ревизионных комиссий (включая состав совета, протокол). 6. Бюджетный учет акций (долей) в казне. 7. Сведения об эмитенте (обществе) должны содержать информацию, указанную в пунктах 1.7 (в отношении генерального директора) и 1.11 в разделе 4.3 настоящего технического задания, а также возможность перехода в реестр договоров для получения информации о долговых обязательствах с расшифровкой по каждому кредитору, реквизитами заключенных договоров, существенными условиями по каждому договору, основному долгу и процентам. 8. Информацию о крупных сделках, в том числе с возможностью перехода в карточку сделки, для просмотра реквизитов документа, которым она согласована и ее существенных условий. С возможностью загрузки в Систему документа, которым согласована сделка «Адресная подсистема» «Адресная подсистема» (средства формирования адресов объектов для реестровой подсистемы учета) должна обеспечивать возможность формирования и учета произвольного количества адресов для каждого объекта учета. Для каждого из адресов должна быть предусмотрена возможность указания типа адреса на основе расширяемого классификатора (присвоенный адрес – официальный, юридический адрес, предыдущий адрес (при наличии) и адресного ориентира (местоположение объекта учета). Присвоенный адрес – официальный, должен быть один. «Адресная подсистема» должна обеспечивать возможность указания адресных реквизитов, утвержденных, постановлением Правительства РФ от 19.11.2014 № 1221 как с использованием собственных справочников и классификаторов присвоенных адресов или установленных ранее, включая адресный ориентир, так и с использованием базы федеральной информационной адресной системы (ФИАС). «Адресная подсистема» должна обеспечивать возможность настройки шаблона вывода адреса (формирования строки адреса) для каждого из типов объектов учета (наименований реестров объектов учета). Шаблон должен обеспечивать возможность указания адресных реквизитов в соответствии с требованиями к структуре адреса, например, , , , , или , , , и т.п. Строка адреса обязательно отображается в карточке объекта учета и в списке объектов учета соответствующего типа. «Адресная подсистема» должна обеспечивать возможность ввода адреса любых объектов учета, включая адреса комнат, офисов, территорий и т.д. Должна быть предусмотрена возможность указания адресного ориентира «Адресная подсистема» (2) «Адресная подсистема» должна обеспечивать возможность ввода адреса следующей структуры: 1. Наименование страны (Российская Федерация) – выбирается из справочника. 2. Наименование субъекта Российской Федерации – выбирается из справочника. 3. Наименование муниципального района, городского округа или внутригородской территории (для городов федерального значения) в составе субъекта Российской Федерации – выбирается из справочника. 4. Наименование городского или сельского поселения в составе муниципального района (для муниципального района) или внутригородского района городского округа – выбирается из справочника. 5. Наименование населенного пункта – выбирается из справочника. 6. Наименование элемента планировочной структуры – выбирается из справочника. 7. Наименование элемента улично-дорожной сети – выбирается из справочника присвоенных наименований элементам УДС. 8. Номер земельного участка. 9. Тип и номер здания, сооружения или объекта незавершенного строительства. 10. Тип и номер помещения, расположенного в здании или сооружении. Перечень элементов планировочной структуры (справочник), элементов улично-дорожной сети (справочник), элементов объектов адресации, типов зданий (сооружений) и помещений, используемых в качестве реквизитов адреса (справочники), а также правила сокращенного наименования адресообразующих элементов устанавливаются Министерством финансов Российской Федерации. Для зависимых справочников должна быть предусмотрена возможность автоматической подфильтровки допустимых для выбора элементов при заполнении элементов вышестоящих классификаторов, от которых зависят данные. Если значения вышестоящих классификаторов не заданы, то при выборе элемента некоторого зависимого справочника элементы вышестоящих справочников должны заполниться (выбраться автоматически) Особенности работы адресной подсистемы при использовании ФИАС При использовании сведений об адресе из ФИАС ввод или изменение адреса объекта учета должно производиться в отдельной строке экранной формы объекта учета с обязательным внесением уникального номера адреса объекта адресации из государственного адресного реестра. Структура базы данных для хранения данных ФИАС должна полностью соответствовать структуре данных ФИАС. Элементы ФИАС должны быть расположены в отдельной базе данных Системы, для которой должен быть предоставлен отдельный режим обслуживания и резервного копирования. В адресной подсистеме должен быть предусмотрен режим обновления во всех подсистемах Системы адресообразующих элементов, включая уникальный номер адреса объекта адресации в государственном адресном реестре базы данных ФИАС Подсистема управления договорами и дополнительными соглашениями должна автоматизировать выполнение всех задач ведения соответствующих договорных отношений и претензий за фактическое использование объектов без заключения договорных отношений. Подсистема «Имущество» автоматизирует ведение договоров и других правовых отношений следующих типов: 1. Договор социального найма жилья (для объектов жилого фонда). 2. Договор специализированного найма жилья (для объектов жилого фонда). 3. Договоры на согласовании (при заключении договора балансодержателями имущества). 4. Договор аренды. 5. Договор купли/продажи/приватизации. 6. Договор выкупа с рассрочкой. 7. Договор безвозмездного пользования объектов движимого имущества. 8. Договор безвозмездного пользования недвижимого имущества, имущественных комплексов. 9. Договор мены. 10. Договор дарения. 11. Договор на установку и эксплуатацию рекламных конструкций. 12. Распорядительный документ по праву постоянного бессрочного пользования. 13. Разрешение на установку и эксплуатацию рекламных конструкций. 14. Договор на размещение информационных конструкций. 15. Решение о регистрации информационных конструкций. Подсистема «Земля» автоматизирует ведение договоров и других правовых отношений следующих типов: 1. Договор аренды. 2. Договор купли-продажи земельного участка, заключенный по итогам аукциона. 3. Договор купли-продажи земельного участка без торгов (в том числе с рассрочкой платежей). 4. Соглашение о перераспределении земельных участков. 5. Договор безвозмездного пользования. 6. Соглашение о сервитуте (публичном сервитуте). 7. Разрешения на использование земельного участка без его предоставления и установления сервитута. 8. Претензия за фактическое использование участка без заключения договора (расчеты в соответствии с требованиями Гражданского кодекса РФ) Подсистема управления договорами и дополнительными соглашениями должна автоматизировать выполнение всех задач ведения соответствующих договорных отношений и претензий за фактическое использование объектов без заключения договорных отношений. Подсистема «Имущество» автоматизирует ведение договоров и других правовых отношений следующих типов: 1. Договор социального найма жилья (для объектов жилого фонда). 2. Договор специализированного найма жилья (для объектов жилого фонда). 3. Договоры на согласовании (при заключении договора балансодержателями имущества). 4. Договор аренды. 5. Договор купли/продажи/приватизации. 6. Договор выкупа с рассрочкой. 7. Договор безвозмездного пользования объектов движимого имущества. 8. Договор безвозмездного пользования недвижимого имущества, имущественных комплексов. 9. Договор мены. 10. Договор дарения. 11. Договор на установку и эксплуатацию рекламных конструкций. 12. Распорядительный документ по праву постоянного бессрочного пользования. 13. Разрешение на установку и эксплуатацию рекламных конструкций. 14. Договор на размещение информационных конструкций. 15. Решение о регистрации информационных конструкций. Подсистема «Земля» автоматизирует ведение договоров и других правовых отношений следующих типов: 1. Договор аренды. 2. Договор купли-продажи земельного участка, заключенный по итогам аукциона. 3. Договор купли-продажи земельного участка без торгов (в том числе с рассрочкой платежей). 4. Соглашение о перераспределении земельных участков. 5. Договор безвозмездного пользования. 6. Соглашение о сервитуте (публичном сервитуте). 7. Разрешения на использование земельного участка без его предоставления и установления сервитута. 8. Претензия за фактическое использование участка без заключения договора (расчеты в соответствии с требованиями Гражданского кодекса РФ) Подсистема «Ведение договоров и дополнительных соглашений» (2) Подсистема управления договорами и дополнительными соглашениями должна автоматизировать решение следующих основных задач: 1. Учет всех условий договоров и дополнительных соглашений. По каждому договору и доп. соглашению ведется следующая основная информация: 1.1. Номер и дата договора, доп. соглашения, номер и дата регистрации. 1.2. Код бюджетной классификации. 1.3. Тип использования, целевое использование. 1.4. Дата начала фактического использования объекта договора (для определения периода фактического использования). 1.5. Дата начала действия, планируемого и фактического окончания (расторжения), дата фактического освобождения объекта (для определения периода фактического использования объекта после расторжения договора). 1.6. Особые условия, ограничения. 1.7. Документы-основания, документы на льготы, другие документы. 1.8. Комиссии. 1.9. Объекты договора (может быть несколько объектов в договоре) – с возможностью указания периода нахождения объекта или его доли в договоре, доли объектов учета по договору – с историей изменения величины доли. 1.10. Формула (алгоритм) расчета планируемой платы по договору (индивидуально для каждого объекта или доли объекта в договоре) – с историей изменения. 1.11. Коэффициенты, ставки, индивидуальные показатели, другие характеристики, участвующие в автоматическом расчете планируемой арендной платы (индивидуально по каждому объекту в договоре) – с историей изменения. 1.12. Субъекты договора (с историей изменения, периодами действия для переуступки, субаренды, доверенности, ссылками на документы-основания). 1.13. Информация по субаренде с привязкой к объектам субаренды и характеристикам, коэффициентам, влияющим на расчет суммы планируемой арендной платы на субарендуемые площади (индивидуально для каждого субарендатора и субъекта субаренды) – с периодами действия. 1.14. Информация по планируемой плате по договору (с полной историей изменения) 1.15. Схема начисления в соответствии с условиями договора с историей изменения. Подсистема «Ведение договоров и дополнительных соглашений» (3) 1.16. Индивидуальные ставки пени – с историей изменения и ссылками на документы-основаниями, а также возможностью индивидуальной настройки количества знаков после запятой для расчетов пени, а также возможности начисления процентов вместо пени. 1.17. Индивидуальные ставки процентов за пользование чужими денежными средствами – с историей изменения и ссылками на документы-основаниями, а также возможностью индивидуальной настройки количества знаков после запятой для расчетов процентов, а также возможности начисления пени вместо процентов. 2. Управление дополнительными соглашениями, изменениями условий договора по дополнительным соглашениям. 3. Управление договорами с множественностью лиц. 4. Управление договорами с множественностью объектов. 5. Переоформление, продление договоров. 6. Автоматизация процесса переуступки права по договору. 7. Переоформление договоров аренды земельных участков при разграничении собственности на объекты аренды. 8. Автоматизированный расчет суммы планируемой платы, платы за выкуп с учетом всех особых условий договора. 9. Автоматизация расчета суммы планируемой платы по договору с учетом истории изменения расчетных величин, изменения условий договора по доп. соглашениям, учета различных особых условий (в том числе различные виды льгот, субаренда, долевая аренда/выкуп, аренда/выкуп с разными типами использования объектов договора, автоматическим поднятием до установленных минимумов). 10. Автоматизация подготовки необходимых печатных форм (в том числе текстов договора, доп. Соглашения, проектов постановлений, распоряжений, приказов). 11. Формирование аналитики по задолженности, работа с должниками. 12. Автоматизация претензионной и исковой деятельности. 13. Формирование аналитической отчетности в соответствующей сфере. Подсистема «Ведение договоров и дополнительных соглашений» (4) 14. Проведение экспресс-аналитики и др. Проведение начислений арендной платы по договорам, платы за выкуп, пени и других штрафов, учет платежей, расчет задолженности в необходимых разрезах производится финансово-аналитической подсистемой Ведение договоров и дополнительных соглашений специализированного жилищного фонда К жилым помещениям специализированного жилищного фонда относятся следующие виды жилых помещений, находящиеся в муниципальной собственности: 1. Служебные жилые помещения. 2. Жилые помещения в общежитиях. 3. Жилые помещения маневренного фонда. 4. Жилые помещения в домах системы социального обслуживания населения. 5. Жилые помещения для социальной защиты отдельных категорий граждан. 6. Жилые помещения для детей-сирот и детей, оставшихся без попечения родителей, лиц из числа детей сирот и детей, оставшихся без попечения родителей. В рамках управления специализированным жилищным фондом должна быть обеспечена возможность ведения следующих типов договоров: 1. Договор найма служебного жилого помещения. 2. Договор найма жилого помещения маневренного фонда. 3. Договор найма жилого помещения для детей сирот и детей, оставшихся без попечения родителей, лиц из числа детей сирот и детей, оставшихся без попечения родителей далее (дети-сироты). 4. Договор найма жилого помещения в домах системы социального обслуживания населения. 5. Договор найма жилого помещения для социальной защиты отдельных категорий граждан. 6. Договор найма жилого помещения жилищного фонда для коммерческого использования с условием последующего выкупа жилого помещения Индивидуальные ставки пени и процентов (1) Индивидуальные ставки пени и процеВ Системе должна быть предусмотрена возможность ведения индивидуальных ставок пени для каждого договора с указанием периода действия индивидуальной ставки, а также документа-основания. Средства настройки индивидуальной ставки пени должны предусматривать возможность дополнительной настройки следующих параметров: 1. Возможность указания конкретной величины ставки (в процентах или абсолютных единицах) или указание на ставку со значениями, задаваемыми справочником (например, ставка рефинансирования, ключевая ставка, среднебанковская ставка для вкладов физических лиц). 2. Доля ставки (знаменатель при указании ставки в виде простой дроби). 3. Количество знаков после запятой при расчете величины ставки в абсолютных единицах (по умолчанию – максимально возможное). 4. Признак необходимости расчета пени по методике равного количества дней в месяце (30 дней в месяце, 360 дней в году). 5. Признак необходимости расчета процентов за пользование чужими денежными средствами вместо пени. 6. Признак «плавающей» ставки пени в периоде расчета («Плавающая» или фиксированная на день исполнения денежных обязательств или их части). В периоде действия индивидуальных ставок пени расчет пени по договору производится по общей методике, в противном случае – по технологии, определенной по умолчанию для данного вида договора и/или схеме начисления. Аналогично должна быть реализована возможность для ведения индивидуальных ставок процентов за пользование чужими денежными средствами. По умолчанию должна применяться методика, соответствующая 395 статье Гражданского кодекса РФ (с учетом всех редакций данной статьи, распространяющих действия до следующего внесения изменений в статью) Индивидуальные ставки пени и процентов (2) Средства настройки индивидуальной ставки процентов должны предусматривать возможность дополнительной настройки следующих параметров: 1. Возможность указания конкретной величины ставки (в процентах или абсолютных единицах) или указание на ставку со значениями, задаваемыми справочником (например, ставка рефинансирования, ключевая ставка, среднебанковская ставка для вкладов физических лиц); 2. Доля ставки (знаменатель при указании ставки в виде простой дроби); 3. Количество знаков после запятой при расчете величины ставки в абсолютных единицах (по умолчанию – максимально возможное). 4. Признак необходимости расчета пени по методике равного количества дней в месяце (30 дней в месяце, 360 дней в году). 5. Признак необходимости расчета пени вместо процентов за пользование чужими денежными средствами. 6. Признак «плавающей» ставки процентов в периоде расчета («Плавающая» или фиксированная на день исполнения денежных обязательств или их части). В периоде действия индивидуальных ставок пени расчет пени по договору производится по общей методике, в противном случае – по технологии, определенной по умолчанию для данного вида договора и/или схеме начисления. нтов Подсистема «Выкуп с рассрочкой» (1) Подсистема «Выкуп с рассрочкой» необходима для ведения учета договоров выкупа с рассрочкой согласно Федерального закона «Об особенностях отчуждения недвижимого имущества, находящегося в муниципальной собственности субъектов Российской Федерации и арендуемого субъектами малого и среднего предпринимательства, и о внесении изменений в отдельные законодательные акты Российской Федерации» от 22.07.2008 N 159ФЗ (с изменениями от 08.06.2020). Данная подсистема должна включать в себя как весь функционал подсистемы «Подсистема ведения договоров и дополнительных соглашений», так и специфические особенности учета договоров выкупа с рассрочкой: 1. Подсистема должна иметь возможность настройки графика платежей. Для этого необходимо указать цену выкупа объекта, количество месяцев рассрочки, сумму и дату первого взноса. После проведения настройки должна иметься возможность формирования первоначального графика платежей. Должна иметься возможность смещать график платежей на любое количество периодов (как в будущее, так и в прошлое, как первый, так и последующие календарные периоды). Ставка рефинансирования (ключевая ставка) должна определяться автоматически на дату подписания договора, при расчете начисления процентов данная ставка делится на 3. Начисления основного долга и процентов должны соответствовать дифференцированной схеме (не аннуитет). 2. При распределении платежей на договор в первую очередь должна погашаться задолженность по процентам, а оставшаяся сумма платежа покрывает задолженность по основному долгу. Данные суммы вычисляются системой автоматически. При этом после каждого распределения платежей сумма последующих начислений процентов пересчитывается автоматически. 3. Должны иметься гибкие возможности настройки данной подсистемы, в том числе: 3.1. Начисление должны производиться одной суммой или с разбивкой на основной платеж и проценты. 3.2. Начисление пени должны производиться только на основной платеж или как на основной платеж, так и на проценты Подсистема «Выкуп с рассрочкой» (2) 3.3. Ставку рефинансирования и график начисления платежей должна иметься возможность учитывать с даты начала договора, даты подписания договора, даты публикации договора, даты договора, с указанием конкретной даты вручную. 3.4. Начисление процентов производить на первоначальный взнос или не производить. 3.5. Платеж в первую очередь должен погашать пеню, потом процент, потом основной долг (либо в первую очередь на процент, а оставшуюся сумма платежа – на основной долг) «Финансово-аналитическая подсистема» (1) «Финансово-аналитическая подсистема» является ключевой с точки зрения определения и повышения эффективности неналоговых поступлений от использования муниципальной собственности. Подсистема должна обеспечивать широкие возможности точной настройки на все нюансы федерального, регионального и местного законодательства, особенностей технологии управления имущественно-земельным комплексом, принятым в соответствующих органах управления собственностью и земельными ресурсами региона и государственных образований на территории региона. «Финансово-аналитическая подсистема» должна обеспечивать автоматизацию выполнения следующих основных задач: 1. Управление финансово-аналитической информацией (начислениями всех типов, платежами, задолженностью) в разрезах договоров, кодов бюджетной классификации (аналитических уровней), видов договоров, субъектов. 2. Автоматическое формирование начислений по договору возмездного и безвозмездного пользования, платы за фактическое использование, льготной арендной платы, платы за выкуп. Система автоматически должна определять, какой из видов начисления необходимо произвести в соответствии с условиями договорных соглашений (с учетом всех доп. соглашений и других корректировок), норм Гражданского Кодекса, в тех периодах использования объектов, которые не регулируются договором (в том числе фактическое использование объектов без договора, до заключения договора, в периоде до регистрации договора, после расторжения договора до даты освобождения объекта). 3. Автоматическое начисление пени, процентов, других штрафных санкций за пользование чужими денежными средствами. Система автоматически должна определять вид начисления (штрафных санкций) исходя из условий договора или руководствуясь нормами гражданского Кодекса в периоде фактического использования объекта. 4. Автоматическое доначисление по доп. соглашениям, изменяющим условия договора «задним числом». 5. Автоматический расчет сальдо «Финансово-аналитическая подсистема» (2) 6. Автоматический перерасчет планируемой платы по договору (например, в ходе массовой индексации по уровню инфляции). 7. Импорт платежей из электронных источников (выгрузка из СУФД и др.). 8. Автоматическое, полуавтоматическое и ручное распределение и перераспределение поступлений по субъектам договоров, договорам, видам начислений. 9. Формирование информации о задолженности в любом разрезе и на произвольную дату. 10. Формирование информации о динамике возникновения задолженности. 11. Управление начислениями по решению суда, автоматизация работы с реструктуризацией задолженности. 12. Ведение протоколов выполнения автоматических операций, возможности по эвристическому анализу информационного фонда на предмет корректности исходной информации для выполнения автоматических операций. 13. Автоматизация работы с должниками. 14. Формирование необходимых печатных форм (в том числе справки о наличии/отсутствии задолженности, формирование претензий, исковых требований, детализации всех видов начислений для суда, формирование актов сверки). 15. Формирование необходимой аналитической отчетности «Финансово-аналитическая подсистема» (3) 16. Организация массовой рассылки уведомлений о необходимости погашения задолженности, об изменении условий договора, величины планируемой платы по договору. 17. Проведение экспресс-аналитики. Помимо стандартных функций по управлению финансово-аналитической информацией, в подсистему должен быть включен ряд функций и возможностей, направленных на дополнительное расширение возможностей подсистемы как в части расширения функционала, так и в части настройки технологии учета под особенности внутреннего регламента по управлению финансово-аналитической информацией, технологии учета, особенности местного и регионального законодательства Настройка уровня аналитического учета (1) В Системе должна быть предусмотрена возможность индивидуальной настройки уровня аналитического учета платежей и начислений за аренду этих объектов. 1. Учет платежей и начислений должен вестись как в разрезе субъектов договоров (арендаторы), плательщиков (оплата 3-ми лицами), так и по договорам (аренда, выкуп, неосновательное обогащение, учет и т.д.). Платежи распределяются как по субъектам договоров (арендаторы), так и по договорам (аренда, выкуп, неосновательное обогащение, учет и т.д.). Пени и другие штрафные санкции и сальдо рассчитываются также в разрезе субъектов и по договорам аренды. Возможно применение смешанной технологии учета, в которой основная технология выбрана в разрезе субъектов договоров (арендаторы), но для части договоров учет ведется в разрезе договоров. 2. Возможно ведение технологии учета в разрезе КБК (кодов бюджетной классификации). При таком ведении учета пени и сальдо рассчитываются индивидуально для каждого кода бюджетной классификации. Данный аналитический уровень может быть применен как при ведении учета в разрезе арендаторов, так и при ведении учета в разрезе договоров. 3. Ведение библиотеки алгоритмов выполнения автоматических операций. 4. Ведение библиотеки схем начисления арендной платы и сроков оплаты Настройка уровня аналитического учета (2) 5. Библиотека схем начисления должна предоставлять следующие возможности: 6. Создание произвольного количества схем начисления. Под схемой начисления подразумевается алгоритм выполнения начисления, периодичностью (квартал, месяц, полугодие, набор месяцев) и сроки начисления. 7. Возможность создания и настройки произвольного количества периодичностей начисления (например, помесячное начисление, поквартальное, 2 раза в год для сельхоз. земель, 2 раза в год для других земель). При этом для каждой периодичности может быть указано произвольное количество периодов произвольной длительности. Для каждого периода индивидуальное указание произвольного срока оплаты. 8. Для каждого договора аренды указание индивидуальной схемы начисления из библиотеки (схема по умолчанию также должна настраиваться) Расширение функциональных и аналитических возможностей блока (1) В Системе должна быть реализована функция определения задолженности в любом разрезе. При этом функция должна рассчитать задолженность по состоянию на любую заданную дату как по базе целиком, так и по любому из перечисленных аналитических уровней (или их произвольному сочетанию): 1. Вычисление задолженности по договорам определенного типа (аренда, купля/продажа земельных участков, недвижимого, движимого имущества, объектов наружной рекламы, имущественных комплексов) или по всем типам. 2. Вычисление общей задолженности по субъекту договора или по всем субъектам. 3. Вычисление задолженности по договору или всем договорам. 4. Вычисление общей задолженности по определенному виду начисления или по всем видам. 5. Вычисление общей задолженности по определенному КБК или по всем КБК 6. В Системе должны быть предусмотрены следующие возможности: 7. Возможность запуска операции автоматического начисления арендной платы по диапазону периодов, годов. 8. Протоколирование выполнения всех автоматических операций и эвристический анализ состояния информационного фонда на поиск ошибок и потенциальных ошибок. 9. Выполнение любой автоматической операции должно сопровождаться формированием подробного протокола выполнения операции, в который в текстовом, понятном пользователю виде заносятся все операции, которые были произведены системой со всеми объектами учета. Расширение функциональных и аналитических возможностей блока (2) Одновременно, система должна выполнять комплекс эвристических проверок состояния информационного фонда системы на поиск ошибок или потенциальных ошибок, которые потенциально могут повлиять на корректность полученного результата. 10. Протоколы выполнения всех автоматических операций должны хранится в базе на постоянной основе и быть доступны для анализа в любой момент времени (возможность постанализа результатов выполнения операции). 11. Автоматический расчет и отображение «горячих итогов» (автовычисляемая и отображаемая на экране задолженность по заданным видам начисления (настраивается) по состоянию на текущую дату) по каждому субъекту (всем договорам субъекта общей суммой) и/или договору. В автоматическом режиме Система должна рассчитывать и отображать следующие данные: 1. Задолженность по арендной плате/плате за выкуп по состоянию на текущее число. 2. Задолженность по пене по состоянию на текущее число. 3. Общая задолженность (по всем видам начисления) по состоянию на текущее число. 4. Текущая пеня (сумма пени, рассчитанная на текущий момент). 5. Всего начислено с начала года. 6. Текущая сумма планируемой арендной платы/платы за выкуп. Поля «горячих» итогов должны поддерживать настройку на отображение итогов по любому виду начисления (глобальная настройка по Системе целиком). Должна быть предусмотрена возможность настройки не менее 10 показателей «горячих итогов» Подсистема «Автоматизация претензионной и исковой деятельности» (1) Подсистема должна автоматизировать выполнение следующих основных задач: 1. Ведение полной информации по претензиям и исковым процессам, по требованиям, предъявленным к пользователям Системы и по имуществу пользователям Системы: 1.1. Договор или иной документ, на основании которого ведется претензионно-исковая деятельность. 1.2. Претензия, иск стороны для требований, предъявленных к пользователям Системы по имуществу. 1.3. Субъект (заявитель) претензии. 1.4. Объект. 1.5. Предмет претензионно-исковых требований: 1.6. требования имущественного характера (сумма к взысканию по различным видам начислений); 1.7. требований имущественного характера, не подлежащего оценке; 1.8. требования неимущественного характера. 2. Возможность формировать печатные формы претензий и исковых заявлений автоматически на основе данных из учетной системы. 3. Стороны (участники) иска, категория (вид) иска, признак особой важности. 4. Состояние иска (подготовка, в процессе, завершен). 5. Учет судебных дел и претензионно-исковых этапов: претензия, подготовка иска, подача иска, наименование суда, номер судебного дела, судья, инстанция (апелляция, кассация, в порядке надзора), дата и время судебного заседания, сотрудник правового отдела – исполнитель, судебные акты по делу (решения, определения о приостановлении производства по делу, об оставлении иска без рассмотрения, об оставлении иска без движения, о возвращении искового заявления, о прекращении производства по делу, о принятии к производству встречного иска, о принятии (отмене) мер по обеспечению иска) Подсистема «Автоматизация претензионной и исковой деятельности» (2) 6. Учет исполнительного производства: дата вступления судебного акта в законную силу, дата получения исполнительного листа, дата направления исполнительного листа в отдел судебных приставов, отдел судебных приставов, судебный пристав исполнитель, постановления пристава исполнителя. 7. Учет конкурсного производства: суд, номер дела, дата введения процедур в отношении предприятия банкрота (определения суда), сведения о ходе процедур банкротства. 8. Возможность формирования отчета о сроках (длительности) претензионной работы, подготовки и подачи иска, рассмотрения дела в суде, исполнительного производства, конкурсного производства. 9. Возможность поиска судебных дел по различным критериям. 10. Наличие ссылки на страницу дела на сайте kad.arbitr.ru. 11. Возможность прикрепления файлов материалов к судебному делу (претензий, исков, судебных актов), к исполнительному производству (исполнительный лист, заявление о направлении исполнительного листа, постановления приставов-исполнителей), к конкурсному производству (судебные акты дела о банкротстве, извещения о проведении собраний кредиторов). 12. Формирование отчетов: о претензионной и исковой деятельности организации (количестве претензий, исков, судебных дел по различным критериям и заданным периодам), о сумме предъявленных и взысканных средствах в заданные периоды, в отношении различных субъектов и объектов; о количестве исполнительных и конкурсных производств по субъектам и объектам, суммам взысканных средств, заданным периодам. 13. Возможность сотруднику самостоятельно конструировать отчет, добавлять новые поля к карточкам судебных дел Подсистема «Автоматизация претензионной и исковой деятельности» (3) 14. Контроль за ходом иска в разрезе исполнителя, уведомление исполнителя о необходимости завершения текущего искового этапа и перехода к следующему. 15. Формирование графика судебных дел на каждого исполнителя и на правовой отдел в целом (ежедневник, еженедельник, ежемесячник) с возможностью размещения дополнительных сведений в графике о планируемой работе сотрудника. 16. Предусмотреть экспорт данных в табличный формат (xlsx, csv). Возможность формирования необходимых печатных форм (с использованием встроенных генераторов отчетов). 17. Предусмотреть разграничение прав доступа. 18. Постановка и контроль исполнения задач/поручений сотрудниками правового отдела. 19. Формирование статистики выигранных/проигранных судебных дел, отслеживание текущей загрузки сотрудников, анализ эффективности претензионной и исковой деятельности. 20. Протоколирование результатов расчета пени на расчетную дату. 21. Протоколирование результатов расчета задолженности по всем видам операций на расчетную дату, для возможности отслеживания изменений и анализа их причин Аналитическая и сервисная подсистема «Библиотека запросов» (1) Средства подсистемы должны предоставлять возможность для проведения оперативных выборок и для выполнения запросов по индивидуальному или массовому изменению, добавлению, удалению информации в банке данных Системы, например, в ходе обслуживания информационного фонда. Подсистема должна предоставлять средства оперативного построения, накопления и выполнения запросов произвольной сложности и произвольного содержания к единому информационному фонду Системы. Средства подсистемы должны быть максимально интуитивны и просты в использовании, выполнение запросов не требует каких-либо специальных знаний и навыков от пользователей. Количество запросов, которые могут быть добавлены в подсистему, должно быть не ограничено. Добавление запросов в подсистему должно выполняться средствами подсистемы, не требовать обновления Системы или ее компонентов, привлечения разработчиков Системы. Запросы могут содержать произвольное количество параметров любых типов (даты, числа, строки, данные из любых справочников и классификаторов Системы), фактические значения которых указываются пользователем в момент выполнения выбранного запроса, что в значительной степени повышает оперативность и точность получения данных в результате выполнения запроса. Должна быть предусмотрена возможность непосредственно из результатов выполнения запроса открыть электронную карточку объекта, по которому содержится информация в соответствующей строчке результатов выполнения запроса. Подсистема должна предоставлять возможность дополнительного постанализа данных (анализ после получения результата выполнения запроса в табличном виде), полученных в результате выполнения запроса: Аналитическая и сервисная подсистема «Библиотека запросов» (2) 1. Группировка данных по одному или нескольким полям, что в значительной степени может повысить информативность полученных данных. Например, данные по должникам можно сгруппировать по району плательщика, кодам бюджетной классификации и видам начислений. 2. Вычисление общих итогов, в том числе для каждой из групп (в случае применения группировки). Например, для приведенного примера возможна автоматическая калькуляция общей задолженности арендаторов, а также задолженности по каждому из районов, коду бюджетной классификации и виду начисления. 3. Дополнительная оперативная фильтрация данных по значениям любого поля\совокупности полей. 4. Сортировка данных по произвольному полю\совокупности полей. Должна быть предусмотрена возможность экспорта сформированных данных в табличные форматы (xlsx, csv), текстового файла, xml или внутренние форматы генератора отчетов. При этом должна быть обеспечена возможность экспорта данных, в том чисел в формат xml сложной структуры с учетом всех сортировок, группировок, итогов и прочего форматирования, которые были наложены на результат запроса в окне результата запроса. В случае содержания в результатах запроса сведений об объектах учета единого банка данных Системы должен быть реализован быстрый доступ (двойной «щелчок мыши») к карточкам соответствующих объектов учета. Средства подсистемы должны предоставлять возможность администратору Системы мониторинга состояния информационного фонда Системы, анализа целостности, непротиворечивости данных, регулярного обслуживания банка данных. Средства подсистемы должны предоставлять возможность не только для проведения оперативных выборок, но и для выполнения запросов по индивидуальному или массовому изменению, добавлению, удалению информации в банке данных системы, например, в ходе обслуживания информационного фонда Подсистема «Формирование отчетов и печатных форм, генератор отчетов» Подсистема должна предоставлять возможность формирования выходных данных системы – от простейших печатных карточек объектов учета до аналитических отчетов, выборок, прогнозов произвольной сложности по состоянию на произвольную дату в пределах информационного фонда Системы. Подсистема не должна содержать ограничений на количество шаблонов отчетов и печатных форм. В состав подсистемы должен входить генератор отчетов «FastReport» или эквивалент с помощью которого можно самостоятельно разрабатывать и подключать к Системе отчеты и печатные формы произвольной сложности, а также производить экспресс-изменения подключенных шаблонов. Кроме того, подсистема должна обладать возможностью подключения шаблонов отчетов и печатных форм, разработанных с помощью MS Word, MS Excel и OpenOffice (LibreOffice) или эквивалент с использованием API и VBA (или эквивалент). Подсистема должна обеспечить формирование произвольного количества отчетов и печатных форм любой сложности в рамках информационного фонда Системы. Для каждой печатной формы должна быть предусмотрена возможность выполнения произвольных действий (алгоритмов), выполняемых до и после формирования печатной формы. Должна быть предусмотрена библиотека соответствующих алгоритмов с возможностью выбора ранее разработанного алгоритма для любой печатной формы любому пользователю, не обладающему какими-либо специальными знаниями. Например, должна быть предусмотрена возможность автоматического внесения информации о сформированном акте сверки в перечень документов по договору аренды с автоматическим присвоением номера и даты формируемому акту сверки по алгоритмам произвольной сложности. Если соответствующие действия предусмотрены, они должны выполняться после дополнительного подтверждения пользователем, формирующим соответствующую печатную форму. Должна быть предусмотрена возможность добавления, изменения или удаления отчетов и печатных форм силами обученных пользователей Системы без необходимости обновления Системы или ее компонентов Средства ведения журналов сформированных документов (печатных форм) В подсистеме формирования отчетов и печатных форм должна быть предусмотрена возможность реализации средств сохранения информации о формировании соответствующей печатной формы с привязкой к электронной карточке объектов учета, а также фиксированием информации о времени формирования и пользователе, который выполнял формирование. Кроме того, должна быть предусмотрена возможность вывода журналов сформированных ранее печатных форм заданного типа в заданный промежуток времени. Например, средствами системы должна быть предусмотрена возможность формирования журнала выданных за период выписок из реестра муниципального имущества по заданным критериям. Кроме того, должна быть предусмотрена возможность по необходимости добавления в печатную форму признака необходимости включения факта формирования печатной формы в журнал. Например, если выписка из реестра формируется не с целью оказания соответствующей государственной услуги, то факт формирования выписки в журнале не должен быть учтен. Должна быть предусмотрена возможность добавления, изменения или удаления отчетов и печатных форм силами специалистов Системы без необходимости обновления Системы или ее компонентов. Должна быть предусмотрена возможность реализации описанных функций силами обученных специалистов Системы без необходимости обновления Системы или ее компонентов Подсистема «Обеспечение безопасности, администрирования и разграничения прав доступа» (1) Подсистема должна: 1. Обеспечивать возможности индивидуальной настройки для каждого пользователя базовых ограничений прав и разрешений с возможностью дальнейшего расширения. 2. Возможности индивидуального ограничения просмотра реестра объектов любого из типов. 3. Возможности индивидуального ограничения просмотра данных карточек объектов учета любых типов. Предоставление прав на частичный просмотр информации по объекту (например, запрет на просмотр экономических показателей объекта, но разрешение на просмотр технических показателей). 4. Возможности ограничения доступа к персональным данным, требующим отдельной защиты. 5. Возможности индивидуального ограничения изменения данных по объектам учета всех типов. Предоставление прав на частичное изменение информации. 6. «Горизонтальное» ограничение прав на изменение множественных атрибутов объектов учета (например, пользователю предоставляются права на изменение/внесение в карточку объектов документов определенной направленности и закрываются права на правку документов иной направленности (например, реестровых документов)). 7. Ограничение прав на выполнение различных операций с объектом учета (выделение подобъектов, включение в группу). 8. Ограничение на операции с печатными формами (просмотр и печать отчетов и печатных форм, экспорт во внешние форматы (docx, xlsx), редактирование сформированных отчетов). Для печатных форм права должны назначаться индивидуально для каждого типа объектов учета, для аналитических отчетов – индивидуально для каждой темы отчета. 9. Ограничение прав на работу с блоками начислений и платежей за аренду недвижимости и ЗУ (индивидуально на все функции, выполнение операций в каждом из режимов (индивидуальном, массовом)) Подсистема «Обеспечение безопасности, администрирования и разграничения прав доступа» (2) 10. Ограничение прав на работу с универсальной библиотекой запросов – права предоставляются индивидуально для каждой темы запросов и на выполнение операций блока запросов (выполнение запроса, экспорт результатов). 11. Ограничение прав на работу с НСИ (права предоставляются индивидуально для каждого справочника или классификатора). 12. Ограничение права на настройки системы (индивидуально на каждый блок настроек). Все права и разрешения на работу с объектами учета всех типов должны предоставляться индивидуально для каждой стадии формирования объекта учета (заявка, новый, актуальный (реестровый), актуальный зарегистрированный (в Росреестре), архивный, справочный, внереестровый или объект налогового потенциала). В Системе должны присутствовать средства объединения пользователей в группы (причем, каждый пользователь может быть включен в одну и иное количество групп) с автоматическим наследованием всех прав и разрешений групп, в которые включен пользователь. В Системе должны быть реализованы особые механизмы хранения и проверки паролей, обеспечивающие повышенную безопасность. При установке и смене пароля, новый пароль кодируется необратимыми алгоритмами (без возможности восстановления исходного пароля) Разграничение прав пользователей единого информационного пространства Для каждого пользователя или группы пользователей должна быть предусмотрена возможность управления правами доступа (в объеме, описанном выше) индивидуально для каждого из информационных фондов организаций-участников, составляющих единую базу данных Системы. В совокупности с возможностью сопоставления пользователей с соответствующими информационными фондами, а также автоматической идентификации принадлежности объектов учета к соответствующим информационным фондам, должен достигаться максимальный уровень защищенности информационных фондов от несанкционированного доступа (как на просмотр, так и на корректировку информационного фонда) Подсистема «Ведение нормативно-справочной информации» Подсистема должна обеспечивает функционирование необходимого для эффективной работы Системы набора справочников и классификаторов. Помимо федеральных справочников и классификаторов, а также справочников и классификаторов, формируемых в процессе поставки Системы, в состав Системы должен быть включен ряд дополнительных справочников, направленных на: 1. Повышение аналитических возможностей Системы. 2. Повышение возможностей Системы по расширению перечня учитываемых показателей. 3. Повышения адаптивности Системы к изменению законодательства, технологии учета, обеспечения быстрой настройки Системы под все нюансы работы органов управления имущественно-земельным комплексом. В Системе должна быть возможность доступа к справочникам и классификаторам непосредственно в ходе редактирования параметра с выбором из справочника с целью выполнения расширенного поиска, а по необходимости и внесения изменений в классификатор. Должна быть реализована возможность «привязки» как самих классификаторов, так и элементов классификации к видам реестров. Классификаторы и элементы классификации должно быть возможно выбрать только в тех реестрах, в которых это разрешено настройками Системы Подсистема «Автоматическое обновление клиентских рабочих мест» (1) Подсистема «Автоматическое обновление клиентских рабочих мест» (далее – Подсистема автообновления) предназначена для облегчения работы по обслуживанию клиентских рабочих мест Системы или компонентов, библиотек, включая общесистемные компоненты и библиотеки, необходимые для функционирования клиентского рабочего места. Подсистема автообновления предназначена для автоматического обновления файлов клиентских мест Системы или других компонентов, необходимых для функционирования. Система автообновления должна быть построена по клиент-серверной архитектуре, обновления должны распространятся по сети с использованием протокола TCP/IP. Подсистема автообновления должна состоять из следующих компонентов (программ): 1. «Служба обновления» – серверная часть подсистемы автообновления, устанавливаемая на компьютере – сервере. 2. «Конфигуратор службы обновления» – утилита по настройке службы обновления. 3. «Клиент обновления» – клиентская часть подсистемы автообновления, устанавливаемая на компьютере пользователя Подсистема «Автоматическое обновление клиентских рабочих мест» (2) Подсистема автообновления должна обладать следующим функционалом: 1. Автоматическое обновление клиентов обновлений на компьютерах пользователей при установке новой версии системы обновлений. Служба должна предоставлять клиентским местам Системы актуальную версию клиента обновлений. Для каждой новой версии клиента обновлений должен генерироваться уникальный идентификатор обновления. 2. Автоматическое обновление клиентских мест Системы на компьютерах пользователей при наличии обновлений программы. Служба должна предоставлять клиентским местам Системы актуальные версии файлов программы. Для каждой новой версии программы должен генерироваться уникальный идентификатор обновления. 3. Автоматическое восстановление отсутствующих файлов клиентских мест Системы на компьютерах пользователей. 4. При обновлении клиентских мест должна поддерживаться работа со списком исключений для удаления с клиентских мест устаревших файлов и папок. 5. Возможность обновления клиентских мест Системы из нескольких источников. Количество источников не должно быть ограничено. Для каждого источника должна быть предусмотрена возможность задать имя, путь к папке с файлами обновлений, а также путь к файлу со списком исключений. 6. Возможность сжатия пересылаемых по сети пакетов для уменьшения нагрузки на сеть. Активация данного функционала должна происходить по решению администратора. 7. Возможность контроля целостности пересылаемых по сети пакетов для предотвращения модификации пересылаемых файлов сторонним ПО, вирусами и иными внешними факторами. Файлы должны приходить на компьютеры пользователей в неизменном виде Служба обновления Серверная часть подсистемы автообновления должна быть представлена в виде службы ОС (далее – Служба). Служба должна отвечать на запросы «Клиентов обновления» (далее – Клиентов), предоставляя им всю необходимую информацию об обновлениях, а также сами обновления. Должна быть предусмотрена возможность запустить Службу как вручную, так и с помощью конфигуратора службы. Также Служба должна запускаться автоматически при включении компьютера и не требовать входа в Систему под учетной записью какого-либо пользователя. Служба обновления должна применять новые настройки конфигурации автоматически, без необходимости перезапуска. Служба обновления должна автоматически отслеживать наличие новой версии клиента обновлений, а также отслеживать любые изменения в папках источников обновлений. При наличии новой версии клиента обновлений служба должна сгенерировать уникальный идентификатор обновления. Этот идентификатор должен передаваться клиентам обновления на клиентских местах при их подключении к службе обновлений. При наличии изменений в папках источников обновлений служба должна сгенерировать уникальный идентификатор обновления индивидуально для каждого источника обновлений. Этот идентификатор должен передаваться клиентам обновления на клиентских местах при их подключении к службе обновлений Конфигуратор службы обновления Для настройки службы обновления должна быть предназначена специальная утилита «Конфигуратор службы обновления» (далее – Конфигуратор). Конфигуратор не должен требовать установки и должен иметь возможность быть запущенным из любого места на компьютере, где установлена служба обновления. При запуске конфигуратор должен проверять наличие установленной службы и в случае её отсутствия, сообщить об этом пользователю. Если Служба установлена, то должно открываться окно Конфигуратора, на котором должны быть представлены текущие настройки Службы. Конфигуратор должен обладать следующим функционалом по настройке службы обновления: 1. Отслеживать текущее состояние Службы. 2. Иметь средства для остановки, запуска и перезапуска службы обновления. 3. Позволять указывать местоположение актуальной версии клиента обновления (которая совместима со службой обновления). 4. Позволять управлять (активация/деактивация) опцией по сжатию пакетов, передаваемых по сети (для уменьшения нагрузки на сеть). 5. Позволять управлять (активация/деактивация) опцией по контролю целостности пакетов, передаваемых по сети (для предотвращения модификации содержимого пакетов внешними факторами). 6. Позволять добавлять новые источники обновлений (без ограничения по их количеству). 7. Позволять редактировать сведения об источниках обновлений. В частности, настраивать следующие параметры: 8. Задавать имя источника обновлений. 9. Указывать путь к папке с файлами обновлений. 10. Указывать путь к файлу исключений Клиент обновлений (1) Клиентская часть подсистемы автообновления должна быть представлена в виде отдельной программы – клиента обновления. Клиент обновления должен быть предназначен для соединения со службой обновления, расположенной на другом или текущем компьютере, и получения от неё актуальной версии файлов обновляемой программы, а также актуальной версии самого клиента обновления. Клиент обновления не должен требовать специальной установки и может быть запущен из любого места. Клиент обновления должен обладать возможностью запуска в двух режимах: 1. «Режим настройки» - в этом режиме должно открываться окно настройки клиента обновления. 2. «Режим обновления» - в этом режиме программа должна выполнять соединение с сервером обновлений, согласно выполненной настройке, и получать от сервера обновлений актуальные версии файлов обновляемой программы и самого клиента. Клиент обновления в «режиме настройки» должен предоставлять возможность задавать следующие настройки: 1. Настройки подключения к службе обновлений (IP-адрес или имя компьютера, на котором установлена служба обновлений, порт служба обновлений). Для проверки корректности настройки должна быть предусмотрена кнопка для тестирования соединения. 2. В случае необходимости подключения к серверу через прокси-сервер, должна быть возможность в соответствующей группе настроек указать IP-адрес прокси-сервера, порт подключения к прокси-серверу, а также логин и пароль для авторизации на прокси-сервере (при необходимости). 3. Источник обновления. Выбор источника обновлений должен осуществляться из выпадающего списка, а котором должны присутствовать все доступные источники обновлений. 4. Путь к временной папке, в которую будут загружаться обновления перед их применением. 5. Путь к папке, в которую необходимо сохранить загруженные обновления. 6. Путь к файлу программы, которую необходимо запустить после обновления. Должна присутствовать возможность настроить запрет запуска нескольких экземпляров Клиент обновлений (2) 7. Индивидуальная для клиентского места настройка сжатия пакетов, передаваемых по сети. 8. Индивидуальная для клиентского места настройка контроля целостности пакетов, передаваемых по сети. 9. Настройка протоколирования процесса обновления. Если ip-адрес и имя сервера обновления неизвестны, то должна быть реализована возможность автоматического поиска сервера в локальной сети. Для автоматического поиска сервера должна присутствовать кнопка «Поиск сервера». После успешного поиска, настройки подключения должны быть установлены автоматически, и пользователю должно быть показано соответствующее уведомление. Клиент обновления в «режиме обновления» должен осуществлять следующие действия: 1. Проверять наличие новой версии клиента обновления. Для этого клиент обновления должен получить текущий идентификатор обновления клиента и сравнить с ранее сохраненным идентификатором. Если идентификаторы различаются, то клиент обновления должен произвести самообновление с сохранением текущего идентификатора обновления. 2. Проверить наличие обновлений клиентского места Системы. Для этого клиент обновления должен получить текущий идентификатор обновления клиентского места и сравнить с ранее сохраненным идентификатором. Если идентификаторы различаются, то клиент обновления должен произвести загрузку измененных и новых файлов с сохранением текущего идентификатора обновления. При загрузке обновлений должны загружаться только новые и изменение файлы (сверяться контрольные суммы файлов (CRC)) Клиент обновлений (3) 3. При отсутствии обновлений клиентского места Системы клиент обновления должен проверить наличие отсутствующих файлов клиентского места Системы и при необходимости восстановить их. 4. По завершению работы клиент обновления должен произвести обработку файла исключений. Для этого клиент обновления должен получить содержимое файла исключений и удалить файлы и папки, согласно полученного списка. Процесс обновления должен отображаться в виде окна, на котором должны быть размещены следующие элементы: 1. Текст сообщения с описанием текущего этапа обновления. 2. Индикатор прогресса обновления. Клиент обновления должен поддерживать возможность протоколирования процесса обновления в текстовом файле, который должен автоматически создаваться в папке клиента обновления Подсистема «Оповещение пользователей» (1) Подсистема «Оповещение пользователей» создается с целью ускорения установки и настройки и дальнейшего облегчения работы по обслуживанию клиентских рабочих мест Системы. Подсистема оповещения пользователей предназначена для выполнения следующих задач: 1. Автоматизация отключения пользователей от Системы для проведения работ по техническому обслуживанию. 2. Информирование пользователей путем отсылки им текстовых сообщений. Подсистема оповещения должна быть доступна из главного меню клиента Системы и из главного меню сервера приложений, в случае если сервер приложений не запущен в режиме службы. Подсистема оповещения пользователей должна обеспечивать следующие возможности: 1. Направить подключенным пользователям (подключенным клиентским приложениям) текстовое сообщение о проведении технических работ, требующих отключения клиентских приложений от Системы. Для данного типа сообщений должна быть предусмотрена возможность указания времени (в минутах), по истечении которого клиентские приложения должны быть автоматически отключены от Системы. Данное сообщение посылается всем подключенным клиентским приложениям и должно сопровождаться отображением счетчика обратного отсчета до автоматического отключения клиентского места. Сообщение должно отображаться поверх всех окон клиентского приложения Подсистема «Оповещение пользователей» (2) 2. Автоматически завершить работу всех подключенных клиентских приложений по истечении заданного времени. 3. Формировать простые текстовые сообщения подключенным пользователям Системы. 4. Формировать текстовые сообщения всем пользователям Системы (не подключенные на момент формирования сообщения пользователи получат сообщение в момент следующего подключения). Пользователь должен получить сообщение только один раз вне зависимости от компьютера, на котором запущено клиентское приложение (в отличие от сообщений об автоматическом отключении клиентских приложений, простые текстовые сообщения должны отправляться не каждому клиентскому приложению, а пользователю, который был указан при подключении к клиентскому приложению. 5. Отзыв направленного ранее сообщения об отключении клиентских приложений. Автоматическое отключение клиентских приложений должно быть отменено, сообщение об отключении и таймер обратного отсчета на всех клиентских приложениях должны быть закрыты, должна быть возобновлена возможность подключения клиентских приложений. 6. Ведение журнала всех отправленных сообщений. 7. Ведение журнала получения сообщений пользователями Типы оповещений пользователей Для оповещения должна быть предоставлена возможность выбора типа оповещения. Должна быть реализована возможность выбора следующих типов: 1. Оповещение о начале технических работ на сервере, о необходимости выхода из Системы и автоматического отключения клиента. 2. Простое оповещение только подключенным пользователям, автоматического отключения не происходит. 3. Оповещение всем пользователям, подключенным и не подключённым, неподключенные должны получить оповещение при первом входе в Систему Журнал оповещений Должен вестись журнал оповещений, обладающих следующими характеристиками: 1. Для каждого оповещения сохраняется информация с указанием их типа, текста сообщения, даты и времени отправки сообщения, пользователя, сформировавшего сообщения. 2. Журнал оповещений должен обладать средствами поиска сообщений по всем параметрам журнала. Реализованы фильтры по диапазону дат, пользователю, группе пользователей, текстовый поиск. 3. Невозможно удалить произвольное оповещение. 4. Удалить записи журнала о старых оповещениях можно только до указанной даты. Права на удаление записей имеет только администратор. Ведется дополнительный лог по пользователям, прочитавшим оповещение. Просмотр лога так же доступен в интерфейсе просмотра журнала Подсистема «Самодиагностика с автоматическим оповещением о выявленных аномалиях по электронной почте» Подсистема «Самодиагностика с автоматическим оповещением о выявленных аномалиях по электронной почте» должна быть использована в целях улучшения качества работы, уменьшения количества ошибок, уменьшения времени реагирования на появление проблемы. Должен быть сформирован набор тестов, проверяющих состояние работоспособности Системы и ее подсистем, возникновения проблем при взаимодействии Системы с внешними системами, возникновении некорректных данных в информационном фонде. Мониторинг работоспособности должен производиться непрерывно. Мониторинг целостности и непротиворечивости данных должен проверяться при помощи регламентных операций, выполняемых Системой по заданному расписанию (например, в ночное время). Оповещения должны отправляться с использованием механизма очереди оповещений на адреса электронной почты, которые заданы при настройке подсистемы «Самодиагностика с автоматическим оповещением о выявленных аномалиях по электронной почте» Средства ведения электронных карточек объектов учета Под объектом учета понимается любой объект, информация по которому должна быть учтена в едином информационном фонде Системы. Например, объектами учета являются: земельные участки любой формы собственности, а также земельные участки, собственность на которые не разграничена, объекты движимого и недвижимого имущества, субъекты права, документы, договоры, соглашения, претензионные и исковые процессы, финансовые поступления. Для доступа к реквизитам (атрибутам, характеристикам) объекта учета в Системе должна быть предусмотрена отдельная экранная форма. Экранная форма по умолчанию должна открываться в режиме просмотра (возможность редактирования атрибутов объекта отключена) с возможностью переключения в режим редактирования при наличии соответствующих прав и разрешений. Экранная форма доступа к реквизитам объекта должна отображать информацию по объекту учета в соответствии с правами и разрешениями пользователя (не отображать атрибуты объекта, для которых у пользователя отсутствуют права на просмотр). При переключении экранной формы карточки объекта учета в режим редактирования доступ на редактирование должен быть предоставлен только к тем атрибутам объекта учета, на которые активный пользователь имеет права и разрешения на изменение. Остальные атрибуты должны оставаться в режиме просмотра (без возможности внесения изменений) Требования по ведению атрибутов объектов учета Объект учета в обязательном порядке должен содержать следующую информацию: 1. Идентификатор – числовое значение, однозначно идентифицирующее объект учета (не должно существовать любого другого объекта учета, имеющего такой же идентификатор). Идентификатор должен присваиваться Системе автоматически при создании нового объекта. 2. Наименование (описание) объекта – строковое значение, описывающее объект, заполняется вручную, не является обязательным. Объект учета может иметь произвольное количество атрибутов (характеристик). Каждый атрибут должен содержать: 1. Наименование (идентификатор) атрибута – выбирается из соответствующих справочников наименований атрибутов каждого из типов данных. Должен быть предусмотрен инструмент формирования допустимого перечня атрибутов, который может быть указан (выбран) в карточке каждого из типов объектов учета (инструмент индивидуального формирования перечня атрибутов для каждого типа объектов учета). 2. Значение – указывается в зависимости от типа данных атрибута. 3. Период действия – дата начала периода действия атрибута и дата окончания периода действия атрибута. Индивидуально для каждого вида (наименования) атрибута должна быть предусмотрена возможность настройки допустимости пересечения периодов действия значений этого атрибута (множественный ввод значений одноименных атрибутов в один момент времени). 4. Перечень ссылок на документы-основания начала действия значения атрибута – перечень ссылок на информацию о документах с обязательным указанием основного документа-основания. 5. Перечень ссылок на документы-основания окончания действия значения атрибута – перечень ссылок на информацию о документах с обязательным указанием основного документа-основания. Индивидуально для каждого вида (наименования) атрибута должна быть предусмотрена возможность настройки использования документов-оснований окончания действия (используется или нет) Требования по ведению атрибутов объектов учета (2) 6. Примечание – текстовое поле. Система должна обеспечивать возможность создания и ведения атрибутов объектов учета следующих типов данных: 1. Числовой тип (коэффициент). Должна быть предусмотрена возможность установки фиксированного значения величины коэффициента для каждого наименования коэффициента (наименования атрибута соответствующего типа) без возможности индивидуального изменения в карточке объекта учета (константа) или с возможностью индивидуального изменения (в этом случае значение, связанное с наименованием коэффициента, должно устанавливаться как значение по умолчанию с возможностью последующей корректировки индивидуально в карточке конкретного объекта). Такая настройка должна быть предусмотрена индивидуально для каждого вида (наименования) коэффициента. 2. Денежный тип (экономический показатель). 3. Строковый тип (технический, описательный показатель). Для каждого наименования атрибута данного типа должна быть предусмотрена возможность установки маски ввода значения атрибута. 4. Классификационный тип – справочник. Для каждого наименования атрибута (категории классификационных данных) должна быть предусмотрена возможность индивидуальной настройки перечня (справочника) элементов классификатора данной категории. 5. Булевый тип – признак (да/нет). Допустимо отсутствие ведения информации по периоду действия и документам-основаниям. 6. Тип даты – событие. 7. Ссылка на субъект права – с указанием типа субъекта права. 8. Кроме того, в карточку объекта учета дополнительно могут быть загружены: 8.1. Информация по адресу объекта с использованием адресной подсистемы Требования по ведению атрибутов объектов учета (3) 8.2. Произвольное количество файлов любого типа. Файлы могут загружаться как по одному, так и массово путем выделения нескольких файлов в средстве работы с файлами операционной системы (проводнике, менеджере файлов). Должна быть предусмотрена возможность загрузки в карточку объектов файлов путем использования технологии Drag-And-Drop (перетащи и отпусти). Открытие файлов должно производиться непосредственно из Системы путем использования средств операционной системы, назначенных по умолчанию (аналогично открытию файлов проводником или другим менеджером файлов). Хранение прикрепленных файлов объекта учета должно производиться на сервере в базе данных или с использованием других средств, обеспечивающих надежность и скорость работы с файлами не хуже соответствующих инструментов СУБД (транзакционный механизм доступа с возможностью автоматического отката транзакций, завершившихся аварийно, резервное копирование). 8.3. Произвольное количество файлов распространенных графических форматов (jpg, bmp). Функционал аналогичен работе с прикрепленными файлами, дополнительно в Системе должны быть предусмотрены средства предварительного просмотра графических изображений без открытия файлов. 8.4. Информация о произвольном количестве документов: 8.4.1. Направление документа – значение из соответствующего справочника, указывающее на назначение документа в карточке объекта – определяется технологией работы с объектами соответствующего типа. 8.4.2. Номер документа. 8.4.3. Дата документа. 8.4.4. Тип документа – значение из классификатора типов документов. 8.4.5. Источник документа – значение из классификатора источников документов (организация, выпустившая документ) Требования по ведению атрибутов объектов учета (4) 8.4.6. Наименование документа – текстовое описание с возможностью выбора из справочника шаблонов наименований с возможностью последующего индивидуального изменения. 8.4.7. Примечание документа. 8.4.8. Ссылка на прикрепленный файл документа. Сохранение карточки объекта учета (атрибутов, файлов, графических объектов, документов должно производиться на основе транзакционных механизмов, то есть либо вся измененная информация карточки (внесенные в карточку данные) должны успешно сохраниться в базе данных, либо, например, в случае какой-либо ошибки, все изменения в базе данных, выполненные в процессе сохранения, должны быть отменены, и карточка должна вернуться в состояние, предшествующее сохранению. Пользователь должен быть подробно проинформирован Системой о характере возникшей ошибки и, по возможности, Система должна дать рекомендации по способам исправления ошибки. После исправления пользователем причин, приведшим к ошибке, должна быть предусмотрена возможность повторного сохранения внесенных в карточку изменений. Частичное автоматическое внесение изменений в базу данных в процессе внесения изменений в карточку объектов недопустимо Требования к настройке элементов формы карточки объектов Средства работы с атрибутами каждого из доступных типов данных по умолчанию должны содержаться в экранных контейнерах (панелях экранной формы), контейнеры должны быть размещены на вкладках экранной формы. Экранные контейнеры должны представлять собой панели прямоугольной формы, на которой размещаются элементы управления (просмотра, редактирования) атрибутами объектов учета. Для экранных контейнеров должна быть предусмотрена возможность выполнения следующих действий: 1. Изменение размеров контейнера (высота, ширина). 2. Перемещение контейнера по экранной форме, включая перемещение контейнера на другие вкладки (на свободное место экранной формы (не занятое другими элементами управления) имеющем размеры, достаточные для вмещения контейнера). Должна быть предусмотрена возможность для каждого типа объектов учета создания произвольного количества контейнеров с размещением в них произвольного количества логически связанных атрибутов любых типов единым списком. Для каждого атрибута, размещаемого в создаваемом контейнере, должна быть возможность указания признака автоматического добавления атрибута в карточку объекта учета и порядкового номера по умолчанию отображения автоматически добавленных атрибутов в контейнере. Автоматически добавляемые атрибуты должны добавляться в контейнер автоматически с последующим возможным указанием пользователем их значения. Должна быть предусмотрена возможность визуальной индикации в контейнере атрибутов, добавленных автоматически, но значение которых пользователем еще не введены (по факту такие атрибуты для объекта учета еще не определены). Для экранной формы должны быть предусмотрены следующие возможности по работе с вкладками: 1. Добавление вкладок. 2. Изменение наименований вкладок. 3. Изменение порядка следования вкладок. 4. Удаление вкладок, не содержащих элементов управления или контейнеров Требования к настройке меню доступа к объектам учета и работы со списками Система должна содержать в своем составе средства настройки иерархического меню доступа к объектам учета всех типов с учетом возможностей по добавлению новых объектов учета. Доступ к меню доступа к объектам учета должен предоставляться из основного окна Системы. Доступ к каждому пункту меню должен осуществляться за минимальное количество действий пользователя. При возобновлении сеанса работы с Системой (повторном запуске Системы) позиция текущего пункта меню в иерархическом меню должна быть восстановлена автоматически, то есть доступ к объектам учета соответствующего типа должен осуществляться путем использования одного клика мыши. Иерархическое меню должно иметь элементы следующих типов: 1. Промежуточные узлы – нажатие на этот пункт меню должен раскрывать следующий уровень иерархии (отображать вложенные пункты меню). 2. Промежуточные узлы-реестры – нажатие на данный пункт меню должен открыть объединенный список объектов учета, соответствующий совокупности объектов учета всех конечных элементов меню, вложенных с учетом иерархии в данный пункт (узел). Для данного типа пункта меню должна быть возможность открытия вложенных пунктов меню без открытия объединенного реестра. 3. Конечный узел – открывает список объектов учета, соответствующий данному пункту меню. 4. Конечный узел объединенного реестра – открывает объединенный список объектов учета, соответствующий конечным узлам пунктов меню, находящихся на этом же уровне иерархии (имеющих единый промежуточный узел). В меню должна быть предусмотрена возможность добавления пунктов, для которых может быть указан дополнительный фильтр, который автоматически применяется при отображении списка объектов, отображаемых с помощью данного пункта меню Режим добавления объекта по шаблону В Системе должна быть предусмотрена возможность добавления объекта по шаблону на основе любого выбранного пользователем объекта, информация о котором уже содержится в единой базе данных Системы. В режиме добавления объекта по шаблону должна быть создана карточка нового объекта соответствующего типа (как у объекта, на основе которого производится добавление) с полным копированием информации из исходного объекта в карточку добавляемого объекта, за исключением информации, идентифицирующей объект (реестровый номер, инвентарный номер, паспортные данные, ПТС транспортного средства) Средства поиска, отображения и анализа информации (1) Средства поиска, отображения и анализа информации должны быть включены во все экранные формы работы со списками объектов учета, в том числе в экранные формы работы с объектами реестра. Средства поиска должны обеспечивать возможности поиска объектов учета по всем характеристикам самих объектов, а также по всем характеристикам связанных объектов учета любого уровня вложенности (например, поиск объектов по параметрам связанных объектов учета, которые связаны со связанными объектами учета. – поиск объектов по параметрам договоров на них и параметрам субъектов этих договоров). Для каждой из характеристик должны быть предусмотрены следующие логические условия поиска: 1. Равно. 2. Не равно. 3. Больше. 4. Меньше. 5. Больше или равно. 6. Меньше или равно. 7. Содержит (для текстовых характеристик). 8. Не содержит (для текстовых характеристик). 9. Начинается на (для текстовых характеристик). 10. Не начинается на (для текстовых характеристик). 11. Заполнено. 12. Не заполнено. 13. Отсутствует. Для характеристик, имеющих историю изменения, должны быть предусмотрены средства указания даты, на которую выполняется поиск значения характеристики. Для сложных или связанных характеристик должны быть предусмотрены возможности поиска по комбинациям значений (например, поиск по коэффициентам подразумевает возможность поиска по произвольной комбинации значений, составляющих информацию по коэффициенту – наименование коэффициента, величина, диапазон дат периода действия коэффициента) Должен быть предусмотрен поиск по отрицанию условий поиска (объекты, НЕ удовлетворяющие условиям поиска). Должна быть предусмотрена возможность комбинации условий поиска – поиск в найденном и новый поиск в дополнение к предыдущему. Должна быть предусмотрена возможность сохранение ранее сформированных условий поиска для последующего быстрого использования Средства поиска, отображения и анализа информации (2) Для администраторов системы должна быть предусмотрена возможность формирования и отображения SQL-скрипта, соответствующего выборке объектов учета для формирования списка с учетом SQL-выражений, удовлетворяющих сформированным условиям поиска. Администратор должен иметь возможность ручной корректировки сформированных SQL-выражений поиска с возможностью выполнения поиска на основе скорректированных SQL-выражений. 1. Контекстный поиск В любой списочной форме (экранной форме отображения списка объектов учета или множественных реквизитов, атрибутов, характеристик объектов учета) должны быть предусмотрены средства контекстного поиска – возможность ввода символов в любой из колонок списка с автоматическим позиционированием курсора в списке на первый объект, соответствующий условиям поиска (вводимым значениям). 2. Универсальные средства предварительного просмотра В любой форме отображения списка объектов учета должна быть предусмотрена возможность отображения средств предварительного просмотра. Например, в списке договоров можно отобразить перечень кадастровых номеров земельных участков, арендуемых по текущему договору в списке, или перечень документов-оснований, перечень дополнительных соглашений, развернутую информацию о задолженности по договору. Средства предварительного просмотра должны представлять собой печатные формы, сформированные с использованием генератора отчетов, и отображающие всю необходимую информацию по текущему объекту учета в списке без выполнения дополнительных действий со стороны пользователя. Для каждого типа объектов учета может быть настроено произвольное количество форм предварительного просмотра с возможностью выбора текущей отображаемой формы из списка доступных форм Средства поиска, отображения и анализа информации (3) Средства предварительного просмотра должны обладать всеми возможностями печатных форм, включая возможность открытия карточки объекта учета путем двойного клика по информации по нему в окне предварительного просмотра (например, открытие карточки земельного участка из окна предварительного просмотра договоров, отображающего перечень земельных участков по текущему договору). 3. Аналитические средства элементов работы со списками объектов учета 1. Группировка данных по одному или нескольким столбцам. Например, реестр может быть сгруппирован по состоянию объектов учета, району области, разрешенному использованию. 2. Вычисление общих итогов, в том числе для каждой из групп (в случае применения группировки). Например, для приведенного примера возможна автоматическая калькуляция общей планируемой платы, площади объектов, величины задолженности в разрезе состояний договоров аренды, района расположения объекта договора, целевого использования; 3. Дополнительная оперативная фильтрация данных по значениям любого столбца\совокупности столбцов; 4. Сортировка данных по произвольному столбцу\совокупности столбцов. 5. Возможность выбора отображаемых столбцов. 6. Автоматическое сохранение настроек табличного представления для каждого типа объектов учета. Должна быть предусмотрена возможность экспорта сформированных данных в форматы табличные форматы (xlsx, csv), текстового файла или внутренние форматы генератора отчетов Средства предварительного просмотра В Системе должна быть реализована возможность автоматического предварительного просмотра документа непосредственно в табличной форме реестра любого типа объектов. При переходе от одного к другому объекту в списке, форма предварительного просмотра должна обновляться автоматически. Должна быть реализована возможность отключать данный режим, настраивать форму просмотра, выбирая нужный шаблон документа, из списка доступных для данного режима, шаблонов. Должна быть возможность создавать и редактировать шаблоны документов для данного режима наряду с любыми другими шаблонами документов Средства выполнения массовых операций Система должна иметь средства выполнения однотипных операций над заданным количеством объектов учета, в том числе: 1. Передача с баланса на баланс, в казну, из казны, списание объектов. 2. Внесение документа-основания. 3. Смена адреса. 4. Смена характеристик объектов учета. 5. Изменить нумерацию объектов. 6. Слияние «двойников». 7. Включить физическое лицо в очередь и исключить из очереди. 8. Массовое формирование квитанций, уведомлений, претензий и других печатных форм на основе заданных шаблонов. 9. Распределение платежного документа, оплаченного по 2-м и более договорам субъекта договоров (арендатор) осуществляется по начислению и по сальдо на любую дату. Массовые операции должны повысить эффективность управления имущественно-земельным комплексом, снизить трудозатраты специалистов на выполнение операций над объектами Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (1) Подсистема должна автоматизировать межведомственное электронное взаимодействие органов управления муниципальной собственностью в части формирования межведомственных запросов по протоколам СМЭВ в отношении объектов учета, субъектов права и договоров, зарегистрированных в единой базе данных Системы, а также автоматизации внесения изменений в единую базу данных Системы на основе полученных сведений. Подсистема должна решать следующие задачи: 1. Формирование межведомственных запросов в ручном режиме с любого рабочего места Системы (ручное заполнение информации по запросу). 2. Формирование межведомственных запросов непосредственно из карточки объекта учета, субъекта права или договора (автоматическое формирование запроса в «один клик»). 3. Формирование межведомственных запросов по вручную определенному пользователем перечню объектов учета, субъектов права или договоров в режиме массовой операции (полностью автоматическое формирование запросов без ограничения количества). 4. Автоматическое формирование межведомственных запросов по определенному перечню объектов учета, субъектов права или договоров в режиме регламентной операции (автоматически по расписанию без ограничения количества). Например, автоматическое формирование запроса на получение выписки из ЕГРН через месяц после подписания договора приватизации с целью определения даты перехода права на приватизированный объект (даты регистрации права собственности на нового собственника и исключения объекта из муниципальной доли) Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (2) После получения ответов на отправленные запросы подсистема в автоматическом или автоматизированном режиме должна позволять: 1. Обеспечивать возможность автоматического и автоматизированного (автоматического по требованию пользователя) внесения изменений в единую базу данных Системы на основе полученных сведений. 2. Автоматически прикреплять полученные сведения к карточке соответствующего объекта учета, субъекта права или договора в базе Системы с обеспечением возможности автоматизированного внесения изменений в карточку объекта учета, субъекта права или договора на основе этих сведений. 3. Обеспечивать возможность в автоматизированном режиме формировать информацию, аналитические и статистические отчеты, запросы на основе полученных в результате межведомственных запросов сведений, например, формировать уведомления о необходимости регистрации права собственности на приобретаемые в собственность объекты муниципальной собственности (покупке, приватизация) лицам или организациям, нарушившим сроки регистрации. Функции подсистемы должны быть использованы для автоматизации выполнения следующих задач: 1. Определения даты исключения объекта из муниципальной собственности в ходе продажи/приватизации объекта. 2. Определения периода нахождения объекта в муниципальной казне, обеспечения корректного бюджетного учета движения объектов в казне. 3. Определения даты расторжения договоров аренды на объекты муниципальной собственности в ходе выкупа из аренды. 4. Определения даты передачи муниципальной собственности на праве оперативного управления или хозяйственного ведения. 5. Уточнения сведений по объектам муниципальной собственности, подлежащим продаже, приватизации, наложению других обременений и/или вещных прав. 6. Уточнения площадных, стоимостных и других характеристик объектов муниципальной собственности. 7. Уточнение сведений по зарегистрированным правам на объекты муниципальной собственности Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (3) 8. Определения периода оплаты взносов на капитальный ремонт объектов муниципальной собственности, расположенных в многоквартирных жилых домах, включенных в программу капитального ремонта. Общей целью подсистемы должно быть обеспечение полноты и актуальности информации по объектам муниципальной собственности, земельным участкам, право собственности на которые не разграничено, вне-реестровым объектам учета, субъектам права, договорам и другим правам на объекты, подлежащие учету в рамках единого информационного фонда Системы. Для достижения поставленных целей подсистема должна обеспечить получение информации от участников межведомственного электронного взаимодействия путем формирования запросов в соответствии с установленными методическими рекомендациям, размещенными на портале https:/info.gosuslugi.ru Подсистема должна обеспечить: 1. Своевременное получение информации об изменении состава и/или содержания зарегистрированных на объекты учета прав, актуализацию соответствующих сведений в единой базе данных. 2. Своевременное проведение процедур, связанных с изменением информации по объектам учета, субъектам права и зарегистрированным правам. 3. Обеспечение полноты и качества ведения бюджетного учета движения объектов в муниципальной казне на основе актуальной информации по датам перехода права собственности на объекты учета, прав оперативного управления и хозяйственного ведения. 4. Обеспечение полноты и качества администрирования поступлений по администрируемым кодам бюджетной классификации на основе актуальной информации о регистрации договорных отношений. 5. Контроль за расходованием бюджетных средств на обслуживание объектов муниципальной собственности, включая оплату взносов на капитальный ремонт и др. Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (4) В составе подсистемы должны быть реализованы следующие средства: 1. Интегрированное хранилище данных в составе единой базы данных Системы. 2. Интегрированные средства ведения справочников и классификаторов. 3. Средства настройки. 4. Средства ручного формирования межведомственных запросов. 5. Средства формирования межведомственных запросов из карточки объекта Системы. 6. Средства формирования межведомственных запросов в режиме массовой операции. 7. Средства формирования межведомственных запросов в режиме регламентной операции. 8. Средства подписания запросов электронной подписью. 9. Средства ручного внесения результатов запросов, которые не формировались средствами подсистемы. 10. Средства предотвращения повторного формирования запросов 11. Средства опроса системы СМЭВ на предмет уточнения состояния запроса. 12. Средства загрузки полученных сведений в интегрированной хранилище данных. 13. Средства автоматического внесения изменений в единую БД Системы на основе полученных сведений. 14. Алгоритмы автоматического внесения изменений в единую БД Системы на основе полученных сведений. 15. Средства «закрытия» запросов. 16. Средства работы с журналом межведомственных запросов. 17. Средства работы с карточкой межведомственного запроса. 18. Средства поиска объектов Системы по параметрам межведомственных запросов. 19. Средства просмотра протоколов выполнения операций. 20. Средства администрирования и разграничения прав пользователей Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (5) Интегрированное хранилище данных в составе единой базы данных Системы Интегрированное хранилище данных должно быть предназначено для обеспечения хранения взаимосвязанной между собой информации подсистемы в составе единой базы данных Системы. Интегрированное хранилище данных должно обеспечивать хранение информации без дублирования, повторного внесения информации, которая уже содержится в единой базе данных Системы. Интегрированное хранилище должно содержать ссылки на объекты, субъекты и договоры единой базы данных Системы. Интегрированное хранилище должно обеспечивать хранение в единой базе данных Системы следующей информации: 1. Нормативно-справочная информация подсистемы (содержимое справочников и классификаторов, использующихся в подсистеме). 2. Информацию о настройках функционирования подсистемы. 3. Информация по сформированным запросам, полученным в ходе запросов сведениям. 4. Протоколы всех действий, выполняемых средствами подсистемы в автоматическом, полуавтоматическом и ручном режимах. 5. По каждому запросу должна быть размещена следующая информация: 5.1. Идентификатор вида сведений версии 3.х. 5.2. Вид операции из соответствующего классификатора (ручной, из карточки объекта Системы, из массовой операции, регламентная операция, на основе результатов, полученных из других источников), для массовой и регламентной операции – идентификатор операции. 5.3. Дата и время формирования запроса, идентификатор пользователя (если операция инициирована пользователем). 5.4. Информация, переданная в систему СМЭВ в ходе формирования запроса. 5.5. Идентификатор запроса, присвоенный системой СМЭВ. 5.6. Идентификатор карточки Системы, из которой (для которой) сформирован запрос. 5.7. Идентификаторы объекта (помещение или земельный участок), субъекта (юридическое или физическое лицо, ИП), договора, по которым сформирован запрос. Заполняются те идентификаторы, которые применимы для конкретного вида запроса Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (6) Примечание. Например, запрос информации из ЕГРН для определения даты перехода права в ходе приватизации теоретически может быть сформирован как из договора приватизации, так и из объекта. В этом случае идентификаторы карточки Системы, из которой сформирован запрос, должны быть разные, но идентификатор объекта в обоих запросах должен быть один. Это должно потенциально позволить предотвратить повторные запросы на основе анализа идентификатора объекта. 5.8. Дата и время автоматического или полуавтоматического внесения информации, по полученным сведениям, в единую базу данных. 5.9. Режим внесения изменений (автоматический, полуавтоматический «мастер», ручной) – см. пункт «Интегрированные средства ведения нормативно-справочной информации». 5.10. Идентификатор пользователя, внесшего изменения в ручном или полуавтоматическом режиме – «мастер». 5.11. Признак отработки результатов запроса (да или нет). 5.12. Текущий статус (состояние) запроса в системе СМЭВ. 5.13. Дата и время изменения сведений запроса в системе СМЭВ (по данным СМЭВ). 5.14. Дата и время внесения изменений из системы СМЭВ (изменения статуса запроса). 5.15. Дату и время последнего успешного опроса системы СМЭВ по данному запросу. 5.16. Полную информация обо всех изменениях статусов (состояний) запросов, включая дату и время смены состояния, текстовое описание причины смены состояния, и другие сведения, полученные из системы СМЭВ в ходе информационного обмена Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (7) 6. Информация, полученная в ходе исполнения межведомственного запроса должна быть представлена в структурированном виде и размещаться ее в реляционных структурах (таблицах) единой базы данных Системы. Информация должна быть представлена в виде, пригодном для формирования SQL-запросов с ее использованием. Должны быть предусмотрены средства заполнения данных в структурированном, реляционном виде на основе информации, размещенной в XML-файле полученного результата запроса. Хранение данных только в XML-файле результата запроса недопустимо. Полученную информацию необходимо вносить в интегрированное хранилище. В интегрированном хранилище должны быть размещены протоколы всех действий, выполняемых средствами подсистемы в автоматическом, полуавтоматическом и ручном режимах, в том числе: 1. Протокол взаимодействия с подсистемой СМЭВ (формирование запроса, опросы с целью получения статуса запроса (пингование), загрузка результата в интегрированное хранилище, парсинг результата, размещение данных результата в реляционных таблицах). 2. Протокол применения результата к объектам базы данных (поиск объектов в базе данных для ручных запросов, автоматическое добавление объектов в базу данных по результатам запросов, внесение изменений в электронные карточки объектов учета на основе полученных данных (индивидуально для каждого выполненного изменения)). Протоколы должны содержать следующую информацию: 1. Дата и время выполнения операции или действия. 2. Имя пользователя, инициировавшего операцию (если операцию инициировал пользователь). 3. Вид операции из соответствующего классификатора (ручной, из карточки объекта Системы, из массовой операции, регламентная операция, опрос (пингование) запроса в системе СМЭВ, получение события из системы СМЭВ), для массовой и регламентной операции – идентификатор операции. 4. Признак успешности выполнения операции из соответствующего классификатора (успешно, не успешно). 5. Выполненное действие (из соответствующего классификатора) Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (8) 6. Данные, связанные с действием (в текстовом виде), например, при вводе кадастрового номера объекта на основе полученных данных – кадастровый номер. 7. Дополнительная текстовая информация (в случае ошибки – причина ошибки). Интерфейс для работы пользователей с данными, размещенными в интегрированном хранилище, должен быть обеспечен непосредственно Системой с использованием экранных форм, разработанных по общим принципам, принятым для Системы, с использованием единого визуального стиля, оформления Системы. Интегрированные средства ведения справочников и классификаторов Средства должны быть предназначены для управления работой со справочниками и классификаторами подсистемы и обеспечивать единое пространство справочной информации в процессе использования учетных данных и документов. Средства должны обеспечивать выполнение функций: 1. Редактирование справочников и классификаторов. 2. Просмотр справочников и классификаторов. Средства настройки Подсистема должна обеспечивать максимально широкие возможности по настройке, изменению технологии работы подсистемы силами обученных пользователей Системы без привлечения программистов Исполнителя. Должны быть предусмотрены следующие средства настройки, изменения технологии работы подсистемы силами обученных пользователей Системы: 1. Средства настройки перечня доступных сервисов и/или видов сведений для формирования межведомственных запросов в ручном режиме. 2. Средства настройки перечня доступных для каждого из типов объектов учета Системы сервисов и/или видов сведений. 3. Перечень регламентных операций для формирования запросов по расписанию, настройка расписания выполнения регламентных операций. 4. Средства/Алгоритмы чтения полученных в результате межведомственного запроса сведений и размещения их в реляционных субтаблицах интегрированного хранилища (единой базы данных Системы). 5. Средства/Алгоритмы внесения изменений в электронные карточки объектов учета на основе полученных данных Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (9) 6. Средства/Алгоритмы создания объектов учета, отсутствующих в базе данных, на основе сведений, содержащихся в полученных ответах. 7. Средства/Алгоритмы связи запросов, выполненных в ручном режиме, с объектами, которые уже есть в базе данных Системы на основе сведений, содержащихся в полученных ответах. 8. Средства/Алгоритмы автоматического «закрытия» межведомственных запросов после получения и использования (применения, внесения в базу данных) полученных сведений, возможность индивидуального отключения автоматического «закрытия» запросов. 9. Создание шаблонов автоматического частичного заполнения формы формирования ручного запроса. Средства ручного формирования межведомственных запросов При ручном формировании запроса пользователь должен предварительно выбирать услугу (сервис), для которой формируется запрос. Выбор должен производиться из перечня услуг (сервисов), для которых доступно ручное формирование запроса. В случае, если для некоторого сервиса/услуги предусмотрена возможность формирования запросов по нескольким вариантам параметров (например, по кадастровому номеру или адресу объекта), то должна быть предусмотрена возможность ввода параметров запроса для каждого варианта. При проектировании должна быть предусмотрена возможность создания шаблонов автоматического заполнения одного или нескольких параметров запросов. Должна быть предусмотрена возможность индивидуального создания шаблонов каждым пользователем. Технология создания шаблонов должна быть реализована по следующему принципу – пользователь заполняет те параметры экранной формы ручного формирования запросов, которые должны быть включены в шаблон. Далее пользователь инициирует создание шаблона и вводит его наименование/описание. После этого шаблон автоматически появляется в списке доступных для данного пользователя шаблонов для данной услуги/сервиса. Для одного из шаблонов каждого сервиса/услуги должна быть предусмотрена возможность выбора шаблона по умолчанию Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (10) Пользователь может выбрать любой доступный для данного сервиса/услуги шаблон, в этом случае соответствующие параметры из шаблона автоматически должны заполнять поля экранной формы ручного формирования запроса. После успешного формирования запроса пользователю должно быть выведено соответствующее сообщение с указанием кода сформированного запроса в журнале запросов. Для запросов по кадастровому номеру или кадастровому кварталу должна быть предусмотрена возможность пакетного формирования ручных запросов на основе кадастровых номеров (или кварталов), определенных в текстовом файле (в столбик) – для каждого кадастрового номера (квартала) автоматически должен быть сформирован запрос. Аналогичная возможность должна быть предусмотрена для запросов по ИНН, ОГРН и другим классификационным кодам юридических, физических лиц, индивидуальных предпринимателей. Средства формирования межведомственных запросов из карточки объекта Системы Формирование межведомственных запросов из карточки объекта Системы подразумевает возможность автоматического формирования запроса в системе СМЭВ. Параметры, необходимые для формирования запроса в автоматическом режиме должны заполняться на основе данных, размещенных в соответствующей карточке объекта учета, из которой формируется запрос. При формировании запроса пользователь должен предварительно выбрать услугу (сервис), для которой формируется запрос. Выбор должен производиться из перечня услуг (сервисов), для которых доступно формирование запроса из карточки объекта данного типа (см. требования к настройке подсистемы). Формирование запроса должно быть реализовано с использованием динамически формируемого перечня пунктов подменю пункта «СМЭВ» меню карточки (или кнопки СМЭВ). Динамически формируемый перечень подменю должна соответствовать перечню доступных для запроса услуг/сервисов с отбивкой сепаратором услуг/сервисов различных организаций (услуги/сервисы различных организаций визуально должны быть отделены друг от друга) Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (11) В случае, если карточка объекта учета не содержит всей необходимой для формирования запроса информации, пользователь должен быть в развернутой форме информирован о характере возникшей ошибки с указанием конкретных реквизитов объекта, которые должны быть заполнены для корректного формирования запроса. Должна быть предусмотрен режим ручного формирования запроса из карточки объекта. В данном режиме Система инициирует ручное создание запроса, а также производит автоматическое заполнение параметров запроса сведениями, содержащимися в карточке соответствующего объекта учета. После этого пользователю предоставляется возможность самостоятельной корректировки сведений (параметров запроса) и ручного формирования межведомственного запроса. После формирования запроса пользователю должно быть выведено соответствующее сообщение с указанием кода сформированного запроса в журнале запросов. Средства формирования межведомственных запросов в режиме массовой операции Для формирования межведомственных запросов в режиме массовой операции должен быть задействован стандартный механизм Системы работы с массовыми операциями (выбора объектов для выполнения массовой операции). Выбор объектов для массовой операции должен производиться с использованием следующих средств: 1. Из списка объектов учета любых типов основного окна Системы. 2. Из экранных форм Системы, отображающих списки объектов учета произвольных типов. 3. Из окна результата запроса подсистемы «Библиотека запросов». Выбор услуги (сервиса) для формирования запроса должен быть реализован путем динамического создания пунктов подменю пункта СМЭВ. Пункты подменю должны содержать полный перечень всех услуг/сервисов, доступных для формирования из карточек объектов учета, доступных для выполнения массовой операции в текущем режиме работы Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (12) Выполнение массовой операции должно производиться пообъектно способом, аналогичным формированию запроса из карточки объекта учета соответствующего типа (описание приведено выше). В случае, если операция формирования запроса для данного вида объекта учета недоступна (в соответствии с настройками) или для формирования запроса недостаточно информации, по таким объектам формируется ошибка по правилам функционирования функционала массовых операций (объект помечается красным фоном, формируется развернутое сообщение об ошибке (содержит четкое описание сути ошибки), объект пропускается, происходит переход к обработке следующего объекта). Операции, выполняемые в режиме массовой операции, должны протоколироваться по общим принципам (индивидуальное протоколирование каждого сформированного в режиме массовой операции межведомственного запроса). Средства формирования межведомственных запросов в режиме регламентной операции Регламентная операция представляет собой выполнение некоторого запроса по определенному расписанию, межведомственные запросы формируются в автоматическом режиме для каждого объекта, информация по которому возвращена запросом. Средства формирования межведомственных запросов в режиме регламентных операций должны обеспечивать ведение библиотеки регламентных операций, средства добавления, изменения, удаления регламентных операций, приостановки выполнения регламентных операций. Библиотека регламентных операций должна представлять собой список регламентных операций, содержащий следующие атрибуты: 1. Код идентификатор (код) регламентной операции. 2. Наименование - наименование регламентной операции. 3. Организация – наименование организации, предоставляющей услугу/сервис. 4. Сервис наименование услуги/сервиса для формирования запроса в режиме регламентной операции. 5. Признак успешности предыдущего выполнения. 6. Дата, время следующего выполнения. 7. Состояние (запланировано, приостановлено) Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (13) 8. Приостановленные регламентные операции или регламентные операции, для которых не определено время следующего запуска должно визуально выделяться (серый текст шрифта). 9. Регламентные операции, по которым предыдущий вызов был завершен ошибкой должны визуально выделяться (розовый фон). 10. Для каждой регламентной операции должны быть определены: 10.1. Код – присваивается автоматически. 10.2. Наименование регламентной операции. 10.3. Описание регламентной операции – текст произвольного размера. 10.4. Услуга/сервис – выбор из списка услуг/сервисов, доступных для формирования запросов в режиме регламентной операции. Расписание выполнения операции (стандартный функционал для формирования расписаний) – в определенное время разово, ежечасно, ежедневно, еженедельно в определенные дни. Средства подписания запросов электронной подписью С целью обеспечения возможности автоматизированного формирования запросов в пакетном режиме, а также автоматического формирования запросов в режиме массовой операции в Подсистеме должны быть реализованы средства централизованного (серверного) принципа подписания запросов электронной подписью. Для этого в составе подсистемы должен быть реализован сервер ЭП (сервер электронной подписи). Это означает, что в подсистеме должна быть реализована возможность добавления одной или более учетных записей организаций/пользователей организаций, настройки и реквизиты которых будут использоваться для формирования межведомственных запросов и подписания их электронной подписью. Для каждой учетной записи должна быть обеспечена возможность сопоставления с ЭП-ОВ (электронной подписи органа власти) и ЭП-СП – электронная подпись служебного пользования уполномоченного лица (руководителя), которые загружены на сервер ЭП Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (14) Для каждого пользователя Системы, в должностные обязанности которого входит возможность формирования межведомственных запросов, должна быть предусмотрена возможность указать учетную запись организации/уполномоченного лица организации, электронные подписи которой будут использоваться для автоматического подписания запросов, сформированных соответствующим пользователем. Запросы, формируемые средствами подсистемы в любом из описанных выше режимов, должны подписываться ЭП-ОВ и/или ЭП-СП в зависимости от методических рекомендаций для соответствующего вида сведений. Средства ручного внесения результатов запросов, которые не формировались средствами подсистемы В подсистеме должны быть предусмотрены средства внесения результатов запросов, полученных из внешних источников, то есть без использования средств подсистемы. При ручной загрузке результата подсистема должно быть инициировано автоматическое занесение соответствующего запроса в журнал запросов. Дальнейшая обработка загруженного вручную результата должна производиться стандартным способом (загрузка результата в интегрированное хранилище, применение результата (внесение изменений в единую база данных Системы на основе полученных сведений)). В протокол работы с запросом автоматически должна быть добавлена запись, что результат загружен вручную без использования межведомственного взаимодействия. Средства предотвращения повторного формирования запросов Подсистема должна содержать средства повторного формирования запросов на одни и те же объекты учета Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (15) Под повторным формированием запроса понимается формирование запроса на объект, на который уже был ранее сформирован межведомственный запрос на получение сведений по этой же услуге (сервису), по которому сведения получены, но еще не использованы (запрос не «закрыт»), или запрос находится в состоянии ожидания сведений (ответа), то есть по запрос не был отклонен (не находится в состоянии ошибки), сведения еще не получены. В ходе проверки на наличие предыдущих запросов следует учесть, что запрос на данный объект учета мог быть сформирован не из текущей карточки, например, текущий запрос получения выписки из ЕГРН на объект имущества формируется из карточки договора приватизации этого объекта имущества, однако ранее был сформирован запрос на этот же объект, но из карточки другого договора или самого объекта. Должна быть предусмотрена возможность определения возможности проверки на наличие сформированных ранее запросов в ручном режиме – возможность должна быть определена на этапе реализации. При наличии возможности указанный функционал подлежит реализации. Для каждого сервиса/услуги должна быть предусмотрена возможность настройки количества дней, в течение которых результат предыдущего запроса можно считать актуальным. В случае, если такая настройка произведена, то при ручном формировании запроса или формировании запроса из карточки объекта, при наличии ранее полученного ответа подсистема должна предупреждать пользователя, что уже получен результат на соответствующий запрос с указанием даты его получения и возможностью открытия результата предыдущего запроса. В режиме массовой и регламентной операции формирование таких повторных запросов должно быть заблокировано с указанием причины (по объекту имеется актуальные сведения на запрос, полученные такого-то числа). Средства опроса системы СМЭВ на предмет уточнения состояния запроса, загрузка полученных сведений Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (16) Основным режимом получения/обновления сведений о сформированных ранее межведомственных запросов из системы СМЭВ является режим периодического опроса (пингования) системы СМЭВ. При наличии изменений с момента последнего опроса (пингования) системы СМЭВ (изменение даты и времени последнего изменения запроса в системе СМЭВ с аналогичными данными в интегрированном хранилище Системы), полученная информация должна быть занесена в интегрированное хранилище Системы: 1. Дата и время последнего изменения состояния или сведений запроса в системе СМЭВ. 2. Текущий статус (состояние) запроса. 3. При изменении статуса (состояния) запроса – информация по изменению состояния (см. требования к интегрированному хранилищу данных). При получении сведений за межведомственный запрос (XML-файл, содержащий сведения), подсистема должна выполнять чтение файла и должна разместить полученную из XML-файла информацию в соответствующих субтаблицах запроса в виде, пригодном для формирования SQL-запросов с использованием полученных сведений. Все операции по опросу (пингованию) системы СМЭВ вне зависимости от наличия изменений должны протоколироваться. Требования к протоколированию приведены в пункте «Интегрированное хранилище данных». Должна быть предусмотрена возможность опроса (пингования) по всем сформированным межведомственным запросам, обработка которых еще не завершена (запрос не находится в состоянии ошибки и сведения по нему еще не получены), а также по межведомственным запросам определенной (выбранной пользователем) услуги (сервиса). Операция должна выполняться из основного окна Системы с использованием соответствующих пунктов меню. В некоторых случаях сведения, содержащиеся в ответе на межведомственный запрос, не передаются в ходе межведомственного взаимодействия, а должны скачиваться пользователем вручную с использованием сети интернет. Такая ситуация возникает, например, из-за большого объема полученных сведений. Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (17) Средства загрузки полученных сведений в интегрированное хранилище Полученные в результате межведомственного запроса сведения содержат XML-файл заданной в спецификациях к конкретной услуге (сервису) структуры. В момент получения XML-файла должно быть обеспечено чтение всех данных XML-файла и размещение их в интегрированном хранилище Системы (единой базе данных Системы) в структурированном виде, пригодном для использования в SQL-запросах (см. требования к интегрированному хранилищу). Чтение данных XML-файла и размещение их в интегрированном хранилище должно осуществляться с использованием алгоритма из библиотеки алгоритмов парсинга (разбора) результатов запросов, полученных в машиночитаемом виде (xml). Должна быть предусмотрена возможность разработки новых алгоритмов и включение их в библиотеку алгоритмов силами обученных пользователей Системы Заказчика. Должно быть предусмотрено обязательное протоколирование выполнения указанной процедуры. Требования к протоколированию приведены в пункте «Интегрированное хранилище данных»). Загрузка полученных сведений в интегрированное хранилище должно производиться вне зависимости от способа загрузки сведений (автоматическая загрузка при получении ответа на сформированный ранее запрос), ручная загрузка результата, направленного ранее запроса, ручная загрузка результата на запрос, который не был отправлен средствами подсистемы. Средства автоматического внесения изменений в единую БД Системы на основе полученных сведений Автоматическое внесение изменений в единую базу данных Системы на основе полученных сведений должно производится в момент получения сведений на межведомственный запрос после размещения полученных данных в реляционных субтаблицах. Автоматическое внесение изменений должно производиться путем вызова соответствующего алгоритма из библиотеки алгоритмов, наименование которого настраивается для каждой услуги (сервиса) Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (18) Должна быть предусмотрена возможность разработки новых алгоритмов и включение их в библиотеку алгоритмов силами обученных пользователей Системы Заказчика. По завершении автоматического внесения информации в интегрированном хранилище для данного запроса должны быть установлены дата и время автоматического внесения изменений на основе полученных сведений, признак завершения отработки запроса, а также вид операции – «Автоматическое внесение информации». Должно быть предусмотрено обязательное протоколирование выполнения указанной процедуры. Протоколированию подлежит также факт невыполнения автоматической операции в связи с отсутствием имени алгоритма, выполняющего соответствующее действие. Автоматическое внесение сведений может быть отключено настройками подсистемы (такая настройка должна быть предусмотрена индивидуально для каждого типа объектов учета, а также сервиса/услуги). В случае, если автоматическое внесение изменений отключено, должна быть предусмотрена возможность ручного запуска средств автоматического внесения изменений из окна просмотра результатов запроса. Факт ручного запуска средств автоматического внесения информации должен быть внесен в протокол. Алгоритмы автоматического внесения изменений в единую БД Системы на основе полученных сведений Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (19) Алгоритм автоматического внесения изменений в единую БД Системы на основе полученных сведений должен быть определен индивидуально для каждого типа объектов учета и каждого сервиса/услуги с возможностью его настройки. Алгоритм должен функционировать по следующему принципу: 1. Если запрос был сформирован вручную, то на основе полученных сведений должен быть выполнен поиск соответствующего объекта в единой базе данных Системы, при успешном поиске запрос должен быть автоматически прикреплен к соответствующему объекту, соответствующее действие должно быть внесено в протокол. 2. Если найти объект не удалось, то в зависимости от настройки (такая настройка должна быть предусмотрена) подсистема автоматически создаст соответствующий объект в единой базе данных Системы и заполнит электронную карточку объекта сведениями, содержащимися в полученных данных. Соответствующие действия должны быть внесены в протокол. 3. Если получены сведения на запрос по объекту, который уже находится в базе данных Системы, то алгоритм опционально (такая настройка должна быть предусмотрена индивидуально для каждого типа объектов учета, сервиса/услуги и действия из перечисленного ниже списка) должен иметь возможность выполнить следующие действия: 3.1. Для каждого реквизита полученных сведений должна быть выполнена сверка с соответствующим реквизитом в электронной карточке соответствующего объекта учета. Возможны следующие варианты: 3.1.1. Если реквизит не заполнен, он подлежит заполнению на основе полученных сведений (должно настраиваться). 3.1.2. Если реквизит заполнен, и он отличен от соответствующего реквизита в полученных сведениях, то в зависимости от настройки либо реквизит подлежит изменению (с протоколированием каждого действия), либо для запроса должно быть сформировано предупреждение (состояние запроса сменится на «Предупреждение») с внесением в текст предупреждения развернутой информации о выявленных различиях Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (20) 4. Информация о полученных сведениях должна быть занесена в документы по объекту учета (опционально). Для выписок из Росреестра о правах на объекты имущества дополнительно (опционально) должны быть предусмотрены следующие возможности: 1. Сверка с единой БД Системы на предмет наличия объекта в реестре муниципальной собственности (если в Системы объект включен в реестр, а по данным Росреестра – нет или наоборот, то должно быть сформировано соответствующее предупреждение). 2. В случае, если в выписке обнаружена информация о регистрации права на объект имущества Системы, которое перешло новому владельцу на основании документов, фигурирующих в единой БД Системы (например, в ходе продажи или приватизации объекта), то опционально должна быть предусмотрена возможность автоматического исключения объекта из реестра муниципальной собственности датой, предшествующей дате регистрации объекта на нового собственника с автоматическим внесением информации о документе-основании исключения. Автоматические изменения в соответствии с алгоритмами и настройками Системы могут быть инициированы пользователем вручную. В этом случае пользователь должен быть проинформирован о всех произведенных действиях подсистемы (открыт протокол соответствующих действий) с возможностью быстрого доступа (в один клик мыши) к карточке объекта учета для анализа и возможной корректировки соответствующих действий. Средства «закрытия» запросов Под «закрытием» запроса помечается возможность пометки запроса в качестве отработанного, то есть запроса, не требующего дальнейшего анализа или использования пользователем. Должна быть предусмотрена возможность автоматического и ручного «закрытия» запросов Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (21) Автоматическое «закрытие» запросов должно производиться по настройке (такая настройка должна быть предусмотрена индивидуально для каждого типа объектов учета и услуге/сервису) после успешного получения результатов запроса и автоматического успешного внесения изменений в единой базе данных Системы, предусмотренных соответствующим алгоритмом. Должна быть предусмотрена возможность отключения автоматического «закрытия» запросов индивидуально для каждого пользователя. Ручное «закрытие» должно производится пользователем самостоятельно после изучения и/или использования результатов запроса. «Закрытые» запросы не должно изыматься из единой базы данных Системы, последующий доступ к ним должен быть обеспечен по запросам пользователей. По умолчанию для журнала запросов должна быть предусмотрена возможность отображения не закрытых запросов – см. требования к функционированию журнала запросов. Средства работы с журналом межведомственных запросов Журнал запросов должен представлять собой список запросов, содержащий всю основную информацию по каждому запросу, а также средства открытия карточки запроса и выполнения основных действий над запросом. Журнал запросов должен быть доступен в следующих режимах: 1. Из карточки объекта Системы – журнал размещается на вкладке «СМЭВ» карточки объекта и содержит все межведомственные запросы, которые были сформированы для данного объекта. 1.1. Из основного окна Системы для всех услуг/сервисов, а также индивидуально для каждого из сервисов/услуг в режиме отображения «моих» запросов. Под «моими» запросами понимаются запросы, сформированные текущим пользователем Системы. 1.2. Из основного окна Системы для всех услуг/сервисов, а также индивидуально для каждого из сервисов/услуг в режиме отображения всех запросов Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (22) Для журнала межведомственных запросов должны быть предусмотрены средства поиска/фильтрации запросов в соответствии с требованиями к функционированию подсистемы поиска и анализа информации Системы: 1. Должны быть предусмотрены возможности поиска запросов по любым параметрам запроса, в том числе: 1.1. Сервис/услуга. 1.2. Код запроса. 1.3. Дата формирования запроса. 1.4. Состояние запроса (с возможностью множественного выбора из справочника состояний). 1.5. Статус запроса (текстовый статус сервисов межведомственного взаимодействия). 1.6. Сообщение протокола прохождения (выполнения) запроса. 1.7. Сообщения протокола применения результатов запроса (внесения изменений в базу Системы по результатам запроса). 1.8. Номер заявки. 1.9. GUID запроса в Системы. 1.10. Признак «закрытия» запроса. 1.11. Тип операции создания запроса (вручную, из карточки объекта, массовая операция, регламентная операция) – множественный выбор из справочника. 1.12. Источник операции создания запроса – множественный выбор из соответствующего справочника. 1.13. Пользователь, инициировавший запрос. 1.14. Дата последнего изменения информации. 1.15. Код регламентной операции. 1.16. Дата получения результата. 1.17. Дата загрузки результата. 1.18. Дата применения результата. 1.19. Тип операции применения результата – из соответствующего справочника. 1.20. Источник операции применения результата – из соответствующего справочника. 1.21. Пользователь, применивший результат. 1.22. Признак автоматического создания запроса при ручной загрузке результата, полученного из внешних источников. 1.23. Признак необходимости ручной загрузки результатов запроса. 1.24. Признак необходимости ручного применения результатов. 1.25. Признак включения в план повторных запросов Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (23) 2. Должны быть предусмотрена возможность поиска запросов по любым параметрам объектов единой базы данных Системы с использованием экранных форм поиска/фильтрации объектов, предусмотренных для соответствующих объектов в Системы. 3. Должны быть предусмотрена возможность просмотра/корректировки (для администратора) SQL-запроса на выборку запросов в соответствии с параметрами поиска. 4. Должны быть предусмотрен фильтр по умолчанию на отображение запросов, требующих внимания пользователей, то есть запрос не «закрыт» и результат получен (состояние запроса – «Успех, «Предупреждение» или «Ошибка»). Средства работы с карточкой межведомственного запроса Карточка межведомственного запроса должна открываться из журнала запросов в любом из режимов его отображения и содержать следующую информацию/средства управления: 1. Основную информацию по запросу: 1.1. Код запроса. 1.2. Текущее состояние запроса. 1.3. Текстовый статус запроса. 1.4. Дата и время формирования запроса. 1.5. Пользователь, сформировавший запрос. 1.6. Дата и время получения результата запроса. 1.7. Информация по объекту Системы, связанного с данным запросом. 1.8. Сведения о загрузке результата в базу данных. 1.9. Сведения о применении результата (внесении изменений в базу данных). 2. Средства просмотра протоколов работы с запросом. 3. Средства просмотра файлов, полученных в результате запроса (в разархивированном виде). 4. Средства выгрузки файлов результатов запроса на внешний носитель. 5. Средства открытия файлов результатов запросов стандартными средствами операционной системы. 6. Средства просмотра xml-файла результата запроса в виде документа (с применением соответствующих стилей отображения XML в оффлайн-режиме – без требования наличия сети интернет). 7. Печать и выгрузка XML-файла в виде документа. 8. Средства «Закрытия запроса». 9. Средства ручного применения результатов запроса Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (24) 10. Средства доступа к карточке объекта учета в Системе (в один клик). 11. Средства загрузки результатов запроса (для запросов, требующих ручную загрузку результатов). 12. Средства открытия запроса в системе СМЭВ. Средства поиска объектов Системы по параметрам межведомственных запросов Для объектов базы данных Системы должны быть предусмотрены средства поиска объектов по параметрам межведомственных запросов. Средства указания параметров поиска/фильтрации должны быть интегрированы непосредственно в стандартные окна поиска/фильтрации объектов Системы и должны быть размещены на отдельной вкладке «СМЭВ». Средства поиска должны обладать следующими возможностями: 1. Поиск объектов по наличию или отсутствию межведомственных запросов указанного сервиса/услуги (если не указано, то для любых сервисов/услуг) в заданном диапазоне дат (если не указано, то на любую дату). 2. Поиск объектов по любым параметрам запросов с использованием формы поиска/фильтрации журнала межведомственных запросов. Средства просмотра протоколов выполнения операций Средства просмотра протоколов выполненных операций должны представлять собой таблицу с возможностью стандартной расширенной настройки табличного представления (сортировка, группировка, встроенные фильтры), отображающей все выполненные операции по заданному запросу. Средства просмотра протоколов выполнения операций должны быть доступны из карточки запроса. Средствами подсистемы «Библиотека запросов» Системы должна иметь возможность анализа протоколов по алгоритмам, которые определяются соответствующими запросами в «Библиотеке запросов» Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (25) Средства администрирования и разграничения прав пользователей Все операции подсистемы, которые могут быть инициированы пользователем, должны подлежать администрированию и разграничению прав доступа. Администрированию должны подлежать: 1. Операции ручного формирования запросов – индивидуально для каждого вида услуги (сервиса) – по справочнику услуг (сервисов). 2. Операции формирования запросов из карточек объектов учета – индивидуально для каждого вида объекта и услуги (сервиса). 3. Операции формирования запросов в режиме массовой операции – индивидуально для каждого вида объекта в массовой операции и услуги (сервиса). 4. Операции ручной загрузки сведений, полученных из сторонних источников – индивидуально для каждого вида объекта и услуги (сервиса). 5. Операции ручного инициирования автоматического внесения изменений на основе полученных сведений – индивидуально для каждого вида объекта и услуги (сервиса). 6. Просмотр, печать, экспорт результатов, сформированных ранее запросов – индивидуально для каждого вида объекта и услуги (сервиса) Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» (1) Подсистема должна обеспечивать автоматический сбор и передачу информации по начислениям из Системы в Государственную информационную систему государственных и муниципальных платежей (ГИС ГМП) с использованием протоколов СМЭВ в форматах и порядке, утвержденных приказом Федерального казначейства от 12 мая 2017 г. № 11н «Об утверждении Порядка ведения Государственной информационной системы о государственных платежах». Подсистема должна быть реализована в виде сервисов ОС, которые выполняют следующие функции: 1. Формирование и присвоение УИН (уникальный идентификатор) начислениям всех типов (в соответствии с методическими и форматными требованиями ГИС ГМП). 2. Автоматический сбор информации по начислениям, а также корректировкам и аннулированиям начислений из Системы. 3. Формирование сообщений в утверждённых форматах ГИС ГМП, заверение их электронной подписью (ЭП) и передача сообщений по протоколам СМЭВ, формирование протокола отправки и подтверждения получения из ГИС ГМП. 4. Анализ полученных ответов и создание необходимых записей/протоколов в БД Системы. 5. Автоматическое распределение поступлений, в которых указан корректный UIN, по договорам Системы. Подсистема должна автоматизировать работу оператора начислений, снять нагрузку по ручному формированию и отправке начислений в Федеральное казначейство, а также проверки статусов начислений. Вся работа должна осуществляться в стандартном интерфейсе Системы, средства взаимодействия должны функционировать полностью автоматически и не требовать дополнительных действий от пользователей Системы Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» (2) Средства импорта поступлений из ГИС ГМП, квитирования начисления Подсистема должна обеспечить в автоматическом режиме получение платежей из ГИС ГМП и размещение их в журнал платежей подсистемы. Получение платежей должно выполняться полностью автоматическом фоновом режиме по заданному расписанию. Журнал платежей ГИС ГМП должен обеспечивать выполнение следующих задач: 1. Хранение полной информации по всем полученным платежам (атрибутам платежей), в объеме и составе атрибутов, использующихся в финансово-аналитической подсистеме Системы, журнале нераспределенных платежей. 2. Хранение даты получения информации о платеже. 3. Ведение журнала (лога) всех операций, выполняемых над платежами в журнале. 4. Постановка функции получения платежей на паузу. 5. Обеспечение поиска/фильтрации платежей в журнале по всем параметрам платежей, а также их состояниям, сообщениям лога работы с платежами. 6. Формирование и ведение информации о несквитированной сумме платежа в режиме реального времени. Информация об автоматическом квитировании начислений платежами на стороне ГИС ГМП (при совершении платежа плательщиком с использованием УИН начисления) должна приниматься из ГИС ГМП в автоматическом режиме одновременно с получением информации о соответствующих платежах. В случае получения информации об автоматическом квитировании должен быть автоматически произведен поиск соответствующих начислений в журнале начислений и связывание платежа с этими начислениями (квитирование) Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» (3) Должна быть предусмотрена возможность ручного квитирования начислений. Ручное квитирование начислений с платежами должно выполняться путем выбора платежа, квитирующего данное начисление с указанием суммы квитирования. Выбор платежа должен производиться с использованием инструментов журнала платежей подсистемы. Должен быть предусмотрен комплекс проверок – сумма квитирования не должна превышать суммы начисления, начисление может быть сквитировано с платежом на сумму, не превышающую сумму платежа. Должна быть предусмотрена возможность частичного квитирования начисления (квитирования не всей суммы начисления) Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» (4) Ручное квитирование должно быть предусмотрено только для успешно отправленных в ГИС ГМП начислений, сумма которых не сквитирована или не полностью сквитирована с платежами. Должна быть предусмотрена возможность квитирования начислений с отсутствующим платежом (в соответствии с технологией квитирования, предусмотренной в ГИС ГМП). Информация о вручную выполненных квитированиях должна автоматически отправляться в ГИС ГМП в соответствии с форматами обмена (действующая версия формата на момент заключения Контракта). Средства автоматического распределения поступлений с использованием УИН Поступления по администрируемым кодам бюджетной классификации (КБК) поступают в журнал нераспределенных поступлений финансово-аналитической подсистемы из системы СУФД Федерального Казначейства. В Системе должна быть предусмотрена возможность выполнения автоматических операций по автоматическому распределению поступлений на договоры с привязкой к виду начисления. В случае, если информация о поступлении содержит УИН начисления, эта информация должна использоваться для однозначного определения договора и вида начисления путем поиска по УИН и анализа информации о соответствующем начислении. Должно быть выполнено соответствующее развитие алгоритмов автоматического распределения поступлений по договорам и видам начислений финансово-аналитической подсистемы Требования к видам обеспечения (1) 4.1 Информационное обеспечение Системы Информационный обмен между узлами Системы основывается на стандартных протоколах передачи данных, использующих сетевой протокол TCP/IP. 4.2 Требования к контролю, хранению, обновлению и восстановлению данных Система должна контролировать корректность вводимой информации, а также проверять логическую целостность информации в БД при выполнении операций с БД. Стратегию и план резервного копирования разрабатывает Заказчик на основе рекомендаций Исполнителя, исходя из следующих условий: 1. Емкость и производительность системы резервного копирования. 2. Объемов разделов БД. 3. Допустимого времени восстановления. 4. Требований по обеспечению сохранности информации. Система должна протоколировать все события, связанные с изменением своего информационного наполнения, и иметь возможность, в случае сбоя в работе, восстанавливать свое состояние, используя ранее запротоколированные изменения данных. 4.3 Аппаратное обеспечение Системы Система должна функционировать на предоставленном Заказчиком оборудовании, с перечисленными ниже характеристиками. Оборудование предоставляется Заказчиком не позднее чем через 2 дня после заключения контракта. 4.3.1 Основной сервер Системы Требования к видам обеспечения (2) На нем размещаются следующие функциональные серверы: 1. Сервер БД – сервер баз данных СУБД, предназначены для хранения и управления информацией базы данных Системы. В качестве СУБД может быть использован Postgres версии не менее 12.0 или эквивалент. 2. Сервер приложений - обеспечивает предоставление доступа Клиентских мест, автоматизированных рабочих мест (далее - АРМ) пользователей к данным Системы, а также содержит средства обеспечения корректности исполнения технологических процессов (бизнес-логики) функционирования Системы. Представляет собой промежуточное звено обеспечения взаимодействия между АРМ пользователей и Сервером БД. Сервер должен иметь конфигурацию не ниже следующей: 1. Процессор: 8 ядер, частота не менее 2 ГГЦ на одно ядро. 2. Оперативная память не менее 16 Гб (рекомендуется от 32 Гб). 3. Емкость HDD не менее 400 Гб свободного места. 4. СУБД PostgreSQL 12.0 и выше 5. Операционная система. 5.1. Семейства Linux: - Ubuntu 20.04 LTS - Ubuntu 22.04 LTS - RedHat Enterprise Linux (version 8) - АльтЛинукс РС 10.2 (или выше) - РЕД ОС 8.0 - Astra Linux SE 1.8 - Альт СП 10 5.2. Семейства Windows: -Windows Server 2019 - Windows Server 2022 - Windows 10 - Windows 11 6. Доступ к серверу БД по протоколу TCP\IP. 7. При использовании ОС на базе Linux сервер: 7.1. Наличие графической оболочки (рабочего стола) 7.2. Возможность удаленного подключения по RDP (xRDP или аналог). 7.3. Возможность установки обновления для операционной системы, а также установки дополнительных пакетов (ПО) необходимых для работы сопровождаемого программного обеспечения из стандартных дистрибутивов Требования к видам обеспечения (3) 4.3.2 Сервер платформы СМЭВ Сервер платформы СМЭВ (сервер ЭП) – предназначен для автоматизации межведомственного электронного взаимодействия органов управления муниципальной собственностью в части формирования межведомственных запросов по протоколам СМЭВ в отношении объектов учета, субъектов права и договоров, зарегистрированных в единой базе данных Системы, а также автоматизации внесения изменений в базу данных Системы на основе полученных сведений. Требует для своей работы установку КриптоПро CSP версии не ниже 5.0. Заказчик организовывает наличие защищенного канала до СМЭВ (РСМЭВ). В случае невозможности организации защищенного канала для основного сервера, сервер платформы СМЭВ может быть размещен на отдельном сервере. Сервер платформы СМЭВ имеет конфигурацию не ниже следующей: 1. Операционная система. Windows: необходима подсистема WSL2 не ниже Windows Server 2019 (для серверов) не ниже Windows 10 22H2 должна быть включена виртуализация Linux: Astra Linux Ubuntu не ниже 22.04 Альт СП 10 2. Оперативная память не менее 64 Гб. 3. Процессор 4х ядерный процессор с тактовой частотой не менее 2 Ггц. 4. СУБД PostgreSQL не ниже 12. 5. Доступ к Web-серверу по протоколу TCP/IP (перечень портов согласовывается). 4.3.3 Сервер резервного копирования для единой базы данных Системы Сервер резервного копирования предназначен для хранения резервных копий. В качестве сервера можно использовать сетевую папку на стороннем компьютере или NAS хранилище с аналогичными характеристиками или любой из имеющихся серверов с малой производительностью, но достаточной дисковой подсистемой Требования к видам обеспечения (4) Сервер имеет емкость HDD не менее 500 Гб с возможностью увеличения по необходимости. 4.3.4 Клиентские рабочие места Клиентские рабочие места должны иметь следующую конфигурацию: 1. Процессор Intel Celeron 4900 или выше. 2. Количество ядер процессора: не менее 2. 3. Базовая тактовая частота процессора: не менее 3.10 Ггц. 4. Оперативная память не менее 4 Гб. 5. Жесткий диск 1 Гб свободного места на диске. 6. Операционная система – семейство Windows (Windows 7 и выше). 7. Офисный пакет 32 бит (для работы с отчетами и печатными формами). 8. Для работы межведомственного взаимодействия необходимо: 8.1. Яндекс браузер v.25 и выше, MS EDGE v20, Google Chrome v57 и выше, Opera v44 и выше, Firefox v52 и выше. 8.2. Браузер должен поддерживать HTML5, CSS3, выполнение JavaScript должно быть разрешено Требования к поставке (1) В рамках поставки Автоматизированной системы управления муниципальной собственностью (АС УМС) для нужд Управление имущественных отношений администрации Минераловодского муниципального округа Ставропольского края, Исполнитель должен Заказчику передать простые (неисключительные) права на условиях простой (неисключительной) лицензии в течение всего срока действия исключительного права на использование Системы в следующем составе: 1. 4 (четыре) клиентских места в режиме полнофункционального доступа, включающие следующие компоненты: 1.1. Подсистема «Имущество». 1.2. Подсистема «Земля». 1.3. Подсистема «Ведение информации по субъектам права». 1.4. Подсистема «Ведение информации по акциям». 1.5. «Адресная подсистема». 1.6. Подсистема «Ведение договоров и дополнительных соглашений» 1.7. Подсистема «Выкуп с рассрочкой». 1.8. «Финансово-аналитическая подсистема». 1.9. Подсистема «Автоматизация претензионной и исковой деятельности». 1.10. Аналитическая и сервисная подсистема «Библиотека запросов». 1.11. Подсистема «Формирование отчетов и печатных форм, генератор отчетов». 1.12. Подсистема «Обеспечение безопасности, администрирования и разграничения прав доступа». 1.13. Подсистема «Ведение нормативно-справочной информации». 1.14. Подсистема «Автоматическое обновление клиентских рабочих мест». 1.15. Подсистема «Оповещение пользователей». 1.16. Подсистема «Самодиагностика с оповещением о выявленных аномалиях по электронной почте» Требования к поставке (2) 1.17. Средства ведения электронных карточек объектов учета. 1.18. Средства поиска, отображения и анализа информации. 1.19. Средства предварительного просмотра. 1.20. Средства выполнения массовых операций. 2. Подсистема Межведомственное электронное взаимодействие. Платформа СМЭВ». 3. Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП». Клиентское место полного доступа должно обладать полнофункциональными возможностями всех компонентов в составе АС УМС в Управление имущественных отношений администрации Минераловодского муниципального округа Ставропольского края. В случае, если Исполнитель не является правообладателем Системы, то он должен являться официальным партнером Лицензиара (подтверждается заверенной копией партнерского договора участника с Лицензиаром) Требования к результатам оказания услуг (1) Результатом является поставка автоматизированной системы управления муниципальной собственностью (АС УМС) для Управление имущественных отношений администрации Минераловодского муниципального округа Ставропольского края. Документация должна быть предоставлена Заказчику в период исполнения контракта Исполнителем в одном экземпляре в электронном виде и соответствовать требованиям настоящего технического задания и государственных стандартов. Перечень подлежащих разработке Исполнителем видов и комплектов документов: 1. Руководство пользователя Системы. 2. Программа и методика испытаний. 3. Лицензионный договор на использование программного обеспечения на праве простой неисключительной лицензии. 4. Акт приема-передачи неисключительных прав на использование Системы в следующем составе: 1. 4 (четыре) клиентских места в режиме полнофункционального доступа, включающие следующие компоненты: 1.1. Подсистема «Имущество». 1.2. Подсистема «Земля». 1.3. Подсистема «Ведение информации по субъектам права». 1.4. Подсистема «Ведение информации по акциям». 1.5. «Адресная подсистема». 1.6. Подсистема «Ведение договоров и дополнительных соглашений» 1.7. Подсистема «Выкуп с рассрочкой» Требования к результатам оказания услуг (2) 1.8. «Финансово-аналитическая подсистема». 1.9. Подсистема «Автоматизация претензионной и исковой деятельности». 1.10. Аналитическая и сервисная подсистема «Библиотека запросов». 1.11. Подсистема «Формирование отчетов и печатных форм, генератор отчетов». 1.12. Подсистема «Обеспечение безопасности, администрирования и разграничения прав доступа». 1.13. Подсистема «Ведение нормативно-справочной информации». 1.14. Подсистема «Автоматическое обновление клиентских рабочих мест». 1.15. Подсистема «Оповещение пользователей». 1.16. Подсистема «Самодиагностика с оповещением о выявленных аномалиях по электронной почте». 1.17. Средства ведения электронных карточек объектов учета. 1.18. Средства поиска, отображения и анализа информации. 1.19. Средства предварительного просмотра. 1.20. Средства выполнения массовых операций. 2. Подсистема Межведомственное электронное взаимодействие. Платформа СМЭВ». 3. Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Класс программ для электронных вычислительных машин и баз данных - (02.07) Средства управления базами данных - - - Способ предоставления - Копия электронного экземпляра - - - Вид лицензии - Простая (неисключительная) - - - Клиентское место полного доступа, обладающее полнофункциональными возможностями всех компонентов в составе АС УМС в Управления имущественных отношений администрации Минераловодского муниципального округа Ставропольского края - ? 4 - Штука - - Клиентское место АС УМС полного доступа первое (Базовый комплект) – 1 единица - наличие - - - Клиентское место АС УМС полного доступа со 2 по 4 – 3 единицы - наличие - - - Платформа СМЭВ-Диалог – 1 единица - наличие - - - Подсистема «ГИС ГМП. Начисления, платежи, квитирование» – 1 единица - наличие - - - Назначение - Система должна быть предназначена для автоматизации деятельности по управлению земельными участками, недвижимым и движимым имуществом, путем сбора, систематизации, хранения, обработки информации в сфере имущественно-земельных отношений и организации электронного взаимодействия между пользователями Системы - - - Система должна быть построена по 3х-звенной архитектуре и состоять из следующих компонентов (1) - 1. Системы управления базами данных (СУБД) – предназначены для хранения и управления информацией базы данных Системы. Система должна быть совместима с СУБД Исполнителя или эквивалентной (далее - СУБД). В случае, если предлагаемая Исполнителем для использования СУБД не является свободно распространяемым программным обеспечением, то Исполнитель передает Заказчику права на использование СУБД без каких-либо ограничений на использование, в том числе без ограничений по сроку действия лицензии, количеству подключений, размеру используемых баз данных. СУБД не должна иметь ограничений по размеру базы данных и не должна требовать дополнительных обязательных расходов на сопровождение - - - Система должна быть построена по 3х-звенной архитектуре и состоять из следующих компонентов (2) - 2. Сервер приложений – промежуточное звено обеспечения взаимодействия клиентских мест и СУБД. Сервер приложений для Системы должен обеспечивать предоставление доступа клиентских мест к данным Системы, а также содержать средства обеспечения корректности исполнения технологических процессов (бизнес-логики) функционирования Системы. Сервер приложений не должен требовать ручного запуска перед началом работы пользователей Системы. С целью минимизации сетевого траффика сервер приложения должен обеспечивать передачу клиентским местам информацию порциями по настраиваемому количеству записей (количество записей, которое помещается на экран без прокрутки при любом из используемых разрешений экрана) по мере обращения. Передача информации на клиентское место из используемых справочников и классификаторов должна производиться при первом обращении к справочникам и классификаторам (за исключением системных справочников и классификаторов, необходимых для функционирования Системы в целом). Передача информации на клиентское место по открытым электронным карточкам объектов учета должна производиться только в том объеме, в котором информация отображается в соответствующий момент в карточке объекта учета. Например, информация, размещенная на неоткрытых вкладках карточки объекта учета, должна передаваться на клиентское место непосредственно в момент перехода на соответствующую вкладку - - - Система должна быть построена по 3х-звенной архитектуре и состоять из следующих компонентов (3) - 3. Клиентские места – «тонкий» (Desktop) клиент - пользовательские приложения, устанавливаемые на рабочих местах пользователей для предоставления доступа пользователей к функциям Системы или web-клиент. Клиентские места должны обеспечивать возможность доступа ко всему объему функционала Системы, который описан в разделе «Состав Системы, функциональные требования» - - - Требования к размещению средств обеспечения корректности исполнения технологических процессов (бизнес-логики) Системы (1) - Средства обеспечения корректности исполнения технологических процессов (бизнес-логики) в максимально возможном объеме должны быть реализованы на уровне базы данных (выполняться в автоматическом режиме на уровне СУБД). Данное требование продиктовано необходимостью корректной обработки информации при ее модификации в информационном фонде Системы любым из доступных способов вплоть до корректировки средствами СУБД (запуском скриптов непосредственно в базе данных), а также обеспечением возможности изменения технологических процессов пользователями Системы путем изменения логики реализации технологических процессов на стороне SQL - - - Требования к размещению средств обеспечения корректности исполнения технологических процессов (бизнес-логики) Системы (2) - На уровне СУБД должны быть реализованы следующие процессы (технологические процессы или их части): 1. Ведение аудита действий пользователей на уровне полей таблиц (конкретных атомарных атрибутов объектов учета, в том числе в составе составных характеристик). 2. Проверка прав пользователей (хранимые функции или процедуры проверки прав пользователей). 3. Поддержка функционирования средств «быстрого поиска» (по необходимости). 4. Начисление арендной платы, платы за выкуп, платы за фактическое использование объектов, всех видов штрафных санкций, включая начисление пени, процентов за пользование чужими денежными средствами. 5. Расчет сальдо. 6. Расчет задолженности на произвольную дату в произвольном разрезе. 7. Пересчет задолженности на текущее число по всем видам договорных отношений - - - Требования к размещению средств обеспечения корректности исполнения технологических процессов (бизнес-логики) Системы (3) - Средства обеспечения технологических процессов, которые не могут быть реализованы на стороне СУБД, должны быть реализованы средствами сервера приложения. Для удобства пользователей часть технологических процессов должна быть продублирована на клиентском месте для обеспечения своевременности информирования пользователя о недопустимости производимых им изменений в момент совершения изменения (до передачи/сохранения изменений на сервер приложения или в базу данных). Например, при удалении из карточки объекта информации, которая используется в информации в карточках других объектов средства проверки допустимости операции (контроль ссылочной целостности) должны быть исполнены непосредственно в момент выполнения операции, а не в момент пакетного сохранения всех выполненных изменений в карточке объекта учета (нажатие пользователем кнопки «Сохранить изменения» или эквивалент). При этом в момент сохранения изменений соответствующая проверка должна быть выполнена повторно средствами сервера приложения или СУБД непосредственно в момент сохранения изменений карточки в рамках соответствующей транзакции. Таким образом, на клиентском месте должны быть продублированы те элементы технологических процессов, которые могут определить некорректные действия пользователя непосредственно в момент их совершения, а не в момент пакетного сохранения выполненных изменений - - - Требования к способам и средствам связи для информационного обмена между компонентами Системы - Система должна обеспечивать коллективную работу пользователей объекта автоматизации с использованием единого интегрированного хранилища данных по технологии «клиент-сервер» с использованием трехзвенной архитектуры - - - Требования к приспособляемости Системы - Функциональность Системы реализуется, как расширяемая, т.е. должна допускать наращивание функциональных возможностей на основе подключения дополнительных (или изменения существующих) подсистем в связи с изменением существующих и возникновением новых автоматизируемых процессов, обусловленных изменениями в нормативно-законодательной базе. Подсистемы должны иметь программные интерфейсы, обеспечивающие возможность расширения функциональности Системы путём добавления компетентными, обученными пользователями Системы дополнительных программных модулей. Система должна быть гибкой, т.е. легко настраивающейся на изменения условий функционирования и организационной структуры объектов автоматизации Системы. Система должна сохранять работоспособность при увеличении количества пользователей в пределах, поддерживаемых аппаратно-программной средой серверов технологического узла. Должна быть обеспечена возможность увеличения числа пользователей Системы - - - Требования к защите информации от несанкционированного доступа (1) - Подсистемы должны отвечать требованиям к защите данных от несанкционированного доступа. Система должна обеспечивать идентификацию и аутентификацию пользователя, обратившегося для получения доступа к функциям Системы. В Системе должны быть обеспечены разграничение и администрирование доступа к компонентам Системы. Применение вышеуказанных средств защиты информации должно осуществляться пользователями Системы в соответствии с ведомственными нормативными актами и регламентами. Механизмы безопасности Системы должны позволять ограничивать круг лиц, принимающих участие в работе с данными, и позволять контролировать процесс работы с защищенными документами и знать, откуда возможна утечка информации - - - Требования к защите информации от несанкционированного доступа (2) - Защита информации от несанкционированного доступа в Системе должна обеспечиваться реализацией следующих функций Системы: 1. Предоставление доступа к Системе должно предоставляться только предварительно зарегистрированным пользователям. 2. Возможность разграничения доступа к подсистемам для каждого пользователя. 3. Возможность для каждого пользователя установить уровень доступа, обеспечивающий только просмотр или редактирование информации. 4. Управление разграничением и/или уровнями доступа пользователей должно осуществляться через группы доступа. 5. Разграничение по доступу к данным Системы должно быть согласно утвержденным полномочиям пользователей Системы. 6. Регистрация входа (выхода) пользователей в Систему (из Системы) должна фиксироваться в журнале действий пользователей. 7. Должна быть возможность функционального разграничения действий пользователей при обработке информации. 8. Ведение справочника пользователей Системы. 9. Журналирование действий пользователей, которое должно обеспечиваться путем ведения в Системе «журнала событий», доступного только с автоматизированного рабочего места администратора и включающего в себя следующие данные: 9.1. Системные действия: дата, событие, пользователь. 9.2. Действия над пользователями Системы: дата, событие, администратор. 9.3. Действия пользователей. «Журнал событий» должен быть недоступен к внесению изменений - - - Требования к защите информации от несанкционированного доступа (3) - Система должна обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях Система должна выдавать пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных. Должна быть предусмотрена возможность резервного копирования и ручного восстановления стандартными средствами системы управления базой данных (далее – СУБД) администраторами Системы обрабатываемой информации из резервной копии в следующих аварийных ситуациях: 1. Ошибочные действия пользователей (администраторов), приведшие к утрате или искажению данных Системы. 2. Отказ Системы, связанный с фатальным нарушением целостности файловой системы или структуры баз данных. Для резервного копирования должны использоваться штатные средства системной программной платформы, причем организация баз данных Системы должна обеспечивать сохранение: 1. Всех параметров настройки Системы, включая учетные записи и персональные настройки пользователей. 2. Всей информации Системы - - - Требования к патентной чистоте - Система должна отвечать требованиям по патентной чистоте согласно действующему законодательству Российской Федерации, в Системе не должны использоваться решения, приводящие к нарушению смежных прав и прав третьих лиц, защищенные патентами или иными действующими на территории Российской Федерации документами, удостоверяющими авторские права на них, без соответствующего лицензионного соглашения с авторами данных решений. Выполнение требований по обеспечению лицензионной чистоты Системы возлагается на Исполнителя - - - Требования к контролю, хранению, обновлению и восстановлению данных - Контроль корректности данных должен обеспечиваться реализацией функций форматного, логического контроля на уровне пользовательских форм. Для хранения данных Системы должна использоваться СУБД, средствами которой выполняются действия записи, обновления, журналирования изменений, резервного копирования и восстановления данных - - - Требования к лингвистическому обеспечению - В системных диалогах с пользователями в текстах сообщений должен применяться русский язык. Содержание используемых в Системе справочников должно быть реализовано на русском языке - - - Состав системы, функциональные требования - Система состоит из следующих подсистем, средств и других элементов, выполняющих соответствующие функции: 1. Подсистема «Имущество». 2. Подсистема «Земля». 3. Подсистема «Ведение информации по субъектам права». 4. Подсистема «Ведение информации по акциям». 5. «Адресная подсистема». 6. Подсистема «Ведение договоров и дополнительных соглашений» 7. Подсистема «Выкуп с рассрочкой». 8. «Финансово-аналитическая подсистема». 9. Подсистема «Автоматизация претензионной и исковой деятельности». 10. Аналитическая и сервисная подсистема «Библиотека запросов». 11. Подсистема «Формирование отчетов и печатных форм, генератор отчетов». 12. Подсистема «Обеспечение безопасности, администрирования и разграничения прав доступа». 13. Подсистема «Ведение нормативно-справочной информации». 14. Подсистема «Автоматическое обновление клиентских рабочих мест». 15. Подсистема «Оповещение пользователей». 16. Подсистема «Самодиагностика с оповещением о выявленных аномалиях по электронной почте». 17. Средства ведения электронных карточек объектов учета. 18. Средства поиска, отображения и анализа информации. 19. Средства предварительного просмотра. 20. Средства выполнения массовых операций. 21. Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ. 22. Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» - - - Подсистема «Имущество» (1) - Подсистема «Имущество» должна автоматизировать ведение реестра объектов муниципальной собственности, а также внереестровых объектов всех учитываемых типов. Доступ к объектам имущества должен осуществляться из основного окна Системы с использованием иерархического меню. Перечень учитываемых типов и конкретная настройка иерархического меню доступа к объектам должны быть определены на этапе обследования организации. Например, иерархическое меню доступа и перечень учитываемых типов объектов могут быть настроены в ручном режиме, например, в соответствии со схемой: 1. Недвижимое имущество: 1.1. Жилой фонд: 1.1.1. Жилые здания. 1.1.2. Жилые квартиры, помещения. 1.1.3. Жилые комнаты. 1.2. Нежилые здания. 1.3. Нежилые помещения. 1.4. Объекты незавершенного строительства. 1.5. Объекты инженерной инфраструктуры, сооружения. 1.6. Объекты внешнего благоустройства. 1.7. Доли. 1.8. Нематериальные активы, объекты интеллектуальной собственности. 1.9. Воздушные и морские суда, суда внутреннего плавания. 1.10. Космические объекты. 1.11. Прочие объекты, не включенные в указанные группировки. 2. Движимое имущество: 2.1. Особо ценное движимое имущество. 2.2. Малоценное (прочее) движимое имущество. 2.3. Транспортные средства. 2.4. Объекты инженерной инфраструктуры. 2.5. Прочее движимое имущество, не относящиеся к указанным выше. 3. Акции, паи, доли. 4. Имущественные комплексы. 5. Муниципальные предприятия и учреждения. Должна быть предусмотрена возможность скрытия неиспользуемых на момент внедрения пунктов меню (видов объектов учета) - - - Подсистема «Имущество» (2) - Подсистема должна автоматизировать выполнение следующих основных задач. 1. Учет объектов. Для каждого из объектов должна вестись следующая основная информация: 1.1. Наименование объекта. 1.2. Принадлежность к реестру, подреестру (с историей изменения и ссылками на документы-основания). 1.3. Реестровый номер (с историей изменения и ссылками на документы-основания). 1.4. Кадастровый номер (не обязательный для заполнения, при наличии – обязательный для заполнения), условный номер. 1.5. Адрес (с возможностью ввода множественного адреса). 1.6. Субъекты права (движение на балансе, другие субъекты права) – с историей изменения, множественностью документов-оснований возникновения и прекращения права (ссылки на документы). 1.7. Экономические показатели (балансовые, остаточные стоимости и др.) – с историей изменения и ссылками на документы-основания. 1.8. Технические показатели (с историей изменения и ссылками на документы-основания). 1.9. Документы (все документы, имеющие отношение к данному объекту с делением по направлениям воздействия документов (включение/исключение, внесение изменений, правоустанавливающие, регистрирующие документа) – без ограничения количества и типов регистрируемых документов). 1.10. Комиссии. 1.11. Коэффициенты-характеристики, площадь (с историей изменения и ссылками на документы-основания). 1.12. Части помещений (подвал, полуподвал, этажи): 1.12.1. Коэффициенты-характеристики частей помещений, площадь (с историей изменения и ссылками на документы-основания). 1.12.2. Типы использования частей помещений (с историей изменения и ссылками на документы-основания). 1.12.3. Материал стен, варианты входа, уровни благоустройства, высота потолков – произвольное количество категорий благоустройства с произвольным количеством выбираемых элементов благоустройства в каждой категории, предусмотрена возможность указания уровней благоустройства объекта целиком и каждой из частей помещения отдельно. 1.13. Принадлежность к земельному участку (множественная связь – один - - - Подсистема «Имущество» (3) - 1.15. Признак принадлежности к объектам культурного наследия, а также информация о включении объекта в реестр объектов культурного наследия (Номер в реестре, категория историко-культурного наследия – справочник, Признак принадлежности объекта к объектам религиозного значения, признак принадлежности объекта к ансамблям, ссылка на документ-основание с возможностью указания нескольких документов оснований и период нахождения объекта в реестре с возможностью учета разных периодов включения объектов и соответственно разных данных по нахождению объекта в реестре). 1.16. Информация по проводимым аукционам, торгам, конкурсам. 1.17. Классификация объектов учета – предусмотрена возможность учета произвольного количества категорий классификации с произвольным количеством элементов классификации в каждой из категорий, а также текстовым описанием каждого элемента – с историей изменений и ссылками на документы-основания присвоения элемента классификации и исключения объекта из классификации (множественность документов-ссылок). 1.18. События (даты) – с историей изменений и ссылкой на документ-основание. 1.19. Признаки («галочки») - принадлежность к чему-либо с текстовым описанием признака. 1.20. Договоры использования и обременения (аренды, купли-продажи, безвозмездного пользования, согласования, разрешения, размещения, сервитуты). 1.21. Информация по претензионной и исковой деятельности (детальная информация по поданным претензиям и искам, включая необходимую классификационную и описательную части, предметы исков, в том числе суммы с делением по видам начислений, перечень этапов претензионной и исковой деятельности с указанием ссылок на документы этапа, уточнение требований) – см. пункт «Подсистема автоматизации претензионной и исковой деятельности» - - - Подсистема «Имущество» (4) - 2. Автоматическое присвоение реестрового номера с возможностью настройки методики и структуры формирования номера, а также возможностью организации сквозной нумерации по нескольким видам объектов учета (настройка категорий нумерации, для каждой категории можно указать перечень видов объектов учета, входящих в категорию). 3. Ведение информации по подобъектам, составным частям объектов. 4. Управление историей изменения основных характеристик объектов и документами-основаниями на проведение изменений. 5. Управление движением объектов в реестре (включение, исключение, перемещение между реестрами, ведение истории реорганизации объектов (слияния, разделения)). 6. Управление движением объектов на балансе и в казне, договорами оперативного управления и хозяйственного ведения. 7. Обеспечение информационного взаимодействия/обмена информацией по объектам муниципальной собственности с субъектами права (балансодержателями и др.) – массовое обновление стоимостных показателей (балансовая, остаточная стоимость, износ), характеристик объектов. 8. Управление движением объектов в казне (с возможностью ведения балансового и забалансового бюджетного учета движения объектов в казне). 9. Ведение документального обеспечения (документов-оснований) движения объектов, изменения характеристик объектов в реестре. 10. Ведение аукционов и торгов на право аренды или купли-продажи объектов. 11. Формирование реестров объектов муниципальной собственности. 12. Формирование выписок из реестров, справок о движении объектов, проектов приказов, постановлений, распоряжений, других необходимых печатных форм. 13. Формирование аналитической отчетности. 14. Проведение экспресс-аналитики. 15. Корректное проставление даты выбытия объекта в зависимости от выбранного документа основания (например, выбытие по исключению из реестра или из-за регистрации права собственности за иным лицом) - - - Подсистема «Имущество» (5) - 16. Возможность указания шаблона для вывода адреса в нужном формате. 17. Возможность работы со справочниками ФИАС при формировании адреса. 18. Управление историей объектов для отслеживания хронологии реорганизации, разделения, объединения объекта. 19. Протоколирование действий пользователей. 20. Возможность прикрепления к карточке объекта учета произвольного количества файлов произвольного типа. 21. Возможность ведения внереестровых объектов. Должна быть предусмотрена возможность смены типа объектов, включенных по ошибке в другие подразделы имущества (в том числе объектов прошлых периодов), например, изменить тип «нежилое здание» на «нежилое помещение» или на «сооружение» и наоборот - - - Подсистема «Земля» (1) - Подсистема «Земля» должна автоматизировать ведение реестров земельных участков, собственность на которую разграничена, а также ведение земельных участков, собственность на которые не разграничена или с другими видами собственности, находящихся в сфере компетенции органов управления земельными ресурсами. Подсистема должна автоматизировать выполнение следующих основных задач: 1. Пообъектный учет земельных участков (ЗУ). Для каждого из ЗУ ведется следующая основная информация: 1.1. Наименование ЗУ. 1.2. Принадлежность к реестру, подреестру (с историей изменения). 1.3. Кадастровый номер (кадастровый квартал выбирается из классификатора, не обязательный для заполнения). 1.4. Категория земель (с историей изменения и ссылками на документы-основания). 1.5. Разрешенное использование (с историей изменения и ссылками на документы-основания). 1.6. Уровень собственности (состояние). 1.7. Реестровый номер (с историей изменения и ссылками на документы-основания). 1.8. Адрес, адресный ориентир (с возможностью ввода множественного адреса). Должна быть предусмотрена возможность указания государственного образования для обеспечения возможности дальнейшего отбора земельных участков по соответствующему показателю. 1.9. Субъекты права (землепользователи, другие субъекты права) – с историей изменения, множественностью документов-оснований возникновения и прекращения права (ссылки на документы), в том числе и права постоянного (бессрочного) пользования. 1.10. Экономические показатели (Кадастровые стоимости и др.) – с историей изменения и ссылками на документы-основания. 1.11. Технические показатели (с историей изменения и ссылками на документы-основания). 1.12. Документы (все документы, имеющие отношение к данному объекту с делением по направлениям воздействия документов (включение/исключение, внесение изменений, правоустанавливающие, регистрирующие документа)). 1.13. Комиссии. 1.14. Коэффициенты-характеристики, площадь (с историей изменения и ссылками на документы-основания) - - - Подсистема «Земля» (2) - 1.15. Информация по использованию ЗУ (классификация для аналитики, ставки арендной платы, типы использования для кадастровой оценки, налоговые ставки по типам использования) с возможностью указания различных типов использования долей земельного участка (с историей изменения и ссылками на документы-основания). 1.16. Перечень объектов недвижимого имущества, размещенных на данном участке. (кадастровый номер, наименование, права) 1.17. Информация по проводимым аукционам, торгам, конкурсам. 1.18. Классификация объектов учета – предусмотрена возможность учета произвольного количества категорий классификации с произвольным количеством элементов классификации в каждой из категорий, а также текстовым описанием каждого элемента – с историей изменений и ссылками на документы-основания присвоения элемента классификации и исключения объекта из классификации (множественность документов-ссылок). 1.19. Информация по претензионной и исковой деятельности (детальная информация по поданным претензиям и искам, включая необходимую классификационную и описательную части, предметы исков, в том числе суммы с делением по видам начислений, перечень этапов претензионной и исковой деятельности с указанием ссылок на документы этапа, уточнение требований) – см. Пункт «Подсистема автоматизации претензионной и исковой деятельности». 1.20. События (даты) – с историей изменений и ссылкой на документ-основание. 1.21. Признаки («галочки») - принадлежность к чему-либо с текстовым описанием признака. 1.22. Договоры использования и обременения (аренды, купли-продажи, безвозмездного пользования, согласования, разрешения, размещения, сервитуты) - - - Подсистема «Земля» (3) - 2. Автоматическое присвоение реестрового номера с возможностью настройки методики и структуры формирования номера, а также возможностью организации сквозной нумерации по нескольким видам объектов учета (настройка категорий нумерации, для каждой категории можно указать перечень видов объектов учета, входящих в категорию). 3. Управление историей изменения основных характеристик ЗУ, документами-основаниями на проведение изменений. 4. Управление движением ЗУ в реестре (включение, исключение, перемещение между реестрами, ведение истории реорганизации объектов (слияния, разделения)). 5. Управление движением ЗУ по субъектам права. 6. Управление движением ЗУ в казне (с возможностью ведения балансового и забалансового бюджетного учета движения объектов в казне). 7. Ведение документального обеспечения (документов-оснований) движения ЗУ, изменения характеристик объектов в реестре. 8. Ведение аукционов и торгов на право аренды или купли-продажи ЗУ. 9. Формирование реестров земельных участков. 10. Формирование выписок из реестра, справок о движении ЗУ, проектов приказов, постановлений, распоряжений, других необходимых печатных форм. 11. Формирование аналитической отчетности в соответствующей сфере. 12. Проведение экспресс-аналитики. 13. Корректное проставление даты выбытия объекта в зависимости от выбранного документа основания (например, выбытие по исключению из реестра или из-за регистрации права собственности за иным лицом). 14. Возможность указания шаблона для вывода адреса в нужном формате. 15. Возможность работы со справочниками ФИАС при формировании адреса. 16. Управление историей объектов для отслеживания хронологии реорганизации, разделения, объединения объекта. 17. Протоколирование действий пользователей. 18. Возможность прикрепления к карточке объекта учета произвольного количества файлов произвольного типа. 19. Возможность ведения внереестровых объектов - - - Подсистема «Ведение информации по субъектам права» (1) - Подсистема должна обеспечивать ведение информации по муниципальным предприятиям и учреждениям (как реестровым объектам), а также по субъектам права, участвующих в имущественно-земельных отношениях (юридические, физические лица, индивидуальные предприниматели). Подсистема должна автоматизировать выполнение следующих основных задач: 1. Пообъектный учет субъектов права. Для каждого из субъектов права ведется следующая основная информация: 1.1. Наименование субъекта права (полное и краткая информация, с историей изменения). 1.2. ИНН. 1.3. Принадлежность к реестру, подреестру (с историей изменения и ссылкой на документ-основание). 1.4. Реестровый номер (с историей изменения и ссылкой на документ-основание). 1.5. Адрес (с возможностью ввода множественного адреса), структура адреса должна соответствовать федеральным требованиям (ФИАС). Система должна обеспечивать возможность автоматизированного обновления классификаторов адресной подсистемы на основе ФИАС. 1.6. Организационная форма, вид деятельности, вид собственности (классификаторы). 1.7. Контакты - руководитель, главный бухгалтер, другие сотрудники (произвольное количество), телефоны (произвольное количество), банковские реквизиты (с историей изменения), реквизиты трудовых договоров руководителя и главного бухгалтера с возможность загрузки в систему самих договоров и дополнительных соглашений к ним, а также реквизитов документов о назначении и увольнении руководителей с возможностью загрузки в систему указанных документов. 1.8. Информация по членам семьи, родственным отношениям (для физических лиц). 1.9. Паспортные данные (для физических лиц, индивидуальных предпринимателей) – с историей изменения, дата рождения. 1.10. Субъекты права (представители, учредители) – с историей изменения и ссылками на документы-основания, возможностью расширения в части регистрации произвольного количество субъектов права произвольного типа (любого вида права, с возможностью расширения) - - - Подсистема «Ведение информации по субъектам права» (2) - 1.11. Экономические показатели (балансовая, остаточная стоимость объектов на балансе, среднесписочная численность сотрудников, показатели эффективности) – с историей изменения и ссылками на документы-основания. Должна быть обеспечена возможность учета произвольного количества экономических показателей любого типа с возможностью расширения средствами системы. Минимальный набор показателей эффективности: ? основные средства; ? финансовые вложения; ? отложенные налоговые активы; ? прочие внеоборотные активы; ? запасы; ? дебиторская задолженность; ? финансовые вложения (за исключением денежных эквивалентов); ? денежные средства и денежные эквиваленты; ? прочие оборотные активы; ? уставный капитал/фонд; ? добавочный капитал (без переоценки); ? резервный капитал; ? нераспределенная прибыль (непокрытый убыток); ? чистые активы; ? заемные средства; ? отложенные налоговые обязательства; ? оценочные обязательства; ? прочие обязательства; ? заемные средства; ? кредиторская задолженность; ? доходы будущих периодов; ? оценочные обязательства; ? прочие обязательства; ? выручка; ? себестоимость продаж; ? валовая прибыль (убыток); ? коммерческие расходы; ? управленческие расходы; ? прибыль (убыток) от продаж; ? доходы от участия в других организациях; ? проценты к получению; ? проценты к уплате; ? прочие доходы; ? прочие расходы; ? прибыль (убыток) до налогообложения; ? налог на прибыль; ? в том числе: ? текущий налог на прибыль; ? отложенный налог на прибыль; ? прочее; ? чистая прибыль (убыток). Программа должна предусматривать возможность загружать скан-образы бухгалтерской (финансовой) отчетности и планов (программ) финансово-хозяйственной деятельности. Также Программа должна предусматривать возможность ведения основных плановых и фактических показателей результатов финансово-хозяйственной деятельности. - - - Подсистема «Ведение информации по субъектам права» (3) - 1.12. Классификационные коды (ОКВЭД, ОКОНХ, ОГРН, КПП) – с ведением истории и ссылками на документы-основания, с возможностью расширения перечня учитываемых кодов без участия программистов. 1.13. Информация по документам (все документы, имеющие отношение к данному объекту с делением по направлениям воздействия документов (включение/исключение, внесение изменений, правоустанавливающие, регистрирующие документа)). Должна быть обеспечена возможность учета информации по произвольному количеству документов любого типа с возможностью расширения средствами системы. 1.14. Комиссии. 1.15. События (даты жизненного цикла объекта) с возможностью расширения количества и типов событий средствами системы. 1.16. Признаки (принадлежности к определенным учетным категориям, группам в соответствии с технологией учета) с возможностью расширений наименований признаков средствами системы. 1.17. Перечень объектов имущества на балансе и в пользовании. 1.18. Перечень земельных участков в землепользовании и в пользовании (аренда). 1.19. Перечень договоров всех типов для объектов имущества (аренда, купля/продажа, безвозмездное пользование, социальный найм). 1.20. Перечень договоров всех типов для земельных участков (аренда, купля/продажа, безвозмездное пользование). 1.21. Полная финансовая информация по всем видам договоров (начисления, платежи, задолженность). Для ГУП должна содержаться следующая информация: ? о долговых обязательствах с расшифровкой по каждому кредитору, а также с возможностью перехода к реестру договоров субъекта, в котором можно получить доступ к реквизитам заключенных договоров, существенными условиями по каждому договору, основному долгу и процентам; ? о крупных сделках, в том числе с возможностью перехода в карточку сделки, для просмотра реквизитов документа, которым она согласована и ее существенных условий. С возможностью загрузки в Систему документа, которым согласована сделка - - - Подсистема «Ведение информации по субъектам права» (4) - 1.22. Информация по банкротству. 1.23. Информация по претензионной и исковой деятельности (детальная информация по поданным претензиям и искам, включая необходимую классификационную и описательную части, предметы исков, в том числе суммы с делением по видам начислений, перечень этапов претензионной и исковой деятельности с указанием ссылок на документы этапа, уточнение требований) – см. Пункт «подсистема автоматизации претензионной и исковой деятельности». 2. Управление историей изменения основных данных по субъектам права, документами-основаниями на проведение изменений. 3. Управление движением субъектов права в реестре и списках учета (включение, исключение, перемещение между реестрами, ведение истории реорганизации объектов (слияния, разделения)), документами-основаниями, правоустанавливающими и другими документами. 4. Использование информации по субъектам права при формировании договоров, дополнительных соглашений, других документов, при формировании информации о других имущественно-земельных отношениях с участием соответствующих субъектов права. 5. Формирование аналитики по деятельности субъекта права в рамках имущественно-земельных отношений. 6. Формирование аналитики по задолженности, работа с должниками. 7. Возможность формирования аналитической отчетности в соответствующей сфере (с использованием встроенных средств генераторов отчетов). 8. Проведение экспресс-аналитики - - - Управления предприятиями банкротами - В Системе должна быть реализована возможность управления информацией о предприятиях банкротах, а также процессах и стадиях банкротства. В рамках данной функции должна быть предусмотрена возможность ведения следующей информации: 1. Перечень стадий банкротства (внешнее наблюдение, конкурсное управление). 2. Информацию об управляющих компаниях и саморегулирующихся организациях. 3. Перечень заседаний руководства для обсуждения текущих вопросов. 4. Сведения о публикации сведений о банкротстве. 5. Реестр требований кредиторов для реструктуризации задолженности. 6. Информация о конкурсной массе на момент открытия конкурсного производства. 7. Периоды изменения всех вышеперечисленных атрибутов. 8. Информация о всех документах, связанных со всеми процессами банкротства, а также связи данных документов с теми атрибутами, на изменение которых они направлены. 9. Ведение данной информация позволит эффективно отслеживать все процессы, связанные с банкротством, и оперативно предпринимать меры по улучшению финансового состояния должника - - - Подсистема «Ведение информации по акциям» - В Системе должна быть возможность ведения информации об акциях (долях), находящихся в собственности муниципального образования. В рамках подсистемы помимо стандартных атрибутов должна быть предусмотрена возможность ведения следующей информации: 1. Субъекты акций (сведения об эмитенте, совете директоров, ревизионных комиссиях). 2. Субъекты долей (сведения об обществе, совете директоров, ревизионных комиссиях). 3. Заседания совета директоров и общего собрания акционеров (участников), включая возможность фиксации решения собрания, загрузки протоколов. 4. Информация о стоимостях акций (долей) и количестве акций (в разрезах видов акций). 5. Сведения о собраниях советов директоров и ревизионных комиссий (включая состав совета, протокол). 6. Бюджетный учет акций (долей) в казне. 7. Сведения об эмитенте (обществе) должны содержать информацию, указанную в пунктах 1.7 (в отношении генерального директора) и 1.11 в разделе 4.3 настоящего технического задания, а также возможность перехода в реестр договоров для получения информации о долговых обязательствах с расшифровкой по каждому кредитору, реквизитами заключенных договоров, существенными условиями по каждому договору, основному долгу и процентам. 8. Информацию о крупных сделках, в том числе с возможностью перехода в карточку сделки, для просмотра реквизитов документа, которым она согласована и ее существенных условий. С возможностью загрузки в Систему документа, которым согласована сделка - - - «Адресная подсистема» - «Адресная подсистема» (средства формирования адресов объектов для реестровой подсистемы учета) должна обеспечивать возможность формирования и учета произвольного количества адресов для каждого объекта учета. Для каждого из адресов должна быть предусмотрена возможность указания типа адреса на основе расширяемого классификатора (присвоенный адрес – официальный, юридический адрес, предыдущий адрес (при наличии) и адресного ориентира (местоположение объекта учета). Присвоенный адрес – официальный, должен быть один. «Адресная подсистема» должна обеспечивать возможность указания адресных реквизитов, утвержденных, постановлением Правительства РФ от 19.11.2014 № 1221 как с использованием собственных справочников и классификаторов присвоенных адресов или установленных ранее, включая адресный ориентир, так и с использованием базы федеральной информационной адресной системы (ФИАС). «Адресная подсистема» должна обеспечивать возможность настройки шаблона вывода адреса (формирования строки адреса) для каждого из типов объектов учета (наименований реестров объектов учета). Шаблон должен обеспечивать возможность указания адресных реквизитов в соответствии с требованиями к структуре адреса, например, , , , , или , , , и т.п. Строка адреса обязательно отображается в карточке объекта учета и в списке объектов учета соответствующего типа. «Адресная подсистема» должна обеспечивать возможность ввода адреса любых объектов учета, включая адреса комнат, офисов, территорий и т.д. Должна быть предусмотрена возможность указания адресного ориентира - - - «Адресная подсистема» (2) - «Адресная подсистема» должна обеспечивать возможность ввода адреса следующей структуры: 1. Наименование страны (Российская Федерация) – выбирается из справочника. 2. Наименование субъекта Российской Федерации – выбирается из справочника. 3. Наименование муниципального района, городского округа или внутригородской территории (для городов федерального значения) в составе субъекта Российской Федерации – выбирается из справочника. 4. Наименование городского или сельского поселения в составе муниципального района (для муниципального района) или внутригородского района городского округа – выбирается из справочника. 5. Наименование населенного пункта – выбирается из справочника. 6. Наименование элемента планировочной структуры – выбирается из справочника. 7. Наименование элемента улично-дорожной сети – выбирается из справочника присвоенных наименований элементам УДС. 8. Номер земельного участка. 9. Тип и номер здания, сооружения или объекта незавершенного строительства. 10. Тип и номер помещения, расположенного в здании или сооружении. Перечень элементов планировочной структуры (справочник), элементов улично-дорожной сети (справочник), элементов объектов адресации, типов зданий (сооружений) и помещений, используемых в качестве реквизитов адреса (справочники), а также правила сокращенного наименования адресообразующих элементов устанавливаются Министерством финансов Российской Федерации. Для зависимых справочников должна быть предусмотрена возможность автоматической подфильтровки допустимых для выбора элементов при заполнении элементов вышестоящих классификаторов, от которых зависят данные. Если значения вышестоящих классификаторов не заданы, то при выборе элемента некоторого зависимого справочника элементы вышестоящих справочников должны заполниться (выбраться автоматически) - - - Особенности работы адресной подсистемы при использовании ФИАС - При использовании сведений об адресе из ФИАС ввод или изменение адреса объекта учета должно производиться в отдельной строке экранной формы объекта учета с обязательным внесением уникального номера адреса объекта адресации из государственного адресного реестра. Структура базы данных для хранения данных ФИАС должна полностью соответствовать структуре данных ФИАС. Элементы ФИАС должны быть расположены в отдельной базе данных Системы, для которой должен быть предоставлен отдельный режим обслуживания и резервного копирования. В адресной подсистеме должен быть предусмотрен режим обновления во всех подсистемах Системы адресообразующих элементов, включая уникальный номер адреса объекта адресации в государственном адресном реестре базы данных ФИАС - - - Подсистема управления договорами и дополнительными соглашениями должна автоматизировать выполнение всех задач ведения соответствующих договорных отношений и претензий за фактическое использование объектов без заключения договорных отношений. Подсистема «Имущество» автоматизирует ведение договоров и других правовых отношений следующих типов: 1. Договор социального найма жилья (для объектов жилого фонда). 2. Договор специализированного найма жилья (для объектов жилого фонда). 3. Договоры на согласовании (при заключении договора балансодержателями имущества). 4. Договор аренды. 5. Договор купли/продажи/приватизации. 6. Договор выкупа с рассрочкой. 7. Договор безвозмездного пользования объектов движимого имущества. 8. Договор безвозмездного пользования недвижимого имущества, имущественных комплексов. 9. Договор мены. 10. Договор дарения. 11. Договор на установку и эксплуатацию рекламных конструкций. 12. Распорядительный документ по праву постоянного бессрочного пользования. 13. Разрешение на установку и эксплуатацию рекламных конструкций. 14. Договор на размещение информационных конструкций. 15. Решение о регистрации информационных конструкций. Подсистема «Земля» автоматизирует ведение договоров и других правовых отношений следующих типов: 1. Договор аренды. 2. Договор купли-продажи земельного участка, заключенный по итогам аукциона. 3. Договор купли-продажи земельного участка без торгов (в том числе с рассрочкой платежей). 4. Соглашение о перераспределении земельных участков. 5. Договор безвозмездного пользования. 6. Соглашение о сервитуте (публичном сервитуте). 7. Разрешения на использование земельного участка без его предоставления и установления сервитута. 8. Претензия за фактическое использование участка без заключения договора (расчеты в соответствии с требованиями Гражданского кодекса РФ) - Подсистема управления договорами и дополнительными соглашениями должна автоматизировать выполнение всех задач ведения соответствующих договорных отношений и претензий за фактическое использование объектов без заключения договорных отношений. Подсистема «Имущество» автоматизирует ведение договоров и других правовых отношений следующих типов: 1. Договор социального найма жилья (для объектов жилого фонда). 2. Договор специализированного найма жилья (для объектов жилого фонда). 3. Договоры на согласовании (при заключении договора балансодержателями имущества). 4. Договор аренды. 5. Договор купли/продажи/приватизации. 6. Договор выкупа с рассрочкой. 7. Договор безвозмездного пользования объектов движимого имущества. 8. Договор безвозмездного пользования недвижимого имущества, имущественных комплексов. 9. Договор мены. 10. Договор дарения. 11. Договор на установку и эксплуатацию рекламных конструкций. 12. Распорядительный документ по праву постоянного бессрочного пользования. 13. Разрешение на установку и эксплуатацию рекламных конструкций. 14. Договор на размещение информационных конструкций. 15. Решение о регистрации информационных конструкций. Подсистема «Земля» автоматизирует ведение договоров и других правовых отношений следующих типов: 1. Договор аренды. 2. Договор купли-продажи земельного участка, заключенный по итогам аукциона. 3. Договор купли-продажи земельного участка без торгов (в том числе с рассрочкой платежей). 4. Соглашение о перераспределении земельных участков. 5. Договор безвозмездного пользования. 6. Соглашение о сервитуте (публичном сервитуте). 7. Разрешения на использование земельного участка без его предоставления и установления сервитута. 8. Претензия за фактическое использование участка без заключения договора (расчеты в соответствии с требованиями Гражданского кодекса РФ) - - - Подсистема «Ведение договоров и дополнительных соглашений» (2) - Подсистема управления договорами и дополнительными соглашениями должна автоматизировать решение следующих основных задач: 1. Учет всех условий договоров и дополнительных соглашений. По каждому договору и доп. соглашению ведется следующая основная информация: 1.1. Номер и дата договора, доп. соглашения, номер и дата регистрации. 1.2. Код бюджетной классификации. 1.3. Тип использования, целевое использование. 1.4. Дата начала фактического использования объекта договора (для определения периода фактического использования). 1.5. Дата начала действия, планируемого и фактического окончания (расторжения), дата фактического освобождения объекта (для определения периода фактического использования объекта после расторжения договора). 1.6. Особые условия, ограничения. 1.7. Документы-основания, документы на льготы, другие документы. 1.8. Комиссии. 1.9. Объекты договора (может быть несколько объектов в договоре) – с возможностью указания периода нахождения объекта или его доли в договоре, доли объектов учета по договору – с историей изменения величины доли. 1.10. Формула (алгоритм) расчета планируемой платы по договору (индивидуально для каждого объекта или доли объекта в договоре) – с историей изменения. 1.11. Коэффициенты, ставки, индивидуальные показатели, другие характеристики, участвующие в автоматическом расчете планируемой арендной платы (индивидуально по каждому объекту в договоре) – с историей изменения. 1.12. Субъекты договора (с историей изменения, периодами действия для переуступки, субаренды, доверенности, ссылками на документы-основания). 1.13. Информация по субаренде с привязкой к объектам субаренды и характеристикам, коэффициентам, влияющим на расчет суммы планируемой арендной платы на субарендуемые площади (индивидуально для каждого субарендатора и субъекта субаренды) – с периодами действия. 1.14. Информация по планируемой плате по договору (с полной историей изменения) 1.15. Схема начисления в соответствии с условиями договора с историей изменения. - - - Подсистема «Ведение договоров и дополнительных соглашений» (3) - 1.16. Индивидуальные ставки пени – с историей изменения и ссылками на документы-основаниями, а также возможностью индивидуальной настройки количества знаков после запятой для расчетов пени, а также возможности начисления процентов вместо пени. 1.17. Индивидуальные ставки процентов за пользование чужими денежными средствами – с историей изменения и ссылками на документы-основаниями, а также возможностью индивидуальной настройки количества знаков после запятой для расчетов процентов, а также возможности начисления пени вместо процентов. 2. Управление дополнительными соглашениями, изменениями условий договора по дополнительным соглашениям. 3. Управление договорами с множественностью лиц. 4. Управление договорами с множественностью объектов. 5. Переоформление, продление договоров. 6. Автоматизация процесса переуступки права по договору. 7. Переоформление договоров аренды земельных участков при разграничении собственности на объекты аренды. 8. Автоматизированный расчет суммы планируемой платы, платы за выкуп с учетом всех особых условий договора. 9. Автоматизация расчета суммы планируемой платы по договору с учетом истории изменения расчетных величин, изменения условий договора по доп. соглашениям, учета различных особых условий (в том числе различные виды льгот, субаренда, долевая аренда/выкуп, аренда/выкуп с разными типами использования объектов договора, автоматическим поднятием до установленных минимумов). 10. Автоматизация подготовки необходимых печатных форм (в том числе текстов договора, доп. Соглашения, проектов постановлений, распоряжений, приказов). 11. Формирование аналитики по задолженности, работа с должниками. 12. Автоматизация претензионной и исковой деятельности. 13. Формирование аналитической отчетности в соответствующей сфере. - - - Подсистема «Ведение договоров и дополнительных соглашений» (4) - 14. Проведение экспресс-аналитики и др. Проведение начислений арендной платы по договорам, платы за выкуп, пени и других штрафов, учет платежей, расчет задолженности в необходимых разрезах производится финансово-аналитической подсистемой - - - Ведение договоров и дополнительных соглашений специализированного жилищного фонда - К жилым помещениям специализированного жилищного фонда относятся следующие виды жилых помещений, находящиеся в муниципальной собственности: 1. Служебные жилые помещения. 2. Жилые помещения в общежитиях. 3. Жилые помещения маневренного фонда. 4. Жилые помещения в домах системы социального обслуживания населения. 5. Жилые помещения для социальной защиты отдельных категорий граждан. 6. Жилые помещения для детей-сирот и детей, оставшихся без попечения родителей, лиц из числа детей сирот и детей, оставшихся без попечения родителей. В рамках управления специализированным жилищным фондом должна быть обеспечена возможность ведения следующих типов договоров: 1. Договор найма служебного жилого помещения. 2. Договор найма жилого помещения маневренного фонда. 3. Договор найма жилого помещения для детей сирот и детей, оставшихся без попечения родителей, лиц из числа детей сирот и детей, оставшихся без попечения родителей далее (дети-сироты). 4. Договор найма жилого помещения в домах системы социального обслуживания населения. 5. Договор найма жилого помещения для социальной защиты отдельных категорий граждан. 6. Договор найма жилого помещения жилищного фонда для коммерческого использования с условием последующего выкупа жилого помещения - - - Индивидуальные ставки пени и процентов (1) - Индивидуальные ставки пени и процеВ Системе должна быть предусмотрена возможность ведения индивидуальных ставок пени для каждого договора с указанием периода действия индивидуальной ставки, а также документа-основания. Средства настройки индивидуальной ставки пени должны предусматривать возможность дополнительной настройки следующих параметров: 1. Возможность указания конкретной величины ставки (в процентах или абсолютных единицах) или указание на ставку со значениями, задаваемыми справочником (например, ставка рефинансирования, ключевая ставка, среднебанковская ставка для вкладов физических лиц). 2. Доля ставки (знаменатель при указании ставки в виде простой дроби). 3. Количество знаков после запятой при расчете величины ставки в абсолютных единицах (по умолчанию – максимально возможное). 4. Признак необходимости расчета пени по методике равного количества дней в месяце (30 дней в месяце, 360 дней в году). 5. Признак необходимости расчета процентов за пользование чужими денежными средствами вместо пени. 6. Признак «плавающей» ставки пени в периоде расчета («Плавающая» или фиксированная на день исполнения денежных обязательств или их части). В периоде действия индивидуальных ставок пени расчет пени по договору производится по общей методике, в противном случае – по технологии, определенной по умолчанию для данного вида договора и/или схеме начисления. Аналогично должна быть реализована возможность для ведения индивидуальных ставок процентов за пользование чужими денежными средствами. По умолчанию должна применяться методика, соответствующая 395 статье Гражданского кодекса РФ (с учетом всех редакций данной статьи, распространяющих действия до следующего внесения изменений в статью) - - - Индивидуальные ставки пени и процентов (2) - Средства настройки индивидуальной ставки процентов должны предусматривать возможность дополнительной настройки следующих параметров: 1. Возможность указания конкретной величины ставки (в процентах или абсолютных единицах) или указание на ставку со значениями, задаваемыми справочником (например, ставка рефинансирования, ключевая ставка, среднебанковская ставка для вкладов физических лиц); 2. Доля ставки (знаменатель при указании ставки в виде простой дроби); 3. Количество знаков после запятой при расчете величины ставки в абсолютных единицах (по умолчанию – максимально возможное). 4. Признак необходимости расчета пени по методике равного количества дней в месяце (30 дней в месяце, 360 дней в году). 5. Признак необходимости расчета пени вместо процентов за пользование чужими денежными средствами. 6. Признак «плавающей» ставки процентов в периоде расчета («Плавающая» или фиксированная на день исполнения денежных обязательств или их части). В периоде действия индивидуальных ставок пени расчет пени по договору производится по общей методике, в противном случае – по технологии, определенной по умолчанию для данного вида договора и/или схеме начисления. нтов - - - Подсистема «Выкуп с рассрочкой» (1) - Подсистема «Выкуп с рассрочкой» необходима для ведения учета договоров выкупа с рассрочкой согласно Федерального закона «Об особенностях отчуждения недвижимого имущества, находящегося в муниципальной собственности субъектов Российской Федерации и арендуемого субъектами малого и среднего предпринимательства, и о внесении изменений в отдельные законодательные акты Российской Федерации» от 22.07.2008 N 159ФЗ (с изменениями от 08.06.2020). Данная подсистема должна включать в себя как весь функционал подсистемы «Подсистема ведения договоров и дополнительных соглашений», так и специфические особенности учета договоров выкупа с рассрочкой: 1. Подсистема должна иметь возможность настройки графика платежей. Для этого необходимо указать цену выкупа объекта, количество месяцев рассрочки, сумму и дату первого взноса. После проведения настройки должна иметься возможность формирования первоначального графика платежей. Должна иметься возможность смещать график платежей на любое количество периодов (как в будущее, так и в прошлое, как первый, так и последующие календарные периоды). Ставка рефинансирования (ключевая ставка) должна определяться автоматически на дату подписания договора, при расчете начисления процентов данная ставка делится на 3. Начисления основного долга и процентов должны соответствовать дифференцированной схеме (не аннуитет). 2. При распределении платежей на договор в первую очередь должна погашаться задолженность по процентам, а оставшаяся сумма платежа покрывает задолженность по основному долгу. Данные суммы вычисляются системой автоматически. При этом после каждого распределения платежей сумма последующих начислений процентов пересчитывается автоматически. 3. Должны иметься гибкие возможности настройки данной подсистемы, в том числе: 3.1. Начисление должны производиться одной суммой или с разбивкой на основной платеж и проценты. 3.2. Начисление пени должны производиться только на основной платеж или как на основной платеж, так и на проценты - - - Подсистема «Выкуп с рассрочкой» (2) - 3.3. Ставку рефинансирования и график начисления платежей должна иметься возможность учитывать с даты начала договора, даты подписания договора, даты публикации договора, даты договора, с указанием конкретной даты вручную. 3.4. Начисление процентов производить на первоначальный взнос или не производить. 3.5. Платеж в первую очередь должен погашать пеню, потом процент, потом основной долг (либо в первую очередь на процент, а оставшуюся сумма платежа – на основной долг) - - - «Финансово-аналитическая подсистема» (1) - «Финансово-аналитическая подсистема» является ключевой с точки зрения определения и повышения эффективности неналоговых поступлений от использования муниципальной собственности. Подсистема должна обеспечивать широкие возможности точной настройки на все нюансы федерального, регионального и местного законодательства, особенностей технологии управления имущественно-земельным комплексом, принятым в соответствующих органах управления собственностью и земельными ресурсами региона и государственных образований на территории региона. «Финансово-аналитическая подсистема» должна обеспечивать автоматизацию выполнения следующих основных задач: 1. Управление финансово-аналитической информацией (начислениями всех типов, платежами, задолженностью) в разрезах договоров, кодов бюджетной классификации (аналитических уровней), видов договоров, субъектов. 2. Автоматическое формирование начислений по договору возмездного и безвозмездного пользования, платы за фактическое использование, льготной арендной платы, платы за выкуп. Система автоматически должна определять, какой из видов начисления необходимо произвести в соответствии с условиями договорных соглашений (с учетом всех доп. соглашений и других корректировок), норм Гражданского Кодекса, в тех периодах использования объектов, которые не регулируются договором (в том числе фактическое использование объектов без договора, до заключения договора, в периоде до регистрации договора, после расторжения договора до даты освобождения объекта). 3. Автоматическое начисление пени, процентов, других штрафных санкций за пользование чужими денежными средствами. Система автоматически должна определять вид начисления (штрафных санкций) исходя из условий договора или руководствуясь нормами гражданского Кодекса в периоде фактического использования объекта. 4. Автоматическое доначисление по доп. соглашениям, изменяющим условия договора «задним числом». 5. Автоматический расчет сальдо - - - «Финансово-аналитическая подсистема» (2) - 6. Автоматический перерасчет планируемой платы по договору (например, в ходе массовой индексации по уровню инфляции). 7. Импорт платежей из электронных источников (выгрузка из СУФД и др.). 8. Автоматическое, полуавтоматическое и ручное распределение и перераспределение поступлений по субъектам договоров, договорам, видам начислений. 9. Формирование информации о задолженности в любом разрезе и на произвольную дату. 10. Формирование информации о динамике возникновения задолженности. 11. Управление начислениями по решению суда, автоматизация работы с реструктуризацией задолженности. 12. Ведение протоколов выполнения автоматических операций, возможности по эвристическому анализу информационного фонда на предмет корректности исходной информации для выполнения автоматических операций. 13. Автоматизация работы с должниками. 14. Формирование необходимых печатных форм (в том числе справки о наличии/отсутствии задолженности, формирование претензий, исковых требований, детализации всех видов начислений для суда, формирование актов сверки). 15. Формирование необходимой аналитической отчетности - - - «Финансово-аналитическая подсистема» (3) - 16. Организация массовой рассылки уведомлений о необходимости погашения задолженности, об изменении условий договора, величины планируемой платы по договору. 17. Проведение экспресс-аналитики. Помимо стандартных функций по управлению финансово-аналитической информацией, в подсистему должен быть включен ряд функций и возможностей, направленных на дополнительное расширение возможностей подсистемы как в части расширения функционала, так и в части настройки технологии учета под особенности внутреннего регламента по управлению финансово-аналитической информацией, технологии учета, особенности местного и регионального законодательства - - - Настройка уровня аналитического учета (1) - В Системе должна быть предусмотрена возможность индивидуальной настройки уровня аналитического учета платежей и начислений за аренду этих объектов. 1. Учет платежей и начислений должен вестись как в разрезе субъектов договоров (арендаторы), плательщиков (оплата 3-ми лицами), так и по договорам (аренда, выкуп, неосновательное обогащение, учет и т.д.). Платежи распределяются как по субъектам договоров (арендаторы), так и по договорам (аренда, выкуп, неосновательное обогащение, учет и т.д.). Пени и другие штрафные санкции и сальдо рассчитываются также в разрезе субъектов и по договорам аренды. Возможно применение смешанной технологии учета, в которой основная технология выбрана в разрезе субъектов договоров (арендаторы), но для части договоров учет ведется в разрезе договоров. 2. Возможно ведение технологии учета в разрезе КБК (кодов бюджетной классификации). При таком ведении учета пени и сальдо рассчитываются индивидуально для каждого кода бюджетной классификации. Данный аналитический уровень может быть применен как при ведении учета в разрезе арендаторов, так и при ведении учета в разрезе договоров. 3. Ведение библиотеки алгоритмов выполнения автоматических операций. 4. Ведение библиотеки схем начисления арендной платы и сроков оплаты - - - Настройка уровня аналитического учета (2) - 5. Библиотека схем начисления должна предоставлять следующие возможности: 6. Создание произвольного количества схем начисления. Под схемой начисления подразумевается алгоритм выполнения начисления, периодичностью (квартал, месяц, полугодие, набор месяцев) и сроки начисления. 7. Возможность создания и настройки произвольного количества периодичностей начисления (например, помесячное начисление, поквартальное, 2 раза в год для сельхоз. земель, 2 раза в год для других земель). При этом для каждой периодичности может быть указано произвольное количество периодов произвольной длительности. Для каждого периода индивидуальное указание произвольного срока оплаты. 8. Для каждого договора аренды указание индивидуальной схемы начисления из библиотеки (схема по умолчанию также должна настраиваться) - - - Расширение функциональных и аналитических возможностей блока (1) - В Системе должна быть реализована функция определения задолженности в любом разрезе. При этом функция должна рассчитать задолженность по состоянию на любую заданную дату как по базе целиком, так и по любому из перечисленных аналитических уровней (или их произвольному сочетанию): 1. Вычисление задолженности по договорам определенного типа (аренда, купля/продажа земельных участков, недвижимого, движимого имущества, объектов наружной рекламы, имущественных комплексов) или по всем типам. 2. Вычисление общей задолженности по субъекту договора или по всем субъектам. 3. Вычисление задолженности по договору или всем договорам. 4. Вычисление общей задолженности по определенному виду начисления или по всем видам. 5. Вычисление общей задолженности по определенному КБК или по всем КБК 6. В Системе должны быть предусмотрены следующие возможности: 7. Возможность запуска операции автоматического начисления арендной платы по диапазону периодов, годов. 8. Протоколирование выполнения всех автоматических операций и эвристический анализ состояния информационного фонда на поиск ошибок и потенциальных ошибок. 9. Выполнение любой автоматической операции должно сопровождаться формированием подробного протокола выполнения операции, в который в текстовом, понятном пользователю виде заносятся все операции, которые были произведены системой со всеми объектами учета. - - - Расширение функциональных и аналитических возможностей блока (2) - Одновременно, система должна выполнять комплекс эвристических проверок состояния информационного фонда системы на поиск ошибок или потенциальных ошибок, которые потенциально могут повлиять на корректность полученного результата. 10. Протоколы выполнения всех автоматических операций должны хранится в базе на постоянной основе и быть доступны для анализа в любой момент времени (возможность постанализа результатов выполнения операции). 11. Автоматический расчет и отображение «горячих итогов» (автовычисляемая и отображаемая на экране задолженность по заданным видам начисления (настраивается) по состоянию на текущую дату) по каждому субъекту (всем договорам субъекта общей суммой) и/или договору. В автоматическом режиме Система должна рассчитывать и отображать следующие данные: 1. Задолженность по арендной плате/плате за выкуп по состоянию на текущее число. 2. Задолженность по пене по состоянию на текущее число. 3. Общая задолженность (по всем видам начисления) по состоянию на текущее число. 4. Текущая пеня (сумма пени, рассчитанная на текущий момент). 5. Всего начислено с начала года. 6. Текущая сумма планируемой арендной платы/платы за выкуп. Поля «горячих» итогов должны поддерживать настройку на отображение итогов по любому виду начисления (глобальная настройка по Системе целиком). Должна быть предусмотрена возможность настройки не менее 10 показателей «горячих итогов» - - - Подсистема «Автоматизация претензионной и исковой деятельности» (1) - Подсистема должна автоматизировать выполнение следующих основных задач: 1. Ведение полной информации по претензиям и исковым процессам, по требованиям, предъявленным к пользователям Системы и по имуществу пользователям Системы: 1.1. Договор или иной документ, на основании которого ведется претензионно-исковая деятельность. 1.2. Претензия, иск стороны для требований, предъявленных к пользователям Системы по имуществу. 1.3. Субъект (заявитель) претензии. 1.4. Объект. 1.5. Предмет претензионно-исковых требований: 1.6. требования имущественного характера (сумма к взысканию по различным видам начислений); 1.7. требований имущественного характера, не подлежащего оценке; 1.8. требования неимущественного характера. 2. Возможность формировать печатные формы претензий и исковых заявлений автоматически на основе данных из учетной системы. 3. Стороны (участники) иска, категория (вид) иска, признак особой важности. 4. Состояние иска (подготовка, в процессе, завершен). 5. Учет судебных дел и претензионно-исковых этапов: претензия, подготовка иска, подача иска, наименование суда, номер судебного дела, судья, инстанция (апелляция, кассация, в порядке надзора), дата и время судебного заседания, сотрудник правового отдела – исполнитель, судебные акты по делу (решения, определения о приостановлении производства по делу, об оставлении иска без рассмотрения, об оставлении иска без движения, о возвращении искового заявления, о прекращении производства по делу, о принятии к производству встречного иска, о принятии (отмене) мер по обеспечению иска) - - - Подсистема «Автоматизация претензионной и исковой деятельности» (2) - 6. Учет исполнительного производства: дата вступления судебного акта в законную силу, дата получения исполнительного листа, дата направления исполнительного листа в отдел судебных приставов, отдел судебных приставов, судебный пристав исполнитель, постановления пристава исполнителя. 7. Учет конкурсного производства: суд, номер дела, дата введения процедур в отношении предприятия банкрота (определения суда), сведения о ходе процедур банкротства. 8. Возможность формирования отчета о сроках (длительности) претензионной работы, подготовки и подачи иска, рассмотрения дела в суде, исполнительного производства, конкурсного производства. 9. Возможность поиска судебных дел по различным критериям. 10. Наличие ссылки на страницу дела на сайте kad.arbitr.ru. 11. Возможность прикрепления файлов материалов к судебному делу (претензий, исков, судебных актов), к исполнительному производству (исполнительный лист, заявление о направлении исполнительного листа, постановления приставов-исполнителей), к конкурсному производству (судебные акты дела о банкротстве, извещения о проведении собраний кредиторов). 12. Формирование отчетов: о претензионной и исковой деятельности организации (количестве претензий, исков, судебных дел по различным критериям и заданным периодам), о сумме предъявленных и взысканных средствах в заданные периоды, в отношении различных субъектов и объектов; о количестве исполнительных и конкурсных производств по субъектам и объектам, суммам взысканных средств, заданным периодам. 13. Возможность сотруднику самостоятельно конструировать отчет, добавлять новые поля к карточкам судебных дел - - - Подсистема «Автоматизация претензионной и исковой деятельности» (3) - 14. Контроль за ходом иска в разрезе исполнителя, уведомление исполнителя о необходимости завершения текущего искового этапа и перехода к следующему. 15. Формирование графика судебных дел на каждого исполнителя и на правовой отдел в целом (ежедневник, еженедельник, ежемесячник) с возможностью размещения дополнительных сведений в графике о планируемой работе сотрудника. 16. Предусмотреть экспорт данных в табличный формат (xlsx, csv). Возможность формирования необходимых печатных форм (с использованием встроенных генераторов отчетов). 17. Предусмотреть разграничение прав доступа. 18. Постановка и контроль исполнения задач/поручений сотрудниками правового отдела. 19. Формирование статистики выигранных/проигранных судебных дел, отслеживание текущей загрузки сотрудников, анализ эффективности претензионной и исковой деятельности. 20. Протоколирование результатов расчета пени на расчетную дату. 21. Протоколирование результатов расчета задолженности по всем видам операций на расчетную дату, для возможности отслеживания изменений и анализа их причин - - - Аналитическая и сервисная подсистема «Библиотека запросов» (1) - Средства подсистемы должны предоставлять возможность для проведения оперативных выборок и для выполнения запросов по индивидуальному или массовому изменению, добавлению, удалению информации в банке данных Системы, например, в ходе обслуживания информационного фонда. Подсистема должна предоставлять средства оперативного построения, накопления и выполнения запросов произвольной сложности и произвольного содержания к единому информационному фонду Системы. Средства подсистемы должны быть максимально интуитивны и просты в использовании, выполнение запросов не требует каких-либо специальных знаний и навыков от пользователей. Количество запросов, которые могут быть добавлены в подсистему, должно быть не ограничено. Добавление запросов в подсистему должно выполняться средствами подсистемы, не требовать обновления Системы или ее компонентов, привлечения разработчиков Системы. Запросы могут содержать произвольное количество параметров любых типов (даты, числа, строки, данные из любых справочников и классификаторов Системы), фактические значения которых указываются пользователем в момент выполнения выбранного запроса, что в значительной степени повышает оперативность и точность получения данных в результате выполнения запроса. Должна быть предусмотрена возможность непосредственно из результатов выполнения запроса открыть электронную карточку объекта, по которому содержится информация в соответствующей строчке результатов выполнения запроса. Подсистема должна предоставлять возможность дополнительного постанализа данных (анализ после получения результата выполнения запроса в табличном виде), полученных в результате выполнения запроса: - - - Аналитическая и сервисная подсистема «Библиотека запросов» (2) - 1. Группировка данных по одному или нескольким полям, что в значительной степени может повысить информативность полученных данных. Например, данные по должникам можно сгруппировать по району плательщика, кодам бюджетной классификации и видам начислений. 2. Вычисление общих итогов, в том числе для каждой из групп (в случае применения группировки). Например, для приведенного примера возможна автоматическая калькуляция общей задолженности арендаторов, а также задолженности по каждому из районов, коду бюджетной классификации и виду начисления. 3. Дополнительная оперативная фильтрация данных по значениям любого поля\совокупности полей. 4. Сортировка данных по произвольному полю\совокупности полей. Должна быть предусмотрена возможность экспорта сформированных данных в табличные форматы (xlsx, csv), текстового файла, xml или внутренние форматы генератора отчетов. При этом должна быть обеспечена возможность экспорта данных, в том чисел в формат xml сложной структуры с учетом всех сортировок, группировок, итогов и прочего форматирования, которые были наложены на результат запроса в окне результата запроса. В случае содержания в результатах запроса сведений об объектах учета единого банка данных Системы должен быть реализован быстрый доступ (двойной «щелчок мыши») к карточкам соответствующих объектов учета. Средства подсистемы должны предоставлять возможность администратору Системы мониторинга состояния информационного фонда Системы, анализа целостности, непротиворечивости данных, регулярного обслуживания банка данных. Средства подсистемы должны предоставлять возможность не только для проведения оперативных выборок, но и для выполнения запросов по индивидуальному или массовому изменению, добавлению, удалению информации в банке данных системы, например, в ходе обслуживания информационного фонда - - - Подсистема «Формирование отчетов и печатных форм, генератор отчетов» - Подсистема должна предоставлять возможность формирования выходных данных системы – от простейших печатных карточек объектов учета до аналитических отчетов, выборок, прогнозов произвольной сложности по состоянию на произвольную дату в пределах информационного фонда Системы. Подсистема не должна содержать ограничений на количество шаблонов отчетов и печатных форм. В состав подсистемы должен входить генератор отчетов «FastReport» или эквивалент с помощью которого можно самостоятельно разрабатывать и подключать к Системе отчеты и печатные формы произвольной сложности, а также производить экспресс-изменения подключенных шаблонов. Кроме того, подсистема должна обладать возможностью подключения шаблонов отчетов и печатных форм, разработанных с помощью MS Word, MS Excel и OpenOffice (LibreOffice) или эквивалент с использованием API и VBA (или эквивалент). Подсистема должна обеспечить формирование произвольного количества отчетов и печатных форм любой сложности в рамках информационного фонда Системы. Для каждой печатной формы должна быть предусмотрена возможность выполнения произвольных действий (алгоритмов), выполняемых до и после формирования печатной формы. Должна быть предусмотрена библиотека соответствующих алгоритмов с возможностью выбора ранее разработанного алгоритма для любой печатной формы любому пользователю, не обладающему какими-либо специальными знаниями. Например, должна быть предусмотрена возможность автоматического внесения информации о сформированном акте сверки в перечень документов по договору аренды с автоматическим присвоением номера и даты формируемому акту сверки по алгоритмам произвольной сложности. Если соответствующие действия предусмотрены, они должны выполняться после дополнительного подтверждения пользователем, формирующим соответствующую печатную форму. Должна быть предусмотрена возможность добавления, изменения или удаления отчетов и печатных форм силами обученных пользователей Системы без необходимости обновления Системы или ее компонентов - - - Средства ведения журналов сформированных документов (печатных форм) - В подсистеме формирования отчетов и печатных форм должна быть предусмотрена возможность реализации средств сохранения информации о формировании соответствующей печатной формы с привязкой к электронной карточке объектов учета, а также фиксированием информации о времени формирования и пользователе, который выполнял формирование. Кроме того, должна быть предусмотрена возможность вывода журналов сформированных ранее печатных форм заданного типа в заданный промежуток времени. Например, средствами системы должна быть предусмотрена возможность формирования журнала выданных за период выписок из реестра муниципального имущества по заданным критериям. Кроме того, должна быть предусмотрена возможность по необходимости добавления в печатную форму признака необходимости включения факта формирования печатной формы в журнал. Например, если выписка из реестра формируется не с целью оказания соответствующей государственной услуги, то факт формирования выписки в журнале не должен быть учтен. Должна быть предусмотрена возможность добавления, изменения или удаления отчетов и печатных форм силами специалистов Системы без необходимости обновления Системы или ее компонентов. Должна быть предусмотрена возможность реализации описанных функций силами обученных специалистов Системы без необходимости обновления Системы или ее компонентов - - - Подсистема «Обеспечение безопасности, администрирования и разграничения прав доступа» (1) - Подсистема должна: 1. Обеспечивать возможности индивидуальной настройки для каждого пользователя базовых ограничений прав и разрешений с возможностью дальнейшего расширения. 2. Возможности индивидуального ограничения просмотра реестра объектов любого из типов. 3. Возможности индивидуального ограничения просмотра данных карточек объектов учета любых типов. Предоставление прав на частичный просмотр информации по объекту (например, запрет на просмотр экономических показателей объекта, но разрешение на просмотр технических показателей). 4. Возможности ограничения доступа к персональным данным, требующим отдельной защиты. 5. Возможности индивидуального ограничения изменения данных по объектам учета всех типов. Предоставление прав на частичное изменение информации. 6. «Горизонтальное» ограничение прав на изменение множественных атрибутов объектов учета (например, пользователю предоставляются права на изменение/внесение в карточку объектов документов определенной направленности и закрываются права на правку документов иной направленности (например, реестровых документов)). 7. Ограничение прав на выполнение различных операций с объектом учета (выделение подобъектов, включение в группу). 8. Ограничение на операции с печатными формами (просмотр и печать отчетов и печатных форм, экспорт во внешние форматы (docx, xlsx), редактирование сформированных отчетов). Для печатных форм права должны назначаться индивидуально для каждого типа объектов учета, для аналитических отчетов – индивидуально для каждой темы отчета. 9. Ограничение прав на работу с блоками начислений и платежей за аренду недвижимости и ЗУ (индивидуально на все функции, выполнение операций в каждом из режимов (индивидуальном, массовом)) - - - Подсистема «Обеспечение безопасности, администрирования и разграничения прав доступа» (2) - 10. Ограничение прав на работу с универсальной библиотекой запросов – права предоставляются индивидуально для каждой темы запросов и на выполнение операций блока запросов (выполнение запроса, экспорт результатов). 11. Ограничение прав на работу с НСИ (права предоставляются индивидуально для каждого справочника или классификатора). 12. Ограничение права на настройки системы (индивидуально на каждый блок настроек). Все права и разрешения на работу с объектами учета всех типов должны предоставляться индивидуально для каждой стадии формирования объекта учета (заявка, новый, актуальный (реестровый), актуальный зарегистрированный (в Росреестре), архивный, справочный, внереестровый или объект налогового потенциала). В Системе должны присутствовать средства объединения пользователей в группы (причем, каждый пользователь может быть включен в одну и иное количество групп) с автоматическим наследованием всех прав и разрешений групп, в которые включен пользователь. В Системе должны быть реализованы особые механизмы хранения и проверки паролей, обеспечивающие повышенную безопасность. При установке и смене пароля, новый пароль кодируется необратимыми алгоритмами (без возможности восстановления исходного пароля) - - - Разграничение прав пользователей единого информационного пространства - Для каждого пользователя или группы пользователей должна быть предусмотрена возможность управления правами доступа (в объеме, описанном выше) индивидуально для каждого из информационных фондов организаций-участников, составляющих единую базу данных Системы. В совокупности с возможностью сопоставления пользователей с соответствующими информационными фондами, а также автоматической идентификации принадлежности объектов учета к соответствующим информационным фондам, должен достигаться максимальный уровень защищенности информационных фондов от несанкционированного доступа (как на просмотр, так и на корректировку информационного фонда) - - - Подсистема «Ведение нормативно-справочной информации» - Подсистема должна обеспечивает функционирование необходимого для эффективной работы Системы набора справочников и классификаторов. Помимо федеральных справочников и классификаторов, а также справочников и классификаторов, формируемых в процессе поставки Системы, в состав Системы должен быть включен ряд дополнительных справочников, направленных на: 1. Повышение аналитических возможностей Системы. 2. Повышение возможностей Системы по расширению перечня учитываемых показателей. 3. Повышения адаптивности Системы к изменению законодательства, технологии учета, обеспечения быстрой настройки Системы под все нюансы работы органов управления имущественно-земельным комплексом. В Системе должна быть возможность доступа к справочникам и классификаторам непосредственно в ходе редактирования параметра с выбором из справочника с целью выполнения расширенного поиска, а по необходимости и внесения изменений в классификатор. Должна быть реализована возможность «привязки» как самих классификаторов, так и элементов классификации к видам реестров. Классификаторы и элементы классификации должно быть возможно выбрать только в тех реестрах, в которых это разрешено настройками Системы - - - Подсистема «Автоматическое обновление клиентских рабочих мест» (1) - Подсистема «Автоматическое обновление клиентских рабочих мест» (далее – Подсистема автообновления) предназначена для облегчения работы по обслуживанию клиентских рабочих мест Системы или компонентов, библиотек, включая общесистемные компоненты и библиотеки, необходимые для функционирования клиентского рабочего места. Подсистема автообновления предназначена для автоматического обновления файлов клиентских мест Системы или других компонентов, необходимых для функционирования. Система автообновления должна быть построена по клиент-серверной архитектуре, обновления должны распространятся по сети с использованием протокола TCP/IP. Подсистема автообновления должна состоять из следующих компонентов (программ): 1. «Служба обновления» – серверная часть подсистемы автообновления, устанавливаемая на компьютере – сервере. 2. «Конфигуратор службы обновления» – утилита по настройке службы обновления. 3. «Клиент обновления» – клиентская часть подсистемы автообновления, устанавливаемая на компьютере пользователя - - - Подсистема «Автоматическое обновление клиентских рабочих мест» (2) - Подсистема автообновления должна обладать следующим функционалом: 1. Автоматическое обновление клиентов обновлений на компьютерах пользователей при установке новой версии системы обновлений. Служба должна предоставлять клиентским местам Системы актуальную версию клиента обновлений. Для каждой новой версии клиента обновлений должен генерироваться уникальный идентификатор обновления. 2. Автоматическое обновление клиентских мест Системы на компьютерах пользователей при наличии обновлений программы. Служба должна предоставлять клиентским местам Системы актуальные версии файлов программы. Для каждой новой версии программы должен генерироваться уникальный идентификатор обновления. 3. Автоматическое восстановление отсутствующих файлов клиентских мест Системы на компьютерах пользователей. 4. При обновлении клиентских мест должна поддерживаться работа со списком исключений для удаления с клиентских мест устаревших файлов и папок. 5. Возможность обновления клиентских мест Системы из нескольких источников. Количество источников не должно быть ограничено. Для каждого источника должна быть предусмотрена возможность задать имя, путь к папке с файлами обновлений, а также путь к файлу со списком исключений. 6. Возможность сжатия пересылаемых по сети пакетов для уменьшения нагрузки на сеть. Активация данного функционала должна происходить по решению администратора. 7. Возможность контроля целостности пересылаемых по сети пакетов для предотвращения модификации пересылаемых файлов сторонним ПО, вирусами и иными внешними факторами. Файлы должны приходить на компьютеры пользователей в неизменном виде - - - Служба обновления - Серверная часть подсистемы автообновления должна быть представлена в виде службы ОС (далее – Служба). Служба должна отвечать на запросы «Клиентов обновления» (далее – Клиентов), предоставляя им всю необходимую информацию об обновлениях, а также сами обновления. Должна быть предусмотрена возможность запустить Службу как вручную, так и с помощью конфигуратора службы. Также Служба должна запускаться автоматически при включении компьютера и не требовать входа в Систему под учетной записью какого-либо пользователя. Служба обновления должна применять новые настройки конфигурации автоматически, без необходимости перезапуска. Служба обновления должна автоматически отслеживать наличие новой версии клиента обновлений, а также отслеживать любые изменения в папках источников обновлений. При наличии новой версии клиента обновлений служба должна сгенерировать уникальный идентификатор обновления. Этот идентификатор должен передаваться клиентам обновления на клиентских местах при их подключении к службе обновлений. При наличии изменений в папках источников обновлений служба должна сгенерировать уникальный идентификатор обновления индивидуально для каждого источника обновлений. Этот идентификатор должен передаваться клиентам обновления на клиентских местах при их подключении к службе обновлений - - - Конфигуратор службы обновления - Для настройки службы обновления должна быть предназначена специальная утилита «Конфигуратор службы обновления» (далее – Конфигуратор). Конфигуратор не должен требовать установки и должен иметь возможность быть запущенным из любого места на компьютере, где установлена служба обновления. При запуске конфигуратор должен проверять наличие установленной службы и в случае её отсутствия, сообщить об этом пользователю. Если Служба установлена, то должно открываться окно Конфигуратора, на котором должны быть представлены текущие настройки Службы. Конфигуратор должен обладать следующим функционалом по настройке службы обновления: 1. Отслеживать текущее состояние Службы. 2. Иметь средства для остановки, запуска и перезапуска службы обновления. 3. Позволять указывать местоположение актуальной версии клиента обновления (которая совместима со службой обновления). 4. Позволять управлять (активация/деактивация) опцией по сжатию пакетов, передаваемых по сети (для уменьшения нагрузки на сеть). 5. Позволять управлять (активация/деактивация) опцией по контролю целостности пакетов, передаваемых по сети (для предотвращения модификации содержимого пакетов внешними факторами). 6. Позволять добавлять новые источники обновлений (без ограничения по их количеству). 7. Позволять редактировать сведения об источниках обновлений. В частности, настраивать следующие параметры: 8. Задавать имя источника обновлений. 9. Указывать путь к папке с файлами обновлений. 10. Указывать путь к файлу исключений - - - Клиент обновлений (1) - Клиентская часть подсистемы автообновления должна быть представлена в виде отдельной программы – клиента обновления. Клиент обновления должен быть предназначен для соединения со службой обновления, расположенной на другом или текущем компьютере, и получения от неё актуальной версии файлов обновляемой программы, а также актуальной версии самого клиента обновления. Клиент обновления не должен требовать специальной установки и может быть запущен из любого места. Клиент обновления должен обладать возможностью запуска в двух режимах: 1. «Режим настройки» - в этом режиме должно открываться окно настройки клиента обновления. 2. «Режим обновления» - в этом режиме программа должна выполнять соединение с сервером обновлений, согласно выполненной настройке, и получать от сервера обновлений актуальные версии файлов обновляемой программы и самого клиента. Клиент обновления в «режиме настройки» должен предоставлять возможность задавать следующие настройки: 1. Настройки подключения к службе обновлений (IP-адрес или имя компьютера, на котором установлена служба обновлений, порт служба обновлений). Для проверки корректности настройки должна быть предусмотрена кнопка для тестирования соединения. 2. В случае необходимости подключения к серверу через прокси-сервер, должна быть возможность в соответствующей группе настроек указать IP-адрес прокси-сервера, порт подключения к прокси-серверу, а также логин и пароль для авторизации на прокси-сервере (при необходимости). 3. Источник обновления. Выбор источника обновлений должен осуществляться из выпадающего списка, а котором должны присутствовать все доступные источники обновлений. 4. Путь к временной папке, в которую будут загружаться обновления перед их применением. 5. Путь к папке, в которую необходимо сохранить загруженные обновления. 6. Путь к файлу программы, которую необходимо запустить после обновления. Должна присутствовать возможность настроить запрет запуска нескольких экземпляров - - - Клиент обновлений (2) - 7. Индивидуальная для клиентского места настройка сжатия пакетов, передаваемых по сети. 8. Индивидуальная для клиентского места настройка контроля целостности пакетов, передаваемых по сети. 9. Настройка протоколирования процесса обновления. Если ip-адрес и имя сервера обновления неизвестны, то должна быть реализована возможность автоматического поиска сервера в локальной сети. Для автоматического поиска сервера должна присутствовать кнопка «Поиск сервера». После успешного поиска, настройки подключения должны быть установлены автоматически, и пользователю должно быть показано соответствующее уведомление. Клиент обновления в «режиме обновления» должен осуществлять следующие действия: 1. Проверять наличие новой версии клиента обновления. Для этого клиент обновления должен получить текущий идентификатор обновления клиента и сравнить с ранее сохраненным идентификатором. Если идентификаторы различаются, то клиент обновления должен произвести самообновление с сохранением текущего идентификатора обновления. 2. Проверить наличие обновлений клиентского места Системы. Для этого клиент обновления должен получить текущий идентификатор обновления клиентского места и сравнить с ранее сохраненным идентификатором. Если идентификаторы различаются, то клиент обновления должен произвести загрузку измененных и новых файлов с сохранением текущего идентификатора обновления. При загрузке обновлений должны загружаться только новые и изменение файлы (сверяться контрольные суммы файлов (CRC)) - - - Клиент обновлений (3) - 3. При отсутствии обновлений клиентского места Системы клиент обновления должен проверить наличие отсутствующих файлов клиентского места Системы и при необходимости восстановить их. 4. По завершению работы клиент обновления должен произвести обработку файла исключений. Для этого клиент обновления должен получить содержимое файла исключений и удалить файлы и папки, согласно полученного списка. Процесс обновления должен отображаться в виде окна, на котором должны быть размещены следующие элементы: 1. Текст сообщения с описанием текущего этапа обновления. 2. Индикатор прогресса обновления. Клиент обновления должен поддерживать возможность протоколирования процесса обновления в текстовом файле, который должен автоматически создаваться в папке клиента обновления - - - Подсистема «Оповещение пользователей» (1) - Подсистема «Оповещение пользователей» создается с целью ускорения установки и настройки и дальнейшего облегчения работы по обслуживанию клиентских рабочих мест Системы. Подсистема оповещения пользователей предназначена для выполнения следующих задач: 1. Автоматизация отключения пользователей от Системы для проведения работ по техническому обслуживанию. 2. Информирование пользователей путем отсылки им текстовых сообщений. Подсистема оповещения должна быть доступна из главного меню клиента Системы и из главного меню сервера приложений, в случае если сервер приложений не запущен в режиме службы. Подсистема оповещения пользователей должна обеспечивать следующие возможности: 1. Направить подключенным пользователям (подключенным клиентским приложениям) текстовое сообщение о проведении технических работ, требующих отключения клиентских приложений от Системы. Для данного типа сообщений должна быть предусмотрена возможность указания времени (в минутах), по истечении которого клиентские приложения должны быть автоматически отключены от Системы. Данное сообщение посылается всем подключенным клиентским приложениям и должно сопровождаться отображением счетчика обратного отсчета до автоматического отключения клиентского места. Сообщение должно отображаться поверх всех окон клиентского приложения - - - Подсистема «Оповещение пользователей» (2) - 2. Автоматически завершить работу всех подключенных клиентских приложений по истечении заданного времени. 3. Формировать простые текстовые сообщения подключенным пользователям Системы. 4. Формировать текстовые сообщения всем пользователям Системы (не подключенные на момент формирования сообщения пользователи получат сообщение в момент следующего подключения). Пользователь должен получить сообщение только один раз вне зависимости от компьютера, на котором запущено клиентское приложение (в отличие от сообщений об автоматическом отключении клиентских приложений, простые текстовые сообщения должны отправляться не каждому клиентскому приложению, а пользователю, который был указан при подключении к клиентскому приложению. 5. Отзыв направленного ранее сообщения об отключении клиентских приложений. Автоматическое отключение клиентских приложений должно быть отменено, сообщение об отключении и таймер обратного отсчета на всех клиентских приложениях должны быть закрыты, должна быть возобновлена возможность подключения клиентских приложений. 6. Ведение журнала всех отправленных сообщений. 7. Ведение журнала получения сообщений пользователями - - - Типы оповещений пользователей - Для оповещения должна быть предоставлена возможность выбора типа оповещения. Должна быть реализована возможность выбора следующих типов: 1. Оповещение о начале технических работ на сервере, о необходимости выхода из Системы и автоматического отключения клиента. 2. Простое оповещение только подключенным пользователям, автоматического отключения не происходит. 3. Оповещение всем пользователям, подключенным и не подключённым, неподключенные должны получить оповещение при первом входе в Систему - - - Журнал оповещений - Должен вестись журнал оповещений, обладающих следующими характеристиками: 1. Для каждого оповещения сохраняется информация с указанием их типа, текста сообщения, даты и времени отправки сообщения, пользователя, сформировавшего сообщения. 2. Журнал оповещений должен обладать средствами поиска сообщений по всем параметрам журнала. Реализованы фильтры по диапазону дат, пользователю, группе пользователей, текстовый поиск. 3. Невозможно удалить произвольное оповещение. 4. Удалить записи журнала о старых оповещениях можно только до указанной даты. Права на удаление записей имеет только администратор. Ведется дополнительный лог по пользователям, прочитавшим оповещение. Просмотр лога так же доступен в интерфейсе просмотра журнала - - - Подсистема «Самодиагностика с автоматическим оповещением о выявленных аномалиях по электронной почте» - Подсистема «Самодиагностика с автоматическим оповещением о выявленных аномалиях по электронной почте» должна быть использована в целях улучшения качества работы, уменьшения количества ошибок, уменьшения времени реагирования на появление проблемы. Должен быть сформирован набор тестов, проверяющих состояние работоспособности Системы и ее подсистем, возникновения проблем при взаимодействии Системы с внешними системами, возникновении некорректных данных в информационном фонде. Мониторинг работоспособности должен производиться непрерывно. Мониторинг целостности и непротиворечивости данных должен проверяться при помощи регламентных операций, выполняемых Системой по заданному расписанию (например, в ночное время). Оповещения должны отправляться с использованием механизма очереди оповещений на адреса электронной почты, которые заданы при настройке подсистемы «Самодиагностика с автоматическим оповещением о выявленных аномалиях по электронной почте» - - - Средства ведения электронных карточек объектов учета - Под объектом учета понимается любой объект, информация по которому должна быть учтена в едином информационном фонде Системы. Например, объектами учета являются: земельные участки любой формы собственности, а также земельные участки, собственность на которые не разграничена, объекты движимого и недвижимого имущества, субъекты права, документы, договоры, соглашения, претензионные и исковые процессы, финансовые поступления. Для доступа к реквизитам (атрибутам, характеристикам) объекта учета в Системе должна быть предусмотрена отдельная экранная форма. Экранная форма по умолчанию должна открываться в режиме просмотра (возможность редактирования атрибутов объекта отключена) с возможностью переключения в режим редактирования при наличии соответствующих прав и разрешений. Экранная форма доступа к реквизитам объекта должна отображать информацию по объекту учета в соответствии с правами и разрешениями пользователя (не отображать атрибуты объекта, для которых у пользователя отсутствуют права на просмотр). При переключении экранной формы карточки объекта учета в режим редактирования доступ на редактирование должен быть предоставлен только к тем атрибутам объекта учета, на которые активный пользователь имеет права и разрешения на изменение. Остальные атрибуты должны оставаться в режиме просмотра (без возможности внесения изменений) - - - Требования по ведению атрибутов объектов учета - Объект учета в обязательном порядке должен содержать следующую информацию: 1. Идентификатор – числовое значение, однозначно идентифицирующее объект учета (не должно существовать любого другого объекта учета, имеющего такой же идентификатор). Идентификатор должен присваиваться Системе автоматически при создании нового объекта. 2. Наименование (описание) объекта – строковое значение, описывающее объект, заполняется вручную, не является обязательным. Объект учета может иметь произвольное количество атрибутов (характеристик). Каждый атрибут должен содержать: 1. Наименование (идентификатор) атрибута – выбирается из соответствующих справочников наименований атрибутов каждого из типов данных. Должен быть предусмотрен инструмент формирования допустимого перечня атрибутов, который может быть указан (выбран) в карточке каждого из типов объектов учета (инструмент индивидуального формирования перечня атрибутов для каждого типа объектов учета). 2. Значение – указывается в зависимости от типа данных атрибута. 3. Период действия – дата начала периода действия атрибута и дата окончания периода действия атрибута. Индивидуально для каждого вида (наименования) атрибута должна быть предусмотрена возможность настройки допустимости пересечения периодов действия значений этого атрибута (множественный ввод значений одноименных атрибутов в один момент времени). 4. Перечень ссылок на документы-основания начала действия значения атрибута – перечень ссылок на информацию о документах с обязательным указанием основного документа-основания. 5. Перечень ссылок на документы-основания окончания действия значения атрибута – перечень ссылок на информацию о документах с обязательным указанием основного документа-основания. Индивидуально для каждого вида (наименования) атрибута должна быть предусмотрена возможность настройки использования документов-оснований окончания действия (используется или нет) - - - Требования по ведению атрибутов объектов учета (2) - 6. Примечание – текстовое поле. Система должна обеспечивать возможность создания и ведения атрибутов объектов учета следующих типов данных: 1. Числовой тип (коэффициент). Должна быть предусмотрена возможность установки фиксированного значения величины коэффициента для каждого наименования коэффициента (наименования атрибута соответствующего типа) без возможности индивидуального изменения в карточке объекта учета (константа) или с возможностью индивидуального изменения (в этом случае значение, связанное с наименованием коэффициента, должно устанавливаться как значение по умолчанию с возможностью последующей корректировки индивидуально в карточке конкретного объекта). Такая настройка должна быть предусмотрена индивидуально для каждого вида (наименования) коэффициента. 2. Денежный тип (экономический показатель). 3. Строковый тип (технический, описательный показатель). Для каждого наименования атрибута данного типа должна быть предусмотрена возможность установки маски ввода значения атрибута. 4. Классификационный тип – справочник. Для каждого наименования атрибута (категории классификационных данных) должна быть предусмотрена возможность индивидуальной настройки перечня (справочника) элементов классификатора данной категории. 5. Булевый тип – признак (да/нет). Допустимо отсутствие ведения информации по периоду действия и документам-основаниям. 6. Тип даты – событие. 7. Ссылка на субъект права – с указанием типа субъекта права. 8. Кроме того, в карточку объекта учета дополнительно могут быть загружены: 8.1. Информация по адресу объекта с использованием адресной подсистемы - - - Требования по ведению атрибутов объектов учета (3) - 8.2. Произвольное количество файлов любого типа. Файлы могут загружаться как по одному, так и массово путем выделения нескольких файлов в средстве работы с файлами операционной системы (проводнике, менеджере файлов). Должна быть предусмотрена возможность загрузки в карточку объектов файлов путем использования технологии Drag-And-Drop (перетащи и отпусти). Открытие файлов должно производиться непосредственно из Системы путем использования средств операционной системы, назначенных по умолчанию (аналогично открытию файлов проводником или другим менеджером файлов). Хранение прикрепленных файлов объекта учета должно производиться на сервере в базе данных или с использованием других средств, обеспечивающих надежность и скорость работы с файлами не хуже соответствующих инструментов СУБД (транзакционный механизм доступа с возможностью автоматического отката транзакций, завершившихся аварийно, резервное копирование). 8.3. Произвольное количество файлов распространенных графических форматов (jpg, bmp). Функционал аналогичен работе с прикрепленными файлами, дополнительно в Системе должны быть предусмотрены средства предварительного просмотра графических изображений без открытия файлов. 8.4. Информация о произвольном количестве документов: 8.4.1. Направление документа – значение из соответствующего справочника, указывающее на назначение документа в карточке объекта – определяется технологией работы с объектами соответствующего типа. 8.4.2. Номер документа. 8.4.3. Дата документа. 8.4.4. Тип документа – значение из классификатора типов документов. 8.4.5. Источник документа – значение из классификатора источников документов (организация, выпустившая документ) - - - Требования по ведению атрибутов объектов учета (4) - 8.4.6. Наименование документа – текстовое описание с возможностью выбора из справочника шаблонов наименований с возможностью последующего индивидуального изменения. 8.4.7. Примечание документа. 8.4.8. Ссылка на прикрепленный файл документа. Сохранение карточки объекта учета (атрибутов, файлов, графических объектов, документов должно производиться на основе транзакционных механизмов, то есть либо вся измененная информация карточки (внесенные в карточку данные) должны успешно сохраниться в базе данных, либо, например, в случае какой-либо ошибки, все изменения в базе данных, выполненные в процессе сохранения, должны быть отменены, и карточка должна вернуться в состояние, предшествующее сохранению. Пользователь должен быть подробно проинформирован Системой о характере возникшей ошибки и, по возможности, Система должна дать рекомендации по способам исправления ошибки. После исправления пользователем причин, приведшим к ошибке, должна быть предусмотрена возможность повторного сохранения внесенных в карточку изменений. Частичное автоматическое внесение изменений в базу данных в процессе внесения изменений в карточку объектов недопустимо - - - Требования к настройке элементов формы карточки объектов - Средства работы с атрибутами каждого из доступных типов данных по умолчанию должны содержаться в экранных контейнерах (панелях экранной формы), контейнеры должны быть размещены на вкладках экранной формы. Экранные контейнеры должны представлять собой панели прямоугольной формы, на которой размещаются элементы управления (просмотра, редактирования) атрибутами объектов учета. Для экранных контейнеров должна быть предусмотрена возможность выполнения следующих действий: 1. Изменение размеров контейнера (высота, ширина). 2. Перемещение контейнера по экранной форме, включая перемещение контейнера на другие вкладки (на свободное место экранной формы (не занятое другими элементами управления) имеющем размеры, достаточные для вмещения контейнера). Должна быть предусмотрена возможность для каждого типа объектов учета создания произвольного количества контейнеров с размещением в них произвольного количества логически связанных атрибутов любых типов единым списком. Для каждого атрибута, размещаемого в создаваемом контейнере, должна быть возможность указания признака автоматического добавления атрибута в карточку объекта учета и порядкового номера по умолчанию отображения автоматически добавленных атрибутов в контейнере. Автоматически добавляемые атрибуты должны добавляться в контейнер автоматически с последующим возможным указанием пользователем их значения. Должна быть предусмотрена возможность визуальной индикации в контейнере атрибутов, добавленных автоматически, но значение которых пользователем еще не введены (по факту такие атрибуты для объекта учета еще не определены). Для экранной формы должны быть предусмотрены следующие возможности по работе с вкладками: 1. Добавление вкладок. 2. Изменение наименований вкладок. 3. Изменение порядка следования вкладок. 4. Удаление вкладок, не содержащих элементов управления или контейнеров - - - Требования к настройке меню доступа к объектам учета и работы со списками - Система должна содержать в своем составе средства настройки иерархического меню доступа к объектам учета всех типов с учетом возможностей по добавлению новых объектов учета. Доступ к меню доступа к объектам учета должен предоставляться из основного окна Системы. Доступ к каждому пункту меню должен осуществляться за минимальное количество действий пользователя. При возобновлении сеанса работы с Системой (повторном запуске Системы) позиция текущего пункта меню в иерархическом меню должна быть восстановлена автоматически, то есть доступ к объектам учета соответствующего типа должен осуществляться путем использования одного клика мыши. Иерархическое меню должно иметь элементы следующих типов: 1. Промежуточные узлы – нажатие на этот пункт меню должен раскрывать следующий уровень иерархии (отображать вложенные пункты меню). 2. Промежуточные узлы-реестры – нажатие на данный пункт меню должен открыть объединенный список объектов учета, соответствующий совокупности объектов учета всех конечных элементов меню, вложенных с учетом иерархии в данный пункт (узел). Для данного типа пункта меню должна быть возможность открытия вложенных пунктов меню без открытия объединенного реестра. 3. Конечный узел – открывает список объектов учета, соответствующий данному пункту меню. 4. Конечный узел объединенного реестра – открывает объединенный список объектов учета, соответствующий конечным узлам пунктов меню, находящихся на этом же уровне иерархии (имеющих единый промежуточный узел). В меню должна быть предусмотрена возможность добавления пунктов, для которых может быть указан дополнительный фильтр, который автоматически применяется при отображении списка объектов, отображаемых с помощью данного пункта меню - - - Режим добавления объекта по шаблону - В Системе должна быть предусмотрена возможность добавления объекта по шаблону на основе любого выбранного пользователем объекта, информация о котором уже содержится в единой базе данных Системы. В режиме добавления объекта по шаблону должна быть создана карточка нового объекта соответствующего типа (как у объекта, на основе которого производится добавление) с полным копированием информации из исходного объекта в карточку добавляемого объекта, за исключением информации, идентифицирующей объект (реестровый номер, инвентарный номер, паспортные данные, ПТС транспортного средства) - - - Средства поиска, отображения и анализа информации (1) - Средства поиска, отображения и анализа информации должны быть включены во все экранные формы работы со списками объектов учета, в том числе в экранные формы работы с объектами реестра. Средства поиска должны обеспечивать возможности поиска объектов учета по всем характеристикам самих объектов, а также по всем характеристикам связанных объектов учета любого уровня вложенности (например, поиск объектов по параметрам связанных объектов учета, которые связаны со связанными объектами учета. – поиск объектов по параметрам договоров на них и параметрам субъектов этих договоров). Для каждой из характеристик должны быть предусмотрены следующие логические условия поиска: 1. Равно. 2. Не равно. 3. Больше. 4. Меньше. 5. Больше или равно. 6. Меньше или равно. 7. Содержит (для текстовых характеристик). 8. Не содержит (для текстовых характеристик). 9. Начинается на (для текстовых характеристик). 10. Не начинается на (для текстовых характеристик). 11. Заполнено. 12. Не заполнено. 13. Отсутствует. Для характеристик, имеющих историю изменения, должны быть предусмотрены средства указания даты, на которую выполняется поиск значения характеристики. Для сложных или связанных характеристик должны быть предусмотрены возможности поиска по комбинациям значений (например, поиск по коэффициентам подразумевает возможность поиска по произвольной комбинации значений, составляющих информацию по коэффициенту – наименование коэффициента, величина, диапазон дат периода действия коэффициента) Должен быть предусмотрен поиск по отрицанию условий поиска (объекты, НЕ удовлетворяющие условиям поиска). Должна быть предусмотрена возможность комбинации условий поиска – поиск в найденном и новый поиск в дополнение к предыдущему. Должна быть предусмотрена возможность сохранение ранее сформированных условий поиска для последующего быстрого использования - - - Средства поиска, отображения и анализа информации (2) - Для администраторов системы должна быть предусмотрена возможность формирования и отображения SQL-скрипта, соответствующего выборке объектов учета для формирования списка с учетом SQL-выражений, удовлетворяющих сформированным условиям поиска. Администратор должен иметь возможность ручной корректировки сформированных SQL-выражений поиска с возможностью выполнения поиска на основе скорректированных SQL-выражений. 1. Контекстный поиск В любой списочной форме (экранной форме отображения списка объектов учета или множественных реквизитов, атрибутов, характеристик объектов учета) должны быть предусмотрены средства контекстного поиска – возможность ввода символов в любой из колонок списка с автоматическим позиционированием курсора в списке на первый объект, соответствующий условиям поиска (вводимым значениям). 2. Универсальные средства предварительного просмотра В любой форме отображения списка объектов учета должна быть предусмотрена возможность отображения средств предварительного просмотра. Например, в списке договоров можно отобразить перечень кадастровых номеров земельных участков, арендуемых по текущему договору в списке, или перечень документов-оснований, перечень дополнительных соглашений, развернутую информацию о задолженности по договору. Средства предварительного просмотра должны представлять собой печатные формы, сформированные с использованием генератора отчетов, и отображающие всю необходимую информацию по текущему объекту учета в списке без выполнения дополнительных действий со стороны пользователя. Для каждого типа объектов учета может быть настроено произвольное количество форм предварительного просмотра с возможностью выбора текущей отображаемой формы из списка доступных форм - - - Средства поиска, отображения и анализа информации (3) - Средства предварительного просмотра должны обладать всеми возможностями печатных форм, включая возможность открытия карточки объекта учета путем двойного клика по информации по нему в окне предварительного просмотра (например, открытие карточки земельного участка из окна предварительного просмотра договоров, отображающего перечень земельных участков по текущему договору). 3. Аналитические средства элементов работы со списками объектов учета 1. Группировка данных по одному или нескольким столбцам. Например, реестр может быть сгруппирован по состоянию объектов учета, району области, разрешенному использованию. 2. Вычисление общих итогов, в том числе для каждой из групп (в случае применения группировки). Например, для приведенного примера возможна автоматическая калькуляция общей планируемой платы, площади объектов, величины задолженности в разрезе состояний договоров аренды, района расположения объекта договора, целевого использования; 3. Дополнительная оперативная фильтрация данных по значениям любого столбца\совокупности столбцов; 4. Сортировка данных по произвольному столбцу\совокупности столбцов. 5. Возможность выбора отображаемых столбцов. 6. Автоматическое сохранение настроек табличного представления для каждого типа объектов учета. Должна быть предусмотрена возможность экспорта сформированных данных в форматы табличные форматы (xlsx, csv), текстового файла или внутренние форматы генератора отчетов - - - Средства предварительного просмотра - В Системе должна быть реализована возможность автоматического предварительного просмотра документа непосредственно в табличной форме реестра любого типа объектов. При переходе от одного к другому объекту в списке, форма предварительного просмотра должна обновляться автоматически. Должна быть реализована возможность отключать данный режим, настраивать форму просмотра, выбирая нужный шаблон документа, из списка доступных для данного режима, шаблонов. Должна быть возможность создавать и редактировать шаблоны документов для данного режима наряду с любыми другими шаблонами документов - - - Средства выполнения массовых операций - Система должна иметь средства выполнения однотипных операций над заданным количеством объектов учета, в том числе: 1. Передача с баланса на баланс, в казну, из казны, списание объектов. 2. Внесение документа-основания. 3. Смена адреса. 4. Смена характеристик объектов учета. 5. Изменить нумерацию объектов. 6. Слияние «двойников». 7. Включить физическое лицо в очередь и исключить из очереди. 8. Массовое формирование квитанций, уведомлений, претензий и других печатных форм на основе заданных шаблонов. 9. Распределение платежного документа, оплаченного по 2-м и более договорам субъекта договоров (арендатор) осуществляется по начислению и по сальдо на любую дату. Массовые операции должны повысить эффективность управления имущественно-земельным комплексом, снизить трудозатраты специалистов на выполнение операций над объектами - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (1) - Подсистема должна автоматизировать межведомственное электронное взаимодействие органов управления муниципальной собственностью в части формирования межведомственных запросов по протоколам СМЭВ в отношении объектов учета, субъектов права и договоров, зарегистрированных в единой базе данных Системы, а также автоматизации внесения изменений в единую базу данных Системы на основе полученных сведений. Подсистема должна решать следующие задачи: 1. Формирование межведомственных запросов в ручном режиме с любого рабочего места Системы (ручное заполнение информации по запросу). 2. Формирование межведомственных запросов непосредственно из карточки объекта учета, субъекта права или договора (автоматическое формирование запроса в «один клик»). 3. Формирование межведомственных запросов по вручную определенному пользователем перечню объектов учета, субъектов права или договоров в режиме массовой операции (полностью автоматическое формирование запросов без ограничения количества). 4. Автоматическое формирование межведомственных запросов по определенному перечню объектов учета, субъектов права или договоров в режиме регламентной операции (автоматически по расписанию без ограничения количества). Например, автоматическое формирование запроса на получение выписки из ЕГРН через месяц после подписания договора приватизации с целью определения даты перехода права на приватизированный объект (даты регистрации права собственности на нового собственника и исключения объекта из муниципальной доли) - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (2) - После получения ответов на отправленные запросы подсистема в автоматическом или автоматизированном режиме должна позволять: 1. Обеспечивать возможность автоматического и автоматизированного (автоматического по требованию пользователя) внесения изменений в единую базу данных Системы на основе полученных сведений. 2. Автоматически прикреплять полученные сведения к карточке соответствующего объекта учета, субъекта права или договора в базе Системы с обеспечением возможности автоматизированного внесения изменений в карточку объекта учета, субъекта права или договора на основе этих сведений. 3. Обеспечивать возможность в автоматизированном режиме формировать информацию, аналитические и статистические отчеты, запросы на основе полученных в результате межведомственных запросов сведений, например, формировать уведомления о необходимости регистрации права собственности на приобретаемые в собственность объекты муниципальной собственности (покупке, приватизация) лицам или организациям, нарушившим сроки регистрации. Функции подсистемы должны быть использованы для автоматизации выполнения следующих задач: 1. Определения даты исключения объекта из муниципальной собственности в ходе продажи/приватизации объекта. 2. Определения периода нахождения объекта в муниципальной казне, обеспечения корректного бюджетного учета движения объектов в казне. 3. Определения даты расторжения договоров аренды на объекты муниципальной собственности в ходе выкупа из аренды. 4. Определения даты передачи муниципальной собственности на праве оперативного управления или хозяйственного ведения. 5. Уточнения сведений по объектам муниципальной собственности, подлежащим продаже, приватизации, наложению других обременений и/или вещных прав. 6. Уточнения площадных, стоимостных и других характеристик объектов муниципальной собственности. 7. Уточнение сведений по зарегистрированным правам на объекты муниципальной собственности - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (3) - 8. Определения периода оплаты взносов на капитальный ремонт объектов муниципальной собственности, расположенных в многоквартирных жилых домах, включенных в программу капитального ремонта. Общей целью подсистемы должно быть обеспечение полноты и актуальности информации по объектам муниципальной собственности, земельным участкам, право собственности на которые не разграничено, вне-реестровым объектам учета, субъектам права, договорам и другим правам на объекты, подлежащие учету в рамках единого информационного фонда Системы. Для достижения поставленных целей подсистема должна обеспечить получение информации от участников межведомственного электронного взаимодействия путем формирования запросов в соответствии с установленными методическими рекомендациям, размещенными на портале https:/info.gosuslugi.ru Подсистема должна обеспечить: 1. Своевременное получение информации об изменении состава и/или содержания зарегистрированных на объекты учета прав, актуализацию соответствующих сведений в единой базе данных. 2. Своевременное проведение процедур, связанных с изменением информации по объектам учета, субъектам права и зарегистрированным правам. 3. Обеспечение полноты и качества ведения бюджетного учета движения объектов в муниципальной казне на основе актуальной информации по датам перехода права собственности на объекты учета, прав оперативного управления и хозяйственного ведения. 4. Обеспечение полноты и качества администрирования поступлений по администрируемым кодам бюджетной классификации на основе актуальной информации о регистрации договорных отношений. 5. Контроль за расходованием бюджетных средств на обслуживание объектов муниципальной собственности, включая оплату взносов на капитальный ремонт и др. - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (4) - В составе подсистемы должны быть реализованы следующие средства: 1. Интегрированное хранилище данных в составе единой базы данных Системы. 2. Интегрированные средства ведения справочников и классификаторов. 3. Средства настройки. 4. Средства ручного формирования межведомственных запросов. 5. Средства формирования межведомственных запросов из карточки объекта Системы. 6. Средства формирования межведомственных запросов в режиме массовой операции. 7. Средства формирования межведомственных запросов в режиме регламентной операции. 8. Средства подписания запросов электронной подписью. 9. Средства ручного внесения результатов запросов, которые не формировались средствами подсистемы. 10. Средства предотвращения повторного формирования запросов 11. Средства опроса системы СМЭВ на предмет уточнения состояния запроса. 12. Средства загрузки полученных сведений в интегрированной хранилище данных. 13. Средства автоматического внесения изменений в единую БД Системы на основе полученных сведений. 14. Алгоритмы автоматического внесения изменений в единую БД Системы на основе полученных сведений. 15. Средства «закрытия» запросов. 16. Средства работы с журналом межведомственных запросов. 17. Средства работы с карточкой межведомственного запроса. 18. Средства поиска объектов Системы по параметрам межведомственных запросов. 19. Средства просмотра протоколов выполнения операций. 20. Средства администрирования и разграничения прав пользователей - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (5) - Интегрированное хранилище данных в составе единой базы данных Системы Интегрированное хранилище данных должно быть предназначено для обеспечения хранения взаимосвязанной между собой информации подсистемы в составе единой базы данных Системы. Интегрированное хранилище данных должно обеспечивать хранение информации без дублирования, повторного внесения информации, которая уже содержится в единой базе данных Системы. Интегрированное хранилище должно содержать ссылки на объекты, субъекты и договоры единой базы данных Системы. Интегрированное хранилище должно обеспечивать хранение в единой базе данных Системы следующей информации: 1. Нормативно-справочная информация подсистемы (содержимое справочников и классификаторов, использующихся в подсистеме). 2. Информацию о настройках функционирования подсистемы. 3. Информация по сформированным запросам, полученным в ходе запросов сведениям. 4. Протоколы всех действий, выполняемых средствами подсистемы в автоматическом, полуавтоматическом и ручном режимах. 5. По каждому запросу должна быть размещена следующая информация: 5.1. Идентификатор вида сведений версии 3.х. 5.2. Вид операции из соответствующего классификатора (ручной, из карточки объекта Системы, из массовой операции, регламентная операция, на основе результатов, полученных из других источников), для массовой и регламентной операции – идентификатор операции. 5.3. Дата и время формирования запроса, идентификатор пользователя (если операция инициирована пользователем). 5.4. Информация, переданная в систему СМЭВ в ходе формирования запроса. 5.5. Идентификатор запроса, присвоенный системой СМЭВ. 5.6. Идентификатор карточки Системы, из которой (для которой) сформирован запрос. 5.7. Идентификаторы объекта (помещение или земельный участок), субъекта (юридическое или физическое лицо, ИП), договора, по которым сформирован запрос. Заполняются те идентификаторы, которые применимы для конкретного вида запроса - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (6) - Примечание. Например, запрос информации из ЕГРН для определения даты перехода права в ходе приватизации теоретически может быть сформирован как из договора приватизации, так и из объекта. В этом случае идентификаторы карточки Системы, из которой сформирован запрос, должны быть разные, но идентификатор объекта в обоих запросах должен быть один. Это должно потенциально позволить предотвратить повторные запросы на основе анализа идентификатора объекта. 5.8. Дата и время автоматического или полуавтоматического внесения информации, по полученным сведениям, в единую базу данных. 5.9. Режим внесения изменений (автоматический, полуавтоматический «мастер», ручной) – см. пункт «Интегрированные средства ведения нормативно-справочной информации». 5.10. Идентификатор пользователя, внесшего изменения в ручном или полуавтоматическом режиме – «мастер». 5.11. Признак отработки результатов запроса (да или нет). 5.12. Текущий статус (состояние) запроса в системе СМЭВ. 5.13. Дата и время изменения сведений запроса в системе СМЭВ (по данным СМЭВ). 5.14. Дата и время внесения изменений из системы СМЭВ (изменения статуса запроса). 5.15. Дату и время последнего успешного опроса системы СМЭВ по данному запросу. 5.16. Полную информация обо всех изменениях статусов (состояний) запросов, включая дату и время смены состояния, текстовое описание причины смены состояния, и другие сведения, полученные из системы СМЭВ в ходе информационного обмена - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (7) - 6. Информация, полученная в ходе исполнения межведомственного запроса должна быть представлена в структурированном виде и размещаться ее в реляционных структурах (таблицах) единой базы данных Системы. Информация должна быть представлена в виде, пригодном для формирования SQL-запросов с ее использованием. Должны быть предусмотрены средства заполнения данных в структурированном, реляционном виде на основе информации, размещенной в XML-файле полученного результата запроса. Хранение данных только в XML-файле результата запроса недопустимо. Полученную информацию необходимо вносить в интегрированное хранилище. В интегрированном хранилище должны быть размещены протоколы всех действий, выполняемых средствами подсистемы в автоматическом, полуавтоматическом и ручном режимах, в том числе: 1. Протокол взаимодействия с подсистемой СМЭВ (формирование запроса, опросы с целью получения статуса запроса (пингование), загрузка результата в интегрированное хранилище, парсинг результата, размещение данных результата в реляционных таблицах). 2. Протокол применения результата к объектам базы данных (поиск объектов в базе данных для ручных запросов, автоматическое добавление объектов в базу данных по результатам запросов, внесение изменений в электронные карточки объектов учета на основе полученных данных (индивидуально для каждого выполненного изменения)). Протоколы должны содержать следующую информацию: 1. Дата и время выполнения операции или действия. 2. Имя пользователя, инициировавшего операцию (если операцию инициировал пользователь). 3. Вид операции из соответствующего классификатора (ручной, из карточки объекта Системы, из массовой операции, регламентная операция, опрос (пингование) запроса в системе СМЭВ, получение события из системы СМЭВ), для массовой и регламентной операции – идентификатор операции. 4. Признак успешности выполнения операции из соответствующего классификатора (успешно, не успешно). 5. Выполненное действие (из соответствующего классификатора) - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (8) - 6. Данные, связанные с действием (в текстовом виде), например, при вводе кадастрового номера объекта на основе полученных данных – кадастровый номер. 7. Дополнительная текстовая информация (в случае ошибки – причина ошибки). Интерфейс для работы пользователей с данными, размещенными в интегрированном хранилище, должен быть обеспечен непосредственно Системой с использованием экранных форм, разработанных по общим принципам, принятым для Системы, с использованием единого визуального стиля, оформления Системы. Интегрированные средства ведения справочников и классификаторов Средства должны быть предназначены для управления работой со справочниками и классификаторами подсистемы и обеспечивать единое пространство справочной информации в процессе использования учетных данных и документов. Средства должны обеспечивать выполнение функций: 1. Редактирование справочников и классификаторов. 2. Просмотр справочников и классификаторов. Средства настройки Подсистема должна обеспечивать максимально широкие возможности по настройке, изменению технологии работы подсистемы силами обученных пользователей Системы без привлечения программистов Исполнителя. Должны быть предусмотрены следующие средства настройки, изменения технологии работы подсистемы силами обученных пользователей Системы: 1. Средства настройки перечня доступных сервисов и/или видов сведений для формирования межведомственных запросов в ручном режиме. 2. Средства настройки перечня доступных для каждого из типов объектов учета Системы сервисов и/или видов сведений. 3. Перечень регламентных операций для формирования запросов по расписанию, настройка расписания выполнения регламентных операций. 4. Средства/Алгоритмы чтения полученных в результате межведомственного запроса сведений и размещения их в реляционных субтаблицах интегрированного хранилища (единой базы данных Системы). 5. Средства/Алгоритмы внесения изменений в электронные карточки объектов учета на основе полученных данных - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (9) - 6. Средства/Алгоритмы создания объектов учета, отсутствующих в базе данных, на основе сведений, содержащихся в полученных ответах. 7. Средства/Алгоритмы связи запросов, выполненных в ручном режиме, с объектами, которые уже есть в базе данных Системы на основе сведений, содержащихся в полученных ответах. 8. Средства/Алгоритмы автоматического «закрытия» межведомственных запросов после получения и использования (применения, внесения в базу данных) полученных сведений, возможность индивидуального отключения автоматического «закрытия» запросов. 9. Создание шаблонов автоматического частичного заполнения формы формирования ручного запроса. Средства ручного формирования межведомственных запросов При ручном формировании запроса пользователь должен предварительно выбирать услугу (сервис), для которой формируется запрос. Выбор должен производиться из перечня услуг (сервисов), для которых доступно ручное формирование запроса. В случае, если для некоторого сервиса/услуги предусмотрена возможность формирования запросов по нескольким вариантам параметров (например, по кадастровому номеру или адресу объекта), то должна быть предусмотрена возможность ввода параметров запроса для каждого варианта. При проектировании должна быть предусмотрена возможность создания шаблонов автоматического заполнения одного или нескольких параметров запросов. Должна быть предусмотрена возможность индивидуального создания шаблонов каждым пользователем. Технология создания шаблонов должна быть реализована по следующему принципу – пользователь заполняет те параметры экранной формы ручного формирования запросов, которые должны быть включены в шаблон. Далее пользователь инициирует создание шаблона и вводит его наименование/описание. После этого шаблон автоматически появляется в списке доступных для данного пользователя шаблонов для данной услуги/сервиса. Для одного из шаблонов каждого сервиса/услуги должна быть предусмотрена возможность выбора шаблона по умолчанию - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (10) - Пользователь может выбрать любой доступный для данного сервиса/услуги шаблон, в этом случае соответствующие параметры из шаблона автоматически должны заполнять поля экранной формы ручного формирования запроса. После успешного формирования запроса пользователю должно быть выведено соответствующее сообщение с указанием кода сформированного запроса в журнале запросов. Для запросов по кадастровому номеру или кадастровому кварталу должна быть предусмотрена возможность пакетного формирования ручных запросов на основе кадастровых номеров (или кварталов), определенных в текстовом файле (в столбик) – для каждого кадастрового номера (квартала) автоматически должен быть сформирован запрос. Аналогичная возможность должна быть предусмотрена для запросов по ИНН, ОГРН и другим классификационным кодам юридических, физических лиц, индивидуальных предпринимателей. Средства формирования межведомственных запросов из карточки объекта Системы Формирование межведомственных запросов из карточки объекта Системы подразумевает возможность автоматического формирования запроса в системе СМЭВ. Параметры, необходимые для формирования запроса в автоматическом режиме должны заполняться на основе данных, размещенных в соответствующей карточке объекта учета, из которой формируется запрос. При формировании запроса пользователь должен предварительно выбрать услугу (сервис), для которой формируется запрос. Выбор должен производиться из перечня услуг (сервисов), для которых доступно формирование запроса из карточки объекта данного типа (см. требования к настройке подсистемы). Формирование запроса должно быть реализовано с использованием динамически формируемого перечня пунктов подменю пункта «СМЭВ» меню карточки (или кнопки СМЭВ). Динамически формируемый перечень подменю должна соответствовать перечню доступных для запроса услуг/сервисов с отбивкой сепаратором услуг/сервисов различных организаций (услуги/сервисы различных организаций визуально должны быть отделены друг от друга) - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (11) - В случае, если карточка объекта учета не содержит всей необходимой для формирования запроса информации, пользователь должен быть в развернутой форме информирован о характере возникшей ошибки с указанием конкретных реквизитов объекта, которые должны быть заполнены для корректного формирования запроса. Должна быть предусмотрен режим ручного формирования запроса из карточки объекта. В данном режиме Система инициирует ручное создание запроса, а также производит автоматическое заполнение параметров запроса сведениями, содержащимися в карточке соответствующего объекта учета. После этого пользователю предоставляется возможность самостоятельной корректировки сведений (параметров запроса) и ручного формирования межведомственного запроса. После формирования запроса пользователю должно быть выведено соответствующее сообщение с указанием кода сформированного запроса в журнале запросов. Средства формирования межведомственных запросов в режиме массовой операции Для формирования межведомственных запросов в режиме массовой операции должен быть задействован стандартный механизм Системы работы с массовыми операциями (выбора объектов для выполнения массовой операции). Выбор объектов для массовой операции должен производиться с использованием следующих средств: 1. Из списка объектов учета любых типов основного окна Системы. 2. Из экранных форм Системы, отображающих списки объектов учета произвольных типов. 3. Из окна результата запроса подсистемы «Библиотека запросов». Выбор услуги (сервиса) для формирования запроса должен быть реализован путем динамического создания пунктов подменю пункта СМЭВ. Пункты подменю должны содержать полный перечень всех услуг/сервисов, доступных для формирования из карточек объектов учета, доступных для выполнения массовой операции в текущем режиме работы - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (12) - Выполнение массовой операции должно производиться пообъектно способом, аналогичным формированию запроса из карточки объекта учета соответствующего типа (описание приведено выше). В случае, если операция формирования запроса для данного вида объекта учета недоступна (в соответствии с настройками) или для формирования запроса недостаточно информации, по таким объектам формируется ошибка по правилам функционирования функционала массовых операций (объект помечается красным фоном, формируется развернутое сообщение об ошибке (содержит четкое описание сути ошибки), объект пропускается, происходит переход к обработке следующего объекта). Операции, выполняемые в режиме массовой операции, должны протоколироваться по общим принципам (индивидуальное протоколирование каждого сформированного в режиме массовой операции межведомственного запроса). Средства формирования межведомственных запросов в режиме регламентной операции Регламентная операция представляет собой выполнение некоторого запроса по определенному расписанию, межведомственные запросы формируются в автоматическом режиме для каждого объекта, информация по которому возвращена запросом. Средства формирования межведомственных запросов в режиме регламентных операций должны обеспечивать ведение библиотеки регламентных операций, средства добавления, изменения, удаления регламентных операций, приостановки выполнения регламентных операций. Библиотека регламентных операций должна представлять собой список регламентных операций, содержащий следующие атрибуты: 1. Код идентификатор (код) регламентной операции. 2. Наименование - наименование регламентной операции. 3. Организация – наименование организации, предоставляющей услугу/сервис. 4. Сервис наименование услуги/сервиса для формирования запроса в режиме регламентной операции. 5. Признак успешности предыдущего выполнения. 6. Дата, время следующего выполнения. 7. Состояние (запланировано, приостановлено) - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (13) - 8. Приостановленные регламентные операции или регламентные операции, для которых не определено время следующего запуска должно визуально выделяться (серый текст шрифта). 9. Регламентные операции, по которым предыдущий вызов был завершен ошибкой должны визуально выделяться (розовый фон). 10. Для каждой регламентной операции должны быть определены: 10.1. Код – присваивается автоматически. 10.2. Наименование регламентной операции. 10.3. Описание регламентной операции – текст произвольного размера. 10.4. Услуга/сервис – выбор из списка услуг/сервисов, доступных для формирования запросов в режиме регламентной операции. Расписание выполнения операции (стандартный функционал для формирования расписаний) – в определенное время разово, ежечасно, ежедневно, еженедельно в определенные дни. Средства подписания запросов электронной подписью С целью обеспечения возможности автоматизированного формирования запросов в пакетном режиме, а также автоматического формирования запросов в режиме массовой операции в Подсистеме должны быть реализованы средства централизованного (серверного) принципа подписания запросов электронной подписью. Для этого в составе подсистемы должен быть реализован сервер ЭП (сервер электронной подписи). Это означает, что в подсистеме должна быть реализована возможность добавления одной или более учетных записей организаций/пользователей организаций, настройки и реквизиты которых будут использоваться для формирования межведомственных запросов и подписания их электронной подписью. Для каждой учетной записи должна быть обеспечена возможность сопоставления с ЭП-ОВ (электронной подписи органа власти) и ЭП-СП – электронная подпись служебного пользования уполномоченного лица (руководителя), которые загружены на сервер ЭП - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (14) - Для каждого пользователя Системы, в должностные обязанности которого входит возможность формирования межведомственных запросов, должна быть предусмотрена возможность указать учетную запись организации/уполномоченного лица организации, электронные подписи которой будут использоваться для автоматического подписания запросов, сформированных соответствующим пользователем. Запросы, формируемые средствами подсистемы в любом из описанных выше режимов, должны подписываться ЭП-ОВ и/или ЭП-СП в зависимости от методических рекомендаций для соответствующего вида сведений. Средства ручного внесения результатов запросов, которые не формировались средствами подсистемы В подсистеме должны быть предусмотрены средства внесения результатов запросов, полученных из внешних источников, то есть без использования средств подсистемы. При ручной загрузке результата подсистема должно быть инициировано автоматическое занесение соответствующего запроса в журнал запросов. Дальнейшая обработка загруженного вручную результата должна производиться стандартным способом (загрузка результата в интегрированное хранилище, применение результата (внесение изменений в единую база данных Системы на основе полученных сведений)). В протокол работы с запросом автоматически должна быть добавлена запись, что результат загружен вручную без использования межведомственного взаимодействия. Средства предотвращения повторного формирования запросов Подсистема должна содержать средства повторного формирования запросов на одни и те же объекты учета - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (15) - Под повторным формированием запроса понимается формирование запроса на объект, на который уже был ранее сформирован межведомственный запрос на получение сведений по этой же услуге (сервису), по которому сведения получены, но еще не использованы (запрос не «закрыт»), или запрос находится в состоянии ожидания сведений (ответа), то есть по запрос не был отклонен (не находится в состоянии ошибки), сведения еще не получены. В ходе проверки на наличие предыдущих запросов следует учесть, что запрос на данный объект учета мог быть сформирован не из текущей карточки, например, текущий запрос получения выписки из ЕГРН на объект имущества формируется из карточки договора приватизации этого объекта имущества, однако ранее был сформирован запрос на этот же объект, но из карточки другого договора или самого объекта. Должна быть предусмотрена возможность определения возможности проверки на наличие сформированных ранее запросов в ручном режиме – возможность должна быть определена на этапе реализации. При наличии возможности указанный функционал подлежит реализации. Для каждого сервиса/услуги должна быть предусмотрена возможность настройки количества дней, в течение которых результат предыдущего запроса можно считать актуальным. В случае, если такая настройка произведена, то при ручном формировании запроса или формировании запроса из карточки объекта, при наличии ранее полученного ответа подсистема должна предупреждать пользователя, что уже получен результат на соответствующий запрос с указанием даты его получения и возможностью открытия результата предыдущего запроса. В режиме массовой и регламентной операции формирование таких повторных запросов должно быть заблокировано с указанием причины (по объекту имеется актуальные сведения на запрос, полученные такого-то числа). Средства опроса системы СМЭВ на предмет уточнения состояния запроса, загрузка полученных сведений - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (16) - Основным режимом получения/обновления сведений о сформированных ранее межведомственных запросов из системы СМЭВ является режим периодического опроса (пингования) системы СМЭВ. При наличии изменений с момента последнего опроса (пингования) системы СМЭВ (изменение даты и времени последнего изменения запроса в системе СМЭВ с аналогичными данными в интегрированном хранилище Системы), полученная информация должна быть занесена в интегрированное хранилище Системы: 1. Дата и время последнего изменения состояния или сведений запроса в системе СМЭВ. 2. Текущий статус (состояние) запроса. 3. При изменении статуса (состояния) запроса – информация по изменению состояния (см. требования к интегрированному хранилищу данных). При получении сведений за межведомственный запрос (XML-файл, содержащий сведения), подсистема должна выполнять чтение файла и должна разместить полученную из XML-файла информацию в соответствующих субтаблицах запроса в виде, пригодном для формирования SQL-запросов с использованием полученных сведений. Все операции по опросу (пингованию) системы СМЭВ вне зависимости от наличия изменений должны протоколироваться. Требования к протоколированию приведены в пункте «Интегрированное хранилище данных». Должна быть предусмотрена возможность опроса (пингования) по всем сформированным межведомственным запросам, обработка которых еще не завершена (запрос не находится в состоянии ошибки и сведения по нему еще не получены), а также по межведомственным запросам определенной (выбранной пользователем) услуги (сервиса). Операция должна выполняться из основного окна Системы с использованием соответствующих пунктов меню. В некоторых случаях сведения, содержащиеся в ответе на межведомственный запрос, не передаются в ходе межведомственного взаимодействия, а должны скачиваться пользователем вручную с использованием сети интернет. Такая ситуация возникает, например, из-за большого объема полученных сведений. - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (17) - Средства загрузки полученных сведений в интегрированное хранилище Полученные в результате межведомственного запроса сведения содержат XML-файл заданной в спецификациях к конкретной услуге (сервису) структуры. В момент получения XML-файла должно быть обеспечено чтение всех данных XML-файла и размещение их в интегрированном хранилище Системы (единой базе данных Системы) в структурированном виде, пригодном для использования в SQL-запросах (см. требования к интегрированному хранилищу). Чтение данных XML-файла и размещение их в интегрированном хранилище должно осуществляться с использованием алгоритма из библиотеки алгоритмов парсинга (разбора) результатов запросов, полученных в машиночитаемом виде (xml). Должна быть предусмотрена возможность разработки новых алгоритмов и включение их в библиотеку алгоритмов силами обученных пользователей Системы Заказчика. Должно быть предусмотрено обязательное протоколирование выполнения указанной процедуры. Требования к протоколированию приведены в пункте «Интегрированное хранилище данных»). Загрузка полученных сведений в интегрированное хранилище должно производиться вне зависимости от способа загрузки сведений (автоматическая загрузка при получении ответа на сформированный ранее запрос), ручная загрузка результата, направленного ранее запроса, ручная загрузка результата на запрос, который не был отправлен средствами подсистемы. Средства автоматического внесения изменений в единую БД Системы на основе полученных сведений Автоматическое внесение изменений в единую базу данных Системы на основе полученных сведений должно производится в момент получения сведений на межведомственный запрос после размещения полученных данных в реляционных субтаблицах. Автоматическое внесение изменений должно производиться путем вызова соответствующего алгоритма из библиотеки алгоритмов, наименование которого настраивается для каждой услуги (сервиса) - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (18) - Должна быть предусмотрена возможность разработки новых алгоритмов и включение их в библиотеку алгоритмов силами обученных пользователей Системы Заказчика. По завершении автоматического внесения информации в интегрированном хранилище для данного запроса должны быть установлены дата и время автоматического внесения изменений на основе полученных сведений, признак завершения отработки запроса, а также вид операции – «Автоматическое внесение информации». Должно быть предусмотрено обязательное протоколирование выполнения указанной процедуры. Протоколированию подлежит также факт невыполнения автоматической операции в связи с отсутствием имени алгоритма, выполняющего соответствующее действие. Автоматическое внесение сведений может быть отключено настройками подсистемы (такая настройка должна быть предусмотрена индивидуально для каждого типа объектов учета, а также сервиса/услуги). В случае, если автоматическое внесение изменений отключено, должна быть предусмотрена возможность ручного запуска средств автоматического внесения изменений из окна просмотра результатов запроса. Факт ручного запуска средств автоматического внесения информации должен быть внесен в протокол. Алгоритмы автоматического внесения изменений в единую БД Системы на основе полученных сведений - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (19) - Алгоритм автоматического внесения изменений в единую БД Системы на основе полученных сведений должен быть определен индивидуально для каждого типа объектов учета и каждого сервиса/услуги с возможностью его настройки. Алгоритм должен функционировать по следующему принципу: 1. Если запрос был сформирован вручную, то на основе полученных сведений должен быть выполнен поиск соответствующего объекта в единой базе данных Системы, при успешном поиске запрос должен быть автоматически прикреплен к соответствующему объекту, соответствующее действие должно быть внесено в протокол. 2. Если найти объект не удалось, то в зависимости от настройки (такая настройка должна быть предусмотрена) подсистема автоматически создаст соответствующий объект в единой базе данных Системы и заполнит электронную карточку объекта сведениями, содержащимися в полученных данных. Соответствующие действия должны быть внесены в протокол. 3. Если получены сведения на запрос по объекту, который уже находится в базе данных Системы, то алгоритм опционально (такая настройка должна быть предусмотрена индивидуально для каждого типа объектов учета, сервиса/услуги и действия из перечисленного ниже списка) должен иметь возможность выполнить следующие действия: 3.1. Для каждого реквизита полученных сведений должна быть выполнена сверка с соответствующим реквизитом в электронной карточке соответствующего объекта учета. Возможны следующие варианты: 3.1.1. Если реквизит не заполнен, он подлежит заполнению на основе полученных сведений (должно настраиваться). 3.1.2. Если реквизит заполнен, и он отличен от соответствующего реквизита в полученных сведениях, то в зависимости от настройки либо реквизит подлежит изменению (с протоколированием каждого действия), либо для запроса должно быть сформировано предупреждение (состояние запроса сменится на «Предупреждение») с внесением в текст предупреждения развернутой информации о выявленных различиях - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (20) - 4. Информация о полученных сведениях должна быть занесена в документы по объекту учета (опционально). Для выписок из Росреестра о правах на объекты имущества дополнительно (опционально) должны быть предусмотрены следующие возможности: 1. Сверка с единой БД Системы на предмет наличия объекта в реестре муниципальной собственности (если в Системы объект включен в реестр, а по данным Росреестра – нет или наоборот, то должно быть сформировано соответствующее предупреждение). 2. В случае, если в выписке обнаружена информация о регистрации права на объект имущества Системы, которое перешло новому владельцу на основании документов, фигурирующих в единой БД Системы (например, в ходе продажи или приватизации объекта), то опционально должна быть предусмотрена возможность автоматического исключения объекта из реестра муниципальной собственности датой, предшествующей дате регистрации объекта на нового собственника с автоматическим внесением информации о документе-основании исключения. Автоматические изменения в соответствии с алгоритмами и настройками Системы могут быть инициированы пользователем вручную. В этом случае пользователь должен быть проинформирован о всех произведенных действиях подсистемы (открыт протокол соответствующих действий) с возможностью быстрого доступа (в один клик мыши) к карточке объекта учета для анализа и возможной корректировки соответствующих действий. Средства «закрытия» запросов Под «закрытием» запроса помечается возможность пометки запроса в качестве отработанного, то есть запроса, не требующего дальнейшего анализа или использования пользователем. Должна быть предусмотрена возможность автоматического и ручного «закрытия» запросов - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (21) - Автоматическое «закрытие» запросов должно производиться по настройке (такая настройка должна быть предусмотрена индивидуально для каждого типа объектов учета и услуге/сервису) после успешного получения результатов запроса и автоматического успешного внесения изменений в единой базе данных Системы, предусмотренных соответствующим алгоритмом. Должна быть предусмотрена возможность отключения автоматического «закрытия» запросов индивидуально для каждого пользователя. Ручное «закрытие» должно производится пользователем самостоятельно после изучения и/или использования результатов запроса. «Закрытые» запросы не должно изыматься из единой базы данных Системы, последующий доступ к ним должен быть обеспечен по запросам пользователей. По умолчанию для журнала запросов должна быть предусмотрена возможность отображения не закрытых запросов – см. требования к функционированию журнала запросов. Средства работы с журналом межведомственных запросов Журнал запросов должен представлять собой список запросов, содержащий всю основную информацию по каждому запросу, а также средства открытия карточки запроса и выполнения основных действий над запросом. Журнал запросов должен быть доступен в следующих режимах: 1. Из карточки объекта Системы – журнал размещается на вкладке «СМЭВ» карточки объекта и содержит все межведомственные запросы, которые были сформированы для данного объекта. 1.1. Из основного окна Системы для всех услуг/сервисов, а также индивидуально для каждого из сервисов/услуг в режиме отображения «моих» запросов. Под «моими» запросами понимаются запросы, сформированные текущим пользователем Системы. 1.2. Из основного окна Системы для всех услуг/сервисов, а также индивидуально для каждого из сервисов/услуг в режиме отображения всех запросов - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (22) - Для журнала межведомственных запросов должны быть предусмотрены средства поиска/фильтрации запросов в соответствии с требованиями к функционированию подсистемы поиска и анализа информации Системы: 1. Должны быть предусмотрены возможности поиска запросов по любым параметрам запроса, в том числе: 1.1. Сервис/услуга. 1.2. Код запроса. 1.3. Дата формирования запроса. 1.4. Состояние запроса (с возможностью множественного выбора из справочника состояний). 1.5. Статус запроса (текстовый статус сервисов межведомственного взаимодействия). 1.6. Сообщение протокола прохождения (выполнения) запроса. 1.7. Сообщения протокола применения результатов запроса (внесения изменений в базу Системы по результатам запроса). 1.8. Номер заявки. 1.9. GUID запроса в Системы. 1.10. Признак «закрытия» запроса. 1.11. Тип операции создания запроса (вручную, из карточки объекта, массовая операция, регламентная операция) – множественный выбор из справочника. 1.12. Источник операции создания запроса – множественный выбор из соответствующего справочника. 1.13. Пользователь, инициировавший запрос. 1.14. Дата последнего изменения информации. 1.15. Код регламентной операции. 1.16. Дата получения результата. 1.17. Дата загрузки результата. 1.18. Дата применения результата. 1.19. Тип операции применения результата – из соответствующего справочника. 1.20. Источник операции применения результата – из соответствующего справочника. 1.21. Пользователь, применивший результат. 1.22. Признак автоматического создания запроса при ручной загрузке результата, полученного из внешних источников. 1.23. Признак необходимости ручной загрузки результатов запроса. 1.24. Признак необходимости ручного применения результатов. 1.25. Признак включения в план повторных запросов - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (23) - 2. Должны быть предусмотрена возможность поиска запросов по любым параметрам объектов единой базы данных Системы с использованием экранных форм поиска/фильтрации объектов, предусмотренных для соответствующих объектов в Системы. 3. Должны быть предусмотрена возможность просмотра/корректировки (для администратора) SQL-запроса на выборку запросов в соответствии с параметрами поиска. 4. Должны быть предусмотрен фильтр по умолчанию на отображение запросов, требующих внимания пользователей, то есть запрос не «закрыт» и результат получен (состояние запроса – «Успех, «Предупреждение» или «Ошибка»). Средства работы с карточкой межведомственного запроса Карточка межведомственного запроса должна открываться из журнала запросов в любом из режимов его отображения и содержать следующую информацию/средства управления: 1. Основную информацию по запросу: 1.1. Код запроса. 1.2. Текущее состояние запроса. 1.3. Текстовый статус запроса. 1.4. Дата и время формирования запроса. 1.5. Пользователь, сформировавший запрос. 1.6. Дата и время получения результата запроса. 1.7. Информация по объекту Системы, связанного с данным запросом. 1.8. Сведения о загрузке результата в базу данных. 1.9. Сведения о применении результата (внесении изменений в базу данных). 2. Средства просмотра протоколов работы с запросом. 3. Средства просмотра файлов, полученных в результате запроса (в разархивированном виде). 4. Средства выгрузки файлов результатов запроса на внешний носитель. 5. Средства открытия файлов результатов запросов стандартными средствами операционной системы. 6. Средства просмотра xml-файла результата запроса в виде документа (с применением соответствующих стилей отображения XML в оффлайн-режиме – без требования наличия сети интернет). 7. Печать и выгрузка XML-файла в виде документа. 8. Средства «Закрытия запроса». 9. Средства ручного применения результатов запроса - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (24) - 10. Средства доступа к карточке объекта учета в Системе (в один клик). 11. Средства загрузки результатов запроса (для запросов, требующих ручную загрузку результатов). 12. Средства открытия запроса в системе СМЭВ. Средства поиска объектов Системы по параметрам межведомственных запросов Для объектов базы данных Системы должны быть предусмотрены средства поиска объектов по параметрам межведомственных запросов. Средства указания параметров поиска/фильтрации должны быть интегрированы непосредственно в стандартные окна поиска/фильтрации объектов Системы и должны быть размещены на отдельной вкладке «СМЭВ». Средства поиска должны обладать следующими возможностями: 1. Поиск объектов по наличию или отсутствию межведомственных запросов указанного сервиса/услуги (если не указано, то для любых сервисов/услуг) в заданном диапазоне дат (если не указано, то на любую дату). 2. Поиск объектов по любым параметрам запросов с использованием формы поиска/фильтрации журнала межведомственных запросов. Средства просмотра протоколов выполнения операций Средства просмотра протоколов выполненных операций должны представлять собой таблицу с возможностью стандартной расширенной настройки табличного представления (сортировка, группировка, встроенные фильтры), отображающей все выполненные операции по заданному запросу. Средства просмотра протоколов выполнения операций должны быть доступны из карточки запроса. Средствами подсистемы «Библиотека запросов» Системы должна иметь возможность анализа протоколов по алгоритмам, которые определяются соответствующими запросами в «Библиотеке запросов» - - - Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (25) - Средства администрирования и разграничения прав пользователей Все операции подсистемы, которые могут быть инициированы пользователем, должны подлежать администрированию и разграничению прав доступа. Администрированию должны подлежать: 1. Операции ручного формирования запросов – индивидуально для каждого вида услуги (сервиса) – по справочнику услуг (сервисов). 2. Операции формирования запросов из карточек объектов учета – индивидуально для каждого вида объекта и услуги (сервиса). 3. Операции формирования запросов в режиме массовой операции – индивидуально для каждого вида объекта в массовой операции и услуги (сервиса). 4. Операции ручной загрузки сведений, полученных из сторонних источников – индивидуально для каждого вида объекта и услуги (сервиса). 5. Операции ручного инициирования автоматического внесения изменений на основе полученных сведений – индивидуально для каждого вида объекта и услуги (сервиса). 6. Просмотр, печать, экспорт результатов, сформированных ранее запросов – индивидуально для каждого вида объекта и услуги (сервиса) - - - Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» (1) - Подсистема должна обеспечивать автоматический сбор и передачу информации по начислениям из Системы в Государственную информационную систему государственных и муниципальных платежей (ГИС ГМП) с использованием протоколов СМЭВ в форматах и порядке, утвержденных приказом Федерального казначейства от 12 мая 2017 г. № 11н «Об утверждении Порядка ведения Государственной информационной системы о государственных платежах». Подсистема должна быть реализована в виде сервисов ОС, которые выполняют следующие функции: 1. Формирование и присвоение УИН (уникальный идентификатор) начислениям всех типов (в соответствии с методическими и форматными требованиями ГИС ГМП). 2. Автоматический сбор информации по начислениям, а также корректировкам и аннулированиям начислений из Системы. 3. Формирование сообщений в утверждённых форматах ГИС ГМП, заверение их электронной подписью (ЭП) и передача сообщений по протоколам СМЭВ, формирование протокола отправки и подтверждения получения из ГИС ГМП. 4. Анализ полученных ответов и создание необходимых записей/протоколов в БД Системы. 5. Автоматическое распределение поступлений, в которых указан корректный UIN, по договорам Системы. Подсистема должна автоматизировать работу оператора начислений, снять нагрузку по ручному формированию и отправке начислений в Федеральное казначейство, а также проверки статусов начислений. Вся работа должна осуществляться в стандартном интерфейсе Системы, средства взаимодействия должны функционировать полностью автоматически и не требовать дополнительных действий от пользователей Системы - - - Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» (2) - Средства импорта поступлений из ГИС ГМП, квитирования начисления Подсистема должна обеспечить в автоматическом режиме получение платежей из ГИС ГМП и размещение их в журнал платежей подсистемы. Получение платежей должно выполняться полностью автоматическом фоновом режиме по заданному расписанию. Журнал платежей ГИС ГМП должен обеспечивать выполнение следующих задач: 1. Хранение полной информации по всем полученным платежам (атрибутам платежей), в объеме и составе атрибутов, использующихся в финансово-аналитической подсистеме Системы, журнале нераспределенных платежей. 2. Хранение даты получения информации о платеже. 3. Ведение журнала (лога) всех операций, выполняемых над платежами в журнале. 4. Постановка функции получения платежей на паузу. 5. Обеспечение поиска/фильтрации платежей в журнале по всем параметрам платежей, а также их состояниям, сообщениям лога работы с платежами. 6. Формирование и ведение информации о несквитированной сумме платежа в режиме реального времени. Информация об автоматическом квитировании начислений платежами на стороне ГИС ГМП (при совершении платежа плательщиком с использованием УИН начисления) должна приниматься из ГИС ГМП в автоматическом режиме одновременно с получением информации о соответствующих платежах. В случае получения информации об автоматическом квитировании должен быть автоматически произведен поиск соответствующих начислений в журнале начислений и связывание платежа с этими начислениями (квитирование) - - - Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» (3) - Должна быть предусмотрена возможность ручного квитирования начислений. Ручное квитирование начислений с платежами должно выполняться путем выбора платежа, квитирующего данное начисление с указанием суммы квитирования. Выбор платежа должен производиться с использованием инструментов журнала платежей подсистемы. Должен быть предусмотрен комплекс проверок – сумма квитирования не должна превышать суммы начисления, начисление может быть сквитировано с платежом на сумму, не превышающую сумму платежа. Должна быть предусмотрена возможность частичного квитирования начисления (квитирования не всей суммы начисления) - - - Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» (4) - Ручное квитирование должно быть предусмотрено только для успешно отправленных в ГИС ГМП начислений, сумма которых не сквитирована или не полностью сквитирована с платежами. Должна быть предусмотрена возможность квитирования начислений с отсутствующим платежом (в соответствии с технологией квитирования, предусмотренной в ГИС ГМП). Информация о вручную выполненных квитированиях должна автоматически отправляться в ГИС ГМП в соответствии с форматами обмена (действующая версия формата на момент заключения Контракта). Средства автоматического распределения поступлений с использованием УИН Поступления по администрируемым кодам бюджетной классификации (КБК) поступают в журнал нераспределенных поступлений финансово-аналитической подсистемы из системы СУФД Федерального Казначейства. В Системе должна быть предусмотрена возможность выполнения автоматических операций по автоматическому распределению поступлений на договоры с привязкой к виду начисления. В случае, если информация о поступлении содержит УИН начисления, эта информация должна использоваться для однозначного определения договора и вида начисления путем поиска по УИН и анализа информации о соответствующем начислении. Должно быть выполнено соответствующее развитие алгоритмов автоматического распределения поступлений по договорам и видам начислений финансово-аналитической подсистемы - - - Требования к видам обеспечения (1) - 4.1 Информационное обеспечение Системы Информационный обмен между узлами Системы основывается на стандартных протоколах передачи данных, использующих сетевой протокол TCP/IP. 4.2 Требования к контролю, хранению, обновлению и восстановлению данных Система должна контролировать корректность вводимой информации, а также проверять логическую целостность информации в БД при выполнении операций с БД. Стратегию и план резервного копирования разрабатывает Заказчик на основе рекомендаций Исполнителя, исходя из следующих условий: 1. Емкость и производительность системы резервного копирования. 2. Объемов разделов БД. 3. Допустимого времени восстановления. 4. Требований по обеспечению сохранности информации. Система должна протоколировать все события, связанные с изменением своего информационного наполнения, и иметь возможность, в случае сбоя в работе, восстанавливать свое состояние, используя ранее запротоколированные изменения данных. 4.3 Аппаратное обеспечение Системы Система должна функционировать на предоставленном Заказчиком оборудовании, с перечисленными ниже характеристиками. Оборудование предоставляется Заказчиком не позднее чем через 2 дня после заключения контракта. 4.3.1 Основной сервер Системы - - - Требования к видам обеспечения (2) - На нем размещаются следующие функциональные серверы: 1. Сервер БД – сервер баз данных СУБД, предназначены для хранения и управления информацией базы данных Системы. В качестве СУБД может быть использован Postgres версии не менее 12.0 или эквивалент. 2. Сервер приложений - обеспечивает предоставление доступа Клиентских мест, автоматизированных рабочих мест (далее - АРМ) пользователей к данным Системы, а также содержит средства обеспечения корректности исполнения технологических процессов (бизнес-логики) функционирования Системы. Представляет собой промежуточное звено обеспечения взаимодействия между АРМ пользователей и Сервером БД. Сервер должен иметь конфигурацию не ниже следующей: 1. Процессор: 8 ядер, частота не менее 2 ГГЦ на одно ядро. 2. Оперативная память не менее 16 Гб (рекомендуется от 32 Гб). 3. Емкость HDD не менее 400 Гб свободного места. 4. СУБД PostgreSQL 12.0 и выше 5. Операционная система. 5.1. Семейства Linux: - Ubuntu 20.04 LTS - Ubuntu 22.04 LTS - RedHat Enterprise Linux (version 8) - АльтЛинукс РС 10.2 (или выше) - РЕД ОС 8.0 - Astra Linux SE 1.8 - Альт СП 10 5.2. Семейства Windows: -Windows Server 2019 - Windows Server 2022 - Windows 10 - Windows 11 6. Доступ к серверу БД по протоколу TCP\IP. 7. При использовании ОС на базе Linux сервер: 7.1. Наличие графической оболочки (рабочего стола) 7.2. Возможность удаленного подключения по RDP (xRDP или аналог). 7.3. Возможность установки обновления для операционной системы, а также установки дополнительных пакетов (ПО) необходимых для работы сопровождаемого программного обеспечения из стандартных дистрибутивов - - - Требования к видам обеспечения (3) - 4.3.2 Сервер платформы СМЭВ Сервер платформы СМЭВ (сервер ЭП) – предназначен для автоматизации межведомственного электронного взаимодействия органов управления муниципальной собственностью в части формирования межведомственных запросов по протоколам СМЭВ в отношении объектов учета, субъектов права и договоров, зарегистрированных в единой базе данных Системы, а также автоматизации внесения изменений в базу данных Системы на основе полученных сведений. Требует для своей работы установку КриптоПро CSP версии не ниже 5.0. Заказчик организовывает наличие защищенного канала до СМЭВ (РСМЭВ). В случае невозможности организации защищенного канала для основного сервера, сервер платформы СМЭВ может быть размещен на отдельном сервере. Сервер платформы СМЭВ имеет конфигурацию не ниже следующей: 1. Операционная система. Windows: необходима подсистема WSL2 не ниже Windows Server 2019 (для серверов) не ниже Windows 10 22H2 должна быть включена виртуализация Linux: Astra Linux Ubuntu не ниже 22.04 Альт СП 10 2. Оперативная память не менее 64 Гб. 3. Процессор 4х ядерный процессор с тактовой частотой не менее 2 Ггц. 4. СУБД PostgreSQL не ниже 12. 5. Доступ к Web-серверу по протоколу TCP/IP (перечень портов согласовывается). 4.3.3 Сервер резервного копирования для единой базы данных Системы Сервер резервного копирования предназначен для хранения резервных копий. В качестве сервера можно использовать сетевую папку на стороннем компьютере или NAS хранилище с аналогичными характеристиками или любой из имеющихся серверов с малой производительностью, но достаточной дисковой подсистемой - - - Требования к видам обеспечения (4) - Сервер имеет емкость HDD не менее 500 Гб с возможностью увеличения по необходимости. 4.3.4 Клиентские рабочие места Клиентские рабочие места должны иметь следующую конфигурацию: 1. Процессор Intel Celeron 4900 или выше. 2. Количество ядер процессора: не менее 2. 3. Базовая тактовая частота процессора: не менее 3.10 Ггц. 4. Оперативная память не менее 4 Гб. 5. Жесткий диск 1 Гб свободного места на диске. 6. Операционная система – семейство Windows (Windows 7 и выше). 7. Офисный пакет 32 бит (для работы с отчетами и печатными формами). 8. Для работы межведомственного взаимодействия необходимо: 8.1. Яндекс браузер v.25 и выше, MS EDGE v20, Google Chrome v57 и выше, Opera v44 и выше, Firefox v52 и выше. 8.2. Браузер должен поддерживать HTML5, CSS3, выполнение JavaScript должно быть разрешено - - - Требования к поставке (1) - В рамках поставки Автоматизированной системы управления муниципальной собственностью (АС УМС) для нужд Управление имущественных отношений администрации Минераловодского муниципального округа Ставропольского края, Исполнитель должен Заказчику передать простые (неисключительные) права на условиях простой (неисключительной) лицензии в течение всего срока действия исключительного права на использование Системы в следующем составе: 1. 4 (четыре) клиентских места в режиме полнофункционального доступа, включающие следующие компоненты: 1.1. Подсистема «Имущество». 1.2. Подсистема «Земля». 1.3. Подсистема «Ведение информации по субъектам права». 1.4. Подсистема «Ведение информации по акциям». 1.5. «Адресная подсистема». 1.6. Подсистема «Ведение договоров и дополнительных соглашений» 1.7. Подсистема «Выкуп с рассрочкой». 1.8. «Финансово-аналитическая подсистема». 1.9. Подсистема «Автоматизация претензионной и исковой деятельности». 1.10. Аналитическая и сервисная подсистема «Библиотека запросов». 1.11. Подсистема «Формирование отчетов и печатных форм, генератор отчетов». 1.12. Подсистема «Обеспечение безопасности, администрирования и разграничения прав доступа». 1.13. Подсистема «Ведение нормативно-справочной информации». 1.14. Подсистема «Автоматическое обновление клиентских рабочих мест». 1.15. Подсистема «Оповещение пользователей». 1.16. Подсистема «Самодиагностика с оповещением о выявленных аномалиях по электронной почте» - - - Требования к поставке (2) - 1.17. Средства ведения электронных карточек объектов учета. 1.18. Средства поиска, отображения и анализа информации. 1.19. Средства предварительного просмотра. 1.20. Средства выполнения массовых операций. 2. Подсистема Межведомственное электронное взаимодействие. Платформа СМЭВ». 3. Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП». Клиентское место полного доступа должно обладать полнофункциональными возможностями всех компонентов в составе АС УМС в Управление имущественных отношений администрации Минераловодского муниципального округа Ставропольского края. В случае, если Исполнитель не является правообладателем Системы, то он должен являться официальным партнером Лицензиара (подтверждается заверенной копией партнерского договора участника с Лицензиаром) - - - Требования к результатам оказания услуг (1) - Результатом является поставка автоматизированной системы управления муниципальной собственностью (АС УМС) для Управление имущественных отношений администрации Минераловодского муниципального округа Ставропольского края. Документация должна быть предоставлена Заказчику в период исполнения контракта Исполнителем в одном экземпляре в электронном виде и соответствовать требованиям настоящего технического задания и государственных стандартов. Перечень подлежащих разработке Исполнителем видов и комплектов документов: 1. Руководство пользователя Системы. 2. Программа и методика испытаний. 3. Лицензионный договор на использование программного обеспечения на праве простой неисключительной лицензии. 4. Акт приема-передачи неисключительных прав на использование Системы в следующем составе: 1. 4 (четыре) клиентских места в режиме полнофункционального доступа, включающие следующие компоненты: 1.1. Подсистема «Имущество». 1.2. Подсистема «Земля». 1.3. Подсистема «Ведение информации по субъектам права». 1.4. Подсистема «Ведение информации по акциям». 1.5. «Адресная подсистема». 1.6. Подсистема «Ведение договоров и дополнительных соглашений» 1.7. Подсистема «Выкуп с рассрочкой» - - - Требования к результатам оказания услуг (2) - 1.8. «Финансово-аналитическая подсистема». 1.9. Подсистема «Автоматизация претензионной и исковой деятельности». 1.10. Аналитическая и сервисная подсистема «Библиотека запросов». 1.11. Подсистема «Формирование отчетов и печатных форм, генератор отчетов». 1.12. Подсистема «Обеспечение безопасности, администрирования и разграничения прав доступа». 1.13. Подсистема «Ведение нормативно-справочной информации». 1.14. Подсистема «Автоматическое обновление клиентских рабочих мест». 1.15. Подсистема «Оповещение пользователей». 1.16. Подсистема «Самодиагностика с оповещением о выявленных аномалиях по электронной почте». 1.17. Средства ведения электронных карточек объектов учета. 1.18. Средства поиска, отображения и анализа информации. 1.19. Средства предварительного просмотра. 1.20. Средства выполнения массовых операций. 2. Подсистема Межведомственное электронное взаимодействие. Платформа СМЭВ». 3. Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» - -

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

Класс программ для электронных вычислительных машин и баз данных - (02.07) Средства управления базами данных - -

Способ предоставления - Копия электронного экземпляра - -

Вид лицензии - Простая (неисключительная) - -

Клиентское место полного доступа, обладающее полнофункциональными возможностями всех компонентов в составе АС УМС в Управления имущественных отношений администрации Минераловодского муниципального округа Ставропольского края - ? 4 - Штука -

Клиентское место АС УМС полного доступа первое (Базовый комплект) – 1 единица - наличие - -

Клиентское место АС УМС полного доступа со 2 по 4 – 3 единицы - наличие - -

Платформа СМЭВ-Диалог – 1 единица - наличие - -

Подсистема «ГИС ГМП. Начисления, платежи, квитирование» – 1 единица - наличие - -

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

Система должна быть построена по 3х-звенной архитектуре и состоять из следующих компонентов (1) - 1. Системы управления базами данных (СУБД) – предназначены для хранения и управления информацией базы данных Системы. Система должна быть совместима с СУБД Исполнителя или эквивалентной (далее - СУБД). В случае, если предлагаемая Исполнителем для использования СУБД не является свободно распространяемым программным обеспечением, то Исполнитель передает Заказчику права на использование СУБД без каких-либо ограничений на использование, в том числе без ограничений по сроку действия лицензии, количеству подключений, размеру используемых баз данных. СУБД не должна иметь ограничений по размеру базы данных и не должна требовать дополнительных обязательных расходов на сопровождение - -

Система должна быть построена по 3х-звенной архитектуре и состоять из следующих компонентов (2) - 2. Сервер приложений – промежуточное звено обеспечения взаимодействия клиентских мест и СУБД. Сервер приложений для Системы должен обеспечивать предоставление доступа клиентских мест к данным Системы, а также содержать средства обеспечения корректности исполнения технологических процессов (бизнес-логики) функционирования Системы. Сервер приложений не должен требовать ручного запуска перед началом работы пользователей Системы. С целью минимизации сетевого траффика сервер приложения должен обеспечивать передачу клиентским местам информацию порциями по настраиваемому количеству записей (количество записей, которое помещается на экран без прокрутки при любом из используемых разрешений экрана) по мере обращения. Передача информации на клиентское место из используемых справочников и классификаторов должна производиться при первом обращении к справочникам и классификаторам (за исключением системных справочников и классификаторов, необходимых для функционирования Системы в целом). Передача информации на клиентское место по открытым электронным карточкам объектов учета должна производиться только в том объеме, в котором информация отображается в соответствующий момент в карточке объекта учета. Например, информация, размещенная на неоткрытых вкладках карточки объекта учета, должна передаваться на клиентское место непосредственно в момент перехода на соответствующую вкладку - -

Система должна быть построена по 3х-звенной архитектуре и состоять из следующих компонентов (3) - 3. Клиентские места – «тонкий» (Desktop) клиент - пользовательские приложения, устанавливаемые на рабочих местах пользователей для предоставления доступа пользователей к функциям Системы или web-клиент. Клиентские места должны обеспечивать возможность доступа ко всему объему функционала Системы, который описан в разделе «Состав Системы, функциональные требования» - -

Требования к размещению средств обеспечения корректности исполнения технологических процессов (бизнес-логики) Системы (1) - Средства обеспечения корректности исполнения технологических процессов (бизнес-логики) в максимально возможном объеме должны быть реализованы на уровне базы данных (выполняться в автоматическом режиме на уровне СУБД). Данное требование продиктовано необходимостью корректной обработки информации при ее модификации в информационном фонде Системы любым из доступных способов вплоть до корректировки средствами СУБД (запуском скриптов непосредственно в базе данных), а также обеспечением возможности изменения технологических процессов пользователями Системы путем изменения логики реализации технологических процессов на стороне SQL - -

Требования к размещению средств обеспечения корректности исполнения технологических процессов (бизнес-логики) Системы (2) - На уровне СУБД должны быть реализованы следующие процессы (технологические процессы или их части): 1. Ведение аудита действий пользователей на уровне полей таблиц (конкретных атомарных атрибутов объектов учета, в том числе в составе составных характеристик). 2. Проверка прав пользователей (хранимые функции или процедуры проверки прав пользователей). 3. Поддержка функционирования средств «быстрого поиска» (по необходимости). 4. Начисление арендной платы, платы за выкуп, платы за фактическое использование объектов, всех видов штрафных санкций, включая начисление пени, процентов за пользование чужими денежными средствами. 5. Расчет сальдо. 6. Расчет задолженности на произвольную дату в произвольном разрезе. 7. Пересчет задолженности на текущее число по всем видам договорных отношений - -

Требования к размещению средств обеспечения корректности исполнения технологических процессов (бизнес-логики) Системы (3) - Средства обеспечения технологических процессов, которые не могут быть реализованы на стороне СУБД, должны быть реализованы средствами сервера приложения. Для удобства пользователей часть технологических процессов должна быть продублирована на клиентском месте для обеспечения своевременности информирования пользователя о недопустимости производимых им изменений в момент совершения изменения (до передачи/сохранения изменений на сервер приложения или в базу данных). Например, при удалении из карточки объекта информации, которая используется в информации в карточках других объектов средства проверки допустимости операции (контроль ссылочной целостности) должны быть исполнены непосредственно в момент выполнения операции, а не в момент пакетного сохранения всех выполненных изменений в карточке объекта учета (нажатие пользователем кнопки «Сохранить изменения» или эквивалент). При этом в момент сохранения изменений соответствующая проверка должна быть выполнена повторно средствами сервера приложения или СУБД непосредственно в момент сохранения изменений карточки в рамках соответствующей транзакции. Таким образом, на клиентском месте должны быть продублированы те элементы технологических процессов, которые могут определить некорректные действия пользователя непосредственно в момент их совершения, а не в момент пакетного сохранения выполненных изменений - -

Требования к способам и средствам связи для информационного обмена между компонентами Системы - Система должна обеспечивать коллективную работу пользователей объекта автоматизации с использованием единого интегрированного хранилища данных по технологии «клиент-сервер» с использованием трехзвенной архитектуры - -

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

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

Требования к защите информации от несанкционированного доступа (2) - Защита информации от несанкционированного доступа в Системе должна обеспечиваться реализацией следующих функций Системы: 1. Предоставление доступа к Системе должно предоставляться только предварительно зарегистрированным пользователям. 2. Возможность разграничения доступа к подсистемам для каждого пользователя. 3. Возможность для каждого пользователя установить уровень доступа, обеспечивающий только просмотр или редактирование информации. 4. Управление разграничением и/или уровнями доступа пользователей должно осуществляться через группы доступа. 5. Разграничение по доступу к данным Системы должно быть согласно утвержденным полномочиям пользователей Системы. 6. Регистрация входа (выхода) пользователей в Систему (из Системы) должна фиксироваться в журнале действий пользователей. 7. Должна быть возможность функционального разграничения действий пользователей при обработке информации. 8. Ведение справочника пользователей Системы. 9. Журналирование действий пользователей, которое должно обеспечиваться путем ведения в Системе «журнала событий», доступного только с автоматизированного рабочего места администратора и включающего в себя следующие данные: 9.1. Системные действия: дата, событие, пользователь. 9.2. Действия над пользователями Системы: дата, событие, администратор. 9.3. Действия пользователей. «Журнал событий» должен быть недоступен к внесению изменений - -

Требования к защите информации от несанкционированного доступа (3) - Система должна обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях Система должна выдавать пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных. Должна быть предусмотрена возможность резервного копирования и ручного восстановления стандартными средствами системы управления базой данных (далее – СУБД) администраторами Системы обрабатываемой информации из резервной копии в следующих аварийных ситуациях: 1. Ошибочные действия пользователей (администраторов), приведшие к утрате или искажению данных Системы. 2. Отказ Системы, связанный с фатальным нарушением целостности файловой системы или структуры баз данных. Для резервного копирования должны использоваться штатные средства системной программной платформы, причем организация баз данных Системы должна обеспечивать сохранение: 1. Всех параметров настройки Системы, включая учетные записи и персональные настройки пользователей. 2. Всей информации Системы - -

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

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

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

Состав системы, функциональные требования - Система состоит из следующих подсистем, средств и других элементов, выполняющих соответствующие функции: 1. Подсистема «Имущество». 2. Подсистема «Земля». 3. Подсистема «Ведение информации по субъектам права». 4. Подсистема «Ведение информации по акциям». 5. «Адресная подсистема». 6. Подсистема «Ведение договоров и дополнительных соглашений» 7. Подсистема «Выкуп с рассрочкой». 8. «Финансово-аналитическая подсистема». 9. Подсистема «Автоматизация претензионной и исковой деятельности». 10. Аналитическая и сервисная подсистема «Библиотека запросов». 11. Подсистема «Формирование отчетов и печатных форм, генератор отчетов». 12. Подсистема «Обеспечение безопасности, администрирования и разграничения прав доступа». 13. Подсистема «Ведение нормативно-справочной информации». 14. Подсистема «Автоматическое обновление клиентских рабочих мест». 15. Подсистема «Оповещение пользователей». 16. Подсистема «Самодиагностика с оповещением о выявленных аномалиях по электронной почте». 17. Средства ведения электронных карточек объектов учета. 18. Средства поиска, отображения и анализа информации. 19. Средства предварительного просмотра. 20. Средства выполнения массовых операций. 21. Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ. 22. Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» - -

Подсистема «Имущество» (1) - Подсистема «Имущество» должна автоматизировать ведение реестра объектов муниципальной собственности, а также внереестровых объектов всех учитываемых типов. Доступ к объектам имущества должен осуществляться из основного окна Системы с использованием иерархического меню. Перечень учитываемых типов и конкретная настройка иерархического меню доступа к объектам должны быть определены на этапе обследования организации. Например, иерархическое меню доступа и перечень учитываемых типов объектов могут быть настроены в ручном режиме, например, в соответствии со схемой: 1. Недвижимое имущество: 1.1. Жилой фонд: 1.1.1. Жилые здания. 1.1.2. Жилые квартиры, помещения. 1.1.3. Жилые комнаты. 1.2. Нежилые здания. 1.3. Нежилые помещения. 1.4. Объекты незавершенного строительства. 1.5. Объекты инженерной инфраструктуры, сооружения. 1.6. Объекты внешнего благоустройства. 1.7. Доли. 1.8. Нематериальные активы, объекты интеллектуальной собственности. 1.9. Воздушные и морские суда, суда внутреннего плавания. 1.10. Космические объекты. 1.11. Прочие объекты, не включенные в указанные группировки. 2. Движимое имущество: 2.1. Особо ценное движимое имущество. 2.2. Малоценное (прочее) движимое имущество. 2.3. Транспортные средства. 2.4. Объекты инженерной инфраструктуры. 2.5. Прочее движимое имущество, не относящиеся к указанным выше. 3. Акции, паи, доли. 4. Имущественные комплексы. 5. Муниципальные предприятия и учреждения. Должна быть предусмотрена возможность скрытия неиспользуемых на момент внедрения пунктов меню (видов объектов учета) - -

Подсистема «Имущество» (2) - Подсистема должна автоматизировать выполнение следующих основных задач. 1. Учет объектов. Для каждого из объектов должна вестись следующая основная информация: 1.1. Наименование объекта. 1.2. Принадлежность к реестру, подреестру (с историей изменения и ссылками на документы-основания). 1.3. Реестровый номер (с историей изменения и ссылками на документы-основания). 1.4. Кадастровый номер (не обязательный для заполнения, при наличии – обязательный для заполнения), условный номер. 1.5. Адрес (с возможностью ввода множественного адреса). 1.6. Субъекты права (движение на балансе, другие субъекты права) – с историей изменения, множественностью документов-оснований возникновения и прекращения права (ссылки на документы). 1.7. Экономические показатели (балансовые, остаточные стоимости и др.) – с историей изменения и ссылками на документы-основания. 1.8. Технические показатели (с историей изменения и ссылками на документы-основания). 1.9. Документы (все документы, имеющие отношение к данному объекту с делением по направлениям воздействия документов (включение/исключение, внесение изменений, правоустанавливающие, регистрирующие документа) – без ограничения количества и типов регистрируемых документов). 1.10. Комиссии. 1.11. Коэффициенты-характеристики, площадь (с историей изменения и ссылками на документы-основания). 1.12. Части помещений (подвал, полуподвал, этажи): 1.12.1. Коэффициенты-характеристики частей помещений, площадь (с историей изменения и ссылками на документы-основания). 1.12.2. Типы использования частей помещений (с историей изменения и ссылками на документы-основания). 1.12.3. Материал стен, варианты входа, уровни благоустройства, высота потолков – произвольное количество категорий благоустройства с произвольным количеством выбираемых элементов благоустройства в каждой категории, предусмотрена возможность указания уровней благоустройства объекта целиком и каждой из частей помещения отдельно. 1.13. Принадлежность к земельному участку (множественная связь – один - -

Подсистема «Имущество» (3) - 1.15. Признак принадлежности к объектам культурного наследия, а также информация о включении объекта в реестр объектов культурного наследия (Номер в реестре, категория историко-культурного наследия – справочник, Признак принадлежности объекта к объектам религиозного значения, признак принадлежности объекта к ансамблям, ссылка на документ-основание с возможностью указания нескольких документов оснований и период нахождения объекта в реестре с возможностью учета разных периодов включения объектов и соответственно разных данных по нахождению объекта в реестре). 1.16. Информация по проводимым аукционам, торгам, конкурсам. 1.17. Классификация объектов учета – предусмотрена возможность учета произвольного количества категорий классификации с произвольным количеством элементов классификации в каждой из категорий, а также текстовым описанием каждого элемента – с историей изменений и ссылками на документы-основания присвоения элемента классификации и исключения объекта из классификации (множественность документов-ссылок). 1.18. События (даты) – с историей изменений и ссылкой на документ-основание. 1.19. Признаки («галочки») - принадлежность к чему-либо с текстовым описанием признака. 1.20. Договоры использования и обременения (аренды, купли-продажи, безвозмездного пользования, согласования, разрешения, размещения, сервитуты). 1.21. Информация по претензионной и исковой деятельности (детальная информация по поданным претензиям и искам, включая необходимую классификационную и описательную части, предметы исков, в том числе суммы с делением по видам начислений, перечень этапов претензионной и исковой деятельности с указанием ссылок на документы этапа, уточнение требований) – см. пункт «Подсистема автоматизации претензионной и исковой деятельности» - -

Подсистема «Имущество» (4) - 2. Автоматическое присвоение реестрового номера с возможностью настройки методики и структуры формирования номера, а также возможностью организации сквозной нумерации по нескольким видам объектов учета (настройка категорий нумерации, для каждой категории можно указать перечень видов объектов учета, входящих в категорию). 3. Ведение информации по подобъектам, составным частям объектов. 4. Управление историей изменения основных характеристик объектов и документами-основаниями на проведение изменений. 5. Управление движением объектов в реестре (включение, исключение, перемещение между реестрами, ведение истории реорганизации объектов (слияния, разделения)). 6. Управление движением объектов на балансе и в казне, договорами оперативного управления и хозяйственного ведения. 7. Обеспечение информационного взаимодействия/обмена информацией по объектам муниципальной собственности с субъектами права (балансодержателями и др.) – массовое обновление стоимостных показателей (балансовая, остаточная стоимость, износ), характеристик объектов. 8. Управление движением объектов в казне (с возможностью ведения балансового и забалансового бюджетного учета движения объектов в казне). 9. Ведение документального обеспечения (документов-оснований) движения объектов, изменения характеристик объектов в реестре. 10. Ведение аукционов и торгов на право аренды или купли-продажи объектов. 11. Формирование реестров объектов муниципальной собственности. 12. Формирование выписок из реестров, справок о движении объектов, проектов приказов, постановлений, распоряжений, других необходимых печатных форм. 13. Формирование аналитической отчетности. 14. Проведение экспресс-аналитики. 15. Корректное проставление даты выбытия объекта в зависимости от выбранного документа основания (например, выбытие по исключению из реестра или из-за регистрации права собственности за иным лицом) - -

Подсистема «Имущество» (5) - 16. Возможность указания шаблона для вывода адреса в нужном формате. 17. Возможность работы со справочниками ФИАС при формировании адреса. 18. Управление историей объектов для отслеживания хронологии реорганизации, разделения, объединения объекта. 19. Протоколирование действий пользователей. 20. Возможность прикрепления к карточке объекта учета произвольного количества файлов произвольного типа. 21. Возможность ведения внереестровых объектов. Должна быть предусмотрена возможность смены типа объектов, включенных по ошибке в другие подразделы имущества (в том числе объектов прошлых периодов), например, изменить тип «нежилое здание» на «нежилое помещение» или на «сооружение» и наоборот - -

Подсистема «Земля» (1) - Подсистема «Земля» должна автоматизировать ведение реестров земельных участков, собственность на которую разграничена, а также ведение земельных участков, собственность на которые не разграничена или с другими видами собственности, находящихся в сфере компетенции органов управления земельными ресурсами. Подсистема должна автоматизировать выполнение следующих основных задач: 1. Пообъектный учет земельных участков (ЗУ). Для каждого из ЗУ ведется следующая основная информация: 1.1. Наименование ЗУ. 1.2. Принадлежность к реестру, подреестру (с историей изменения). 1.3. Кадастровый номер (кадастровый квартал выбирается из классификатора, не обязательный для заполнения). 1.4. Категория земель (с историей изменения и ссылками на документы-основания). 1.5. Разрешенное использование (с историей изменения и ссылками на документы-основания). 1.6. Уровень собственности (состояние). 1.7. Реестровый номер (с историей изменения и ссылками на документы-основания). 1.8. Адрес, адресный ориентир (с возможностью ввода множественного адреса). Должна быть предусмотрена возможность указания государственного образования для обеспечения возможности дальнейшего отбора земельных участков по соответствующему показателю. 1.9. Субъекты права (землепользователи, другие субъекты права) – с историей изменения, множественностью документов-оснований возникновения и прекращения права (ссылки на документы), в том числе и права постоянного (бессрочного) пользования. 1.10. Экономические показатели (Кадастровые стоимости и др.) – с историей изменения и ссылками на документы-основания. 1.11. Технические показатели (с историей изменения и ссылками на документы-основания). 1.12. Документы (все документы, имеющие отношение к данному объекту с делением по направлениям воздействия документов (включение/исключение, внесение изменений, правоустанавливающие, регистрирующие документа)). 1.13. Комиссии. 1.14. Коэффициенты-характеристики, площадь (с историей изменения и ссылками на документы-основания) - -

Подсистема «Земля» (2) - 1.15. Информация по использованию ЗУ (классификация для аналитики, ставки арендной платы, типы использования для кадастровой оценки, налоговые ставки по типам использования) с возможностью указания различных типов использования долей земельного участка (с историей изменения и ссылками на документы-основания). 1.16. Перечень объектов недвижимого имущества, размещенных на данном участке. (кадастровый номер, наименование, права) 1.17. Информация по проводимым аукционам, торгам, конкурсам. 1.18. Классификация объектов учета – предусмотрена возможность учета произвольного количества категорий классификации с произвольным количеством элементов классификации в каждой из категорий, а также текстовым описанием каждого элемента – с историей изменений и ссылками на документы-основания присвоения элемента классификации и исключения объекта из классификации (множественность документов-ссылок). 1.19. Информация по претензионной и исковой деятельности (детальная информация по поданным претензиям и искам, включая необходимую классификационную и описательную части, предметы исков, в том числе суммы с делением по видам начислений, перечень этапов претензионной и исковой деятельности с указанием ссылок на документы этапа, уточнение требований) – см. Пункт «Подсистема автоматизации претензионной и исковой деятельности». 1.20. События (даты) – с историей изменений и ссылкой на документ-основание. 1.21. Признаки («галочки») - принадлежность к чему-либо с текстовым описанием признака. 1.22. Договоры использования и обременения (аренды, купли-продажи, безвозмездного пользования, согласования, разрешения, размещения, сервитуты) - -

Подсистема «Земля» (3) - 2. Автоматическое присвоение реестрового номера с возможностью настройки методики и структуры формирования номера, а также возможностью организации сквозной нумерации по нескольким видам объектов учета (настройка категорий нумерации, для каждой категории можно указать перечень видов объектов учета, входящих в категорию). 3. Управление историей изменения основных характеристик ЗУ, документами-основаниями на проведение изменений. 4. Управление движением ЗУ в реестре (включение, исключение, перемещение между реестрами, ведение истории реорганизации объектов (слияния, разделения)). 5. Управление движением ЗУ по субъектам права. 6. Управление движением ЗУ в казне (с возможностью ведения балансового и забалансового бюджетного учета движения объектов в казне). 7. Ведение документального обеспечения (документов-оснований) движения ЗУ, изменения характеристик объектов в реестре. 8. Ведение аукционов и торгов на право аренды или купли-продажи ЗУ. 9. Формирование реестров земельных участков. 10. Формирование выписок из реестра, справок о движении ЗУ, проектов приказов, постановлений, распоряжений, других необходимых печатных форм. 11. Формирование аналитической отчетности в соответствующей сфере. 12. Проведение экспресс-аналитики. 13. Корректное проставление даты выбытия объекта в зависимости от выбранного документа основания (например, выбытие по исключению из реестра или из-за регистрации права собственности за иным лицом). 14. Возможность указания шаблона для вывода адреса в нужном формате. 15. Возможность работы со справочниками ФИАС при формировании адреса. 16. Управление историей объектов для отслеживания хронологии реорганизации, разделения, объединения объекта. 17. Протоколирование действий пользователей. 18. Возможность прикрепления к карточке объекта учета произвольного количества файлов произвольного типа. 19. Возможность ведения внереестровых объектов - -

Подсистема «Ведение информации по субъектам права» (1) - Подсистема должна обеспечивать ведение информации по муниципальным предприятиям и учреждениям (как реестровым объектам), а также по субъектам права, участвующих в имущественно-земельных отношениях (юридические, физические лица, индивидуальные предприниматели). Подсистема должна автоматизировать выполнение следующих основных задач: 1. Пообъектный учет субъектов права. Для каждого из субъектов права ведется следующая основная информация: 1.1. Наименование субъекта права (полное и краткая информация, с историей изменения). 1.2. ИНН. 1.3. Принадлежность к реестру, подреестру (с историей изменения и ссылкой на документ-основание). 1.4. Реестровый номер (с историей изменения и ссылкой на документ-основание). 1.5. Адрес (с возможностью ввода множественного адреса), структура адреса должна соответствовать федеральным требованиям (ФИАС). Система должна обеспечивать возможность автоматизированного обновления классификаторов адресной подсистемы на основе ФИАС. 1.6. Организационная форма, вид деятельности, вид собственности (классификаторы). 1.7. Контакты - руководитель, главный бухгалтер, другие сотрудники (произвольное количество), телефоны (произвольное количество), банковские реквизиты (с историей изменения), реквизиты трудовых договоров руководителя и главного бухгалтера с возможность загрузки в систему самих договоров и дополнительных соглашений к ним, а также реквизитов документов о назначении и увольнении руководителей с возможностью загрузки в систему указанных документов. 1.8. Информация по членам семьи, родственным отношениям (для физических лиц). 1.9. Паспортные данные (для физических лиц, индивидуальных предпринимателей) – с историей изменения, дата рождения. 1.10. Субъекты права (представители, учредители) – с историей изменения и ссылками на документы-основания, возможностью расширения в части регистрации произвольного количество субъектов права произвольного типа (любого вида права, с возможностью расширения) - -

Подсистема «Ведение информации по субъектам права» (2) - 1.11. Экономические показатели (балансовая, остаточная стоимость объектов на балансе, среднесписочная численность сотрудников, показатели эффективности) – с историей изменения и ссылками на документы-основания. Должна быть обеспечена возможность учета произвольного количества экономических показателей любого типа с возможностью расширения средствами системы. Минимальный набор показателей эффективности: ? основные средства; ? финансовые вложения; ? отложенные налоговые активы; ? прочие внеоборотные активы; ? запасы; ? дебиторская задолженность; ? финансовые вложения (за исключением денежных эквивалентов); ? денежные средства и денежные эквиваленты; ? прочие оборотные активы; ? уставный капитал/фонд; ? добавочный капитал (без переоценки); ? резервный капитал; ? нераспределенная прибыль (непокрытый убыток); ? чистые активы; ? заемные средства; ? отложенные налоговые обязательства; ? оценочные обязательства; ? прочие обязательства; ? заемные средства; ? кредиторская задолженность; ? доходы будущих периодов; ? оценочные обязательства; ? прочие обязательства; ? выручка; ? себестоимость продаж; ? валовая прибыль (убыток); ? коммерческие расходы; ? управленческие расходы; ? прибыль (убыток) от продаж; ? доходы от участия в других организациях; ? проценты к получению; ? проценты к уплате; ? прочие доходы; ? прочие расходы; ? прибыль (убыток) до налогообложения; ? налог на прибыль; ? в том числе: ? текущий налог на прибыль; ? отложенный налог на прибыль; ? прочее; ? чистая прибыль (убыток). Программа должна предусматривать возможность загружать скан-образы бухгалтерской (финансовой) отчетности и планов (программ) финансово-хозяйственной деятельности. Также Программа должна предусматривать возможность ведения основных плановых и фактических показателей результатов финансово-хозяйственной деятельности. - -

Подсистема «Ведение информации по субъектам права» (3) - 1.12. Классификационные коды (ОКВЭД, ОКОНХ, ОГРН, КПП) – с ведением истории и ссылками на документы-основания, с возможностью расширения перечня учитываемых кодов без участия программистов. 1.13. Информация по документам (все документы, имеющие отношение к данному объекту с делением по направлениям воздействия документов (включение/исключение, внесение изменений, правоустанавливающие, регистрирующие документа)). Должна быть обеспечена возможность учета информации по произвольному количеству документов любого типа с возможностью расширения средствами системы. 1.14. Комиссии. 1.15. События (даты жизненного цикла объекта) с возможностью расширения количества и типов событий средствами системы. 1.16. Признаки (принадлежности к определенным учетным категориям, группам в соответствии с технологией учета) с возможностью расширений наименований признаков средствами системы. 1.17. Перечень объектов имущества на балансе и в пользовании. 1.18. Перечень земельных участков в землепользовании и в пользовании (аренда). 1.19. Перечень договоров всех типов для объектов имущества (аренда, купля/продажа, безвозмездное пользование, социальный найм). 1.20. Перечень договоров всех типов для земельных участков (аренда, купля/продажа, безвозмездное пользование). 1.21. Полная финансовая информация по всем видам договоров (начисления, платежи, задолженность). Для ГУП должна содержаться следующая информация: ? о долговых обязательствах с расшифровкой по каждому кредитору, а также с возможностью перехода к реестру договоров субъекта, в котором можно получить доступ к реквизитам заключенных договоров, существенными условиями по каждому договору, основному долгу и процентам; ? о крупных сделках, в том числе с возможностью перехода в карточку сделки, для просмотра реквизитов документа, которым она согласована и ее существенных условий. С возможностью загрузки в Систему документа, которым согласована сделка - -

Подсистема «Ведение информации по субъектам права» (4) - 1.22. Информация по банкротству. 1.23. Информация по претензионной и исковой деятельности (детальная информация по поданным претензиям и искам, включая необходимую классификационную и описательную части, предметы исков, в том числе суммы с делением по видам начислений, перечень этапов претензионной и исковой деятельности с указанием ссылок на документы этапа, уточнение требований) – см. Пункт «подсистема автоматизации претензионной и исковой деятельности». 2. Управление историей изменения основных данных по субъектам права, документами-основаниями на проведение изменений. 3. Управление движением субъектов права в реестре и списках учета (включение, исключение, перемещение между реестрами, ведение истории реорганизации объектов (слияния, разделения)), документами-основаниями, правоустанавливающими и другими документами. 4. Использование информации по субъектам права при формировании договоров, дополнительных соглашений, других документов, при формировании информации о других имущественно-земельных отношениях с участием соответствующих субъектов права. 5. Формирование аналитики по деятельности субъекта права в рамках имущественно-земельных отношений. 6. Формирование аналитики по задолженности, работа с должниками. 7. Возможность формирования аналитической отчетности в соответствующей сфере (с использованием встроенных средств генераторов отчетов). 8. Проведение экспресс-аналитики - -

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

Подсистема «Ведение информации по акциям» - В Системе должна быть возможность ведения информации об акциях (долях), находящихся в собственности муниципального образования. В рамках подсистемы помимо стандартных атрибутов должна быть предусмотрена возможность ведения следующей информации: 1. Субъекты акций (сведения об эмитенте, совете директоров, ревизионных комиссиях). 2. Субъекты долей (сведения об обществе, совете директоров, ревизионных комиссиях). 3. Заседания совета директоров и общего собрания акционеров (участников), включая возможность фиксации решения собрания, загрузки протоколов. 4. Информация о стоимостях акций (долей) и количестве акций (в разрезах видов акций). 5. Сведения о собраниях советов директоров и ревизионных комиссий (включая состав совета, протокол). 6. Бюджетный учет акций (долей) в казне. 7. Сведения об эмитенте (обществе) должны содержать информацию, указанную в пунктах 1.7 (в отношении генерального директора) и 1.11 в разделе 4.3 настоящего технического задания, а также возможность перехода в реестр договоров для получения информации о долговых обязательствах с расшифровкой по каждому кредитору, реквизитами заключенных договоров, существенными условиями по каждому договору, основному долгу и процентам. 8. Информацию о крупных сделках, в том числе с возможностью перехода в карточку сделки, для просмотра реквизитов документа, которым она согласована и ее существенных условий. С возможностью загрузки в Систему документа, которым согласована сделка - -

«Адресная подсистема» - «Адресная подсистема» (средства формирования адресов объектов для реестровой подсистемы учета) должна обеспечивать возможность формирования и учета произвольного количества адресов для каждого объекта учета. Для каждого из адресов должна быть предусмотрена возможность указания типа адреса на основе расширяемого классификатора (присвоенный адрес – официальный, юридический адрес, предыдущий адрес (при наличии) и адресного ориентира (местоположение объекта учета). Присвоенный адрес – официальный, должен быть один. «Адресная подсистема» должна обеспечивать возможность указания адресных реквизитов, утвержденных, постановлением Правительства РФ от 19.11.2014 № 1221 как с использованием собственных справочников и классификаторов присвоенных адресов или установленных ранее, включая адресный ориентир, так и с использованием базы федеральной информационной адресной системы (ФИАС). «Адресная подсистема» должна обеспечивать возможность настройки шаблона вывода адреса (формирования строки адреса) для каждого из типов объектов учета (наименований реестров объектов учета). Шаблон должен обеспечивать возможность указания адресных реквизитов в соответствии с требованиями к структуре адреса, например, , , , , или , , , и т.п. Строка адреса обязательно отображается в карточке объекта учета и в списке объектов учета соответствующего типа. «Адресная подсистема» должна обеспечивать возможность ввода адреса любых объектов учета, включая адреса комнат, офисов, территорий и т.д. Должна быть предусмотрена возможность указания адресного ориентира - -

«Адресная подсистема» (2) - «Адресная подсистема» должна обеспечивать возможность ввода адреса следующей структуры: 1. Наименование страны (Российская Федерация) – выбирается из справочника. 2. Наименование субъекта Российской Федерации – выбирается из справочника. 3. Наименование муниципального района, городского округа или внутригородской территории (для городов федерального значения) в составе субъекта Российской Федерации – выбирается из справочника. 4. Наименование городского или сельского поселения в составе муниципального района (для муниципального района) или внутригородского района городского округа – выбирается из справочника. 5. Наименование населенного пункта – выбирается из справочника. 6. Наименование элемента планировочной структуры – выбирается из справочника. 7. Наименование элемента улично-дорожной сети – выбирается из справочника присвоенных наименований элементам УДС. 8. Номер земельного участка. 9. Тип и номер здания, сооружения или объекта незавершенного строительства. 10. Тип и номер помещения, расположенного в здании или сооружении. Перечень элементов планировочной структуры (справочник), элементов улично-дорожной сети (справочник), элементов объектов адресации, типов зданий (сооружений) и помещений, используемых в качестве реквизитов адреса (справочники), а также правила сокращенного наименования адресообразующих элементов устанавливаются Министерством финансов Российской Федерации. Для зависимых справочников должна быть предусмотрена возможность автоматической подфильтровки допустимых для выбора элементов при заполнении элементов вышестоящих классификаторов, от которых зависят данные. Если значения вышестоящих классификаторов не заданы, то при выборе элемента некоторого зависимого справочника элементы вышестоящих справочников должны заполниться (выбраться автоматически) - -

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

Подсистема управления договорами и дополнительными соглашениями должна автоматизировать выполнение всех задач ведения соответствующих договорных отношений и претензий за фактическое использование объектов без заключения договорных отношений. Подсистема «Имущество» автоматизирует ведение договоров и других правовых отношений следующих типов: 1. Договор социального найма жилья (для объектов жилого фонда). 2. Договор специализированного найма жилья (для объектов жилого фонда). 3. Договоры на согласовании (при заключении договора балансодержателями имущества). 4. Договор аренды. 5. Договор купли/продажи/приватизации. 6. Договор выкупа с рассрочкой. 7. Договор безвозмездного пользования объектов движимого имущества. 8. Договор безвозмездного пользования недвижимого имущества, имущественных комплексов. 9. Договор мены. 10. Договор дарения. 11. Договор на установку и эксплуатацию рекламных конструкций. 12. Распорядительный документ по праву постоянного бессрочного пользования. 13. Разрешение на установку и эксплуатацию рекламных конструкций. 14. Договор на размещение информационных конструкций. 15. Решение о регистрации информационных конструкций. Подсистема «Земля» автоматизирует ведение договоров и других правовых отношений следующих типов: 1. Договор аренды. 2. Договор купли-продажи земельного участка, заключенный по итогам аукциона. 3. Договор купли-продажи земельного участка без торгов (в том числе с рассрочкой платежей). 4. Соглашение о перераспределении земельных участков. 5. Договор безвозмездного пользования. 6. Соглашение о сервитуте (публичном сервитуте). 7. Разрешения на использование земельного участка без его предоставления и установления сервитута. 8. Претензия за фактическое использование участка без заключения договора (расчеты в соответствии с требованиями Гражданского кодекса РФ) - Подсистема управления договорами и дополнительными соглашениями должна автоматизировать выполнение всех задач ведения соответствующих договорных отношений и претензий за фактическое использование объектов без заключения договорных отношений. Подсистема «Имущество» автоматизирует ведение договоров и других правовых отношений следующих типов: 1. Договор социального найма жилья (для объектов жилого фонда). 2. Договор специализированного найма жилья (для объектов жилого фонда). 3. Договоры на согласовании (при заключении договора балансодержателями имущества). 4. Договор аренды. 5. Договор купли/продажи/приватизации. 6. Договор выкупа с рассрочкой. 7. Договор безвозмездного пользования объектов движимого имущества. 8. Договор безвозмездного пользования недвижимого имущества, имущественных комплексов. 9. Договор мены. 10. Договор дарения. 11. Договор на установку и эксплуатацию рекламных конструкций. 12. Распорядительный документ по праву постоянного бессрочного пользования. 13. Разрешение на установку и эксплуатацию рекламных конструкций. 14. Договор на размещение информационных конструкций. 15. Решение о регистрации информационных конструкций. Подсистема «Земля» автоматизирует ведение договоров и других правовых отношений следующих типов: 1. Договор аренды. 2. Договор купли-продажи земельного участка, заключенный по итогам аукциона. 3. Договор купли-продажи земельного участка без торгов (в том числе с рассрочкой платежей). 4. Соглашение о перераспределении земельных участков. 5. Договор безвозмездного пользования. 6. Соглашение о сервитуте (публичном сервитуте). 7. Разрешения на использование земельного участка без его предоставления и установления сервитута. 8. Претензия за фактическое использование участка без заключения договора (расчеты в соответствии с требованиями Гражданского кодекса РФ) - -

Подсистема «Ведение договоров и дополнительных соглашений» (2) - Подсистема управления договорами и дополнительными соглашениями должна автоматизировать решение следующих основных задач: 1. Учет всех условий договоров и дополнительных соглашений. По каждому договору и доп. соглашению ведется следующая основная информация: 1.1. Номер и дата договора, доп. соглашения, номер и дата регистрации. 1.2. Код бюджетной классификации. 1.3. Тип использования, целевое использование. 1.4. Дата начала фактического использования объекта договора (для определения периода фактического использования). 1.5. Дата начала действия, планируемого и фактического окончания (расторжения), дата фактического освобождения объекта (для определения периода фактического использования объекта после расторжения договора). 1.6. Особые условия, ограничения. 1.7. Документы-основания, документы на льготы, другие документы. 1.8. Комиссии. 1.9. Объекты договора (может быть несколько объектов в договоре) – с возможностью указания периода нахождения объекта или его доли в договоре, доли объектов учета по договору – с историей изменения величины доли. 1.10. Формула (алгоритм) расчета планируемой платы по договору (индивидуально для каждого объекта или доли объекта в договоре) – с историей изменения. 1.11. Коэффициенты, ставки, индивидуальные показатели, другие характеристики, участвующие в автоматическом расчете планируемой арендной платы (индивидуально по каждому объекту в договоре) – с историей изменения. 1.12. Субъекты договора (с историей изменения, периодами действия для переуступки, субаренды, доверенности, ссылками на документы-основания). 1.13. Информация по субаренде с привязкой к объектам субаренды и характеристикам, коэффициентам, влияющим на расчет суммы планируемой арендной платы на субарендуемые площади (индивидуально для каждого субарендатора и субъекта субаренды) – с периодами действия. 1.14. Информация по планируемой плате по договору (с полной историей изменения) 1.15. Схема начисления в соответствии с условиями договора с историей изменения. - -

Подсистема «Ведение договоров и дополнительных соглашений» (3) - 1.16. Индивидуальные ставки пени – с историей изменения и ссылками на документы-основаниями, а также возможностью индивидуальной настройки количества знаков после запятой для расчетов пени, а также возможности начисления процентов вместо пени. 1.17. Индивидуальные ставки процентов за пользование чужими денежными средствами – с историей изменения и ссылками на документы-основаниями, а также возможностью индивидуальной настройки количества знаков после запятой для расчетов процентов, а также возможности начисления пени вместо процентов. 2. Управление дополнительными соглашениями, изменениями условий договора по дополнительным соглашениям. 3. Управление договорами с множественностью лиц. 4. Управление договорами с множественностью объектов. 5. Переоформление, продление договоров. 6. Автоматизация процесса переуступки права по договору. 7. Переоформление договоров аренды земельных участков при разграничении собственности на объекты аренды. 8. Автоматизированный расчет суммы планируемой платы, платы за выкуп с учетом всех особых условий договора. 9. Автоматизация расчета суммы планируемой платы по договору с учетом истории изменения расчетных величин, изменения условий договора по доп. соглашениям, учета различных особых условий (в том числе различные виды льгот, субаренда, долевая аренда/выкуп, аренда/выкуп с разными типами использования объектов договора, автоматическим поднятием до установленных минимумов). 10. Автоматизация подготовки необходимых печатных форм (в том числе текстов договора, доп. Соглашения, проектов постановлений, распоряжений, приказов). 11. Формирование аналитики по задолженности, работа с должниками. 12. Автоматизация претензионной и исковой деятельности. 13. Формирование аналитической отчетности в соответствующей сфере. - -

Подсистема «Ведение договоров и дополнительных соглашений» (4) - 14. Проведение экспресс-аналитики и др. Проведение начислений арендной платы по договорам, платы за выкуп, пени и других штрафов, учет платежей, расчет задолженности в необходимых разрезах производится финансово-аналитической подсистемой - -

Ведение договоров и дополнительных соглашений специализированного жилищного фонда - К жилым помещениям специализированного жилищного фонда относятся следующие виды жилых помещений, находящиеся в муниципальной собственности: 1. Служебные жилые помещения. 2. Жилые помещения в общежитиях. 3. Жилые помещения маневренного фонда. 4. Жилые помещения в домах системы социального обслуживания населения. 5. Жилые помещения для социальной защиты отдельных категорий граждан. 6. Жилые помещения для детей-сирот и детей, оставшихся без попечения родителей, лиц из числа детей сирот и детей, оставшихся без попечения родителей. В рамках управления специализированным жилищным фондом должна быть обеспечена возможность ведения следующих типов договоров: 1. Договор найма служебного жилого помещения. 2. Договор найма жилого помещения маневренного фонда. 3. Договор найма жилого помещения для детей сирот и детей, оставшихся без попечения родителей, лиц из числа детей сирот и детей, оставшихся без попечения родителей далее (дети-сироты). 4. Договор найма жилого помещения в домах системы социального обслуживания населения. 5. Договор найма жилого помещения для социальной защиты отдельных категорий граждан. 6. Договор найма жилого помещения жилищного фонда для коммерческого использования с условием последующего выкупа жилого помещения - -

Индивидуальные ставки пени и процентов (1) - Индивидуальные ставки пени и процеВ Системе должна быть предусмотрена возможность ведения индивидуальных ставок пени для каждого договора с указанием периода действия индивидуальной ставки, а также документа-основания. Средства настройки индивидуальной ставки пени должны предусматривать возможность дополнительной настройки следующих параметров: 1. Возможность указания конкретной величины ставки (в процентах или абсолютных единицах) или указание на ставку со значениями, задаваемыми справочником (например, ставка рефинансирования, ключевая ставка, среднебанковская ставка для вкладов физических лиц). 2. Доля ставки (знаменатель при указании ставки в виде простой дроби). 3. Количество знаков после запятой при расчете величины ставки в абсолютных единицах (по умолчанию – максимально возможное). 4. Признак необходимости расчета пени по методике равного количества дней в месяце (30 дней в месяце, 360 дней в году). 5. Признак необходимости расчета процентов за пользование чужими денежными средствами вместо пени. 6. Признак «плавающей» ставки пени в периоде расчета («Плавающая» или фиксированная на день исполнения денежных обязательств или их части). В периоде действия индивидуальных ставок пени расчет пени по договору производится по общей методике, в противном случае – по технологии, определенной по умолчанию для данного вида договора и/или схеме начисления. Аналогично должна быть реализована возможность для ведения индивидуальных ставок процентов за пользование чужими денежными средствами. По умолчанию должна применяться методика, соответствующая 395 статье Гражданского кодекса РФ (с учетом всех редакций данной статьи, распространяющих действия до следующего внесения изменений в статью) - -

Индивидуальные ставки пени и процентов (2) - Средства настройки индивидуальной ставки процентов должны предусматривать возможность дополнительной настройки следующих параметров: 1. Возможность указания конкретной величины ставки (в процентах или абсолютных единицах) или указание на ставку со значениями, задаваемыми справочником (например, ставка рефинансирования, ключевая ставка, среднебанковская ставка для вкладов физических лиц); 2. Доля ставки (знаменатель при указании ставки в виде простой дроби); 3. Количество знаков после запятой при расчете величины ставки в абсолютных единицах (по умолчанию – максимально возможное). 4. Признак необходимости расчета пени по методике равного количества дней в месяце (30 дней в месяце, 360 дней в году). 5. Признак необходимости расчета пени вместо процентов за пользование чужими денежными средствами. 6. Признак «плавающей» ставки процентов в периоде расчета («Плавающая» или фиксированная на день исполнения денежных обязательств или их части). В периоде действия индивидуальных ставок пени расчет пени по договору производится по общей методике, в противном случае – по технологии, определенной по умолчанию для данного вида договора и/или схеме начисления. нтов - -

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

Подсистема «Выкуп с рассрочкой» (2) - 3.3. Ставку рефинансирования и график начисления платежей должна иметься возможность учитывать с даты начала договора, даты подписания договора, даты публикации договора, даты договора, с указанием конкретной даты вручную. 3.4. Начисление процентов производить на первоначальный взнос или не производить. 3.5. Платеж в первую очередь должен погашать пеню, потом процент, потом основной долг (либо в первую очередь на процент, а оставшуюся сумма платежа – на основной долг) - -

«Финансово-аналитическая подсистема» (1) - «Финансово-аналитическая подсистема» является ключевой с точки зрения определения и повышения эффективности неналоговых поступлений от использования муниципальной собственности. Подсистема должна обеспечивать широкие возможности точной настройки на все нюансы федерального, регионального и местного законодательства, особенностей технологии управления имущественно-земельным комплексом, принятым в соответствующих органах управления собственностью и земельными ресурсами региона и государственных образований на территории региона. «Финансово-аналитическая подсистема» должна обеспечивать автоматизацию выполнения следующих основных задач: 1. Управление финансово-аналитической информацией (начислениями всех типов, платежами, задолженностью) в разрезах договоров, кодов бюджетной классификации (аналитических уровней), видов договоров, субъектов. 2. Автоматическое формирование начислений по договору возмездного и безвозмездного пользования, платы за фактическое использование, льготной арендной платы, платы за выкуп. Система автоматически должна определять, какой из видов начисления необходимо произвести в соответствии с условиями договорных соглашений (с учетом всех доп. соглашений и других корректировок), норм Гражданского Кодекса, в тех периодах использования объектов, которые не регулируются договором (в том числе фактическое использование объектов без договора, до заключения договора, в периоде до регистрации договора, после расторжения договора до даты освобождения объекта). 3. Автоматическое начисление пени, процентов, других штрафных санкций за пользование чужими денежными средствами. Система автоматически должна определять вид начисления (штрафных санкций) исходя из условий договора или руководствуясь нормами гражданского Кодекса в периоде фактического использования объекта. 4. Автоматическое доначисление по доп. соглашениям, изменяющим условия договора «задним числом». 5. Автоматический расчет сальдо - -

«Финансово-аналитическая подсистема» (2) - 6. Автоматический перерасчет планируемой платы по договору (например, в ходе массовой индексации по уровню инфляции). 7. Импорт платежей из электронных источников (выгрузка из СУФД и др.). 8. Автоматическое, полуавтоматическое и ручное распределение и перераспределение поступлений по субъектам договоров, договорам, видам начислений. 9. Формирование информации о задолженности в любом разрезе и на произвольную дату. 10. Формирование информации о динамике возникновения задолженности. 11. Управление начислениями по решению суда, автоматизация работы с реструктуризацией задолженности. 12. Ведение протоколов выполнения автоматических операций, возможности по эвристическому анализу информационного фонда на предмет корректности исходной информации для выполнения автоматических операций. 13. Автоматизация работы с должниками. 14. Формирование необходимых печатных форм (в том числе справки о наличии/отсутствии задолженности, формирование претензий, исковых требований, детализации всех видов начислений для суда, формирование актов сверки). 15. Формирование необходимой аналитической отчетности - -

«Финансово-аналитическая подсистема» (3) - 16. Организация массовой рассылки уведомлений о необходимости погашения задолженности, об изменении условий договора, величины планируемой платы по договору. 17. Проведение экспресс-аналитики. Помимо стандартных функций по управлению финансово-аналитической информацией, в подсистему должен быть включен ряд функций и возможностей, направленных на дополнительное расширение возможностей подсистемы как в части расширения функционала, так и в части настройки технологии учета под особенности внутреннего регламента по управлению финансово-аналитической информацией, технологии учета, особенности местного и регионального законодательства - -

Настройка уровня аналитического учета (1) - В Системе должна быть предусмотрена возможность индивидуальной настройки уровня аналитического учета платежей и начислений за аренду этих объектов. 1. Учет платежей и начислений должен вестись как в разрезе субъектов договоров (арендаторы), плательщиков (оплата 3-ми лицами), так и по договорам (аренда, выкуп, неосновательное обогащение, учет и т.д.). Платежи распределяются как по субъектам договоров (арендаторы), так и по договорам (аренда, выкуп, неосновательное обогащение, учет и т.д.). Пени и другие штрафные санкции и сальдо рассчитываются также в разрезе субъектов и по договорам аренды. Возможно применение смешанной технологии учета, в которой основная технология выбрана в разрезе субъектов договоров (арендаторы), но для части договоров учет ведется в разрезе договоров. 2. Возможно ведение технологии учета в разрезе КБК (кодов бюджетной классификации). При таком ведении учета пени и сальдо рассчитываются индивидуально для каждого кода бюджетной классификации. Данный аналитический уровень может быть применен как при ведении учета в разрезе арендаторов, так и при ведении учета в разрезе договоров. 3. Ведение библиотеки алгоритмов выполнения автоматических операций. 4. Ведение библиотеки схем начисления арендной платы и сроков оплаты - -

Настройка уровня аналитического учета (2) - 5. Библиотека схем начисления должна предоставлять следующие возможности: 6. Создание произвольного количества схем начисления. Под схемой начисления подразумевается алгоритм выполнения начисления, периодичностью (квартал, месяц, полугодие, набор месяцев) и сроки начисления. 7. Возможность создания и настройки произвольного количества периодичностей начисления (например, помесячное начисление, поквартальное, 2 раза в год для сельхоз. земель, 2 раза в год для других земель). При этом для каждой периодичности может быть указано произвольное количество периодов произвольной длительности. Для каждого периода индивидуальное указание произвольного срока оплаты. 8. Для каждого договора аренды указание индивидуальной схемы начисления из библиотеки (схема по умолчанию также должна настраиваться) - -

Расширение функциональных и аналитических возможностей блока (1) - В Системе должна быть реализована функция определения задолженности в любом разрезе. При этом функция должна рассчитать задолженность по состоянию на любую заданную дату как по базе целиком, так и по любому из перечисленных аналитических уровней (или их произвольному сочетанию): 1. Вычисление задолженности по договорам определенного типа (аренда, купля/продажа земельных участков, недвижимого, движимого имущества, объектов наружной рекламы, имущественных комплексов) или по всем типам. 2. Вычисление общей задолженности по субъекту договора или по всем субъектам. 3. Вычисление задолженности по договору или всем договорам. 4. Вычисление общей задолженности по определенному виду начисления или по всем видам. 5. Вычисление общей задолженности по определенному КБК или по всем КБК 6. В Системе должны быть предусмотрены следующие возможности: 7. Возможность запуска операции автоматического начисления арендной платы по диапазону периодов, годов. 8. Протоколирование выполнения всех автоматических операций и эвристический анализ состояния информационного фонда на поиск ошибок и потенциальных ошибок. 9. Выполнение любой автоматической операции должно сопровождаться формированием подробного протокола выполнения операции, в который в текстовом, понятном пользователю виде заносятся все операции, которые были произведены системой со всеми объектами учета. - -

Расширение функциональных и аналитических возможностей блока (2) - Одновременно, система должна выполнять комплекс эвристических проверок состояния информационного фонда системы на поиск ошибок или потенциальных ошибок, которые потенциально могут повлиять на корректность полученного результата. 10. Протоколы выполнения всех автоматических операций должны хранится в базе на постоянной основе и быть доступны для анализа в любой момент времени (возможность постанализа результатов выполнения операции). 11. Автоматический расчет и отображение «горячих итогов» (автовычисляемая и отображаемая на экране задолженность по заданным видам начисления (настраивается) по состоянию на текущую дату) по каждому субъекту (всем договорам субъекта общей суммой) и/или договору. В автоматическом режиме Система должна рассчитывать и отображать следующие данные: 1. Задолженность по арендной плате/плате за выкуп по состоянию на текущее число. 2. Задолженность по пене по состоянию на текущее число. 3. Общая задолженность (по всем видам начисления) по состоянию на текущее число. 4. Текущая пеня (сумма пени, рассчитанная на текущий момент). 5. Всего начислено с начала года. 6. Текущая сумма планируемой арендной платы/платы за выкуп. Поля «горячих» итогов должны поддерживать настройку на отображение итогов по любому виду начисления (глобальная настройка по Системе целиком). Должна быть предусмотрена возможность настройки не менее 10 показателей «горячих итогов» - -

Подсистема «Автоматизация претензионной и исковой деятельности» (1) - Подсистема должна автоматизировать выполнение следующих основных задач: 1. Ведение полной информации по претензиям и исковым процессам, по требованиям, предъявленным к пользователям Системы и по имуществу пользователям Системы: 1.1. Договор или иной документ, на основании которого ведется претензионно-исковая деятельность. 1.2. Претензия, иск стороны для требований, предъявленных к пользователям Системы по имуществу. 1.3. Субъект (заявитель) претензии. 1.4. Объект. 1.5. Предмет претензионно-исковых требований: 1.6. требования имущественного характера (сумма к взысканию по различным видам начислений); 1.7. требований имущественного характера, не подлежащего оценке; 1.8. требования неимущественного характера. 2. Возможность формировать печатные формы претензий и исковых заявлений автоматически на основе данных из учетной системы. 3. Стороны (участники) иска, категория (вид) иска, признак особой важности. 4. Состояние иска (подготовка, в процессе, завершен). 5. Учет судебных дел и претензионно-исковых этапов: претензия, подготовка иска, подача иска, наименование суда, номер судебного дела, судья, инстанция (апелляция, кассация, в порядке надзора), дата и время судебного заседания, сотрудник правового отдела – исполнитель, судебные акты по делу (решения, определения о приостановлении производства по делу, об оставлении иска без рассмотрения, об оставлении иска без движения, о возвращении искового заявления, о прекращении производства по делу, о принятии к производству встречного иска, о принятии (отмене) мер по обеспечению иска) - -

Подсистема «Автоматизация претензионной и исковой деятельности» (2) - 6. Учет исполнительного производства: дата вступления судебного акта в законную силу, дата получения исполнительного листа, дата направления исполнительного листа в отдел судебных приставов, отдел судебных приставов, судебный пристав исполнитель, постановления пристава исполнителя. 7. Учет конкурсного производства: суд, номер дела, дата введения процедур в отношении предприятия банкрота (определения суда), сведения о ходе процедур банкротства. 8. Возможность формирования отчета о сроках (длительности) претензионной работы, подготовки и подачи иска, рассмотрения дела в суде, исполнительного производства, конкурсного производства. 9. Возможность поиска судебных дел по различным критериям. 10. Наличие ссылки на страницу дела на сайте kad.arbitr.ru. 11. Возможность прикрепления файлов материалов к судебному делу (претензий, исков, судебных актов), к исполнительному производству (исполнительный лист, заявление о направлении исполнительного листа, постановления приставов-исполнителей), к конкурсному производству (судебные акты дела о банкротстве, извещения о проведении собраний кредиторов). 12. Формирование отчетов: о претензионной и исковой деятельности организации (количестве претензий, исков, судебных дел по различным критериям и заданным периодам), о сумме предъявленных и взысканных средствах в заданные периоды, в отношении различных субъектов и объектов; о количестве исполнительных и конкурсных производств по субъектам и объектам, суммам взысканных средств, заданным периодам. 13. Возможность сотруднику самостоятельно конструировать отчет, добавлять новые поля к карточкам судебных дел - -

Подсистема «Автоматизация претензионной и исковой деятельности» (3) - 14. Контроль за ходом иска в разрезе исполнителя, уведомление исполнителя о необходимости завершения текущего искового этапа и перехода к следующему. 15. Формирование графика судебных дел на каждого исполнителя и на правовой отдел в целом (ежедневник, еженедельник, ежемесячник) с возможностью размещения дополнительных сведений в графике о планируемой работе сотрудника. 16. Предусмотреть экспорт данных в табличный формат (xlsx, csv). Возможность формирования необходимых печатных форм (с использованием встроенных генераторов отчетов). 17. Предусмотреть разграничение прав доступа. 18. Постановка и контроль исполнения задач/поручений сотрудниками правового отдела. 19. Формирование статистики выигранных/проигранных судебных дел, отслеживание текущей загрузки сотрудников, анализ эффективности претензионной и исковой деятельности. 20. Протоколирование результатов расчета пени на расчетную дату. 21. Протоколирование результатов расчета задолженности по всем видам операций на расчетную дату, для возможности отслеживания изменений и анализа их причин - -

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

Аналитическая и сервисная подсистема «Библиотека запросов» (2) - 1. Группировка данных по одному или нескольким полям, что в значительной степени может повысить информативность полученных данных. Например, данные по должникам можно сгруппировать по району плательщика, кодам бюджетной классификации и видам начислений. 2. Вычисление общих итогов, в том числе для каждой из групп (в случае применения группировки). Например, для приведенного примера возможна автоматическая калькуляция общей задолженности арендаторов, а также задолженности по каждому из районов, коду бюджетной классификации и виду начисления. 3. Дополнительная оперативная фильтрация данных по значениям любого поля\совокупности полей. 4. Сортировка данных по произвольному полю\совокупности полей. Должна быть предусмотрена возможность экспорта сформированных данных в табличные форматы (xlsx, csv), текстового файла, xml или внутренние форматы генератора отчетов. При этом должна быть обеспечена возможность экспорта данных, в том чисел в формат xml сложной структуры с учетом всех сортировок, группировок, итогов и прочего форматирования, которые были наложены на результат запроса в окне результата запроса. В случае содержания в результатах запроса сведений об объектах учета единого банка данных Системы должен быть реализован быстрый доступ (двойной «щелчок мыши») к карточкам соответствующих объектов учета. Средства подсистемы должны предоставлять возможность администратору Системы мониторинга состояния информационного фонда Системы, анализа целостности, непротиворечивости данных, регулярного обслуживания банка данных. Средства подсистемы должны предоставлять возможность не только для проведения оперативных выборок, но и для выполнения запросов по индивидуальному или массовому изменению, добавлению, удалению информации в банке данных системы, например, в ходе обслуживания информационного фонда - -

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

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

Подсистема «Обеспечение безопасности, администрирования и разграничения прав доступа» (1) - Подсистема должна: 1. Обеспечивать возможности индивидуальной настройки для каждого пользователя базовых ограничений прав и разрешений с возможностью дальнейшего расширения. 2. Возможности индивидуального ограничения просмотра реестра объектов любого из типов. 3. Возможности индивидуального ограничения просмотра данных карточек объектов учета любых типов. Предоставление прав на частичный просмотр информации по объекту (например, запрет на просмотр экономических показателей объекта, но разрешение на просмотр технических показателей). 4. Возможности ограничения доступа к персональным данным, требующим отдельной защиты. 5. Возможности индивидуального ограничения изменения данных по объектам учета всех типов. Предоставление прав на частичное изменение информации. 6. «Горизонтальное» ограничение прав на изменение множественных атрибутов объектов учета (например, пользователю предоставляются права на изменение/внесение в карточку объектов документов определенной направленности и закрываются права на правку документов иной направленности (например, реестровых документов)). 7. Ограничение прав на выполнение различных операций с объектом учета (выделение подобъектов, включение в группу). 8. Ограничение на операции с печатными формами (просмотр и печать отчетов и печатных форм, экспорт во внешние форматы (docx, xlsx), редактирование сформированных отчетов). Для печатных форм права должны назначаться индивидуально для каждого типа объектов учета, для аналитических отчетов – индивидуально для каждой темы отчета. 9. Ограничение прав на работу с блоками начислений и платежей за аренду недвижимости и ЗУ (индивидуально на все функции, выполнение операций в каждом из режимов (индивидуальном, массовом)) - -

Подсистема «Обеспечение безопасности, администрирования и разграничения прав доступа» (2) - 10. Ограничение прав на работу с универсальной библиотекой запросов – права предоставляются индивидуально для каждой темы запросов и на выполнение операций блока запросов (выполнение запроса, экспорт результатов). 11. Ограничение прав на работу с НСИ (права предоставляются индивидуально для каждого справочника или классификатора). 12. Ограничение права на настройки системы (индивидуально на каждый блок настроек). Все права и разрешения на работу с объектами учета всех типов должны предоставляться индивидуально для каждой стадии формирования объекта учета (заявка, новый, актуальный (реестровый), актуальный зарегистрированный (в Росреестре), архивный, справочный, внереестровый или объект налогового потенциала). В Системе должны присутствовать средства объединения пользователей в группы (причем, каждый пользователь может быть включен в одну и иное количество групп) с автоматическим наследованием всех прав и разрешений групп, в которые включен пользователь. В Системе должны быть реализованы особые механизмы хранения и проверки паролей, обеспечивающие повышенную безопасность. При установке и смене пароля, новый пароль кодируется необратимыми алгоритмами (без возможности восстановления исходного пароля) - -

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

Подсистема «Ведение нормативно-справочной информации» - Подсистема должна обеспечивает функционирование необходимого для эффективной работы Системы набора справочников и классификаторов. Помимо федеральных справочников и классификаторов, а также справочников и классификаторов, формируемых в процессе поставки Системы, в состав Системы должен быть включен ряд дополнительных справочников, направленных на: 1. Повышение аналитических возможностей Системы. 2. Повышение возможностей Системы по расширению перечня учитываемых показателей. 3. Повышения адаптивности Системы к изменению законодательства, технологии учета, обеспечения быстрой настройки Системы под все нюансы работы органов управления имущественно-земельным комплексом. В Системе должна быть возможность доступа к справочникам и классификаторам непосредственно в ходе редактирования параметра с выбором из справочника с целью выполнения расширенного поиска, а по необходимости и внесения изменений в классификатор. Должна быть реализована возможность «привязки» как самих классификаторов, так и элементов классификации к видам реестров. Классификаторы и элементы классификации должно быть возможно выбрать только в тех реестрах, в которых это разрешено настройками Системы - -

Подсистема «Автоматическое обновление клиентских рабочих мест» (1) - Подсистема «Автоматическое обновление клиентских рабочих мест» (далее – Подсистема автообновления) предназначена для облегчения работы по обслуживанию клиентских рабочих мест Системы или компонентов, библиотек, включая общесистемные компоненты и библиотеки, необходимые для функционирования клиентского рабочего места. Подсистема автообновления предназначена для автоматического обновления файлов клиентских мест Системы или других компонентов, необходимых для функционирования. Система автообновления должна быть построена по клиент-серверной архитектуре, обновления должны распространятся по сети с использованием протокола TCP/IP. Подсистема автообновления должна состоять из следующих компонентов (программ): 1. «Служба обновления» – серверная часть подсистемы автообновления, устанавливаемая на компьютере – сервере. 2. «Конфигуратор службы обновления» – утилита по настройке службы обновления. 3. «Клиент обновления» – клиентская часть подсистемы автообновления, устанавливаемая на компьютере пользователя - -

Подсистема «Автоматическое обновление клиентских рабочих мест» (2) - Подсистема автообновления должна обладать следующим функционалом: 1. Автоматическое обновление клиентов обновлений на компьютерах пользователей при установке новой версии системы обновлений. Служба должна предоставлять клиентским местам Системы актуальную версию клиента обновлений. Для каждой новой версии клиента обновлений должен генерироваться уникальный идентификатор обновления. 2. Автоматическое обновление клиентских мест Системы на компьютерах пользователей при наличии обновлений программы. Служба должна предоставлять клиентским местам Системы актуальные версии файлов программы. Для каждой новой версии программы должен генерироваться уникальный идентификатор обновления. 3. Автоматическое восстановление отсутствующих файлов клиентских мест Системы на компьютерах пользователей. 4. При обновлении клиентских мест должна поддерживаться работа со списком исключений для удаления с клиентских мест устаревших файлов и папок. 5. Возможность обновления клиентских мест Системы из нескольких источников. Количество источников не должно быть ограничено. Для каждого источника должна быть предусмотрена возможность задать имя, путь к папке с файлами обновлений, а также путь к файлу со списком исключений. 6. Возможность сжатия пересылаемых по сети пакетов для уменьшения нагрузки на сеть. Активация данного функционала должна происходить по решению администратора. 7. Возможность контроля целостности пересылаемых по сети пакетов для предотвращения модификации пересылаемых файлов сторонним ПО, вирусами и иными внешними факторами. Файлы должны приходить на компьютеры пользователей в неизменном виде - -

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

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

Клиент обновлений (1) - Клиентская часть подсистемы автообновления должна быть представлена в виде отдельной программы – клиента обновления. Клиент обновления должен быть предназначен для соединения со службой обновления, расположенной на другом или текущем компьютере, и получения от неё актуальной версии файлов обновляемой программы, а также актуальной версии самого клиента обновления. Клиент обновления не должен требовать специальной установки и может быть запущен из любого места. Клиент обновления должен обладать возможностью запуска в двух режимах: 1. «Режим настройки» - в этом режиме должно открываться окно настройки клиента обновления. 2. «Режим обновления» - в этом режиме программа должна выполнять соединение с сервером обновлений, согласно выполненной настройке, и получать от сервера обновлений актуальные версии файлов обновляемой программы и самого клиента. Клиент обновления в «режиме настройки» должен предоставлять возможность задавать следующие настройки: 1. Настройки подключения к службе обновлений (IP-адрес или имя компьютера, на котором установлена служба обновлений, порт служба обновлений). Для проверки корректности настройки должна быть предусмотрена кнопка для тестирования соединения. 2. В случае необходимости подключения к серверу через прокси-сервер, должна быть возможность в соответствующей группе настроек указать IP-адрес прокси-сервера, порт подключения к прокси-серверу, а также логин и пароль для авторизации на прокси-сервере (при необходимости). 3. Источник обновления. Выбор источника обновлений должен осуществляться из выпадающего списка, а котором должны присутствовать все доступные источники обновлений. 4. Путь к временной папке, в которую будут загружаться обновления перед их применением. 5. Путь к папке, в которую необходимо сохранить загруженные обновления. 6. Путь к файлу программы, которую необходимо запустить после обновления. Должна присутствовать возможность настроить запрет запуска нескольких экземпляров - -

Клиент обновлений (2) - 7. Индивидуальная для клиентского места настройка сжатия пакетов, передаваемых по сети. 8. Индивидуальная для клиентского места настройка контроля целостности пакетов, передаваемых по сети. 9. Настройка протоколирования процесса обновления. Если ip-адрес и имя сервера обновления неизвестны, то должна быть реализована возможность автоматического поиска сервера в локальной сети. Для автоматического поиска сервера должна присутствовать кнопка «Поиск сервера». После успешного поиска, настройки подключения должны быть установлены автоматически, и пользователю должно быть показано соответствующее уведомление. Клиент обновления в «режиме обновления» должен осуществлять следующие действия: 1. Проверять наличие новой версии клиента обновления. Для этого клиент обновления должен получить текущий идентификатор обновления клиента и сравнить с ранее сохраненным идентификатором. Если идентификаторы различаются, то клиент обновления должен произвести самообновление с сохранением текущего идентификатора обновления. 2. Проверить наличие обновлений клиентского места Системы. Для этого клиент обновления должен получить текущий идентификатор обновления клиентского места и сравнить с ранее сохраненным идентификатором. Если идентификаторы различаются, то клиент обновления должен произвести загрузку измененных и новых файлов с сохранением текущего идентификатора обновления. При загрузке обновлений должны загружаться только новые и изменение файлы (сверяться контрольные суммы файлов (CRC)) - -

Клиент обновлений (3) - 3. При отсутствии обновлений клиентского места Системы клиент обновления должен проверить наличие отсутствующих файлов клиентского места Системы и при необходимости восстановить их. 4. По завершению работы клиент обновления должен произвести обработку файла исключений. Для этого клиент обновления должен получить содержимое файла исключений и удалить файлы и папки, согласно полученного списка. Процесс обновления должен отображаться в виде окна, на котором должны быть размещены следующие элементы: 1. Текст сообщения с описанием текущего этапа обновления. 2. Индикатор прогресса обновления. Клиент обновления должен поддерживать возможность протоколирования процесса обновления в текстовом файле, который должен автоматически создаваться в папке клиента обновления - -

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

Подсистема «Оповещение пользователей» (2) - 2. Автоматически завершить работу всех подключенных клиентских приложений по истечении заданного времени. 3. Формировать простые текстовые сообщения подключенным пользователям Системы. 4. Формировать текстовые сообщения всем пользователям Системы (не подключенные на момент формирования сообщения пользователи получат сообщение в момент следующего подключения). Пользователь должен получить сообщение только один раз вне зависимости от компьютера, на котором запущено клиентское приложение (в отличие от сообщений об автоматическом отключении клиентских приложений, простые текстовые сообщения должны отправляться не каждому клиентскому приложению, а пользователю, который был указан при подключении к клиентскому приложению. 5. Отзыв направленного ранее сообщения об отключении клиентских приложений. Автоматическое отключение клиентских приложений должно быть отменено, сообщение об отключении и таймер обратного отсчета на всех клиентских приложениях должны быть закрыты, должна быть возобновлена возможность подключения клиентских приложений. 6. Ведение журнала всех отправленных сообщений. 7. Ведение журнала получения сообщений пользователями - -

Типы оповещений пользователей - Для оповещения должна быть предоставлена возможность выбора типа оповещения. Должна быть реализована возможность выбора следующих типов: 1. Оповещение о начале технических работ на сервере, о необходимости выхода из Системы и автоматического отключения клиента. 2. Простое оповещение только подключенным пользователям, автоматического отключения не происходит. 3. Оповещение всем пользователям, подключенным и не подключённым, неподключенные должны получить оповещение при первом входе в Систему - -

Журнал оповещений - Должен вестись журнал оповещений, обладающих следующими характеристиками: 1. Для каждого оповещения сохраняется информация с указанием их типа, текста сообщения, даты и времени отправки сообщения, пользователя, сформировавшего сообщения. 2. Журнал оповещений должен обладать средствами поиска сообщений по всем параметрам журнала. Реализованы фильтры по диапазону дат, пользователю, группе пользователей, текстовый поиск. 3. Невозможно удалить произвольное оповещение. 4. Удалить записи журнала о старых оповещениях можно только до указанной даты. Права на удаление записей имеет только администратор. Ведется дополнительный лог по пользователям, прочитавшим оповещение. Просмотр лога так же доступен в интерфейсе просмотра журнала - -

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

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

Требования по ведению атрибутов объектов учета - Объект учета в обязательном порядке должен содержать следующую информацию: 1. Идентификатор – числовое значение, однозначно идентифицирующее объект учета (не должно существовать любого другого объекта учета, имеющего такой же идентификатор). Идентификатор должен присваиваться Системе автоматически при создании нового объекта. 2. Наименование (описание) объекта – строковое значение, описывающее объект, заполняется вручную, не является обязательным. Объект учета может иметь произвольное количество атрибутов (характеристик). Каждый атрибут должен содержать: 1. Наименование (идентификатор) атрибута – выбирается из соответствующих справочников наименований атрибутов каждого из типов данных. Должен быть предусмотрен инструмент формирования допустимого перечня атрибутов, который может быть указан (выбран) в карточке каждого из типов объектов учета (инструмент индивидуального формирования перечня атрибутов для каждого типа объектов учета). 2. Значение – указывается в зависимости от типа данных атрибута. 3. Период действия – дата начала периода действия атрибута и дата окончания периода действия атрибута. Индивидуально для каждого вида (наименования) атрибута должна быть предусмотрена возможность настройки допустимости пересечения периодов действия значений этого атрибута (множественный ввод значений одноименных атрибутов в один момент времени). 4. Перечень ссылок на документы-основания начала действия значения атрибута – перечень ссылок на информацию о документах с обязательным указанием основного документа-основания. 5. Перечень ссылок на документы-основания окончания действия значения атрибута – перечень ссылок на информацию о документах с обязательным указанием основного документа-основания. Индивидуально для каждого вида (наименования) атрибута должна быть предусмотрена возможность настройки использования документов-оснований окончания действия (используется или нет) - -

Требования по ведению атрибутов объектов учета (2) - 6. Примечание – текстовое поле. Система должна обеспечивать возможность создания и ведения атрибутов объектов учета следующих типов данных: 1. Числовой тип (коэффициент). Должна быть предусмотрена возможность установки фиксированного значения величины коэффициента для каждого наименования коэффициента (наименования атрибута соответствующего типа) без возможности индивидуального изменения в карточке объекта учета (константа) или с возможностью индивидуального изменения (в этом случае значение, связанное с наименованием коэффициента, должно устанавливаться как значение по умолчанию с возможностью последующей корректировки индивидуально в карточке конкретного объекта). Такая настройка должна быть предусмотрена индивидуально для каждого вида (наименования) коэффициента. 2. Денежный тип (экономический показатель). 3. Строковый тип (технический, описательный показатель). Для каждого наименования атрибута данного типа должна быть предусмотрена возможность установки маски ввода значения атрибута. 4. Классификационный тип – справочник. Для каждого наименования атрибута (категории классификационных данных) должна быть предусмотрена возможность индивидуальной настройки перечня (справочника) элементов классификатора данной категории. 5. Булевый тип – признак (да/нет). Допустимо отсутствие ведения информации по периоду действия и документам-основаниям. 6. Тип даты – событие. 7. Ссылка на субъект права – с указанием типа субъекта права. 8. Кроме того, в карточку объекта учета дополнительно могут быть загружены: 8.1. Информация по адресу объекта с использованием адресной подсистемы - -

Требования по ведению атрибутов объектов учета (3) - 8.2. Произвольное количество файлов любого типа. Файлы могут загружаться как по одному, так и массово путем выделения нескольких файлов в средстве работы с файлами операционной системы (проводнике, менеджере файлов). Должна быть предусмотрена возможность загрузки в карточку объектов файлов путем использования технологии Drag-And-Drop (перетащи и отпусти). Открытие файлов должно производиться непосредственно из Системы путем использования средств операционной системы, назначенных по умолчанию (аналогично открытию файлов проводником или другим менеджером файлов). Хранение прикрепленных файлов объекта учета должно производиться на сервере в базе данных или с использованием других средств, обеспечивающих надежность и скорость работы с файлами не хуже соответствующих инструментов СУБД (транзакционный механизм доступа с возможностью автоматического отката транзакций, завершившихся аварийно, резервное копирование). 8.3. Произвольное количество файлов распространенных графических форматов (jpg, bmp). Функционал аналогичен работе с прикрепленными файлами, дополнительно в Системе должны быть предусмотрены средства предварительного просмотра графических изображений без открытия файлов. 8.4. Информация о произвольном количестве документов: 8.4.1. Направление документа – значение из соответствующего справочника, указывающее на назначение документа в карточке объекта – определяется технологией работы с объектами соответствующего типа. 8.4.2. Номер документа. 8.4.3. Дата документа. 8.4.4. Тип документа – значение из классификатора типов документов. 8.4.5. Источник документа – значение из классификатора источников документов (организация, выпустившая документ) - -

Требования по ведению атрибутов объектов учета (4) - 8.4.6. Наименование документа – текстовое описание с возможностью выбора из справочника шаблонов наименований с возможностью последующего индивидуального изменения. 8.4.7. Примечание документа. 8.4.8. Ссылка на прикрепленный файл документа. Сохранение карточки объекта учета (атрибутов, файлов, графических объектов, документов должно производиться на основе транзакционных механизмов, то есть либо вся измененная информация карточки (внесенные в карточку данные) должны успешно сохраниться в базе данных, либо, например, в случае какой-либо ошибки, все изменения в базе данных, выполненные в процессе сохранения, должны быть отменены, и карточка должна вернуться в состояние, предшествующее сохранению. Пользователь должен быть подробно проинформирован Системой о характере возникшей ошибки и, по возможности, Система должна дать рекомендации по способам исправления ошибки. После исправления пользователем причин, приведшим к ошибке, должна быть предусмотрена возможность повторного сохранения внесенных в карточку изменений. Частичное автоматическое внесение изменений в базу данных в процессе внесения изменений в карточку объектов недопустимо - -

Требования к настройке элементов формы карточки объектов - Средства работы с атрибутами каждого из доступных типов данных по умолчанию должны содержаться в экранных контейнерах (панелях экранной формы), контейнеры должны быть размещены на вкладках экранной формы. Экранные контейнеры должны представлять собой панели прямоугольной формы, на которой размещаются элементы управления (просмотра, редактирования) атрибутами объектов учета. Для экранных контейнеров должна быть предусмотрена возможность выполнения следующих действий: 1. Изменение размеров контейнера (высота, ширина). 2. Перемещение контейнера по экранной форме, включая перемещение контейнера на другие вкладки (на свободное место экранной формы (не занятое другими элементами управления) имеющем размеры, достаточные для вмещения контейнера). Должна быть предусмотрена возможность для каждого типа объектов учета создания произвольного количества контейнеров с размещением в них произвольного количества логически связанных атрибутов любых типов единым списком. Для каждого атрибута, размещаемого в создаваемом контейнере, должна быть возможность указания признака автоматического добавления атрибута в карточку объекта учета и порядкового номера по умолчанию отображения автоматически добавленных атрибутов в контейнере. Автоматически добавляемые атрибуты должны добавляться в контейнер автоматически с последующим возможным указанием пользователем их значения. Должна быть предусмотрена возможность визуальной индикации в контейнере атрибутов, добавленных автоматически, но значение которых пользователем еще не введены (по факту такие атрибуты для объекта учета еще не определены). Для экранной формы должны быть предусмотрены следующие возможности по работе с вкладками: 1. Добавление вкладок. 2. Изменение наименований вкладок. 3. Изменение порядка следования вкладок. 4. Удаление вкладок, не содержащих элементов управления или контейнеров - -

Требования к настройке меню доступа к объектам учета и работы со списками - Система должна содержать в своем составе средства настройки иерархического меню доступа к объектам учета всех типов с учетом возможностей по добавлению новых объектов учета. Доступ к меню доступа к объектам учета должен предоставляться из основного окна Системы. Доступ к каждому пункту меню должен осуществляться за минимальное количество действий пользователя. При возобновлении сеанса работы с Системой (повторном запуске Системы) позиция текущего пункта меню в иерархическом меню должна быть восстановлена автоматически, то есть доступ к объектам учета соответствующего типа должен осуществляться путем использования одного клика мыши. Иерархическое меню должно иметь элементы следующих типов: 1. Промежуточные узлы – нажатие на этот пункт меню должен раскрывать следующий уровень иерархии (отображать вложенные пункты меню). 2. Промежуточные узлы-реестры – нажатие на данный пункт меню должен открыть объединенный список объектов учета, соответствующий совокупности объектов учета всех конечных элементов меню, вложенных с учетом иерархии в данный пункт (узел). Для данного типа пункта меню должна быть возможность открытия вложенных пунктов меню без открытия объединенного реестра. 3. Конечный узел – открывает список объектов учета, соответствующий данному пункту меню. 4. Конечный узел объединенного реестра – открывает объединенный список объектов учета, соответствующий конечным узлам пунктов меню, находящихся на этом же уровне иерархии (имеющих единый промежуточный узел). В меню должна быть предусмотрена возможность добавления пунктов, для которых может быть указан дополнительный фильтр, который автоматически применяется при отображении списка объектов, отображаемых с помощью данного пункта меню - -

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

Средства поиска, отображения и анализа информации (1) - Средства поиска, отображения и анализа информации должны быть включены во все экранные формы работы со списками объектов учета, в том числе в экранные формы работы с объектами реестра. Средства поиска должны обеспечивать возможности поиска объектов учета по всем характеристикам самих объектов, а также по всем характеристикам связанных объектов учета любого уровня вложенности (например, поиск объектов по параметрам связанных объектов учета, которые связаны со связанными объектами учета. – поиск объектов по параметрам договоров на них и параметрам субъектов этих договоров). Для каждой из характеристик должны быть предусмотрены следующие логические условия поиска: 1. Равно. 2. Не равно. 3. Больше. 4. Меньше. 5. Больше или равно. 6. Меньше или равно. 7. Содержит (для текстовых характеристик). 8. Не содержит (для текстовых характеристик). 9. Начинается на (для текстовых характеристик). 10. Не начинается на (для текстовых характеристик). 11. Заполнено. 12. Не заполнено. 13. Отсутствует. Для характеристик, имеющих историю изменения, должны быть предусмотрены средства указания даты, на которую выполняется поиск значения характеристики. Для сложных или связанных характеристик должны быть предусмотрены возможности поиска по комбинациям значений (например, поиск по коэффициентам подразумевает возможность поиска по произвольной комбинации значений, составляющих информацию по коэффициенту – наименование коэффициента, величина, диапазон дат периода действия коэффициента) Должен быть предусмотрен поиск по отрицанию условий поиска (объекты, НЕ удовлетворяющие условиям поиска). Должна быть предусмотрена возможность комбинации условий поиска – поиск в найденном и новый поиск в дополнение к предыдущему. Должна быть предусмотрена возможность сохранение ранее сформированных условий поиска для последующего быстрого использования - -

Средства поиска, отображения и анализа информации (2) - Для администраторов системы должна быть предусмотрена возможность формирования и отображения SQL-скрипта, соответствующего выборке объектов учета для формирования списка с учетом SQL-выражений, удовлетворяющих сформированным условиям поиска. Администратор должен иметь возможность ручной корректировки сформированных SQL-выражений поиска с возможностью выполнения поиска на основе скорректированных SQL-выражений. 1. Контекстный поиск В любой списочной форме (экранной форме отображения списка объектов учета или множественных реквизитов, атрибутов, характеристик объектов учета) должны быть предусмотрены средства контекстного поиска – возможность ввода символов в любой из колонок списка с автоматическим позиционированием курсора в списке на первый объект, соответствующий условиям поиска (вводимым значениям). 2. Универсальные средства предварительного просмотра В любой форме отображения списка объектов учета должна быть предусмотрена возможность отображения средств предварительного просмотра. Например, в списке договоров можно отобразить перечень кадастровых номеров земельных участков, арендуемых по текущему договору в списке, или перечень документов-оснований, перечень дополнительных соглашений, развернутую информацию о задолженности по договору. Средства предварительного просмотра должны представлять собой печатные формы, сформированные с использованием генератора отчетов, и отображающие всю необходимую информацию по текущему объекту учета в списке без выполнения дополнительных действий со стороны пользователя. Для каждого типа объектов учета может быть настроено произвольное количество форм предварительного просмотра с возможностью выбора текущей отображаемой формы из списка доступных форм - -

Средства поиска, отображения и анализа информации (3) - Средства предварительного просмотра должны обладать всеми возможностями печатных форм, включая возможность открытия карточки объекта учета путем двойного клика по информации по нему в окне предварительного просмотра (например, открытие карточки земельного участка из окна предварительного просмотра договоров, отображающего перечень земельных участков по текущему договору). 3. Аналитические средства элементов работы со списками объектов учета 1. Группировка данных по одному или нескольким столбцам. Например, реестр может быть сгруппирован по состоянию объектов учета, району области, разрешенному использованию. 2. Вычисление общих итогов, в том числе для каждой из групп (в случае применения группировки). Например, для приведенного примера возможна автоматическая калькуляция общей планируемой платы, площади объектов, величины задолженности в разрезе состояний договоров аренды, района расположения объекта договора, целевого использования; 3. Дополнительная оперативная фильтрация данных по значениям любого столбца\совокупности столбцов; 4. Сортировка данных по произвольному столбцу\совокупности столбцов. 5. Возможность выбора отображаемых столбцов. 6. Автоматическое сохранение настроек табличного представления для каждого типа объектов учета. Должна быть предусмотрена возможность экспорта сформированных данных в форматы табличные форматы (xlsx, csv), текстового файла или внутренние форматы генератора отчетов - -

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

Средства выполнения массовых операций - Система должна иметь средства выполнения однотипных операций над заданным количеством объектов учета, в том числе: 1. Передача с баланса на баланс, в казну, из казны, списание объектов. 2. Внесение документа-основания. 3. Смена адреса. 4. Смена характеристик объектов учета. 5. Изменить нумерацию объектов. 6. Слияние «двойников». 7. Включить физическое лицо в очередь и исключить из очереди. 8. Массовое формирование квитанций, уведомлений, претензий и других печатных форм на основе заданных шаблонов. 9. Распределение платежного документа, оплаченного по 2-м и более договорам субъекта договоров (арендатор) осуществляется по начислению и по сальдо на любую дату. Массовые операции должны повысить эффективность управления имущественно-земельным комплексом, снизить трудозатраты специалистов на выполнение операций над объектами - -

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (1) - Подсистема должна автоматизировать межведомственное электронное взаимодействие органов управления муниципальной собственностью в части формирования межведомственных запросов по протоколам СМЭВ в отношении объектов учета, субъектов права и договоров, зарегистрированных в единой базе данных Системы, а также автоматизации внесения изменений в единую базу данных Системы на основе полученных сведений. Подсистема должна решать следующие задачи: 1. Формирование межведомственных запросов в ручном режиме с любого рабочего места Системы (ручное заполнение информации по запросу). 2. Формирование межведомственных запросов непосредственно из карточки объекта учета, субъекта права или договора (автоматическое формирование запроса в «один клик»). 3. Формирование межведомственных запросов по вручную определенному пользователем перечню объектов учета, субъектов права или договоров в режиме массовой операции (полностью автоматическое формирование запросов без ограничения количества). 4. Автоматическое формирование межведомственных запросов по определенному перечню объектов учета, субъектов права или договоров в режиме регламентной операции (автоматически по расписанию без ограничения количества). Например, автоматическое формирование запроса на получение выписки из ЕГРН через месяц после подписания договора приватизации с целью определения даты перехода права на приватизированный объект (даты регистрации права собственности на нового собственника и исключения объекта из муниципальной доли) - -

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (2) - После получения ответов на отправленные запросы подсистема в автоматическом или автоматизированном режиме должна позволять: 1. Обеспечивать возможность автоматического и автоматизированного (автоматического по требованию пользователя) внесения изменений в единую базу данных Системы на основе полученных сведений. 2. Автоматически прикреплять полученные сведения к карточке соответствующего объекта учета, субъекта права или договора в базе Системы с обеспечением возможности автоматизированного внесения изменений в карточку объекта учета, субъекта права или договора на основе этих сведений. 3. Обеспечивать возможность в автоматизированном режиме формировать информацию, аналитические и статистические отчеты, запросы на основе полученных в результате межведомственных запросов сведений, например, формировать уведомления о необходимости регистрации права собственности на приобретаемые в собственность объекты муниципальной собственности (покупке, приватизация) лицам или организациям, нарушившим сроки регистрации. Функции подсистемы должны быть использованы для автоматизации выполнения следующих задач: 1. Определения даты исключения объекта из муниципальной собственности в ходе продажи/приватизации объекта. 2. Определения периода нахождения объекта в муниципальной казне, обеспечения корректного бюджетного учета движения объектов в казне. 3. Определения даты расторжения договоров аренды на объекты муниципальной собственности в ходе выкупа из аренды. 4. Определения даты передачи муниципальной собственности на праве оперативного управления или хозяйственного ведения. 5. Уточнения сведений по объектам муниципальной собственности, подлежащим продаже, приватизации, наложению других обременений и/или вещных прав. 6. Уточнения площадных, стоимостных и других характеристик объектов муниципальной собственности. 7. Уточнение сведений по зарегистрированным правам на объекты муниципальной собственности - -

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (3) - 8. Определения периода оплаты взносов на капитальный ремонт объектов муниципальной собственности, расположенных в многоквартирных жилых домах, включенных в программу капитального ремонта. Общей целью подсистемы должно быть обеспечение полноты и актуальности информации по объектам муниципальной собственности, земельным участкам, право собственности на которые не разграничено, вне-реестровым объектам учета, субъектам права, договорам и другим правам на объекты, подлежащие учету в рамках единого информационного фонда Системы. Для достижения поставленных целей подсистема должна обеспечить получение информации от участников межведомственного электронного взаимодействия путем формирования запросов в соответствии с установленными методическими рекомендациям, размещенными на портале https:/info.gosuslugi.ru Подсистема должна обеспечить: 1. Своевременное получение информации об изменении состава и/или содержания зарегистрированных на объекты учета прав, актуализацию соответствующих сведений в единой базе данных. 2. Своевременное проведение процедур, связанных с изменением информации по объектам учета, субъектам права и зарегистрированным правам. 3. Обеспечение полноты и качества ведения бюджетного учета движения объектов в муниципальной казне на основе актуальной информации по датам перехода права собственности на объекты учета, прав оперативного управления и хозяйственного ведения. 4. Обеспечение полноты и качества администрирования поступлений по администрируемым кодам бюджетной классификации на основе актуальной информации о регистрации договорных отношений. 5. Контроль за расходованием бюджетных средств на обслуживание объектов муниципальной собственности, включая оплату взносов на капитальный ремонт и др. - -

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (4) - В составе подсистемы должны быть реализованы следующие средства: 1. Интегрированное хранилище данных в составе единой базы данных Системы. 2. Интегрированные средства ведения справочников и классификаторов. 3. Средства настройки. 4. Средства ручного формирования межведомственных запросов. 5. Средства формирования межведомственных запросов из карточки объекта Системы. 6. Средства формирования межведомственных запросов в режиме массовой операции. 7. Средства формирования межведомственных запросов в режиме регламентной операции. 8. Средства подписания запросов электронной подписью. 9. Средства ручного внесения результатов запросов, которые не формировались средствами подсистемы. 10. Средства предотвращения повторного формирования запросов 11. Средства опроса системы СМЭВ на предмет уточнения состояния запроса. 12. Средства загрузки полученных сведений в интегрированной хранилище данных. 13. Средства автоматического внесения изменений в единую БД Системы на основе полученных сведений. 14. Алгоритмы автоматического внесения изменений в единую БД Системы на основе полученных сведений. 15. Средства «закрытия» запросов. 16. Средства работы с журналом межведомственных запросов. 17. Средства работы с карточкой межведомственного запроса. 18. Средства поиска объектов Системы по параметрам межведомственных запросов. 19. Средства просмотра протоколов выполнения операций. 20. Средства администрирования и разграничения прав пользователей - -

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (5) - Интегрированное хранилище данных в составе единой базы данных Системы Интегрированное хранилище данных должно быть предназначено для обеспечения хранения взаимосвязанной между собой информации подсистемы в составе единой базы данных Системы. Интегрированное хранилище данных должно обеспечивать хранение информации без дублирования, повторного внесения информации, которая уже содержится в единой базе данных Системы. Интегрированное хранилище должно содержать ссылки на объекты, субъекты и договоры единой базы данных Системы. Интегрированное хранилище должно обеспечивать хранение в единой базе данных Системы следующей информации: 1. Нормативно-справочная информация подсистемы (содержимое справочников и классификаторов, использующихся в подсистеме). 2. Информацию о настройках функционирования подсистемы. 3. Информация по сформированным запросам, полученным в ходе запросов сведениям. 4. Протоколы всех действий, выполняемых средствами подсистемы в автоматическом, полуавтоматическом и ручном режимах. 5. По каждому запросу должна быть размещена следующая информация: 5.1. Идентификатор вида сведений версии 3.х. 5.2. Вид операции из соответствующего классификатора (ручной, из карточки объекта Системы, из массовой операции, регламентная операция, на основе результатов, полученных из других источников), для массовой и регламентной операции – идентификатор операции. 5.3. Дата и время формирования запроса, идентификатор пользователя (если операция инициирована пользователем). 5.4. Информация, переданная в систему СМЭВ в ходе формирования запроса. 5.5. Идентификатор запроса, присвоенный системой СМЭВ. 5.6. Идентификатор карточки Системы, из которой (для которой) сформирован запрос. 5.7. Идентификаторы объекта (помещение или земельный участок), субъекта (юридическое или физическое лицо, ИП), договора, по которым сформирован запрос. Заполняются те идентификаторы, которые применимы для конкретного вида запроса - -

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (6) - Примечание. Например, запрос информации из ЕГРН для определения даты перехода права в ходе приватизации теоретически может быть сформирован как из договора приватизации, так и из объекта. В этом случае идентификаторы карточки Системы, из которой сформирован запрос, должны быть разные, но идентификатор объекта в обоих запросах должен быть один. Это должно потенциально позволить предотвратить повторные запросы на основе анализа идентификатора объекта. 5.8. Дата и время автоматического или полуавтоматического внесения информации, по полученным сведениям, в единую базу данных. 5.9. Режим внесения изменений (автоматический, полуавтоматический «мастер», ручной) – см. пункт «Интегрированные средства ведения нормативно-справочной информации». 5.10. Идентификатор пользователя, внесшего изменения в ручном или полуавтоматическом режиме – «мастер». 5.11. Признак отработки результатов запроса (да или нет). 5.12. Текущий статус (состояние) запроса в системе СМЭВ. 5.13. Дата и время изменения сведений запроса в системе СМЭВ (по данным СМЭВ). 5.14. Дата и время внесения изменений из системы СМЭВ (изменения статуса запроса). 5.15. Дату и время последнего успешного опроса системы СМЭВ по данному запросу. 5.16. Полную информация обо всех изменениях статусов (состояний) запросов, включая дату и время смены состояния, текстовое описание причины смены состояния, и другие сведения, полученные из системы СМЭВ в ходе информационного обмена - -

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (7) - 6. Информация, полученная в ходе исполнения межведомственного запроса должна быть представлена в структурированном виде и размещаться ее в реляционных структурах (таблицах) единой базы данных Системы. Информация должна быть представлена в виде, пригодном для формирования SQL-запросов с ее использованием. Должны быть предусмотрены средства заполнения данных в структурированном, реляционном виде на основе информации, размещенной в XML-файле полученного результата запроса. Хранение данных только в XML-файле результата запроса недопустимо. Полученную информацию необходимо вносить в интегрированное хранилище. В интегрированном хранилище должны быть размещены протоколы всех действий, выполняемых средствами подсистемы в автоматическом, полуавтоматическом и ручном режимах, в том числе: 1. Протокол взаимодействия с подсистемой СМЭВ (формирование запроса, опросы с целью получения статуса запроса (пингование), загрузка результата в интегрированное хранилище, парсинг результата, размещение данных результата в реляционных таблицах). 2. Протокол применения результата к объектам базы данных (поиск объектов в базе данных для ручных запросов, автоматическое добавление объектов в базу данных по результатам запросов, внесение изменений в электронные карточки объектов учета на основе полученных данных (индивидуально для каждого выполненного изменения)). Протоколы должны содержать следующую информацию: 1. Дата и время выполнения операции или действия. 2. Имя пользователя, инициировавшего операцию (если операцию инициировал пользователь). 3. Вид операции из соответствующего классификатора (ручной, из карточки объекта Системы, из массовой операции, регламентная операция, опрос (пингование) запроса в системе СМЭВ, получение события из системы СМЭВ), для массовой и регламентной операции – идентификатор операции. 4. Признак успешности выполнения операции из соответствующего классификатора (успешно, не успешно). 5. Выполненное действие (из соответствующего классификатора) - -

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (8) - 6. Данные, связанные с действием (в текстовом виде), например, при вводе кадастрового номера объекта на основе полученных данных – кадастровый номер. 7. Дополнительная текстовая информация (в случае ошибки – причина ошибки). Интерфейс для работы пользователей с данными, размещенными в интегрированном хранилище, должен быть обеспечен непосредственно Системой с использованием экранных форм, разработанных по общим принципам, принятым для Системы, с использованием единого визуального стиля, оформления Системы. Интегрированные средства ведения справочников и классификаторов Средства должны быть предназначены для управления работой со справочниками и классификаторами подсистемы и обеспечивать единое пространство справочной информации в процессе использования учетных данных и документов. Средства должны обеспечивать выполнение функций: 1. Редактирование справочников и классификаторов. 2. Просмотр справочников и классификаторов. Средства настройки Подсистема должна обеспечивать максимально широкие возможности по настройке, изменению технологии работы подсистемы силами обученных пользователей Системы без привлечения программистов Исполнителя. Должны быть предусмотрены следующие средства настройки, изменения технологии работы подсистемы силами обученных пользователей Системы: 1. Средства настройки перечня доступных сервисов и/или видов сведений для формирования межведомственных запросов в ручном режиме. 2. Средства настройки перечня доступных для каждого из типов объектов учета Системы сервисов и/или видов сведений. 3. Перечень регламентных операций для формирования запросов по расписанию, настройка расписания выполнения регламентных операций. 4. Средства/Алгоритмы чтения полученных в результате межведомственного запроса сведений и размещения их в реляционных субтаблицах интегрированного хранилища (единой базы данных Системы). 5. Средства/Алгоритмы внесения изменений в электронные карточки объектов учета на основе полученных данных - -

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (9) - 6. Средства/Алгоритмы создания объектов учета, отсутствующих в базе данных, на основе сведений, содержащихся в полученных ответах. 7. Средства/Алгоритмы связи запросов, выполненных в ручном режиме, с объектами, которые уже есть в базе данных Системы на основе сведений, содержащихся в полученных ответах. 8. Средства/Алгоритмы автоматического «закрытия» межведомственных запросов после получения и использования (применения, внесения в базу данных) полученных сведений, возможность индивидуального отключения автоматического «закрытия» запросов. 9. Создание шаблонов автоматического частичного заполнения формы формирования ручного запроса. Средства ручного формирования межведомственных запросов При ручном формировании запроса пользователь должен предварительно выбирать услугу (сервис), для которой формируется запрос. Выбор должен производиться из перечня услуг (сервисов), для которых доступно ручное формирование запроса. В случае, если для некоторого сервиса/услуги предусмотрена возможность формирования запросов по нескольким вариантам параметров (например, по кадастровому номеру или адресу объекта), то должна быть предусмотрена возможность ввода параметров запроса для каждого варианта. При проектировании должна быть предусмотрена возможность создания шаблонов автоматического заполнения одного или нескольких параметров запросов. Должна быть предусмотрена возможность индивидуального создания шаблонов каждым пользователем. Технология создания шаблонов должна быть реализована по следующему принципу – пользователь заполняет те параметры экранной формы ручного формирования запросов, которые должны быть включены в шаблон. Далее пользователь инициирует создание шаблона и вводит его наименование/описание. После этого шаблон автоматически появляется в списке доступных для данного пользователя шаблонов для данной услуги/сервиса. Для одного из шаблонов каждого сервиса/услуги должна быть предусмотрена возможность выбора шаблона по умолчанию - -

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (10) - Пользователь может выбрать любой доступный для данного сервиса/услуги шаблон, в этом случае соответствующие параметры из шаблона автоматически должны заполнять поля экранной формы ручного формирования запроса. После успешного формирования запроса пользователю должно быть выведено соответствующее сообщение с указанием кода сформированного запроса в журнале запросов. Для запросов по кадастровому номеру или кадастровому кварталу должна быть предусмотрена возможность пакетного формирования ручных запросов на основе кадастровых номеров (или кварталов), определенных в текстовом файле (в столбик) – для каждого кадастрового номера (квартала) автоматически должен быть сформирован запрос. Аналогичная возможность должна быть предусмотрена для запросов по ИНН, ОГРН и другим классификационным кодам юридических, физических лиц, индивидуальных предпринимателей. Средства формирования межведомственных запросов из карточки объекта Системы Формирование межведомственных запросов из карточки объекта Системы подразумевает возможность автоматического формирования запроса в системе СМЭВ. Параметры, необходимые для формирования запроса в автоматическом режиме должны заполняться на основе данных, размещенных в соответствующей карточке объекта учета, из которой формируется запрос. При формировании запроса пользователь должен предварительно выбрать услугу (сервис), для которой формируется запрос. Выбор должен производиться из перечня услуг (сервисов), для которых доступно формирование запроса из карточки объекта данного типа (см. требования к настройке подсистемы). Формирование запроса должно быть реализовано с использованием динамически формируемого перечня пунктов подменю пункта «СМЭВ» меню карточки (или кнопки СМЭВ). Динамически формируемый перечень подменю должна соответствовать перечню доступных для запроса услуг/сервисов с отбивкой сепаратором услуг/сервисов различных организаций (услуги/сервисы различных организаций визуально должны быть отделены друг от друга) - -

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (11) - В случае, если карточка объекта учета не содержит всей необходимой для формирования запроса информации, пользователь должен быть в развернутой форме информирован о характере возникшей ошибки с указанием конкретных реквизитов объекта, которые должны быть заполнены для корректного формирования запроса. Должна быть предусмотрен режим ручного формирования запроса из карточки объекта. В данном режиме Система инициирует ручное создание запроса, а также производит автоматическое заполнение параметров запроса сведениями, содержащимися в карточке соответствующего объекта учета. После этого пользователю предоставляется возможность самостоятельной корректировки сведений (параметров запроса) и ручного формирования межведомственного запроса. После формирования запроса пользователю должно быть выведено соответствующее сообщение с указанием кода сформированного запроса в журнале запросов. Средства формирования межведомственных запросов в режиме массовой операции Для формирования межведомственных запросов в режиме массовой операции должен быть задействован стандартный механизм Системы работы с массовыми операциями (выбора объектов для выполнения массовой операции). Выбор объектов для массовой операции должен производиться с использованием следующих средств: 1. Из списка объектов учета любых типов основного окна Системы. 2. Из экранных форм Системы, отображающих списки объектов учета произвольных типов. 3. Из окна результата запроса подсистемы «Библиотека запросов». Выбор услуги (сервиса) для формирования запроса должен быть реализован путем динамического создания пунктов подменю пункта СМЭВ. Пункты подменю должны содержать полный перечень всех услуг/сервисов, доступных для формирования из карточек объектов учета, доступных для выполнения массовой операции в текущем режиме работы - -

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (12) - Выполнение массовой операции должно производиться пообъектно способом, аналогичным формированию запроса из карточки объекта учета соответствующего типа (описание приведено выше). В случае, если операция формирования запроса для данного вида объекта учета недоступна (в соответствии с настройками) или для формирования запроса недостаточно информации, по таким объектам формируется ошибка по правилам функционирования функционала массовых операций (объект помечается красным фоном, формируется развернутое сообщение об ошибке (содержит четкое описание сути ошибки), объект пропускается, происходит переход к обработке следующего объекта). Операции, выполняемые в режиме массовой операции, должны протоколироваться по общим принципам (индивидуальное протоколирование каждого сформированного в режиме массовой операции межведомственного запроса). Средства формирования межведомственных запросов в режиме регламентной операции Регламентная операция представляет собой выполнение некоторого запроса по определенному расписанию, межведомственные запросы формируются в автоматическом режиме для каждого объекта, информация по которому возвращена запросом. Средства формирования межведомственных запросов в режиме регламентных операций должны обеспечивать ведение библиотеки регламентных операций, средства добавления, изменения, удаления регламентных операций, приостановки выполнения регламентных операций. Библиотека регламентных операций должна представлять собой список регламентных операций, содержащий следующие атрибуты: 1. Код идентификатор (код) регламентной операции. 2. Наименование - наименование регламентной операции. 3. Организация – наименование организации, предоставляющей услугу/сервис. 4. Сервис наименование услуги/сервиса для формирования запроса в режиме регламентной операции. 5. Признак успешности предыдущего выполнения. 6. Дата, время следующего выполнения. 7. Состояние (запланировано, приостановлено) - -

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (13) - 8. Приостановленные регламентные операции или регламентные операции, для которых не определено время следующего запуска должно визуально выделяться (серый текст шрифта). 9. Регламентные операции, по которым предыдущий вызов был завершен ошибкой должны визуально выделяться (розовый фон). 10. Для каждой регламентной операции должны быть определены: 10.1. Код – присваивается автоматически. 10.2. Наименование регламентной операции. 10.3. Описание регламентной операции – текст произвольного размера. 10.4. Услуга/сервис – выбор из списка услуг/сервисов, доступных для формирования запросов в режиме регламентной операции. Расписание выполнения операции (стандартный функционал для формирования расписаний) – в определенное время разово, ежечасно, ежедневно, еженедельно в определенные дни. Средства подписания запросов электронной подписью С целью обеспечения возможности автоматизированного формирования запросов в пакетном режиме, а также автоматического формирования запросов в режиме массовой операции в Подсистеме должны быть реализованы средства централизованного (серверного) принципа подписания запросов электронной подписью. Для этого в составе подсистемы должен быть реализован сервер ЭП (сервер электронной подписи). Это означает, что в подсистеме должна быть реализована возможность добавления одной или более учетных записей организаций/пользователей организаций, настройки и реквизиты которых будут использоваться для формирования межведомственных запросов и подписания их электронной подписью. Для каждой учетной записи должна быть обеспечена возможность сопоставления с ЭП-ОВ (электронной подписи органа власти) и ЭП-СП – электронная подпись служебного пользования уполномоченного лица (руководителя), которые загружены на сервер ЭП - -

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

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

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (16) - Основным режимом получения/обновления сведений о сформированных ранее межведомственных запросов из системы СМЭВ является режим периодического опроса (пингования) системы СМЭВ. При наличии изменений с момента последнего опроса (пингования) системы СМЭВ (изменение даты и времени последнего изменения запроса в системе СМЭВ с аналогичными данными в интегрированном хранилище Системы), полученная информация должна быть занесена в интегрированное хранилище Системы: 1. Дата и время последнего изменения состояния или сведений запроса в системе СМЭВ. 2. Текущий статус (состояние) запроса. 3. При изменении статуса (состояния) запроса – информация по изменению состояния (см. требования к интегрированному хранилищу данных). При получении сведений за межведомственный запрос (XML-файл, содержащий сведения), подсистема должна выполнять чтение файла и должна разместить полученную из XML-файла информацию в соответствующих субтаблицах запроса в виде, пригодном для формирования SQL-запросов с использованием полученных сведений. Все операции по опросу (пингованию) системы СМЭВ вне зависимости от наличия изменений должны протоколироваться. Требования к протоколированию приведены в пункте «Интегрированное хранилище данных». Должна быть предусмотрена возможность опроса (пингования) по всем сформированным межведомственным запросам, обработка которых еще не завершена (запрос не находится в состоянии ошибки и сведения по нему еще не получены), а также по межведомственным запросам определенной (выбранной пользователем) услуги (сервиса). Операция должна выполняться из основного окна Системы с использованием соответствующих пунктов меню. В некоторых случаях сведения, содержащиеся в ответе на межведомственный запрос, не передаются в ходе межведомственного взаимодействия, а должны скачиваться пользователем вручную с использованием сети интернет. Такая ситуация возникает, например, из-за большого объема полученных сведений. - -

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (17) - Средства загрузки полученных сведений в интегрированное хранилище Полученные в результате межведомственного запроса сведения содержат XML-файл заданной в спецификациях к конкретной услуге (сервису) структуры. В момент получения XML-файла должно быть обеспечено чтение всех данных XML-файла и размещение их в интегрированном хранилище Системы (единой базе данных Системы) в структурированном виде, пригодном для использования в SQL-запросах (см. требования к интегрированному хранилищу). Чтение данных XML-файла и размещение их в интегрированном хранилище должно осуществляться с использованием алгоритма из библиотеки алгоритмов парсинга (разбора) результатов запросов, полученных в машиночитаемом виде (xml). Должна быть предусмотрена возможность разработки новых алгоритмов и включение их в библиотеку алгоритмов силами обученных пользователей Системы Заказчика. Должно быть предусмотрено обязательное протоколирование выполнения указанной процедуры. Требования к протоколированию приведены в пункте «Интегрированное хранилище данных»). Загрузка полученных сведений в интегрированное хранилище должно производиться вне зависимости от способа загрузки сведений (автоматическая загрузка при получении ответа на сформированный ранее запрос), ручная загрузка результата, направленного ранее запроса, ручная загрузка результата на запрос, который не был отправлен средствами подсистемы. Средства автоматического внесения изменений в единую БД Системы на основе полученных сведений Автоматическое внесение изменений в единую базу данных Системы на основе полученных сведений должно производится в момент получения сведений на межведомственный запрос после размещения полученных данных в реляционных субтаблицах. Автоматическое внесение изменений должно производиться путем вызова соответствующего алгоритма из библиотеки алгоритмов, наименование которого настраивается для каждой услуги (сервиса) - -

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

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (19) - Алгоритм автоматического внесения изменений в единую БД Системы на основе полученных сведений должен быть определен индивидуально для каждого типа объектов учета и каждого сервиса/услуги с возможностью его настройки. Алгоритм должен функционировать по следующему принципу: 1. Если запрос был сформирован вручную, то на основе полученных сведений должен быть выполнен поиск соответствующего объекта в единой базе данных Системы, при успешном поиске запрос должен быть автоматически прикреплен к соответствующему объекту, соответствующее действие должно быть внесено в протокол. 2. Если найти объект не удалось, то в зависимости от настройки (такая настройка должна быть предусмотрена) подсистема автоматически создаст соответствующий объект в единой базе данных Системы и заполнит электронную карточку объекта сведениями, содержащимися в полученных данных. Соответствующие действия должны быть внесены в протокол. 3. Если получены сведения на запрос по объекту, который уже находится в базе данных Системы, то алгоритм опционально (такая настройка должна быть предусмотрена индивидуально для каждого типа объектов учета, сервиса/услуги и действия из перечисленного ниже списка) должен иметь возможность выполнить следующие действия: 3.1. Для каждого реквизита полученных сведений должна быть выполнена сверка с соответствующим реквизитом в электронной карточке соответствующего объекта учета. Возможны следующие варианты: 3.1.1. Если реквизит не заполнен, он подлежит заполнению на основе полученных сведений (должно настраиваться). 3.1.2. Если реквизит заполнен, и он отличен от соответствующего реквизита в полученных сведениях, то в зависимости от настройки либо реквизит подлежит изменению (с протоколированием каждого действия), либо для запроса должно быть сформировано предупреждение (состояние запроса сменится на «Предупреждение») с внесением в текст предупреждения развернутой информации о выявленных различиях - -

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (20) - 4. Информация о полученных сведениях должна быть занесена в документы по объекту учета (опционально). Для выписок из Росреестра о правах на объекты имущества дополнительно (опционально) должны быть предусмотрены следующие возможности: 1. Сверка с единой БД Системы на предмет наличия объекта в реестре муниципальной собственности (если в Системы объект включен в реестр, а по данным Росреестра – нет или наоборот, то должно быть сформировано соответствующее предупреждение). 2. В случае, если в выписке обнаружена информация о регистрации права на объект имущества Системы, которое перешло новому владельцу на основании документов, фигурирующих в единой БД Системы (например, в ходе продажи или приватизации объекта), то опционально должна быть предусмотрена возможность автоматического исключения объекта из реестра муниципальной собственности датой, предшествующей дате регистрации объекта на нового собственника с автоматическим внесением информации о документе-основании исключения. Автоматические изменения в соответствии с алгоритмами и настройками Системы могут быть инициированы пользователем вручную. В этом случае пользователь должен быть проинформирован о всех произведенных действиях подсистемы (открыт протокол соответствующих действий) с возможностью быстрого доступа (в один клик мыши) к карточке объекта учета для анализа и возможной корректировки соответствующих действий. Средства «закрытия» запросов Под «закрытием» запроса помечается возможность пометки запроса в качестве отработанного, то есть запроса, не требующего дальнейшего анализа или использования пользователем. Должна быть предусмотрена возможность автоматического и ручного «закрытия» запросов - -

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (21) - Автоматическое «закрытие» запросов должно производиться по настройке (такая настройка должна быть предусмотрена индивидуально для каждого типа объектов учета и услуге/сервису) после успешного получения результатов запроса и автоматического успешного внесения изменений в единой базе данных Системы, предусмотренных соответствующим алгоритмом. Должна быть предусмотрена возможность отключения автоматического «закрытия» запросов индивидуально для каждого пользователя. Ручное «закрытие» должно производится пользователем самостоятельно после изучения и/или использования результатов запроса. «Закрытые» запросы не должно изыматься из единой базы данных Системы, последующий доступ к ним должен быть обеспечен по запросам пользователей. По умолчанию для журнала запросов должна быть предусмотрена возможность отображения не закрытых запросов – см. требования к функционированию журнала запросов. Средства работы с журналом межведомственных запросов Журнал запросов должен представлять собой список запросов, содержащий всю основную информацию по каждому запросу, а также средства открытия карточки запроса и выполнения основных действий над запросом. Журнал запросов должен быть доступен в следующих режимах: 1. Из карточки объекта Системы – журнал размещается на вкладке «СМЭВ» карточки объекта и содержит все межведомственные запросы, которые были сформированы для данного объекта. 1.1. Из основного окна Системы для всех услуг/сервисов, а также индивидуально для каждого из сервисов/услуг в режиме отображения «моих» запросов. Под «моими» запросами понимаются запросы, сформированные текущим пользователем Системы. 1.2. Из основного окна Системы для всех услуг/сервисов, а также индивидуально для каждого из сервисов/услуг в режиме отображения всех запросов - -

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (22) - Для журнала межведомственных запросов должны быть предусмотрены средства поиска/фильтрации запросов в соответствии с требованиями к функционированию подсистемы поиска и анализа информации Системы: 1. Должны быть предусмотрены возможности поиска запросов по любым параметрам запроса, в том числе: 1.1. Сервис/услуга. 1.2. Код запроса. 1.3. Дата формирования запроса. 1.4. Состояние запроса (с возможностью множественного выбора из справочника состояний). 1.5. Статус запроса (текстовый статус сервисов межведомственного взаимодействия). 1.6. Сообщение протокола прохождения (выполнения) запроса. 1.7. Сообщения протокола применения результатов запроса (внесения изменений в базу Системы по результатам запроса). 1.8. Номер заявки. 1.9. GUID запроса в Системы. 1.10. Признак «закрытия» запроса. 1.11. Тип операции создания запроса (вручную, из карточки объекта, массовая операция, регламентная операция) – множественный выбор из справочника. 1.12. Источник операции создания запроса – множественный выбор из соответствующего справочника. 1.13. Пользователь, инициировавший запрос. 1.14. Дата последнего изменения информации. 1.15. Код регламентной операции. 1.16. Дата получения результата. 1.17. Дата загрузки результата. 1.18. Дата применения результата. 1.19. Тип операции применения результата – из соответствующего справочника. 1.20. Источник операции применения результата – из соответствующего справочника. 1.21. Пользователь, применивший результат. 1.22. Признак автоматического создания запроса при ручной загрузке результата, полученного из внешних источников. 1.23. Признак необходимости ручной загрузки результатов запроса. 1.24. Признак необходимости ручного применения результатов. 1.25. Признак включения в план повторных запросов - -

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

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (24) - 10. Средства доступа к карточке объекта учета в Системе (в один клик). 11. Средства загрузки результатов запроса (для запросов, требующих ручную загрузку результатов). 12. Средства открытия запроса в системе СМЭВ. Средства поиска объектов Системы по параметрам межведомственных запросов Для объектов базы данных Системы должны быть предусмотрены средства поиска объектов по параметрам межведомственных запросов. Средства указания параметров поиска/фильтрации должны быть интегрированы непосредственно в стандартные окна поиска/фильтрации объектов Системы и должны быть размещены на отдельной вкладке «СМЭВ». Средства поиска должны обладать следующими возможностями: 1. Поиск объектов по наличию или отсутствию межведомственных запросов указанного сервиса/услуги (если не указано, то для любых сервисов/услуг) в заданном диапазоне дат (если не указано, то на любую дату). 2. Поиск объектов по любым параметрам запросов с использованием формы поиска/фильтрации журнала межведомственных запросов. Средства просмотра протоколов выполнения операций Средства просмотра протоколов выполненных операций должны представлять собой таблицу с возможностью стандартной расширенной настройки табличного представления (сортировка, группировка, встроенные фильтры), отображающей все выполненные операции по заданному запросу. Средства просмотра протоколов выполнения операций должны быть доступны из карточки запроса. Средствами подсистемы «Библиотека запросов» Системы должна иметь возможность анализа протоколов по алгоритмам, которые определяются соответствующими запросами в «Библиотеке запросов» - -

Подсистема межведомственного электронного взаимодействия. Платформа СМЭВ (25) - Средства администрирования и разграничения прав пользователей Все операции подсистемы, которые могут быть инициированы пользователем, должны подлежать администрированию и разграничению прав доступа. Администрированию должны подлежать: 1. Операции ручного формирования запросов – индивидуально для каждого вида услуги (сервиса) – по справочнику услуг (сервисов). 2. Операции формирования запросов из карточек объектов учета – индивидуально для каждого вида объекта и услуги (сервиса). 3. Операции формирования запросов в режиме массовой операции – индивидуально для каждого вида объекта в массовой операции и услуги (сервиса). 4. Операции ручной загрузки сведений, полученных из сторонних источников – индивидуально для каждого вида объекта и услуги (сервиса). 5. Операции ручного инициирования автоматического внесения изменений на основе полученных сведений – индивидуально для каждого вида объекта и услуги (сервиса). 6. Просмотр, печать, экспорт результатов, сформированных ранее запросов – индивидуально для каждого вида объекта и услуги (сервиса) - -

Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» (1) - Подсистема должна обеспечивать автоматический сбор и передачу информации по начислениям из Системы в Государственную информационную систему государственных и муниципальных платежей (ГИС ГМП) с использованием протоколов СМЭВ в форматах и порядке, утвержденных приказом Федерального казначейства от 12 мая 2017 г. № 11н «Об утверждении Порядка ведения Государственной информационной системы о государственных платежах». Подсистема должна быть реализована в виде сервисов ОС, которые выполняют следующие функции: 1. Формирование и присвоение УИН (уникальный идентификатор) начислениям всех типов (в соответствии с методическими и форматными требованиями ГИС ГМП). 2. Автоматический сбор информации по начислениям, а также корректировкам и аннулированиям начислений из Системы. 3. Формирование сообщений в утверждённых форматах ГИС ГМП, заверение их электронной подписью (ЭП) и передача сообщений по протоколам СМЭВ, формирование протокола отправки и подтверждения получения из ГИС ГМП. 4. Анализ полученных ответов и создание необходимых записей/протоколов в БД Системы. 5. Автоматическое распределение поступлений, в которых указан корректный UIN, по договорам Системы. Подсистема должна автоматизировать работу оператора начислений, снять нагрузку по ручному формированию и отправке начислений в Федеральное казначейство, а также проверки статусов начислений. Вся работа должна осуществляться в стандартном интерфейсе Системы, средства взаимодействия должны функционировать полностью автоматически и не требовать дополнительных действий от пользователей Системы - -

Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» (2) - Средства импорта поступлений из ГИС ГМП, квитирования начисления Подсистема должна обеспечить в автоматическом режиме получение платежей из ГИС ГМП и размещение их в журнал платежей подсистемы. Получение платежей должно выполняться полностью автоматическом фоновом режиме по заданному расписанию. Журнал платежей ГИС ГМП должен обеспечивать выполнение следующих задач: 1. Хранение полной информации по всем полученным платежам (атрибутам платежей), в объеме и составе атрибутов, использующихся в финансово-аналитической подсистеме Системы, журнале нераспределенных платежей. 2. Хранение даты получения информации о платеже. 3. Ведение журнала (лога) всех операций, выполняемых над платежами в журнале. 4. Постановка функции получения платежей на паузу. 5. Обеспечение поиска/фильтрации платежей в журнале по всем параметрам платежей, а также их состояниям, сообщениям лога работы с платежами. 6. Формирование и ведение информации о несквитированной сумме платежа в режиме реального времени. Информация об автоматическом квитировании начислений платежами на стороне ГИС ГМП (при совершении платежа плательщиком с использованием УИН начисления) должна приниматься из ГИС ГМП в автоматическом режиме одновременно с получением информации о соответствующих платежах. В случае получения информации об автоматическом квитировании должен быть автоматически произведен поиск соответствующих начислений в журнале начислений и связывание платежа с этими начислениями (квитирование) - -

Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» (3) - Должна быть предусмотрена возможность ручного квитирования начислений. Ручное квитирование начислений с платежами должно выполняться путем выбора платежа, квитирующего данное начисление с указанием суммы квитирования. Выбор платежа должен производиться с использованием инструментов журнала платежей подсистемы. Должен быть предусмотрен комплекс проверок – сумма квитирования не должна превышать суммы начисления, начисление может быть сквитировано с платежом на сумму, не превышающую сумму платежа. Должна быть предусмотрена возможность частичного квитирования начисления (квитирования не всей суммы начисления) - -

Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» (4) - Ручное квитирование должно быть предусмотрено только для успешно отправленных в ГИС ГМП начислений, сумма которых не сквитирована или не полностью сквитирована с платежами. Должна быть предусмотрена возможность квитирования начислений с отсутствующим платежом (в соответствии с технологией квитирования, предусмотренной в ГИС ГМП). Информация о вручную выполненных квитированиях должна автоматически отправляться в ГИС ГМП в соответствии с форматами обмена (действующая версия формата на момент заключения Контракта). Средства автоматического распределения поступлений с использованием УИН Поступления по администрируемым кодам бюджетной классификации (КБК) поступают в журнал нераспределенных поступлений финансово-аналитической подсистемы из системы СУФД Федерального Казначейства. В Системе должна быть предусмотрена возможность выполнения автоматических операций по автоматическому распределению поступлений на договоры с привязкой к виду начисления. В случае, если информация о поступлении содержит УИН начисления, эта информация должна использоваться для однозначного определения договора и вида начисления путем поиска по УИН и анализа информации о соответствующем начислении. Должно быть выполнено соответствующее развитие алгоритмов автоматического распределения поступлений по договорам и видам начислений финансово-аналитической подсистемы - -

Требования к видам обеспечения (1) - 4.1 Информационное обеспечение Системы Информационный обмен между узлами Системы основывается на стандартных протоколах передачи данных, использующих сетевой протокол TCP/IP. 4.2 Требования к контролю, хранению, обновлению и восстановлению данных Система должна контролировать корректность вводимой информации, а также проверять логическую целостность информации в БД при выполнении операций с БД. Стратегию и план резервного копирования разрабатывает Заказчик на основе рекомендаций Исполнителя, исходя из следующих условий: 1. Емкость и производительность системы резервного копирования. 2. Объемов разделов БД. 3. Допустимого времени восстановления. 4. Требований по обеспечению сохранности информации. Система должна протоколировать все события, связанные с изменением своего информационного наполнения, и иметь возможность, в случае сбоя в работе, восстанавливать свое состояние, используя ранее запротоколированные изменения данных. 4.3 Аппаратное обеспечение Системы Система должна функционировать на предоставленном Заказчиком оборудовании, с перечисленными ниже характеристиками. Оборудование предоставляется Заказчиком не позднее чем через 2 дня после заключения контракта. 4.3.1 Основной сервер Системы - -

Требования к видам обеспечения (2) - На нем размещаются следующие функциональные серверы: 1. Сервер БД – сервер баз данных СУБД, предназначены для хранения и управления информацией базы данных Системы. В качестве СУБД может быть использован Postgres версии не менее 12.0 или эквивалент. 2. Сервер приложений - обеспечивает предоставление доступа Клиентских мест, автоматизированных рабочих мест (далее - АРМ) пользователей к данным Системы, а также содержит средства обеспечения корректности исполнения технологических процессов (бизнес-логики) функционирования Системы. Представляет собой промежуточное звено обеспечения взаимодействия между АРМ пользователей и Сервером БД. Сервер должен иметь конфигурацию не ниже следующей: 1. Процессор: 8 ядер, частота не менее 2 ГГЦ на одно ядро. 2. Оперативная память не менее 16 Гб (рекомендуется от 32 Гб). 3. Емкость HDD не менее 400 Гб свободного места. 4. СУБД PostgreSQL 12.0 и выше 5. Операционная система. 5.1. Семейства Linux: - Ubuntu 20.04 LTS - Ubuntu 22.04 LTS - RedHat Enterprise Linux (version 8) - АльтЛинукс РС 10.2 (или выше) - РЕД ОС 8.0 - Astra Linux SE 1.8 - Альт СП 10 5.2. Семейства Windows: -Windows Server 2019 - Windows Server 2022 - Windows 10 - Windows 11 6. Доступ к серверу БД по протоколу TCP\IP. 7. При использовании ОС на базе Linux сервер: 7.1. Наличие графической оболочки (рабочего стола) 7.2. Возможность удаленного подключения по RDP (xRDP или аналог). 7.3. Возможность установки обновления для операционной системы, а также установки дополнительных пакетов (ПО) необходимых для работы сопровождаемого программного обеспечения из стандартных дистрибутивов - -

Требования к видам обеспечения (3) - 4.3.2 Сервер платформы СМЭВ Сервер платформы СМЭВ (сервер ЭП) – предназначен для автоматизации межведомственного электронного взаимодействия органов управления муниципальной собственностью в части формирования межведомственных запросов по протоколам СМЭВ в отношении объектов учета, субъектов права и договоров, зарегистрированных в единой базе данных Системы, а также автоматизации внесения изменений в базу данных Системы на основе полученных сведений. Требует для своей работы установку КриптоПро CSP версии не ниже 5.0. Заказчик организовывает наличие защищенного канала до СМЭВ (РСМЭВ). В случае невозможности организации защищенного канала для основного сервера, сервер платформы СМЭВ может быть размещен на отдельном сервере. Сервер платформы СМЭВ имеет конфигурацию не ниже следующей: 1. Операционная система. Windows: необходима подсистема WSL2 не ниже Windows Server 2019 (для серверов) не ниже Windows 10 22H2 должна быть включена виртуализация Linux: Astra Linux Ubuntu не ниже 22.04 Альт СП 10 2. Оперативная память не менее 64 Гб. 3. Процессор 4х ядерный процессор с тактовой частотой не менее 2 Ггц. 4. СУБД PostgreSQL не ниже 12. 5. Доступ к Web-серверу по протоколу TCP/IP (перечень портов согласовывается). 4.3.3 Сервер резервного копирования для единой базы данных Системы Сервер резервного копирования предназначен для хранения резервных копий. В качестве сервера можно использовать сетевую папку на стороннем компьютере или NAS хранилище с аналогичными характеристиками или любой из имеющихся серверов с малой производительностью, но достаточной дисковой подсистемой - -

Требования к видам обеспечения (4) - Сервер имеет емкость HDD не менее 500 Гб с возможностью увеличения по необходимости. 4.3.4 Клиентские рабочие места Клиентские рабочие места должны иметь следующую конфигурацию: 1. Процессор Intel Celeron 4900 или выше. 2. Количество ядер процессора: не менее 2. 3. Базовая тактовая частота процессора: не менее 3.10 Ггц. 4. Оперативная память не менее 4 Гб. 5. Жесткий диск 1 Гб свободного места на диске. 6. Операционная система – семейство Windows (Windows 7 и выше). 7. Офисный пакет 32 бит (для работы с отчетами и печатными формами). 8. Для работы межведомственного взаимодействия необходимо: 8.1. Яндекс браузер v.25 и выше, MS EDGE v20, Google Chrome v57 и выше, Opera v44 и выше, Firefox v52 и выше. 8.2. Браузер должен поддерживать HTML5, CSS3, выполнение JavaScript должно быть разрешено - -

Требования к поставке (1) - В рамках поставки Автоматизированной системы управления муниципальной собственностью (АС УМС) для нужд Управление имущественных отношений администрации Минераловодского муниципального округа Ставропольского края, Исполнитель должен Заказчику передать простые (неисключительные) права на условиях простой (неисключительной) лицензии в течение всего срока действия исключительного права на использование Системы в следующем составе: 1. 4 (четыре) клиентских места в режиме полнофункционального доступа, включающие следующие компоненты: 1.1. Подсистема «Имущество». 1.2. Подсистема «Земля». 1.3. Подсистема «Ведение информации по субъектам права». 1.4. Подсистема «Ведение информации по акциям». 1.5. «Адресная подсистема». 1.6. Подсистема «Ведение договоров и дополнительных соглашений» 1.7. Подсистема «Выкуп с рассрочкой». 1.8. «Финансово-аналитическая подсистема». 1.9. Подсистема «Автоматизация претензионной и исковой деятельности». 1.10. Аналитическая и сервисная подсистема «Библиотека запросов». 1.11. Подсистема «Формирование отчетов и печатных форм, генератор отчетов». 1.12. Подсистема «Обеспечение безопасности, администрирования и разграничения прав доступа». 1.13. Подсистема «Ведение нормативно-справочной информации». 1.14. Подсистема «Автоматическое обновление клиентских рабочих мест». 1.15. Подсистема «Оповещение пользователей». 1.16. Подсистема «Самодиагностика с оповещением о выявленных аномалиях по электронной почте» - -

Требования к поставке (2) - 1.17. Средства ведения электронных карточек объектов учета. 1.18. Средства поиска, отображения и анализа информации. 1.19. Средства предварительного просмотра. 1.20. Средства выполнения массовых операций. 2. Подсистема Межведомственное электронное взаимодействие. Платформа СМЭВ». 3. Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП». Клиентское место полного доступа должно обладать полнофункциональными возможностями всех компонентов в составе АС УМС в Управление имущественных отношений администрации Минераловодского муниципального округа Ставропольского края. В случае, если Исполнитель не является правообладателем Системы, то он должен являться официальным партнером Лицензиара (подтверждается заверенной копией партнерского договора участника с Лицензиаром) - -

Требования к результатам оказания услуг (1) - Результатом является поставка автоматизированной системы управления муниципальной собственностью (АС УМС) для Управление имущественных отношений администрации Минераловодского муниципального округа Ставропольского края. Документация должна быть предоставлена Заказчику в период исполнения контракта Исполнителем в одном экземпляре в электронном виде и соответствовать требованиям настоящего технического задания и государственных стандартов. Перечень подлежащих разработке Исполнителем видов и комплектов документов: 1. Руководство пользователя Системы. 2. Программа и методика испытаний. 3. Лицензионный договор на использование программного обеспечения на праве простой неисключительной лицензии. 4. Акт приема-передачи неисключительных прав на использование Системы в следующем составе: 1. 4 (четыре) клиентских места в режиме полнофункционального доступа, включающие следующие компоненты: 1.1. Подсистема «Имущество». 1.2. Подсистема «Земля». 1.3. Подсистема «Ведение информации по субъектам права». 1.4. Подсистема «Ведение информации по акциям». 1.5. «Адресная подсистема». 1.6. Подсистема «Ведение договоров и дополнительных соглашений» 1.7. Подсистема «Выкуп с рассрочкой» - -

Требования к результатам оказания услуг (2) - 1.8. «Финансово-аналитическая подсистема». 1.9. Подсистема «Автоматизация претензионной и исковой деятельности». 1.10. Аналитическая и сервисная подсистема «Библиотека запросов». 1.11. Подсистема «Формирование отчетов и печатных форм, генератор отчетов». 1.12. Подсистема «Обеспечение безопасности, администрирования и разграничения прав доступа». 1.13. Подсистема «Ведение нормативно-справочной информации». 1.14. Подсистема «Автоматическое обновление клиентских рабочих мест». 1.15. Подсистема «Оповещение пользователей». 1.16. Подсистема «Самодиагностика с оповещением о выявленных аномалиях по электронной почте». 1.17. Средства ведения электронных карточек объектов учета. 1.18. Средства поиска, отображения и анализа информации. 1.19. Средства предварительного просмотра. 1.20. Средства выполнения массовых операций. 2. Подсистема Межведомственное электронное взаимодействие. Платформа СМЭВ». 3. Подсистема «Межведомственное электронное взаимодействие с ГИС ГМП» - -

- Обоснование включения дополнительной информации в сведения о товаре, работе, услуге Дополнительная информация указана в соответствии с положениями статьи 33 Федерального закона № 44-ФЗ, включена в связи с отсутствием в каталоге товаров, работ, услуг технических и функциональных характеристик, детализирующих описание объекта закупки.

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

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

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

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

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

Начальная (максимальная) цена контракта: 1 665 150,00

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

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

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

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

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

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

Наименование бюджета: бюджет Минераловодского муниципального округа Ставропольского края

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

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

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

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

Порядок внесения денежных средств в качестве обеспечения заявки на участие в закупке, а также условия гарантии: Порядок внесения денежных средств в качестве обеспечения заявки на участие в закупке установлен в соответствии с частью 5 статьи 44 Федерального закона № 44-ФЗ. В случае, если обеспечение заявки на участие в закупке предоставляется в виде независимой гарантии, ее условия должны соответствовать положениям статьи 45 Федерального закона № 44-ФЗ, включая дополнительные требования, утвержденные постановлением Правительства Российской Федерации № 1005 от 08.11.2013 «О независимых гарантиях, используемых для целей Федерального закона «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд»». Такая независимая гарантия в обязательном порядке должна соответствовать типовой форме утвержденной постановлением Правительства Российской Федерации № 1005 от 08.11.2013 «О независимых гарантиях, используемых для целей Федерального закона «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд»». Для участников, являющихся иностранными лицами, обеспечение заявок в виде денежных средств предоставляется с учетом особенностей, предусмотренных постановлением Правительства Российской Федерации от 10 апреля 2023 г. № 579 «Об особенностях порядка предоставления обеспечения заявок на участие в закупках товаров, работ, услуг для обеспечения государственных или муниципальных нужд участниками таких закупок, являющимися иностранными лицами.

Реквизиты счета для учета операций со средствами, поступающими заказчику: p/c 03232643075390002100, л/c 05213D29800, БИК 010702101

Реквизиты счета для перечисления денежных средств в случае, предусмотренном ч.13 ст. 44 Закона № 44-ФЗ (в соответствующий бюджет бюджетной системы Российской Федерации): Получатель Номер единого казначейского счета Номер казначейского счета БИК ТОФК УПРАВЛЕНИЕ ФЕДЕРАЛЬНОГО КАЗНАЧЕЙСТВА ПО СТАВРОПОЛЬСКОМУ КРАЮ (УПРАВЛЕНИЕ ИМУЩЕСТВЕННЫХ ОТНОШЕНИЙ АДМИНИСТРАЦИИ МИНЕРАЛОВОДСКОГО МУНИЦИПАЛЬНОГО ОКРУГА) ИНН: 2630046625 КПП: 263001001 КБК: 70211610061140000140 ОКТМО: 07539000001 40102810345370000013 03100643000000012100 010702101

Место поставки товара, выполнения работы или оказания услуги: Российская Федерация, край Ставропольский, м.о. Минераловодский, г Минеральные Воды, ул 50 лет Октября, зд. 87А, или удаленно средствами информационно-телекоммуникационных технологий с соблюдением требований безопасности информации

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

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

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

Порядок предоставления обеспечения исполнения контракта, требования к обеспечению: Порядок предоставления обеспечения исполнения контракта установлен в соответствии со статьей 96 Федерального закона № 44-ФЗ В случае, если обеспечение будет предоставляться в виде независимой гарантии, ее условия должны соответствовать положениям статьи 45 Федерального закона № 44-ФЗ, включая дополнительные требования, утвержденные постановлением Правительства Российской Федерации № 1005 от 08.11.2013 «О независимых гарантиях, используемых для целей Федерального закона «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». Такая независимая гарантия в обязательном порядке должна соответствовать типовой форме, утвержденной постановлением Правительства Российской Федерации № 1005 от 08.11.2013 «О независимых гарантиях, используемых для целей Федерального закона «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд».

Платежные реквизиты для обеспечения исполнения контракта: p/c 03232643075390002100, л/c 05213D29800, БИК 010702101, ОКЦ № 2 ЮГУ Банка России//УФК по Ставропольскому краю, г Ставрополь, к/c 40102810345370000013

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

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

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

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

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

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

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

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

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

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

Наименование бюджета: бюджет Минераловодского муниципального округа Ставропольского края

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

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

Документы

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

Документы

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