При работе с государственной системой маркировки «Честный знак» многие разработчики и пользователи сталкиваются с рядом вызовов и неочевидных моментов. В данной статье мы рассмотрим наиболее острые проблемы, касающиеся API, тестирования, интеграции с 1С, классификации товаров и спорных юридических аспектов, основываясь на опыте сообщества и официальной информации.
Одной из ключевых трудностей, с которой мы можем столкнуться при работе с API «Честного знака», является отсутствие методов для получения полного статуса заказов, особенно тех, которые уже закрыты. Рассмотрим эту ситуацию подробнее.
Если нам необходимо получить статус заказа в Станции управления заказами (СУЗ), мы обнаруживаем, что методы API не всегда соответствуют нашим потребностям. Например:
orders?omsId предназначен для получения всех заказов, но исключает закрытые. Это означает, что он не подходит для комплексного анализа, а получение состояния всех заказов может быть неэффективным.GET /api/v2/light/buffer/status?orderId возвращает ошибку, если заказ закрыт. Заказ может быть закрыт по разным причинам: как обычное завершение, так и аннулирование. В результате мы остаемся без информации о его конечном статусе.На прямой вопрос о наличии API-метода для просмотра статуса закрытого бизнес-заказа поступает официальный ответ: «В СУЗ метода API для просмотра статуса закрытого бизнес-заказа не предусмотрено». Это создает значительные сложности для разработчиков, поскольку мы видим эти состояния (например, «закрыт» или «аннулирован») в описаниях, но не имеем возможности программно их получить.
Еще один аспект, вызывающий вопросы, — это процесс получения кодов маркировки, особенно их повторное получение. Система предлагает два разных метода:
Казалось бы, это удобно, но загвоздка в том, что для повторного получения кодов необходимо указать ID пакета этих кодов. Это означает, что мы должны предварительно запросить эти ID. Вместо того, чтобы система могла сама проверить и предоставить нужные данные, она требует от нас выполнения дополнительных запросов, усложняя логику работы.
Далее ситуация усугубляется: если заказ закрыт, мы уже не можем получить по нему свои же собственные, оплаченные коды. Логика системы сводится к тому, что «заказ закрыт, чего вы хотите по закрытому заказу?». Метод «получить коды повторно» был создан для случаев проблем с базой данных, но подразумевается, что если заказ закрыт (или автоматически закрылся через 3 дня), то проблем с вашей базой данных уже быть не может.
Важный момент: Описание в текстовом формате часто оставляет желать лучшего, что дополнительно затрудняет понимание работы API.
С товарными группами также возникают недопонимания. В некоторых запросах требуется указывать товарную группу, и если она указана неверно, запрос возвращает ошибку с описанием, например, о том, что для этой группы нет заключенного договора. При этом в других запросах мы можем указать любую товарную группу, и система «съест» это за милую душу, вернув при этом верные данные. Возникает вопрос: зачем вообще нужна товарная группа в запросе, если у системы уже есть все необходимые данные (например, уникальные ID заказов)? Мы ощущаем, что это добавляет излишнюю сложность без видимой на то причины.
Для сторонних разработчиков, стремящихся протестировать функционал маркировки, например, для молочной продукции, где документ «Описание остатков» не предусмотрен, вопрос получения GTIN (Global Trade Item Number) для тестовых целей становится критическим. Оператор системы предлагает два варианта:
Эти варианты показывают, что разработчикам приходится проявлять инициативу и самостоятельно искать или создавать тестовые GTIN, поскольку удобного готового решения не предусмотрено.
Напоминаем: GTIN — это уникальный номер, присваиваемый каждому виду товара, являющийся международным стандартом, используемым более чем в 150 странах.
Определение принадлежности товара к категории маркируемых может быть весьма сложным, особенно в пограничных случаях. Мы видим это на примере рабочей одежды, которая по общим критериям может не подпадать под маркировку. Однако, если коды ТН ВЭД ЕАЭС на эту одежду совпадают с кодами маркируемых категорий, товар внезапно начинает подлежать обязательной маркировке. Это создает юридическую неопределенность и требует внимательного анализа законодательства.
Мы должны учитывать, что перечень товаров легкой промышленности, подлежащих обязательной маркировке, постоянно расширяется согласно постановлениям Правительства РФ (например, с 1 апреля 2024 года и 1 марта 2025 года). При возникновении трудностей с определением принадлежности товара, необходимо ориентироваться на коды ТН ВЭД ЕАЭС и/или ОКПД2.
Интеграция учетных систем, таких как 1С, с «Честным знаком» является ключевым этапом для автоматизации бизнес-процессов. Однако и здесь мы сталкиваемся с определенными нюансами.
Рассмотрим ситуацию с базой 1С:Управление торговлей 11. Если поставщик включает в одну накладную товары разных товарных групп, например, обувь и легкую промышленность, это может вызвать сложности. Мы наблюдали случай, когда после загрузки смешанной накладной, даже последующие документы только с обувной продукцией стали получать вид продукции «Товары легкой промышленности» в документах приемки.
Решение: В подобных случаях, даже если поставщик смешивает товары в одной накладной, мы настоятельно рекомендуем приходовать обувную и легпром разными накладными. Некоторые поставщики уже делят накладные на маркированный и немаркированный товар, а также по товарным группам. Если поставщик не готов к такому разделению, это может указывать на сложности в его собственных бизнес-процессах или на его неготовность к корректной работе с маркировкой.
Для успешной интеграции 1С с системой «Честный знак» нам потребуется:
В актуальных релизах 1С:Бухгалтерия 8.3 предусмотрена встроенная интеграция с ГИС МТ, что обеспечивает обмен данными в реальном времени и фиксацию статусов кодов маркировки. Для производителей обязательна настройка СУЗ в 1С, причем для каждого вида маркированной продукции необходимо настраивать отдельную СУЗ.
Мы, как пользователи и разработчики, периодически сталкиваемся с ошибками при работе с «Честным знаком». Одна из распространенных — «Ошибка запроса данных, код 500». Эта ошибка обычно связана с техническими сбоями на сервере «Честного знака» и, как правило, не зависит от наших действий. В таких случаях остается только ждать, пока проблемы будут устранены со стороны оператора системы.
Помимо серверных ошибок, мы также встречаем ошибки, связанные с:
Эти ошибки требуют внимательной проверки нашей конфигурации и корректности формируемых запросов.
Примечание: Стоимость одного кода маркировки составляет 50 копеек без НДС. Штрафы за нарушения могут достигать 1,5 миллиона рублей с конфискацией товара, что подчеркивает важность корректной работы с системой.
Вопрос о криптохвосте (или крипточасти) вызывает активные дискуссии в сообществе. Разберем его суть и связанные с ним спорные моменты.
Криптохвост — это последовательность символов, генерируемая с использованием криптографических алгоритмов. Его основное назначение — защита идентификатора от копирования и подтверждение подлинности товара. Он хранится в защищенной базе данных «Честного знака» и не предназначен для прямого считывания или копирования. Без криптохвоста код легко подделать, но с ним подделка становится бессмысленной, так как система распознает несоответствие при проверке.
Криптохвост является частью всего кода DataMatrix. Сам DataMatrix кодирует весь код, включая GTIN, серийный номер, ключ проверки и криптохвост. Однако в символьном коде, который часто печатается под DataMatrix для ручного ввода, обычно указывается только GTIN.
Мы понимаем, что криптохвост нужен для того, чтобы предотвратить возможность повторной печати одной и той же марки на другой единице товара, особенно в случаях, когда оригинал был утерян, поврежден или продан без фиксации в системе. Если бы мы могли просто перепечатать марку, это открыло бы возможности для легализации контрафактного товара или повторной продажи украденного.
Пример: Если у нас украли товар с маркой, и мы бы имели возможность просто распечатать эту же марку на «контрафактные» товары, мы могли бы их прекрасно продать через кассу, обходя систему контроля.
Одним из самых спорных вопросов является возможность хранения криптохвоста в базах данных участников оборота. Некоторые источники утверждают, что:
Однако другие участники сообщества и некоторые документы утверждают, что прямого законодательного запрета на хранение криптохвоста для большинства участников оборота нет. Так, например, в официальном документе, регулирующем общие правила работы, такой нормы не обнаруживается.
Оператором системы были направлены предложения по нормативному закреплению тезиса о невозможности хранения криптохвоста для производителей лекарственных препаратов. Это говорит о том, что вопрос является сложным и регулируется по-разному для разных товарных групп.
На практике: Купленные марки могут выдаваться в виде CSV-файла. Это позволяет нам печатать столько копий, сколько необходимо, и хранить их, если не существует прямого запрета. Однако, если мы напечатаем несколько упаковок с одним и тем же sgtin (серийным глобальным идентификатором торговой единицы), то только одну из них можно будет легально продать. Вторая вызовет тревогу в системе, независимо от наличия или отсутствия криптохвоста.
Тем не менее, если мы печатаем копию марки из-за порчи ее читаемости или отсутствия (например, при возврате от покупателя без упаковки), это является оправданным. В иных случаях, для новой единицы товара следует заказывать новую марку.
Система маркировки «Честный знак» постоянно развивается, и нам необходимо быть готовыми к изменениям в API, обновлению учетных систем и внимательно следить за документацией. Проблемы с API, тестированием, классификацией и юридическими аспектами являются частью рабочего процесса. Мы призываем к активному взаимодействию с поддержкой «Честного знака» и обмену опытом в сообществе, чтобы совместно находить решения и адаптироваться к новым требованиям.
Помним, что для корректной работы требуется своевременное обновление учетных систем, таких как 1С:Управление торговлей, для поддержки нового API. Документация по работе с API для зарегистрированных участников системы доступна в личном кабинете, а интеграторам рекомендуется обращаться к участникам системы маркировки для получения технической документации.