1 октября в прод: что 12 платформам придётся перестроить из-за нового закона

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

С 1 октября 2026 года вступает в силу Федеральный закон № 289-ФЗ «Об отдельных вопросах регулирования платформенной экономики в Российской Федерации». Для площадок из предварительного перечня Минэкономразвития это дата готовности к новому режиму: обязательный контур должен быть в проде не позднее включения конкретной платформы в реестр.

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

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

12 площадок в списке — и у каждой откроется свой бэклог

Минэкономразвития назвало 12 площадок, которые планирует включить в реестр: Avito, Delivery Club, Joom, Lamoda, Ozon, Wildberries, «Купер», «Магнит Маркет», «Яндекс Маркет», «Яндекс Go», «Яндекс Еда» и «Яндекс Путешествия»

Перечень пока предварительный. Закон начинает действовать 1 октября 2026 года, а статус посреднической цифровой платформы возникает после включения в реестр. Значит, 1 октября — точка готовности к новому режиму, а запись в реестре — момент, когда обязательные сценарии уже должны работать.

В законе № 289-ФЗ много формулировок вроде «уведомить», «получить согласие», «проверить» и «отменить меру». Для разработки это глаголы с состоянием. Нужно знать, кто запустил действие, к какому объекту оно относится, когда истекает срок, какой модуль отвечает за результат и что происходит при ошибке.

Требование «уведомить продавца» превращается в событие, канал доставки, подтверждение, таймер и запись для аудита. Этот слой и создаёт объём, которого нет на первом макете.

Кнопка «жалоба удовлетворена» должна сработать в пяти сервисах

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

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

Кнопка сработала в поддержке. Система — ещё нет.

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

Мы связываем изменения общим идентификатором решения. В распределённой архитектуре запись о смене состояния и событие для других сервисов фиксируем через transactional outbox. Обработчики делаем идемпотентными: повторная команда не должна второй раз вернуть деньги, поднять рейтинг или разблокировать кабинет. После исчерпания повторов сообщение попадает в dead letter queue (DLQ), откуда его разбирает поддержка.
 

45 дней, три дня, 15 дней, 48 часов: теперь это системные таймеры

О существенных изменениях договора партнёра предупреждают за 45 дней. О большинстве санкций — за три дня. На ответ по жалобе даётся 15 дней, на отмену обоснованно оспоренной меры — 48 часов. Эти сроки собраны в статьях 12–14 закона.

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

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

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

Реестр не ответил. Что увидит продавец?

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

При регистрации платформа сверяет партнёров и владельцев пунктов выдачи через ЕГРЮЛ, ЕГРИП, ЕСИА или другие разрешённые способы. Для товарных карточек код ТН ВЭД ЕАЭС или ОКПД 2 определяет, нужно ли обращаться к реестру разрешительных документов. На специальную проверку отведено три рабочих дня, а для старого каталога предусмотрен переходный период в 180 дней. Механику закрепляет постановление № 821.

Интеграцию сразу проектируем с учётом недоступности источника. Реестр может отвечать медленно, вернуть неполные данные или временно отключиться. Запросу нужны idempotency key, retry с ограничением попыток и backoff, журнал ответа и понятный статус для пользователя. После нескольких неудач запись уходит в DLQ, которую видит поддержка.

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

Одно поле не закроет согласия, отправки и часы

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

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

Та же инженерная дисциплина нужна в обмене с ФНС. Правила взаимодействия с ФНС предусматривают электронные сервисы и протоколы, а ведомство уже публикует проекты интерфейсов. Команде понадобятся версии схем, контроль доставки, сверка отправленных данных и повторная обработка ошибок. Кнопка «отправить» без журнала и подтверждения быстро создаст расхождение между платформой и внешней системой.

У сервисных платформ появляется ещё один расчётный модуль. Постановление № 760 задаёт критерий продолжительной работы на одного заказчика: свыше 60 часов в месяц на протяжении шести месяцев подряд для ряда видов деятельности. Показатель работает как правило допуска к следующему заказу. Система связывает исполнителя, заказчика, отрасль, часы и скользящее шестимесячное окно, заранее показывает приближение к ограничению и объясняет отказ.

Что должно работать к запуску, даже если команда не успевает всё

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

• проверка новых партнёров и карточек с блокировкой публикации до обязательной сверки;

• уведомления, ограничения, жалобы и восстановление доступа в установленный срок;

• согласия на скидки, отзыв согласия и защита положения продавца после отказа;

• журнал решений, таймеры, повторная обработка ошибок и мониторинг внешних интеграций.

Старый каталог можно проверять после старта в пределах 180-дневного переходного периода из постановления № 821. Очередь миграции, ограничение её нагрузки и наблюдаемость нужны уже в первом релизе. Иначе переходный период превратится в неконтролируемый фон и начнёт мешать новым карточкам.

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

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

Шесть проверок до первой оценки разработки

До макетов и перечня экранов команда Qtim проходит шесть шагов:

• Выписываем события, которые создают юридический срок или меняют права пользователя.

• Связываем каждое событие с модулем, владельцем данных и зависимыми системами.

• Для каждой внешней интеграции описываем таймаут, retry, недоступность и DLQ.

• Проверяем, можно ли восстановить историю решения: основание, версию правила, время и исполнителя.

• Отделяем миграции старых данных от ежедневного потока и оцениваем нагрузку на оба контура.

• Собираем сквозные тесты для жалобы, отзыва согласия, недоступности реестра и отмены ограничения.

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

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

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