Партнерка на США и Канаду по недвижимости, выплаты в крипто

30% recurring commission
Выплаты в USDT
Вывод каждую неделю
Комиссия до 5 лет за каждого referral

Приложение

к запросу котировок цен

Требования к техническим характеристикам услуг.

1. Требования к системе

1.1. Общие требования к программному комплексу

Система должна обеспечивать:

Ведение реестра контрактов в электронном виде в соответствии с положением утвержденным постановлением Правительства Российской Федерации от 01.01.01 г. № 000 (далее Постановления). Подготовку сведений о контрактах и их исполнении (расторжении) получателями бюджетных средств и прием сведений уполномоченным органом в электронном виде Подготовку документации, отражение проведения и учет закупочных процедур в соответствии с требованиями действующей редакции федерального закона от 01.01.2001 г. "О размещении заказов на поставки товаров, выполнение работ, оказание услуг для государственных и муниципальных нужд" (далее Закона). Функционирование официального сайта муниципальных закупок в сети Интернет. Публикацию реестра контрактов и информации о закупках на официальном сайте муниципальных закупок

1.2. Требования к структуре и принципам использования

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

Автоматизированное рабочее место заказчика (РМЗ) для подготовки сведений о контрактах Система управления реестром (СУР) Система управления закупками (СУЗ) Сайт муниципальных закупок в сети интернет (Сайт)

Программное обеспечение РМЗ – однопользовательское автономное приложение, не требующее подключения к СУР по телекоммуникационным каналам и предназначенное для установки на компьютеры муниципальных заказчиков, и подготовки ими сведений о контрактах в электронном и печатном виде.

НЕ нашли? Не то? Что вы ищете?

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

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

Файлы, содержащие сведения, должны передаваться в УО. Данные из поданных файлов должны автоматически по команде пользователя должны загружаться в систему управления реестром. Специалисты УО средствами системы управления реестром должны иметь возможность проверять загруженные данные и вносить, на их основании изменения в реестр контрактов.

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

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

1.3. Требования к рабочему месту заказчика

1.3.1. Требования к рабочему месту

CPU не хуже Intel Celeron 1000, ОЗУ не менее 250Mb, свободное место на жестком диске не менее 200 Мб.

Установленная ОС семейства MS Windows или Linux

Офисный пакет Microsoft Office 2000 или новее, либо Open Office 2.3 или новее.

1.3.2. Требования к функционалу программного обеспечения РМЗ

Автоматизированное рабочее должно обеспечивать пользователю возможность:

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

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

С программным обеспечением РМЗ должны поставляться и использоваться при заполнении сведений следующие справочники:

ОКП - общероссийский классификатор продукции справочник "Бюджеты" справочник "Виды внебюджетных средств" справочник "Способы размещения заказа" ОКЕИ - общероссийский классификатор единиц измерения ОКВ - общероссийский классификатор валют ОКСМ - общероссийский классификатор стран мира справочник "Способы размещения заказа" справочник "Наименований источников финансирования" справочник "Статусы поставщиков" справочник "Типы изменений" Справочник «Основания заключения контракта с единственным поставщиком»

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

Все справочники должны быть доступными из программного обеспечения РМЗ и использоваться при заполнении соответствующих полей сведений о контрактах. Справочник ОКП должен быть представленным в виде иерархии и поддерживать поиск по полям «код» и «наименование».

Программное обеспечение РМЗ должно обеспечивать возможность автоматического заполнения раздела 3 сведений о заключении контракта, данными из специально подготовленного файла в формате MS Excel.

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

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

2. Требования к системе управления реестром

2.1. Требования к архитектуре

Система управления реестром (СУР) должна обеспечивать одновременную работу нескольких пользователей с данными хранящимися в единой СУБД.

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

Двухзвенная — система из двух компонент: СУБД и приложение рабочего стола «Клиент Системы управления реестром» Трехзвенная — система из трех компонент: СУБД, сервер системы управления реестром и «Клиент Системы управления реестром»

2.2. Требования к компонентам

2.2.1. СУБД

Система управления реестром должна использовать для хранения и обработки данных реляционную СУБД. В качестве СУБД система управления реестром должна позволять использовать следующие программные продукты:

Database Oracle 10g СУБД PostgreSQL 8.4 СУБД Apache Derby

