← На главную

При обновлении платформы «1С:Предприятие» до версии 8.3.14 и выше (а также при отключении режима совместимости в конфигурации) разработчики часто сталкиваются с неожиданным поведением старых, проверенных временем отчетов на базе Системы компоновки данных (СКД). Отчеты, которые годами работали корректно, вдруг начинают выводить пустые значения, нулевые показатели или NULL в ресурсах, хотя сами группировки и аналитика в структуре выводятся правильно. Выясним причину этой проблемы, проанализируем поведение новой настройки СКД и разберем по шагам, как вернуть отчетам работоспособность.

За что отвечает флаг «Использовать группировки запроса если возможно»?

Начиная с версии платформы 8.3.14, в конструкторе схемы компоновки данных (на вкладке «Наборы данных», рядом с флагом «Автозаполнение») появилось новое свойство — «Использовать группировки запроса если возможно». По умолчанию, как только режим совместимости конфигурации переводится в состояние «Не использовать», эта опция автоматически активируется для всех наборов данных типа «Запрос».

Рассмотрим подробнее, какую задачу решает эта настройка с точки зрения платформы 1С:

1. Оптимизация на стороне СУБД: Если в настройках отчета (в структуре компоновки) выводятся только группировочные поля и агрегированные ресурсы (то есть в структуре отсутствуют «Детальные записи»), СКД пытается перенести операцию свертки данных непосредственно на SQL-сервер.
2. Формирование SQL-запроса: При включенной опции платформа автоматически добавляет в результирующий SQL-запрос секцию GROUP BY и соответствующие агрегатные функции (такие как SUM, MAX, COUNT).
3. Экономия ресурсов: Вместо того чтобы передавать на сервер приложений 1С миллионы детальных строк и группировать их силами процессора компоновки, СУБД возвращает уже свернутый, компактный результат. Это значительно снижает нагрузку на сеть и оперативную память сервера «1С:Предприятие» при построении тяжелых аналитических отчетов.

Если же этот флаг снят, СКД работает по классической схеме: выбирает из базы данных весь детальный массив записей, а затем процессор вывода СКД самостоятельно группирует их и рассчитывает итоги.

Почему обнуляются числовые показатели при объединении наборов?

Проанализируем ситуацию, описанную автором темы на форуме. Имеется отчет, базирующийся на объединении или соединении нескольких наборов данных (например, трех отдельных запросов). После активации режима совместимости «Не использовать» показатели (ресурсы) из второго и третьего наборов данных внезапно превращаются в нули или пустые значения.

Выясним причину этого сбоя. Когда мы связываем или объединяем наборы данных, СКД должна сопоставить строки из разных выборок по ключевым полям (полям связи). Включение настройки «Использовать группировки запроса если возможно» ломает эту логику по следующей схеме:

1. Преждевременная свертка: СКД пытается оптимизировать каждый набор данных-запрос локально и независимо друг от друга. Обнаружив включенный флаг в первом наборе, система сворачивает его результат на уровне SQL еще до того, как произойдет слияние или соединение со вторым набором.
2. Потеря детальной аналитики: Из-за ранней группировки на стороне СУБД из первого набора данных могут исчезнуть промежуточные ключевые поля или измениться уровень детализации строк.
3. Нарушение связи наборов: Когда процессор СКД пытается связать предварительно сгруппированный первый набор с детальным вторым набором, связь по ключевым полям не может корректно сопоставиться. Результатом такого некорректного соединения становится то, что аналитические группировки во второй части отчета выводятся (так как они берутся из структуры), а вот числовые показатели по ним приходят пустыми (в виде NULL), что на форме отображается как нули.
4. Ошибки автозаполнения: Если у вас активен механизм автозаполнения полей, СКД при анализе оптимизированного запроса может ошибочно исключить из выборки поля связи, посчитав их неиспользуемыми в итоговых группировках.

Как решить проблему с обнулением данных?

Если вы обнаружили, что сложный отчёт с несколькими наборами данных стал выдавать пустые ресурсы, необходимо деактивировать эту оптимизацию. Разберем по шагам, как это сделать:

1. Откройте схему компоновки данных (СКД) вашего отчета в конфигураторе.
2. Перейдите на вкладку «Наборы данных».
3. Выберите по очереди каждый набор данных типа «Запрос».
4. Найдите в правой верхней части панели (рядом с флажком «Автозаполнение») свойство «Использовать группировки запроса если возможно».
5. Снимите этот флажок для всех наборов данных, которые участвуют в объединениях или соединениях.
6. Сохраните отчет и проверьте результат его формирования в режиме «1С:Предприятие».

После отключения флага СКД перестанет навязывать SQL-серверу преждевременную группировку, корректно соединит наборы данных на уровне детальных записей и правильно рассчитает все ресурсы.

Еще один подводный камень: «Ошибка преобразования данных XDTO»

Помимо искажения итогов в отчетах, данная настройка таит в себе еще одну серьезную опасность при коллективной разработке или переносе доработок между базами с разным уровнем обновления платформы.

Свойство useQueryGroupIfPossible (именно так этот флаг называется во внутренней XML-структуре схемы компоновки) записывается непосредственно в файл макета СКД. Если вы сохраните отчет или конфигурацию в платформе версии 8.3.14 или выше, а затем попытаетесь загрузить этот отчет или объединить конфигурацию в базе, работающей на более старом релизе платформы (например, 8.3.12, 8.3.10 и т.д.), вы получите критическую ошибку:

«Ошибка преобразования данных XDTO: НачалоСвойства: useQueryGroupIfPossible»

Старые версии платформ просто «не знают» о существовании такого свойства схемы и аварийно завершают чтение файла XML. Чтобы исправить эту ситуацию и вернуть схему в рабочее состояние для старых платформ, выполните следующие действия:

1. Сохраните проблемную схему компоновки данных во внешний файл (с расширением .xml или .xsd).
2. Откройте этот файл в любом текстовом редакторе (например, Notepad++ или встроенном текстовом редакторе 1С).
3. Запустите поиск по тексту файла фразы useQueryGroupIfPossible.
4. Вы найдете XML-теги, которые выглядят следующим образом: <useQueryGroupIfPossible>true</useQueryGroupIfPossible> Или со значением false.
5. Полностью удалите эти строки из XML-кода схемы компоновки данных.
6. Сохраните изменения в файле и загрузите исправленную схему обратно в отчет в конфигураторе.

Резюме и рекомендации

Подводя итог анализу новой опции, сформулируем правила ее безопасного использования:

• Когда оставлять включенной: Оставляйте флаг активным в простых отчетах, построенных на базе одного-единственного запроса к крупным таблицам БД (например, регистру накопления «Продажи» или «Обороты бюджетов»), где пользователи формируют только итоговые таблицы без вывода детальных строк. Это действительно ускорит работу отчета за счет агрегации на стороне СУБД.
• Когда обязательно отключать: Всегда снимайте этот флаг, если в схеме компоновки используется соединение или объединение нескольких наборов данных, а также если вы используете сложные связи параметров виртуальных таблиц. Помните, что корректность данных всегда приоритетнее скорости оптимизации.