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