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