Почему дополнительные реквизиты недоступны для всех справочников в 1С? Разбор архитектуры БСП

← На главную

При работе с программными продуктами на платформе 1С:Предприятие 8.3 (например, 1С:ЗУП 3.1, 1С:ERP или 1С:УТ) пользователи и начинающие разработчики часто сталкиваются со странной ситуацией. В конфигураторе у множества справочников мы видим табличную часть ДополнительныеРеквизиты, а также настроенные характеристики. Однако при попытке добавить новый дополнительный реквизит в режиме «1С:Предприятие» в списке доступных справочников отображается лишь малая часть из них.

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

Архитектурные причины ограничений: почему не все справочники равны?

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

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

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

Где хранятся настройки доступности: Справочник «Наборы дополнительных реквизитов и сведений»

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

Однако просто добавить элемент в этот справочник в режиме конфигуратора недостаточно. Требуется провести комплексную интеграцию справочника с подсистемой БСП.

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

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

Шаг 1. Программная регистрация в общем модуле БСП

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

Нам необходимо программно добавить описание нашего набора свойств. Посмотрим на пример кода, который решает эту задачу:


Процедура ПриПолученииПредопределенныхНаборовСвойств(Наборы) Экспорт

    // Регистрируем наш справочник в системе свойств БСП
    Набор = Наборы.Строки.Добавить();
    Набор.Имя = "Справочник_ИмяВашегоСправочника";
    Набор.Идентификатор = Новый УникальныйИдентификатор("00000000-0000-0000-0000-000000000000"); // Укажите уникальный UUID
    Набор.Используется = Истина;

КонецПроцедуры

При очередном обновлении версии конфигурации или при первом запуске информационной базы БСП автоматически считает эти данные и создаст соответствующий предопределенный элемент в справочнике НаборыДополнительныхРеквизитовИСведений.

Шаг 2. Настройка метаданных справочника в конфигураторе

Теперь подготовим сам справочник на уровне метаданных в конфигураторе. Нам нужно связать его типы данных с БСП:

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

Шаг 3. Внедрение кода в форму элемента справочника

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

1. На форме элемента создадим обычную группу без отображения с именем ГруппаДополнительныеРеквизиты. Именно сюда подсистема БСП будет выводить элементы управления.

2. В модуле формы пропишем стандартные вызовы обработчиков БСП. Рассмотрим пример реализации:


&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
    
    // Инициализируем свойства на форме
    УправлениеСвойствами.ПриСозданииНаСервере(ЭтотОбъект, "ГруппаДополнительныеРеквизиты");
    
КонецПроцедуры

&НаСервере
Процедура ПриЧтенииНаСервере(ТекущийОбъект)
    
    // Заполняем значения дополнительных реквизитов при чтении элемента
    УправлениеСвойствами.ПриЧтенииНаСервере(ЭтотОбъект, ТекущийОбъект);
    
КонецПроцедуры

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

&НаСервере
Процедура ОбработкаПроверкиЗаполненияНаСервере(Отказ, ПроверяемыеРеквизиты)
    
    // Проверяем обязательность заполнения дополнительных реквизитов
    УправлениеСвойствами.ОбработкаПроверкиЗаполненияНаСервере(ЭтотОбъект, Отказ, ПроверяемыеРеквизиты);
    
КонецПроцедуры

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

Важный нюанс: служебный реквизит «Используется»

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

У каждого элемента справочника НаборыДополнительныхРеквизитовИСведений имеется скрытый от глаз обычного пользователя служебный реквизит Используется (тип Булево). При программном создании предопределенных наборов он по умолчанию может принимать значение Ложь.

Решение проблемы:

Откройте в режиме «1С:Предприятие» обработку «Групповое изменение реквизитов» (доступна в подразделе «Администрирование» -> «Обслуживание» -> «Корректировка данных»).
Включите отображение служебных реквизитов в настройках обработки.
Выберите справочник НаборыДополнительныхРеквизитовИСведений, найдите нужный элемент (ваш справочник) и принудительно установите реквизиту Используется значение Истина.

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

Резюме

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