При работе с Системой компоновки данных (СКД) программисты часто сталкиваются с необходимостью ручного управления полями отбора и выбора. Использование конструкции в фигурных скобках {} — это мощный инструмент, который позволяет сделать запрос динамическим. Однако ошибки в синтаксисе или непонимание того, как СКД обрабатывает пустые значения и NULL, могут привести к некорректной работе отчетов. В этой статье мы разберем, как заставить «капризные» отборы работать правильно, проанализируем особенности синтаксиса и научимся обрабатывать сложные случаи с перечислениями.
Конструкции в фигурных скобках — это расширение языка запросов 1С, предназначенное специально для системы компоновки данных. Они указывают СКД, какие поля могут быть доступны пользователю для настройки, даже если они не участвуют в основном тексте запроса. Рассмотрим основные секции:
{ВЫБРАТЬ Поле1, Поле2.*}. Позволяет пользователю выбирать дополнительные поля в настройках отчета (вкладка «Выбранные поля»).{ГДЕ Таблица.Поле КАК Псевдоним}. Позволяет накладывать произвольные условия в настройках (вкладка «Отбор»).Важный нюанс: Ошибка часто кроется в несоответствии имен. Если в основном запросе вы используете псевдоним для поля, например ЗаказКлиента.Статус КАК ЛогистическийСтатус, то и в фигурных скобках {ГДЕ ...} нужно либо обращаться к полному пути источника данных, либо явно назначать псевдоним через ключевое слово КАК. Проанализируем правильный пример написания:
{ГДЕ ТаблицаДляОпределенияДопСтатусов.ЗаказКлиента.*,
ТаблицаДляОпределенияДопСтатусов.ЛогСтатус КАК ЛогистическийСтатус}
Обратите внимание, что использование .* после имени поля позволяет СКД «раскрыть» все доступные реквизиты этого объекта для отбора, что очень удобно для конечного пользователя.
Одной из самых коварных проблем является работа условия «Не в списке», когда в данных встречаются пустые значения перечислений или NULL. Разберем ситуацию: пользователь хочет исключить определенные статусы заказов, но записи с незаполненным статусом (пустая ссылка или NULL) внезапно исчезают из отчета.
Это происходит из-за логики работы SQL. Любое сравнение с NULL (в том числе проверка на вхождение в список) дает результат «Ложь». Чтобы отбор работал корректно, нам необходимо гарантировать наличие конкретного значения. Посмотрим на пример использования функции ЕСТЬNULL в запросе:
ВЫБРАТЬ
Заказы.Ссылка КАК ЗаказКлиента,
ЕСТЬNULL(ДопСтатусы.ЛогСтатус, ЗНАЧЕНИЕ(Перечисление.СтатусыЗаказовЛогистические.ПустаяСсылка)) КАК ЛогистическийСтатус
ИЗ
Документ.ЗаказКлиента КАК Заказы
ЛЕВОЕ СОЕДИНЕНИЕ ВТ_ДопСтатусы КАК ДопСтатусы ПО Заказы.Ссылка = ДопСтатусы.ЗаказКлиента
{ГДЕ
Заказы.Ссылка.* КАК ЗаказКлиента,
(ЕСТЬNULL(ДопСтатусы.ЛогСтатус, ЗНАЧЕНИЕ(Перечисление.СтатусыЗаказовЛогистические.ПустаяСсылка))) КАК ЛогистическийСтатус}
Использование ЕСТЬNULL гарантирует, что даже если по заказу еще нет записи в таблице статусов, система увидит Пустую Ссылку перечисления, а не NULL. В этом случае условие «Не в списке» отработает предсказуемо.
Многие ошибки ручного ввода можно предотвратить, если использовать встроенный конструктор. Напомним, как это сделать:
{ГДЕ ...}.Рассмотрим преимущество этого метода: Конструктор автоматически подставит правильные пути к полям и поможет избежать опечаток в псевдонимах, на которые часто жалуются разработчики.
Если ваш отчет строится на базе виртуальных таблиц (например, ОстаткиИОбороты), использование общего блока {ГДЕ ...} в конце запроса может существенно замедлить работу. В этом случае СКД сначала получит все данные из регистра, а уже потом отфильтрует их.
Правильный подход заключается в выносе фигурных скобок непосредственно в параметры виртуальной таблицы. Проанализируем пример:
ВЫБРАТЬ
Обороты.Номенклатура,
Обороты.КоличествоОборот
ИЗ
РегистрНакопления.Продажи.Обороты( , , , {Номенклатура.* КАК Номенклатура}) КАК Обороты
В данном случае условие будет наложено еще на этапе формирования выборки на уровне сервера СУБД, что значительно повысит производительность при больших объемах данных.
Если «магия» фигурных скобок кажется вам слишком неявной, можно использовать механизм необязательных параметров. Это позволяет более жестко контролировать логику запроса. Рассмотрим пример реализации условия, которое срабатывает только при заполненном параметре:
ГДЕ
(&ИспользоватьОтборПоСтатусу = ЛОЖЬ
ИЛИ Таблица.ЛогСтатус В (&СписокСтатусов))
В настройках СКД для параметра СписокСтатусов можно включить возможность использования списка значений. Если пользователь не заполнит этот список, условие фактически будет игнорироваться, не ограничивая выборку.
При настройке отборов важно помнить, что в СКД тип поля должен быть определен однозначно. Если поле ЛогистическийСтатус имеет составной тип или тип не определен (например, в результате сложного вложенного запроса), отбор «В списке» может работать нестабильно.
Рекомендуется: На закладке «Поля» в наборе данных СКД всегда проверять колонку «Тип значения». Если там указано «Составной тип», лучше явно ограничить его нужным перечислением. Это поможет системе правильно подбирать редактор значений для пользователя и корректно формировать SQL-запрос.
Выясним причину, почему иногда кажется, что отбор «не работает». Часто это связано с Автозаполнением. Если в схеме включен флаг «Автозаполнение», СКД пытается сама добавить все доступные поля. Однако ручные вставки {ГДЕ ...} имеют приоритет. Если вы начали описывать условия вручную, вы должны описать все поля, по которым планируется фильтрация, иначе они могут пропасть из списка доступных полей компоновки.
Подводя итог, можно сказать, что работа с отборами в СКД требует внимательности к типам данных и точности в описании путей к полям. Использование ЕСТЬNULL для обработки пустых значений и перенос условий в параметры виртуальных таблиц — это те практики, которые отличают качественный отчет от медленного и нестабильного.