При разработке отчетов на системе компоновки данных (СКД) часто возникает задача упростить интерфейс для пользователя. Стандартный выбор периода с начальной и конечной датой может быть избыточным, если отчет всегда строится строго за один календарный год. В этой ситуации гораздо удобнее предоставить пользователю возможность просто ввести число (например, 2024), а все необходимые границы дат система должна рассчитать автоматически.
В данной статье мы разберем несколько способов реализации этой задачи: от простого условия в запросе до продвинутых настроек выражений СКД, которые позволяют сохранить гибкость отчета без написания лишнего программного кода.
Проанализируем самый очевидный вариант, который часто первым приходит в голову разработчикам. Вместо того чтобы использовать параметры &НачалоПериода и &КонецПериода для ограничения выборки данных, мы можем использовать встроенную функцию языка запросов ГОД().
Рассмотрим пример реализации такого запроса:
ВЫБРАТЬ
ПродажиОбороты.Номенклатура,
ПродажиОбороты.КоличествоОборот,
ПродажиОбороты.СуммаВыручкиОборот
ИЗ
РегистрНакопления.Продажи.Обороты(,, Авто, ) КАК ПродажиОбороты
ГДЕ
ГОД(ПродажиОбороты.Период) = &ВыбранныйГод
В этом случае в списке параметров СКД появится параметр &ВыбранныйГод с типом Число. Важный нюанс: при использовании такого подхода на больших объемах данных производительность может снизиться, так как использование функций над полями в условии ГДЕ часто блокирует использование индексов. Поэтому для крупных баз данных лучше использовать второй способ.
Разберем более профессиональный и оптимальный с точки зрения производительности метод. Мы оставим в запросе стандартные параметры &НачалоПериода и &КонецПериода, но скроем их от пользователя, а расчет их значений привяжем к нашему числовому параметру &ВыбранныйГод.
Выполним следующие шаги в конструкторе схемы компоновки данных:
ВыбранныйГод, тип — Число (длина 4, точность 0).НачалоПериода и КонецПериода установим галочку Ограничение доступности, чтобы пользователь не видел их в настройках.НачалоПериода пропишем формулу:
ДАТАВРЕМЯ(&ВыбранныйГод, 1, 1, 0, 0, 0)
КонецПериода пропишем формулу:
КонецПериода(ДАТАВРЕМЯ(&ВыбранныйГод, 1, 1, 0, 0, 0), "ГОД")
Таким образом, пользователь вводит только число, а СКД автоматически подставляет правильные границы дат в виртуальные таблицы запроса, обеспечивая высокую скорость работы отчета.
Выясним, как сделать работу с отчетом еще приятнее. По умолчанию числовые параметры могут отображаться с разделителем групп разрядов (например, "2 024"). Для года это выглядит неестественно. Также удобно, чтобы при открытии отчета в поле уже стоял текущий год.
Проанализируем настройки параметра ВыбранныйГод на той же закладке Параметры:
ВыбранныйГод напишем: Год(ТекущаяДата()). При этом убедитесь, что галочка "Ограничение доступности" для него снята.Иногда пользователю проще выбрать год из списка, чем вводить его вручную. В СКД это реализуется без программирования. В свойствах параметра ВыбранныйГод найдем колонку Доступные значения. Здесь можно заранее перечислить список лет (например, с 2020 по 2030). В интерфейсе это превратится в удобный выпадающий список.
Если вы решили создать собственную форму для отчета, чтобы добавить специфические элементы управления (например, кнопки регулировки "вверх-вниз" для года), вы можете столкнуться с ошибкой "Не передан служебный параметр НастройкиОтчета" при нажатии на кнопку "Настройки".
Это происходит из-за того, что в современных конфигурациях на базе БСП (Библиотека стандартных подсистем) формы отчетов должны быть интегрированы в общую подсистему вариантов отчетов. Чтобы решить эту проблему, выполните следующие действия в модуле формы:
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Подключаем стандартный механизм вариантов отчетов БСП
ВариантыОтчетов.ПриСозданииНаСервере(ЭтаФорма, Параметры);
КонецПроцедуры
Также не забудьте проверить, что в свойствах самого отчета в конфигураторе ваша новая форма назначена Основной формой отчета. Без этого вызова стандартные кнопки командной панели (Настройки, Печать, Сохранить) могут работать некорректно или выдавать ошибки.
Подводя итог, отметим, что наиболее гибким и "чистым" способом является Способ №2. Он позволяет избежать написания кода в модулях, сохраняет высокую производительность запросов и обеспечивает максимально простой интерфейс для конечного пользователя.