Почему СКД и консоль запросов 1С дают разный результат: разбираемся, как переписывается запрос

Запрос в консоли 1С возвращает правильные данные, а отчёт на СКД — другой результат.

На упрощённых примерах разбираем, как СКД исключает поля и временные таблицы, переносит пользовательские отборы и меняет параметры виртуальных таблиц. В конце — способы исправления и чек-лист для отладки сложных отчётов.

Наверное, многие разработчики 1С сталкивались с ситуацией:

• запрос в консоли возвращает правильные данные;

• тот же запрос переносится в систему компоновки данных;

• параметры и данные остаются прежними;

• результат отчёта меняется.

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

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

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

Примеры намеренно упрощены: названия регистров и полей условные, а запросы показывают механизм, а не готовое прикладное решение.

Что происходит между схемой компоновки и СУБД

Система компоновки данных — это не просто оболочка, которая выполняет написанный разработчиком запрос и оформляет полученный результат.

1С описывает СКД как декларативный механизм построения отчётов. Схема содержит текст запроса, поля, параметры, связи, ресурсы и другие элементы, а настройки определяют отборы, группировки, сортировку и состав выводимых данных. 

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

Далее для краткости я буду называть механизм, который преобразует исходный запрос, оптимизатором СКД. Речь не идёт об отдельном объекте платформы — это условное обозначение этапов формирования макета и запросов.

На практике СКД может:

• исключить неиспользуемые поля;

• удалить ненужные части пакета запросов;

• добавить служебные поля;

• получить представления ссылочных значений;

• перенести отбор ближе к источнику данных;

• изменить набор параметров;

• перестроить запрос с учётом группировок и сортировки.

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

Пример 1. СКД исключает поля, которые не выводятся в отчёт

Начнём с простого запроса к виртуальной таблице регистра накопления:

ВЫБРАТЬ

    Обороты.Номенклатура КАК Номенклатура,

    Обороты.Менеджер КАК Менеджер,

    Обороты.Склад КАК Склад,

    Обороты.КоличествоНачальныйОстаток

        КАК КоличествоНачальныйОстаток,

    Обороты.КоличествоОборот

        КАК КоличествоОборот,

    Обороты.КоличествоКонечныйОстаток

        КАК КоличествоКонечныйОстаток

ПОМЕСТИТЬ ВТОбороты

ИЗ

    РегистрНакопления.ЗакупкиПродажи.ОстаткиОбороты(

        &НачалоПериода,

        &КонецПериода,

        ,

        ) КАК Обороты

;

ВЫБРАТЬ

    ВТОбороты.Номенклатура,

    ВТОбороты.Менеджер,

    ВТОбороты.Склад,

    ВТОбороты.КоличествоНачальныйОстаток,

    ВТОбороты.КоличествоОборот,

    ВТОбороты.КоличествоКонечныйОстаток

ИЗ

    ВТОбороты КАК ВТОбороты

Но в настройках отчёта пользователь выбрал только три поля:

• Номенклатура;

• КоличествоОборот;

• КоличествоКонечныйОстаток.

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

ВЫБРАТЬ

    Обороты.Номенклатура,

    Обороты.КоличествоОборот,

    Обороты.КоличествоКонечныйОстаток

ИЗ

    РегистрНакопления.ЗакупкиПродажи.ОстаткиОбороты(

        &НачалоПериода,

        &КонецПериода,

        ,

        ) КАК Обороты

СКД определила, какие данные нужны для текущего варианта отчёта, и не стала получать остальные.

Для простого отчёта это полезная оптимизация:

• уменьшается объём выбираемых данных;

• сокращается размер временной таблицы;

• СУБД обрабатывает меньше полей;

• запрос потенциально выполняется быстрее.

Но отсюда следует важный вывод:

Наличие поля в исходном тексте запроса ещё не означает, что оно сохранится в фактически выполняемом запросе.

Служебные поля и представления ссылок

СКД способна не только убрать поля, но и добавить новые конструкции.

Например, при выводе ссылочных значений в сформированном запросе могут появиться операции, необходимые для получения представлений объектов и упорядочивания результата.

Вместо непосредственного вывода ссылочного значения СКД может добавить:

• получение его представления;

• проверку на пустое значение;

• служебное поле порядка;

• сортировку по представлению.

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

Пример 2. Неиспользуемая временная таблица исчезает

Добавим в пакет запросов две временные таблицы:

ВЫБРАТЬ

    Продажи.Номенклатура,

    СУММА(Продажи.КоличествоОборот) КАК Количество

