Как расширить состав реквизитов предопределенных элементов справочника в 1С?

← На главную

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

Почему нельзя заполнить реквизиты предопределенного элемента в конфигураторе?

Проанализируем архитектуру платформы «1С:Предприятие». В окне редактирования предопределенных элементов справочника разработчику доступны только три базовых поля: Имя (идентификатор в метаданных), Код и Наименование. Задать значения произвольных реквизитов непосредственно в дереве метаданных невозможно.

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

Рассмотрим основные способы реализации поставленной задачи в зависимости от требований к изменяемости данных.

Способ 1. Добавление стандартного реквизита с однократным программным заполнением

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

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

Посмотрим на пример защиты предопределенного элемента от перезаписи служебного реквизита в модуле объекта:


Процедура ПередЗаписью(Отказ)
    Если Предопределенный И Не ЭтоНовый() Тогда
        СсылкаВБазе = Ссылка.ПолучитьОбъект();
        Если СсылкаВБазе <> Неопределено И ЭтотОбъект.Описание <> СсылкаВБазе.Описание Тогда
            Отказ = Истина;
            ВызватьИсключение "Запрещено изменять описание предопределенного элемента!";
        КонецЕсли;
    КонецЕсли;
КонецПроцедуры

Способ 2. Вычисление описания через модуль менеджера без добавления реквизита

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

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

Посмотрим на пример реализации такой функции в модуле менеджера справочника:


Функция ПолучитьОписаниеПредопределенного(ЭлементСправочника) Экспорт
    ИмяПредопределенного = ЭлементСправочника.ИмяПредопределенныхДанных;
    
    Если ИмяПредопределенного = "ОсновнойСклад" Тогда
        Возврат "Центральный распределительный склад компании.";
    ИначеЕсли ИмяПредопределенного = "ТранзитныйСклад" Тогда
        Возврат "Склад для временного хранения перемещаемых грузов.";
    КонецЕсли;
    
    Возврат "";
КонецФункции

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

Способ 3. Вынос данных в независимый регистр сведений

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

В такой ситуации создадим независимый непериодический регистр сведений:

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

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