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

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

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

В этом материале мы детально разберем синтаксис языка запросов 1С для работы с ДР, рассмотрим специфику виртуальных таблиц и обсудим нюансы производительности при фильтрации по произвольным полям.

Механизм хранения данных в базе

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

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

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

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

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

Для того чтобы вытащить дополнительные реквизиты в запросе, необходимо использовать специальный синтаксис обращения к полям объекта. В секции ВЫБРАТЬ вы указываете имя объекта, а затем через точку — имя нужного дополнительного реквизита. Платформа распознает это обращение и автоматически сформирует левое соединение с соответствующей таблицей значений.

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

Рассмотрим пример запроса к справочнику Номенклатура. Нам нужно получить наименование и дополнительный реквизит "Цвет", который был создан пользователем:

ВЫБРАТЬ
Номенклатура.Ссылка,
Номенклатура.Наименование,
Номенклатура.ДополнительныеРеквизиты.Цвет КАК Цвет
ИЗ
Справочник.Номенклатура КАК Номенклатура

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

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

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

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

Пример выборки периодических сведений о поставщике (например, "Рейтинг надежности" на конкретную дату):

ВЫБРАТЬ
Поставщики.Ссылка,
ПоставщикиДопСведения.Значение КАК Рейтинг
ИЗ
Справочник.Поставщики КАК Поставщики
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ПоставщикиДопСведения.СрезПоследних(,
ПоставщикиДопСведения.Объект = Поставщики.Ссылка) КАК ПоставщикиДопСведения
ПО ИСТИНА

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

Тип данных	Таблица хранения	Особенности выборки
Доп. реквизиты	Таблица значений	Выбираются напрямую через точку
Доп. сведения (периодические)	Регистр сведений	Требуется указание периода или срез
Доп. сведения (непериодические)	Таблица значений	Аналогично доп. реквизитам
Характеристики номенклатуры	План видов характеристик	Требуют соединения с планом

Фильтрация и условия в WHERE

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

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

Пример отбора товаров только красного цвета:

ВЫБРАТЬ
Номенклатура.Ссылка
ИЗ
Справочник.Номенклатура КАК Номенклатура
ГДЕ
Номенклатура.ДополнительныеРеквизиты.Цвет = ЗНАЧЕНИЕ(Перечисление.Цвета.Красный)

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

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

Обработка результатов в коде 1С

После выполнения запроса результат попадает в объект ВыборкаИзРезультатаЗапроса. Работа с дополнительными реквизитами здесь имеет одну особенность: если для какого-то объекта дополнительный реквизит не заполнен, в выборке будет значение Неопределено (Null). Это поведение обусловлено использованием левого соединения, которое платформа подставляет автоматически.

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

Пример кода обработки на языке 1С:

Пока Выборка.Следующий() Цикл
Если Выборка.Цвет <> Неопределено Тогда
Сообщить("Товар " + Выборка.Наименование + " имеет цвет: " + Выборка.Цвет);
Иначе
Сообщить("Товар " + Выборка.Наименование + " без указанного цвета");
КонецЕсли;
КонецЦикла;

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

Частые ошибки и производительность

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

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

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

Как ускорить выборку по ДР?

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

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

FAQ: Вопросы и ответы

Можно ли использовать дополнительные реквизиты в условиях соединения (JOIN)?

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

Что делать, если запрос не видит новый дополнительный реквизит?

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

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

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

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

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