Перейти к материалу
Редакция закупочной аналитики Ферман Закупки
F Ферман Радар

Канал есть, модуля нет: почему ФАС вернула закупку счётчиков на 646 млн

В документации отдельно требовались поддержка PLC+RF, выбор съёмного модуля и IP64. Комиссия превратила альтернативы в новые обязательные условия — и два протокола пришлось отменить.

Специалист сверяет электросчётчик и два съёмных модуля связи с технической документацией на испытательном столе
Редакционная фотокомпозиция Ферман Радар, создана с помощью OpenAI imagegen; не изображает реальных участников закупки

ФАС России вернула на рассмотрение закупку электросчётчиков с начальной ценой 646 млн рублей. Спор возник не потому, что заявитель оставил характеристики пустыми. Заказчик перенёс обязательное значение из одной строки технического задания в другую, а диапазон исполнений модели прочитал как несоответствие конкретного товара.

Документация отдельно требовала, чтобы счётчик поддерживал канал PLC+RF. Отдельно перечисляла допустимые съёмные модули через альтернативу. Ещё одна строка задавала степень защиты IP64. Участник заполнил все три, но из трёх заявок до процедуры допустили только одну.

24 июля ЕИС отметила два протокола от 26 июня как недействующие. В карточке отмены основанием названо предписание ФАС. Нового результата пока нет, поэтому возврат заявки нельзя выдавать за победу в закупке.

Масштаб и стадия спора
646 млн ₽ начальная цена договора
3 → 1 поданные и допущенные заявки
2 оспоренные характеристики
7 августа срок подтверждения исполнения ФАС

Источник: решение и предписание ФАС № 28/07/2-2695/2026; ЕИС № 32615966003

Три строки, которые нельзя склеивать

Техническое задание содержало три самостоятельных требования:

  1. счётчик обязательно поддерживает канал передачи данных PLC+RF;
  2. для съёмных модулей связи допустимы PLC+RF или GSM/2G+4G LTE или GSM/2G+NB-IoT;
  3. степень защиты от пыли и влаги — IP64.

В техническом предложении участник указал поддержку обязательного канала PLC+RF. Для съёмных модулей он назвал RF433, GSM/2G+4G LTE и GSM/2G+NB-IoT. Две последние позиции прямо входили в опубликованный заказчиком набор альтернатив.

Комиссия отклонила заявку, потому что в строке о съёмных модулях не было PLC+RF. Тем самым союз «или» фактически заменили на «и»: один из допустимых вариантов стал обязательным вдобавок к уже подтверждённой базовой функции.

ФАС разделила строки обратно. Отсутствие съёмного модуля PLC+RF не означает, что сам прибор не поддерживает канал PLC+RF. Более того, заключение технических экспертов заказчика признало заявку соответствующей именно по базовой поддержке канала.

Слой проверки Что требовала документация Что было в предложении Где возникла ошибка
Базовая функция Обязательная поддержка канала PLC+RF Поддержка подтверждена Комиссия не спорила с этой строкой
Съёмный модуль Один или несколько вариантов из альтернативного перечня RF433 и оба допустимых GSM-варианта От участника дополнительно потребовали PLC+RF
Исполнение корпуса IP64 Указано IP64 и приложены подтверждения Диапазон семейства и руководство для другого исполнения прочитали как опровержение

Эта матрица важнее названий конкретных протоколов связи. Та же ошибка возникает при закупке серверов, медицинской техники, датчиков или станков: наличие функции в базовой комплектации не делает одноимённый сменный блок обязательным, а список возможных исполнений не описывает каждый поставляемый экземпляр сразу.

IP64: диапазон семейства не равен характеристике экземпляра

Второе основание отклонения выглядело убедительнее. Участник заявил IP64. Заказчик проверил описания типов счётчиков МИРТЕК-12-РУ и МИРТЕК-32-РУ и увидел три значения: IP51, IP54 и IP64. В руководствах по эксплуатации на сайте изготовителя он нашёл IP54.

Но диапазон в описании типа говорит, какие исполнения входят в семейство. Он не доказывает, что участник предложил именно вариант IP51 или IP54. Для этого нужно связать полное обозначение товара с конкретной характеристикой.

