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

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

Разберем причину: иерархия метаданных

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

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

Способ 1: Написание запроса в контексте расширения

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

Выясним, как это работает по шагам:

1. Откройте объект метаданных в расширении (например, форму или модуль).
2. Вызовите конструктор запроса именно там.
3. В списке доступных таблиц вы увидите объекты основной конфигурации, дополненные вашими реквизитами из расширения.

Способ 2: Использование «песочницы» (временной обработки)

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

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

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

Способ 3: Ручное редактирование текста запроса

Для простых операций зачастую быстрее дописать текст запроса вручную, не прибегая к помощи конструктора. Рассмотрим пример. Допустим, мы расширили справочник Номенклатура реквизитом прф_СкладскойИндекс. Текст запроса будет выглядеть следующим образом:

Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |   Номенклатура.Ссылка КАК Ссылка,
    |   Номенклатура.Наименование КАК Наименование,
    |   Номенклатура.прф_СкладскойИндекс КАК СкладскойИндекс
    |ИЗ
    |   Справочник.Номенклатура КАК Номенклатура";

Платформа успешно скомпилирует этот запрос в режиме исполнения, так как она сопоставит поле прф_СкладскойИндекс с соответствующей колонкой в физической таблице базы данных.

Технические нюансы: производительность и хранение

Многих разработчиков волнует вопрос: не замедляет ли работу системы использование реквизитов в расширениях? Проанализируем ситуацию с точки зрения СУБД. Платформа 1С хранит реквизиты расширения в тех же самых физических таблицах, что и основные данные. Например, если в справочнике _Reference45 (Номенклатура) были колонки _Fld100 и _Fld101, то реквизит расширения просто станет колонкой _Fld102 в этой же таблице.

Отсюда следует несколько важных выводов:

• Производительность: Скорость выборки данных из расширения идентична скорости выборки из основной конфигурации.
• Индексация: Вы можете (и должны) устанавливать свойство Индексировать для реквизитов расширения, если планируете использовать их в условиях отбора (ГДЕ). Это создаст стандартный индекс средствами SQL.
• Обновление: При удалении расширения колонки из БД физически удаляются вместе с данными, поэтому будьте осторожны.

Ограничения и рекомендации по версиям

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

1. Типизация: Если ваш реквизит в расширении имеет тип, который также создан в этом расширении (например, ссылка на новый справочник из расширения), использовать его в запросах основной конфигурации крайне рискованно. Основная конфигурация может не распознать тип данных, что приведет к ошибке при обращении через точку.

2. Префиксы: Всегда используйте уникальные префиксы (например, абв_Наименование). Это защитит вашу разработку, если в будущем фирма «1С» выпустит обновление основной конфигурации, где появится реквизит с таким же именем. Конфликт имен в расширении может привести к невозможности запуска базы.

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

Таким образом, мы выяснили, что отсутствие видимости в конструкторе — это не баг, а особенность архитектуры 1С. Используя контекст самого расширения или ручное редактирование текста, вы сможете полноценно использовать все возможности расширения данных без потери производительности.