Чем заменить метод НайтиПоКоду и жесткую привязку по GUID в 1С?

← На главную

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

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

Почему не стоит использовать НайтиПоКоду() и жесткую фиксацию GUID

Рассмотрим подробнее проблемы, которые возникают при использовании устаревших подходов:

Хрупкость метода НайтиПоКоду(): поиск по строковому коду крайне чувствителен к форматированию (наличие или отсутствие ведущих нулей, несовпадение длины строки, пробелы). Если в справочнике отключен контроль уникальности кодов или используется периодическая нумерация, метод вернет первый попавшийся элемент из индекса базы данных без гарантии однозначности. Кроме того, вызов этого метода в цикле создает избыточную нагрузку на СУБД, так как выполняет одиночные прямые чтения без кэширования.
Опасность метода ПолучитьСсылку(): платформа конструирует ссылку на основе переданного объекта УникальныйИдентификатор без фактического обращения к базе данных. Метод возвращает ссылку даже в том случае, если элемента с таким GUID в базе никогда не существовало или он был удален. Проверка Ссылка.Пустая() для такого объекта вернет Ложь, а обращение к реквизитам вернет пустые значения или вызовет появление надписи «Объект не найден».
Хардкодинг и изменение бизнес-логики: жесткая фиксация кода, наименования или GUID в тексте модулей делает конфигурацию негибкой. Пользователь может переименовать элемент, заменить его или пометить на удаление. Если организации потребуется выбрать другого контрагента или статью затрат, придется вносить изменения в программный код и обновлять конфигурацию.

Вариант 1. Использование констант и регистров сведений для настроек

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

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


// Получение значения из константы
ОсновнойКонтрагент = Константы.ОсновнойКонтрагентДляРасчетов.Получить();

Если Не ЗначениеЗаполнено(ОсновнойКонтрагент) Тогда
    ВызватьИсключение "В настройках системы не заполнен основной контрагент!";
КонецЕсли;

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

Вариант 2. Предопределенные элементы и управление свойством ИмяПредопределенныхДанных

Если элемент справочника жестко завязан на логику конфигурации и алгоритмы не могут функционировать без него, используем механизм предопределенных элементов. В платформе 1С:Предприятие 8.3 предопределенные элементы можно связывать с кодовой базой без обязательного создания элементов в дереве метаданных конфигуратора.

Для обращения к предопределенному элементу в коде используем конструкцию:

Контрагент = Справочники.Контрагенты.ОсновнойПартнер;

Если элемент уже создан пользователем в режиме «1С:Предприятие», мы можем программно привязать его к логике конфигурации, заполнив системный реквизит ИмяПредопределенныхДанных:


ОбъектКонтрагент = ВыбраннаяСсылка.ПолучитьОбъект();
ОбъектКонтрагент.ИмяПредопределенныхДанных = "ОсновнойПартнер";
ОбъектКонтрагент.Записать();

Такой подход защищает элемент от случайного удаления пользователем и дает строгую типизацию в коде.

Вариант 3. Поиск по устойчивым бизнес-идентификаторам через запрос

Когда требуется программно сопоставить данные (например, при загрузке информации из внешних систем или файлов), вместо внутреннего кода базы или GUID следует выполнять поиск по ключевым реквизитам предметной области (ИНН + КПП, штрихкод, артикул).

Посмотрим на пример безопасного поиска контрагента через запрос с контролем уникальности:


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

Запрос.УстановитьПараметр("ИНН", ИскомыйИНН);
Запрос.УстановитьПараметр("КПП", ИскомыйКПП);

Результат = Запрос.Выполнить();
Выборка = Результат.Выбрать();

Если Выборка.Следующий() Тогда
    НайденныйКонтрагент = Выборка.Ссылка;
Иначе
    НайденныйКонтрагент = Справочники.Контрагенты.ПустаяСсылка();
КонецЕсли;

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

Вариант 4. Служебные регистры соответствия для интеграций

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

Измерение: ИдентификаторИсточника (Строка) — внешний ID или GUID.
Измерение: ТипОбъекта (Строка).
Ресурс: Ссылка1С (Ссылка на объект метаданных).

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