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