Как устранить ошибку операторов ССЫЛКА и ВЫРАЗИТЬ в СКД внутри расширения при работе с субконто

← На главную

При разработке отчетов в системе компоновки данных (СКД) внутри расширений конфигурации программисты часто сталкиваются со специфическим поведением платформы. Одна из наиболее распространенных проблем возникает при попытке построить отчет по регистру бухгалтерии (например, Хозрасчетный в "Бухгалтерии предприятия 3.0"), используя в запросе проверку типов для полей субконто или корсубконто. В этой статье мы подробно разберем, почему возникают ошибки при использовании операторов ССЫЛКА и ВЫРАЗИТЬ, и рассмотрим проверенные способы их обхода.

Суть проблемы и анализ ситуации

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


ВЫБРАТЬ
    ХР.Счет КАК Счет,
    ХР.СуммаОборот КАК СуммаОборот,
    ВЫБОР
        КОГДА ХР.КорСубконто1 ССЫЛКА Справочник.Контрагенты ТОГДА "Контрагенты"
        ИНАЧЕ "Другой тип"
    КОНЕЦ КАК ТипКорСубконто1
ИЗ
    РегистрБухгалтерии.Хозрасчетный.Обороты КАК ХР

Проанализируем поведение системы: если запустить этот же запрос во внешнем отчете или в составе основной конфигурации, он отработает корректно. Однако внутри расширения конструктор схемы компоновки данных выдает ошибку валидации. Аналогичная ситуация происходит и при попытке жесткого приведения типа через оператор ВЫРАЗИТЬ:


ВЫБРАТЬ
    ВЫРАЗИТЬ(ХР.КорСубконто1 КАК Справочник.Контрагенты) КАК Контрагент
ИЗ
    РегистрБухгалтерии.Хозрасчетный.Обороты КАК ХР

Причина такого поведения кроется в механизме проверки метаданных. Поля Субконто и КорСубконто имеют составной тип данных, который определяется объектом ПланВидовХарактеристик. В контексте расширения связь между виртуальной таблицей регистра и допустимыми типами этого плана часто "размывается" для парсера запросов конфигуратора. Система не может гарантировать, что конкретное поле субконто может быть приведено к указанному ссылочному типу, даже если все необходимые объекты метаданных заимствованы в расширение.

Решение №1: Использование функции ТИПЗНАЧЕНИЯ

Наиболее эффективным и стабильным способом обхода этого ограничения является использование функции ТИПЗНАЧЕНИЯ в сочетании с оператором ТИП. В отличие от оператора ССЫЛКА, который проходит строгую статическую проверку в конфигураторе, функция ТИПЗНАЧЕНИЯ вычисляется непосредственно в момент выполнения запроса к базе данных.

Давайте перепишем наш исходный запрос, используя этот подход:


ВЫБРАТЬ
    ХР.Счет КАК Счет,
    ХР.СуммаОборот КАК СуммаОборот,
    ВЫБОР
        КОГДА ТИПЗНАЧЕНИЯ(ХР.КорСубконто1) = ТИП(Справочник.Контрагенты) ТОГДА "Контрагенты"
        ИНАЧЕ "Другой тип"
    КОНЕЦ КАК ТипКорСубконто1
ИЗ
    РегистрБухгалтерии.Хозрасчетный.Обороты КАК ХР

Важный нюанс: Такой синтаксис не вызывает претензий у валидатора расширения, так как он не требует от системы сопоставления структуры ПланВидовХарактеристик с конкретным полем регистра на этапе сохранения схемы СКД. Это позволяет успешно сохранить отчет и использовать его в режиме предприятия.

Решение №2: Проверка заимствования характеристик

Если вы все же хотите использовать ССЫЛКА или ВЫРАЗИТЬ, необходимо убедиться, что архитектура расширения полностью соответствует требованиям платформы. Разберем по шагам, что должно быть заимствовано:

Регистр бухгалтерии: Должен быть заимствован со всеми необходимыми измерениями.
План счетов: Обязательно должен присутствовать в расширении, так как он связан с регистром.
План видов характеристик (ПВХ): Это критический момент. Вы должны заимствовать ПВХ, который является источником типов для субконто.
Тип данных в ПВХ: В заимствованном объекте ПланВидовХарактеристик, в свойстве "Тип значений", должны быть отмечены галочками те типы (например, Справочник.Контрагенты), к которым вы обращаетесь в запросе.

Если в основной конфигурации список типов ПВХ был расширен, а в расширении вы используете "старую" версию заимствованного объекта, это гарантированно приведет к ошибке ВЫРАЗИТЬ.

Особенности проверки в конфигураторе

Стоит обратить внимание на интересную особенность, которую отмечают многие разработчики: иногда отчет, созданный в расширении, подсвечивается красным или выдает ошибку при открытии конструктора СКД, но при этом прекрасно работает в режиме "1С:Предприятие".

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

Отладить запрос во внешнем отчете.
Перенести готовый текст запроса в схему СКД расширения (через текстовый редактор, минуя визуальный конструктор, если это возможно).
Проверить работу отчета непосредственно в пользовательском режиме.

Дополнительные рекомендации

Проанализируем ситуацию, когда даже ТИПЗНАЧЕНИЯ не помогает (например, при очень сложных вложенных запросах). В таких случаях рекомендуется рассмотреть вариант программного формирования схемы компоновки данных. Вы можете описать запрос в программном модуле расширения, сформировать структуру и передать её в отчет. Программный метод создания схемы обходит ограничения визуального конструктора конфигуратора, так как проверка типов будет происходить уже в рантайме.

Также помните, что тип субконто теоретически может быть не ссылочным (например, Булево или Число). Если в ПланВидовХарактеристик указаны примитивные типы, оператор ССЫЛКА к ним применен быть не может по определению, что также может служить причиной диагностических сообщений системы.

Подводя итог, можно сказать, что для разработки надежных отчетов в расширениях 1С при работе с регистрами бухгалтерии лучшей практикой является использование ТИПЗНАЧЕНИЯ(Поле) = ТИП(ИмяТипа). Это избавляет от лишних проблем с валидацией метаданных и делает ваш код более устойчивым к изменениям в структуре заимствованных объектов.