Как найти владельца номенклатуры при загрузке цен и избежать дублей в 1С

← На главную

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

Анализ проблемы: почему стандартный поиск не работает

Рассмотрим типичную ситуацию: в базе ведется учет для трех разных магазинов, и для каждого создана отдельная карточка одного и того же товара. При попытке загрузить цены через обработку «Загрузка данных из табличного документа», система обращается к методу НайтиПоРеквизиту или НайтиПоНаименованию. Проблема заключается в том, что эти методы возвращают первую найденную ссылку. Если в базе три «Болта М8» с одинаковым артикулом, 1С всегда будет выбирать только один из них, игнорируя остальные, что приведет к установке неверных цен для других подразделений.

Автор темы пытался использовать следующий код:


СсылкаНоменклатуры = Справочники.Номенклатура.НайтиПоРеквизиту("Артикул", ТекстЯчейки, , );
Результат = СсылкаНоменклатуры;

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

Решение 1: Исправление архитектуры НСИ (Единый справочник)

Проанализируем структуру базы. Создание дублей номенклатуры под каждый магазин — это так называемый «антипаттерн» в разработке на 1С. Правильным подходом является использование единой карточки номенклатуры для всех торговых точек. Разделение данных должно происходить на уровне регистров накопления и сведений.

Разберем, как это реализовать по шагам:

Объединение справочников: Необходимо провести ревизию и пометить на удаление дублирующиеся позиции, перенеся все остатки на одну «эталонную» карточку.
Использование складов: Для разделения остатков в документах поступления и реализации следует указывать разные элементы справочника Склады.
Виды цен: Вместо создания разных товаров для установки разных цен, создадим разные Виды цен (например, «Розничная Магазин 1», «Розничная Магазин 2»). В документе Установка цен номенклатуры можно будет указать разные значения для одного и того же товара в разрезе этих видов цен.
Настройка прав доступа (RLS): Чтобы пользователи разных магазинов не видели «чужие» документы или цены, настройте ограничение доступа на уровне записей. Это позволит работать в единой базе, сохраняя изоляцию данных.

Решение 2: Точная идентификация через уникальный идентификатор (GUID)

Если по каким-то причинам объединение номенклатуры невозможно в краткосрочной перспективе, необходимо изменить метод идентификации при загрузке. Вместо поиска по строковому артикулу следует использовать Уникальный идентификатор ссылки.

Проанализируем алгоритм:

При выгрузке шаблона для заполнения цен добавьте в таблицу скрытую колонку с внутренним идентификатором 1С (GUID).
При загрузке используйте поиск по этому идентификатору. Это гарантирует 100% точность, так как GUID уникален для каждого объекта в базе, даже если все остальные реквизиты совпадают.

Пример кода для получения ссылки по идентификатору из строки:


// Предположим, что ТекстGUID — это строка из колонки файла
Идентификатор = Новый УникальныйИдентификатор(ТекстGUID);
СсылкаНаОбъект = Справочники.Номенклатура.ПолучитьСсылку(Идентификатор);

Если СсылкаНаОбъект.ПолучитьОбъект() = Неопределено Тогда
    Сообщить("Объект не найден!");
Иначе
    Результат = СсылкаНаОбъект;
КонецЕсли;

Решение 3: Поиск по нескольким реквизитам

Рассмотрим ситуацию, когда идентификатор (GUID) получить невозможно. В этом случае нам нужно сузить область поиска, добавив дополнительный фильтр. Если номенклатура каждого магазина лежит в своей папке (группе), мы можем искать товар только внутри конкретной родительской группы.

Разберем пример функции для поиска с учетом родителя:


Функция НайтиТоварСУчетомМагазина(АртикулПоиска, ГруппаМагазина)
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |	Номенклатура.Ссылка КАК Ссылка
        |ИЗ
        |	Справочник.Номенклатура КАК Номенклатура
        |ГДЕ
        |	Номенклатура.Артикул = &Артикул
        |	И Номенклатура.ЭтоГруппа = ЛОЖЬ
        |	И Номенклатура.Ссылка В ИЕРАРХИИ(&Родитель)";
    
    Запрос.УстановитьПараметр("Артикул", АртикулПоиска);
    Запрос.УстановитьПараметр("Родитель", ГруппаМагазина);
    
    РезультатЗапроса = Запрос.Выполнить();
    Если Не РезультатЗапроса.Пустой() Тогда
        Выборка = РезультатЗапроса.Выбрать();
        Выборка.Следующий();
        Возврат Выборка.Ссылка;
    КонецЕсли;
    
    Возврат Справочники.Номенклатура.ПустаяСсылка();
КонецФункции

Решение 4: Привязка видов цен к складам

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

Важные шаги настройки:

Перейдите в раздел Склады и магазины.
Для каждой торговой точки создайте отдельный элемент.
В поле Тип цен выберите соответствующий прайс-лист для данного магазина.

Практические советы по работе с импортом данных

Выясним, как правильно настроить саму обработку загрузки, чтобы «прилипание» цены происходило корректно:

Использование штрихкодов: Штрихкод обычно более уникален, чем артикул. Если у ваших товаров разные внутренние штрихкоды, используйте для поиска регистр сведений ШтрихкодыНоменклатуры.
Дополнительные реквизиты: Можно добавить в справочник Номенклатура доп. реквизит «Магазин-владелец» и использовать его в условиях запроса при поиске, как мы рассматривали в Решении 3.
Контроль уникальности: Верните контроль уникальности кодов в конфигураторе. Это дисциплинирует пользователей и предотвращает появление неконтролируемых дублей в будущем.

Подводя итог, отметим: если вы программируете в среде 1С, всегда стремитесь к минимизации избыточности данных. Один товар — одна карточка. Все различия (цены, остатки, характеристики) должны описываться через подчиненные справочники и регистры. Это обеспечит стабильную работу системы и легкость при внедрении новых инструментов автоматизации.