ПОМЕСТИТЬ ВТПродажи

ИЗ

    РегистрНакопления.Продажи.Обороты(

        &НачалоПериода,

        &КонецПериода,

        ,

        ) КАК Продажи

СГРУППИРОВАТЬ ПО

    Продажи.Номенклатура

;

ВЫБРАТЬ

    Остатки.Номенклатура,

    Остатки.КоличествоОстаток

ПОМЕСТИТЬ ВТОстатки

ИЗ

    РегистрНакопления.ТоварыНаСкладах.Остатки(

        &КонецПериода,

        ) КАК Остатки

;

ВЫБРАТЬ

    ВТПродажи.Номенклатура,

    ВТПродажи.Количество

ИЗ

    ВТПродажи КАК ВТПродажи

В финальной части пакета используется только ВТПродажи. Данные из ВТОстатки ни на что не влияют.

В сформированном запросе вторая временная таблица может отсутствовать полностью. СКД видит, что результата от неё никто не использует, и исключает этот участок пакета.

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

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

Когда оптимизация начинает менять расчёт

Удаление лишнего становится проблемой, если поле:

1. не выводится в итоговый отчёт;

2. не используется в финальной группировке;

3. но влияет на промежуточную агрегацию или расчёт.

Рассмотрим такой случай.

Пример 3. Поле склада не выводится, но влияет на количество к заказу

Есть данные о потребности и остатках товаров:

Количество к заказу нужно рассчитывать отдельно для каждого склада:
Максимум(Потребность − Остаток, 0)

Получаем:

• яблоки: 200 − 100 = 100;

• молоко на складе №1: заказывать не нужно;

• молоко на складе №2: 500 − 0 = 500.

Итог по региону:

Сначала рассчитаем потребность по каждому складу:

ВЫБРАТЬ

    Потребности.Регион КАК Регион,

    Потребности.Склад КАК Склад,

    Потребности.Номенклатура КАК Номенклатура,

    СУММА(

        ВЫБОР

            КОГДА Потребности.Потребность >

                    Потребности.Остаток

                ТОГДА Потребности.Потребность -

                    Потребности.Остаток

            ИНАЧЕ 0

        КОНЕЦ

    ) КАК КоличествоКЗаказу

ПОМЕСТИТЬ ВТКоличествоПоСкладам

ИЗ

    РегистрСведений.ПотребностиПоСкладам

        КАК Потребности

СГРУППИРОВАТЬ ПО

    Потребности.Регион,

    Потребности.Склад,

    Потребности.Номенклатура

;

Затем агрегируем результат по региону:

ВЫБРАТЬ

    ВТКоличествоПоСкладам.Регион КАК Регион,

    ВТКоличествоПоСкладам.Номенклатура

        КАК Номенклатура,

    СУММА(

        ВТКоличествоПоСкладам.КоличествоКЗаказу

    ) КАК КоличествоКЗаказу

ИЗ

    ВТКоличествоПоСкладам

        КАК ВТКоличествоПоСкладам

ГДЕ

    ВТКоличествоПоСкладам.КоличествоКЗаказу > 0

СГРУППИРОВАТЬ ПО

    ВТКоличествоПоСкладам.Регион,

    ВТКоличествоПоСкладам.Номенклатура

Поле Склад в итоговом отчёте не выводится. Пользователь видит только регион, номенклатуру и количество к заказу.

На протестированном стенде СКД исключила склад из промежуточного набора. В результате остатки и потребности начали агрегироваться на уровне региона до расчёта количества к заказу.

Для молока логика изменилась:

Общая потребность: 500
Общий остаток: 200

Количество к заказу: 500 − 200 = 300

Вместо правильных 500 единиц отчёт показал 300.

Запрос в обычной консоли отрабатывал правильно. Расхождение возникло после формирования запроса средствами СКД.

Почему это произошло

С точки зрения итогового представления поле Склад не требовалось:

• пользователь его не выбрал;

• в финальной группировке его нет;

• отдельная колонка склада не выводится.

Но с точки зрения бизнес-логики поле было критически важным: оно определяло уровень, на котором нужно сначала рассчитать потребность.

СКД не знает, что заказ рассчитывается отдельно для каждого склада. Она видит только структуру схемы, зависимости полей и настройки отчёта.

Как сохранить поле, которое нужно только для промежуточного расчёта

Способ 1. Сделать зависимость явной

Самый понятный вариант — пометить поле как обязательное в схеме компоновки, если свойства конкретного поля и версия платформы позволяют это сделать.

