Почему не обновляется внешний отчет 1С 8 на СКД и как решить проблему с красными крестами в полях?

← На главную

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

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

Симптомы и суть проблемы

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

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

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

---

Причина №1. Ограничение прав доступа и составные типы данных в СКД

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

Если в вашем запросе СКД присутствует поле составного типа (например, регистратор для регистра накопления или документ-основание, который может принимать значения нескольких видов документов), платформа анализирует права текущего пользователя на каждый из этих типов. Если у пользователя нет прав доступа (даже просто на «Просмотр» или «Чтение») хотя бы к одному из документов или справочников, входящих в этот составной тип, СКД превентивно полностью исключает данное поле и все его дочерние реквизиты из списка доступных полей.

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

Причина №2. Кэширование вариантов отчетов в подсистеме БСП

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

Справочник ВариантыОтчетов
Справочник ПредопределенныеВариантыОтчетов
Регистр сведений НастройкиОтчетов

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

Причина №3. Влияние функциональных опций

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

Причина №4. Кэш планов SQL-запросов и ограничения RLS

При наличии у пользователя ограничений на уровне записей (RLS) платформа 1С модифицирует исходный SQL-запрос СКД, добавляя в него условия проверки прав. Эти тяжелые запросы компилируются и кэшируются СУБД и сервером приложений. На старых релизах платформы (в частности, на ветках 8.3.11, 8.3.12) существовали зарегистрированные ошибки, из-за которых кэш планов запросов СКД с RLS для конкретного пользователя не сбрасывался при обновлении файла внешнего отчета. Назначение пользователю роли без RLS (или полных прав) заставляло систему перекомпилировать запрос, из-за чего отчет начинал работать корректно.

Причина №5. Безопасный режим работы внешних отчетов

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

---

Пошаговые методы решения проблемы

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

Метод 1. Проверка и доработка прав доступа (Роли)

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

Особое внимание уделим составным типам данных. Если поле имеет составной тип, используем в запросе СКД явное приведение типов с помощью функции ВЫРАЗИТЬ. Например, вместо обращения напрямую к полю составного типа:


ВЫБРАТЬ
    Продажи.Регистратор.Организация КАК Организация
ИЗ
    РегистрНакопления.Продажи КАК Продажи

Применим явное ограничение типов для каждого возможного документа:


ВЫБРАТЬ
    ВЫРАЗИТЬ(Продажи.Регистратор КАК Документ.РеализацияТоваровУслуг).Организация КАК Организация
ИЗ
    РегистрНакопления.Продажи КАК Продажи

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

Метод 2. Принудительное обновление вспомогательных данных БСП

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

Откроем обработку «Обновление вспомогательных данных» (доступна в составе инструментов разработчика или через запуск сеанса с параметром ЗапуститьОбновлениеИнформационнойБазы).
Программно вызовем метод обновления вариантов отчетов для нашей схемы. Для этого можно использовать следующий код в обработке:
```
Настройки = ВариантыОтчетов.ПолучитьНастройкиОбновления();
ВариантыОтчетов.Обновить(Настройки);
```
Это заставит БСП перечитать схемы всех внешних отчетов и обновить записи в справочниках вариантов отчетов для всех пользователей.

Метод 3. Очистка сохраненных пользовательских настроек

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


Процедура ПередОткрытием(Отказ, СтандартнаяОбработка)
    Если Не СохранениеНастроек.ЗаполнитьНастройкиПриОткрытииОтчета(ОтчетОбъект) Тогда
        ИнициализацияОтчета();
    КонецЕсли;
КонецПроцедуры

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

Зайдем в базу данных под полными правами.
Перейдем в интерфейс управления сохраненными настройками (в УПП это «Сервис — Настройки пользователя — Сохраненные настройки»).
Найдем настройки по имени нашего внешнего отчета для конкретного пользователя и безжалостно удалим их. При большом количестве сотрудников платформа для создания программных роботов автоматизирует повторяющиеся действия в интерфейсе без ручного труда. При следующем открытии система будет вынуждена инициализировать схему СКД по умолчанию из нового файла.

Метод 4. Правильное сохранение и переименование отчета

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

В конфигураторе откроем внешний отчет.
Выполним изменения в схеме компоновки данных, завершим работу с конструктором СКД.
Обязательно перейдем в главное меню конфигуратора и выберем пункт Файл — Сохранить (или нажмем комбинацию клавиш Ctrl+S), убедившись, что фокус ввода стоит на самом окне отчета, а не внутри конструктора схемы.
Попробуем полностью изменить уникальное имя объекта отчета (в свойствах корневого элемента) и его синоним. Это заставит БСП воспринять отчет как совершенно новый объект и создать под него чистые кэш-записи в базе данных, которые еще не были привязаны к настройкам старых пользователей.

Метод 5. Использование привилегированного режима для построения отчета

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


Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка)
    
    СтандартнаяОбработка = Ложь;
    УстановитьПривилегированныйРежим(Истина);
    
    // Выполняем стандартную компоновку программно в привилегированном режиме
    КомпоновщикМакета = Новый КомпоновщикМакетаКомпоновкиДанных;
    МакетКомпоновки = КомпоновщикМакета.Выполнить(СхемаКомпоновкиДанных, КомпоновщикНастроек.ПолучитьНастройки(), ДанныеРасшифровки);
    
    ПроцессорКомпоновки = Новый ПроцессорКомпоновкиДанных;
    ПроцессорКомпоновки.Инициализировать(МакетКомпоновки, , ДанныеРасшифровки, Истина);
    
    ПроцессорВывода = Новый ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокумент;
    ПроцессорВывода.УстановитьДокумент(ДокументРезультат);
    ПроцессорВывода.Вывести(ПроцессорКомпоновки);
    
    УстановитьПривилегированныйРежим(Ложь);
    
КонецПроцедуры

Использование УстановитьПривилегированныйРежим(Истина) позволяет временно отключить проверку прав доступа RLS и ограничений метаданных на время выполнения запроса СКД. Это полностью предотвратит пропадание полей и появление красных крестов у пользователей с любым набором прав. Для быстрой реализации такого подхода подойдёт готовый пример отчета СКД с выполнением в привилегированном режиме.

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