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

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

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

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

Наименование электронной площадки в информационно-телекоммуникационной сети «Интернет»: РОСЭЛТОРГ (АО«ЕЭТП»)

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

Размещение осуществляет: Уполномоченное учреждение ГОСУДАРСТВЕННОЕ КАЗЕННОЕ УЧРЕЖДЕНИЕ "ЦЕНТР ГОСУДАРСТВЕННЫХ ЗАКУПОК САХАЛИНСКОЙ ОБЛАСТИ"

Наименование объекта закупки: Оказание услуг по развитию подсистемы отбора получателей субсидий и подсистемы ведения соглашений (договоров) в части интеграции с иными подсистемами государственной информационной системы Сахалинской области «Автоматизированная система управления бюджетным процессом Сахалинской области» и внешними информационными системами

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

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

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

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

Организация, осуществляющая размещение: ГОСУДАРСТВЕННОЕ КАЗЕННОЕ УЧРЕЖДЕНИЕ "ЦЕНТР ГОСУДАРСТВЕННЫХ ЗАКУПОК САХАЛИНСКОЙ ОБЛАСТИ"

Почтовый адрес: Российская Федерация, 693007, Сахалинская обл, Южно-Сахалинск г, УЛ КОМСОМОЛЬСКАЯ, Д. 192Б

Место нахождения: Российская Федерация, 693007, Сахалинская обл, Южно-Сахалинск г, УЛ КОМСОМОЛЬСКАЯ, Д. 192Б

Ответственное должностное лицо: Хижнякова Е. В.

Адрес электронной почты: e.hizhnyakova@sakhalin.gov.ru

Номер контактного телефона: 8-4242-459076

Факс: 7-4242-459070

Дополнительная информация: Информация отсутствует

Регион: Сахалинская обл

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

Дата и время начала срока подачи заявок: 28.10.2026 14:30 (МСК+8)

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

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

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

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

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

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

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

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

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

- 62.01.11.000 - Услуги по проектированию и разработке информационных технологий для прикладных задач и тестированию программного обеспечения Количество обрабатываемых документов в день ? 10000 Количество одновременно работающих пользователей ? 1000 Количество обрабатываемых запросов во внешние системы и подсистемы ГИС АСУБП в день ? 1000 - Условная единица - 1,00 - 20 000 000,00 - 20 000 000,00

МИНИСТЕРСТВО ФИНАНСОВ САХАЛИНСКОЙ ОБЛАСТИ - 1 -

