Почему параметр не появляется в запросе СКД и как правильно с ним работать?

При разработке отчетов на базе Системы компоновки данных (СКД) в 1С начинающие разработчики часто сталкиваются с неочевидным поведением параметров. Типичный сценарий: программист переходит на вкладку «Параметры» в схеме компоновки, нажимает кнопку «Добавить» (+), создает новый параметр (например, &ПометкаУдаления), а затем открывает конструктор запроса в наборе данных и обнаруживает, что созданного параметра там просто нет в списке доступных условий.

В этой статье мы подробно разберем, почему так происходит, как устроен механизм связывания параметров в СКД, и изучим лучшие практики работы с ними на конкретных примерах.

Главная причина: Как работает направление связей в СКД

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

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

Посмотрим на пример запроса, аналогичный тому, что использовался в обсуждении на форуме:

ВЫБРАТЬ
    ЗаказПокупателя.Ссылка КАК Ссылка,
    ЗаказПокупателя.Проведен КАК Проведен,
    ЗаказПокупателя.Ответственный КАК Ответственный
ИЗ
    Документ.ЗаказПокупателя КАК ЗаказПокупателя
ГДЕ
    ЗаказПокупателя.Дата МЕЖДУ &НачПериода И &КонПериода
    И ЗаказПокупателя.ПометкаУдаления = &ПараметрПометки

Проанализируем эту ситуацию. В данном запросе мы явно объявили три параметра: &НачПериода, &КонПериода и &ПараметрПометки. Как только мы закроем конструктор запроса (или сохраним текст), СКД автоматически перенесет их на вкладку «Параметры». При этом они станут доступны для настройки пользователем.

Разбираемся с механизмом «Автозаполнение»

Почему параметры, созданные автоматически, заблокированы для изменения имени на вкладке «Параметры»? За это поведение отвечает флаг «Автозаполнение», который находится в настройках набора данных (рядом с полем ввода текста запроса).

Рассмотрим подробнее два режима его работы:

1. Автозаполнение включено (по умолчанию): СКД полностью берет управление параметрами и доступными полями на себя. Она автоматически считывает все параметры из запроса и жестко привязывает их к схеме. Вы не можете переименовать такой параметр на вкладке «Параметры», так как его имя продиктовано текстом запроса. Если вам нужно изменить имя, сначала измените его в самом запросе (например, замените &КонПериода на &КонецПериода), и СКД обновит вкладку параметров сама.
2. Автозаполнение выключено: В этом режиме вы получаете полную свободу действий. Однако вам придется вручную описывать все доступные поля выбора, группировки и параметры на соответствующих вкладках. Этот режим используется опытными разработчиками для создания сложных, тонко настроенных отчетов с нетипичной структурой.

Зачем нужна кнопка «Добавить» (+) на вкладке параметров СКД?

Если параметры автоматически переносятся из запроса, логично спросить: зачем вообще нужна кнопка добавления на вкладке параметров? Разберем основные сценарии, когда ручное создание параметров просто необходимо:

• Использование в вычисляемых полях: Если вам нужно выполнить расчет в вычисляемом поле (например, умножить сумму на коэффициент, задаваемый пользователем), вы можете создать ручной параметр &Коэффициент и использовать его в формуле на вкладке «Вычисляемые поля». В самом запросе этот параметр фигурировать не будет.
• Связи между наборами данных: При объединении нескольких наборов данных (например, «Набор данных - запрос» и «Набор данных - объект») ручные параметры могут служить связующим звеном для передачи данных из одного набора в другой.
• Создание параметров-прослоек (например, для настройки периодов): Это один из самых частых и полезных кейсов, который мы подробно рассмотрим ниже.

Настройка периодов: решаем проблему «границы дня» и упрощаем интерфейс

В запросе из примера присутствуют параметры начала и окончания периода. При работе с ними разработчики часто совершают две критические ошибки.

Проблема 1: Граница дня

Если пользователь выбирает дату окончания периода (например, 31.12.2023), то по умолчанию время в параметре установится в 00:00:00. В результате все документы, проведенные в течение дня 31 декабря, не попадут в отчет. Нам нужно привести дату к концу дня.

Решать это в тексте запроса через функции работы с датами не совсем удобно. Правильный подход в СКД — использовать колонку «Выражение» на вкладке «Параметры».

Для параметра &КонПериода в колонке «Выражение» напишем следующую функцию:

КонецПериода(&КонПериода, "ДЕНЬ")

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

Проблема 2: Неудобный выбор двух дат отдельно

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

Разберем по шагам, как это настроить:

1. Перейдем на вкладку «Параметры» нашей схемы компоновки.
2. Нажмем кнопку «Добавить» (+) и создадим новый параметр с именем ПериодОтчета.
3. В колонке «Тип» укажем для него тип данных СтандартныйПериод.
4. Для автоматически созданных параметров запроса &НачПериода и &КонПериода в колонке «Выражение» пропишем формулы связи с нашим новым параметром:
   • Для &НачПериода пишем: &ПериодОтчета.ДатаНачала
   • Для &КонПериода пишем: КонецПериода(&ПериодОтчета.ДатаОкончания, "ДЕНЬ")
5. Чтобы пользователь не путался и не видел три параметра вместо одного, установим флаг «Ограничение доступности» для параметров &НачПериода и &КонПериода. Это скроет их из настроек отчета на форме, оставив доступным только удобный ПериодОтчета.

Использование констант вместо параметров (работа над ошибками)

Посмотрим еще раз на запрос из обсуждения на форуме. Разработчик хотел добавить в условие параметр &Ложь для проверки пометки удаления:

И ПлатежноеПоручениеВходящееРасшифровкаПлатежа.Ссылка.ПометкаУдаления = &Ложь

Это классический пример неоптимального проектирования. В платформе 1С создание параметров для передачи булевых значений (ИСТИНА / ЛОЖЬ) считается плохим тоном и ошибкой проектирования. Язык запросов 1С прекрасно понимает булевы литералы напрямую.

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

// Вариант 1 (наиболее лаконичный и правильный)
И НЕ ПлатежноеПоручениеВходящееРасшифровкаПлатежа.Ссылка.ПометкаУдаления

// Вариант 2 (более наглядный для новичков)
И ПлатежноеПоручениеВходящееРасшифровкаПлатежа.Ссылка.ПометкаУдаления = ЛОЖЬ

Используйте этот подход, чтобы не плодить лишние сущности на вкладке параметров СКД.

Автоматические параметры виртуальных таблиц

Стоит упомянуть еще одну особенность СКД, которая часто пугает новичков. Если в вашем запросе используются виртуальные таблицы (например, РегистрНакопления.Продажи.Обороты), то даже при отсутствии в тексте запроса каких-либо параметров, на вкладке «Параметры» схемы автоматически появятся &НачалоПериода и &КонецПериода.

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