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