Как получить информацию по коду маркировки (КИ) обуви через API Честный ЗНАК

← На главную

В процессе работы с маркированной продукцией, в частности с обувью, перед компаниями часто встает задача предварительной проверки товаров, поступивших от поставщика. Необходимо убедиться, что коды идентификации (КИ) валидны, введены в оборот и действительно принадлежат отправителю, еще до момента официальной приемки через ЭДО. В этой статье мы подробно разберем, как реализовать проверку кодов через API ГИС МТ (Честный ЗНАК) средствами 1С, рассмотрим основные методы и научимся обходить технические ошибки, связанные со спецсимволами.

Выбор подходящего метода API для проверки статуса

При работе с API «Честного ЗНАКА» (контур Фасад) программисты часто сталкиваются с тем, что методы /api/v3/facade/marked_products/listV2 или /api/v3/facade/identifytools/listV2 возвращают информацию только по тем маркам, которые уже находятся в собственности владельца токена. Для проверки «чужих» марок (товаров, которые еще числятся за поставщиком) такие методы не подходят.

Проанализируем ситуацию: для получения информации по конкретному коду идентификации, независимо от текущего владельца, наиболее эффективным является метод:

/api/v3/facade/cis/cis_list

Разберем, как правильно сформировать запрос. Если мы передаем конкретный код в параметре cis, система возвращает JSON-объект с детальной информацией: статус (например, IN_CIRCULATION), ИНН текущего владельца, наименование товара и другие атрибуты. Рассмотрим пример формирования строки запроса в 1С:


КодCIS = "010290000119684021..."; // Ваш КИ
URLЗапроса = "/api/v3/facade/cis/cis_list?cis=" + КодCIS;
// Далее следует отправка HTTPЗапроса с использованием авторизационного токена

Проблема спецсимволов и их кодирования

Одной из главных сложностей при работе с кодами маркировки в URL-запросах является наличие спецсимволов. Коды маркировки часто содержат такие знаки, как ,, /, +, ;, =. Если просто добавить их в строку запроса, сервер может вернуть ошибку 400 (Bad Request) или пустой ответ.

Выясним причину: стандартная функция 1С КодироватьСтроку(КИ, СпособКодированияСтроки.КодировкаURL) не всегда корректно обрабатывает все символы, которые критичны для парсера ЦРПТ. Особенно часто проблемы возникают с запятой. Разберем по шагам решение, которое применяется в типовых конфигурациях 1С (библиотека интеграции с ИСМП):

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

Посмотрим на пример кода, позволяющий обойти ошибку при наличии запятой:


// Пример логики из интерфейса ИСМП
ЗначениеДляПоиска = "01029000123456215,ABC/123"; 
ПараметрыЗапроса = Новый Соответствие;

Если СтрНайти(ЗначениеДляПоиска, ",") > 0 Тогда
    // В некоторых случаях помогает передача пустого префикса или 
    // ручная замена символа на его URL-код %2C
    ЗначениеДляПоиска = СтрЗаменить(ЗначениеДляПоиска, ",", "%2C");
КонецЕсли;

URLЗапроса = "/api/v3/facade/cis/cis_list?cis=" + ЗначениеДляПоиска;

Передача кода: 31 символ или полный код с криптохвостом?

Важно понимать различие между Кодом Маркировки (полный состав с криптохвостом) и Кодом Идентификации (КИ). Для большинства методов фасадного API (получение информации о товаре) криптохвост не требуется.

Проанализируем структуру кода: 01 (GTIN - 14 символов) + 21 (Серийный номер - 13 символов). Всего 31 символ (включая идентификаторы применения 01 и 21). Если вы пытаетесь отправить в GET-запросе полный код из DataMatrix (включая группы 91 и 92), это гарантированно приведет к ошибкам из-за обилия спецсимволов в «хвосте».

Рекомендация: Для проверки статуса через cis_list отрезайте лишние данные, оставляя только первые 31 символ. Это значительно повышает стабильность работы API и уменьшает количество ошибок кодирования.

Массовая проверка кодов (пакетный режим)

Если вам необходимо проверить партию товара (например, 800–1000 коробок), выполнение индивидуального HTTP-запроса на каждый код крайне неэффективно. Более того, ЦРПТ применяет Rate Limiting (ограничение частоты запросов), и при интенсивном опросе ваш IP или токен может быть временно заблокирован с ошибкой 429 (Too Many Requests).

Рассмотрим, как правильно организовать массовую проверку:

1. Использование POST-запросов

Многие методы API v3 позволяют передавать список кодов в теле (Body) JSON-запроса. Это снимает проблему ограничений длины URL и необходимости экранирования спецсимволов. Вместо GET-запроса с параметрами в строке, мы формируем POST-запрос с массивом КИ.

2. Работа через ЭДО

Наиболее правильный путь в системе 1С — это использование встроенного функционала «Проверка поступивших кодов маркировки» в документе «Приобретение товаров и услуг» или «Приходная накладная». При получении электронного УПД система уже содержит список всех марок. При нажатии кнопки «Проверить» 1С сама обращается к ИСМП, используя оптимизированные пакетные запросы, и сверяет статус каждой марки.

Сводная таблица статусов при проверке

При получении ответа от API следует обращать внимание на поле status. Рассмотрим основные значения:

INTRODUCED — Код эмитирован, но еще не нанесен (или не введен в оборот).
APPLIED — Код нанесен на товар, но еще не в обороте.
IN_CIRCULATION — Товар легально находится в обороте. Это единственный статус, при котором покупка у поставщика и дальнейшая продажа безопасны.
RETIRED — Код выведен из оборота (продан, списан). Такой товар принимать нельзя.

Важный нюанс: Если API возвращает пустой ответ или статус «Код не найден», проверьте корректность GTIN. Он всегда должен состоять из 14 цифр. Если ваш GTIN короче, дополните его ведущими нулями (например, 00000012345678) перед формированием запроса.

Таким образом, для успешной проверки «чужих» марок обуви используйте метод cis_list, передавайте только 31 символ кода и внимательно следите за экранированием спецсимволов в строке URL. В идеале — стремитесь к использованию POST-методов и пакетной обработке данных через встроенные библиотеки 1С.