Как получить реквизит «Наименование» из составного типа в расширении 1С?

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

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

Почему возникает ошибка в расширении?

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

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

Рассмотрим по шагам, как устранить эту ошибку и заставить запрос работать корректно.

Способ 1: Использование оператора ВЫРАЗИТЬ

Это самый надежный и правильный способ обхода подобных проблем в расширениях. Чтобы снять неопределенность для парсера запросов и визуального конструктора, мы должны явно указать платформе, к какому типу данных обращаемся. Воспользуемся оператором ВЫРАЗИТЬ (CAST).

Посмотрим на пример того, как нужно преобразовать проблемный участок кода:

ВЫБРАТЬ
    ДокументПКО.Ссылка КАК ДокументСсылка,
    ВЫРАЗИТЬ(ДокументПКО.КассаОтправитель КАК Справочник.Кассы).Наименование КАК КассаНаименование
ИЗ
    Документ.ПриходноКассовыйОрдер КАК ДокументПКО

Применяя ВЫРАЗИТЬ, мы принудительно направляем систему к конкретной таблице базы данных (в данном случае к справочнику Кассы). Это полностью решает проблему «Поле не найдено» как на этапе сохранения запроса в конфигураторе, так и при его выполнении.

Способ 2: Проверка длины наименования в свойствах расширения

Если приведение типа не помогло, проанализируем структуру заимствованного справочника. Перейдем в дерево метаданных расширения, найдем заимствованный справочник (например, Кассы) и откроем его палитру свойств.

Обратим внимание на свойство Длина наименования. Важно убедиться, что оно больше нуля (например, 50 или 100, в зависимости от основной конфигурации). Если по какой-то причине там установлен «0», система считает, что у справочника в рамках расширения нет наименования в принципе. Корректировка этого свойства на правильное значение часто решает проблему мгновенно.

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

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

Вместо того чтобы заваливать расширение лишними метаданными, применим следующий алгоритм:

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

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

Способ 4: Очистка расширения и проверка ролей

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

Посмотрим, что можно предпринять:

1. Удалим проблемные реквизиты составного типа и справочники из расширения.
2. Обновим конфигурацию базы данных.
3. Заново добавим нужные объекты (справочники и документы) в расширение.
4. Проверим настройки самого расширения: дважды кликнем по корню расширения и убедимся, что установлена галочка Использовать основные роли для всех пользователей (в зависимости от архитектуры прав доступа). Отсутствие прав на стандартные реквизиты в контексте расширения также может приводить к маскировке полей под ошибку «Поле не найдено».

Резюмируя сказанное, при работе с расширениями всегда нужно помнить о строгой типизации. Используя явное приведение типов с помощью ВЫРАЗИТЬ, мы не только избавляемся от ошибок визуального конструктора, но и делаем код более оптимизированным и понятным для СУБД.