Методы ограничения типа документа в запросах 1С

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

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

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

Использование оператора ВЫБОР для явной фильтрации

Самый универсальный и понятный способ отфильтровать документы определенного типа — использование оператора ВЫБОР в условии ГДЕ. Этот подход позволяет явно перечислить все интересующие вас типы документов. Синтаксис требует указания полного имени типа, включая пространство имен конфигурации.

При формировании условия Вы можете использовать конструкцию ТИПЗНАЧЕНИЯ(ДокументСсылка.ИмяДокумента). Это выражение возвращает описание типа, которое можно сравнить с типом значения в выборке.

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

Использование ВЫБОР делает код читаемым, но при большом количестве типов документов условие может стать громоздким. Однако для производительности это часто лучший вариант, так как оптимизатор запросов 1С умеет эффективно использовать индексы по типу ссылки.

• 📌 Оператор ВЫБОР позволяет комбинировать условия через ИЛИ для нескольких типов документов в одном запросе.
• 📌 Функция ТИПЗНАЧЕНИЯ является стандартным средством получения описания типа объекта метаданных.
• 📌 Явное перечисление типов помогает избежать случайной выборки документов-заглушек или служебных записей.

⚠️ Внимание: При использовании оператора ВЫБОР убедитесь, что имена документов указаны точно так, как они зарегистрированы в конфигураторе. Опечатка в имени типа приведет к ошибке компиляции запроса.

Работа с псевдополем Тип в виртуальных таблицах

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

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

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

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

Существует нюанс при работе с таблицей значений в коде. Если вы получаете данные запроса в таблицу значений, то тип колонки «Документ» будет определен как составной. Фильтрация такой таблицы значений в коде требует использования метода Отбор с указанием значения типа, аналогично языку запросов.

Оптимизация запросов и использование индексов

Производительность запроса напрямую зависит от того, как сформулированы условия отбора. Поле, хранящее ссылку на документ, обычно индексируется вместе с полем типа ссылки. Это означает, что условие ГДЕ Документ.Вид = ТИПЗНАЧЕНИЯ(..) будет выполняться очень быстро, так как СУБД использует индекс для поиска.

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

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

Метод фильтрации	Производительность	Читаемость кода	Рекомендация
Оператор ВЫБОР	Высокая	Средняя	Основной метод для явных списков
Виртуальные поля	Средняя	Высокая	Для стандартных отчетов и регистров
Фильтрация в коде	Низкая	Низкая	Только для малых выборок

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

Обработка составных типов в условиях соединения

Частая задача — соединить таблицу документов с регистром движений. При этом в регистре в измерении «Документ» могут храниться ссылки на разные виды. Если вы делаете ВНУТРЕННЕЕ СОЕДИНЕНИЕ, условие соединения должно учитывать тип.

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

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

• 🔍 Условие соединения с проверкой типа защищает от логических ошибок при объединении разнородных данных.
• 🔍 Использование ВНУТРЕННЕЕ СОЕДИНЕНИЕ автоматически отбрасывает строки, для которых нет пары, что удобно для фильтрации.
• 🔍 Проверка типа в соединении часто эффективнее, чем последующая фильтрация результата через ГДЕ.

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

Динамическое формирование условий с параметрами

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

Вы можете создать параметр запроса, например, СписокТипов, который будет иметь тип СписокЗначений или Массив. В тексте запроса используется конструкция Документ.Вид В (&СписокТипов). Это позволяет динамически подставлять нужные типы.

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

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

Пример формирования параметра в коде: вы создаете объект СписокЗначений, добавляете туда ТипЗнч(ДокументСсылка.РеализацияТоваровУслуг) и передаете этот список в структуру параметров запроса. Механизм 1С сам корректно подставит значения в условие В.

Типичные ошибки и способы их устранения

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

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

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

Что делать, если запрос возвращает лишние документы?

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

Для отладки таких запросов удобно использовать консоль запросов. Там можно визуально увидеть структуру результирующей таблицы и убедиться, что в колонке «Документ» присутствуют только ожидаемые виды. Анализ текста сгенерированного SQL-кода (через технологический журнал) также помогает понять, как именно СУБД выполняет фильтрацию.

Специфика работы с различными версиями платформы

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

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

При переходе с файловых баз на SQL-серверы (PostgreSQL, MS SQL) поведение индексов по составным типам может отличаться. На SQL-серверах явное указание типа в условии ГДЕ дает более заметный прирост скорости, чем на файловом варианте, благодаря особенностям хранения данных в таблицах СУБД.

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

Для этого необходимо добавить в условие ГДЕ проверку на проведение, обычно это поле Проведение или использование виртуальной таблицы Документ.Последовательности. Комбинируйте отбор по типу: ГДЕ ТИПЗНАЧЕНИЯ(ДокументСсылка.Реализация) И Проведение = ИСТИНА.

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

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

Что быстрее: фильтр в запросе или отбор в таблице значений?

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

Как обработать ситуацию, если тип документа неизвестен заранее?

Используйте параметр запроса с типом Неопределено или передавайте NULL. В тексте запроса используйте конструкцию ЕСТЬNULL(&ПараметрТипа, ТИПЗНАЧЕНИЯ(..)) или логику ВЫБОР, чтобы подставить нужный тип динамически в зависимости от условия.

Влияет ли ограничение типа документа на блокировки в базе?

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