Почему внешний отчет выдает синтаксическую ошибку при обращении к реквизиту расширения и как это исправить?

← На главную

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

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

Выясняем причину: почему Конфигуратор «не видит» реквизит расширения?

Для того чтобы эффективно решить проблему, необходимо четко понимать физику процесса. Главная причина кроется в изоляции контекстов выполнения и разработки:

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

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

Решение А. Программная подмена запроса в СКД (Рекомендуемый метод)

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

Суть метода заключается в использовании «заглушки». Вместо реального реквизита расширения в конструкторе запросов мы пишем пустое поле или константу, а перед выводом отчета программно заменяем эту заглушку на реальный реквизит.

Разберем этот процесс по шагам:

В Конфигураторе открываем схему компоновки данных (СКД) нашего внешнего отчета.
В тексте запроса набора данных вместо обращения к реквизиту расширения пишем нейтральное значение, которое Конфигуратор без проблем пропустит. Например:
```
ВЫБРАТЬ
    Ссылка КАК Ссылка,
    0 КАК МойРеквизитРасширения
ИЗ
    Справочник.Номенклатура
```
В схеме компоновки данных настраиваем поле МойРеквизитРасширения как обычно: задаем ему нужный тип (например, число или строка), добавляем в ресурсы, выводим в настройки структуры отчета. Конфигуратор полностью доволен, схема валидна.
Переходим в модуль объекта внешнего отчета. Для этого в окне свойств отчета нажимаем «Открыть модуль объекта».
Создаем предопределенную процедуру ПриКомпоновкеРезультата. В ней мы перехватим стандартную обработку вывода отчета, подменим текст запроса в схеме на реальный и выведем результат программно.

Проанализируем готовый код для модуля объекта внешнего отчета:


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

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

Решение Б. Перенос схемы компоновки через XML-файл

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

Разберем этот алгоритм работы:

Запускаем базу данных в режиме «1С:Предприятие».
Открываем любую внешнюю обработку «Консоль компоновки данных» или «Консоль отчетов» (важно запускать ее именно в пользовательском режиме, где расширение полностью активно).
В консоли создаем новый отчет, пишем правильный запрос, который напрямую обращается к реквизиту расширения (например: Номенклатура.МойРеквизитРасширения). Настраиваем все необходимые поля группировок, ресурсы и параметры.
В консоли находим команду экспорта/сохранения схемы и сохраняем настроенную схему компоновки данных во внешний файл формата .xml.
Возвращаемся в Конфигуратор, открываем наш внешний отчет .erf.
Внутри СКД нажимаем кнопку загрузки схемы из файла и выбираем наш сохраненный .xml. Схема успешно импортируется со всей структурой полей.

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

Решение В. Встраивание отчета в расширение конфигурации (Современный стандарт БСП)

Разработчики Библиотеки стандартных подсистем (БСП) в актуальных версиях рекомендуют уходить от классических внешних отчетов, если они разрабатываются под конкретную базу данных с расширениями. Наиболее надежный и перспективный подход — встраивать ваши отчеты непосредственно в само расширение.

Рассмотрим, почему это выгодно и как это сделать:

В окне «Конфигурация» находим нужное нам расширение, открываем его дерево объектов.
В ветке «Отчеты» расширения добавляем новый отчет.
Поскольку отчет теперь физически находится внутри расширения, конструктор запросов Конфигуратора видит как объекты основной конфигурации, так и все новые реквизиты, добавленные в это расширение. Никаких ошибок синтаксиса больше возникать не будет.
Такой отчет можно легко обновлять, сопровождать и переносить между базами в составе самого расширения.

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

Обратите внимание на безопасный режим (Safe Mode)

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

В безопасном режиме платформа накладывает жесткие ограничения на программный доступ к метаданным расширений. Если в самом расширении также взведен флаг «Безопасный режим» (в списке расширений конфигурации), то внешний отчет может получить отказ в доступе к новым реквизитам.

Для гарантированной работоспособности рекомендуется сделать следующее:

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


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

Что изменится в будущем (Платформа 8.3.28)

Фирма «1С» детально изучила неудобства разработчиков, связанные с контекстной изоляцией файлов при проектировании. Начиная с версии платформы 8.3.28, анонсирован качественно новый механизм работы Конфигуратора.

В новых версиях платформы внешние отчеты и обработки (файлы .erf/.epf), открытые в Конфигураторе, смогут использовать контекст метаданных расширений, подключенных к активной информационной базе. Конструкторы запросов и СКД перестанут выдавать ошибки при обращении к новым реквизитам, что избавит разработчиков от необходимости использовать программные заглушки или XML-импорт.

А пока ваша система работает на более ранних версиях платформы, используйте Вариант А (программная подмена через ПриКомпоновкеРезультата) или Вариант В (встраивание в расширение) как наиболее надежные и проверенные временем решения!

← На главную