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