Почему 1С не видит справочник из расширения в конструкторе запросов и как это исправить?

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

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

Для начала проанализируем техническую сторону вопроса. Конструктор запросов в Конфигураторе всегда работает в контексте определенного набора метаданных. Когда вы создаете или открываете внешний файл отчета (.erf), система по умолчанию связывает его с «Основной конфигурацией». Расширение же представляет собой дополнительный слой, который динамически накладывается на основную конфигурацию. В старых версиях платформы (до 8.3.15) и при стандартном подходе Конфигуратор не объединяет эти слои для внешних файлов. В итоге конструктор «видит» только то, что есть в корневой конфигурации, и полностью игнорирует добавленные в расширение объекты.

Решение №1: Добавление отчета в состав расширения (самый надежный способ)

Рассмотрим самый эффективный метод, который позволяет получить полный доступ ко всем объектам расширения без ограничений. Вместо того чтобы создавать внешний отчет через меню «Файл — Новый», мы добавим его непосредственно в дерево объектов расширения.

1. Откроем Конфигуратор и перейдем в дерево объектов нужного нам расширения.
2. В ветке Отчеты нажмем кнопку «Добавить».
3. Теперь, когда отчет является частью расширения, откроем схему компоновки данных (СКД) или конструктор запроса.
4. Проанализируем результат: теперь все справочники, документы и реквизиты, добавленные в это расширение, отображаются в списке доступных таблиц.
5. После завершения разработки и отладки, если нам все же нужен именно внешний файл, нажмем на отчете правой кнопкой мыши и выберем пункт «Сохранить как внешний отчет...».
6. После сохранения файл можно удалить из расширения, чтобы не загромождать его метаданные.

Решение №2: Использование внешних инструментов в режиме Предприятия

Выясним, как упростить отладку, не прибегая к постоянному обновлению расширения. Часто более продуктивным подходом является разработка схемы запроса не в Конфигураторе, а непосредственно в пользовательском режиме.

Воспользуемся обработкой «Консоль системы компоновки данных». Поскольку в режиме Предприятия расширение уже успешно применено и интегрировано в общую структуру метаданных, консоль будет видеть абсолютно все объекты. Порядок действий следующий:

1. Запустим «1С:Предприятие» с подключенным расширением.
2. Откроем консоль СКД и сформируем там запрос к нашему справочнику из расширения.
3. Настроим поля, ресурсы и параметры.
4. Выгрузим готовую схему в XML-файл.
5. Вернемся в Конфигуратор, откроем внешний отчет и загрузим полученную схему в СКД.

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

Решение №3: Особенности работы на новых версиях платформы (8.3.15+)

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

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

Программное обращение к объектам расширения

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

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

// Вместо прямого обращения: Справочники.МойСправочникИзРасширения.ПустаяСсылка()
// Используем безопасный метод получения типа:
НужныйТип = Тип("СправочникСсылка.МойСправочникИзРасширения");
Если ТипЗнч(СсылкаНаОбъект) = НужныйТип Тогда
    // Выполняем действия
КонецЕсли;

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

Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |   Т.Ссылка КАК Ссылка,
    |   Т.Наименование КАК Наименование
    |ИЗ
    |   Справочник.МойСправочникИзРасширения КАК Т";
РезультатЗапроса = Запрос.Выполнить();

Метод «Пустого справочника» (Лайфхак для старых платформ)

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

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

Подведем итоги

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