С 1 октября 2026 года карточка товара на маркетплейсе становится не просто витриной. Она превращается в объект формализованной проверки: площадка должна сопоставлять сведения о товаре с государственными реестрами, а для продукции с обязательным подтверждением соответствия учитывать действующий сертификат или декларацию.
Для продавца это выглядит как еще одно поле в кабинете. Для учетной системы задача гораздо серьезнее. Нужно понять, какой документ действует на конкретный товар, где лежит его файл, загружен ли документ на площадку, привязан ли он к карточке и не истек ли срок. Если делать это вручную, специалист переносит данные между 1С и кабинетом по одной позиции. При сотнях и тысячах артикулов такая работа перестает быть операцией и становится отдельным процессом с неизбежными пропусками.
В этой статье разберу, что именно меняет регулирование платформенной экономики, почему проблема сертификатов касается юристов, контент-менеджеров и специалистов по 1С, как представить ее в данных 1С и каким должен быть безопасный массовый обмен с Ozon. Это инженерный разбор требований и практики автоматизации.
Что меняется 1 октября 2026 года
Федеральный закон от 31.07.2025 N 289-ФЗ "Об отдельных вопросах регулирования платформенной экономики в Российской Федерации" вступает в силу 1 октября 2026 года. Закон определяет правила взаимодействия операторов посреднических цифровых платформ, партнеров и пользователей. Для товарных площадок важна статья 7: оператор проверяет информацию, размещаемую в карточке, и не допускает карточку, если обязательные сведения не прошли установленную проверку.
Практический порядок установлен постановлением Правительства РФ от 02.07.2026 N 821. Для товаров, которые подлежат обязательному подтверждению соответствия, оператор проверяет регистрационный номер сертификата или декларации, код товара и статус документа. Положительный результат предполагает, что документ найден в соответствующем реестре, относится к нужному товару и имеет статус "действует". Для документов, зарегистрированных в России, в карточке также размещается ссылка на запись в реестре.
Ключевое изменение не в том, что сертификаты появились впервые. Обязанность подтверждать соответствие существовала и раньше. Изменился сам порядок контроля. Проверка входит в жизненный цикл карточки на платформе. Значит, разрешительный документ должен быть не только у компании в папке, у специалиста по качеству или в электронном архиве. Он должен быть представлен в форме, которую понимает площадка, связан с конкретным ассортиментом и доступен для машинной проверки.
Это хороший пример того, что означает платформенная экономика на уровне учетной системы. Регулирование задает правило, государственный реестр становится источником статуса, маркетплейс реализует контроль, а внутренняя система продавца должна подготовить корректные данные. Ошибка в любом звене проявляется одинаково: карточка не проходит проверку или перестает продаваться.
Почему ручная загрузка плохо масштабируется
Пока документов мало, процесс кажется простым. Открыть сертификат в 1С, сохранить файл, войти в кабинет Ozon, создать документ, выбрать его тип, перенести номер и срок действия, затем найти нужные товары и выполнить привязку. Для одной карточки это несколько минут. Для ста карточек это уже рабочий день, а для нескольких тысяч нужен постоянный сотрудник и контроль качества его работы.
Главная проблема даже не в количестве кликов. Один документ часто действует на группу товаров. Один товар может иметь несколько документов. Сертификат может быть действующим в 1С, но уже находиться в кабинете. Документ в кабинете может быть загружен, но не привязан к конкретному артикулу. У товара может быть остаток, но не быть артикула, совпадающего с offer_id площадки. Наконец, в карточке сертификата может быть заполнен номер, но отсутствовать сам скан.
При ручной работе эти состояния смешиваются. Пользователь видит длинный список и принимает решение по памяти. При автоматизации состояния нужно назвать явно:
- Уже привязан. Документ есть в Ozon и связан с товаром. Повторных действий не требуется.
- Привязать. Документ найден в кабинете, но у товара связи пока нет.
- Загрузить и привязать. В 1С есть документ и файл, в кабинете документа еще нет.
- Не отправлять. Не хватает артикула, файла, обязательного реквизита или документ не действует.
- Ошибка. Площадка отклонила запрос и вернула конкретную причину.
Такая классификация превращает неопределенную задачу "разнести сертификаты" в конечный план работ. Пользователь до отправки видит, какие строки готовы, какие уже обработаны и что надо исправить в 1С.
Где должны жить исходные данные
В типовых конфигурациях 1С:Управление торговлей 11.5, 1С:Комплексная автоматизация 2.5 и 1С:ERP 2.5 есть учет сертификатов номенклатуры. В карточке документа хранятся вид документа, регистрационный номер, даты действия и область действия. Отдельно хранится присоединенный файл. Связь с номенклатурой позволяет определить, на какие товары распространяется документ.
Это принципиально лучше отдельной таблицы для маркетплейса. Если источник один, сертификат можно использовать в закупках, продажах, внутреннем контроле и интеграциях. Когда срок закончился или область действия изменилась, исправление делается в одном месте. Обмен с площадкой только читает типовые данные и отражает результат.
Есть важная техническая граница: файл должен быть доступен средствами платформы 1С. Если присоединенные файлы вынесены во внешний том, который конкретная база или серверный сеанс не может прочитать, номер документа будет виден без двоичных данных для отправки. Такой случай нельзя маскировать пустым файлом. Строка должна получить понятный вердикт "нет скана" и не попадать в отправку.
Для Ozon полезно заранее проверять формат и размер. Практический набор форматов: PDF, JPG, JPEG и PNG, размер до 10 МБ. Проверку лучше выполнять до вызова API. Тогда пользователь исправляет карточку документа в 1С, а не разбирает общий отказ после массовой загрузки.
Артикул является ключом интеграции
Чтобы связать строку 1С с товаром в Ozon, нужен стабильный внешний ключ. В рассматриваемой схеме это артикул номенклатуры, который совпадает с offer_id товара в кабинете. Наименование для связи использовать нельзя. Оно меняется, содержит сокращения и может повторяться. Штрихкод тоже подходит не всегда: один товар может иметь несколько кодов, набор и единичная позиция часто маркируются по-разному.
Перед массовой работой стоит провести простую сверку: сколько товаров с остатком имеют заполненный артикул, сколько артикулов находятся в кабинете и сколько строк остались без пары. Этот отчет полезен сам по себе. Он показывает качество мастер-данных, от которого зависят сертификаты, остатки, цены, заказы и любая другая интеграция.
Если артикул не найден в кабинете, обработка не должна гадать. Правильное действие - оставить строку без отметки отправки и показать причину. Автоматическое сопоставление по похожему названию удобно в демонстрации, но опасно в боевой базе: ошибочная привязка разрешительного документа хуже, чем отсутствие связи.
Два этапа обмена с Ozon
На уровне Seller API операция состоит из двух разных действий. Сначала создается разрешительный документ: площадке передаются его тип, номер, параметры и файл в Base64. После успешного создания Ozon возвращает идентификатор документа. Затем отдельным запросом документ связывается с товарами.
Разделение важно для повторного запуска. Если документ уже создан, повторно загружать файл не нужно. Достаточно найти существующий документ по номеру и выполнить отсутствующую привязку. Если связь тоже существует, строка получает состояние "уже привязан". Идемпотентность здесь означает, что повторный запуск не создает копии и не ломает готовые связи.
Практический алгоритм выглядит так:
- Прочитать из 1С номенклатуру, области действия документов и присоединенные файлы.
- Отбросить просроченные документы, строки без артикула и, при выбранном режиме, товары без положительного остатка.
- Получить из Ozon товары и ранее созданные разрешительные документы.
- Сопоставить документы по нормализованному номеру, а товары по артикулу.
- Показать план: ничего не делать, привязать, загрузить и привязать либо исправить данные.
- Отправить только строки, которые пользователь отметил флажком.
- Обновить результат только по обработанным строкам и сохранить подробный журнал.
Последний пункт важен для интерфейса. После отправки одной строки нельзя полностью пересобирать таблицу и сбрасывать остальные отметки. Пользователь может подготовить пакет, отправить сначала один контрольный товар, проверить результат и продолжить тем же списком.
Почему нужен тестовый режим
Проверка подключения еще не означает готовность данных. Ключ может быть действующим, а документ не пройти проверку формата. Поэтому безопасный сценарий состоит из двух ступеней.
В тестовом режиме обработка читает кабинет, строит сопоставление, проверяет наличие файла, размер, обязательные поля и формирует тот же план, но не вызывает методы изменения данных. В журнале видно, какой документ и какой объем файла готовы к отправке. Пользователь может открыть номенклатуру и сертификат непосредственно из таблицы, исправить карточку и повторить заполнение.
Для боевого запуска тестовый режим снимается отдельно. Перед отправкой обработка еще раз сообщает, что будут изменены данные в Ozon, и работает только с отмеченными строками. Флажок в таблице служит явным разрешением на конкретную операцию.
Такой подход особенно полезен при первом внедрении. Сначала выбирается один товар с действующим сертификатом и доступным PDF. После загрузки проверяются три факта: документ появился в кабинете, товар получил связь, повторное заполнение показывает "уже привязан". Только после этого имеет смысл отмечать большую группу.
Какие ошибки должны быть видны человеку
Интеграция не должна ограничиваться сообщением "запрос выполнен". Для каждой строки нужен бизнес-результат и техническая причина. Например, Ozon может потребовать дополнительный параметр для свидетельства о государственной регистрации. Для отказного письма может быть обязательна ссылка на реестр. Номер документа может не соответствовать ожидаемому формату. Все это нужно возвращать в колонку пояснения рядом с товаром.
Полезно разделять краткое состояние и журнал. В таблице остается итог, с которым работает пользователь: "Отправлено", "Уже привязан", "Не отправлять", "Ошибка". В журнале записываются время, номер документа, этап, количество созданных документов, количество привязанных товаров и число ошибок. Тогда экран не перегружен, но расследование возможно без технологического журнала платформы.
На контрольном боевом прогоне использовался один реальный товар и один действующий документ. Сначала прошел тестовый прогон без изменений. Затем документ был создан в Ozon, привязан к товару, а журнал зафиксировал результат: загружен один документ, привязан один товар, ошибок ноль. Повторное заполнение показало готовую связь. Такой тест проверяет всю цепочку, а не только доступность API.
Отчет о товарах без сертификатов важнее кнопки отправки
Главный управленческий вопрос звучит так: "сколько карточек требуют внимания до вступления правил в силу". Для ответа кабинет Ozon не обязателен. Достаточно данных 1С: товары с артикулом, остатки, области действия сертификатов и сроки.
Отчет должен отделять товары, прикрытые действующим документом, от товаров под риском. В детализации нужны артикул, номенклатура и причина. Такой список можно передать специалисту по качеству или закупкам. Он не требует доступа к Seller API и остается полезным даже компании, которая пока не готова к автоматической отправке.
Важно понимать границы такого отчета. Наличие записи в 1С не доказывает применимость документа ко всем вариантам товара. Отсутствие записи тоже само по себе не означает, что товар подлежит обязательной сертификации. Отчет показывает пробел в учетных данных и помогает организовать проверку. Решение о том, какой документ обязателен для категории, принимает ответственный специалист.
Массовая отправка без массового риска
Когда один товар прошел полный цикл, можно переходить к пакету. Но массовость должна появляться только на последнем шаге. Сначала система автоматически строит план, затем пользователь просматривает исключения, после этого отмечает готовые строки. Команды "установить отметки" и "снять отметки" должны работать в контексте таблицы, а не прятаться среди настроек подключения.
Если несколько товаров используют один сертификат, файл загружается один раз, а к возвращенному идентификатору привязывается набор товарных идентификаторов. Это уменьшает количество запросов и исключает дубли документов. Если часть товаров из группы уже привязана, обработка отправляет только недостающие связи.
После каждой порции полезно сохранять три счетчика: документов загружено, товаров привязано, ошибок. Нулевое число ошибок само по себе недостаточно, если обе первые величины тоже нулевые. Успешный результат должен соответствовать плану. Если было отмечено десять строк, а привязана одна, журнал обязан объяснить остальные девять.
Что хранить в настройках подключения
Для Seller API нужны Client-Id и Api-Key. Их не следует зашивать в код обработки, размещать в макете или передавать вместе с файлом. В пользовательском интерфейсе ключ показывается как пароль. Сохранение выполняется только по отдельной команде и в общих настройках текущего пользователя конкретной информационной базы.
Проверка подключения должна быть безопасной: выполнить чтение справочника типов или списка документов и не менять данные кабинета. Пользователь получает отдельный результат "подключение работает" до того, как начнет формировать таблицу товаров.
При публикации скриншотов Client-Id тоже нужно считать внутренним идентификатором и закрывать. Маска Api-Key защищает сам секрет, но лучше не показывать весь блок подключения без необходимости. В демонстрационных материалах достаточно показать, что настройка состоит из двух полей и отдельной проверки.
Граница ответственности автоматизации
Обработка может надежно перенести то, что правильно заведено в 1С. Она не определяет за специалиста, нужен ли конкретному товару сертификат, не подтверждает подлинность документа и не исправляет область действия. Автоматизация должна усиливать учет, а не подменять его.
Поэтому хороший результат внедрения состоит из трех частей. Первая - привести в порядок типовые карточки сертификатов и связи с номенклатурой. Вторая - получить отчет о товарах без действующих документов и закрыть пробелы. Третья - синхронизировать готовые документы с площадкой и контролировать результат.
Если начать сразу с массовой кнопки, ошибки внутреннего учета быстро окажутся на внешней платформе. Если начать с отчета и одного контрольного товара, тот же инструмент становится управляемым процессом подготовки каталога.
Документ в кабинете есть, а толку нет
Самая неприятная находка прогона ждала меня в списке документов кабинета. Ozon отдает их одним ответом, и у каждого свой статус. Живьем я видел три: approved, declined, awaiting_verification. Отклоненный документ лежит в том же списке, что и принятый, и внешне ничем от него не отличается.
Отсюда прямое следствие для сверки. Если она смотрит только на факт "документ с таким номером в кабинете есть", то про товар с отклоненным документом честно напишет "уже привязан". Таблица будет зеленой, а карточка проверку не пройдет. Сверять надо пару "номер плюс статус", и строки со статусом declined выносить в отдельную категорию. В общем итоге они растворяются бесследно.
Практический чек-лист перед запуском
- Проверьте, что артикулы 1С совпадают с offer_id в Ozon.
- Откройте несколько карточек сертификатов и убедитесь, что заполнены номер, вид, даты и область действия.
- Проверьте наличие читаемого PDF или изображения в присоединенных файлах.
- Сформируйте отчет о товарах без действующего документа.
- Создайте отдельный ключ Seller API с необходимыми правами и проверьте подключение.
- Заполните таблицу в тестовом режиме и разберите все строки "Не отправлять".
- Выберите один товар, снимите тестовый режим и выполните контрольную отправку.
- Убедитесь, что документ появился в кабинете и привязан к товару.
- Повторно заполните таблицу: контрольная строка должна перейти в состояние "Уже привязан".
- Только после этого отмечайте пакет готовых строк.
Чем я это делал
Все десять шагов выше проходит одна внешняя обработка: Загрузка сертификатов в OZON из 1С. Конфигурация не меняется, расширение не ставится, в базу она не пишет ничего: читает типовой справочник сертификатов номенклатуры, области действия и присоединенные файлы, а дальше ходит в Seller API. Тестовый режим включен по умолчанию, снятие галки требует подтверждения в диалоге.
Скриншоты и запись прогона на карточке сняты с того самого контрольного товара, о котором идет речь выше: документ создан, привязан и в кабинете получил статус "Одобрен".
И вопрос, на который у меня однозначного ответа нет. Вся сверка держится на номере документа: он есть в 1С, он же приходит из кабинета, по нему и сходится. Номера ЕАЭС-деклараций длинные, и любая правка руками на стороне площадки сопоставление ломает. Надежнее было бы хранить идентификатор документа Ozon отдельным реквизитом в 1С, но тогда обработка обязана писать в базу, а я этого избегал сознательно: внешняя обработка, которая только читает, ставится без разговоров с администратором. Кто-то уже выбрал второй путь? Интересно, чем он оказался на дистанции, когда документов тысячи.
Источники: Федеральный закон от 31.07.2025 N 289-ФЗ на официальном портале правовой информации; постановление Правительства РФ от 02.07.2026 N 821; справочные материалы Ozon Seller API по разрешительным документам.
Другие наши инструменты:
- Загрузка сертификатов в OZON из 1С - обработка из этой статьи: сверяет документы 1С с кабинетом, грузит недостающие и показывает товары, у которых действующего сертификата нет вовсе.
- Сводная таблица в Excel из 1С без COM - помогает собрать обменный файл на сервере 1С, где Microsoft Office не установлен.
- Выгрузка структуры метаданных для LLM - показывает модели устройство незнакомой конфигурации перед адаптацией интеграции.
- Анализ кода внешних обработок 1С - проверяет, какие объекты базы читает и изменяет внешняя обработка.
Вступайте в нашу телеграмм-группу Инфостарт