В заявке стояло IP64, а приложенные описания типов включали такое исполнение. Кроме того, ФАС сослалась на протоколы проверки соответствия IP64 по ГОСТ 14254-2015 от 23 и 29 ноября 2023 года. При таком комплекте документов комиссия не могла заменить предложенную характеристику соседним значением из диапазона и отклонить заявку.

Как читать доказательства по оборудованию

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

Документ Что обычно подтверждает Чего сам по себе не доказывает
Описание типа или семейства Допустимые модификации и диапазоны характеристик Какое исполнение фактически предложено
Полный код исполнения и техническое предложение Выбор участника для конкретной поставки Достоверность характеристики без связанного документа
Руководство по эксплуатации Параметры охваченных руководством модификаций Характеристику другой модификации того же семейства
Протокол испытаний Результат проверки названного образца или исполнения Автоматическое соответствие всей линейки

До публикации документации заказчику полезно собрать обратную матрицу: требование → оператор AND/OR → поле заявки → допустимое доказательство → основание отклонения. Если одно условие встречается сразу в нескольких строках, нужно заранее решить, это повтор одной функции или разные уровни комплектации.

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

От решения до отмены протоколов

Что произошло с закупкой № 32615966003
  1. Извещение размещено

    Запрос предложений на поставку счётчиков с НМЦД 646 млн рублей.

  2. Подача заявок завершена

    Поступили три заявки; до дальнейшего участия допустили одну.

  3. Оформлены протоколы

    Заявку жалобщика отклонили в том числе по модулю связи и IP64.

  4. ФАС вынесла решение и предписание

    Жалоба признана обоснованной; рассмотрение нужно повторить.

  5. Акты опубликованы

    Решение и предписание появились в Базе решений ФАС.

  6. ЕИС зафиксировала отмену

    Два протокола от 26 июня получили статус недействующих.

  7. Нужно подтвердить исполнение

    Заказчик и оператор должны представить подтверждение ФАС.

Источник: ФАС России и ЕИС

Предписание требует отменить протокол рассмотрения, назначить новые даты и продолжить закупку с учётом решения. До исполнения предписания заключать договор нельзя. ЕИС уже показывает отмену протоколов № 32615966003-02 и № 32615966003-03, причём карточка второй отмены прямо называет номер предписания.

Новых протоколов на 26 июля нет. Неизвестно и то, станет ли заявитель победителем после повторной проверки: ФАС устранила два основания отклонения, но не оценила за комиссию всю заявку и предложения конкурентов.

Проверка перед следующим протоколом

Заказчику:

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

Поставщику:

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

Часть 6 статьи 3 Закона № 223-ФЗ не запрещает заказчику выбирать строгие технические параметры. Она не позволяет применять требования и порядок проверки, которых нет в опубликованной документации. В деле о счётчиках граница прошла именно здесь: комиссия проверила не ту связь между характеристиками, которую сама предложила участникам.

Практика

Что проверить после этого разбора

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

На чём основан разбор

Ссылки проверены редакцией на дату актуальности материала.

  1. Федеральная антимонопольная служба · 23 июля 2026 г.

    Первичный текст решения: параметры закупки, требования PLC+RF и IP64, доказательства сторон, вывод о нарушении и резолютивная часть.

  2. Федеральная антимонопольная служба · 23 июля 2026 г.

    Требует отменить протокол, назначить новые даты, повторить рассмотрение и подтвердить исполнение не позднее 7 августа.

  3. Единая информационная система в сфере закупок · 29 апреля 2026 г.

    Подтверждает предмет, заказчика, НМЦД 646 млн рублей, сроки и обновление карточки 24 июля 2026 года.

  4. Единая информационная система в сфере закупок · 24 июля 2026 г.

    Показывает два недействующих протокола от 26 июня и действующие записи об их отмене 24 июля.

  5. Единая информационная система в сфере закупок · 24 июля 2026 г.

    Прямо связывает отмену протокола 24 июля с предписанием ФАС от 20 июля № 28/07/2-2695/2026.

Материал проверен 26 июля 2026 г.

Контроль актуальности источников — до 7 августа 2026 г..

Если вы заметили изменение или неточность, напишите на info@fermanai.ru.

Версия материала: 001 · история изменений