При работе с маркируемым товаром в системе 1С:Управление нашей фирмой (УНФ) пользователи часто сталкиваются с необходимостью получения кодов GTIN через сервис 1С:Номенклатура и интеграцию с Национальным каталогом (система «Честный ЗНАК»). Одной из наиболее специфических проблем является ошибка валидации данных, при которой система сообщает о многократной передаче одного и того же атрибута в текущем массиве (фиде).
Рассмотрим подробнее текст типичной ошибки: Ошибка заполнения атрибута 'Код товара в учетной системе поставщика' (идентификатор Национального каталога: 13797): Атрибут передан несколько раз в текущем массиве. Аналогичная ошибка часто возникает и для атрибута Наименование товара в учетной системе поставщика (идентификатор 2480). Проанализируем причины этой ситуации и разберем по шагам методы её решения.
Для начала разберем, что означают указанные идентификаторы. В структуре Национального каталога каждый реквизит имеет свой уникальный системный ID. Например, ID 13797 жестко закреплен за кодом товара, а ID 2480 — за его наименованием. Когда программа 1С формирует пакет данных (JSON-фид) для отправки в сервис, она собирает значения из различных полей карточки номенклатуры и её дополнительных реквизитов.
Ошибка «передан несколько раз» означает, что в сформированном пакете данных для одной позиции номенклатуры система дважды (или более) попыталась записать значение в один и тот же системный слот. Это происходит из-за избыточности настроек сопоставления в вашей базе 1С. Проанализируем ситуацию: если в настройках категории 1С:Номенклатуры два разных поля (например, стандартный «Артикул» и пользовательский «Код для весов») сопоставлены с одним и тем же атрибутом Национального каталога (13797), выгрузка будет прервана с ошибкой.
Как показывает практика и подтверждают ответы технической поддержки, наиболее частой причиной являются лишние или продублированные дополнительные реквизиты. Разберем, как это проверить:
В некоторых случаях ДополнительныеРеквизиты могут содержать скрытые записи, которые не видны в форме элемента, но присутствуют в табличной части. Для очистки таких данных можно использовать стандартную обработку «Групповое изменение реквизитов», чтобы проверить значения полей у проблемных позиций.
Рассмотрим вариант решения, предложенный опытными пользователями, который помогает «сбросить» некорректные связи в метаданных сервиса. Посмотрим на алгоритм действий:
Этот метод позволяет очистить кэшированные настройки сопоставления, которые могли повредиться при обновлении релиза или смене версии API 1С:Номенклатуры.
Проанализируем ситуацию, когда в УНФ используются характеристики. Если для одного товара создано несколько характеристик, система должна выгружать каждую как отдельный экземпляр с уникальным идентификатором. Однако, если настройки сопоставления указаны неверно, 1С может попытаться отправить для каждой характеристики общее наименование «владельца» (самой номенклатуры) под видом уникального атрибута.
Убедимся, что в настройках выгрузки для атрибута Код товара в учетной системе поставщика (ID 13797) выбрано поле, гарантирующее уникальность. Если вы используете характеристики, это должно быть сочетание Код + Характеристика или GUID. Если же в настройках выбрано просто поле Артикул, и он одинаковый у всех характеристик товара, система воспримет это как передачу одного и того же значения несколько раз для разных сущностей в рамках одного фида.
Иногда ошибка может быть вызвана не только логическим дублированием, но и техническим сбоем парсера. Рассмотрим несколько дополнительных моментов:
\n, \r). Иногда они заставляют API воспринимать одну строку как две, что приводит к ложному срабатыванию ошибки дублирования.ЭДО, Маркировка или БЭД (Библиотека электронного документооборота).Подводя итог, можно сказать, что решение проблемы всегда кроется в Настройках соответствия реквизитов для категорий. Выясним алгоритм финальной проверки:
13797 и 2480 с системными полями 1С.Соблюдение этих правил позволит успешно выгрузить товар, получить GTIN и продолжить работу с маркировкой в штатном режиме.