Как реализовать сопоставление номенклатуры поставщиков в 1С:Розница 2.3?

← На главную

В типовой конфигурации 1С:Розница 2.3 часто не хватает функционала, который является базовым для более тяжелых решений, таких как Управление торговлей 11. Одной из таких задач является создание механизма сопоставления «своей» номенклатуры с номенклатурой поставщика. Это критично при оформлении заказов, импорте прайс-листов или работе с электронным документооборотом (ЭДО), когда один и тот же товар у разных поставщиков может называться по-разному. Разберем подробно, как правильно спроектировать и реализовать эту фичу, используя лучшие практики разработки на платформе 1С.

Выбор архитектуры: Справочник или Регистр сведений?

Проанализируем ситуацию, с которой сталкивается разработчик при проектировании связей. На первый взгляд, создание Регистра сведений кажется логичным решением для хранения связей типа «многие-ко-многим». Однако, если мы обратимся к эталонной реализации в УТ 11 или ERP, мы увидим, что там используется подчиненный справочник. Выясним причину такого выбора.

Использование справочника НоменклатураКонтрагентов (или НоменклатураПоставщиков) дает следующие преимущества:

Подчинение владельцу: Мы можем сделать справочник подчиненным справочнику Контрагенты. Это автоматически фильтрует данные в формах выбора.
Объектная сущность: Справочник позволяет хранить не только ссылку на товар, но и дополнительные реквизиты: артикул поставщика, специфическое наименование, штрихкоды поставщика и даже индивидуальные упаковки.
Производительность: При индексации реквизита Номенклатура (ваша позиция) поиск по справочнику для обратного сопоставления работает так же быстро, как и по регистру сведений, при условии, что объем данных не исчисляется миллионами записей.

Рассмотрим вариант реализации, который будет наиболее устойчив к обновлениям и удобен пользователю.

Шаг 1. Создание справочника «Номенклатура поставщиков»

Создадим новый объект метаданных — справочник НоменклатураПоставщиков. Настроим его структуру следующим образом:

Владелец: Справочник Контрагенты. Это позволит нам жестко привязать наименования к конкретному поставщику.
Реквизит «Номенклатура»: Тип СправочникСсылка.Номенклатура. Установите свойство Индексировать, чтобы обеспечить быстрый поиск.
Реквизит «Артикул»: Строка, для хранения кода товара в системе поставщика.
Наименование: Стандартное поле, куда записывается название товара так, как оно звучит у поставщика.

Для программиста, привыкшего к JavaScript, это можно представить как создание таблицы с Foreign Key на таблицу контрагентов и таблицу вашей номенклатуры.

Шаг 2. Реализация двустороннего заполнения в форме документа

Теперь проанализируем, как заставить форму Заказа поставщику работать интерактивно. Нам нужно, чтобы при выборе «Моей номенклатуры» подтягивалась «Номенклатура поставщика», и наоборот. Разберем это по шагам.

В форме документа (например, ЗаказПоставщику) в табличную часть Товары добавим колонку НоменклатураПоставщика (тип СправочникСсылка.НоменклатураПоставщиков).

Для автоматизации выбора воспользуемся событием ПриИзменении. Рассмотрим пример кода для обработки выбора вашей номенклатуры:


&НаКлиенте
Процедура ТоварыНоменклатураПриИзменении(Элемент)
    СтрокаТаблицы = Элементы.Товары.ТекущиеДанные;
    Если ЗначениеЗаполнено(СтрокаТаблицы.Номенклатура) Тогда
        // Вызываем серверную функцию для поиска сопоставления
        НоменклатураПоставщика = НайтиСопоставлениеНаСервере(СтрокаТаблицы.Номенклатура, Объект.Поставщик);
        Если ЗначениеЗаполнено(НоменклатураПоставщика) Тогда
            СтрокаТаблицы.НоменклатураПоставщика = НоменклатураПоставщика;
        КонецЕсли;
    КонецЕсли;
КонецПроцедуры

&НаСервереБезКонтекста
Функция НайтиСопоставлениеНаСервере(Знач ВашаНоменклатура, Знач Поставщик)
    Возврат Справочники.НоменклатураПоставщиков.НайтиПоРеквизиту("Номенклатура", ВашаНоменклатура, , Поставщик);
КонецФункции

И наоборот, если пользователь первым выбирает Номенклатуру поставщика, мы должны мгновенно заполнить поле Номенклатура:


&НаКлиенте
Процедура ТоварыНоменклатураПоставщикаПриИзменении(Элемент)
    СтрокаТаблицы = Эelements.Товары.ТекущиеДанные;
    Если ЗначениеЗаполнено(СтрокаТаблицы.НоменклатураПоставщика) Тогда
        // Получаем данные напрямую из реквизита справочника-ссылки
        СтрокаТаблицы.Номенклатура = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(СтрокаТаблицы.НоменклатураПоставщика, "Номенклатура");
    КонецЕсли;
КонецПроцедуры

Шаг 3. Использование «Связей параметров выбора» (Low-code подход)

Чтобы упростить жизнь пользователю, настроим Связи параметров выбора для реквизита НоменклатураПоставщика прямо в конфигураторе. Это позволит системе автоматически фильтровать список сопоставленных товаров по поставщику, указанному в шапке документа.

В свойствах поля НоменклатураПоставщика (в табличной части документа) найдите пункт Связи параметров выбора. Добавьте новую связь:

Параметр выбора: Отбор.Владелец
Путь к данным: Объект.Поставщик

Благодаря этому, при нажатии на кнопку выбора в колонке «Номенклатура поставщика», пользователь увидит только те позиции, которые принадлежат контрагенту из текущего документа.

Доработка Розницы или переход на УТ 11?

Рассмотрим важный стратегический вопрос: стоит ли «допиливать» Розницу или лучше внедрить связку УТ + Розница. Проанализируем аргументы участников обсуждения.

Почему доработка Розницы может быть оправдана:

У вас один небольшой магазин и один склад.
Вам не нужны сложные механизмы обеспечения потребностей (автоматический расчет заказов на основе транспортного плеча, интервалов поставок и т.д.).
Вы хотите избежать проблем с синхронизацией данных и «разбеганием» остатков между двумя базами.

Почему связка УТ 11 + Розница 2.3 эффективнее в долгосроке:

Аналитика: В УТ 11 гораздо мощнее блок взаиморасчетов (акты сверки, графики платежей).
Скидки и маркетинг: Как отмечено в обсуждении, механизмы оптовых и накопительных скидок в Рознице реализованы специфично (через маркетинговые мероприятия), что может быть неудобно для смешанной торговли.
Разделение функций: В УТ работает менеджер по закупкам и оптовый отдел, а Розница используется исключительно как Front-office для пробития чеков.

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

Резюме для разработчика

Если ваша цель — быстрое и надежное решение в рамках Розницы 2.3, используйте подчиненный справочник. Это наиболее близкая к типовым стандартам архитектура. Помните об индексации полей поиска и использовании серверных вызовов НаСервереБезКонтекста для обеспечения отзывчивости интерфейса. Если же бизнес начинает расти в сторону опта или сложной логистики — не тратьте время на переписывание Розницы, переходите на УТ.