Тогда склад останется в наборе данных, даже если пользователь не выводит его отдельной колонкой.

Это предпочтительный подход, потому что намерение разработчика выражено непосредственно в схеме:

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

Способ 2. Сохранить поле в группировке

В протестированном примере поле также сохранялось, если участвовало в группировке компоновки, даже не отображаясь как отдельная колонка.

Однако здесь необходимо проверить итоговую структуру отчёта: дополнительная группировка не должна менять уровень детализации или порядок расчёта ресурсов.

Способ 3. Изолировать расчёт во вложенном запросе

Можно сделать промежуточную логику самостоятельным подзапросом:

ВЫБРАТЬ

    Расчет.Регион,

    Расчет.Номенклатура,

    СУММА(Расчет.КоличествоКЗаказу)

        КАК КоличествоКЗаказу

ИЗ

    (

        ВЫБРАТЬ

            Потребности.Регион КАК Регион,

            Потребности.Склад КАК Склад,

            Потребности.Номенклатура КАК Номенклатура,

            ВЫБОР

                КОГДА Потребности.Потребность >

                        Потребности.Остаток

                    ТОГДА Потребности.Потребность -

                        Потребности.Остаток

                ИНАЧЕ 0

            КОНЕЦ КАК КоличествоКЗаказу

        ИЗ

            РегистрСведений.ПотребностиПоСкладам

                КАК Потребности

    ) КАК Расчет

ГДЕ

    Расчет.КоличествоКЗаказу > 0

СГРУППИРОВАТЬ ПО

    Расчет.Регион,

    Расчет.Номенклатура

На рассматриваемом стенде перенос расчёта во вложенный запрос позволил сохранить нужную последовательность операций.

Однако делать из этого универсальное правило нельзя. Формулировка «СКД никогда не оптимизирует вложенные запросы» была бы слишком категоричной. Такое решение нужно повторно проверять после обновления платформы и изменения схемы.

Способ 4. Добавить формальное использование поля

Иногда разработчики добавляют выражение или условие, которое не меняет результат, но создаёт явную зависимость от поля.

Например, искусственно используют Склад в промежуточном выражении, чтобы СКД не сочла его ненужным.

Способ может сработать, но у него есть серьёзные минусы:

• причина конструкции неочевидна;

• следующий разработчик может удалить её как лишнюю;

• решение завязано на текущее поведение механизма;

• запрос становится сложнее сопровождать.

Такой приём лучше рассматривать как временный обходной путь, а не как нормальное архитектурное решение.

Перенос пользовательского отбора

Оптимизация касается не только состава полей. СКД может перенести условие отбора ближе к источнику данных, чтобы уменьшить объём обрабатываемых строк.

Обычно это полезно: чем раньше СУБД исключит ненужные записи, тем меньше данных придётся обрабатывать дальше.

Но перенос безопасен только тогда, когда поле имеет одинаковый смысл на всех этапах запроса.

Пример 4. Склад до и после преобразования — это разные поля

Предположим, сначала отчёт собирает данные по фактическим складам:

ВЫБРАТЬ

    Данные.Регион КАК Регион,

    Данные.Склад КАК Склад,

    Данные.Номенклатура КАК Номенклатура,

    СУММА(Данные.Количество) КАК Количество

ПОМЕСТИТЬ ВТДанныеПоСкладам

ИЗ

    РегистрСведений.ДанныеПоСкладам КАК Данные

СГРУППИРОВАТЬ ПО

    Данные.Регион,

    Данные.Склад,

    Данные.Номенклатура

;

Затем фактический склад заменяется основным складом региона:

ВЫБРАТЬ

    ВТДанныеПоСкладам.Регион КАК Регион,

    НастройкиРегионов.ОсновнойСклад КАК Склад,

    ВТДанныеПоСкладам.Номенклатура КАК Номенклатура,

    СУММА(ВТДанныеПоСкладам.Количество)

        КАК Количество

ИЗ

    ВТДанныеПоСкладам

        КАК ВТДанныеПоСкладам

        ЛЕВОЕ СОЕДИНЕНИЕ

            РегистрСведений.НастройкиРегионов

                КАК НастройкиРегионов

        ПО ВТДанныеПоСкладам.Регион =

            НастройкиРегионов.Регион

СГРУППИРОВАТЬ ПО

    ВТДанныеПоСкладам.Регион,

    НастройкиРегионов.ОсновнойСклад,

    ВТДанныеПоСкладам.Номенклатура

Пользователь видит поле Склад и устанавливает по нему отбор.

Но в запросе есть два разных по смыслу значения:

