При интеграции 1С с системой маркировки «Честный ЗНАК» (ГИС МТ) разработчики часто сталкиваются с ситуацией, когда один и тот же программный код отлично работает для товарных групп «Одежда» или «Обувь», но выдает пустой массив данных при попытке получить остатки по табачной продукции. Рассмотрим подробнее, почему метод /api/v4/facade/identifytools/listV2 оказывается неэффективным для табака и какие альтернативные способы получения данных существуют в актуальной версии API.
Первое, что нам необходимо понять: табачная отрасль в системе «Честный ЗНАК» исторически и технически стоит особняком. Она обрабатывается в подсистеме МОТП (Мониторинг оборота табачной продукции). В то время как большинство потребительских товаров используют универсальный Facade API, табак требует использования TrueAPI.
Разберем ситуацию: когда вы отправляете запрос к /facade/identifytools/listV2 с параметром pg=tobacco, система возвращает код 200 OK, подтверждая, что запрос синтаксически корректен и авторизация пройдена. Однако бэкенд, отвечающий за «тяжелые» выборки в фасадном API, зачастую не имеет прямого доступа к оперативным остаткам табачного сегмента или ограничивает выдачу из-за высокой нагрузки. Именно поэтому в ответ приходит пустой массив "items": [].
Для корректной работы с табаком необходимо переключиться на методы TrueAPI. В частности, для получения списка кодов идентификации (КИ), закрепленных за участником оборота, следует использовать функционал формирования отчетов. Проанализируем основные шаги реализации этого процесса:
UUID задачи, а затем периодически опрашиваем систему о готовности файла.ЧтениеZipФайла) и парсинга CSV.Одной из главных жалоб разработчиков является несоответствие статусов. Например, при фильтрации по статусу INTRODUCED (в обороте) в выгрузку могут попасть коды со статусом APPLIED (нанесен). Разберем, почему это происходит.
Система TrueAPI работает с определенной задержкой синхронизации (Latency). Данные из основной транзакционной базы ГИС МТ попадают в аналитическую базу TrueAPI не мгновенно. Задержка может составлять от нескольких часов до суток. Рассмотрим ситуацию: марка была введена в оборот час назад. В личном кабинете вы видите статус «В обороте», но отчет TrueAPI все еще может отдавать старый статус «Нанесен».
Решение для проверки статусов в реальном времени:
Для того чтобы избежать ошибок при формировании документов «Вывод из оборота», рекомендуется перед добавлением марки в документ проверять её текущий статус точечно. Для этого используем метод /cises/info. Посмотрим на пример логики работы:
// 1. Получаем общий список марок через асинхронную задачу TrueAPI
// 2. Для каждой марки из списка выполняем уточняющий запрос
Запрос = Новый HTTPЗапрос("/api/v3/true-api/cises/info?cises=" + ТекМарка);
Ответ = Соединение.Получить(Запрос);
Если Ответ.КодСостояния = 200 Тогда
ДанныеМарки = ПрочитатьJSON(Ответ.ПолучитьТелоКакСтроку());
Если ДанныеМарки.status = "INTRODUCED" Тогда
// Только теперь марку можно безопасно добавлять в документ вывода
КонецЕсли;
КонецЕсли;
Если ваша задача — не получить каждую конкретную марку, а увидеть общую картину остатков для сверки, целесообразно использовать методы Виртуального склада. Эти методы позволяют получить агрегированные данные по GTIN.
Проанализируем преимущества этого подхода:
GTIN, вы можете сопоставить его с данными в регистре СвободныеОстатки вашей конфигурации 1С.Работа с табачной продукцией накладывает жесткие ограничения на частоту запросов. Выясним основные лимиты, которые нужно учитывать при написании кода в 1С:
limit=1000. Для табачного сегмента оптимальным считается значение 100–200 записей. Слишком объемные запросы могут блокироваться системой как создающие избыточную нагрузку.Подведем итог и составим пошаговый план для разработчика 1С:
Шаг 1: Откажитесь от попыток использовать facade/identifytools/listV2 для получения списка марок табака. Этот метод нестабилен для данной товарной группы.
Шаг 2: Реализуйте механизм работы с задачами (Tasks) в TrueAPI. Создайте справочник или используйте регистр сведений в 1С для хранения ID запущенных задач и отслеживания их статуса (Ожидает/Выполнена/Ошибка).
Шаг 3: После скачивания и парсинга файла остатков, не доверяйте слепо статусам из файла. Реализуйте «ленивую» проверку: проверяйте статус конкретной марки методом /cises/info непосредственно в момент сканирования или добавления в документ подбора и проверки продукции.
Шаг 4: Используйте расширенный статус status_ex, если он доступен в ответе API, так как он дает более детальную информацию о нахождении товара (например, заблокирован ли код в рамках другой незавершенной операции).
Соблюдение этих правил позволит создать надежную систему интеграции, которая не будет давать сбоев при обновлении данных на стороне ГИС МТ и обеспечит корректное проведение документов в 1С без ошибок валидации марок.