Как получить ссылку на элемент справочника без кода в 1С:ERP?

← На главную

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

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

Вариант 1. Получение ссылки по уникальному идентификатору (GUID)

Это один из самых быстрых и популярных способов среди разработчиков, когда нужно жестко завязаться на конкретный элемент справочника без изменения метаданных конфигурации. Уникальный идентификатор (UUID/GUID) гарантирует, что даже если пользователь переименует должность в пользовательском режиме, код продолжит работать исправно.

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

Откроем базу в режиме «1С:Предприятие» и найдем нужный элемент справочника (например, должность директора).
Для получения GUID элемента можно воспользоваться внешней обработкой поиска ссылок или получить его быстро через отладчик в конфигураторе. Для этого поставим точку останова в любом месте, где доступна ссылка на нужный объект (например, в форме элемента при создании), и в табло вычислим выражение: Объект.Ссылка.УникальныйИдентификатор().
Скопируем полученную строковую конфигурацию GUID (например, "fc6ab9ad-6aa6-11de-b76f-0019bbe97e60").
Пропишем получение ссылки в коде нашей печатной формы или обработки.

Посмотрим на пример кода:


ИдентификаторСтрокой = "fc6ab9ad-6aa6-11de-b76f-0019bbe97e60";
Идентификатор = Новый УникальныйИдентификатор(ИдентификаторСтрокой);
СсылкаДолжность = Справочники.Должности.ПолучитьСсылку(Идентификатор);

Важное предупреждение: этот метод таит в себе скрытую опасность. Метод ПолучитьСсылку() не обращается к базе данных, он просто конструирует объект ссылки в оперативной памяти. Если эта база — тестовая, а в рабочей базе у той же должности другой GUID (или при переносе данных через XML/EnterpriseData идентификаторы изменились), мы получим так называемую «битую ссылку». При попытке прочитать ее реквизиты (например, наименование) программа выдаст критическую ошибку.

Чтобы обезопасить решение, обязательно используем функцию проверки физического существования записи в базе данных из библиотеки стандартных подсистем (БСП):


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

Вариант 2. Использование предопределенных элементов в расширениях

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

Выполним следующие шаги:

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

Для получения значения предопределенного элемента лучше использовать функции БСП. Это предотвратит аварийное завершение работы системы, если расширение по какой-то причине будет отключено:


ИмяПредопределенного = "Справочник.Должности.ОтветственныйЗаПодписьДокументов";
СсылкаДолжность = ОбщегоНазначения.ПредопределенныйЭлемент(ИмяПредопределенного);

Если ЗначениеЗаполнено(СсылкаДолжность) Тогда
    // Успешно получили предопределенный элемент из расширения
Иначе
    // Элемент не найден в метаданных расширения
КонецЕсли;

Вариант 3. Хранение настройки в константе

Если должность может отличаться в разных базах (например, в филиалах компании должности подписантов называются по-разному), жестко прописывать GUID или создавать предопределенные элементы не имеет смысла. Лучшим архитектурным решением станет создание персональной настройки.

Рассмотрим этот алгоритм:

Через расширение создадим новую константу, например, ОсновнаяДолжностьДляПечатныхФорм с типом значения СправочникСсылка.Должности.
Выведем эту константу на форму настроек нашей обработки или в общую панель администрирования. Пользователь или администратор системы сам один раз выберет нужную должность из справочника.
В коде печатной формы мы просто прочитаем значение этой константы.

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


СсылкаДолжность = Константы.ОсновнаяДолжностьДляПечатныхФорм.Получить();

Если Не ЗначениеЗаполнено(СсылкаДолжность) Тогда
    ОбщегоНазначенияКлиентСервер.СообщитьПользователю(
        "Не заполнена настройка 'Основная должность для печатных форм'!");
КонецЕсли;

Вариант 4. Поиск по дополнительным реквизитам (БСП)

Если требования безопасности запрещают вносить изменения в структуру метаданных (даже через расширения), мы можем задействовать типовой механизм БСП — дополнительные реквизиты и сведения.

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

Проанализируем пример запроса для поиска по дополнительному реквизиту:


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

Запрос.УстановитьПараметр("ИмяСвойства", "ИспользоватьДляПодписи");
Запрос.УстановитьПараметр("ЗначениеСвойства", Истина);

РезультатЗапроса = Запрос.Выполнить();
Если Не РезультатЗапроса.Пустой() Тогда
    Выборка = РезультатЗапроса.Выбрать();
    Выборка.Следующий();
    СсылкаДолжность = Выборка.Ссылка;
КонецЕсли;

Вариант 5. Использование типового механизма ответственных лиц в ERP

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

Вместо того чтобы искать должность Директор, правильнее использовать регистр сведений Ответственные лица организаций или справочник Лица с правом подписи.

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

Используйте программный интерфейс ERP для получения ответственных лиц:


ПараметрыПодписанта = ОтветственныеЛицаСервер.ПолучитьОтветственноеЛицоОрганизации(
    ОрганизацияДокумента, 
    Перечисления.ОтветственныеЛицаОрганизаций.Руководитель, 
    ДатаДокумента
);

Если ПараметрыПодписанта <> Неопределено Тогда
    ФизическоеЛицо = ПараметрыПодписанта.ФизическоеЛицо;
    СсылкаДолжность = ПараметрыПодписанта.Должность;
КонецЕсли;

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