← На главную

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

1. Неполные условия в соединениях таблиц

Самая частая причина размножения строк — не до конца настроенное ЛЕВОЕ СОЕДИНЕНИЕ между таблицами запроса. На тестовой базе для анализируемого объекта могла существовать только одна запись в подчиненной таблице, поэтому запрос возвращал корректные цифры. На рабочей базе реальных данных больше, и при отсутствии связи по всем необходимым ключевым полям происходит размножение записей.

Рассмотрим по шагам, на что обратить внимание при объединении таблиц:

1. Проверим все связи в предложении ПО запроса СКД. Соединение должно производиться по всему комплекту ключевых полей (например, не только по объекту, но и по дате, организации или подразделению).
2. Если связь выполняется с таблицей дополнительных реквизитов или сведений, обязательно явно укажем конкретное свойство:
   Скопировать код

   
   ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ДополнительныеРеквизиты КАК ДопРеквизиты
       ПО ДопРеквизиты.Объект = ОсновнаяТаблица.Ссылка
       И ДопРеквизиты.Свойство = &ИскомоеСвойство
   

2. Декартово произведение при соединении подчиненных таблиц

Если в одном запросе выполняется соединение с несколькими табличными частями или подчиненными регистрами одновременно (связи «один ко многим»), происходит декартово произведение. Каждая строка первой табличной части умножается на каждая строку второй. Если на рабочей базе у объекта заполнено по 3 строки в двух табличных частях, на выходе получим 9 записей вместо 3.

Выясним, как избежать этой проблемы:

1. Предварительно сворачиваем и агрегируем данные подчиненных таблиц во временных таблицах перед их связыванием с основной таблицей.
2. Избегаем прямой связи двух подчиненных таблиц с типом связи «один ко многим» в рамках одного SQL-запроса.

3. Особенности генерации запроса механизмом СКД

Разберем особенности работы самой системы компоновки. СКД не выполняет запрос «как есть», а динамически модифицирует текст SQL-запроса к СУБД в зависимости от выбраных пользователем полей, отборов и группировок. На рабочей базе пользователь мог выбрать другие группировки, добавить поля детальных записей или настроить специфический отбор.

В результате СКД может убрать из итогового SQL-запроса секцию ГРУППИРОВАТЬ ПО или добавить дополнительные таблицы, разворачивающие итоги. Для диагностики этого поведения выполним следующие действия:

1. С помощью консоли СКД или отладчика 1С (в момент формирования макета компоновки) откроем и проанализируем итоговый исполняемый запрос, сгенерированный платформой.
2. Если СКД исключает группировки, укажем ключевое слово АВТОЗАПОЛНЕНИЕ в схеме компоновки или явно ограничим доступность полей для выбора.

4. Отсутствие или неправильная настройка полей на вкладке «Ресурсы»

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

Убедимся, что для всех суммируемых числовых показателей заданы агрегатные выражения, например, Сумма(СуммаОстаток).

5. Некорректная настройка связей наборов данных

Посмотрим на структуру отчета, если он построен на нескольких наборах данных (например, «НаборДанных_Запрос» и «НаборДанных_Объект»). Если связи между ними настроены по полям со связью «один ко многим» без использования уникального ключа, СКД будет размножать строки главного набора на каждую совпадающую строку подчиненного.

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

6. Ошибки при обращении к виртуальным таблицам срезов

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

Всегда передаем точную дату в параметры виртуальной таблицы СрезПоследних(&Период, ...) и выполняем соединение по всему набору ключевых измерений регистра.

7. Различия платформ СУБД и кэширование

Выясним технические факторы, связанные с окружением:

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