Лицензия на СУБД должна входить в состав поставляемого с системой программного обеспечения.

2.2.2. Сервер системы управления реестром

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

Сервер СУР должен иметь возможность функционировать под управлением серверных операционных систем семейства Windows и семейства Linux.

2.2.3. Клиент системы управления реестром

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

Требования компьютеру для развертывания Клиента:

CPU не хуже Intel Celeron 1000, ОЗУ не менее 512Mb, свободное место на жестком диске не менее 200 Мб. ОС семейства MS Windows или Linux Офисный пакет Microsoft Office 2000 или новее, либо Open Office 2.3 или новее.

Для работы в двухзвенной архитектуре компьютеры на которых развернут клиент должны иметь доступ к серверу СУБД по протоколу TCP/IP.

Для работы в трехзвенной архитектуре клиенту не должен требоваться непосредственный доступ к серверу СУБД. Взаимодействие с сервером системы управления реестром должно осуществляться по протоколам HTTP или HTTPS по выбору администратора системы.

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

Работы через прокси-сервер, в том числе требующий авторизации; Автоматическую установку и обновление программных компонентов с сервера по протоколу HTTP/HTTPS, при запуске клиента.

2.3. Установка и начальная настройка

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

2.4. Требования к функционалу СУР

2.4.1. Общие требования

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

Управление доступом пользователей к функциям и данным системы, с разделением функций по ролям; Управление реестрами получателей и распорядителей бюджетных средств; Ведение журнала входящих сведений; Продвижение входящих сведений по статусам (на рассмотрении, в реестре, отказан, проверен); Управление реестром контрактов; Получение печатных форм сведений о контрактах в формате RTF; Получение печатной формы реестра контрактов в форматах HTML и MS Excel; Получение аналитической отчетности о состоянии дел по приему и рассмотрению сведений; Получение аналитической отчетности о состоянии дел по заключению и исполнению контрактов; Анализ истории изменения реестровой записи; Протоколирование действий пользователей в системе;

2.4.2. Управление пользователями

СУР должна предоставлять возможность администратору создавать и удалять учетные записи пользователей, назначать им пароли и сроки действия паролей, включать пользователя в одну или несколько групп безопасности.

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

В СУР должны быть предусмотрены следующие группы безопасности (роли пользователей): администратор, менеджер, уполномоченное лицо, пользователь.

Права для роли "Пользователь":

1. загрузить документ из файла в базу;

2. выполнить "контроль";

3. присвоить заказчика;

4. перевести док. в состоянии "на рассмотрении" в состояние "проверен";

5. перевести док. в состоянии "проверен" обратно в состояние "на рассмотрении";

6. выполнить отказ

Права для роли "Уполномоченное лицо"

1. загрузить документ из файла в базу;

2. выполнить "контроль";

3. присвоить заказчика;

4. перевести док. в состоянии "на рассмотрении" в состояние "проверен";

5. перевести док. в состоянии "проверен" обратно в состояние "на рассмотрении";

6. выполнить отказ;

7. внести в реестр изменения на основании документа в состояниях "проверен" ; или "на рассмотрении"

8. отменить отказ.

Права для роли "Менеджер":

1. загрузить документ из файла в базу

2. выполнить "контроль"

3. присвоить заказчика

4. перевести док. в состоянии "на рассмотрении" в состояние "проверен"

5. перевести док. в состоянии "проверен" обратно в состояние "на рассмотрении"

6. выполнить отказ

7. внести в реестр изменения на основании документа в состояниях "проверен"

или "на рассмотрении"

8. отменить отказ

9. удалить ошибочно загруженный документ

Пользователи с ролью Администратор — должны иметь полный доступ ко всем функциям СУР.

2.4.3. Справочники

В СУР должно быть предусмотрено ведение следующих справочников:

справочник организаций справочник заказчиков справочник ГРБС

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

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

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

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

Справочник ГРБС содержит одно поле - ссылка на организацию в справочнике организаций.

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

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

2.4.4. Журнал входящих сведений

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

2.4.5. Работа со сведениями

СУР должна позволять пользователю выполнить над файлами сведений поданными заказчиком в уполномоченный орган следующие процедуры:

базу данных

внесения изменений

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

2.4.6. Загрузка сведений

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

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

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

2.4.7. Проверка сведений

