1 октября в прод: что 12 платформам придётся перестроить из-за нового закона
Жалоба удовлетворена, но кабинет продавца уже открыт, карточка всё ещё скрыта, рейтинг не вернулся, деньги остаются удержаны: решение застряло между пятью сервисами.
С 1 октября 2026 года вступает в силу Федеральный закон № 289-ФЗ «Об отдельных вопросах регулирования платформенной экономики в Российской Федерации». Для площадок из предварительного перечня Минэкономразвития это дата готовности к новому режиму: обязательный контур должен быть в проде не позднее включения конкретной платформы в реестр.
Для IT-команды это большой релиз. Придётся проверять продавцов и карточки через государственные реестры, хранить согласия на скидки, запускать таймеры уведомлений, принимать жалобы и синхронно отменять ограничения. За каждым глаголом — статусы, интеграции, фоновые задачи, журнал решений и сквозные тесты.
Я — Антон Фокин, CEO Qtim. Мы разрабатываем SaaS-сервисы и платформы, поэтому читаем новые требования как описание будущего поведения системы. Ниже разберу, где возникает скрытый объём разработки и что должно работать к октябрьскому запуску. Юридическую трактовку требований нужно согласовать с профильными специалистами.
12 площадок в списке — и у каждой откроется свой бэклог
Минэкономразвития назвало 12 площадок, которые планирует включить в реестр: Avito, Delivery Club, Joom, Lamoda, Ozon, Wildberries, «Купер», «Магнит Маркет», «Яндекс Маркет», «Яндекс Go», «Яндекс Еда» и «Яндекс Путешествия».
Перечень пока предварительный. Закон начинает действовать 1 октября 2026 года, а статус посреднической цифровой платформы возникает после включения в реестр. Значит, 1 октября — точка готовности к новому режиму, а запись в реестре — момент, когда обязательные сценарии уже должны работать.
В законе № 289-ФЗ много формулировок вроде «уведомить», «получить согласие», «проверить» и «отменить меру». Для разработки это глаголы с состоянием. Нужно знать, кто запустил действие, к какому объекту оно относится, когда истекает срок, какой модуль отвечает за результат и что происходит при ошибке.
Требование «уведомить продавца» превращается в событие, канал доставки, подтверждение, таймер и запись для аудита. Этот слой и создаёт объём, которого нет на первом макете.
Кнопка «жалоба удовлетворена» должна сработать в пяти сервисах
Закон связывает ограничение кабинета или карточки с системой досудебных жалоб. Если оператор признал жалобу обоснованной, применённую меру нужно отменить за 48 часов.
В зрелом продукте доступ закрывает сервис авторизации, карточку снимает модерация, рейтинг считает отдельный модуль, деньги удерживает расчётный контур, а обращение живёт в службе поддержки. Ответ «жалоба удовлетворена» ничего не меняет, пока пять систем хранят разные состояния.
Кнопка сработала в поддержке. Система — ещё нет.
Монолит упирается в те же 48 часов и журнал решений. Сбой просто живёт в другом месте: в локальной транзакции, фоновой задаче или последовательности обновлений модулей. Если восстановление остановилось посередине, пользователь получает тот же рассинхрон.
Мы связываем изменения общим идентификатором решения. В распределённой архитектуре запись о смене состояния и событие для других сервисов фиксируем через transactional outbox. Обработчики делаем идемпотентными: повторная команда не должна второй раз вернуть деньги, поднять рейтинг или разблокировать кабинет. После исчерпания повторов сообщение попадает в dead letter queue (DLQ), откуда его разбирает поддержка.
С похожим классом задач мы сталкивались в платформе аттестации Университета Льва Толстого. Регламент разложили на NestJS-модули и сервисы: контроллер принимает действие, сервисный слой проверяет допустимость перехода, а guards закрывают доступ к документам и медиа до входа в обработчик. Здесь принцип тот же, только границы проходят через большее число продуктовых модулей.
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 можно обсудить технический аудит и план доработок. Для первого разговора пригодятся схема сервисов, список внешних интеграций и один сквозной сценарий, который сейчас проходит через несколько команд.