При разработке внешних отчетов и обработок программисты часто сталкиваются с неприятной особенностью платформы 1С: Конструктор запросов "отказывается" видеть объекты (таблицы, поля), добавленные через расширения конфигурации. Это происходит потому, что внешний файл .erf или .epf по своей природе является автономным объектом, и Конфигуратор при его редактировании ориентируется прежде всего на структуру основной конфигурации.
В этой статье мы подробно разберем, почему возникает эта проблема, и рассмотрим несколько эффективных способов ее решения, от простых манипуляций в Конфигураторе до использования инструментов режима "Предприятие".
Рассмотрим ситуацию глубже: когда мы открываем внешний отчет в Конфигураторе, среда разработки не всегда может однозначно определить, в контексте какого набора расширений будет запускаться этот отчет. В одной базе может быть активно десять расширений, в другой — три, и они могут перекрывать друг друга. Поэтому штатное поведение Конструктора запросов — показывать только те объекты, которые жестко зафиксированы в основной конфигурации. Особенно остро эта проблема проявляется в старых режимах совместимости (например, 8.3.12), где механизмы динамического связывания метаданных еще не были до конца оптимизированы.
Это самый надежный и популярный метод среди разработчиков. Если Конструктор запросов не видит ваш новый регистр из расширения, мы "обманем" систему, временно сделав отчет частью этого расширения. Разберем по шагам:
РегистрНакопления.ДополнительныеПродажи).Теперь у вас есть готовый файл .erf с корректным запросом к объектам расширения. Помните, что при последующем редактировании этого файла вне контекста расширения Конструктор запроса снова может "ругаться" на неизвестные таблицы, но сам запрос в режиме "Предприятие" будет работать корректно.
Выясним причину, по которой Конструктор запроса в режиме "1С:Предприятие" работает лучше, чем в Конфигураторе. В запущенном сеансе база данных уже полностью инициализирована со всеми активными расширениями. Платформа "знает" итоговую структуру таблиц.
Рассмотрим алгоритм действий:
Если вы работаете с СКД, вы можете настроить всю схему прямо в консоли СКД в режиме "Предприятие", выгрузить результат в XML-файл, а затем загрузить этот XML в схему компоновки вашего внешнего отчета в Конфигураторе.
В свойствах внешнего отчета (самый верхний узел в окне свойств) существует поле Основной контейнер метаданных. По умолчанию там установлено значение "Конфигурация". В некоторых версиях платформы (начиная с 8.3.14 и выше при соответствующих режимах совместимости) изменение этого контекста или перенос разработки в 1C:Enterprise Development Tools (EDT) позволяет более гибко работать с расширениями. EDT строит единую модель метаданных для всего проекта, объединяя основную конфигурацию и все подключенные расширения, что делает проблему невидимости объектов неактуальной.
Если вам нужно визуально составить сложный запрос со связями к регистру из расширения, а использовать Способ 1 неудобно, можно прибегнуть к хитрости с временными таблицами. Рассмотрим на примере кода:
// В модуле объекта или в схеме запроса
// Сначала описываем структуру таблицы вручную, если конструктор её не видит
ТекстЗапроса = "ВЫБРАТЬ * ПОМЕСТИТЬ ВТ_Данные ИЗ &ТаблицаРасширения КАК Таблица";
Хотя этот метод требует ручного ввода имен полей, он позволяет "пробросить" описание полей во временную таблицу. После этого, вызвав Конструктор запроса к следующему пакету, вы сможете работать с полями ВТ_Данные визуально, так как Конструктор всегда видит структуру временных таблиц, определенных выше в коде.
Проанализируем влияние режима совместимости 8.3.12, упомянутого в вопросе. В этой версии работа с метаданными расширений имела ряд ограничений. Например, программное обращение к типам данных расширений во внешних обработках могло требовать обязательного наличия этих типов в основной конфигурации (хотя бы в виде заимствования). Если вы столкнулись с тем, что даже в режиме "Предприятие" отчет не видит данные, убедитесь, что:
/ClearCache).Таким образом, несмотря на то что Конфигуратор накладывает определенные ограничения на визуальную разработку, использование временного отчета внутри расширения или использование консоли запросов в режиме "Предприятие" полностью решают проблему доступности данных. Мы рекомендуем использовать Способ 1 для первичной настройки отчета и Способ 2 для оперативной правки запросов.