Как правильно хранить артикулы покупателей в 1С:Управление торговлей 11.4

При работе с крупными торговыми сетями (Metro, Лента, X5 Group) или маркетплейсами (Ozon, Wildberries) перед пользователями 1С:УТ 11.4 неизбежно встает задача: где хранить артикулы покупателей? Эти данные необходимы для корректного заполнения печатных форм, обмена через ЭДО и автоматизации заказов. В этой статье мы подробно разберем, какие штатные механизмы предлагает система и как их адаптировать под реальные бизнес-задачи, когда у одного покупателя могут быть разные артикулы для разных подразделений.

Метод 1. Использование механизма «Номенклатура поставщиков»

Несмотря на название, этот функционал в 1С:УТ 11 является универсальным и предназначен для хранения сопоставлений вашей номенклатуры с данными любых внешних контрагентов. Рассмотрим, как это работает.

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

Разберем по шагам процесс занесения данных:

1. Откроем карточку Партнера (покупателя).
2. Перейдем в панель навигации в раздел Номенклатура поставщика.
3. Создадим новую запись, где укажем:
   • Наименование и Артикул (как они заведены в базе покупателя).
   • Номенклатуру и Характеристику вашей базы, к которым привязывается этот артикул.

Этот метод является ПРАВИЛЬНЫМ с точки зрения архитектуры 1С, так как данные хранятся в специализированном справочнике Справочник.НоменклатураКонтрагентов, который уже интегрирован во многие типовые механизмы поиска и печати.

Метод 2. Решение проблемы разных артикулов для разных РЦ

Часто возникает ситуация (как упоминал автор темы на примере Metro), когда у одного юридического лица есть разные распределительные центры (РЦ) или типы магазинов (оптовые и розничные), и артикулы на один и тот же товар там различаются. Штатная Номенклатура поставщиков привязана к объекту Партнер.

Проанализируем ситуацию: как связать артикул не просто с клиентом, а с конкретным договором или точкой доставки? Выясним причину ограничений: типовая конфигурация предполагает, что один партнер — это одна логистическая единица. Чтобы решить проблему, мы рекомендуем использовать управленческую структуру справочника Партнеры:

Создадим иерархию:

• Головной партнер (например, «Метро Кэш энд Керри»);
• Подчиненный партнер 1 («Метро РЦ Опт»);
• Подчиненный партнер 2 («Метро РЦ Розница»).

При этом Контрагент (юридическое лицо для документов) у них будет общий. В этом случае для каждого подчиненного партнера можно завести свой уникальный список артикулов в «Номенклатуре поставщиков». Это позволит системе автоматически подтягивать нужный артикул в зависимости от того, какой грузополучатель (Партнер) выбран в заказе или реализации.

Метод 3. Хранение через дополнительные сведения

Если дорабатывать базу нельзя, а плодить партнеров не хочется, рассмотрим вариант использования Дополнительных сведений. В отличие от реквизитов, сведения не меняют структуру таблиц БД и хранятся в отдельном регистре.

Посмотрим на алгоритм настройки:

1. Перейдем в НСИ и администрирование — Общие настройки — Дополнительные реквизиты и сведения.
2. Для объекта Номенклатура создадим новое Дополнительное сведение с типом «Строка».
3. Назовем его, например, «Артикул в Ленте».

Такой подход удобен для вывода в печатные формы. Достаточно в макете обратиться к значению этого сведения. Однако у него есть существенный минус: если у вас 50 покупателей-сетей, вам придется создать 50 доп. сведений в каждой карточке товара, что крайне неудобно для поддержки.

Метод 4. Интеграция с ЭДО и Библиотекой электронного документооборота (БЭД)

Если вы обмениваетесь документами через 1С-ЭДО, система уже хранит сопоставления. Проанализируем техническую сторону: в системе существует скрытый регистр сведений НоменклатураКонтрагентовБЭД.

Когда вы получаете заказ (ORDER) или отправляете УПД через ЭДО, система предлагает сопоставить номенклатуру. Эти данные (включая артикул и идентификатор покупателя) сохраняются автоматически. Если ваша задача — автоматизация заполнения документов, приходящих извне, то лучше всего использовать именно этот регистр.

Пример программного обращения к данным сопоставления (условно):

Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	НоменклатураКонтрагентов.Артикул КАК АртикулПокупателя
    |ИЗ
    |	РегистрСведений.НоменклатураКонтрагентовБЭД КАК НоменклатураКонтрагентов
    |ГДЕ
    |	НоменклатураКонтрагентов.Владелец = &Контрагент
    |	И НоменклатураКонтрагентов.Номенклатура = &Номенклатура";

Метод 5. Создание собственного регистра (Расширение)

Если стандартных полей справочника Номенклатура поставщиков недостаточно (например, нужна жесткая привязка к Договору или Соглашению), наиболее правильным техническим решением будет создание Расширения конфигурации.

Выясним, какую структуру регистра лучше использовать. Создадим новый РегистрСведений «АртикулыПокупателей» со следующими измерениями:

• Номенклатура (Тип: СправочникСсылка.Номенклатура)
• Партнер (Тип: СправочникСсылка.Партнеры)
• Соглашение (Тип: СправочникСсылка.СоглашенияСКлиентами) — это позволит разделить артикулы в рамках одного клиента по разным контрактам.

В качестве ресурса добавим поле Артикул (Строка).

Преимущество этого метода в том, что он позволяет реализовать любую логику (например, привязку к GLN — уникальному номеру точки доставки в системе EDI), не затрагивая типовые механизмы и обеспечивая легкость обновления конфигурации.

Выводы и рекомендации

Подводя итог, выберем оптимальный путь:

1. Для простых случаев, когда у клиента один артикул на один товар — используйте штатный справочник Номенклатура поставщиков.
2. Для работы с сетями (Metro, Лента), где артикулы зависят от точки поставки — используйте иерархию Партнеров и привязывайте артикулы к конечным точкам (Партнерам-филиалам).
3. Если требуется сложная логика с привязкой к договорам или специфическим идентификаторам EDI — создавайте собственный регистр в расширении.
4. Не рекомендуется использовать Штрихкоды номенклатуры для хранения артикулов, так как это может привести к ошибкам при сканировании товаров на складе.

Правильно организованное хранение артикулов позволит вам не только корректно печатать документы, но и значительно ускорить обработку входящих заказов от покупателей, исключив ошибки «ручного» подбора позиций.