Как во внешнем отчете СКД использовать реквизиты и объекты из расширения конфигурации?

← На главную

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

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

Причина проблемы: разрыв контекста метаданных

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

Способ 1. Метод «заглушек» (Mock-объектов)

Это один из самых популярных и простых способов среди разработчиков. Разберем его по шагам:

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

Поскольку в режиме «1С:Предприятие» имя реквизита в расширении полностью совпадает с тем, что мы прописали в отчете, платформа успешно подставит данные из расширения в запрос отчета.

Способ 2. «Слепая» разработка и ручная правка запроса

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

Проанализируем алгоритм:

Открываем схему компоновки данных внешнего отчета.
Переходим на закладку «Набор данных» и открываем текст запроса.
Вручную вписываем имя поля, которое существует только в расширении. Например: СправочникНоменклатура.ДополнительныйРеквизитИзРасширения.
При попытке закрыть конструктор запросов или сохранить схему, система выдаст предупреждение: «Поле не найдено». Нам нужно проигнорировать эту ошибку и согласиться на сохранение.

Совет: Чтобы конструктор запросов не «затирал» ваши ручные правки, можно использовать псевдонимы. Сначала выберите любое стандартное поле (например, Код), а затем в тексте запроса замените Код КАК Код на РеальноеИмяИзРасширения КАК НужноеИмяПоля.

Способ 3. Использование Консоли СКД в режиме «Предприятие»

Этот метод позволяет работать с актуальными метаданными, так как в режиме пользователя расширения уже применены. Посмотрим, как это сделать:

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

Этот способ наиболее безопасен и точен, так как исключает ошибки опечаток при ручном вводе имен полей.

Способ 4. Программная модификация схемы (Событие ПриКомпоновкеРезультата)

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


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

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

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

Способ 5. Использование Общего модуля расширения как провайдера данных

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

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

Проанализируем преимущество: внешнему отчету больше не нужно знать о структуре расширения. Он просто ожидает таблицу с определенными именами колонок. Однако при больших объемах данных стоит изучить методы оптимизации отчетов с набором данных - объект, чтобы избежать проблем с производительностью. Это значительно упрощает обновление системы.

Итоги

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