Совет Федерации одобрил поправки к 44-ФЗ: разъяснения Минфина в закон не вошли

23 июля Государственная Дума приняла закон по проекту № 1286425-8 и направила его в Совет Федерации. 24 июля верхняя палата одобрила документ постановлением № 331-СФ. На момент редакционной проверки 30 июля подпись Президента, номер федерального закона и официальное опубликование не подтверждены. Поэтому парламентский текст уже можно использовать для подготовки, но ни одну новую норму ещё нельзя применять в извещении, контракте или продуктивном алгоритме.

Главное отличие от внесённой редакции сохранилось: в одобренном парламентом тексте нет специального механизма официальных разъяснений Минфина. Исчезла и предложенная норма, по которой действия в соответствии с такими разъяснениями не должны были квалифицироваться как нарушение. Если организация успела заложить этот механизм в методологию, базу знаний или бэклог разработки, работу нельзя продолжать по инерции.

Что изменилось 24 июля

Совет Федерации одобрил закон отдельным постановлением № 331-СФ. Это завершило парламентскую стадию, но не сделало поправки действующими. Следующие правовые гейты — подпись Президента и официальное опубликование.

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

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

Что показал redline

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

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

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

Все столбцы — прокрутите таблицу по горизонтали ↔

Блок	Внесённая редакция	Одобренный парламентом текст	Действие команды
Официальные разъяснения	Новый механизм и специальное последствие следования позиции	Блок исключён полностью	Удалить зависимые требования и функции из релизного плана
Сельские закупки	Достаточно широкая привязка к сельским населённым пунктам	Уточнена цель — непосредственное обеспечение жизнедеятельности населения	Переписать условие применимости и набор доказательств
Замена предмета контракта	Характеристики «не хуже»	Характеристики должны быть аналогичными или улучшенными	Заменить общий флаг сравнительной таблицей параметров
Несколько малых закупок	Общий запуск с 1 октября	Норма о том же поставщике — со дня опубликования и для прежних правоотношений	Выделить отдельный правовой и контрольный пакет

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

Три пакета вместо одного релиза

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

1. Официальное опубликование
   Несколько малых закупок у одного поставщика

   Отдельная норма должна заработать в день опубликования; эта дата пока неизвестна.

2. 1 октября 2026
   Основной пакет

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

3. 1 января 2027
   Отложенный пакет

   Порог закупок среди СМП и СОНКО до 30 млн рублей, протокол разногласий и часть процедурных изменений.

Источник: Текст закона, принятого Государственной Думой и одобренного Советом Федерации; статус на 30 июля 2026 года

Профессиональный обзор финальной редакции независимо подтверждает ключевые границы: котировки до 20 млн рублей предполагаются с 1 октября 2026 года до конца 2027 года; лимит 30 млн рублей для закупок среди СМП и СОНКО и протокол разногласий — с 1 января 2027 года.

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

Как возникает «призрачная функция»

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

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

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

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

Две формулировки, которые нельзя обновить поиском и заменой

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

Здесь нужен не переключатель «сельская закупка», а карточка решения: населённый пункт, конкретная потребность, связь с жизнедеятельностью, автор обоснования и документ проверки. Автоматический маршрут может подсказать обязательные поля, но не должен сам выводить применимость из адреса.

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

Для многопараметрического товара улучшение одного свойства может сопровождаться ухудшением другого. Закупочная система должна сопоставлять функциональные, технические, качественные и эксплуатационные характеристики по строкам. Несопоставимый параметр остаётся отдельным отклонением; его нельзя скрыть общей оценкой. Юрист проверяет допустимость изменения, технический специалист — эквивалентность результата, а решение фиксируется до дополнительного соглашения.

Что менять в бэклоге уже сегодня

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

Затем присвойте задачам один из четырёх статусов:

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

Для проекта № 1286425-8 механизм разъяснений попадает в первую группу. Сельское основание и модель сравнения характеристик — во вторую. Пороги и новые варианты изменения контракта — в третью. Норма, запускаемая в день опубликования, — одновременно в третью и четвёртую до появления официальной даты.

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

Четыре проверки до правового гейта

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

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

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

Четвёртый сценарий проверяет календарь. Возьмите три тестовые даты: день до официального опубликования, дату опубликования и 1 октября 2026 года; для следующего пакета добавьте 1 января 2027 года. Пока публикация не состоялась, первая дата в конфигурации должна оставаться неопределённой, а функции — выключенными. После появления официального источника дата подставляется один раз в реестр версий и наследуется зависимыми правилами. Это снижает риск, что разные модули получат разные моменты запуска.

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

Что ещё неизвестно

Парламентская стадия завершена: Совет Федерации одобрил закон 24 июля постановлением № 331-СФ. Поиск Банка документов Президента России по точному названию не показал записи 2026 года. Редакция пока не установила номер федерального закона; не подтверждены направление Президенту, подпись Президента и официальное опубликование. Поэтому нельзя назвать календарный день запуска нормы, которая должна применяться со дня опубликования.

Контрольный поиск портала официального опубликования по предмету закона и диапазону дат с 24 по 30 июля не вернул документов. Это не доказательство отсутствия публикации вне заданного запроса: результат фиксирует только публичное состояние портала на момент проверки и границы поисковой формулировки. Перед выпуском следующей версии поиск нужно повторить по реквизитам, которые станут известны.

Карточка СОЗД на момент проверки отставала от страницы решения Совета Федерации и не показывала событие 6.3. Это не основание отрицать решение палаты и не основание достраивать следующие стадии: статья фиксирует одобрение по первичному документу Совета Федерации, а президентскую и публикационную стадии оставляет неизвестными.

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

Одобрение Советом Федерации уменьшило процессуальную неопределённость, но не открыло правовой гейт. До подтверждения подписи и официального опубликования правильная готовность — это проверенный текст, выключенная функция, владелец, контрольный сценарий и возможность включить изменение только по точному первичному документу.