СУР должна позволять пользователю выполнить проверку соответствия сведений требованиям Постановления, по результатом которой, пользователь должен получить отчет о нарушенных правилах.

2.4.8. Проверка возможности внесения изменений в реестр

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

2.4.9. Внесение изменений в реестр

При внесении первичных сведений о заключении контракта в системе должна создаваться новая запись в реестре контрактов. Реестровой записи должен автоматически присваиваться уникальный номер в соответствии с требования положений Постановления.

При внесение в реестр изменений на основании всех видов сведений система должна автоматически формировать и заполнять поля «номер» и «дата» последнего изменения.

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

У администратора системы должна быть возможность «принудительно» создать реестровую запись с произвольными номером реестровой записи и датой последнего изменения. При этом система должна осуществлять контроль за уникальностью реестрового номера.

2.4.10. Отмена внесения изменений в реестр

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

2.5. Требования к отчетности

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

2.5.1. «Отчёт об объемах работ»

Должен позволяет оценить за произвольный период, по каждому ГРБС:

количество поданных сведений количество сведений внесенных в реестр количество сведений по которым принято решение об отказе от внесения в реестр количество не рассмотренных сведений по состоянию на начало и конец указанного периода

2.5.2. «Реестр контрактов»

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

ГРБС Заказчик Период в который заключен контракт Период в который произошли изменения Наличие измененных сведений Отсутствие измененных сведений Произвольная комбинация способов размещения Наименование поставщика ИНН поставщика Особый статус поставщика

2.5.3. «Отчёт о внесении изменений в реестр»

Должен позволять получить в отношении внесенных в реестр за выбранный период сведений, по каждому ГРБС следующие показатели:

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

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

2.5.4. «Отчёт о внесении изменений в реестр по видам бюджета»

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

2.5.5. «Отчёт о внесении в реестр контрактов заключенных способом «Закупка у единственного источника»»

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

Система должна позволять проанализировать этот показатель с разбивкой по следующим критериям, или их комбинации:

Номер пункта и статьи Закона, на основании которого была проведена закупка у единственного источника ГРБС Заказчик

3. Требования к системе управления закупками

3.1. Требования к архитектуре

Система управления закупками (СУЗ) должна обеспечивать одновременную работу нескольких пользователей с данными хранящимися в единой СУБД.

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

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

2. В виде единой интегрированной системы управления закупками, включающей эквивалентный функционал модулей по подготовке документации для проведения котировок и аукционов и непосредственно системы управления закупками.

Система управления закупками должна состоять из двух компонент: СУБД и приложения рабочего стола — клиента системы управления закупками»

3.2. Требования к компонентам

3.2.1. СУБД

Система управления закупками должна использовать для хранения и обработки данных реляционную СУБД. В качестве СУБД система управления реестром должна позволять использовать следующие программные продукты:

Database Oracle 10g СУБД PostgreSQL 8.4 СУБД Apache Derby

Лицензия на СУБД должна входить в состав поставляемого с системой программного обеспечения.

3.2.2. Сервер системы управления закупками

Сервер СУЗ должен иметь возможность функционировать под управлением серверных операционных систем семейства Windows и семейства Linux.

3.2.3 Автономный модуль автоматизации подготовки документации для проведения котировок

Модуль должен позволять пользователю выполнять следующие функции:

1. Позволять пользователю вносить данные о котировке: наименование, максимальная цена, место проведения, условия поставки (выполнения работ, оказания услуг), требования к поставляемым товарам, оказываемым услугам, выполняемым работам;

2. Подготовку к котировке, в ходе которой производится допуск заявок к участию;

3. Зафиксировать дату и время проведения котировки

4. Формировать протокол определения победителя котировки - модуль должен позволять получить печатную форму протокола в виде файла в формате совместимом с офисными пакетами Microsoft Office и Open Office. Вывести протокол на печать.

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

3.2.4 Автономный модуль подготовки документации для проведения аукционов

Модуль должен позволять пользователю выполнять следующие функции:

6. Позволять пользователю вносить данные об аукционе: наименование аукциона, начальная цена, место проведения, лоты аукциона, и т. д.

7. Подготовку к аукциону, в ходе которой производится регистрация участников, допуск участников к торгам, с присвоением им порядковых номеров.

8. Формирование протокола допуска участников с приложением.

