Мы используем собственную систему учета товаров и планируем интегрировать ее с системой «Честный знак», чтобы автоматически передавать информацию о кодах маркировки. Подскажите, каким образом обычно осуществляется такая интеграция и есть ли официальные API или готовые решения для синхронизации данных между системами.
Да, официальные API для «Честного знака» есть, и интеграция собственной учетной системы обычно делается либо через прямое взаимодействие с ГИС МТ по API, либо через готовые коннекторы/модули (операторов ЭДО, 1С‑решений, WMS/OMS). На практике выбор зависит от товарной группы, ваших процессов (ввод в оборот, перемаркировка, отгрузка, розница) и того, где физически «сканируется» код (склад/касса).
Как обычно устроена интеграция (логика и регуляторика)
«Честный знак» — это государственная информационная система маркировки (ГИС МТ), а обязанность наносить коды и передавать события по ним установлена правилами маркировки по конкретной товарной группе. По смыслу регулирования важно не «подключиться к API», а корректно фиксировать юридически значимые события с кодами: заказ/получение кодов, ввод в оборот, агрегация (короба/палеты), отгрузка/приемка, возвраты, перемаркировка, вывод из оборота (в т.ч. на кассе), списания по причинам и т.д.
Технически интеграция чаще всего строится вокруг трех контуров:
- Контур ГИС МТ: обмен документами/сообщениями по кодам маркировки (заказ кодов, отчеты о нанесении/вводе в оборот, агрегация, корректировки и пр.).
- Контур ЭДО: юридически значимые документы по отгрузкам/приемкам (универсальные передаточные документы и их подписание). Во многих сценариях именно ЭДО связывает хозяйственную операцию и коды маркировки.
- Контур торговой точки: кассовое ПО и оператор фискальных данных (для товарных групп, где вывод из оборота идет через кассу). Здесь своя интеграция и свои требования к корректности передачи кода.
Почему это важно: бизнес часто делает «прямую отправку кодов в ЧЗ», но забывает про связку с первичкой/ЭДО или про требования конкретной товарной группы. В результате формально коды ушли, а статус оборота или выбытия — неверный, и появляются расхождения/блокировки операций.
Какие варианты интеграции бывают на практике
- Прямая интеграция по официальным API ГИС МТ (наиболее гибко): ваша система формирует запросы/документы, подписывает их, отправляет в ГИС МТ и получает статусы/квитанции. Обычно требует настройки криптографии, управления ключами и корректной обработки ошибок/повторов.
- Через готовые модули/коннекторы (быстрее в запуске): 1С‑модули, интеграции WMS/ERP, решения операторов ЭДО/интеграторов. Ваша учетная система отдает данные в коннектор, а он уже общается с ГИС МТ и/или ЭДО.
- Гибридная схема: критичные операции (заказ кодов, ввод в оборот, агрегация) — напрямую по API, а отгрузки — через ЭДО/готовый модуль, чтобы не «изобретать» юридически значимый документооборот.
Что обычно нужно для технического подключения
- Учетная модель в вашей системе: хранение кодов (DataMatrix), их статусов, связей с GTIN/номенклатурой, партиями, документами, агрегатами (SSCC/короба/палеты — если применимо).
- Электронная подпись: большинство значимых операций требует подписания. На практике заранее продумывают, кто подписывает (организация/обособка), где хранится ключ, как обеспечивается непрерывная работа.
- Сценарии по товарной группе: состав операций и документов отличается (например, в части агрегации, перемаркировки, способа вывода из оборота).
- Обработка статусов и квитанций: важна не только отправка, но и получение результата (принято/отказ/ошибка формата/ошибка бизнес‑логики) и повторная отправка по правилам.
Практическая рекомендация: как подойти к проекту без лишних переделок
- Опишите ваши операции с кодами: производство/импорт, склад, отгрузки, возвраты, комиссионка/маркетплейсы, розница. Для каждой операции — какой документ в ГИС МТ и где он рождается.
- Решите, где будет «истина» по кодам: в вашей системе или в промежуточном модуле. Я обычно рекомендую, чтобы ваша учетная система хранила коды и их связи с документами, а интеграционный слой отвечал за транспорт/подпись/ретраи.
- Выберите архитектуру интеграции: прямая API (если есть сильная IT‑команда и много нестандартных процессов) или готовый коннектор (если нужно быстро и типовой процесс).
- Сразу заложите контуры ЭДО и кассы (если применимо): иначе вы сделаете «обмен с ЧЗ», но не закроете выбытие/отгрузки юридически корректно.
- Сделайте тестовый стенд/контур: прогоните полный цикл на небольшой номенклатуре — от заказа кодов до выбытия — и только потом масштабируйте.
Типичные ошибки бизнеса
- Путают обмен с ГИС МТ и ЭДО: отправляют коды, но отгрузочные документы не сходятся по логике, из-за чего статусы оборота «ломаются».
- Не ведут агрегацию там, где она реально нужна (или ведут «для галочки»), а на складе фактически работает отбор коробами/палетами.
- Не закладывают обработку отказов: отправка без контроля квитанций приводит к накоплению «подвисших» кодов и расхождениям в остатках.
- Неправильная мастер‑данная база: GTIN/наименование/единицы/упаковки не согласованы, из-за чего операции не принимаются или принимаются с ошибочными привязками.
Если вы напишете, какая товарная группа, у вас производство или импорт, есть ли розница/касса и как оформляете отгрузки (ЭДО/без ЭДО), я смогу предметно подсказать оптимальную схему интеграции и перечень операций, которые обязательно закрыть.