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

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

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

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

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

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

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

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

Инициализация объекта управления дополнительными сведениями

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

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

ПВХ = ПланыВидовХарактеристик.ДополнительныеСведения;
МенеджерДопСведений = ПланыВидовХарактеристик.ДополнительныеСведения.СоздатьМенеджерДополнительныхСведений();

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

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

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

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

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

• 📝 Идентификатор — уникальное имя реквизита, используемое в коде (например, "ЦветУпаковки").
• 🏷️ Синоним — понятное пользователю название, отображаемое в формах и отчетах.
• 📐 Тип данных — определение формата хранимой информации (строка, число, дата, ссылка).
• ⚙️ Настройки — параметры вроде длины строки, допустимых значений или признака обязательности.

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

Настройка свойств и типизация данных

Особое внимание следует уделить типизации. В 1С тип дополнительного реквизита задается через объект ОписаниеТипов. Это позволяет не только указать базовый тип, но и настроить ограничения. Например, для строки можно задать минимальную и максимальную длину, а для числа — точность и допустимый диапазон значений.

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

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

Параметр	Тип значения	Описание	Пример
Имя	Строка	Технический код реквизита	АртикулПоставщика
Синоним	Строка	Название для интерфейса	Артикул поставщика
Тип	ОписаниеТипов	Формат данных	Строка(50)
Видимость	Булево	Отображать ли в форме	Истина
Индексирование	Булево	Ускорение поиска	Ложь

⚠️ Внимание: Изменение типа существующего реквизита (например, со Строки на Число) программно возможно, но может привести к потере данных, если старые значения не соответствуют новому типу. Всегда делайте резервное копирование перед такими операциями.

Запись и чтение значений в динамические поля

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

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

Пример кода для записи значения в созданный ранее реквизит:

ОбъектСсылка = Справочники.Номенклатура.НайтиПоКоду("00001");
ОбъектСсылка.ДополнительныеСвойства.ЦветУпаковки = "Красный";
ОбъектСсылка.Записать();

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

Оптимизация массовых операций

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

Обработка ошибок и удаление реквизитов

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

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

Частой проблемой является кэширование метаданных на клиенте. После создания или удаления реквизита пользователь может не увидеть изменений в форме до тех пор, пока не перезапустит приложение или не обновит форму. Для решения этой проблемы можно использовать метод ОбновитьНаКлиенте, если архитектура приложения это позволяет.

⚠️ Внимание: Удаление реквизита, который используется в активных отчетах, обработках или внешних подключениях, приведет к ошибкам выполнения в этих местах. Проведите аудит использования перед удалением.

Практические примеры использования в бизнес-задачах

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

Обработка проверяет наличие реквизита «СтранаПроисхождения» в плане видов характеристик для справочника «Номенклатура». Если его нет, она создает его типом «Строка(50)». Затем скрипт проходит по всем элементам справочника и заполняет поле значением по умолчанию или данными из внешнего файла импорта.

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

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

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

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

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

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

Как найти все объекты, где используется конкретный дополнительный реквизит?

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

Сохраняются ли дополнительные реквизиты при обновлении типовой конфигурации?

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

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

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