Вопрос о динамическом создании реквизитов в справочниках 1С является классическим примером столкновения гибких требований бизнеса и строгой структуры реляционных баз данных, на которых базируется платформа 1С. Давайте разберем, почему «в лоб» эта задача не решается через конфигуратор в режиме реального времени, и проанализируем проверенные архитектурные подходы, которые позволяют обойти эти ограничения.
Прежде всего, важно понимать разницу между реквизитами объекта (которые хранятся в таблицах базы данных SQL) и реквизитами формы (которые существуют только в оперативной памяти во время работы пользователя). Изменение структуры базы данных «на лету» невозможно без монопольного доступа и реструктуризации, поэтому мы рассмотрим альтернативные способы реализации этой логики.
Рассмотрим ситуацию, когда нам не нужно создавать новое поле в таблице базы данных, но нужно вывести на экран дополнительные элементы для ввода данных. Для этого в управляемом приложении используется метод ИзменитьРеквизиты(). Проанализируем, как это работает на практике.
Этот метод позволяет добавить программные реквизиты формы, которые будут вести себя как обычные поля, но их значения нужно будет сохранять вручную (например, в связанный регистр или текстовую строку). Разберем пример кода, который добавляет строковое поле на форму:
// На сервере
МассивДобавляемыхРеквизитов = Новый Массив;
Реквизит = Новый РеквизитФормы("ДополнительноеПоле", Новый ОписаниеТипов("Строка"), , "Заголовок поля", Истина);
МассивДобавляемыхРеквизитов.Добавить(Реквизит);
// Добавляем реквизит в структуру формы
ЭтаФорма.ИзменитьРеквизиты(МассивДобавляемыхРеквизитов);
// Теперь создадим визуальный элемент для этого реквизита
Элемент = Элементы.Добавить("ДекоративноеПоле", Тип("ПолеФормы"), ЭтаФорма);
Элемент.Вид = ВидПоляФормы.ПолеВвода;
Элемент.ПутьКДанным = "ДополнительноеПоле";
Важный нюанс: данные, введенные в такие поля, исчезнут при закрытии формы, если вы не предусмотрите механизм их записи в базу данных (например, в процедуре ПриЗаписиНаСервере).
Если задача стоит так, чтобы пользователь сам мог создавать новые «реквизиты» (например, «Цвет», «Размер», «Материал») без участия программиста, то золотым стандартом является использование Планов видов характеристик. Выясним, почему это самый надежный метод.
План видов характеристик позволяет описать типы данных, которые могут принимать дополнительные свойства. Обычно этот механизм работает в связке с регистром сведений или табличной частью справочника. Рассмотрим преимущества этого подхода:
Для реализации этого метода необходимо в конфигураторе настроить вкладку «Характеристики» у справочника, указав, где именно (в каком регистре или табличной части) хранятся значения этих свойств.
Проанализируем более простой, но эффективный способ — добавление в справочник специальной табличной части (например, с именем ДополнительныеРеквизиты). Эта табличная часть должна содержать две основные колонки:
Свойство (Тип: ПланВидовХарактеристикСсылка или просто Строка);Значение (Тип: ЛюбаяСсылка, Строка, Число, Дата — обычно используется Составной тип данных).Посмотрим на пример работы с такой структурой. Когда нам нужно сохранить произвольное данное, мы просто добавляем строку в эту таблицу:
НоваяСтрока = Объект.ДополнительныеРеквизиты.Добавить();
НоваяСтрока.Свойство = "Цвет";
НоваяСтрока.Значение = "Красный";
Этот метод хорош тем, что данные хранятся внутри самого объекта, их легко переносить и копировать вместе со справочником. Однако поиск по таким реквизитам в больших базах данных может работать медленнее, чем по индексированным полям.
Если вы работаете в современной типовой конфигурации (УТ 11, ERP, БП 3.0), то изобретать велосипед не нужно. В составе Библиотеки стандартных подсистем (БСП) уже есть мощный механизм дополнительных реквизитов. Разберем, как его использовать:
Администратор системы в пользовательском режиме заходит в раздел «Администрирование» -> «Общие настройки» -> «Дополнительные реквизиты и сведения». Там можно выбрать нужный справочник (например, «Номенклатура») и добавить любое количество полей.
Как это устроено внутри: БСП использует скрытую табличную часть объекта или специальный регистр сведений. При этом программный код БСП автоматически выводит эти поля на форму элемента, проверяет заполнение и обеспечивает их отображение в списках. Это самый профессиональный способ решения задачи в экосистеме 1С.
Иногда возникает задача хранить огромное количество специфических параметров, по которым никогда не будет вестись поиск или фильтрация (например, технические параметры детали, полученные по API). В этом случае целесообразно использовать одно текстовое поле неограниченной длины.
Разберем алгоритм работы:
ДанныеПараметров с типом Строка (неограниченная).Посмотрим на пример кода для упаковки данных:
ПараметрыОбъекта = Новый Структура;
ПараметрыОбъекта.Вставить("ВесБрутто", 10.5);
ПараметрыОбъекта.Вставить("ТипУпаковки", "Коробка");
ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
ЗаписатьJSON(ЗаписьJSON, ПараметрыОбъекта);
Объект.ДанныеПараметров = ЗаписьJSON.Закрыть();
Этот метод максимально экономит место в базе данных и не требует изменения структуры таблиц, но делает невозможным прямой запрос к этим данным через язык запросов 1С.
Существует мнение, что можно программно генерировать расширения конфигурации (файлы .cfe) и подключать их динамически для добавления реальных реквизитов. Рассмотрим, почему это считается плохой практикой:
dbnames или падение сеансов пользователей.Подведем итог: если вам нужна визуальная динамика на форме — используйте ИзменитьРеквизиты(). Если нужна гибкость для пользователя — используйте Планы видов характеристик или готовые механизмы БСП. Это обеспечит стабильность системы и удобство дальнейшей поддержки программного продукта.