← Все материалы

Автоматизация маркировки для маркетплейсов: где скрипт реально помогает

Автоматизация маркировки для маркетплейсов — это не «подключить Честный ЗНАК» одной кнопкой, а закрыть четыре узких места: заказ кодов, ввод в оборот, передачу кодов в заказ на площадке и сверку того, что реально выбыло. Ниже — что из этого решается скриптом поверх API, а что и без него закрывает личный кабинет или товароучётная система.

Что селлер на самом деле делает с кодами

У каждого кода маркировки есть жизненный цикл, и селлер отвечает почти за весь: заказал коды в станции управления заказами (СУЗ), нанёс Data Matrix на упаковку, ввёл в оборот, передал код в конкретное отправление на площадке, дождался выбытия. Автоматизировать имеет смысл не «маркировку вообще», а конкретные переходы между этими состояниями.

Плата за код зафиксирована постановлением Правительства РФ от 08.05.2019 № 577 — 50 копеек без НДС за штуку, независимо от товарной группы и объёма (с НДС 2026 года это около 61 копейки). Цена кода тут не проблема. Проблема в том, что на партии в несколько тысяч единиц каждый шаг делается руками через выгрузки CSV, и ошибка вылезает уже на приёмке.

Где горит у селлера

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

Этап	Что ломается	Что помогает
Заказ кодов	Заказали не под тот GTIN или не то количество — коды оплачены и лежат мёртвым грузом	Заказ по факту производственного задания, а не «на глазок»
Ввод в оборот	Коды напечатали, а документ ввода не подали — на приёмке статус «Эмитирован»	Проверка статуса каждого кода до отгрузки
Передача площадке	Коды вбивают в личном кабинете руками по одному отправлению	Передача кодов по API из своей базы
Вывод и сверка	Часть кодов «зависла» в обороте после продажи или возврата	Регулярная сверка своей базы с ГИС МТ и отчётами площадки

Последняя строка — самая дорогая. Немаркированный или неправильно оформленный товар в обороте — это статья 15.12 КоАП РФ: по части 2 (продажа, хранение, перевозка в целях сбыта) для юрлиц штраф 50 000–300 000 ₽ с конфискацией предмета правонарушения. Точную квалификацию даёт не подрядчик по автоматизации, а юрист; моя задача — сделать так, чтобы расхождение было видно в тот же день, а не через квартал.

Что требуют Wildberries и Ozon по кодам

С 1 марта 2023 года площадки сами стали участниками оборота — это постановление Правительства РФ от 29.07.2022 № 1351. Практический смысл для селлера: маркетплейс проверяет коды и передаёт в систему сведения о движении товара, но именно вы обязаны довести код до площадки в правильном статусе. Код со статусом «Эмитирован» или уже выведенный из оборота на приёмке разворачивают.

Площадка	Как передаются коды	Метод API
Wildberries, FBS	Код закрепляется за сборочным заданием	PUT /api/v3/orders/{orderId}/meta/sgtin
Wildberries, DBS	Пакетно по списку сборочных заданий	POST /api/v3/dbs/orders/meta/sgtin
Ozon, FBS и rFBS	Сначала валидация кодов, затем привязка к отправлению	/v5/…/exemplar/validate, /v6/…/exemplar/set
Ozon и WB, FBO	Коды уходят вместе с поставкой; в личном кабинете — по составу поставки	Через ЛК и ЭДО, отдельного метода привязки нет

Кто выводит код из оборота, зависит от схемы. Там, где чек пробивает площадка (FBO, FBS), выбытие уходит от неё; на DBS вы сами доставляете и пробиваете чек — значит, выводите сами. Порядок и сроки прописаны в оферте площадки, и они меняются: это первое, что нужно перечитать в актуальной редакции перед тем, как писать код.

Что автоматизируется скриптом поверх API

У Честного ЗНАКа два интерфейса: СУЗ — для заказа и получения кодов, и True API — для документов и статусов в ГИС МТ. Авторизация в True API идёт через УКЭП: запрашивается случайная строка (`/auth/key`), подписывается ключом и меняется на токен сессии (`/auth/simpleSignIn`). Дальше — обычный REST.

• Заказ кодов по потребности. Скрипт берёт план отгрузок, считает, сколько кодов нужно по каждому GTIN, заказывает недостающие и складывает в свою базу с привязкой к товару.
• Ввод в оборот пачками. True API принимает до 30 000 кодов в одном документе, есть лимит на частоту запросов — порядка 50 в секунду на участника. Значит, нужны очередь и разбиение на пачки, а не цикл по одному коду.
• Проверка статусов перед отгрузкой. Массовый запрос состояния кодов и стоп-лист: не даём собрать поставку, если хоть один код не «в обороте».
• Передача кодов в заказ. Забрали новые сборочные задания у площадки, подобрали код из своей базы, отправили в API, записали факт. Ручной ввод исчезает совсем.
• Ежедневная сверка. Три среза — что продано по отчёту площадки, что выведено в ГИС МТ, что числится у вас. Расхождение падает сообщением ответственному, а не всплывает при проверке.

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

Что не надо писать самому

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

• ЭДО Лайт. Встроен в личный кабинет Честного ЗНАКа и предоставляется участникам бесплатно: УПД с кодами можно создавать и подписывать прямо там.
• Товароучётная система. 1С, МойСклад и сервисы для селлеров уже умеют заказывать коды, печатать этикетки и вести остатки. Если объём небольшой, этого хватает целиком.
• Мобильное приложение Честного ЗНАКа. Быстрый способ проверить конкретный Data Matrix глазами до того, как ставить эксперименты с API.

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

Когда автоматизация не нужна

Разработка окупается объёмом операций. Если операций мало, скрипт станет ещё одной системой, которую надо чинить.

• Одна площадка, одна схема работы и десятки отправлений в месяц — ручной ввод кодов дешевле любой интеграции.
• Товароучётная система уже закрывает заказ кодов, печать и обмен документами, а расхождений по остаткам нет — автоматизировать нечего.
• Ассортимент только собирается, товарная группа и схема продаж ещё меняются — интеграция устареет раньше, чем окупится.
• Нет ответственного за маркировку внутри компании. Скрипт будет исправно писать про расхождения, и их никто не будет разбирать.

Как выглядит работа над такой интеграцией

1. Разбор процесса. Смотрим товарные группы, схемы работы на каждой площадке, что уже делает товароучётка и где сейчас ручной ввод. На выходе — список операций с частотой.
2. Доступы. УКЭП для ГИС МТ и СУЗ, ключи Seller API и WB API, права внутри вашей учётной системы. Обычно самый долгий шаг, и зависит он не от кода.
3. Один узкий участок. Начинаем с самого больного — чаще всего это передача кодов в отправления или сверка. Проверяем на маленькой партии и тестовых данных.
4. Сверка и алерты. Ежедневный отчёт по расхождениям с уведомлением ответственному. Только после того, как цифры сходятся, добавляем автоматические действия.
5. Расширение. Остальные площадки, склады, заказ кодов от плана производства.

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

Частые вопросы

Читайте дальше