Как программно использовать Имя элемента в Плане видов характеристик Дополнительные реквизиты и сведения

← На главную

При разработке в среде 1С, особенно при использовании Библиотеки стандартных подсистем (БСП), программисты часто сталкиваются с необходимостью обратиться к конкретному дополнительному реквизиту. Использование ссылок (GUID) крайне нежелательно, так как они могут отличаться в разных узлах распределенной базы или тестовых контурах. Поиск по наименованию («Заголовок») также опасен: пользователь может в любой момент изменить текст заголовка, что приведет к поломке логики. Именно для решения этой проблемы в БСП было введено поле «Имя» (для разработчиков).

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

Почему не работает конструкция ЗНАЧЕНИЕ()

Разберем типичную ошибку начинающего разработчика. Пытаясь обратиться к реквизиту в запросе, многие пробуют использовать стандартную конструкцию: ЗНАЧЕНИЕ(ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения.ИмяРеквизита). Однако система выдает ошибку.

Проанализируем причину: дополнительные реквизиты создаются пользователями или администраторами в режиме «1С:Предприятие». С точки зрения метаданных конфигурации, они являются обычными элементами справочника (или ПВХ), а не предопределенными данными. Конструкция ЗНАЧЕНИЕ() предназначена исключительно для объектов, созданных в Конфигураторе. Поле «Имя», которое мы видим в интерфейсе, — это обычный строковый реквизит элемента ПВХ ДополнительныеРеквизитыИСведения, а не имя метаданных.

Способ 1. Использование поля «Имя» в запросах

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

Допустим, нам нужно найти значение свойства с именем ДатаПоложенияПоСИЗ для конкретного объекта. Мы можем написать следующий запрос:


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

Важный нюанс: поле Имя в БСП обычно индексировано, поэтому такие запросы выполняются быстро. Однако, если вы обращаетесь к свойству через точку в сложных соединениях, убедитесь, что платформа может эффективно использовать индекс. Если тип поля Свойство является составным (что характерно для ТЧ дополнительных реквизитов), рекомендуется использовать оператор ВЫРАЗИТЬ.


ВЫБРАТЬ
    ТЧ.Значение
ИЗ
    Документ.ЗаказПокупателя.ДополнительныеРеквизиты КАК ТЧ
ГДЕ
    ВЫРАЗИТЬ(ТЧ.Свойство КАК ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения).Имя = "ВажноеСвойство"

Способ 2. Программное получение значения через модули БСП

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

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


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

Если Значение <> Неопределено Тогда
    // Обработка полученного значения
КонецЕсли;

Этот метод удобен тем, что система сама найдет нужную ссылку по строковому идентификатору внутри указанного набора свойств, связанного с объектом. Это позволяет избежать «магических GUID-ов» в коде.

Способ 3. Получение ссылки на свойство по имени

Иногда нам нужна сама ссылка на элемент ПВХ (например, чтобы передать её в параметры отчета или использовать для заполнения в новом объекте). Для этого в БСП также существуют методы поиска в кэше. Рассмотрим примерную логику поиска:

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


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

Преимущества использования «Имени» перед «Заголовком»

Выясним, почему разработчики настаивают на использовании поля Имя:

Независимость от локализации: В многоязычных базах заголовок может меняться в зависимости от языка пользователя (например, «Цвет» превратится в «Color»). Имя при этом останется неизменным (Cvet или Color_Prop).
Защита от изменений пользователя: Обычный пользователь может переименовать реквизит «Дата отгрузки» в «Желаемая дата доставки» просто для удобства интерфейса. Если ваш код завязан на заголовок — он сломается. Если на Имя — всё продолжит работать.
Интеграция и Enterprise Data: При обмене данными через формат Enterprise Data (XDTO) именно это поле часто используется для сопоставления свойств между разными базами (например, между УТ и БП), когда внутренние ссылки объектов не совпадают.

Риски и ограничения

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

Рекомендация: Для критически важных свойств, от которых зависит работа бизнес-логики, рекомендуется программно запрещать редактирование поля Имя в форме элемента ПВХ или скрывать его от обычных пользователей через права доступа.

Подводя итог, можно сказать, что использование поля Имя в Дополнительных реквизитах и сведениях — это стандарт де-факто для современной разработки на платформе 8.3. Это позволяет писать гибкий, переносимый код, который легко читать и поддерживать, сохраняя при этом все преимущества динамического расширения состава реквизитов без изменения метаданных.