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