Разъяснения Минфина убрали: что изменилось в принятом пакете поправок к 44-ФЗ

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

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

Что показал redline

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: Принятый Государственной Думой текст проекта № 1286425-8; статус на 23 июля 2026 года

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поэтому готовность сейчас означает не «включить изменения», а построить управляемый переход. У каждой функции есть официальный текст, владелец, тест, правовой гейт и возможность не попасть в production. Redline проекта № 1286425-8 показал, зачем нужна последняя часть: иногда самое важное изменение — то, чего в новом документе больше нет.