При маркировке остатков обуви в типовой конфигурации 1С:Управление торговлей 11 многие пользователи сталкиваются с проблемой на этапе заказа кодов маркировки. Система выдает ошибку от Честного ЗНАКа: «55: Не уникальная комбинация значений полей [Способ ввода товара в оборот PRODUCED_IN_RF, Целевой пол MALE] в документе Описание остатков товара». При этом документ может зависнуть, а коды GTIN так и не появляются в 1С. Разберем подробно, почему возникает эта ошибка и какие существуют способы ее решения.
Для начала проанализируем ситуацию с точки зрения методологии Национального каталога. Ошибка 55 означает, что на ваш ИНН уже был успешно зарегистрирован код GTIN с абсолютно такой же комбинацией базовых атрибутов.
По правилам упрощенной маркировки остатков (когда мы не описываем каждую модель детально), код GTIN выдается не на каждую отдельную позицию номенклатуры (например, туфли красные 38 размера), а на уникальную комбинацию трех параметров:
Это означает, что на весь ваш ассортимент остатков обуви физически может быть выделено всего около 8-10 уникальных кодов GTIN (обычно они начинаются с цифр 029). Если у вас есть 100 разных номенклатурных позиций женской обуви, произведенной в РФ, то для них всех должен использоваться один и тот же GTIN. Различаться будут только серийные уникальные номера марок (SGTIN), которые вы будете заказывать в нужном количестве на этот единый GTIN.
Если в 1С произошел сбой, программа не получила ответ вовремя, или вы попытались создать новый заказ на эмиссию для аналогичных товаров — Честный ЗНАК отклонит запрос с ошибкой 55, так как такой GTIN для вашей организации уже выпущен.
Рассмотрим по шагам первый вариант решения, который отлично зарекомендовал себя на практике. Суть метода заключается в том, чтобы забрать готовый код из личного кабинета и "подсунуть" его в систему, чтобы 1С перестала его запрашивать заново.
Заказ на эмиссию кодов маркировки, который отправлялся по этой комбинации товаров.После этой манипуляции при создании новых документов 1С увидит, что в старых заказах для подобного вида товара уже есть выданный GTIN. Программа перестанет запрашивать его генерацию повторно (следовательно, ошибка 55 уйдет) и будет автоматически подставлять найденный код. Далее эмиссия кодов маркировки (SGTIN) пройдет без проблем.
Посмотрим на альтернативный способ, который будет полезен, если предыдущий вариант не сработал или если вы перешли в новую информационную базу и старых документов заказа просто нет. Мы можем добавить код напрямую во внутренние справочники 1С.
ПредставленияGTINИСМП.Как только вы вручную свяжете номенклатуру и GTIN в этом регистре, система "узнает" код. Также в некоторых релизах помогает использование штатной кнопки «Заполнить доступные GTIN» в документе описания остатков, которая автоматически подтягивает данные, если они были загружены в фоновом режиме.
Многие пользователи отмечают, что при нажатии кнопки «Заполнить» — «Доступные GTIN» программа намертво подвисает и ничего не происходит. Выясним причину этой проблемы.
Зависание при попытке получения кодов чаще всего связано с ошибками в конкретном релизе модуля интеграции с ИС МП (Информационной системой маркировки и прослеживаемости), встроенного в типовую конфигурацию. Чтобы исправить это поведение, не обязательно привлекать программиста. Вам необходимо:
Администрирование — Интернет-поддержка и сервисы — Обновление версии программы.Часто возникает вопрос: нужно ли удалять зависшие и ошибочные заказы в Станции управления заказами (СУЗ)? Рассмотрим этот момент подробнее.
Вы можете зайти на сайт Честного ЗНАКа в личный кабинет, перейти в раздел управления заказами (СУЗ) и нажать на красный крестик рядом с зависшим заказом. Однако стоит понимать важную деталь: удаление заказа на эмиссию в СУЗ не удаляет сам сгенерированный GTIN из Национального каталога! Если GTIN хотя бы один раз успешно присвоен вашему ИНН, он останется там навсегда.
Поэтому повторные запросы из 1С на ту же комбинацию атрибутов все равно будут вызывать Ошибку 55. Если вы не хотите удалять заказы вручную, вы можете просто подождать. Согласно логике работы СУЗ, примерно через двое суток необработанные или зависшие заказы автоматически перемещаются из вкладки «Активные» во вкладку «История» и перестают визуально мешать работе.