1. фактический склад исходной записи;

2. основной склад, подставленный в итоговом результате.

Если СКД переносит отбор в начало запроса, он может примениться к фактическому складу — ещё до подстановки основного.

В результате часть строк отсекается раньше времени, и итоговая сумма меняется.

Как исправитьРазделить семантически разные поля

Не стоит давать им одинаковое имя.
Вместо
НастройкиРегионов.ОсновнойСклад КАК Склад

лучше написать:
НастройкиРегионов.ОсновнойСклад КАК ОсновнойСклад

Теперь пользовательский отбор накладывается на поле ОсновнойСклад, а у СКД меньше оснований связывать его с исходным полем Склад.

Переименование здесь — не косметика. Оно явно фиксирует, что поля имеют разную бизнес-семантику.

Управлять местом применения отбора

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

В схеме можно отключить автозаполнение соответствующих настроек и явно определить, к какому элементу компоновки должен применяться отбор.

Общий принцип такой:

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

Отбор по вычисляемому полю

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

Пример 5. Доступный остаток рассчитывается после резервовЕсть следующие данные:

Сначала получаем исходные показатели:

ВЫБРАТЬ

    Остатки.Номенклатура КАК Номенклатура,

    Остатки.Остаток КАК Остаток,

    Остатки.Зарезервировано КАК Зарезервировано

ПОМЕСТИТЬ ВТОстатки

ИЗ

    РегистрСведений.ОстаткиИРезервы КАК Остатки

;

Затем рассчитываем свободный остаток:

ВЫБРАТЬ

    ВТОстатки.Номенклатура КАК Номенклатура,

    ВТОстатки.Остаток —

        ВТОстатки.Зарезервировано КАК Остаток

ИЗ

    ВТОстатки КАК ВТОстатки

Пользователь устанавливает отбор:
Остаток > 0

По итоговому расчёту должны остаться только молоко:

• яблоки: 50 − 50 = 0;

• молоко: 50 − 0 = 50.

Но если отбор будет перенесён к исходному полю ВТОстатки.Остаток, обе строки пройдут условие, потому что первоначальный остаток у обеих номенклатур равен 50.

Исправление

Не нужно использовать одно имя для разных показателей.

Лучше назвать вычисляемое поле явно:

ВЫБРАТЬ

    ВТОстатки.Номенклатура КАК Номенклатура,

    ВТОстатки.Остаток -

        ВТОстатки.Зарезервировано

            КАК ДоступныйОстаток

ИЗ

    ВТОстатки КАК ВТОстатки

И устанавливать пользовательский отбор уже по полю:

ДоступныйОстаток > 0

Это делает запрос понятнее не только СКД, но и разработчику:

• Остаток — физическое количество;

• Зарезервировано — занято под заказы;

• ДоступныйОстаток — вычисленный показатель.

Чем точнее названы поля, тем меньше вероятность, что автоматическая трансформация свяжет разные этапы расчёта одной семантикой.

Параметры виртуальных таблиц

Ещё один чувствительный участок — несколько обращений к одной виртуальной таблице с разными периодами.

Пример 6. Продажи за февраль и продажи до февраля

Нужно сравнить:

1. продажи за февраль;

2. продажи за весь предшествующий период.

Первый набор данных:

ВЫБРАТЬ

    Продажи.Номенклатура КАК Номенклатура,

    СУММА(Продажи.КоличествоОборот)

        КАК КоличествоЗаПериод

ПОМЕСТИТЬ ВТПродажиЗаПериод

ИЗ

    РегистрНакопления.Продажи.Обороты(

        &НачалоФевраля,

        &КонецФевраля,

        ,

        ) КАК Продажи

СГРУППИРОВАТЬ ПО

    Продажи.Номенклатура

;

Второй набор:

ВЫБРАТЬ

    Продажи.Номенклатура КАК Номенклатура,

    СУММА(Продажи.КоличествоОборот)

        КАК КоличествоДоПериода

ПОМЕСТИТЬ ВТПродажиДоПериода

ИЗ

    РегистрНакопления.Продажи.Обороты(

        ,

        &НачалоФевраля,

        ,

        ) КАК Продажи

СГРУППИРОВАТЬ ПО

    Продажи.Номенклатура

;

В консоли запросов наборы возвращали разные обороты, как и ожидалось.

Но в рассматриваемом отчёте после формирования СКД оба показателя стали одинаковыми. Анализ макета показал, что параметры обращений к виртуальной таблице были преобразованы таким образом, что фактические периоды совпали.

Простое переименование параметров проблему не решило.

