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

Добавлено

Удалено или заменено

• 23 июля Государственная Дума приняла закон по проекту № 1286425-8 и направила его в Совет Федерации. Это ещё не действующие поправки: впереди одобрение верхней палаты, подпись Президента и официальное опубликование. Но для команд, которые готовят регламенты и ИТ-системы заранее, уже изменился сам объект подготовки.
• Главное отличие от внесённой редакции — в принятом тексте нет специального механизма официальных разъяснений Минфина. Исчезла и предложенная норма, по которой действия в соответствии с такими разъяснениями не должны были квалифицироваться как нарушение. Если организация успела заложить этот механизм в методологию, базу знаний или бэклог разработки, такую работу нельзя продолжать по инерции.
• Что показал redline
• Внесённый текст предлагал дополнить статью 2 Закона № 44-ФЗ четырьмя частями. Они описывали письменные официальные разъяснения федерального органа, их пределы, обязанность участников ими руководствоваться и специальное последствие для квалификации действий.
• В тексте к третьему чтению этого блока уже нет. Принятый закон , направленный в Совет Федерации, его также не содержит.
• Практический вывод узкий, но важный. Письма и позиции Минфина не исчезают из работы закупочной команды, однако принятый Госдумой текст не создаёт для них новый специальный статус и не вводит обещанную в ранней версии защитную конструкцию. Нельзя строить внутренний контроль так, будто такая норма почти вступила в силу.
• Последняя строка не означает, что прежнее дробление автоматически становится законным. Принятая редакция разрешает несколько малых закупок однородных или идентичных объектов, в том числе у одного поставщика, и распространяет положение на ранее возникшие отношения. Но предмет, единая заранее известная потребность, планирование и обход конкуренции останутся самостоятельными вопросами контроля. Ретроактивная оговорка требует юридического анализа конкретных обстоятельств, а не массового изменения статуса старых договоров.
• Принято Госдумой — не значит действует
• Пока закон не прошёл оставшиеся стадии и не опубликован, заказчики и поставщики работают по действующей редакции 44-ФЗ. Даже нормы с заранее названной датой нельзя включать в извещения, контракты и продуктивные алгоритмы до наступления правового гейта.
• Три пакета вместо одного релиза
• Принятый текст разводит изменения по разным моментам. Если превратить их в одну дату запуска, система либо опоздает с первой нормой, либо преждевременно включит остальные.
• Официальное опубликование Несколько малых закупок у одного поставщика Отдельная норма должна заработать в день опубликования; эта дата пока неизвестна.
• 1 октября 2026 Основной пакет Порог электронного запроса котировок до 20 млн рублей, отдельные изменения контрактов и другие положения.
• 1 января 2027 Отложенный пакет Порог закупок среди СМП и СОНКО до 30 млн рублей, протокол разногласий и часть процедурных изменений.
• Источник: Принятый Государственной Думой текст проекта № 1286425-8; статус на 23 июля 2026 года
• Профессиональный обзор финальной редакции независимо подтверждает ключевые границы: котировки до 20 млн рублей предполагаются с 1 октября 2026 года до конца 2027 года; лимит 30 млн рублей для закупок среди СМП и СОНКО и протокол разногласий — с 1 января 2027 года.
• В ИТ-системе каждой норме нужны собственные атрибуты: идентификатор редакции, условие активации, дата начала, дата окончания, перечень затрагиваемых процедур и тест обратного выключения. Простое поле effectiveDate не справится с нормой, которая начинает действовать в день ещё не состоявшегося опубликования, применяется к прежним отношениям или имеет временный срок.
• Как возникает «призрачная функция»
• Работа по раннему проекту часто выглядит разумно: аналитик описывает требования, юрист согласует концепцию, разработчик создаёт поле или правило, методолог готовит инструкцию. После изменения законопроекта новая версия попадает в юридическую рассылку, но уже заведённые задачи продолжают движение. В релизе появляется функция, которой нет в принятом тексте.
• Для механизма разъяснений это мог бы быть реестр ответов с признаком особого статуса, маршрут обязательного применения позиции или контроль, блокирующий действие при расхождении с письмом. Каждый такой элемент теперь создавал бы ложную правовую уверенность. Опасность не только в лишней разработке: интерфейс способен подтолкнуть специалиста к выводу, которого закон не содержит.
• Поэтому redline должен управлять удалением так же, как добавлением. Для каждого исключённого требования создаётся отрицательная задача: убрать поле, закрыть маршрут, удалить подсказку, отменить обучение и проверить, что функция не доступна через старую роль или сохранённый шаблон.
• Полезный тест формулируется от обратного: «может ли пользователь придать письму Минфина новый специальный статус, предусмотренный только внесённой редакцией?» Правильный результат после обновления — нет. Такой тест лучше обычной отметки «задача закрыта», потому что проверяет поведение системы.
• Две формулировки, которые нельзя обновить поиском и заменой
• Сельское основание в принятом тексте связано с непосредственным обеспечением жизнедеятельности населения в сельских населённых пунктах. Это не просто новый географический фильтр. Система должна хранить и проверять цель закупки, иначе любое нахождение заказчика или объекта в сельской местности превратится в автоматическое основание не учитывать ограничение годового объёма.
• Здесь нужен не переключатель «сельская закупка», а карточка решения: населённый пункт, конкретная потребность, связь с жизнедеятельностью, автор обоснования и документ проверки. Автоматический маршрут может подсказать обязательные поля, но не должен сам выводить применимость из адреса.
• Вторая формулировка касается замены товара, работы или услуги при исполнении контракта. Ранний текст использовал критерий «не хуже», финальный — «аналогичны или улучшены». Оба выражения требуют доказательств, но второе ещё сильнее показывает недостаточность одной итоговой галочки.
• Для многопараметрического товара улучшение одного свойства может сопровождаться ухудшением другого. Закупочная система должна сопоставлять функциональные, технические, качественные и эксплуатационные характеристики по строкам. Несопоставимый параметр остаётся отдельным отклонением; его нельзя скрыть общей оценкой. Юрист проверяет допустимость изменения, технический специалист — эквивалентность результата, а решение фиксируется до дополнительного соглашения.
• Что менять в бэклоге уже сегодня
• Сначала привяжите каждую задачу к источнику. Ссылка только на номер законопроекта недостаточна: у задачи должны быть стадия, дата документа и короткий хеш или внутренний идентификатор версии. Тогда после нового чтения можно получить список функций, основанных на устаревшем тексте.
• Затем присвойте задачам один из четырёх статусов:
• Удалить — требование исчезло из принятой редакции.
• Перепроектировать — норма сохранилась, но изменились формулировка или границы.
• Подготовить выключенной — содержание подтверждено, правовой гейт ещё не пройден.
• Наблюдать — дата зависит от официального опубликования или последующего акта.
• Для проекта № 1286425-8 механизм разъяснений попадает в первую группу. Сельское основание и модель сравнения характеристик — во вторую. Пороги и новые варианты изменения контракта — в третью. Норма, запускаемая в день опубликования, — одновременно в третью и четвёртую до появления официальной даты.
• Отдельно сохраните доказательство редакторской проверки: redline двух официальных документов, список изменённых требований и решение владельца процесса. Это позволит через несколько месяцев понять не только что включили, но и почему некоторые функции сознательно не реализовали.
• Четыре проверки до правового гейта
• Готовность лучше проверять не по числу закрытых задач, а по четырём контрольным сценариям. Первый сценарий — отрицательный. В тестовой среде загрузите письмо Минфина и убедитесь, что система не присваивает ему особый статус, не делает позицию обязательной и не обещает пользователю защиту от квалификации действий как нарушения. Письмо может оставаться источником профессиональной информации, но принятой Госдумой нормой новая правовая конструкция для него не создана.
• Второй сценарий касается сельских закупок. Одного адреса заказчика или объекта недостаточно для автоматического решения. Тест должен требовать указать населённый пункт, описать непосредственную связь закупки с обеспечением жизнедеятельности населения и сохранить обоснование. Если поле с целью пустое, система не должна считать условие выполненным. Такой сценарий проверяет именно принятую формулировку, а не более широкое правило из внесённого текста.
• Третий сценарий — замена товара, работы или услуги при исполнении контракта. Сравнение следует проводить по строкам характеристик: функциональным, техническим, качественным и эксплуатационным. Система должна показать несопоставимый параметр отдельно, даже если итоговая оценка остальных свойств положительная. Затем решение проходит юридическую проверку и фиксируется вместе с основанием изменения. Это отделяет доказательство аналогичности или улучшения от удобной, но недостаточной общей отметки.
• Четвёртый сценарий проверяет календарь. Возьмите три тестовые даты: день до официального опубликования, дату опубликования и 1 октября 2026 года; для следующего пакета добавьте 1 января 2027 года. Пока публикация не состоялась, первая дата в конфигурации должна оставаться неопределённой, а функции — выключенными. После появления официального источника дата подставляется один раз в реестр версий и наследуется зависимыми правилами. Это снижает риск, что разные модули получат разные моменты запуска.
• Результат каждого сценария стоит хранить как короткую карточку доказательства: версия официального текста, проверяемая формулировка, ожидаемое поведение, фактический результат, ответственный и дата повторной проверки. Если Совет Федерации, Президент или официальная публикация изменят состояние документа, команда увидит, какие карточки требуется прогнать заново, не превращая весь релиз в ручную ревизию.
• Что ещё неизвестно
• У принятого Госдумой текста пока нет номера федерального закона. Не определена дата официального опубликования, а значит, нельзя назвать календарный день запуска первой нормы. Совет Федерации и Президент ещё не завершили свои стадии. Статья фиксирует содержание документа, направленного 23 июля в верхнюю палату, но не предсказывает исход этих стадий.
• Неизвестна и будущая правоприменительная граница ретроактивного положения о малых закупках. Его нельзя использовать как универсальное освобождение от анализа дробления. Аналогично новая формулировка замены предмета контракта не отвечает заранее, какие характеристики суд или контрольный орган сочтёт сопоставимыми в конкретном споре.
• Поэтому готовность сейчас означает не «включить изменения», а построить управляемый переход. У каждой функции есть официальный текст, владелец, тест, правовой гейт и возможность не попасть в production. Redline проекта № 1286425-8 показал, зачем нужна последняя часть: иногда самое важное изменение — то, чего в новом документе больше нет.