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

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

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

Архитектура дополнительных реквизитов в платформе 1С

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

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

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

⚠️ Внимание: Структура хранения дополнительных реквизитов может отличаться в разных типовых конфигурациях (Бухгалтерия, УТ, ЗУП) из-за использования различных механизмов расширения (Расширения конфигурации vs БСП). Всегда проверяйте актуальность механизмов в документации к вашей версии платформы.

Прямой доступ к свойствам объекта справочника

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

Однако использование этого подхода в цикле по большой выборке данных является грубой ошибкой с точки зрения производительности. Каждый вызов метода Записать() инициирует отдельную транзакцию и блокировку записи в базе данных SQL. Если вам нужно обработать 10 000 элементов, система выполнит 10 000 отдельных запросов на запись, что гарантированно приведет к зависанию интерфейса для других пользователей.

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

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

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

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

Массовая обработка через Таблицу Значений

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

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

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

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

ТЗ = Новый ТаблицаЗначений;
ТЗ.Колонки.Добавить("Ссылка", ТипОписанияТипов("СправочникСсылка.Номенклатура"));
ТЗ.Колонки.Добавить("ВесБрутто", ТипОписанияТипов("Число"));

// Заполнение таблицы данными
Для Каждого Элемент Из Выборка Цикл
НоваяСтрока = ТЗ.Добавить();
НоваяСтрока.Ссылка = Элемент.Ссылка;
НоваяСтрока.ВесБрутто = Элемент.Масса * 1.1;
КонецЦикла;

// Пакетная запись
Справочники.Номенклатура.ЗаписатьТаблицуЗначений(ТЗ);

Особенности работы с Динамическим списком

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

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

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

⚠️ Внимание: При работе с динамическими списками в управляемых формах помните о контексте выполнения. Изменение данных в таблице формы не всегда автоматически триггерит запись в базу данных без явного вызова методов сохранения или установки флага модифицированности.

Использование запросов для анализа и выборки

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

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

Однако стоит учитывать, что использование дополнительных реквизитов в условиях отбора (ГДЕ) или соединениях (ЛЕВОЕ СОЕДИНЕНИЕ) может негативно сказаться на производительности запроса, если по этим полям не построены индексы или если объем данных в служебных таблицах велик. Оптимизация таких запросов требует анализа плана выполнения.

Метод доступа	Производительность	Сложность реализации	Рекомендуемое использование
Объект.Записать()	Низкая	Низкая	Единичное редактирование
ЗаписатьТаблицуЗначений	Высокая	Средняя	Массовая обработка, перенос данных
Через форму (GUI)	Низкая	Низкая	Ручной ввод пользователем
COM-соединение	Очень низкая	Высокая	Внешние системы, устаревшие интеграции

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

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

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

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

Что делать при ошибке типа данных?

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

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

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

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

Почему дополнительный реквизит не виден в запросе?

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

Как очистить значение дополнительного реквизита?

Для очистки достаточно присвоить реквизиту значение Неопределено (для ссылочных типов) или пустую строку/ноль (для примитивных типов), а затем записать объект. В таблице значений просто укажите соответствующее пустое значение.

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

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