9. Подготовку к проведению торгов Аукциона, регистрацию участников допущенных к участию в торгах, с присвоением им порядковых номеров.

10. Зафиксировать дату и время начла аукциона

11. Выбрать лот, при этом наименование и начальная цена лота отобразятся на «Аукционном табло»

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

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

14. Формировать протокол проведения открытого аукциона - модуль должен позволять получить печатную форму протокола в виде файла в формате совместимом с офисными пакетами Microsoft Office и Open Office. Вывести протокол на печать.

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

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

3.2.5 Клиент системы управления закупками

Требования компьютеру для развертывания Клиента:

3.2.5.1 Требования к автоматизации запросов котировок

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

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

3.2.5.2 Требования к автоматизации открытых аукционов

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

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

3.2.5.3 Требования к функциям импорта данных

Система должна обеспечивать автоматическое заполнение табличной части раздела «Товары/работы/услуги» формы «Извещение о запросе котировок» из специально подготовленного файла в формате Microsft Excel 97/2000/XP(*.xls). Система должна позволить указать в таком файле по каждой позиции запроса котировок: Наименование товара/работы/услуги, единицу измерения, количество поставляемых единиц или объем работ/услуг, а также требования к товару/работе/услуге в форме строки текста.

Система должна обеспечивать автоматическое заполнение перечня лотов из специально подготовленного файла в формате Microsft Excel 97/2000/XP(*.xls) при подготовке открытого аукциона. Система должна позволять указать в таком файле для каждого лота: номер лота, наименование, начальную цену и одно требование к лоту в форме строки текста.

3.2.5.4 Требования к функции учета соблюдения сроков подачи сведений

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

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

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

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

Текст письма должен формироваться системой в виде файла в формате RTF на основании шаблона в формате RTF подготовленного и размещенного в системе специалистом заказчика. Пример такого шаблона должен поставляться с системой.

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

1. Почтовый адрес и официальное наименование заказчика

Почтовый адрес и официальное наименование отправителя Фамилия имя отчество, должность и пол (для формирования обращения) получателя Фамилия имя отчество, должность и телефон отправителя

3.2.5.5 Требование к функции планирования процедур

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

1. Количество уже назначенных на этот день заседаний

2. Действующий регламент с точки зрения дней на которые могут назначаться заседания комиссий

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

1. Дни на которые запрещено назначать заседания комиссии регламентом

2. Дни на которые назначены еще не проведенные заседания комиссий

3. Выходные и праздничные дни

4. Прочие дни

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

Система должна считать заседание котировочной комиссии назначенным и не проведенным, если в системе существует опубликованное извещение, с датой больше или равной системной дате. Датой и временем заседания котировочной комиссии система должна считать дату и время окончания приема заявок, указанные в извещении.

Система должна считать заседание комиссии по рассмотрению заявок на участие в открытом аукционе назначенным если, в системе существует опубликованное извещение о проведении аукциона, с датой окончания приема заявок больше или равной системной дате. Датой и временем заседания система должна считать дату и время окончания приема заявок.

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

Системная дата должна определятся часами на сервере СУБД.

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

3.3 Прочие требования

1. Система должна обеспечивать возможность автоматического формирования отчета по форме Росстата №1-торги, в объеме, позволяющем его сформировать на основе данных, хранящихся в системе. Отчет должен формироваться в формате Microsft Excel 97/2000/XP(*.xls). Поля, значения которых не могут быть рассчитаны, должны быть оставлены пустыми.

2. В системе должен быть предусмотрен модуль формирования произвольных запросов к БД и последующей выгрузкой результатов в форматы Microsft Excel 97/2000/XP(*.xls) средствами администратора. Необходима возможность многократного использования таких запросов пользователями. Модуль должен сопровождаться

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

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

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

4. Требования к системе публикации (cайту)

4.1. Требования к компонентам

4.1.1. СУБД

Система публикации должна использовать для хранения и обработки данных реляционную СУБД. В качестве СУБД система управления реестром должна позволять использовать следующие программные продукты:
Database Oracle 10g СУБД PostgreSQL 8.4 СУБД Apache Derby
Лицензия на СУБД должна входить в состав поставляемого с системой программного обеспечения.

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

Система обеспечивает публикацию в сети Интернет в открытом доступе следующих разделов:

4.1.2 Требования к функционалу

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