Способы закупок и требования к участникам

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

Три уровня настроек

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

Большинству хватает первого и третьего.

Почему второй уровень настраивает оператор

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

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

Требование — то, что предъявляется подрядчику и по чему его заявку допускают. Набор задаётся редакцией: она готовится заранее и вступает в силу датой, как справочники.

Правила, которые стоит помнить:

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

Чек-листы требований

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

Правила:

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

Разрешительные документы

Тип требования называется «Разрешительный документ», а не «Лицензия», потому что подрядчику ОСИ нужны все три вида сразу: лицензия (строительно-монтажные работы), разрешение (монтаж и обслуживание систем пожарной автоматики) и уведомление (охранная сигнализация).

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

Объявить такое требование системным нельзя — сверять номер не с чем. Проверка, которая всегда отвечала бы «сверить нечем», ничего не проверяет, а останавливает закупку: вердикт по такому требованию не становится решённым никогда, и подвести итог такая процедура не даёт. Появится связь с реестром — появится и провайдер проверки, а требование станет системным без правки закупок.

Проверки благонадёжности

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

Регистрацию подтверждает сам ответ реестра: подрядчика, которого КГД не знает, проверка отклоняет — отдельной отметки «зарегистрирован» реестр не выдаёт. Условие остаётся вычесть аннулированную регистрацию: такой подрядчик в реестре есть, но зарегистрированным не считается.

Заказчик их не снимает: строки закрыты платформой.
Порог задаёт условие требования. «Задолженность не более нуля» — значение по умолчанию; если понадобится смягчить, меняется условие требования — обращаться к разработчикам не нужно.
Молчащий источник — не отказ поставщику. Проверка остаётся без вердикта, итоги закупки не подводятся, а рассматривающий перезапрашивает.
Портал без связи с реестром работает как раньше: проверка честно помечается пропущенной.

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

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

Что настраивается ещё

Минимальный срок подачи заявок — не срок, а нижняя граница: заказчик может дать больше.
Порог заявок, при котором закупка считается состоявшейся.
Сколько несостоявшихся попыток открывает закупку у одного поставщика.
Комиссия — состав, который рассматривает заявки, если способ этого требует.