При разработке отчетов в системе 1С:Предприятие мы часто сталкиваемся с необходимостью использовать данные из расширений конфигурации. Однако, когда речь заходит о внешних отчетах, возникают определенные сложности. Платформа 1С имеет известное ограничение: объекты, добавленные в расширение, не всегда напрямую видны во внешних отчетах или обработках при работе в режиме "Конфигуратор". Это приводит к тому, что конструктор запросов Системы Компоновки Данных (СКД) не "видит" реквизиты, таблицы и другие метаданные, которые существуют только в расширении. Давайте вместе разберем эту проблему и рассмотрим различные подходы, которые позволяют обойти данное ограничение, а также выясним, какие улучшения ожидаются в будущих версиях платформы.
Один из наиболее распространенных и эффективных способов работы с данными расширений во внешних отчетах — это создание и настройка схемы компоновки данных (СКД) непосредственно в режиме 1С:Предприятие. В этом режиме все объекты расширений доступны и видимы, что позволяет полноценно работать с ними.
Рассмотрим по шагам, как мы можем реализовать этот подход:
Консоль отчета или Универсальный отчет (если он позволяет сохранить СКД), которые запускаются в режиме 1С:Предприятие. Это ключевой момент, поскольку именно здесь метаданные расширения будут полностью доступны.МакетКомпоновкиДанных. В этот макет мы загружаем сохраненный ранее XML-файл. На этом этапе мы можем получить сообщения об ошибках, указывающие на "неизвестные поля" или "несуществующие метаданные". Не обращаем на них внимания и игнорируем эти предупреждения, так как отчет все равно будет корректно работать в режиме 1С:Предприятие.Консоль отчета), вносим корректировки, сохраняем новый XML-файл и загружаем его во внешний отчет.Этот метод подтверждается опытом пользователей, которые отмечают, что "Запрос пишешь в режиме предприятия", а "Запрос в модуле не будет открываться, но тебе и не нужно". Таким образом, мы используем преимущества режима 1С:Предприятие для разработки и только потом переносим готовую схему в Конфигуратор.
Этот подход часто считается более "правильным" с точки зрения архитектуры и интеграции. Вместо того чтобы создавать внешний отчет, который пытается использовать данные расширения, мы можем включить сам отчет непосредственно в состав расширения.
Проанализируем преимущества:
Как отмечают опытные разработчики, "не проще отчет ваять в расширении, а затем сохранить как внешний". Это не совсем так. Если отчет является частью расширения, он не является "внешним" в привычном смысле (файлом .erf), а встроен в конфигурацию через расширение.
В некоторых сложных случаях, когда данные невозможно получить простым запросом или требуется предварительная сложная обработка, мы можем программно сформировать данные и передать их в СКД.
Рассмотрим, как это работает:
ТаблицыЗначений. Собранные данные мы помещаем в объект ТаблицаЗначений.ТаблицыЗначений как внешнего набора данных. В схеме СКД мы можем указать, что один из наборов данных будет внешним. Мы передаем в СКД нашу программно сформированную ТаблицуЗначений.Пример программной передачи данных в СКД:
Функция СформироватьОтчет(СхемаКомпоновкиДанных, Настройки)
// ... Ваш код для получения данных из расширения
// Например, через менеджер объектов расширения
ТаблицаДанных = Новый ТаблицаЗначений;
ТаблицаДанных.Колонки.Добавить("ПолеИзРасширения");
ТаблицаДанных.Колонки.Добавить("ДругоеПоле");
// Заполняем ТаблицуДанных
// ...
КомпоновщикМакета = Новый КомпоновщикМакетаКомпоновкиДанных;
МакетКомпоновки = КомпоновщикМакета.Выполнить(СхемаКомпоновкиДанных, Настройки, , , Тип("ГенераторМакетаКомпоновкиДанныхДляКоллекцииЗначений"));
ПроцессорКомпоновки = Новый ПроцессорКомпоновкиДанных;
ПроцессорКомпоновки.Инициализировать(МакетКомпоновки, , ТаблицаДанных); // Передаем ТаблицуЗначений
Результат = Новый ТаблицаЗначений; // или другой объект, например, ТабличныйДокумент
ПроцессорВывода = Новый ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокумент;
ПроцессорВывода.УстановитьДокумент(Результат);
ПроцессорВывода.Вывести(ПроцессорКомпоновки);
Возврат Результат;
КонецФункции
Этот метод позволяет полностью обойти ограничения видимости метаданных в запросах СКД, так как данные уже подготовлены на программном уровне.
Для обращения к объектам, добавленным исключительно в расширение, в запросах СКД (особенно если мы редактируем их вручную) мы можем использовать прямой синтаксис обращения к метаданным, например, Справочник.ИмяСправочникаИзРасширения.
Важно: Этот подход требует, чтобы расширение было активно и загружено в информационную базу. Несмотря на то что Конфигуратор может "ругаться" на отсутствие таких метаданных в основной конфигурации, в режиме 1С:Предприятие запрос будет выполнен корректно, если объект существует в расширении.
Пример запроса:
ВЫБРАТЬ
Справочник.ИмяСправочникаИзРасширения.Код,
Справочник.ИмяСправочникаИзРасширения.Наименование
ИЗ
Справочник.ИмяСправочникаИзРасширения КАК СсылкаНаРасширение
Помните, что при таком подходе конструктор запросов в Конфигураторе все равно не сможет помочь вам с автодополнением или проверкой синтаксиса для объектов расширения.
Этот подход является скорее "хаком" для ускорения разработки и отладки, но сопряжен с рисками и не рекомендуется для постоянного использования. Он подразумевает временное "обманывание" Конфигуратора.
Разберем его шаги:
Пользователи на форумах описывают похожие, но более радикальные методы, например, создание копии базы и копирование объектов из расширения в основную конфигурацию этой копии для спокойной работы с СКД. Мы настоятельно не рекомендуем сохранять такие изменения в рабочей конфигурации, так как это нарушает принцип работы расширений и усложняет дальнейшие обновления.
Давайте подытожим и выделим ключевые моменты, которые помогут нам в работе:
.erf) предназначены для получения и представления данных, предлагая глубокую аналитику. Их главное преимущество — возможность подключения без изменения основной конфигурации, что значительно упрощает обновления системы.Нас ждут хорошие новости: в версии 1С:Предприятие 8.3.28 (или более поздних) планируется, что объекты расширений, установленных в информационную базу, станут доступны в режиме Конфигуратора во внешних отчетах и обработках. Это позволит нам использовать конструктор запросов для создания и редактирования запросов с участием объектов из расширений в схемах компоновки данных внешних отчетов без необходимости применять описанные выше обходные пути. Мы с нетерпением ожидаем этих изменений, которые значительно упростят разработку.
Мы рассмотрели несколько эффективных способов решения проблемы сохранения внешнего отчета, использующего данные расширения. Выбирайте тот, который наиболее подходит для вашей конкретной ситуации, и помните о грядущих улучшениях платформы!
← К списку