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

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

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

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

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

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

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

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

⚠️ Внимание: Структура хранения дополнительных реквизитов может различаться в зависимости от режима совместимости конфигурации и версии платформы 1С. В старых версиях (до 8.3.10) механизм работы с ДРиС имел ряд ограничений по типам данных и производительности, которые были устранены в современных релизах.

Базовый синтаксис записи значения

Самый распространенный и интуитивно понятный способ изменения дополнительного реквизита — это прямое обращение к свойству объекта по имени. Этот метод работает аналогично обращению к обычным полям объекта. Если в справочнике «Контрагенты» создан дополнительный реквизит с именем ИННДополнительный, то присвоение значения выглядит тривиально.

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

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

// Получаем объект для записи
Объект = СсылкаНаЭлемент.ПолучитьОбъект();

// Изменяем дополнительный реквизит
Объект.ДополнительныеРеквизиты.ИННДополнительный = "7701234567";

// Записываем изменения
Объект.Записать();

В данном примере ключевым моментом является использование метода ПолучитьОбъект(). Работа непосредственно со ссылкой не позволяет изменять свойства, включая дополнительные реквизиты. Только после получения полноценного объекта в память мы можем модифицировать его содержимое. Также стоит отметить, что имя реквизита в коде (ИННДополнительный) должно соответствовать имени свойства в метаданных, а не обязательно синониму, видимому пользователю в форме.

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

Динамическое обращение через коллекцию свойств

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

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

ИмяРеквизита = "СтатусПроверки";
НовоеЗначение = "Выполнено";

Объект = Документы.ЗаказКлиента.ПолучитьОбъект(СсылкаНаДокумент);

// Динамическое присваивание
Попытка
Объект.ДополнительныеРеквизиты[ИмяРеквизита] = НовоеЗначение;
Исключение
Сообщить("Ошибка записи: " + ОписаниеОшибки());
КонецПопытки;

Объект.Записать();

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

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

Проверка существования реквизита перед записью

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

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

Метод проверки	Возвращаемое значение	Рекомендуемое использование
Свойство(Объект, "Имя")	Булево (Истина/Ложь)	Быстрая проверка существования
Объект.Свойство("Имя", Значение)	Булево + заполнение переменной	Проверка и чтение в одной операции
Попытка..Исключение	Перехват ошибки	Универсальный метод при динамических именах

Пример реализации проверки с использованием метода объекта:

Объект = Справочники.Номенклатура.ПолучитьОбъект(Ссылка);
ЗначениеРеквизита = Неопределено;

Если Объект.ДополнительныеРеквизиты.Свойство("АртикулПоставщика", ЗначениеРеквизита) Тогда
// Реквизит существует, можно читать или перезаписывать
Объект.ДополнительныеРеквизиты.АртикулПоставщика = "NEW-123";
Объект.Записать();
Иначе
// Реквизит не найден, логика обработки отсутствия
Сообщить("Реквизит АртикулПоставщика не найден в данной конфигурации");
КонецЕсли;

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

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

Работа с дополнительными сведениями (табличная часть)

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

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

Ниже приведен пример добавления нового сведения с типом «Дата» и заполнением значения:

Объект = Документы.ПоступлениеТоваров.ПолучитьОбъект(Ссылка);

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

Объект.Записать();

Критически важным моментом здесь является поле Свойство. В отличие от простых реквизитов, в дополнительных сведениях сначала нужно найти метаданные самого свойства (его определение в справочнике свойств объектов), и только затем создавать строку значений. Прямое присваивание имени строкой здесь не сработает, так как требуется ссылка на объект-описатель свойства.

Особенности удаления сведений

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

Оптимизация и массовое обновление

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

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

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

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

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

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

Почему после записи кодом значение не видно в форме объекта?

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

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

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

Влияет ли изменение ДРр на проведение документов?

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