Программное добавление реквизитов в 1С: Предприятие

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

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

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

Архитектура дополнительных реквизитов через Планы видов характеристик

Механизм Планов видов характеристик (ПВХ) является штатным инструментом платформы 1С для реализации динамических свойств. Суть метода заключается в создании отдельного плана, который связывается с основным объектом метаданных. Значения дополнительных реквизитов хранятся не в основной таблице объекта, а в специальной таблице регистра сведений, что обеспечивает высокую гибкость.

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

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

⚠️ Внимание: При использовании ПВХ помните, что данные хранятся в разрезе видов характеристик. Ошибка в коде при обращении к несуществующему виду характеристики приведет к пустому значению, а не к ошибке выполнения, что может скрыть логические баги.

Алгоритм программного создания и записи значений

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

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

// Пример получения плана и записи значения
План = ПланыВидовХарактеристик.ДополнительныеРеквизиты;
Владелец = Справочники.Номенклатура.НайтиПоНаименованию("Товар А");

// Получаем или создаем вид характеристики
ВидХарактеристики = План.НайтиПоНаименованию("Цвет");
Если ВидХарактеристики = Неопределено Тогда
НовыйВид = План.СоздатьВидХарактеристики();
НовыйВид.Наименование = "Цвет";
НовыйВид.ТипЗначения = Тип("Строка(50)");
НовыйВид.Записать();
ВидХарактеристики = НовыйВид.Ссылка;
КонецЕсли;

// Запись значения
Регистр = РегистрыСведений.ЗначенияДополнительныхРеквизитов;
Запись = Регистр.СоздатьЗапись();
Запись.ВидХарактеристики = ВидХарактеристики;
Запись.Свойство = "ОсновнойЦвет"; // Или динамическое имя
Запись.Значение = "Красный";
Запись.Владелец = Владелец;
Запись.Записать();

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

Использование расширений конфигурации для добавления полей

В современных версиях платформы 1С (начиная с 8.3.10) мощным инструментом стало использование расширений конфигурации. Этот метод позволяет добавлять новые реквизиты непосредственно в объекты метаданных без изменения основной конфигурации. В отличие от ПВХ, данные в этом случае хранятся в основной таблице объекта (в отдельных колонках), что обеспечивает максимальную производительность при выборке.

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

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

Ограничения расширений

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

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

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

Сравнение производительности и методов хранения

Выбор между планом видов характеристик и прямым добавлением реквизитов (через расширение или изменение конфигурации) часто упирается в вопрос производительности. Прямые реквизиты хранятся в одной таблице с основными данными объекта. Это означает, что при выборке списка номенклатуры с дополнительным полем "Артикул поставщика" СУБД выполнит один простой запрос.

В случае с ПВХ данные лежат в отдельной таблице регистра сведений. Для получения значения системе необходимо выполнить JOIN (соединение) между основной таблицей и таблицей регистра. При больших объемах данных (миллионы записей) и отсутствии правильных индексов это может привести к заметному замедлению работы списков и отчетов.

Ниже приведена сравнительная таблица характеристик обоих методов, которая поможет вам принять взвешенное решение при проектировании архитектуры вашей системы 1С.

Критерий	План видов характеристик (ПВХ)	Прямой реквизит (Расширение/Конфигурация)	Дополнительные свойства (Стандартный механизм)
Хранение данных	Отдельная таблица регистра сведений	Основная таблица объекта	Отдельные таблицы для каждого типа
Гибкость добавления	Высокая (программно в рантайме)	Низкая (требуется режим Конфигуратора)	Средняя (через интерфейс пользователя)
Производительность выборки	Средняя (требует соединения таблиц)	Высокая (данные в одной строке)	Низкая (множественные соединения)
Типизация данных	Гибкая (настраивается для вида)	Строгая (на уровне метаданных)	Ограниченная стандартными типами

Обработка событий и валидация данных

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

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

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

Не забывайте о правах доступа. Если вы создаете реквизиты программно, убедитесь, что у ролей пользователей есть права на чтение и запись соответствующих регистров сведений или полей расширений. Часто разработчики забывают настроить права для новых объектов, что приводит к ошибкам "Доступ запрещен" у рядовых пользователей.

Типичные ошибки и лучшие практики оптимизации

Одна из самых частых ошибок при работе с дополнительными реквизитами — отсутствие индексации. В таблицах регистра сведений ПВХ по умолчанию индексируются только служебные поля. Если вы планируете отбирать объекты по значению дополнительного реквизита (например, "Найти все товары с цветом Красный"), вы обязаны создать индекс по соответствующему измерению или ресурсу регистра.

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

⚠️ Внимание: Избегайте хранения больших объемов текста или бинарных данных (картинок, файлов) в дополнительных реквизитах ПВХ. Для этого лучше использовать отдельные документы или файлы, а в реквизите хранить только ссылку на них.

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

Секрет оптимизации

При выборке данных через запрос к ПВХ, всегда указывайте конкретные виды характеристик в условии WHERE. Запрос без фильтра по виду характеристики заставит СУБД сканировать всю таблицу регистра, что убьет производительность.

Часто задаваемые вопросы (FAQ)

Можно ли добавить реквизит программно без прав администратора?

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

Как удалить программно созданный реквизит (вид характеристики)?

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

Влияет ли большое количество дополнительных реквизитов на скорость проведения документов?

Да, влияет. Каждый дополнительный реквизит, записываемый в регистр сведений, требует отдельной транзакции или вставки в пакет. Если у объекта сотни динамических свойств, время проведения документа может увеличиться. В таких случаях стоит пересмотреть архитектуру и сгруппировать данные.

Можно ли использовать ПВХ для документов, а не только для справочников?

Да, планы видов характеристик можно привязывать к любым объектам метаданных, поддерживающим ссылки, включая документы, задачи бизнес-процессов и даже перечисления. Механизм работы при этом остается идентичным.