Нередко разработчики 1С сталкиваются с ситуацией, которая может поставить в тупик: вы meticulously составляете и отлаживаете запрос в консоли, он возвращает идеально точные цифры. Затем вы переносите этот же текст запроса в отчет на Системе Компоновки Данных (СКД), запускаете его и видите совершенно другие, часто неверные, данные. Иногда отчет и вовсе показывает старые результаты, как будто ваши изменения не были применены.
Давайте вместе разберемся, почему возникают такие расхождения и как с ними бороться. Проанализируем несколько возможных причин, от самых простых и очевидных до более сложных, связанных с внутренними механизмами работы СКД.
Первое, что стоит проверить — это различные сохраненные данные, которые могут "перекрывать" ваши изменения в схеме компоновки данных. Система и пользователи могут хранить свои версии настроек отчета.
Пользовательские настройки. Пользователь мог изменить отчет под себя (добавить отбор, поменять сортировку) и сохранить эти изменения. При последующем открытии отчета платформа применит именно сохраненные пользовательские настройки, а не те, что заданы в конфигураторе по умолчанию.
Если это помогло, значит, проблема была в сохраненных настройках конкретного пользователя. Обратите внимание, что эту операцию нужно проделать под каждым пользователем, у которого возникает проблема, так как настройки хранятся индивидуально.
Кэш платформы. Иногда платформа "запоминает" старую версию отчета или его макета и использует ее вместо обновленной. Очистка кэша часто решает проблему "неприменяемых" изменений.
Для очистки кэша необходимо:
%APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8.В клиент-серверном варианте также может помочь перезапуск службы "Агент сервера 1С:Предприятия".
Эта проблема очень распространена, если вы работаете с отчетами, подключенными через механизм "Дополнительные отчеты и обработки" (который является частью Библиотеки стандартных подсистем — БСП).
Суть в том, что когда вы регистрируете внешний отчет в системе, 1С сохраняет его копию внутри информационной базы. Когда пользователь запускает этот отчет из интерфейса программы, система открывает именно внутреннюю сохраненную копию, а не тот файл (*.erf), который вы редактируете в конфигураторе.
Поэтому, даже если вы сто раз сохраните изменения в своем файле и откроете его через меню "Файл" -> "Открыть", при запуске из стандартного интерфейса будет по-прежнему работать старая версия.
Правильный порядок обновления внешнего отчета:
*.erf.Только после этой процедуры система обновит свою внутреннюю копию, и пользователи увидят изменения. Чтобы убедиться, что проблема именно в этом, можно временно отключить или удалить отчет из списка дополнительных, а затем открыть ваш файл через "Файл" -> "Открыть" — если данные станут верными, значит, вы на верном пути.
Это самая сложная и неочевидная причина, но именно она часто объясняет расхождения в числовых данных, когда запрос вроде бы обновлен корректно. СКД — это не просто исполнитель запроса. Это мощный конструктор, который анализирует ваш исходный текст запроса и модифицирует его перед выполнением, исходя из настроек отчета (выбранных полей, отборов, сортировок).
Рассмотрим ситуацию из форумной темы: в консоли расчет 2000 - 500 = 1500 работает верно, а в отчете СКД результат равен 2000. Это явный признак того, что часть запроса, отвечающая за вычитание 500, была отброшена оптимизатором СКД.
Как работает оптимизация?
500, она не попадет в расчет.Номенклатура = "Услуга1", СКД может по ошибке применить этот отбор и к основной услуге, и к ее комплектующему. В итоге строка с комплектующим ("Товар") будет отфильтрована, и его стоимость не будет вычтена.Как бороться с оптимизацией СКД?
У нас есть несколько инструментов, чтобы "подсказать" СКД, как правильно обрабатывать наш запрос.
1. Переименование полей. Это самый простой и эффективный способ, предложенный в теме. Чтобы отбор по одному полю не влиял на другое с таким же именем, просто переименуйте одно из них в запросе. Например, если проблема в отборе по номенклатуре:
ВЫБРАТЬ
Продажи.Номенклатура,
Продажи.Сумма,
СебестоимостьКомплектующих.Номенклатура КАК НоменклатураКомплектующего, // Переименовали поле
СебестоимостьКомплектующих.Себестоимость
ИЗ
РегистрНакопления.Продажи КАК Продажи
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СебестоимостьКомплектующих КАК СебестоимостьКомплектующих
ПО Продажи.Номенклатура = СебестоимостьКомплектующих.ОсновнаяУслуга
Теперь пользовательский отбор по полю Номенклатура не затронет поле НоменклатураКомплектующего, и соединение отработает корректно.
2. Использование фигурных скобок {}. Это более мощный инструмент. Если заключить часть текста запроса (например, всё левое соединение) в фигурные скобки, вы даете СКД команду: "этот кусок кода не трогать и не оптимизировать". СКД включит его в итоговый запрос как есть.
ВЫБРАТЬ
Продажи.Номенклатура,
Продажи.Сумма,
СебестоимостьКомплектующих.Себестоимость
ИЗ
РегистрНакопления.Продажи КАК Продажи
{ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СебестоимостьКомплектующих КАК СебестоимостьКомплектующих
ПО Продажи.Номенклатура = СебестоимостьКомплектующих.ОсновнаяУслуга}
Этот способ гарантирует, что соединение не будет отброшено, даже если поля из присоединенной таблицы явно не используются в настройках отчета.
3. Использование отладчика. Лучший способ понять, что происходит "под капотом" — это отладка. Поставьте точку останова в модуле отчета перед выполнением компоновки и проанализируйте объект НастройкиКомпоновкиДанных. Вы увидите все примененные пользовательские отборы и сможете понять, как они влияют на результат. Также можно программно получить итоговый текст запроса, который генерирует СКД, и сравнить его с вашим исходным — это сразу покажет все "оптимизации", сделанные системой.
Таким образом, при расхождении данных между консолью и СКД всегда двигайтесь от простого к сложному: сначала проверьте кэш и настройки, затем — правильность обновления внешнего отчета, и только потом погружайтесь в анализ оптимизации запроса самой системой компоновки данных. Понимание этих механизмов поможет вам создавать сложные и надежные отчеты.