- Наименование характеристики Значение характеристики Единица измерения характеристики Инструкция по заполнению характеристик в заявке Количество обрабатываемых документов в день ? 10000 Штука Значение характеристики не может изменяться участником закупки Количество одновременно работающих пользователей ? 1000 Значение характеристики не может изменяться участником закупки Количество обрабатываемых запросов во внешние системы и подсистемы ГИС АСУБП в день ? 1000 Штука Значение характеристики не может изменяться участником закупки Время реакции Подсистемы при штатной нагрузке < 8 Секунда Значение характеристики не может изменяться участником закупки Время реакции Подсистемы при пиковой нагрузке < 30 Секунда Значение характеристики не может изменяться участником закупки Максимальное время ожидания ответа при получении данных от внешних систем и подсистем ГИС АСУБП ? 300 Секунда Значение характеристики не может изменяться участником закупки Программное обеспечение должно быть масштабируемо для обеспечения показателей назначения при увеличении объема данных и числа пользователей Да Значение характеристики не может изменяться участником закупки Требования к функциям подсистемы ведения соглашений (договоров) Обеспечение ведения следующих функциональных подразделов: ­ реестр типов соглашений (договоров); ­ реестр типовых форм соглашений (договоров); ­ реестр шаблонов соглашений (договоров); ­ реестр соглашений (договоров). ­ реестр типов отчетов; ­ реестр шаблонов отчетов; ­ реестр отчетов Значение характеристики не может изменяться участником закупки Требования к функциональности реестра типов соглашений (договоров) Обеспечение возможности формирования и ведения перечня типов соглашений (договоров) с указанием по ним следующих данных: - наименование типа; - перечень сторон соглашения (договора) с возможностью настройки указания платежных реквизитов по ним; - признак формирования соглашения в соответствии с требованиями порядка ведения реестра соглашений (договоров) о предоставлении из бюджетов бюджетной системы РФ субсидий и бюджетных инвестиций юридическим лицам, индивидуальным предпринимателям, физическим лицам – производителям товаров, работ, услуг и межбюджетных трансфертов бюджетам бюджетной системы РФ, предусмотренного абз. 14 п. 1 ст. 166.1 БК РФ; признак указания в соглашении (договоре) сведений о капитальных вложениях; признак указания в соглашении (договоре) сведений о результатах предоставления бюджетных средств. Значение характеристики не может изменяться участником закупки Требования к функциональности реестра типовых форм соглашений (договоров) Обеспечение возможности формирования, применения и ведения типовых форм соглашений (договоров) с указанием по ним следующих данных: ­ наименование типовой формы; ­ тип соглашения (договора); ­ наименование и количество сторон соглашения (договора) Значение характеристики не может изменяться участником закупки Требования к функциональности реестра шаблонов соглашений (договоров) Обеспечение возможности формирования шаблона соглашения (договора) путем копирования другого доступного шаблона. Значение характеристики не может изменяться участником закупки Обеспечение по каждому шаблону соглашения (договора) возможности настройки доступа в виде перечня пользователей и учреждений, сотрудникам которых будет доступен данный шаблон соглашения (договора), а также указания режима доступа: на чтение, на редактирование. Обеспечение возможности формирования и ведения шаблонов соглашений (договоров) с указанием по ним следующих данных: - наименование шаблона соглашения (договора); - пользовательского номера шаблона соглашения (договора); - тип соглашения (договора); - форма соглашения (договора); - текстовая часть соглашения (договора); - приложения к соглашению (договору). При заполнении текстовой части соглашения (договора) должно быть обеспечено: - возможность указания наименования; - форма редактирования текста соглашения (договора) с возможностью: - установления ограничений на изменение и (или) удаление пунктов; -возможность установления ограничения на изменение части текста в закрытых для изменения пунктах; - возможность добавления функций, возвращающих автоматически вычисленное значение; - возможность загрузки пользовательских файлов с расширением .pdf; - возможность изменять очередность вывода документа на печать. Требования к функциям ведения реестра соглашений (договоров) Обеспечение возможности формирования и ведения электронного документа соглашения (договора) со следующими разделами: - основные сведения; - стороны; - текстовая часть; - приложения к соглашению (договору). Дополнительно в соглашении (договоре) могут быть указаны следующие сведения: - нормативно-правовые акты (НПА); - коды бюджетной классификации (КБК); - объекты капитального строительства (ОКС); - график выполнения мероприятий; - результаты; - объемы ФО; - документы; - контракты. Значение характеристики не может изменяться участником закупки Раздел «Основные сведения» соглашения (договора) включают следующие реквизиты: - системный номер; - пользовательский номер; - форма; - дата создания; - дата заключения (при наличии). В разделе «Стороны» по каждой из сторон соглашения (договора) должны быть указаны реквизиты и уполномоченное на подписание документа лицо. В разделе «НПА» должны быть указаны сведения о нормативном правовом акте, в соответствии с которым заключено соглашение (договор) о предоставлении бюджетных средств (при наличии). В разделе «КБК» должна быть указана информация о коде классификации расходов бюджета, по которому предусмотрены лимиты бюджетных обязательств на предоставление бюджетных средств (при наличии). В разделе «ОКС» должны быть указаны сведения об объектах капитального строительства, недвижимого имущества. В разделе «График выполнения мероприятий по ОКС» должны быть указаны сведения о графике выполнения мероприятий по проектированию и (или) строительству (реконструкции, в том числе с элементами реставрации, техническому перевооружению) объектов капитального строительства. В разделе «Результаты» должны быть указаны сведения о результатах использования средств, контрольных точках. В разделе «Объемы ФО» должна быть указана информация об объемах субсидии, бюджетных инвестиций, межбюджетного трансферта (при наличии). Обеспечение следующих возможностей: формирование печатной формы документа в одном из следующих форматов: DOC, DOCX, PDF; формирование документа путем копирования другого документа; обеспечение процессов формирования листов согласования для сторон соглашений (договоров); обеспечение процессов рассмотрения сторонами соглашений (договоров); обеспечение процессов подписания сторонами соглашений (договоров); согласования и утверждения соглашений (договоров) с механизмом подписания УКЭП уполномоченного лица. Должна обеспечиваться проверка действительности сертификата УКЭП уполномоченного лица на момент подписания соглашения (договора); формирование новой версии документа в случае наложения отрицательной резолюции; внесение изменений в соглашение (договор) путем формирования дополнительного соглашения (договора) к соглашению (договору). Требования к функциям ведения реестра типов отчетов Обеспечение возможности ведения реестра типов отчетов, который должен обеспечивать пользователя возможностями формирования и согласования отчетов. Документом основанием для формирования отчета должно являться соглашение (договор). Должны учитываться сведения: - наименование типа; - признак формирования отчета в соответствии с требованиями порядка ведения реестра соглашений (договоров) о предоставлении из бюджетов бюджетной системы РФ субсидий и бюджетных инвестиций юридическим лицам, индивидуальным предпринимателям, физическим лицам – производителям товаров, работ, услуг и межбюджетных трансфертов бюджетам бюджетной системы РФ, предусмотренного абз. 14 п. 1 ст. 166.1 БК РФ. Значение характеристики не может изменяться участником закупки Требования к функциям ведения реестра шаблонов отчетов Обеспечение возможности формирования шаблона отчета путем копирования другого доступного шаблона. Значение характеристики не может изменяться участником закупки Обеспечение возможности ведения реестра шаблонов отчетов, обеспечивающая формирование, редактирование и использование шаблонов отчета. Шаблон отчета должен содержать следующие параметры: - наименование шаблона отчета; - наименование отчета; - тип отчета; - типовая форма отчета; - типовая форма соглашения (договора); - формат даты, на которую формируется отчет; - отчетный период шаблона отчета. Требования к функциям ведения реестра отчетов Обеспечение возможности ведения реестра отчетов, содержащего: - общие сведения. Дополнительно в отчете могут быть указаны следующие сведения: - информация о достижении значений результатов; - сведения о принятии отчета; - сведения о выплатах, источником финансового обеспечения которых являются средства Субсидии; - сведения об обязательствах, источником финансового обеспечения которых являются средства Субсидии; - сведения о средствах, размещаемых на депозитах и полученных доходах; - сведения о расходах на организацию предоставления средств государственной поддержки; - достижение целевых показателей; - реализация плана мероприятий по достижению результатов. Значение характеристики не может изменяться участником закупки Раздел «Общие сведения» отчета должен включать следующие реквизиты: - системный номер; - номер соглашения; - номер редакции соглашения; - дата создания; - дата, на которую формируется отчет; - тип отчета; - наименование отчета; - шаблон отчета; - данные предоставителя отчета; - данные получателя отчета. В разделе «Информация о достижении значений результатов» во вкладке «Финансовое обеспечение» по каждому направлению расходов должны быть указаны объемы обязательства, принятых в целях достижения результатов предоставления субсидии, грантов. Во вкладке «Значения результатов» по каждому результату и показателю результата должны быть указаны фактические значения. В разделе «Сведения о принятии отчета» должна быть указана информация о кодах бюджетной классификации расходов, информация о КОСГУ и информация о суммах с начала заключения соглашения и с начала текущего финансового года. В разделе «Сведения о выплатах, источником финансового обеспечения которых являются средства Субсидии» по каждой строке показателя должна быть указана информация о фактических суммах и причина отклонения (при наличии). В разделе «Сведения о средствах, размещаемых на депозитах и полученных доходах» по каждой строке показателя должна быть указана информация о фактических суммах и причина отклонения (при наличии). В разделе «Сведения о расходах на организацию предоставления средств государственной поддержки» по каждой строке показателя должна быть указана информация о фактических суммах и причина отклонения (при наличии). В разделе «Сведения об обязательствах, источником финансового обеспечения которых являются средства Субсидии» по каждой строке показателя должна быть указана информация о фактических суммах и причина отклонения (при наличии). В разделе «Реализация плана мероприятий по достижению результатов» должны быть указаны сведения о фактических или прогнозных сроках достижения результата предоставления субсидии или контрольной точки, сведения о фактических значениях результата предоставления субсидии или контрольной точки. В разделе «Достижения целевых показателей» должны быть указаны сведения о достигнутых значениях показателя по состоянию на отчетную дату. Обеспечение следующих возможностей: - формирование печатной формы документа в одном из следующих форматов: DOC, DOCX, PDF; - формирование документа путем копирования другого документа; - обеспечение процессов формирования листов согласования для сторон отчетов; - обеспечение процессов рассмотрения сторонами отчетов; - обеспечение процессов подписания сторонами отчетов; - согласования и утверждения отчетов с механизмом подписания УКЭП уполномоченного лица. Должна обеспечиваться проверка действительности сертификата УКЭП уполномоченного лица на момент подписания отчета; - формирование новой версии документа в случае наложения отрицательной резолюции; - внесение изменений в отчет путем формирования уточнения к отчету. Требования к способам и средствам связи для информационного обмена между компонентами ГИС АСУБП Взаимодействие подсистемы отбора получателей субсидий с подсистемой ведения соглашений (договоров) Взаимодействие с подсистемой «НСИ» Взаимодействие подсистемы отбора получателей субсидий с подсистемой проектирования бюджета Сахалинской области Значение характеристики не может изменяться участником закупки Общие требования к взаимодействию внутри ГИС АСУБП - обеспечить взаимодействие подсистемы отбора получателей субсидий подсистемы ведения соглашений (договоров) (далее при совместном упоминании – Подсистемы) с подсистемой НСИ для получения данных об организациях; - обеспечить двусторонний обмен данными между подсистемой отбора получателей субсидий и подсистемой ведения соглашений (договоров): не только передачу информации о победителях отбора для заключения соглашения, но и получение данных о статусе заключения, исполнения и расторжения соглашений; - обеспечить взаимодействие подсистемы отбора получателей субсидий с подсистемой проектирования бюджета для получения информации о бюджетных ассигнованиях и лимитах бюджетных обязательств, а также загрузки необходимой справочной информации; - реализовать механизм автоматического обновления информации о соглашениях в подсистеме отбора получателей субсидий; - предусмотреть возможность ручного ввода данных в случае отсутствия интеграции. Значение характеристики не может изменяться участником закупки Требования к взаимодействию подсистемы отбора получателей субсидий с подсистемой ведения соглашений (договоров) Взаимодействие подсистемы отбора получателей субсидий с подсистемой ведения соглашений (договоров) должно осуществляться в части передач данных, необходимых для инициации процесса заключения соглашения между главным распорядителем бюджетных средств и победителями отбора, и получения информации о результатах подписания соглашения (договора). Подсистема отбора получателей субсидий должна обеспечить выполнение следующих функций: - после утверждения субсидии формируется первый пакет данных для отправки в подсистему ведения соглашений (договоров). Состав данных должен содержать необходимую для передачи информацию о субсидии и результатах, которые в нее включены; - после завершения отбора и выявления победителей формируется второй пакет данных для отправки в подсистему ведения соглашений (договоров). Состав данных должен содержать необходимую для передачи информацию об отборе, выявленных победителях и суммах по соответствующим КБК; - после заключения соглашения (договора), начиная с момента наступления срока, установленного в отборе, получать сведения о заключенных по результатам отбора соглашениях (договорах). Полученные сведения должны отображаться в соответствующем разделе субсидии. В случае если сведения о заключенном соглашении (договоре) не поступили в установленный срок, победитель считается уклонившимся от заключения соглашения (договора). Условия запуска процессов отправки и получения данных, а также ожидаемые результаты описаны в Таблице 2 Технического задания (приложения к описанию объекта закупки). При внесении изменений в субсидию, создании и утверждении новой версии документа подсистема отбора получателей субсидий должна направлять новые данные в подсистему ведения соглашений (договоров). Значение характеристики не может изменяться участником закупки Требования к взаимодействию с подсистемой «НСИ Взаимодействие Подсистем с подсистемой «НСИ» должно осуществляться в части получения данных по организациям для формирования и обновления справочника «Учреждения» Подсистем. Условия запуска процессов отправки и получения данных, а также ожидаемые результаты описаны в Таблице 3 Технического задания (приложения к описанию объекта закупки). При наличии расхождения данных для записей с одинаковым идентификатором должна формироваться новая версия записи справочника. Действующей будет считаться последняя версия документа. Значение характеристики не может изменяться участником закупки Требования к взаимодействию подсистемы отбора получателей субсидий с подсистемой проектирования бюджета Сахалинской области Взаимодействие подсистемы отбора получателей субсидий с подсистемой проектирования бюджета должно осуществляться в трех направлениях: загрузка данных по БА и ЛБО соответствующих КБК на этапе формирования субсидии в раздел «Финансовое обеспечение» карточки субсидии. Утверждение и публикация субсидии невозможны пока не будут получены данные о лимитах бюджетных обязательств; в случае если данная настройка включена в подсистеме администратором, выгрузка из подсистемы отбора получателей субсидий данных по принимаемым бюджетным обязательствам, после утверждения объявления об отборе, с целью резервирования денежных средств, если отбор был отменен, то зарезервированная сумма должна высвобождаться автоматически после утверждения объявления об отмене отбора; загрузка информации по справочникам в подсистему отбора получателей субсидий. Условия запуска процессов отправки и получения данных, а также ожидаемые результаты описаны в Таблице 4 Технического задания (приложения к описанию объекта закупки). При внесении изменений в БА и ЛБО, должна автоматически создаваться новая версия соответствующей субсидии, версия создается подконтрольно со стороны пользователей системы, подсистема отбора получателей субсидий должна обеспечивать информирование пользователя я о появлении новых данных по соответствующим кодам расходов бюджета. Обновление информации должно осуществляться автоматически в соответствии с периодичностью, заданной в планировщике задач. При наличии расхождения данных по загружаемым справочникам для записей с одинаковым идентификатором должна формироваться новая версия записи справочника. Действующей будет считаться последняя версия документа. Значение характеристики не может изменяться участником закупки Требования к взаимодействию с внешними информационными системами Взаимодействие с ГИИС «Электронный бюджет» Взаимодействие с открытыми данными Центрального банка России Взаимодействие подсистемы отбора получателей субсидий с СМЭВ Взаимодействие подсистемы отбора получателей субсидий с открытыми данными ФНС Взаимодействие подсистемы отбора получателей субсидий с Федеральной службой по финансовому мониторингу (Росфинмониторинг) Взаимодействие подсистемы отбора получателей субсидий с открытыми данными Федерального казначейства (ФК) Реализация процесса автоматической проверки заявок участников на соответствие требованиям объявления об отборе Значение характеристики не может изменяться участником закупки Требования к взаимодействию с ГИИС «Электронный бюджет» Взаимодействие с ГИИС «Электронный бюджет» должно осуществляться в части получения открытых данных для наполнения справочников Подсистем. Условия запуска процессов получения данных, а также ожидаемые результаты описаны в Таблице 5 Технического задания (приложения к описанию объекта закупки). При выявлении расхождений в данных для записей с одинаковым идентификатором должна формироваться новая версия записи справочника. Действующей считаться последняя актуальная версия записи. Значение характеристики не может изменяться участником закупки Требования к взаимодействию с открытыми данными Центрального банка России Взаимодействие должно осуществляться в части загрузки открытой информации о зарегистрированных на территории РФ кредитных организациях для наполнения справочника Подсистемы «Банки». Условия запуска процессов получения данных, а также ожидаемые результаты описаны в Таблице 6 Технического задания (приложения к описанию объекта закупки). Обновление информации должно осуществляться автоматически в соответствии с периодичностью, заданной в планировщике задач. При наличии расхождения данных для записей с одинаковым идентификатором должна формировать новая версия записи справочника. Действующей будет считаться последняя версия документа. Значение характеристики не может изменяться участником закупки Требования к взаимодействию подсистемы отбора получателей субсидий с СМЭВ Взаимодействие должно осуществляться в части получения данных, необходимых для реализации автоматических проверок на соответствие участника отбора следующим требованиям: а) участник отбора получателей субсидий не должен являться иностранным агентом в соответствии с Федеральным законом «О контроле за деятельностью лиц, находящихся под иностранным влиянием»; б) деятельность не приостановлена в порядке, предусмотренном законодательством Российской Федерации. Проверки должны осуществляться по алгоритму, описанному в Требованиях к взаимодействию подсистемы отбора получателей субсидий с Федеральной службой по финансовому мониторингу (Росфинмониторинг). Для получения сведений из СМЭВ необходимо обеспечить подключение к следующим видам сведений: а) сведения из реестра иностранных агентов; б) сведения об исполнительных производствах об административном приостановлении деятельности юридических лиц и индивидуальных предпринимателей. Источник данных для осуществления проверки и ожидаемые результаты описаны в Таблице 7 Технического задания (приложения к описанию объекта закупки). Значение характеристики не может изменяться участником закупки Требования к взаимодействию подсистемы отбора получателей субсидий с открытыми данными ФНС Взаимодействие должно осуществляться в части получения сведений для реализации автоматических проверок на соответствие участника отбора требованию: - участник отбора получателей субсидий, являющийся юридическим лицом, не должен находиться в процессе реорганизации (за исключением реорганизации в форме присоединения к юридическому лицу, являющемуся участником отбора получателей субсидий, другого юридического лица), ликвидации, в отношении него не введена процедура банкротства, деятельность получателя субсидии не должна быть приостановлена в порядке, предусмотренном законодательством Российской Федерации, а получатель субсидии, являющийся индивидуальным предпринимателем, не должен прекратить деятельность в качестве индивидуального предпринимателя. Значение характеристики не может изменяться участником закупки Взаимодействие должно осуществляться в части получения сведений для реализации автоматических проверок на соответствие участника отбора требованию: - в реестре дисквалифицированных лиц должны отсутствовать сведения о дисквалифицированных руководителе, членах коллегиального исполнительного органа, лице, исполняющем функции единоличного исполнительного органа, или главном бухгалтере получателя субсидии, являющегося юридическим лицом, об индивидуальном предпринимателе и о физическом лице - производителе товаров, работ, услуг, являющихся участниками отбора получателей субсидий; Взаимодействие должно осуществляться в части получения сведений для реализации автоматических проверок на соответствие участника отбора требованию: - участник отбора получателей субсидий не должен являться иностранным юридическим лицом, в том числе местом регистрации которого является государство или территория, включенные в утверждаемый Министерством финансов Российской Федерации перечень государств и территорий, используемых для промежуточного (офшорного) владения активами в Российской Федерации (далее - офшорные компании), а также российским юридическим лицом, в уставном (складочном) капитале которого доля прямого или косвенного (через третьих лиц) участия офшорных компаний в совокупности превышает 25 процентов (если иное не установлено законодательством Российской Федерации). При расчете доли участия офшорных компаний в уставном (складочном) капитале российских юридических лиц не учитываются прямое и (или) косвенное участие офшорных компаний в капитале публичных акционерных обществ (в том числе со статусом международной компании), акции которых обращаются на организованных торгах в Российской Федерации, а также косвенное участие таких офшорных компаний в капитале других российских юридических лиц, реализованное через участие в капитале указанных публичных акционерных обществ; Взаимодействие должно осуществляться в части получения сведений для реализации автоматических проверок на соответствие участника отбора следующим требованию: - у участника отбора получателей субсидий на едином налоговом счете должна отсутствовать или не превышать размер, определенный пунктом 3 статьи 47 Налогового кодекса Российской Федерации, задолженность по уплате налогов, сборов и страховых взносов в бюджеты бюджетной системы Российской Федерации. Проверки должны выполняться по алгоритму, описанному в разделе Требования к взаимодействию подсистемы отбора получателей субсидий с Федеральной службой по финансовому мониторингу (Росфинмониторинг). По требованию «участник отбора получателей субсидий, являющийся юридическим лицом, не должен находиться в процессе реорганизации (за исключением реорганизации в форме присоединения к юридическому лицу, являющемуся участником отбора получателей субсидий, другого юридического лица), ликвидации, в отношении него не введена процедура банкротства, деятельность получателя субсидии не должна быть приостановлена в порядке, предусмотренном законодательством Российской Федерации, а получатель субсидии, являющийся индивидуальным предпринимателем, не должен прекратить деятельность в качестве индивидуального предпринимателя» проверки должны осуществляться путем получения выписки о состоянии участника из открытых данных реестров ЕГРЮЛ / ЕГРИП в зависимости от типа субъекта экономической деятельности. Данное требование для успешной проверки необходимо разбить на четыре отдельных самостоятельных требования, которые будут добавляться автоматически в субсидию в зависимости от указанных типов субъектов экономической деятельности: юридическое лицо не проходит процедуру ликвидации; юридическое лицо не находится в процессе реорганизации; не введена процедура банкротства; деятельность не приостановлена в порядке, предусмотренном законодательством Российской Федерации (проверка осуществляется через СМЭВ, см. раздел Требования к взаимодействию подсистемы отбора получателей субсидий с СМЭВ). Заказчик должен быть зарегистрирован на ФНС ВПД (иметь личный кабинет с доступом к сервисам, перечисленным в Таблице 7 Технического задания (приложения к описанию объекта закупки), для успешного осуществления автопроверки участников. Источник данных для осуществления проверки и ожидаемые результаты описаны в Таблице 8 Технического задания (приложения к описанию объекта закупки). Требования к взаимодействию подсистемы отбора получателей субсидий с Федеральной службой по финансовому мониторингу (Росфинмониторинг) Взаимодействие будет осуществляться в части получения данных, необходимых для реализации автоматической проверки на соответствие участника отбора требованию об отсутствии в перечне организаций и физических лиц, в отношении которых имеются сведения об их причастности к экстремистской деятельности или терроризму. Для получения файла с данными о физических лицах и организациях, входящих в перечень, необходимо пройти регистрацию в личном кабинете Росфинмониторинга. Проверка должна выполняться по алгоритму, описанному в указанных Требованиях. Источник данных для осуществления проверки и ожидаемые результаты описаны в Таблице 9 Технического задания (приложения к описанию объекта закупки). Значение характеристики не может изменяться участником закупки Требования к взаимодействию подсистемы отбора получателей субсидий с открытыми данными Федерального казначейства (ФК) Взаимодействие будет осуществляться в части получения данных, необходимых для реализации автоматической проверки на отсутствие участника в реестре недобросовестных поставщиков (подрядчиков, исполнителей) по данным https://zakupki.gov.ru. Для получения файла с данными о организациях и индивидуальных предпринимателях, внесенных в реестр, необходимо пройти регистрацию в личном кабинете на сайте Единой информационной системы (ЕИС), https://zakupki.gov.ru. Проверка должна выполняться по алгоритму, описанному в разделе Требования к взаимодействию подсистемы отбора получателей субсидий с Федеральной службой по финансовому мониторингу (Росфинмониторинг). Источник данных для осуществления проверки и ожидаемые результаты описаны в Таблице 10 Технического задания (приложения к описанию объекта закупки). Значение характеристики не может изменяться участником закупки Требования к реализации процесса автоматической проверки заявок участников на соответствие требованиям объявления об отборе Потенциальный участник регистрируется в системе, после регистрации он должен иметь возможность подать заявку на участие в отборе или заявку на предоставление субсидии в качестве прямого получателя, если субсидия распределяется без отбора. Заявка должна содержать все необходимые данные об участнике, в зависимости от того к какому типу субъекта экономической деятельности он относится. В заявке участник должен иметь возможность подтвердить свое соответствие требованиям отбора (Таблица 11 Технического задания (приложения к описанию объекта закупки). Значение характеристики не может изменяться участником закупки При наступлении этапа рассмотрения заявок пользователь, выполняющий роль Валидатора, должен еще раз вручную запустить процесс автоматической проверки участников на соответствие требованиям. Если после автоматической проверки участник не соответствует, хотя бы одному требованию, то заявка такого участника отклоняется и прекращает участие в отборе. При добавлении участника в качестве прямого получателя субсидии должен запускаться механизм автоматических проверок по данному участнику. Если участник не соответствует хотя бы одному требованию, то при переводе на согласование субсидии нельзя допускать утверждение такого документа. Необходимо отображать дату последнего обновления данных по автоматическим проверкам. Количество автоматических проверок должно зависеть от типа субъекта экономической деятельности (Таблица 11 Технического задания (приложения к описанию объекта закупки) ). Автоматическая проверка участника на соответствие требованиям должна осуществляться: а) при регистрации участника в системе; б) в режиме самопроверки в личном кабинете участника; в) после подписания заявки участником с использованием ЭП; г) при ручном запуске проверки участника на соответствие требованиям пользователем с ролью Валидатор. Запустить проверку вручную можно 1 раз в сутки; д) перед отправкой информации о победителе отбора в подсистему ведения соглашений (договоров) для заключения соглашения; е) при добавлении участника в раздел «Прямые получатели» субсидии для субсидии способом отбора «Не требуется». Список автоматических проверок, которые должен пройти участник в зависимости от типа субъекта экономической деятельности, к которому он относится, должны содержаться в личном кабинете. С отображением статусной модели по проверкам после регистрации пользователя в Подсистеме. Если участник не прошел автоматическую проверку, по одному или нескольким требованиям на этапе подачи заявок, его заявка должна допускаться до следующего этапа отбора. Но при этом необходимо направлять уведомление участнику о том, что он не прошел проверку по тем или иным требованиям и у него есть время на устранение данной ситуации до начала этапа рассмотрения заявок. Предусмотреть статусную модель для каждой автопроверки в Подсистеме, с всплывающими подсказками: - проверка пройдена успешно; - проверка не пройдена; - в процессе; - данные не получены (ошибка при получении данных); - требуется перепроверка на причастность к экстремисткой деятельности и терроризму (отображается у ФЛ и ИП при совпадении записей ФИО с записью в реестре экстремистов, у которой отсутствует ИНН), ручная перепроверка. После завершения отбора и выявления победителей, перед отправкой заявок победителей в подпрограмму ведения соглашений (договоров) автоматически должен запускаться механизм проверок участников на соответствие требованиям. Требования к развитию подсистемы отбора получателей субсидий в части формирования шаблонов форм документов Необходимо развить функциональность подсистемы отбора получателей субсидий в части формирования документов с использованием механизма шаблонов. Для этого нужно расширить компонентный состав подсистемы следующим образом: разработать отдельный реестр «Шаблоны документов», который должен содержать шаблоны для документов двух видов «Объявления об отборах» и «Заявки участников»; внести изменения в операцию по формированию объявления о проведении отбора и заявки участника в части выбора шаблона, который будет являться основой для создаваемого документа; добавить раздел «Текстовая часть» в карточки документов; внести изменения в карточки документов, исключив поля для ввода информации, не влияющей на бизнес-процесс. Значение характеристики не может изменяться участником закупки Требования к реестру шаблонов Реестр шаблонов отображается в личном кабинете ГРБС. Реестр должен иметь следующую функциональность и набор полей: информация из паспорта шаблона: Вид документа, Наименование шаблона, Реестровый номер шаблона, Системный признак, Статус; фильтры; доступные действия пользователей с шаблоном, с учетом их прав (редактировать, печать, удалить, перевести в статус «Готов», просмотр, копировать); карточка шаблона должна включать в себя следующие разделы: Паспорт шаблона, в разрезе данных: Вид документа («объявление о проведении отбора», «заявка участника»), Наименование шаблона, Реестровый номер шаблона, Системный признак, Статус, Автор, Идентификатор ГРБС; Дата изменения, Дата начала действия, Дата окончания действия, Номер версии; Текстовая часть (шаблон формы документа); Приложения (функциональная возможность добавления файлов в формате .pdf). Пользователи с ролью ГРБС видят шаблоны с системным признаком «Типовая форма», а также шаблоны, созданные пользователями самого ГРБС. Доступ к шаблонам, созданным другим ГРБС, должен быть закрыт. В качестве идентификатора ГРБС используется код участника бюджетного процесса по сводному реестру. Поле идентификатор ГРБС для системных шаблонов заполняется пятью нулями. Значение характеристики не может изменяться участником закупки Правами на создание, редактирование и перевод в статус «Готов» шаблонов с системным признаком «Типовая форма» должны обладать только пользователи с ролью Администратор. Пользователь с правами ГРБС при создании шаблона должен выбрать шаблон с системным признаком «Типовая форма», на основе которого он создает свой шаблон. Текстовая часть шаблона должна представлять собой текстовый редактор, содержащий набор функций: - управление шрифтами; - работа со списками и таблицами; - установка абзацных отступов; - редактирование стилей; - выравнивание текста; - навигация по документу; - установка запретов на изменение и (или) удаление части данных или всего текста; - работа в полноэкранном режиме; - добавление картинок в текст документа; - копирование и вставка текстовых данных; - добавление тэгов из заранее заведенного списка стандартных возможных тэгов в систему, с целью отображения актуальной информации из параметров системы в формируемой форме. Неотъемлемой частью шаблона должны быть объекты, предназначенные для последующего наложения оттиска электронных подписей. При копировании шаблона он должен копироваться полностью вместе с текстовой частью. Реестр «Шаблоны документов» должен включать возможность версионирования записей. Требования к формированию объявления о проведении отбора с использованием шаблонов Объявление об отборе должно формироваться на основании типового шаблона (системный признак «типовая форма»). Пользователь с ролью ГРБС должен иметь возможность сформировать отбор, выбрав заготовленную форму из реестра «Шаблоны документов» по виду документа «Объявление о проведении отбора» в статусе «Готов». Сформированный документ будет отображаться в реестре «Отборы» в статусе «Черновик». Карточка документа будет содержать следующие разделы: - «Общие сведения»; - «Требования и документы»; - «Порядок подачи заявок»; - «Порядок рассмотрения заявок»; - «Порядок оценки заявок»; - «Объем и параметры распределения субсидии»; - «Текстовая часть»; - «Приложения»; - «Распределение средств по итогам отбора». Следующие поля должны быть убраны из карточки документа, они будут находиться только в сформированном пользователем шаблоне текстовой части: 1) Раздел «Порядок подачи заявок»: порядок подачи заявок, порядок предоставления разъяснений положений о проведении отбора. 2) Раздел «Порядок рассмотрения заявок»: порядок рассмотрения заявок, порядок отклонения заявок. Значение характеристики не может изменяться участником закупки Текстовая часть из выбранного шаблона должна полностью переноситься в карточку документа в раздел «Текстовая часть». Система должна позволять редактировать текстовую часть под конкретный отбор пользователем, за исключением полей, заполнение которых осуществляется через экранную форму других разделов – такие поля должны быть заблокированы для изменений. Данный раздел должен содержать те же функции и возможности как и раздел карточки шаблона описанный в Требованиях к реестру шаблонов. Печатная форма отбора, которая формируется по итогам создания документа после утверждения должна иметь вид, который был определен в разделе «Текстовая часть» карточки отбора. При создании новой версии отбора, текстовая часть из карточки отбора должна переноситься полностью в том виде в котором она была сформирована в предыдущей версии документа. При копировании отбора текстовая часть из карточки отбора должна переноситься полностью в копию в том виде в котором она была сформирована. Требования к формированию заявки участника с использованием шаблонов Заявка участника должна формироваться на основании типового шаблона (системный признак «типовая форма»). При формировании объявления об отборе, организатор отбора или ГРБС, должны иметь возможность добавить шаблоны заявок в разделе «Порядок подачи заявок» с ограничением по, указанным типам получателей субсидии в отборе. Далее при формировании заявки в карточку заявки участника должен подтягиваться шаблон, с ограничением по шаблонам, добавленным в отбор, на который происходит подача заявки и типу субъекта экономической деятельности участника. Карточка документа будет содержать разделы: «Общие сведения»; «Информация об участнике»; «Календарный план»; «Бюджет»; «Требования к участнику»; «Документы». Следующие разделы и поля должны быть убраны из карточки документа, они будут находиться только в сформированном пользователем шаблоне текстовой части: Раздел «Основная информация»: «О проекте», «Задачи», «Цели». Текстовая часть из шаблона, выбранного ГРБС или организатором отбора, для соответствующего типа субъекта экономической деятельности должна полностью переноситься в карточку документа в раздел «Текстовая часть». Система должна позволять редактировать текстовую часть под конкретного участника пользователем, за исключением полей, заполнение которых осуществляется через экранную форму других разделов – такие поля должны быть заблокированы для изменений. Данный раздел должен содержать те же функции и возможности как и раздел карточки шаблона описанный в Требованиях к реестру шаблонов. Печатная форма заявки участника, которая формируется по итогам создания документа после подписания должна иметь вид, который был определен в разделе «Текстовая часть» карточки заявки участника. Значение характеристики не может изменяться участником закупки Требования к развитию подсистемы отбора получателей субсидий в части рабочего места «Администрирование» Доступ к функциям программного обеспечения подсистемы должен обеспечиваться в соответствии с ролевой моделью. Рабочее место «Администрирование» должно быть доступно для пользователей, зарегистрированных в системе и имеющих роль «Администратор». Администратор должен иметь доступ к функциям, предусмотренным его ролью и уровнем полномочий. Рабочее место «Администрирование» должно обеспечивать выполнение следующих функций: - управление ролями, группами пользователей и правами доступа; - аудит действий пользователей и контроль сессий; - настройка системных уведомлений; - настройка автоматической публикации документов (субсидия, отбор); - настройка адреса публикации документов (субсидия, отбор); - управление и настройка процесса формирования реестровых записей документов (комиссия, субсидия, отбор, протоколы, заявки участников); - настройка бизнес-процессов. Значение характеристики не может изменяться участником закупки Требования к функции «Автоматическая публикация документов» В Подсистеме должна быть предусмотрена настройка, доступная только пользователям с ролью «Администратор». Настройка должна определять режим публикации сведений о субсидиях, отборов и протоколов. Наименование настройки «Автоматическая публикация сведений о субсидиях», «Автоматическая публикация сведений об отборах», «Автоматическая публикация протоколов» – значения, которые может принимать «Да/Нет». Эта настройка должна влиять на поведение системы при изменении значения в поле «Статус публикации» по таким документам как субсидии, отборы и протоколы. Пользователь с ролью «Администратор» должен иметь доступ к интерфейсу настройки параметров публикации. Этот интерфейс должен включать элементы управления для включения/выключения параметров. Параметры публикации заранее должны быть определены Заказчиком по каждому публикуемому документу для корректной настройки процесса. Кроме этого функция должна обеспечивать возможность установления Администратором адреса публикации документов. Адрес публикации должен отображаться автоматически в Подсистеме в соответствии с установленным на рабочем месте Администратора. Значение характеристики не может изменяться участником закупки Требования к функции «Автоматическая отправка данных по принимаемым бюджетным обязательствам в подсистему проектирования бюджета Сахалинской области» В Подсистеме должна быть предусмотрена настройка, доступная только пользователя с ролью «Администратор». Настройка должна определять возможность автоматической отправки данных по принимаемым бюджетным обязательствам после утверждения документа «Объявление об отборе» в подсистему проектирования бюджета ГИС АСУБП, «Автоматическое резервирование/высвобождение принимаемых БО» – значения, которые может принимать «Да/Нет». Эта настройка должна влиять на поведение системы при переходе «Объявления об отборе» в статус «Утвержден» / «Отменен». Если установлено значение «Да», то после перехода «Объявления об отборе» в статус «Утвержден», автоматически информация о финансовом обеспечении объявления об отборе (номер документа, КБК, суммы, года) направляется в систему проектирования бюджета ГИС АСУБП. Или после перехода «Объявления об отборе» в статус «Отменен», автоматически информация о номере документа направляется в систему проектирования бюджета ГИС АСУБП и зарезервированные денежные средства высвобождаются, давая возможность использовать их для проведения других отборов. Значение характеристики не может изменяться участником закупки Требования к функции «Формирование реестровых номеров документов» Функционал по настройке формирования реестровых номеров для следующих документов: 1. Субсидия; 2. Отбор: 3. Комиссия; 4. Код результата; 5. Протокол вскрытия заявок; 6. Протокол рассмотрения заявок; 7 . Итоговый протокол; 8. Заявка участника; 9. Системные уведомления; 10. Шаблоны отборов и заявок участника. Для каждого документа Администратор должен иметь возможность создавать или изменять структуру реестрового номера. По заданной структуре при создании нового документа реестровые номера должны добавляться автоматически. Все элементы, входящие в структуру любого реестрового номера, должны быть заранее определены Заказчиком. При изменении структуры кода реестрового номера любого документа, все новые записи должны формироваться с учетом внесенных изменений в код реестрового номера. Все утвержденные, на момент изменений, записи должны сохранять структуру реестрового номера, которая была на момент утверждения. Значение характеристики не может изменяться участником закупки Механизм формирования реестровых номеров должен обеспечивать: - уникальность номеров, номера не должны повторяться для разных сущностей; - формат номера должен иметь определенную структуру; - неизменность, реестровый номер не должен меняться в процессе существования сущности, при внесении изменений в документ, при создании новых версий документа; - автоматизация, номера должны создаваться автоматически при добавлении новой сущности по правилам, заданным на рабочем месте Администратора в разделе «Формирование реестровых номеров документов»; - целостность реестровых номеров, один номер должен быть привязан к одному документу. Требования к функции «Управление ролями, группами пользователей и правами доступа» Разделы и документы системы в отношении которых может быть осуществлена настройка прав доступа: - Справочники; - Комиссии; - Субсидии; - Отборы; - Протокол вскрытия заявок: - Протокол рассмотрения заявок; - Протокол подведения итогов; - Протоколы; - Заявки участников; - Заявки; - Оценка заявок; - Валидация; - Мои экспертизы; - Распределение средств по итогам отбора; - Шаблоны заявок участников; - Шаблоны отборов; - Запросы на разъяснения; - Уведомления; - Администрирование. Значение характеристики не может изменяться участником закупки Функция управления ролями, группами пользователей и правами доступа должна обеспечивать выполнение следующих возможностей: - создание ролей с возможностью настройки прав доступа; - изменение прав доступа входящих в состав роли; - создание и настройку групп пользователей; - назначение прав доступа группам пользователей; - индивидуальные настройки прав доступа для отдельных пользователей внутри группы. Настройка прав доступа должна обеспечивать возможность разграничения прав на просмотр, создание, редактирование, согласование, утверждение, отмену, удаление, печать и выполнение иных операций в отношении разделов и документов системы. Набор прав доступа должен быть заранее определен Заказчиком. Требования к функции «Аудит действий пользователей и контроль сессий» Аудит действий пользователей должен осуществляться через интерфейс «Журнал действий пользователей», системный журнал контроля сессий. Значение характеристики не может изменяться участником закупки Требования к интерфейсу «Журнал действий пользователей» Интерфейс «Журнал действий пользователей» должен обеспечивать просмотр, поиск и анализ сведений о действиях пользователей в системе, а также просмотр истории обработки документов и событий пользовательских сессий. Интерфейс должен предоставлять возможность: - просмотра перечня записей журнала действий пользователей в табличном виде; - фильтрации записей журнала по пользователю, дате и времени события, типу действия, объекту действия, разделу системы, результату выполнения операции; - поиска записей журнала по идентификатору документа, наименованию документа, учетной записи пользователя и другим ключевым атрибутам; - просмотра подробной информации по каждой записи журнала; - отображения истории действий пользователя за выбранный период; - отображения пошаговой истории операций по выбранному документу с указанием последовательности действий; - просмотра сведений о том, кто, когда и какое действие выполнил; - отображения сведений о входах и выходах пользователей из системы; - отображения сведений об активных сессиях пользователей; - принудительного завершении сессии; - выгрузки данных журнала в файл в формате, определяемом требованиями Заказчика; - сортировки записей журнала по основным реквизитам; - постраничного отображения данных при большом объеме записей; - обновления списка записей журнала без перезагрузки всей страницы. Значение характеристики не может изменяться участником закупки Журнал действий должен содержать сведения, достаточные для анализа пользовательской активности, контроля выполнения операций и разбора спорных ситуаций, включая как минимум: - дату и время события; - учетную запись пользователя; - роль или группу пользователя; - тип и описание действия; - объект действия; - идентификатор связанного документа или записи; - результат выполнения действия; - сведения об инициаторе действия, если действие выполнено системой или от имени другого пользователя; - дополнительные технические сведения, необходимые для трассировки события. Интерфейс должен обеспечивать удобное представление данных для пользователей с правами администратора, аудитора и иных уполномоченных лиц. Доступ к журналу должен осуществляться с любого реестра Подсистемы, чтобы можно было просмотреть действия по каждому определенному документу, при необходимости. Требования к функции контроля сессий Системный журнал должен позволять: - контролировать сессии пользователей в системе; - регистрировать события входа, выхода, неудачных попыток доступа и таймаутов в системном журнале; - принудительно разрывать сессию в случае необходимости; Каждая сессия должна быть жестко привязана к аутентифицированному пользователю, использование общих учетных записей запрещено. Идентификаторы сессий должны быть длинными, случайными и генерироваться заново после успешного входа. Передача только по защищенным каналам. Значение характеристики не может изменяться участником закупки Требования к функции «Анализ и сопровождение документов» Функция анализа и сопровождения документов должна обеспечивать возможность: - выгрузку структуры данных по документам субсидий и отборов с отображением заполненных значений и соответствующих реестров базы данных в текстовый файл; - просмотр связанных с документом объектов в едином интерфейсе без необходимости последовательного перехода по отдельным сущностям; - просмотр журнала изменений по, выбранному документу; - переход к выбранному документу, открытие карточки документа. Указанный функционал, в части выгрузки структуры данных по субсидиям и отборам, должен обеспечивать возможность анализа причин ошибок, проверки полноты формирования документов. Просмотр связанных объектов должен обеспечивать отображение взаимосвязи между сущностями субсидий, отборов, заявок участников и протоколов, формируемых в рамках системы. Функция просмотра связей между объектами должна быть доступна всем группам пользователей при наличии у них соответствующих прав. Функция просмотра связанных с документом объектов, должна обеспечивать возможность открытия журнала действий по выбранному документу. Функция перехода к выбранному документа, должна обеспечивать возможность открытия карточки документа в режиме просмотра. Значение характеристики не может изменяться участником закупки Требования к функции «Настройка системных уведомлений» Функция настройки системных уведомлений должна обеспечивать возможность: - настройка получателей уведомлений; - времени и даты формирования уведомлений, при необходимости; - настройка событий, по которым формируется уведомление, при необходимости; - настройка доступности формирования уведомлений определенным группа пользователей с учетом их прав; - настройка содержания уведомлений. В качестве событий, в рамках которых пользователям могут направляться уведомления, могут быть: - завершение сроков по этапам: - переход отбора/субсидии на определенный этап; - изменение статусов документов; - завершение работы с заявками валидаторов, экспертов, членов комиссии; - информация о заключенном соглашении; - ошибки в системе (для администратора). Пользователь с ролью Администратор, должен иметь возможность сформировать стандартное системное уведомления, без привязки к заранее определенным в настройках событиям. Значение характеристики не может изменяться участником закупки Общие требования к развитию Подсистем Исполнитель может оказать услуги по развитию Подсистем способом разработки ПО в рамках оказания услуг по настоящему Техническому заданию или способом адаптации принадлежащего Подрядчику на законных основаниях ПО при условии соблюдения принципа однократного ввода и многократного использования информации в Подсистемах. При оказании услуг по развитию Подсистем способом разработки ПО в рамках оказания услуг по настоящему Техническому заданию, должен обеспечить его совместимость и взаимодействие с уже функционирующими компонентами развиваемых Подсистем, на базе которых созданы и функционируют развиваемые Подсистемы, для сохранения принципа однократного ввода информации, подлежащей учету, и обеспечения единообразия интерфейса. При оказании услуг по развитию Подсистем способом адаптации ПО Исполнитель может проводить её в том числе путем параметрической настройки, изменения скриптов, конфигурационных файлов, в том числе файлов, учитывающих параметры оборудования Заказчика и необходимых для привязки адаптируемого ПО к оборудованию Заказчика и т.п. Исполнитель должен уведомить Заказчика о выбранном способе оказания услуг в соответствии с требованиями настоящего Технического задания и условиями Контракта в течение 5 (Пяти) рабочих дней с даты заключения Контракта. Значение характеристики не может изменяться участником закупки Требования к защите информации от несанкционированного доступа Требования к защите обрабатываемой информации, предъявляемые законодательством Российской Федерации, иными нормативными правовыми актами органов государственной власти, регулирующих отношения в области защиты информации Идентификация, аутентификация и авторизация пользователей Системы при доступе к защищаемым ресурсам Подсистемы должны поддерживать: - использование внешнего хранилища учетных данных, в том числе в составе компонента управления учетными записями и правами пользователей Системы - ролевую модель разграничения доступа, установленную Заказчиком Подсистемы должны обеспечивать: - возможности подписания документов электронной подписью определенным пользователем в определенном статусе с использованием средств обеспечения юридической значимости документов, должно поддерживаться множественное подписание документов - визуализацию подписываемой пользователем информации непосредственно перед ее подписанием - журналирование пользовательских операций, включая протоколирование пользовательских сессий (факты входа (авторизации) и выхода (закрытие сессии), фиксирование вызовов пользователем того или иного метода программы и фиксация фактов выполнения пользователями каждого изменения значений полей для объектов определенных классов. - завершение сеанса работы пользователя Подсистемы после установленного времени бездействия (неактивности) пользователя или по его запросу - возможность автоматической блокировки учетных записей при подозрительных действиях или многократных неудачных попытках входа Значение характеристики не может изменяться участником закупки Требования к лингвистическому обеспечению Все экранные формы должны быть представлены пользователю на русском языке. Справки и всплывающие подсказки должны быть на русском языке. Сообщения об ошибках, предупреждения и диалоги должны быть на русском языке. Для интерфейсов взаимодействия эксплуатирующего персонала с Подсистемами, используемых при техническом обслуживании программно-аппаратного комплекса Подсистем, а также для системных сообщений, выдаваемых программно-техническими средствами Подсистем, допускается использование английского языка. Значение характеристики не может изменяться участником закупки Требования к программному обеспечению Должна быть обеспечена возможность использования сертифицированных в соответствии с законодательством Российской Федерации средств защиты информации. Программное обеспечение Подсистем должно обеспечивать заданные функциональные требования к Подсистемам, включая достижение заданных показателей назначения. Подсистемы должны позволять осуществлять настройку программных компонентов и дальнейшее развитие их функциональности. Программное обеспечение Подсистем должно быть реализовано в трехзвенной архитектуре на базе веб-технологий. Программное обеспечение Подсистем должно иметь клиент-серверную архитектуру, в следующем минимальном составе: сервер СУБД. сервер приложений; сервер хранения данных; сервер логирования данных; веб-сервер; сервер для резервного копирования данных. Клиентское приложение должно базироваться на использовании Интернет-браузера, включенного в «Единый реестр российских программ для электронных вычислительных машин и баз данных» (https://reestr.minsvyaz.ru/reestr/) и использующего протокол ГОСТ TLS. Вся логика обработки данных должна реализовываться сервером приложений. Для каждого программного компонента Подсистем должны быть разработаны и включены в состав рабочей документации детальные инструкции по его установке и настройке. Значение характеристики не может изменяться участником закупки Требования к техническому обеспечению Информационно-телекоммуникационная инфраструктура Подсистем должна по возможности использовать технологии виртуализации аппаратных ресурсов. Информационно-телекоммуникационная инфраструктура Подсистем должна быть масштабируемой для обеспечения показателей производительности и надежности при росте данных и числа пользователей. Значение характеристики не может изменяться участником закупки Требования к юридической значимости документов Для обеспечения юридической значимости электронных документов должно быть обеспечено: использование усиленной квалифицированной электронной подписи в соответствии с требованиями законодательства Российской Федерации; придание юридической значимости экземплярам электронных документов путем создания электронной подписи, проверки электронной и признания квалифицированной электронной подписи в соответствии с Федеральным законом от 06 апреля 2011 года № 63-ФЗ «Об электронной подписи»; ведение журнала результатов создания электронной подписи (далее – ЭП), проверки ЭП и признания квалифицированной ЭП. Должна обеспечиваться проверка действительности сертификата ЭП на момент подписания электронного документа. При формировании электронных документов и обмене электронными документами в программе должны использоваться усиленные квалифицированные ЭП. Должна обеспечиваться возможность проверки сертификатов на действительность (валидность) посредством использования сертифицированного программно-аппаратного комплекса для построения систем юридически значимого электронного документооборота Крипто Про CSP. Подсистемы должны обеспечивать возможность подписания документов ЭП по ГОСТ Р 34.10-2012. В зависимости от жизненного цикла того или иного документа подписание может быть настроено для изменения статуса документа. Пользователи Системы должны иметь возможность настройки подписания документа штатными средствами без необходимости внесения изменений в программный код Подсистем. Один и тот же документ может подписываться ЭП неограниченное количество раз в соответствии с бизнес-процессом. Значение характеристики не может изменяться участником закупки Требования к режимам функционирования подсистемы В Подсистемах должны быть предусмотрены следующие режимы функционирования: - штатный режим; - режим технического обслуживания; Основным режимом функционирования Подсистем является штатный. В штатном режиме должна обеспечиваться доступность всех сервисов Подсистем. Штатный режим характеризуется доступностью для пользователей Подсистем в соответствии с документированными эксплуатационными характеристиками всех функций Подсистем. Режим технического обслуживания может сопровождаться полной или частичной недоступностью функциональных возможностей Подсистем. Перевод Подсистем из штатного режима в режим технического обслуживания и обратно должен производиться эксплуатирующим персоналом с использованием средств автоматизации. Порядок действий персонала в различных режимах работы Подсистем должен быть описан в руководстве администратора. Значение характеристики не может изменяться участником закупки Требования к обеспечению надежности Подсистемы Программное обеспечение Подсистем должно обладать надежностью, обеспечивающей стабильную работу пользователей. Отказы и сбои в работе серверов, баз данных и сетевого оборудования Подсистем не должны приводить к разрушению данных. Должна быть обеспечена возможность сохранения работоспособности подсистемы в рамках показателей назначения после возникновения следующих аварийных ситуаций: - отказ или сбой в работе одного или нескольких связанных компонентов ИТ-инфраструктуры: сервера, оборудования системы хранения данных, оборудования локальной вычислительной сети; - отказ (сбой) системного или прикладного обеспечения, требующий восстановления ПО и/или перезагрузки серверного оборудования, где установлено данное ПО; - ошибки в работе персонала; - импульсные помехи, сбои или прекращение электропитания. Не должно быть потерь данных при частичном отказе оборудования. Значение характеристики не может изменяться участником закупки Должна поддерживаться кластерная конфигурация серверов приложений и баз данных с целью: - равномерного распределения нагрузки в штатном режиме работы оборудования; - автоматического перераспределения пользовательских сессий между функционирующими узлами кластера при отказе одного или нескольких узлов без отключения пользовательских сессий. Должна обеспечиваться поддержка технологии горизонтального масштабирования на уровне систем управления базами данных и уровне приложений, а именно: возможность использования нескольких экземпляров с целью разнесения по разным серверам при возникновении ситуации, когда используемые экземпляры ПО не справляются с нагрузкой даже при добавлении аппаратных мощностей. Подсистемы должны обеспечивать корректную обработку ошибочных ситуаций в ППО с возможностью дальнейшего продолжения работы без аварийной остановки системного программного обеспечения и аппаратного обеспечения. При авариях и сбоях в системе электропитания после их устранения восстановление работоспособности Подсистем должно обеспечиваться путем автоматической перезагрузки программно-аппаратного комплекса Подсистем и последующего автоматического восстановления всех предоставляемых Подсистемами сервисов. В целях обеспечения надежного функционирования в Подсистемах должны быть предусмотрены: - контроль целостности программного обеспечения Подсистем; - контроль целостности данных на уровне базы данных; - контроль целостности данных, размещаемых в файловой системе; - журналирование операций в объеме, необходимом для обеспечения требуемого уровня надежности. Программное обеспечение должно обеспечивать логирование информации обо всех действиях пользователей (добавление, изменение, удаление и т.п.) в отношении объектов данных программного обеспечения. При этом должны быть зафиксированы как минимум следующие данные: пользователь, дата выполнения операции и ее тип, идентификатор изменяемого объекта. Так же должен быть реализован удобный просмотр логов (например, стек ELK). Требования к эргономике и технической эстетике Экранные формы должны проектироваться с учетом требований унификации: все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; для обозначения одних и тех же операций должны использоваться одинаковые графические значки, кнопки и другие управляющие (навигационные) элементы; должны быть унифицированы термины, используемые для описания идентичных понятий, операций и действий пользователя; реакция программного обеспечения на действия пользователя (наведение указателя «мыши», переключение фокуса, нажатие кнопки) должна быть типовой для каждого действия над одними и теми же графическими элементами, независимо от их расположения на экране. Значение характеристики не может изменяться участником закупки Взаимодействие пользователей с программным обеспечением Подсистем должно осуществляться посредством визуального графического интерфейса. Интерфейс должен быть понятным и удобным, не должен быть перегружен графическими элементами и должен обеспечивать быстрое отображение экранных форм. Навигационные элементы должны быть выполнены в удобной для пользователя форме. Средства редактирования информации должны удовлетворять принятым соглашениям в части использования функциональных клавиш, режимов работы, поиска, использования для приложений многооконных режимов. Ввод-вывод данных в программе, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен соответствовать современным эргономическим требованиям и обеспечивать удобный доступ к основным функциям и операциям программного обеспечения подсистемы. Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление программным обеспечением должно осуществляться с помощью набора экранных меню, кнопок, значков и т.п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и / или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Программное обеспечение Подсистем должно обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях программное обеспечение Подсистем должно выдавать пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных. Требования к архитектуре Архитектура Подсистем должна обеспечивать возможность непрерывного функционирования Подсистем в условиях их развития в соответствии с заданными показателями назначения. С целью повышения утилизации ресурсов и обеспечения заданных показателей назначения балансировка нагрузки в Подсистемах должна обеспечиваться при взаимодействии: - пользователя с веб-серверами; - веб-сервера с серверами приложений; - сервера приложений с серверами баз данных; - на уровне компонентов комплекса технических средств. Архитектура вычислительных платформ Подсистем должна сочетаться с виртуализацией и динамическим перераспределением ресурсов. Значение характеристики не может изменяться участником закупки Требования к архитектуре технических компонентов программного обеспечения Программное обеспечение должно быть разработано с использованием объектно-ориентированных или мультипарадигменных языков программирования. Для реализации и внедрения программного обеспечения Подсистем должен использоваться набор технологических решений, обеспечивающих: - мониторинг и логирование; - непрерывную интеграцию; - хранение и версионирование артефактов; - оркестрацию контейнеров; - контейнеризацию; - высокопроизводительную систему управления базами данных, которая использует структуру данных в памяти; - поддержку брокера сообщений; - балансировку и маршрутизацию запросов; - идентификацию и аутентификацию пользователей; - применение ключей ЭП; - управление версиями исходного кода; - файловое хранилище. Значение характеристики не может изменяться участником закупки - Наименование характеристики - Значение характеристики - Единица измерения характеристики - Инструкция по заполнению характеристик в заявке - Количество обрабатываемых документов в день - ? 10000 - Штука - Значение характеристики не может изменяться участником закупки - Количество одновременно работающих пользователей - ? 1000 - - Значение характеристики не может изменяться участником закупки - Количество обрабатываемых запросов во внешние системы и подсистемы ГИС АСУБП в день - ? 1000 - Штука - Значение характеристики не может изменяться участником закупки - Время реакции Подсистемы при штатной нагрузке - < 8 - Секунда - Значение характеристики не может изменяться участником закупки - Время реакции Подсистемы при пиковой нагрузке - < 30 - Секунда - Значение характеристики не может изменяться участником закупки - Максимальное время ожидания ответа при получении данных от внешних систем и подсистем ГИС АСУБП - ? 300 - Секунда - Значение характеристики не может изменяться участником закупки - Программное обеспечение должно быть масштабируемо для обеспечения показателей назначения при увеличении объема данных и числа пользователей - Да - - Значение характеристики не может изменяться участником закупки - Требования к функциям подсистемы ведения соглашений (договоров) - Обеспечение ведения следующих функциональных подразделов: ­ реестр типов соглашений (договоров); ­ реестр типовых форм соглашений (договоров); ­ реестр шаблонов соглашений (договоров); ­ реестр соглашений (договоров). ­ реестр типов отчетов; ­ реестр шаблонов отчетов; ­ реестр отчетов - - Значение характеристики не может изменяться участником закупки - Требования к функциональности реестра типов соглашений (договоров) - Обеспечение возможности формирования и ведения перечня типов соглашений (договоров) с указанием по ним следующих данных: - наименование типа; - перечень сторон соглашения (договора) с возможностью настройки указания платежных реквизитов по ним; - признак формирования соглашения в соответствии с требованиями порядка ведения реестра соглашений (договоров) о предоставлении из бюджетов бюджетной системы РФ субсидий и бюджетных инвестиций юридическим лицам, индивидуальным предпринимателям, физическим лицам – производителям товаров, работ, услуг и межбюджетных трансфертов бюджетам бюджетной системы РФ, предусмотренного абз. 14 п. 1 ст. 166.1 БК РФ; признак указания в соглашении (договоре) сведений о капитальных вложениях; признак указания в соглашении (договоре) сведений о результатах предоставления бюджетных средств. - - Значение характеристики не может изменяться участником закупки - Требования к функциональности реестра типовых форм соглашений (договоров) - Обеспечение возможности формирования, применения и ведения типовых форм соглашений (договоров) с указанием по ним следующих данных: ­ наименование типовой формы; ­ тип соглашения (договора); ­ наименование и количество сторон соглашения (договора) - - Значение характеристики не может изменяться участником закупки - Требования к функциональности реестра шаблонов соглашений (договоров) - Обеспечение возможности формирования шаблона соглашения (договора) путем копирования другого доступного шаблона. - - Значение характеристики не может изменяться участником закупки - Обеспечение по каждому шаблону соглашения (договора) возможности настройки доступа в виде перечня пользователей и учреждений, сотрудникам которых будет доступен данный шаблон соглашения (договора), а также указания режима доступа: на чтение, на редактирование. - Обеспечение возможности формирования и ведения шаблонов соглашений (договоров) с указанием по ним следующих данных: - наименование шаблона соглашения (договора); - пользовательского номера шаблона соглашения (договора); - тип соглашения (договора); - форма соглашения (договора); - текстовая часть соглашения (договора); - приложения к соглашению (договору). - При заполнении текстовой части соглашения (договора) должно быть обеспечено: - возможность указания наименования; - форма редактирования текста соглашения (договора) с возможностью: - установления ограничений на изменение и (или) удаление пунктов; -возможность установления ограничения на изменение части текста в закрытых для изменения пунктах; - возможность добавления функций, возвращающих автоматически вычисленное значение; - возможность загрузки пользовательских файлов с расширением .pdf; - возможность изменять очередность вывода документа на печать. - Требования к функциям ведения реестра соглашений (договоров) - Обеспечение возможности формирования и ведения электронного документа соглашения (договора) со следующими разделами: - основные сведения; - стороны; - текстовая часть; - приложения к соглашению (договору). Дополнительно в соглашении (договоре) могут быть указаны следующие сведения: - нормативно-правовые акты (НПА); - коды бюджетной классификации (КБК); - объекты капитального строительства (ОКС); - график выполнения мероприятий; - результаты; - объемы ФО; - документы; - контракты. - - Значение характеристики не может изменяться участником закупки - Раздел «Основные сведения» соглашения (договора) включают следующие реквизиты: - системный номер; - пользовательский номер; - форма; - дата создания; - дата заключения (при наличии). В разделе «Стороны» по каждой из сторон соглашения (договора) должны быть указаны реквизиты и уполномоченное на подписание документа лицо. В разделе «НПА» должны быть указаны сведения о нормативном правовом акте, в соответствии с которым заключено соглашение (договор) о предоставлении бюджетных средств (при наличии). В разделе «КБК» должна быть указана информация о коде классификации расходов бюджета, по которому предусмотрены лимиты бюджетных обязательств на предоставление бюджетных средств (при наличии). В разделе «ОКС» должны быть указаны сведения об объектах капитального строительства, недвижимого имущества. В разделе «График выполнения мероприятий по ОКС» должны быть указаны сведения о графике выполнения мероприятий по проектированию и (или) строительству (реконструкции, в том числе с элементами реставрации, техническому перевооружению) объектов капитального строительства. В разделе «Результаты» должны быть указаны сведения о результатах использования средств, контрольных точках. В разделе «Объемы ФО» должна быть указана информация об объемах субсидии, бюджетных инвестиций, межбюджетного трансферта (при наличии). - Обеспечение следующих возможностей: формирование печатной формы документа в одном из следующих форматов: DOC, DOCX, PDF; формирование документа путем копирования другого документа; обеспечение процессов формирования листов согласования для сторон соглашений (договоров); обеспечение процессов рассмотрения сторонами соглашений (договоров); обеспечение процессов подписания сторонами соглашений (договоров); согласования и утверждения соглашений (договоров) с механизмом подписания УКЭП уполномоченного лица. Должна обеспечиваться проверка действительности сертификата УКЭП уполномоченного лица на момент подписания соглашения (договора); формирование новой версии документа в случае наложения отрицательной резолюции; внесение изменений в соглашение (договор) путем формирования дополнительного соглашения (договора) к соглашению (договору). - Требования к функциям ведения реестра типов отчетов - Обеспечение возможности ведения реестра типов отчетов, который должен обеспечивать пользователя возможностями формирования и согласования отчетов. Документом основанием для формирования отчета должно являться соглашение (договор). Должны учитываться сведения: - наименование типа; - признак формирования отчета в соответствии с требованиями порядка ведения реестра соглашений (договоров) о предоставлении из бюджетов бюджетной системы РФ субсидий и бюджетных инвестиций юридическим лицам, индивидуальным предпринимателям, физическим лицам – производителям товаров, работ, услуг и межбюджетных трансфертов бюджетам бюджетной системы РФ, предусмотренного абз. 14 п. 1 ст. 166.1 БК РФ. - - Значение характеристики не может изменяться участником закупки - Требования к функциям ведения реестра шаблонов отчетов - Обеспечение возможности формирования шаблона отчета путем копирования другого доступного шаблона. - - Значение характеристики не может изменяться участником закупки - Обеспечение возможности ведения реестра шаблонов отчетов, обеспечивающая формирование, редактирование и использование шаблонов отчета. Шаблон отчета должен содержать следующие параметры: - наименование шаблона отчета; - наименование отчета; - тип отчета; - типовая форма отчета; - типовая форма соглашения (договора); - формат даты, на которую формируется отчет; - отчетный период шаблона отчета. - Требования к функциям ведения реестра отчетов - Обеспечение возможности ведения реестра отчетов, содержащего: - общие сведения. Дополнительно в отчете могут быть указаны следующие сведения: - информация о достижении значений результатов; - сведения о принятии отчета; - сведения о выплатах, источником финансового обеспечения которых являются средства Субсидии; - сведения об обязательствах, источником финансового обеспечения которых являются средства Субсидии; - сведения о средствах, размещаемых на депозитах и полученных доходах; - сведения о расходах на организацию предоставления средств государственной поддержки; - достижение целевых показателей; - реализация плана мероприятий по достижению результатов. - - Значение характеристики не может изменяться участником закупки - Раздел «Общие сведения» отчета должен включать следующие реквизиты: - системный номер; - номер соглашения; - номер редакции соглашения; - дата создания; - дата, на которую формируется отчет; - тип отчета; - наименование отчета; - шаблон отчета; - данные предоставителя отчета; - данные получателя отчета. - В разделе «Информация о достижении значений результатов» во вкладке «Финансовое обеспечение» по каждому направлению расходов должны быть указаны объемы обязательства, принятых в целях достижения результатов предоставления субсидии, грантов. Во вкладке «Значения результатов» по каждому результату и показателю результата должны быть указаны фактические значения. В разделе «Сведения о принятии отчета» должна быть указана информация о кодах бюджетной классификации расходов, информация о КОСГУ и информация о суммах с начала заключения соглашения и с начала текущего финансового года. В разделе «Сведения о выплатах, источником финансового обеспечения которых являются средства Субсидии» по каждой строке показателя должна быть указана информация о фактических суммах и причина отклонения (при наличии). В разделе «Сведения о средствах, размещаемых на депозитах и полученных доходах» по каждой строке показателя должна быть указана информация о фактических суммах и причина отклонения (при наличии). - В разделе «Сведения о расходах на организацию предоставления средств государственной поддержки» по каждой строке показателя должна быть указана информация о фактических суммах и причина отклонения (при наличии). В разделе «Сведения об обязательствах, источником финансового обеспечения которых являются средства Субсидии» по каждой строке показателя должна быть указана информация о фактических суммах и причина отклонения (при наличии). В разделе «Реализация плана мероприятий по достижению результатов» должны быть указаны сведения о фактических или прогнозных сроках достижения результата предоставления субсидии или контрольной точки, сведения о фактических значениях результата предоставления субсидии или контрольной точки. В разделе «Достижения целевых показателей» должны быть указаны сведения о достигнутых значениях показателя по состоянию на отчетную дату. - Обеспечение следующих возможностей: - формирование печатной формы документа в одном из следующих форматов: DOC, DOCX, PDF; - формирование документа путем копирования другого документа; - обеспечение процессов формирования листов согласования для сторон отчетов; - обеспечение процессов рассмотрения сторонами отчетов; - обеспечение процессов подписания сторонами отчетов; - согласования и утверждения отчетов с механизмом подписания УКЭП уполномоченного лица. Должна обеспечиваться проверка действительности сертификата УКЭП уполномоченного лица на момент подписания отчета; - формирование новой версии документа в случае наложения отрицательной резолюции; - внесение изменений в отчет путем формирования уточнения к отчету. - Требования к способам и средствам связи для информационного обмена между компонентами ГИС АСУБП - Взаимодействие подсистемы отбора получателей субсидий с подсистемой ведения соглашений (договоров) Взаимодействие с подсистемой «НСИ» Взаимодействие подсистемы отбора получателей субсидий с подсистемой проектирования бюджета Сахалинской области - - Значение характеристики не может изменяться участником закупки - Общие требования к взаимодействию внутри ГИС АСУБП - - обеспечить взаимодействие подсистемы отбора получателей субсидий подсистемы ведения соглашений (договоров) (далее при совместном упоминании – Подсистемы) с подсистемой НСИ для получения данных об организациях; - обеспечить двусторонний обмен данными между подсистемой отбора получателей субсидий и подсистемой ведения соглашений (договоров): не только передачу информации о победителях отбора для заключения соглашения, но и получение данных о статусе заключения, исполнения и расторжения соглашений; - обеспечить взаимодействие подсистемы отбора получателей субсидий с подсистемой проектирования бюджета для получения информации о бюджетных ассигнованиях и лимитах бюджетных обязательств, а также загрузки необходимой справочной информации; - реализовать механизм автоматического обновления информации о соглашениях в подсистеме отбора получателей субсидий; - предусмотреть возможность ручного ввода данных в случае отсутствия интеграции. - - Значение характеристики не может изменяться участником закупки - Требования к взаимодействию подсистемы отбора получателей субсидий с подсистемой ведения соглашений (договоров) - Взаимодействие подсистемы отбора получателей субсидий с подсистемой ведения соглашений (договоров) должно осуществляться в части передач данных, необходимых для инициации процесса заключения соглашения между главным распорядителем бюджетных средств и победителями отбора, и получения информации о результатах подписания соглашения (договора). Подсистема отбора получателей субсидий должна обеспечить выполнение следующих функций: - после утверждения субсидии формируется первый пакет данных для отправки в подсистему ведения соглашений (договоров). Состав данных должен содержать необходимую для передачи информацию о субсидии и результатах, которые в нее включены; - после завершения отбора и выявления победителей формируется второй пакет данных для отправки в подсистему ведения соглашений (договоров). Состав данных должен содержать необходимую для передачи информацию об отборе, выявленных победителях и суммах по соответствующим КБК; - после заключения соглашения (договора), начиная с момента наступления срока, установленного в отборе, получать сведения о заключенных по результатам отбора соглашениях (договорах). Полученные сведения должны отображаться в соответствующем разделе субсидии. В случае если сведения о заключенном соглашении (договоре) не поступили в установленный срок, победитель считается уклонившимся от заключения соглашения (договора). Условия запуска процессов отправки и получения данных, а также ожидаемые результаты описаны в Таблице 2 Технического задания (приложения к описанию объекта закупки). При внесении изменений в субсидию, создании и утверждении новой версии документа подсистема отбора получателей субсидий должна направлять новые данные в подсистему ведения соглашений (договоров). - - Значение характеристики не может изменяться участником закупки - Требования к взаимодействию с подсистемой «НСИ - Взаимодействие Подсистем с подсистемой «НСИ» должно осуществляться в части получения данных по организациям для формирования и обновления справочника «Учреждения» Подсистем. Условия запуска процессов отправки и получения данных, а также ожидаемые результаты описаны в Таблице 3 Технического задания (приложения к описанию объекта закупки). При наличии расхождения данных для записей с одинаковым идентификатором должна формироваться новая версия записи справочника. Действующей будет считаться последняя версия документа. - - Значение характеристики не может изменяться участником закупки - Требования к взаимодействию подсистемы отбора получателей субсидий с подсистемой проектирования бюджета Сахалинской области - Взаимодействие подсистемы отбора получателей субсидий с подсистемой проектирования бюджета должно осуществляться в трех направлениях: загрузка данных по БА и ЛБО соответствующих КБК на этапе формирования субсидии в раздел «Финансовое обеспечение» карточки субсидии. Утверждение и публикация субсидии невозможны пока не будут получены данные о лимитах бюджетных обязательств; в случае если данная настройка включена в подсистеме администратором, выгрузка из подсистемы отбора получателей субсидий данных по принимаемым бюджетным обязательствам, после утверждения объявления об отборе, с целью резервирования денежных средств, если отбор был отменен, то зарезервированная сумма должна высвобождаться автоматически после утверждения объявления об отмене отбора; загрузка информации по справочникам в подсистему отбора получателей субсидий. Условия запуска процессов отправки и получения данных, а также ожидаемые результаты описаны в Таблице 4 Технического задания (приложения к описанию объекта закупки). При внесении изменений в БА и ЛБО, должна автоматически создаваться новая версия соответствующей субсидии, версия создается подконтрольно со стороны пользователей системы, подсистема отбора получателей субсидий должна обеспечивать информирование пользователя я о появлении новых данных по соответствующим кодам расходов бюджета. Обновление информации должно осуществляться автоматически в соответствии с периодичностью, заданной в планировщике задач. При наличии расхождения данных по загружаемым справочникам для записей с одинаковым идентификатором должна формироваться новая версия записи справочника. Действующей будет считаться последняя версия документа. - - Значение характеристики не может изменяться участником закупки - Требования к взаимодействию с внешними информационными системами - Взаимодействие с ГИИС «Электронный бюджет» Взаимодействие с открытыми данными Центрального банка России Взаимодействие подсистемы отбора получателей субсидий с СМЭВ Взаимодействие подсистемы отбора получателей субсидий с открытыми данными ФНС Взаимодействие подсистемы отбора получателей субсидий с Федеральной службой по финансовому мониторингу (Росфинмониторинг) Взаимодействие подсистемы отбора получателей субсидий с открытыми данными Федерального казначейства (ФК) Реализация процесса автоматической проверки заявок участников на соответствие требованиям объявления об отборе - - Значение характеристики не может изменяться участником закупки - Требования к взаимодействию с ГИИС «Электронный бюджет» - Взаимодействие с ГИИС «Электронный бюджет» должно осуществляться в части получения открытых данных для наполнения справочников Подсистем. Условия запуска процессов получения данных, а также ожидаемые результаты описаны в Таблице 5 Технического задания (приложения к описанию объекта закупки). При выявлении расхождений в данных для записей с одинаковым идентификатором должна формироваться новая версия записи справочника. Действующей считаться последняя актуальная версия записи. - - Значение характеристики не может изменяться участником закупки - Требования к взаимодействию с открытыми данными Центрального банка России - Взаимодействие должно осуществляться в части загрузки открытой информации о зарегистрированных на территории РФ кредитных организациях для наполнения справочника Подсистемы «Банки». Условия запуска процессов получения данных, а также ожидаемые результаты описаны в Таблице 6 Технического задания (приложения к описанию объекта закупки). Обновление информации должно осуществляться автоматически в соответствии с периодичностью, заданной в планировщике задач. При наличии расхождения данных для записей с одинаковым идентификатором должна формировать новая версия записи справочника. Действующей будет считаться последняя версия документа. - - Значение характеристики не может изменяться участником закупки - Требования к взаимодействию подсистемы отбора получателей субсидий с СМЭВ - Взаимодействие должно осуществляться в части получения данных, необходимых для реализации автоматических проверок на соответствие участника отбора следующим требованиям: а) участник отбора получателей субсидий не должен являться иностранным агентом в соответствии с Федеральным законом «О контроле за деятельностью лиц, находящихся под иностранным влиянием»; б) деятельность не приостановлена в порядке, предусмотренном законодательством Российской Федерации. Проверки должны осуществляться по алгоритму, описанному в Требованиях к взаимодействию подсистемы отбора получателей субсидий с Федеральной службой по финансовому мониторингу (Росфинмониторинг). Для получения сведений из СМЭВ необходимо обеспечить подключение к следующим видам сведений: а) сведения из реестра иностранных агентов; б) сведения об исполнительных производствах об административном приостановлении деятельности юридических лиц и индивидуальных предпринимателей. Источник данных для осуществления проверки и ожидаемые результаты описаны в Таблице 7 Технического задания (приложения к описанию объекта закупки). - - Значение характеристики не может изменяться участником закупки - Требования к взаимодействию подсистемы отбора получателей субсидий с открытыми данными ФНС - Взаимодействие должно осуществляться в части получения сведений для реализации автоматических проверок на соответствие участника отбора требованию: - участник отбора получателей субсидий, являющийся юридическим лицом, не должен находиться в процессе реорганизации (за исключением реорганизации в форме присоединения к юридическому лицу, являющемуся участником отбора получателей субсидий, другого юридического лица), ликвидации, в отношении него не введена процедура банкротства, деятельность получателя субсидии не должна быть приостановлена в порядке, предусмотренном законодательством Российской Федерации, а получатель субсидии, являющийся индивидуальным предпринимателем, не должен прекратить деятельность в качестве индивидуального предпринимателя. - - Значение характеристики не может изменяться участником закупки - Взаимодействие должно осуществляться в части получения сведений для реализации автоматических проверок на соответствие участника отбора требованию: - в реестре дисквалифицированных лиц должны отсутствовать сведения о дисквалифицированных руководителе, членах коллегиального исполнительного органа, лице, исполняющем функции единоличного исполнительного органа, или главном бухгалтере получателя субсидии, являющегося юридическим лицом, об индивидуальном предпринимателе и о физическом лице - производителе товаров, работ, услуг, являющихся участниками отбора получателей субсидий; - Взаимодействие должно осуществляться в части получения сведений для реализации автоматических проверок на соответствие участника отбора требованию: - участник отбора получателей субсидий не должен являться иностранным юридическим лицом, в том числе местом регистрации которого является государство или территория, включенные в утверждаемый Министерством финансов Российской Федерации перечень государств и территорий, используемых для промежуточного (офшорного) владения активами в Российской Федерации (далее - офшорные компании), а также российским юридическим лицом, в уставном (складочном) капитале которого доля прямого или косвенного (через третьих лиц) участия офшорных компаний в совокупности превышает 25 процентов (если иное не установлено законодательством Российской Федерации). При расчете доли участия офшорных компаний в уставном (складочном) капитале российских юридических лиц не учитываются прямое и (или) косвенное участие офшорных компаний в капитале публичных акционерных обществ (в том числе со статусом международной компании), акции которых обращаются на организованных торгах в Российской Федерации, а также косвенное участие таких офшорных компаний в капитале других российских юридических лиц, реализованное через участие в капитале указанных публичных акционерных обществ; - Взаимодействие должно осуществляться в части получения сведений для реализации автоматических проверок на соответствие участника отбора следующим требованию: - у участника отбора получателей субсидий на едином налоговом счете должна отсутствовать или не превышать размер, определенный пунктом 3 статьи 47 Налогового кодекса Российской Федерации, задолженность по уплате налогов, сборов и страховых взносов в бюджеты бюджетной системы Российской Федерации. - Проверки должны выполняться по алгоритму, описанному в разделе Требования к взаимодействию подсистемы отбора получателей субсидий с Федеральной службой по финансовому мониторингу (Росфинмониторинг). По требованию «участник отбора получателей субсидий, являющийся юридическим лицом, не должен находиться в процессе реорганизации (за исключением реорганизации в форме присоединения к юридическому лицу, являющемуся участником отбора получателей субсидий, другого юридического лица), ликвидации, в отношении него не введена процедура банкротства, деятельность получателя субсидии не должна быть приостановлена в порядке, предусмотренном законодательством Российской Федерации, а получатель субсидии, являющийся индивидуальным предпринимателем, не должен прекратить деятельность в качестве индивидуального предпринимателя» проверки должны осуществляться путем получения выписки о состоянии участника из открытых данных реестров ЕГРЮЛ / ЕГРИП в зависимости от типа субъекта экономической деятельности. Данное требование для успешной проверки необходимо разбить на четыре отдельных самостоятельных требования, которые будут добавляться автоматически в субсидию в зависимости от указанных типов субъектов экономической деятельности: юридическое лицо не проходит процедуру ликвидации; юридическое лицо не находится в процессе реорганизации; не введена процедура банкротства; деятельность не приостановлена в порядке, предусмотренном законодательством Российской Федерации (проверка осуществляется через СМЭВ, см. раздел Требования к взаимодействию подсистемы отбора получателей субсидий с СМЭВ). Заказчик должен быть зарегистрирован на ФНС ВПД (иметь личный кабинет с доступом к сервисам, перечисленным в Таблице 7 Технического задания (приложения к описанию объекта закупки), для успешного осуществления автопроверки участников. Источник данных для осуществления проверки и ожидаемые результаты описаны в Таблице 8 Технического задания (приложения к описанию объекта закупки). - Требования к взаимодействию подсистемы отбора получателей субсидий с Федеральной службой по финансовому мониторингу (Росфинмониторинг) - Взаимодействие будет осуществляться в части получения данных, необходимых для реализации автоматической проверки на соответствие участника отбора требованию об отсутствии в перечне организаций и физических лиц, в отношении которых имеются сведения об их причастности к экстремистской деятельности или терроризму. Для получения файла с данными о физических лицах и организациях, входящих в перечень, необходимо пройти регистрацию в личном кабинете Росфинмониторинга. Проверка должна выполняться по алгоритму, описанному в указанных Требованиях. Источник данных для осуществления проверки и ожидаемые результаты описаны в Таблице 9 Технического задания (приложения к описанию объекта закупки). - - Значение характеристики не может изменяться участником закупки - Требования к взаимодействию подсистемы отбора получателей субсидий с открытыми данными Федерального казначейства (ФК) - Взаимодействие будет осуществляться в части получения данных, необходимых для реализации автоматической проверки на отсутствие участника в реестре недобросовестных поставщиков (подрядчиков, исполнителей) по данным https://zakupki.gov.ru. Для получения файла с данными о организациях и индивидуальных предпринимателях, внесенных в реестр, необходимо пройти регистрацию в личном кабинете на сайте Единой информационной системы (ЕИС), https://zakupki.gov.ru. Проверка должна выполняться по алгоритму, описанному в разделе Требования к взаимодействию подсистемы отбора получателей субсидий с Федеральной службой по финансовому мониторингу (Росфинмониторинг). Источник данных для осуществления проверки и ожидаемые результаты описаны в Таблице 10 Технического задания (приложения к описанию объекта закупки). - - Значение характеристики не может изменяться участником закупки - Требования к реализации процесса автоматической проверки заявок участников на соответствие требованиям объявления об отборе - Потенциальный участник регистрируется в системе, после регистрации он должен иметь возможность подать заявку на участие в отборе или заявку на предоставление субсидии в качестве прямого получателя, если субсидия распределяется без отбора. Заявка должна содержать все необходимые данные об участнике, в зависимости от того к какому типу субъекта экономической деятельности он относится. В заявке участник должен иметь возможность подтвердить свое соответствие требованиям отбора (Таблица 11 Технического задания (приложения к описанию объекта закупки). - - Значение характеристики не может изменяться участником закупки - При наступлении этапа рассмотрения заявок пользователь, выполняющий роль Валидатора, должен еще раз вручную запустить процесс автоматической проверки участников на соответствие требованиям. Если после автоматической проверки участник не соответствует, хотя бы одному требованию, то заявка такого участника отклоняется и прекращает участие в отборе. При добавлении участника в качестве прямого получателя субсидии должен запускаться механизм автоматических проверок по данному участнику. Если участник не соответствует хотя бы одному требованию, то при переводе на согласование субсидии нельзя допускать утверждение такого документа. Необходимо отображать дату последнего обновления данных по автоматическим проверкам. - Количество автоматических проверок должно зависеть от типа субъекта экономической деятельности (Таблица 11 Технического задания (приложения к описанию объекта закупки) ). Автоматическая проверка участника на соответствие требованиям должна осуществляться: а) при регистрации участника в системе; б) в режиме самопроверки в личном кабинете участника; в) после подписания заявки участником с использованием ЭП; г) при ручном запуске проверки участника на соответствие требованиям пользователем с ролью Валидатор. Запустить проверку вручную можно 1 раз в сутки; д) перед отправкой информации о победителе отбора в подсистему ведения соглашений (договоров) для заключения соглашения; е) при добавлении участника в раздел «Прямые получатели» субсидии для субсидии способом отбора «Не требуется». Список автоматических проверок, которые должен пройти участник в зависимости от типа субъекта экономической деятельности, к которому он относится, должны содержаться в личном кабинете. С отображением статусной модели по проверкам после регистрации пользователя в Подсистеме. Если участник не прошел автоматическую проверку, по одному или нескольким требованиям на этапе подачи заявок, его заявка должна допускаться до следующего этапа отбора. Но при этом необходимо направлять уведомление участнику о том, что он не прошел проверку по тем или иным требованиям и у него есть время на устранение данной ситуации до начала этапа рассмотрения заявок. - Предусмотреть статусную модель для каждой автопроверки в Подсистеме, с всплывающими подсказками: - проверка пройдена успешно; - проверка не пройдена; - в процессе; - данные не получены (ошибка при получении данных); - требуется перепроверка на причастность к экстремисткой деятельности и терроризму (отображается у ФЛ и ИП при совпадении записей ФИО с записью в реестре экстремистов, у которой отсутствует ИНН), ручная перепроверка. После завершения отбора и выявления победителей, перед отправкой заявок победителей в подпрограмму ведения соглашений (договоров) автоматически должен запускаться механизм проверок участников на соответствие требованиям. - Требования к развитию подсистемы отбора получателей субсидий в части формирования шаблонов форм документов - Необходимо развить функциональность подсистемы отбора получателей субсидий в части формирования документов с использованием механизма шаблонов. Для этого нужно расширить компонентный состав подсистемы следующим образом: разработать отдельный реестр «Шаблоны документов», который должен содержать шаблоны для документов двух видов «Объявления об отборах» и «Заявки участников»; внести изменения в операцию по формированию объявления о проведении отбора и заявки участника в части выбора шаблона, который будет являться основой для создаваемого документа; добавить раздел «Текстовая часть» в карточки документов; внести изменения в карточки документов, исключив поля для ввода информации, не влияющей на бизнес-процесс. - - Значение характеристики не может изменяться участником закупки - Требования к реестру шаблонов - Реестр шаблонов отображается в личном кабинете ГРБС. Реестр должен иметь следующую функциональность и набор полей: информация из паспорта шаблона: Вид документа, Наименование шаблона, Реестровый номер шаблона, Системный признак, Статус; фильтры; доступные действия пользователей с шаблоном, с учетом их прав (редактировать, печать, удалить, перевести в статус «Готов», просмотр, копировать); карточка шаблона должна включать в себя следующие разделы: Паспорт шаблона, в разрезе данных: Вид документа («объявление о проведении отбора», «заявка участника»), Наименование шаблона, Реестровый номер шаблона, Системный признак, Статус, Автор, Идентификатор ГРБС; Дата изменения, Дата начала действия, Дата окончания действия, Номер версии; Текстовая часть (шаблон формы документа); Приложения (функциональная возможность добавления файлов в формате .pdf). Пользователи с ролью ГРБС видят шаблоны с системным признаком «Типовая форма», а также шаблоны, созданные пользователями самого ГРБС. Доступ к шаблонам, созданным другим ГРБС, должен быть закрыт. В качестве идентификатора ГРБС используется код участника бюджетного процесса по сводному реестру. Поле идентификатор ГРБС для системных шаблонов заполняется пятью нулями. - - Значение характеристики не может изменяться участником закупки - Правами на создание, редактирование и перевод в статус «Готов» шаблонов с системным признаком «Типовая форма» должны обладать только пользователи с ролью Администратор. Пользователь с правами ГРБС при создании шаблона должен выбрать шаблон с системным признаком «Типовая форма», на основе которого он создает свой шаблон. Текстовая часть шаблона должна представлять собой текстовый редактор, содержащий набор функций: - управление шрифтами; - работа со списками и таблицами; - установка абзацных отступов; - редактирование стилей; - выравнивание текста; - навигация по документу; - установка запретов на изменение и (или) удаление части данных или всего текста; - работа в полноэкранном режиме; - добавление картинок в текст документа; - копирование и вставка текстовых данных; - добавление тэгов из заранее заведенного списка стандартных возможных тэгов в систему, с целью отображения актуальной информации из параметров системы в формируемой форме. Неотъемлемой частью шаблона должны быть объекты, предназначенные для последующего наложения оттиска электронных подписей. При копировании шаблона он должен копироваться полностью вместе с текстовой частью. Реестр «Шаблоны документов» должен включать возможность версионирования записей. - Требования к формированию объявления о проведении отбора с использованием шаблонов - Объявление об отборе должно формироваться на основании типового шаблона (системный признак «типовая форма»). Пользователь с ролью ГРБС должен иметь возможность сформировать отбор, выбрав заготовленную форму из реестра «Шаблоны документов» по виду документа «Объявление о проведении отбора» в статусе «Готов». Сформированный документ будет отображаться в реестре «Отборы» в статусе «Черновик». Карточка документа будет содержать следующие разделы: - «Общие сведения»; - «Требования и документы»; - «Порядок подачи заявок»; - «Порядок рассмотрения заявок»; - «Порядок оценки заявок»; - «Объем и параметры распределения субсидии»; - «Текстовая часть»; - «Приложения»; - «Распределение средств по итогам отбора». Следующие поля должны быть убраны из карточки документа, они будут находиться только в сформированном пользователем шаблоне текстовой части: 1) Раздел «Порядок подачи заявок»: порядок подачи заявок, порядок предоставления разъяснений положений о проведении отбора. 2) Раздел «Порядок рассмотрения заявок»: порядок рассмотрения заявок, порядок отклонения заявок. - - Значение характеристики не может изменяться участником закупки - Текстовая часть из выбранного шаблона должна полностью переноситься в карточку документа в раздел «Текстовая часть». Система должна позволять редактировать текстовую часть под конкретный отбор пользователем, за исключением полей, заполнение которых осуществляется через экранную форму других разделов – такие поля должны быть заблокированы для изменений. Данный раздел должен содержать те же функции и возможности как и раздел карточки шаблона описанный в Требованиях к реестру шаблонов. Печатная форма отбора, которая формируется по итогам создания документа после утверждения должна иметь вид, который был определен в разделе «Текстовая часть» карточки отбора. При создании новой версии отбора, текстовая часть из карточки отбора должна переноситься полностью в том виде в котором она была сформирована в предыдущей версии документа. При копировании отбора текстовая часть из карточки отбора должна переноситься полностью в копию в том виде в котором она была сформирована. - Требования к формированию заявки участника с использованием шаблонов - Заявка участника должна формироваться на основании типового шаблона (системный признак «типовая форма»). При формировании объявления об отборе, организатор отбора или ГРБС, должны иметь возможность добавить шаблоны заявок в разделе «Порядок подачи заявок» с ограничением по, указанным типам получателей субсидии в отборе. Далее при формировании заявки в карточку заявки участника должен подтягиваться шаблон, с ограничением по шаблонам, добавленным в отбор, на который происходит подача заявки и типу субъекта экономической деятельности участника. Карточка документа будет содержать разделы: «Общие сведения»; «Информация об участнике»; «Календарный план»; «Бюджет»; «Требования к участнику»; «Документы». Следующие разделы и поля должны быть убраны из карточки документа, они будут находиться только в сформированном пользователем шаблоне текстовой части: Раздел «Основная информация»: «О проекте», «Задачи», «Цели». Текстовая часть из шаблона, выбранного ГРБС или организатором отбора, для соответствующего типа субъекта экономической деятельности должна полностью переноситься в карточку документа в раздел «Текстовая часть». Система должна позволять редактировать текстовую часть под конкретного участника пользователем, за исключением полей, заполнение которых осуществляется через экранную форму других разделов – такие поля должны быть заблокированы для изменений. Данный раздел должен содержать те же функции и возможности как и раздел карточки шаблона описанный в Требованиях к реестру шаблонов. Печатная форма заявки участника, которая формируется по итогам создания документа после подписания должна иметь вид, который был определен в разделе «Текстовая часть» карточки заявки участника. - - Значение характеристики не может изменяться участником закупки - Требования к развитию подсистемы отбора получателей субсидий в части рабочего места «Администрирование» - Доступ к функциям программного обеспечения подсистемы должен обеспечиваться в соответствии с ролевой моделью. Рабочее место «Администрирование» должно быть доступно для пользователей, зарегистрированных в системе и имеющих роль «Администратор». Администратор должен иметь доступ к функциям, предусмотренным его ролью и уровнем полномочий. Рабочее место «Администрирование» должно обеспечивать выполнение следующих функций: - управление ролями, группами пользователей и правами доступа; - аудит действий пользователей и контроль сессий; - настройка системных уведомлений; - настройка автоматической публикации документов (субсидия, отбор); - настройка адреса публикации документов (субсидия, отбор); - управление и настройка процесса формирования реестровых записей документов (комиссия, субсидия, отбор, протоколы, заявки участников); - настройка бизнес-процессов. - - Значение характеристики не может изменяться участником закупки - Требования к функции «Автоматическая публикация документов» - В Подсистеме должна быть предусмотрена настройка, доступная только пользователям с ролью «Администратор». Настройка должна определять режим публикации сведений о субсидиях, отборов и протоколов. Наименование настройки «Автоматическая публикация сведений о субсидиях», «Автоматическая публикация сведений об отборах», «Автоматическая публикация протоколов» – значения, которые может принимать «Да/Нет». Эта настройка должна влиять на поведение системы при изменении значения в поле «Статус публикации» по таким документам как субсидии, отборы и протоколы. Пользователь с ролью «Администратор» должен иметь доступ к интерфейсу настройки параметров публикации. Этот интерфейс должен включать элементы управления для включения/выключения параметров. Параметры публикации заранее должны быть определены Заказчиком по каждому публикуемому документу для корректной настройки процесса. Кроме этого функция должна обеспечивать возможность установления Администратором адреса публикации документов. Адрес публикации должен отображаться автоматически в Подсистеме в соответствии с установленным на рабочем месте Администратора. - - Значение характеристики не может изменяться участником закупки - Требования к функции «Автоматическая отправка данных по принимаемым бюджетным обязательствам в подсистему проектирования бюджета Сахалинской области» - В Подсистеме должна быть предусмотрена настройка, доступная только пользователя с ролью «Администратор». Настройка должна определять возможность автоматической отправки данных по принимаемым бюджетным обязательствам после утверждения документа «Объявление об отборе» в подсистему проектирования бюджета ГИС АСУБП, «Автоматическое резервирование/высвобождение принимаемых БО» – значения, которые может принимать «Да/Нет». Эта настройка должна влиять на поведение системы при переходе «Объявления об отборе» в статус «Утвержден» / «Отменен». Если установлено значение «Да», то после перехода «Объявления об отборе» в статус «Утвержден», автоматически информация о финансовом обеспечении объявления об отборе (номер документа, КБК, суммы, года) направляется в систему проектирования бюджета ГИС АСУБП. Или после перехода «Объявления об отборе» в статус «Отменен», автоматически информация о номере документа направляется в систему проектирования бюджета ГИС АСУБП и зарезервированные денежные средства высвобождаются, давая возможность использовать их для проведения других отборов. - - Значение характеристики не может изменяться участником закупки - Требования к функции «Формирование реестровых номеров документов» - Функционал по настройке формирования реестровых номеров для следующих документов: 1. Субсидия; 2. Отбор: 3. Комиссия; 4. Код результата; 5. Протокол вскрытия заявок; 6. Протокол рассмотрения заявок; 7 . Итоговый протокол; 8. Заявка участника; 9. Системные уведомления; 10. Шаблоны отборов и заявок участника. Для каждого документа Администратор должен иметь возможность создавать или изменять структуру реестрового номера. По заданной структуре при создании нового документа реестровые номера должны добавляться автоматически. Все элементы, входящие в структуру любого реестрового номера, должны быть заранее определены Заказчиком. При изменении структуры кода реестрового номера любого документа, все новые записи должны формироваться с учетом внесенных изменений в код реестрового номера. Все утвержденные, на момент изменений, записи должны сохранять структуру реестрового номера, которая была на момент утверждения. - - Значение характеристики не может изменяться участником закупки - Механизм формирования реестровых номеров должен обеспечивать: - уникальность номеров, номера не должны повторяться для разных сущностей; - формат номера должен иметь определенную структуру; - неизменность, реестровый номер не должен меняться в процессе существования сущности, при внесении изменений в документ, при создании новых версий документа; - автоматизация, номера должны создаваться автоматически при добавлении новой сущности по правилам, заданным на рабочем месте Администратора в разделе «Формирование реестровых номеров документов»; - целостность реестровых номеров, один номер должен быть привязан к одному документу. - Требования к функции «Управление ролями, группами пользователей и правами доступа» - Разделы и документы системы в отношении которых может быть осуществлена настройка прав доступа: - Справочники; - Комиссии; - Субсидии; - Отборы; - Протокол вскрытия заявок: - Протокол рассмотрения заявок; - Протокол подведения итогов; - Протоколы; - Заявки участников; - Заявки; - Оценка заявок; - Валидация; - Мои экспертизы; - Распределение средств по итогам отбора; - Шаблоны заявок участников; - Шаблоны отборов; - Запросы на разъяснения; - Уведомления; - Администрирование. - - Значение характеристики не может изменяться участником закупки - Функция управления ролями, группами пользователей и правами доступа должна обеспечивать выполнение следующих возможностей: - создание ролей с возможностью настройки прав доступа; - изменение прав доступа входящих в состав роли; - создание и настройку групп пользователей; - назначение прав доступа группам пользователей; - индивидуальные настройки прав доступа для отдельных пользователей внутри группы. Настройка прав доступа должна обеспечивать возможность разграничения прав на просмотр, создание, редактирование, согласование, утверждение, отмену, удаление, печать и выполнение иных операций в отношении разделов и документов системы. Набор прав доступа должен быть заранее определен Заказчиком. - Требования к функции «Аудит действий пользователей и контроль сессий» - Аудит действий пользователей должен осуществляться через интерфейс «Журнал действий пользователей», системный журнал контроля сессий. - - Значение характеристики не может изменяться участником закупки - Требования к интерфейсу «Журнал действий пользователей» - Интерфейс «Журнал действий пользователей» должен обеспечивать просмотр, поиск и анализ сведений о действиях пользователей в системе, а также просмотр истории обработки документов и событий пользовательских сессий. Интерфейс должен предоставлять возможность: - просмотра перечня записей журнала действий пользователей в табличном виде; - фильтрации записей журнала по пользователю, дате и времени события, типу действия, объекту действия, разделу системы, результату выполнения операции; - поиска записей журнала по идентификатору документа, наименованию документа, учетной записи пользователя и другим ключевым атрибутам; - просмотра подробной информации по каждой записи журнала; - отображения истории действий пользователя за выбранный период; - отображения пошаговой истории операций по выбранному документу с указанием последовательности действий; - просмотра сведений о том, кто, когда и какое действие выполнил; - отображения сведений о входах и выходах пользователей из системы; - отображения сведений об активных сессиях пользователей; - принудительного завершении сессии; - выгрузки данных журнала в файл в формате, определяемом требованиями Заказчика; - сортировки записей журнала по основным реквизитам; - постраничного отображения данных при большом объеме записей; - обновления списка записей журнала без перезагрузки всей страницы. - - Значение характеристики не может изменяться участником закупки - Журнал действий должен содержать сведения, достаточные для анализа пользовательской активности, контроля выполнения операций и разбора спорных ситуаций, включая как минимум: - дату и время события; - учетную запись пользователя; - роль или группу пользователя; - тип и описание действия; - объект действия; - идентификатор связанного документа или записи; - результат выполнения действия; - сведения об инициаторе действия, если действие выполнено системой или от имени другого пользователя; - дополнительные технические сведения, необходимые для трассировки события. Интерфейс должен обеспечивать удобное представление данных для пользователей с правами администратора, аудитора и иных уполномоченных лиц. Доступ к журналу должен осуществляться с любого реестра Подсистемы, чтобы можно было просмотреть действия по каждому определенному документу, при необходимости. - Требования к функции контроля сессий - Системный журнал должен позволять: - контролировать сессии пользователей в системе; - регистрировать события входа, выхода, неудачных попыток доступа и таймаутов в системном журнале; - принудительно разрывать сессию в случае необходимости; Каждая сессия должна быть жестко привязана к аутентифицированному пользователю, использование общих учетных записей запрещено. Идентификаторы сессий должны быть длинными, случайными и генерироваться заново после успешного входа. Передача только по защищенным каналам. - - Значение характеристики не может изменяться участником закупки - Требования к функции «Анализ и сопровождение документов» - Функция анализа и сопровождения документов должна обеспечивать возможность: - выгрузку структуры данных по документам субсидий и отборов с отображением заполненных значений и соответствующих реестров базы данных в текстовый файл; - просмотр связанных с документом объектов в едином интерфейсе без необходимости последовательного перехода по отдельным сущностям; - просмотр журнала изменений по, выбранному документу; - переход к выбранному документу, открытие карточки документа. Указанный функционал, в части выгрузки структуры данных по субсидиям и отборам, должен обеспечивать возможность анализа причин ошибок, проверки полноты формирования документов. Просмотр связанных объектов должен обеспечивать отображение взаимосвязи между сущностями субсидий, отборов, заявок участников и протоколов, формируемых в рамках системы. Функция просмотра связей между объектами должна быть доступна всем группам пользователей при наличии у них соответствующих прав. Функция просмотра связанных с документом объектов, должна обеспечивать возможность открытия журнала действий по выбранному документу. Функция перехода к выбранному документа, должна обеспечивать возможность открытия карточки документа в режиме просмотра. - - Значение характеристики не может изменяться участником закупки - Требования к функции «Настройка системных уведомлений» - Функция настройки системных уведомлений должна обеспечивать возможность: - настройка получателей уведомлений; - времени и даты формирования уведомлений, при необходимости; - настройка событий, по которым формируется уведомление, при необходимости; - настройка доступности формирования уведомлений определенным группа пользователей с учетом их прав; - настройка содержания уведомлений. В качестве событий, в рамках которых пользователям могут направляться уведомления, могут быть: - завершение сроков по этапам: - переход отбора/субсидии на определенный этап; - изменение статусов документов; - завершение работы с заявками валидаторов, экспертов, членов комиссии; - информация о заключенном соглашении; - ошибки в системе (для администратора). Пользователь с ролью Администратор, должен иметь возможность сформировать стандартное системное уведомления, без привязки к заранее определенным в настройках событиям. - - Значение характеристики не может изменяться участником закупки - Общие требования к развитию Подсистем - Исполнитель может оказать услуги по развитию Подсистем способом разработки ПО в рамках оказания услуг по настоящему Техническому заданию или способом адаптации принадлежащего Подрядчику на законных основаниях ПО при условии соблюдения принципа однократного ввода и многократного использования информации в Подсистемах. При оказании услуг по развитию Подсистем способом разработки ПО в рамках оказания услуг по настоящему Техническому заданию, должен обеспечить его совместимость и взаимодействие с уже функционирующими компонентами развиваемых Подсистем, на базе которых созданы и функционируют развиваемые Подсистемы, для сохранения принципа однократного ввода информации, подлежащей учету, и обеспечения единообразия интерфейса. При оказании услуг по развитию Подсистем способом адаптации ПО Исполнитель может проводить её в том числе путем параметрической настройки, изменения скриптов, конфигурационных файлов, в том числе файлов, учитывающих параметры оборудования Заказчика и необходимых для привязки адаптируемого ПО к оборудованию Заказчика и т.п. Исполнитель должен уведомить Заказчика о выбранном способе оказания услуг в соответствии с требованиями настоящего Технического задания и условиями Контракта в течение 5 (Пяти) рабочих дней с даты заключения Контракта. - - Значение характеристики не может изменяться участником закупки - Требования к защите информации от несанкционированного доступа - Требования к защите обрабатываемой информации, предъявляемые законодательством Российской Федерации, иными нормативными правовыми актами органов государственной власти, регулирующих отношения в области защиты информации Идентификация, аутентификация и авторизация пользователей Системы при доступе к защищаемым ресурсам Подсистемы должны поддерживать: - использование внешнего хранилища учетных данных, в том числе в составе компонента управления учетными записями и правами пользователей Системы - ролевую модель разграничения доступа, установленную Заказчиком Подсистемы должны обеспечивать: - возможности подписания документов электронной подписью определенным пользователем в определенном статусе с использованием средств обеспечения юридической значимости документов, должно поддерживаться множественное подписание документов - визуализацию подписываемой пользователем информации непосредственно перед ее подписанием - журналирование пользовательских операций, включая протоколирование пользовательских сессий (факты входа (авторизации) и выхода (закрытие сессии), фиксирование вызовов пользователем того или иного метода программы и фиксация фактов выполнения пользователями каждого изменения значений полей для объектов определенных классов. - завершение сеанса работы пользователя Подсистемы после установленного времени бездействия (неактивности) пользователя или по его запросу - возможность автоматической блокировки учетных записей при подозрительных действиях или многократных неудачных попытках входа - - Значение характеристики не может изменяться участником закупки - Требования к лингвистическому обеспечению - Все экранные формы должны быть представлены пользователю на русском языке. Справки и всплывающие подсказки должны быть на русском языке. Сообщения об ошибках, предупреждения и диалоги должны быть на русском языке. Для интерфейсов взаимодействия эксплуатирующего персонала с Подсистемами, используемых при техническом обслуживании программно-аппаратного комплекса Подсистем, а также для системных сообщений, выдаваемых программно-техническими средствами Подсистем, допускается использование английского языка. - - Значение характеристики не может изменяться участником закупки - Требования к программному обеспечению - Должна быть обеспечена возможность использования сертифицированных в соответствии с законодательством Российской Федерации средств защиты информации. Программное обеспечение Подсистем должно обеспечивать заданные функциональные требования к Подсистемам, включая достижение заданных показателей назначения. Подсистемы должны позволять осуществлять настройку программных компонентов и дальнейшее развитие их функциональности. Программное обеспечение Подсистем должно быть реализовано в трехзвенной архитектуре на базе веб-технологий. Программное обеспечение Подсистем должно иметь клиент-серверную архитектуру, в следующем минимальном составе: сервер СУБД. сервер приложений; сервер хранения данных; сервер логирования данных; веб-сервер; сервер для резервного копирования данных. Клиентское приложение должно базироваться на использовании Интернет-браузера, включенного в «Единый реестр российских программ для электронных вычислительных машин и баз данных» (https://reestr.minsvyaz.ru/reestr/) и использующего протокол ГОСТ TLS. Вся логика обработки данных должна реализовываться сервером приложений. Для каждого программного компонента Подсистем должны быть разработаны и включены в состав рабочей документации детальные инструкции по его установке и настройке. - - Значение характеристики не может изменяться участником закупки - Требования к техническому обеспечению - Информационно-телекоммуникационная инфраструктура Подсистем должна по возможности использовать технологии виртуализации аппаратных ресурсов. Информационно-телекоммуникационная инфраструктура Подсистем должна быть масштабируемой для обеспечения показателей производительности и надежности при росте данных и числа пользователей. - - Значение характеристики не может изменяться участником закупки - Требования к юридической значимости документов - Для обеспечения юридической значимости электронных документов должно быть обеспечено: использование усиленной квалифицированной электронной подписи в соответствии с требованиями законодательства Российской Федерации; придание юридической значимости экземплярам электронных документов путем создания электронной подписи, проверки электронной и признания квалифицированной электронной подписи в соответствии с Федеральным законом от 06 апреля 2011 года № 63-ФЗ «Об электронной подписи»; ведение журнала результатов создания электронной подписи (далее – ЭП), проверки ЭП и признания квалифицированной ЭП. Должна обеспечиваться проверка действительности сертификата ЭП на момент подписания электронного документа. При формировании электронных документов и обмене электронными документами в программе должны использоваться усиленные квалифицированные ЭП. Должна обеспечиваться возможность проверки сертификатов на действительность (валидность) посредством использования сертифицированного программно-аппаратного комплекса для построения систем юридически значимого электронного документооборота Крипто Про CSP. Подсистемы должны обеспечивать возможность подписания документов ЭП по ГОСТ Р 34.10-2012. В зависимости от жизненного цикла того или иного документа подписание может быть настроено для изменения статуса документа. Пользователи Системы должны иметь возможность настройки подписания документа штатными средствами без необходимости внесения изменений в программный код Подсистем. Один и тот же документ может подписываться ЭП неограниченное количество раз в соответствии с бизнес-процессом. - - Значение характеристики не может изменяться участником закупки - Требования к режимам функционирования подсистемы - В Подсистемах должны быть предусмотрены следующие режимы функционирования: - штатный режим; - режим технического обслуживания; Основным режимом функционирования Подсистем является штатный. В штатном режиме должна обеспечиваться доступность всех сервисов Подсистем. Штатный режим характеризуется доступностью для пользователей Подсистем в соответствии с документированными эксплуатационными характеристиками всех функций Подсистем. Режим технического обслуживания может сопровождаться полной или частичной недоступностью функциональных возможностей Подсистем. Перевод Подсистем из штатного режима в режим технического обслуживания и обратно должен производиться эксплуатирующим персоналом с использованием средств автоматизации. Порядок действий персонала в различных режимах работы Подсистем должен быть описан в руководстве администратора. - - Значение характеристики не может изменяться участником закупки - Требования к обеспечению надежности Подсистемы - Программное обеспечение Подсистем должно обладать надежностью, обеспечивающей стабильную работу пользователей. Отказы и сбои в работе серверов, баз данных и сетевого оборудования Подсистем не должны приводить к разрушению данных. Должна быть обеспечена возможность сохранения работоспособности подсистемы в рамках показателей назначения после возникновения следующих аварийных ситуаций: - отказ или сбой в работе одного или нескольких связанных компонентов ИТ-инфраструктуры: сервера, оборудования системы хранения данных, оборудования локальной вычислительной сети; - отказ (сбой) системного или прикладного обеспечения, требующий восстановления ПО и/или перезагрузки серверного оборудования, где установлено данное ПО; - ошибки в работе персонала; - импульсные помехи, сбои или прекращение электропитания. Не должно быть потерь данных при частичном отказе оборудования. - - Значение характеристики не может изменяться участником закупки - Должна поддерживаться кластерная конфигурация серверов приложений и баз данных с целью: - равномерного распределения нагрузки в штатном режиме работы оборудования; - автоматического перераспределения пользовательских сессий между функционирующими узлами кластера при отказе одного или нескольких узлов без отключения пользовательских сессий. Должна обеспечиваться поддержка технологии горизонтального масштабирования на уровне систем управления базами данных и уровне приложений, а именно: возможность использования нескольких экземпляров с целью разнесения по разным серверам при возникновении ситуации, когда используемые экземпляры ПО не справляются с нагрузкой даже при добавлении аппаратных мощностей. - Подсистемы должны обеспечивать корректную обработку ошибочных ситуаций в ППО с возможностью дальнейшего продолжения работы без аварийной остановки системного программного обеспечения и аппаратного обеспечения. При авариях и сбоях в системе электропитания после их устранения восстановление работоспособности Подсистем должно обеспечиваться путем автоматической перезагрузки программно-аппаратного комплекса Подсистем и последующего автоматического восстановления всех предоставляемых Подсистемами сервисов. В целях обеспечения надежного функционирования в Подсистемах должны быть предусмотрены: - контроль целостности программного обеспечения Подсистем; - контроль целостности данных на уровне базы данных; - контроль целостности данных, размещаемых в файловой системе; - журналирование операций в объеме, необходимом для обеспечения требуемого уровня надежности. Программное обеспечение должно обеспечивать логирование информации обо всех действиях пользователей (добавление, изменение, удаление и т.п.) в отношении объектов данных программного обеспечения. При этом должны быть зафиксированы как минимум следующие данные: пользователь, дата выполнения операции и ее тип, идентификатор изменяемого объекта. Так же должен быть реализован удобный просмотр логов (например, стек ELK). - Требования к эргономике и технической эстетике - Экранные формы должны проектироваться с учетом требований унификации: все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; для обозначения одних и тех же операций должны использоваться одинаковые графические значки, кнопки и другие управляющие (навигационные) элементы; должны быть унифицированы термины, используемые для описания идентичных понятий, операций и действий пользователя; реакция программного обеспечения на действия пользователя (наведение указателя «мыши», переключение фокуса, нажатие кнопки) должна быть типовой для каждого действия над одними и теми же графическими элементами, независимо от их расположения на экране. - - Значение характеристики не может изменяться участником закупки - Взаимодействие пользователей с программным обеспечением Подсистем должно осуществляться посредством визуального графического интерфейса. Интерфейс должен быть понятным и удобным, не должен быть перегружен графическими элементами и должен обеспечивать быстрое отображение экранных форм. Навигационные элементы должны быть выполнены в удобной для пользователя форме. Средства редактирования информации должны удовлетворять принятым соглашениям в части использования функциональных клавиш, режимов работы, поиска, использования для приложений многооконных режимов. Ввод-вывод данных в программе, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме. Интерфейс должен соответствовать современным эргономическим требованиям и обеспечивать удобный доступ к основным функциям и операциям программного обеспечения подсистемы. - Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление программным обеспечением должно осуществляться с помощью набора экранных меню, кнопок, значков и т.п. элементов. Клавиатурный режим ввода должен использоваться главным образом при заполнении и / или редактировании текстовых и числовых полей экранных форм. Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть на русском языке. Программное обеспечение Подсистем должно обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях программное обеспечение Подсистем должно выдавать пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных. - Требования к архитектуре - Архитектура Подсистем должна обеспечивать возможность непрерывного функционирования Подсистем в условиях их развития в соответствии с заданными показателями назначения. С целью повышения утилизации ресурсов и обеспечения заданных показателей назначения балансировка нагрузки в Подсистемах должна обеспечиваться при взаимодействии: - пользователя с веб-серверами; - веб-сервера с серверами приложений; - сервера приложений с серверами баз данных; - на уровне компонентов комплекса технических средств. Архитектура вычислительных платформ Подсистем должна сочетаться с виртуализацией и динамическим перераспределением ресурсов. - - Значение характеристики не может изменяться участником закупки - Требования к архитектуре технических компонентов программного обеспечения - Программное обеспечение должно быть разработано с использованием объектно-ориентированных или мультипарадигменных языков программирования. Для реализации и внедрения программного обеспечения Подсистем должен использоваться набор технологических решений, обеспечивающих: - мониторинг и логирование; - непрерывную интеграцию; - хранение и версионирование артефактов; - оркестрацию контейнеров; - контейнеризацию; - высокопроизводительную систему управления базами данных, которая использует структуру данных в памяти; - поддержку брокера сообщений; - балансировку и маршрутизацию запросов; - идентификацию и аутентификацию пользователей; - применение ключей ЭП; - управление версиями исходного кода; - файловое хранилище. - - Значение характеристики не может изменяться участником закупки

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

Количество обрабатываемых документов в день - ? 10000 - Штука - Значение характеристики не может изменяться участником закупки

Количество одновременно работающих пользователей - ? 1000 - - Значение характеристики не может изменяться участником закупки

Количество обрабатываемых запросов во внешние системы и подсистемы ГИС АСУБП в день - ? 1000 - Штука - Значение характеристики не может изменяться участником закупки

Время реакции Подсистемы при штатной нагрузке - < 8 - Секунда - Значение характеристики не может изменяться участником закупки

Время реакции Подсистемы при пиковой нагрузке - < 30 - Секунда - Значение характеристики не может изменяться участником закупки

Максимальное время ожидания ответа при получении данных от внешних систем и подсистем ГИС АСУБП - ? 300 - Секунда - Значение характеристики не может изменяться участником закупки

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

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

Требования к функциональности реестра типов соглашений (договоров) - Обеспечение возможности формирования и ведения перечня типов соглашений (договоров) с указанием по ним следующих данных: - наименование типа; - перечень сторон соглашения (договора) с возможностью настройки указания платежных реквизитов по ним; - признак формирования соглашения в соответствии с требованиями порядка ведения реестра соглашений (договоров) о предоставлении из бюджетов бюджетной системы РФ субсидий и бюджетных инвестиций юридическим лицам, индивидуальным предпринимателям, физическим лицам – производителям товаров, работ, услуг и межбюджетных трансфертов бюджетам бюджетной системы РФ, предусмотренного абз. 14 п. 1 ст. 166.1 БК РФ; признак указания в соглашении (договоре) сведений о капитальных вложениях; признак указания в соглашении (договоре) сведений о результатах предоставления бюджетных средств. - - Значение характеристики не может изменяться участником закупки

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

Требования к функциональности реестра шаблонов соглашений (договоров) - Обеспечение возможности формирования шаблона соглашения (договора) путем копирования другого доступного шаблона. - - Значение характеристики не может изменяться участником закупки

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

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

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

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

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

Обеспечение следующих возможностей: формирование печатной формы документа в одном из следующих форматов: DOC, DOCX, PDF; формирование документа путем копирования другого документа; обеспечение процессов формирования листов согласования для сторон соглашений (договоров); обеспечение процессов рассмотрения сторонами соглашений (договоров); обеспечение процессов подписания сторонами соглашений (договоров); согласования и утверждения соглашений (договоров) с механизмом подписания УКЭП уполномоченного лица. Должна обеспечиваться проверка действительности сертификата УКЭП уполномоченного лица на момент подписания соглашения (договора); формирование новой версии документа в случае наложения отрицательной резолюции; внесение изменений в соглашение (договор) путем формирования дополнительного соглашения (договора) к соглашению (договору).

Требования к функциям ведения реестра типов отчетов - Обеспечение возможности ведения реестра типов отчетов, который должен обеспечивать пользователя возможностями формирования и согласования отчетов. Документом основанием для формирования отчета должно являться соглашение (договор). Должны учитываться сведения: - наименование типа; - признак формирования отчета в соответствии с требованиями порядка ведения реестра соглашений (договоров) о предоставлении из бюджетов бюджетной системы РФ субсидий и бюджетных инвестиций юридическим лицам, индивидуальным предпринимателям, физическим лицам – производителям товаров, работ, услуг и межбюджетных трансфертов бюджетам бюджетной системы РФ, предусмотренного абз. 14 п. 1 ст. 166.1 БК РФ. - - Значение характеристики не может изменяться участником закупки

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

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

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

Раздел «Общие сведения» отчета должен включать следующие реквизиты: - системный номер; - номер соглашения; - номер редакции соглашения; - дата создания; - дата, на которую формируется отчет; - тип отчета; - наименование отчета; - шаблон отчета; - данные предоставителя отчета; - данные получателя отчета.

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

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

Обеспечение следующих возможностей: - формирование печатной формы документа в одном из следующих форматов: DOC, DOCX, PDF; - формирование документа путем копирования другого документа; - обеспечение процессов формирования листов согласования для сторон отчетов; - обеспечение процессов рассмотрения сторонами отчетов; - обеспечение процессов подписания сторонами отчетов; - согласования и утверждения отчетов с механизмом подписания УКЭП уполномоченного лица. Должна обеспечиваться проверка действительности сертификата УКЭП уполномоченного лица на момент подписания отчета; - формирование новой версии документа в случае наложения отрицательной резолюции; - внесение изменений в отчет путем формирования уточнения к отчету.

Требования к способам и средствам связи для информационного обмена между компонентами ГИС АСУБП - Взаимодействие подсистемы отбора получателей субсидий с подсистемой ведения соглашений (договоров) Взаимодействие с подсистемой «НСИ» Взаимодействие подсистемы отбора получателей субсидий с подсистемой проектирования бюджета Сахалинской области - - Значение характеристики не может изменяться участником закупки

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

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

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

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

Требования к взаимодействию с внешними информационными системами - Взаимодействие с ГИИС «Электронный бюджет» Взаимодействие с открытыми данными Центрального банка России Взаимодействие подсистемы отбора получателей субсидий с СМЭВ Взаимодействие подсистемы отбора получателей субсидий с открытыми данными ФНС Взаимодействие подсистемы отбора получателей субсидий с Федеральной службой по финансовому мониторингу (Росфинмониторинг) Взаимодействие подсистемы отбора получателей субсидий с открытыми данными Федерального казначейства (ФК) Реализация процесса автоматической проверки заявок участников на соответствие требованиям объявления об отборе - - Значение характеристики не может изменяться участником закупки

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

Требования к взаимодействию с открытыми данными Центрального банка России - Взаимодействие должно осуществляться в части загрузки открытой информации о зарегистрированных на территории РФ кредитных организациях для наполнения справочника Подсистемы «Банки». Условия запуска процессов получения данных, а также ожидаемые результаты описаны в Таблице 6 Технического задания (приложения к описанию объекта закупки). Обновление информации должно осуществляться автоматически в соответствии с периодичностью, заданной в планировщике задач. При наличии расхождения данных для записей с одинаковым идентификатором должна формировать новая версия записи справочника. Действующей будет считаться последняя версия документа. - - Значение характеристики не может изменяться участником закупки

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

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

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

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

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

Проверки должны выполняться по алгоритму, описанному в разделе Требования к взаимодействию подсистемы отбора получателей субсидий с Федеральной службой по финансовому мониторингу (Росфинмониторинг). По требованию «участник отбора получателей субсидий, являющийся юридическим лицом, не должен находиться в процессе реорганизации (за исключением реорганизации в форме присоединения к юридическому лицу, являющемуся участником отбора получателей субсидий, другого юридического лица), ликвидации, в отношении него не введена процедура банкротства, деятельность получателя субсидии не должна быть приостановлена в порядке, предусмотренном законодательством Российской Федерации, а получатель субсидии, являющийся индивидуальным предпринимателем, не должен прекратить деятельность в качестве индивидуального предпринимателя» проверки должны осуществляться путем получения выписки о состоянии участника из открытых данных реестров ЕГРЮЛ / ЕГРИП в зависимости от типа субъекта экономической деятельности. Данное требование для успешной проверки необходимо разбить на четыре отдельных самостоятельных требования, которые будут добавляться автоматически в субсидию в зависимости от указанных типов субъектов экономической деятельности: юридическое лицо не проходит процедуру ликвидации; юридическое лицо не находится в процессе реорганизации; не введена процедура банкротства; деятельность не приостановлена в порядке, предусмотренном законодательством Российской Федерации (проверка осуществляется через СМЭВ, см. раздел Требования к взаимодействию подсистемы отбора получателей субсидий с СМЭВ). Заказчик должен быть зарегистрирован на ФНС ВПД (иметь личный кабинет с доступом к сервисам, перечисленным в Таблице 7 Технического задания (приложения к описанию объекта закупки), для успешного осуществления автопроверки участников. Источник данных для осуществления проверки и ожидаемые результаты описаны в Таблице 8 Технического задания (приложения к описанию объекта закупки).

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

Требования к взаимодействию подсистемы отбора получателей субсидий с открытыми данными Федерального казначейства (ФК) - Взаимодействие будет осуществляться в части получения данных, необходимых для реализации автоматической проверки на отсутствие участника в реестре недобросовестных поставщиков (подрядчиков, исполнителей) по данным https://zakupki.gov.ru. Для получения файла с данными о организациях и индивидуальных предпринимателях, внесенных в реестр, необходимо пройти регистрацию в личном кабинете на сайте Единой информационной системы (ЕИС), https://zakupki.gov.ru. Проверка должна выполняться по алгоритму, описанному в разделе Требования к взаимодействию подсистемы отбора получателей субсидий с Федеральной службой по финансовому мониторингу (Росфинмониторинг). Источник данных для осуществления проверки и ожидаемые результаты описаны в Таблице 10 Технического задания (приложения к описанию объекта закупки). - - Значение характеристики не может изменяться участником закупки

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

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

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

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

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

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

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

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

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

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

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

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

Требования к функции «Автоматическая отправка данных по принимаемым бюджетным обязательствам в подсистему проектирования бюджета Сахалинской области» - В Подсистеме должна быть предусмотрена настройка, доступная только пользователя с ролью «Администратор». Настройка должна определять возможность автоматической отправки данных по принимаемым бюджетным обязательствам после утверждения документа «Объявление об отборе» в подсистему проектирования бюджета ГИС АСУБП, «Автоматическое резервирование/высвобождение принимаемых БО» – значения, которые может принимать «Да/Нет». Эта настройка должна влиять на поведение системы при переходе «Объявления об отборе» в статус «Утвержден» / «Отменен». Если установлено значение «Да», то после перехода «Объявления об отборе» в статус «Утвержден», автоматически информация о финансовом обеспечении объявления об отборе (номер документа, КБК, суммы, года) направляется в систему проектирования бюджета ГИС АСУБП. Или после перехода «Объявления об отборе» в статус «Отменен», автоматически информация о номере документа направляется в систему проектирования бюджета ГИС АСУБП и зарезервированные денежные средства высвобождаются, давая возможность использовать их для проведения других отборов. - - Значение характеристики не может изменяться участником закупки

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

Механизм формирования реестровых номеров должен обеспечивать: - уникальность номеров, номера не должны повторяться для разных сущностей; - формат номера должен иметь определенную структуру; - неизменность, реестровый номер не должен меняться в процессе существования сущности, при внесении изменений в документ, при создании новых версий документа; - автоматизация, номера должны создаваться автоматически при добавлении новой сущности по правилам, заданным на рабочем месте Администратора в разделе «Формирование реестровых номеров документов»; - целостность реестровых номеров, один номер должен быть привязан к одному документу.

Требования к функции «Управление ролями, группами пользователей и правами доступа» - Разделы и документы системы в отношении которых может быть осуществлена настройка прав доступа: - Справочники; - Комиссии; - Субсидии; - Отборы; - Протокол вскрытия заявок: - Протокол рассмотрения заявок; - Протокол подведения итогов; - Протоколы; - Заявки участников; - Заявки; - Оценка заявок; - Валидация; - Мои экспертизы; - Распределение средств по итогам отбора; - Шаблоны заявок участников; - Шаблоны отборов; - Запросы на разъяснения; - Уведомления; - Администрирование. - - Значение характеристики не может изменяться участником закупки

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

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

Требования к интерфейсу «Журнал действий пользователей» - Интерфейс «Журнал действий пользователей» должен обеспечивать просмотр, поиск и анализ сведений о действиях пользователей в системе, а также просмотр истории обработки документов и событий пользовательских сессий. Интерфейс должен предоставлять возможность: - просмотра перечня записей журнала действий пользователей в табличном виде; - фильтрации записей журнала по пользователю, дате и времени события, типу действия, объекту действия, разделу системы, результату выполнения операции; - поиска записей журнала по идентификатору документа, наименованию документа, учетной записи пользователя и другим ключевым атрибутам; - просмотра подробной информации по каждой записи журнала; - отображения истории действий пользователя за выбранный период; - отображения пошаговой истории операций по выбранному документу с указанием последовательности действий; - просмотра сведений о том, кто, когда и какое действие выполнил; - отображения сведений о входах и выходах пользователей из системы; - отображения сведений об активных сессиях пользователей; - принудительного завершении сессии; - выгрузки данных журнала в файл в формате, определяемом требованиями Заказчика; - сортировки записей журнала по основным реквизитам; - постраничного отображения данных при большом объеме записей; - обновления списка записей журнала без перезагрузки всей страницы. - - Значение характеристики не может изменяться участником закупки

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

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

Требования к функции «Анализ и сопровождение документов» - Функция анализа и сопровождения документов должна обеспечивать возможность: - выгрузку структуры данных по документам субсидий и отборов с отображением заполненных значений и соответствующих реестров базы данных в текстовый файл; - просмотр связанных с документом объектов в едином интерфейсе без необходимости последовательного перехода по отдельным сущностям; - просмотр журнала изменений по, выбранному документу; - переход к выбранному документу, открытие карточки документа. Указанный функционал, в части выгрузки структуры данных по субсидиям и отборам, должен обеспечивать возможность анализа причин ошибок, проверки полноты формирования документов. Просмотр связанных объектов должен обеспечивать отображение взаимосвязи между сущностями субсидий, отборов, заявок участников и протоколов, формируемых в рамках системы. Функция просмотра связей между объектами должна быть доступна всем группам пользователей при наличии у них соответствующих прав. Функция просмотра связанных с документом объектов, должна обеспечивать возможность открытия журнала действий по выбранному документу. Функция перехода к выбранному документа, должна обеспечивать возможность открытия карточки документа в режиме просмотра. - - Значение характеристики не может изменяться участником закупки

Требования к функции «Настройка системных уведомлений» - Функция настройки системных уведомлений должна обеспечивать возможность: - настройка получателей уведомлений; - времени и даты формирования уведомлений, при необходимости; - настройка событий, по которым формируется уведомление, при необходимости; - настройка доступности формирования уведомлений определенным группа пользователей с учетом их прав; - настройка содержания уведомлений. В качестве событий, в рамках которых пользователям могут направляться уведомления, могут быть: - завершение сроков по этапам: - переход отбора/субсидии на определенный этап; - изменение статусов документов; - завершение работы с заявками валидаторов, экспертов, членов комиссии; - информация о заключенном соглашении; - ошибки в системе (для администратора). Пользователь с ролью Администратор, должен иметь возможность сформировать стандартное системное уведомления, без привязки к заранее определенным в настройках событиям. - - Значение характеристики не может изменяться участником закупки

Общие требования к развитию Подсистем - Исполнитель может оказать услуги по развитию Подсистем способом разработки ПО в рамках оказания услуг по настоящему Техническому заданию или способом адаптации принадлежащего Подрядчику на законных основаниях ПО при условии соблюдения принципа однократного ввода и многократного использования информации в Подсистемах. При оказании услуг по развитию Подсистем способом разработки ПО в рамках оказания услуг по настоящему Техническому заданию, должен обеспечить его совместимость и взаимодействие с уже функционирующими компонентами развиваемых Подсистем, на базе которых созданы и функционируют развиваемые Подсистемы, для сохранения принципа однократного ввода информации, подлежащей учету, и обеспечения единообразия интерфейса. При оказании услуг по развитию Подсистем способом адаптации ПО Исполнитель может проводить её в том числе путем параметрической настройки, изменения скриптов, конфигурационных файлов, в том числе файлов, учитывающих параметры оборудования Заказчика и необходимых для привязки адаптируемого ПО к оборудованию Заказчика и т.п. Исполнитель должен уведомить Заказчика о выбранном способе оказания услуг в соответствии с требованиями настоящего Технического задания и условиями Контракта в течение 5 (Пяти) рабочих дней с даты заключения Контракта. - - Значение характеристики не может изменяться участником закупки

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

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

Требования к программному обеспечению - Должна быть обеспечена возможность использования сертифицированных в соответствии с законодательством Российской Федерации средств защиты информации. Программное обеспечение Подсистем должно обеспечивать заданные функциональные требования к Подсистемам, включая достижение заданных показателей назначения. Подсистемы должны позволять осуществлять настройку программных компонентов и дальнейшее развитие их функциональности. Программное обеспечение Подсистем должно быть реализовано в трехзвенной архитектуре на базе веб-технологий. Программное обеспечение Подсистем должно иметь клиент-серверную архитектуру, в следующем минимальном составе: сервер СУБД. сервер приложений; сервер хранения данных; сервер логирования данных; веб-сервер; сервер для резервного копирования данных. Клиентское приложение должно базироваться на использовании Интернет-браузера, включенного в «Единый реестр российских программ для электронных вычислительных машин и баз данных» (https://reestr.minsvyaz.ru/reestr/) и использующего протокол ГОСТ TLS. Вся логика обработки данных должна реализовываться сервером приложений. Для каждого программного компонента Подсистем должны быть разработаны и включены в состав рабочей документации детальные инструкции по его установке и настройке. - - Значение характеристики не может изменяться участником закупки

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

Требования к юридической значимости документов - Для обеспечения юридической значимости электронных документов должно быть обеспечено: использование усиленной квалифицированной электронной подписи в соответствии с требованиями законодательства Российской Федерации; придание юридической значимости экземплярам электронных документов путем создания электронной подписи, проверки электронной и признания квалифицированной электронной подписи в соответствии с Федеральным законом от 06 апреля 2011 года № 63-ФЗ «Об электронной подписи»; ведение журнала результатов создания электронной подписи (далее – ЭП), проверки ЭП и признания квалифицированной ЭП. Должна обеспечиваться проверка действительности сертификата ЭП на момент подписания электронного документа. При формировании электронных документов и обмене электронными документами в программе должны использоваться усиленные квалифицированные ЭП. Должна обеспечиваться возможность проверки сертификатов на действительность (валидность) посредством использования сертифицированного программно-аппаратного комплекса для построения систем юридически значимого электронного документооборота Крипто Про CSP. Подсистемы должны обеспечивать возможность подписания документов ЭП по ГОСТ Р 34.10-2012. В зависимости от жизненного цикла того или иного документа подписание может быть настроено для изменения статуса документа. Пользователи Системы должны иметь возможность настройки подписания документа штатными средствами без необходимости внесения изменений в программный код Подсистем. Один и тот же документ может подписываться ЭП неограниченное количество раз в соответствии с бизнес-процессом. - - Значение характеристики не может изменяться участником закупки

Требования к режимам функционирования подсистемы - В Подсистемах должны быть предусмотрены следующие режимы функционирования: - штатный режим; - режим технического обслуживания; Основным режимом функционирования Подсистем является штатный. В штатном режиме должна обеспечиваться доступность всех сервисов Подсистем. Штатный режим характеризуется доступностью для пользователей Подсистем в соответствии с документированными эксплуатационными характеристиками всех функций Подсистем. Режим технического обслуживания может сопровождаться полной или частичной недоступностью функциональных возможностей Подсистем. Перевод Подсистем из штатного режима в режим технического обслуживания и обратно должен производиться эксплуатирующим персоналом с использованием средств автоматизации. Порядок действий персонала в различных режимах работы Подсистем должен быть описан в руководстве администратора. - - Значение характеристики не может изменяться участником закупки

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

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

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

Требования к эргономике и технической эстетике - Экранные формы должны проектироваться с учетом требований унификации: все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; для обозначения одних и тех же операций должны использоваться одинаковые графические значки, кнопки и другие управляющие (навигационные) элементы; должны быть унифицированы термины, используемые для описания идентичных понятий, операций и действий пользователя; реакция программного обеспечения на действия пользователя (наведение указателя «мыши», переключение фокуса, нажатие кнопки) должна быть типовой для каждого действия над одними и теми же графическими элементами, независимо от их расположения на экране. - - Значение характеристики не может изменяться участником закупки

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

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

Требования к архитектуре - Архитектура Подсистем должна обеспечивать возможность непрерывного функционирования Подсистем в условиях их развития в соответствии с заданными показателями назначения. С целью повышения утилизации ресурсов и обеспечения заданных показателей назначения балансировка нагрузки в Подсистемах должна обеспечиваться при взаимодействии: - пользователя с веб-серверами; - веб-сервера с серверами приложений; - сервера приложений с серверами баз данных; - на уровне компонентов комплекса технических средств. Архитектура вычислительных платформ Подсистем должна сочетаться с виртуализацией и динамическим перераспределением ресурсов. - - Значение характеристики не может изменяться участником закупки

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

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

Преимущества: Не установлены

Требования к участникам: 1. Единые требования к участникам закупок в соответствии с ч. 1 ст. 31 Закона № 44-ФЗ 2. Требования к участникам закупок в соответствии с ч. 1.1 ст. 31 Закона № 44-ФЗ 3. Требование к участникам закупок в соответствии с п. 1 ч. 1 ст. 31 Закона № 44-ФЗ Дополнительные требования Требования по п.1 ч.1 ст.31 44-ФЗ не установлены 4. Требование к поставщику (подрядчику, исполнителю), не являющемуся субъектом малого предпринимательства или социально ориентированной некоммерческой организацией, о привлечении к исполнению контракта субподрядчиков, соисполнителей из числа субъектов малого предпринимательства, социально ориентированных некоммерческих организаций в соответствии с ч. 5 ст. 30 Закона № 44 ФЗ Дополнительные требования Объем привлечения 30% от цены контракта 5. Требования к участникам закупок в соответствии с ч. 2.1 ст. 31 Закона № 44-ФЗ 5.1? Требования в соответствии c пунктом 4 ПП РФ от 29.12.2021 №2571 Дополнительные требования Наличие у участника закупки опыта исполнения (с учетом правопреемства) в течение трех лет до даты подачи заявки на участие в закупке контракта или договора, заключенного в соответствии с Федеральным законом от 18 июля 2011 года № 223-ФЗ «О закупках товаров, работ, услуг отдельными видами юридических лиц» при условии исполнения таким участником закупки требований об уплате неустоек (штрафов, пеней), предъявленных при исполнении таких контракта, договора. Стоимость исполненных обязательств по таким контракту, договору должна составлять не менее двадцати процентов начальной (максимальной) цены контракта. Информация и документы, подтверждающие соответствие участника закупки дополнительному требованию, установленному в соответствии с частью 2.1 ст. 31 Закона о контрактной системе, являются информация и документы, предусмотренные хотя бы одним из следующих подпунктов: а) номер реестровой записи в предусмотренном Законом о контрактной системе реестре контрактов, заключенных заказчиками (в случае исполнения участником закупки контракта, информация и документы в отношении которого включены в установленном порядке в такой реестр и размещены на официальном сайте единой информационной системы в информационно-телекоммуникационной сети "Интернет"); б) выписка из предусмотренного Законом о контрактной системе реестра контрактов, содержащего сведения, составляющие государственную тайну (в случае исполнения участником закупки контракта, информация о котором включена в установленном порядке в такой реестр); в) исполненный контракт, заключенный в соответствии с Законом о контрактной системе, или договор, заключенный в соответствии с Федеральным законом "О закупках товаров, работ, услуг отдельными видами юридических лиц", а также акт приемки поставленных товаров, выполненных работ, оказанных услуг, подтверждающий цену поставленных товаров, выполненных работ, оказанных услуг. Показать все (6)

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

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

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

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

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

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

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

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

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

Наименование бюджета: областной бюджет Сахалинской области

Вид бюджета: бюджет субъекта Российской Федерации

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

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

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

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

Реквизиты счета для учета операций со средствами, поступающими заказчику: p/c 03222643640000006100, л/c 05016000900, БИК 016401800, ОКЦ № 5 ДГУ Банка России//УФК по Сахалинской области, г Южно-Сахалинск, к/c 40102810845370000053

Место поставки товара, выполнения работы или оказания услуги: Российская Федерация, обл. Сахалинская, г.о. город Южно-Сахалинск, г. Южно-Сахалинск, пр-кт Коммунистический, д. 32, Услуги оказываются удаленно.

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

Размер обеспечения исполнения контракта: 2 000 000,00 Российский рубль (10 %)

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

Платежные реквизиты для обеспечения исполнения контракта: p/c 03222643640000006100, л/c 05016000900, БИК 016401800, ОКЦ № 5 ДГУ Банка России//УФК по Сахалинской области, г Южно-Сахалинск, к/c 40102810845370000053

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

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

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

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

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

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

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

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

Наименование бюджета: областной бюджет Сахалинской области

Вид бюджета: бюджет субъекта Российской Федерации

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

Документы

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

Документы

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