Почему один и тот же отчет в 1С формируется с разной скоростью у разных пользователей?

В процессе администрирования и поддержки конфигураций 1С (например, 1С:Зарплата и управление персоналом 3.1) нередко возникает ситуация: два пользователя с одинаковыми полными правами формируют один и тот же типовой отчет (к примеру, Расчетный листок по одному сотруднику), но у одного формирование занимает 10–11 секунд, а у второго — более минуты. При этом перенос сеанса на другой компьютер или терминальный сервер не меняет картину. Проанализируем, почему возникает такое поведение платформы, как настройки пользователя влияют на исполняемый код и как решить данную проблему.

Технические причины разницы в скорости формирования отчетов

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

1. Динамическая генерация SQL-запроса в СКД: Система компоновки данных не выполняет статичный запрос. Если в пользовательских настройках включены дополнительные поля, обращение через точку (например, Сотрудник.Подразделение.Родитель), скрытые группировки или сортировки, СКД автоматически добавляет конструкции LEFT JOIN к таблицам информационной базы. Это кардинально перестраивает план выполнения запроса на стороне СУБД.
2. Особенности алгоритмов сбора данных в ЗУП 3.1: Формирование расчетных листков — это сложный программный процесс, использующий внешние наборы данных, временные таблицы и модули подсистемы расчета зарплаты. Флаги в настройках отчета (разбивка по рабочим местам, детализация по статьям финансирования, отображение выплат за период) запускают совершенно разные программные ветки, опрашивающие регистры расчета Начисления, Удержания и регистр накопления Взаиморасчеты с сотрудниками с разной глубиной.
3. Механизмы RLS и группы доступа: Наличие роли ПолныеПрава не всегда отключает механизмы разграничения прав на уровне записей (RLS), управляемые БСП. Если для профиля пользователя включены ограничения по организациям или группам физических лиц, платформа внедряет в итоговые запросы соединения с таблицами ключей доступа.
4. Неоптимальный план запроса в кэше СУБД (Parameter Sniffing): При незначительных отличиях в переданных параметрах или структуре отбора СУБД может применить неоптимальный план из процедурного кэша (например, сканирование таблицы Table Scan вместо индексного поиска Index Seek).

Методы диагностики проблемы

Рассмотрим по шагам, как локализовать и точно определить причину задержки при формировании отчета под конкретным пользователем.

Шаг 1. Сравнение настроек компоновщика через XML.

Пользовательские настройки отчета хранятся в объекте КомпоновщикНастроек. Чтобы увидеть реальные различия, выгрузим настройки обоих пользователей в XML через отладчик или внешнюю обработку:

// Пример программной выгрузки пользовательских настроек в XML
НастройкиXML = Новый ЗаписьXML;
НастройкиXML.УстановитьСтроку();
СериализаторXDTO.ЗаписатьXML(НастройкиXML, ОтчетОбъект.КомпоновщикНастроек.ПользовательскиеНастройки);
СтрокаXML = НастройкиXML.Закрыть();

Сравним полученные текстовые файлы в любой утилите сравнения (diff). Это сразу покажет, какие скрытые поля, отборы или параметры вывода были активированы у медленного пользователя.

Шаг 2. Замер производительности в Конфигураторе.

Запустим замер производительности и выполним отчет под обоими пользователями. Посмотрим на распределение времени:

1. Если время тратится в общих модулях зарплаты при заполнении временных таблиц — причина в переключателях детализации отчета.
2. Если длительность сосредоточена на методах ПроцессорКомпоновкиДанных.Инициализировать() или ПроцессорВывода.Вывести() — причина в сложных вычисляемых полях или тяжелых соединениях СКД.

Способы устранения проблемы

Разберем практические способы восстановления нормальной скорости формирования отчета.

1. Очистка и сброс пользовательских настроек отчета

Поскольку настройки вариантов отчетов сохраняются в системных таблицах информационной базы (в частности, ХранилищеВариантовОтчетов и ХранилищеСистемныхНастроек), стандартной очистки локального кэша файлов на диске недостаточно. Выполним следующие действия:

1. Откроем раздел Администрирование → Настройки пользователей и прав.
2. Перейдем по ссылке Персональные настройки пользователей → Очистка настроек.
3. Выберем проблемного пользователя, укажем объект (конкретный отчет) и выполним удаление сохраненных настроек.
4. При открытии отчета нажмем кнопку Еще → Установить стандартные настройки.

2. Копирование эталонных настроек

Если у одного из пользователей (например, администратора) отчет работает быстро и корректно, скопируем его настройки проблемному пользователю:

1. В разделе Настройки пользователей и прав выберем пункт Копирование настроек.
2. В поле От кого укажем пользователя с быстрым формированием отчета, в поле Кому — целевого сотрудника.
3. В списке настроек выберем только нужный вариант отчета и нажмем Скопировать и закрыть.

3. Обновление статистики и очистка процедурного кэша СУБД

Если сброс настроек привел к непредсказуемому изменению времени формирования (например, время выросло еще сильнее), выполним регламентное обслуживание базы данных на сервере СУБД:

1. Запустим обновление статистик для таблиц регистров расчета и накопления.
2. Выполним переиндексацию таблиц базы данных.
3. Очистим процедурный кэш СУБД (для Microsoft SQL Server команда DBCC FREEPROCCACHE), чтобы сервер перестроил планы выполнения тяжелых запросов СКД с учетом актуальной плотности данных.