Рабочим вариантом на тестовом стенде стало явное управление значениями параметров средствами компоновки, а не только их указание внутри текста виртуальной таблицы.

Этот пример особенно важно публиковать вместе с:

• точной версией платформы;

• исходным запросом;

• сформированным запросом;

• значениями параметров;

• скриншотом или фрагментом макета компоновки.

Без этих данных читатель не сможет воспроизвести эффект и понять, относится ли он к его версии платформы.

Как анализировать запрос, который действительно выполняет СКД

Когда результат отчёта отличается от консоли запросов, не стоит сразу переписывать всю бизнес-логику.

Сначала нужно выяснить, какой запрос сформировала СКД.

1. Зафиксировать условия

Запишите:

• версию платформы;

• режим совместимости;

• конфигурацию;

• СУБД;

• вариант отчёта;

• значения параметров;

• пользовательские отборы;

• группировки и выбранные поля.

Без этого результат будет трудно воспроизвести после изменения настроек или обновления базы.

2. Проверить исходный запрос отдельно

Выполните его в консоли запросов с теми же параметрами.

Сохраните:

• текст запроса;

• значения параметров;

• количество строк;

• контрольные суммы или ключевые показатели.

3. Загрузить схему в консоль СКД

Консоль позволяет проходить отдельные этапы компоновки и анализировать сформированные системой запросы. Именно её 1С рекомендует использовать для отладки сложных схем. 

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

4. Сравнить не весь запрос, а ключевые участки

Проверяйте последовательно:

5. Сократить пример

Не стоит отлаживать проблему только на запросе из нескольких сотен строк.

Создайте минимальный воспроизводимый пример:

1. оставьте одну проблемную временную таблицу;

2. сократите количество полей;

3. сохраните один отбор;

4. замените реальные данные несколькими понятными строками;

5. сравните результат до и после изменения настроек.

Минимальный пример быстрее показывает, какое именно действие СКД меняет запрос.

6. Повторить проверку после исправления

Недостаточно получить правильные цифры в одном варианте отчёта.

Нужно проверить:

• отчёт без пользовательских отборов;

• отчёт с каждым значимым отбором;

• разные группировки;

• включение и отключение детальных записей;

• вариант с минимальным набором полей;

• вариант со всеми доступными полями;

• граничные значения периодов;

• пустые ссылки и NULL;

• работу после обновления платформы.

Что учитывать при разработке сложных отчётов

Из разобранных примеров можно вывести несколько практических правил.

Не полагаться на неявную зависимость

Если поле критично для расчёта, это должно быть видно из структуры схемы или запроса.

Фраза «поле же присутствует во временной таблице» недостаточна. Если оно не используется дальше явно, СКД может счесть его ненужным.

Не давать одинаковые имена разным по смыслу полям

Плохой вариант:

Склад → преобразование → Склад

Остаток → вычисление → Остаток

Более безопасный вариант:

ФактическийСклад → ОсновнойСклад

ФизическийОстаток → ДоступныйОстаток

Название поля должно отражать его бизнес-смысл и этап расчёта.

Контролировать пользовательские отборы

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

Особенно внимательно нужно проверять отборы по:

• вычисляемым полям;

• полям, которые переопределяются;

• составным типам;

• регистраторам и партиям;

• показателям после агрегации;

• значениям, полученным соединением с другой таблицей.

Разделять бизнес-расчёт и оформление отчёта

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

СКД удобна именно как декларативный механизм. Но чем больше скрытых зависимостей содержит расчёт, тем сложнее полагаться на автоматическое преобразование.

Проверять фактический макет, а не только исходный запрос

Запрос, записанный в схеме, — это исходный материал.

Для отладки сложного отчёта важнее запрос, который получился после применения настроек компоновки.

Краткий чек-лист: отчёт СКД не совпадает с консолью

Когда результат расходится, я проверяю следующее:

Итог

СКД не просто выполняет написанный разработчиком запрос. Она формирует запрос под конкретный вариант отчёта с учётом:

• выбранных полей;

• отборов;

• группировок;

• сортировки;

• параметров;

• структуры набора данных.

В большинстве случаев это уменьшает объём обрабатываемых данных и избавляет разработчика от лишней ручной работы.

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

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

Главная мысль здесь простая:

Корректный исходный запрос ещё не гарантирует корректный отчёт, если важная часть бизнес-логики выражена только неявно.

Чем яснее в схеме зафиксированы зависимости, уровни расчёта и смысл полей, тем меньше вероятность, что полезная оптимизация неожиданно изменит результат.