Почему возникает ошибка «Несовместимые типы ВЫРАЗИТЬ» в запросах 1С?

← На главную

Разберем одну из типичных проблем, с которой сталкиваются разработчики 1С при написании сложных запросов: ошибку «Несовместимые типы ВЫРАЗИТЬ». Часто бывает так, что запрос успешно отрабатывает во внешней консоли запросов, но отказывается сохраняться или активироваться в конфигураторе. Давайте выясним, почему так происходит и как это исправить.

Причина возникновения ошибки

Основная причина кроется в том, как платформа 1С анализирует метаданные. Когда мы работаем с дополнительными реквизитами или другими полями, имеющими составной тип данных, конфигуратор выполняет строгую проверку.

Оператор ВЫРАЗИТЬ требует, чтобы поле было гарантированно приводимо к целевому типу (в нашем случае — ЧИСЛО). Если в составе типа поля могут находиться значения, которые невозможно превратить в число (например, строки, ссылки на справочники или булево), конфигуратор выдает ошибку на этапе проверки синтаксиса. Он видит потенциальный риск выполнения некорректной операции, в то время как консоль запросов может игнорировать этот риск, выполняя запрос «как есть» на уровне СУБД.

Способ решения №1: Использование конструкции ВЫБОР КОГДА

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

Рассмотрим пример того, как это должно выглядеть в вашем коде:


ВЫБОР
    КОГДА ХарактеристикиНоменклатурыДополнительныеРеквизиты.Значение ССЫЛКА ЧИСЛО 
        ТОГДА ВЫРАЗИТЬ(ХарактеристикиНоменклатурыДополнительныеРеквизиты.Значение КАК ЧИСЛО(15, 2))
    ИНАЧЕ 0
КОНЕЦ КАК Длина

Используя конструкцию ВЫБОР КОГДА, мы страхуем запрос от попыток приведения несовместимых типов, тем самым удовлетворяя требованиям конфигуратора к строгой типизации.

Способ решения №2: Предварительная фильтрация данных

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

Посмотрим, как это реализовать:


ВЫБРАТЬ
    ВТ.Номенклатура,
    ВТ.Характеристика,
    ВТ.Количество,
    ХарактеристикиНоменклатурыДополнительныеРеквизиты.Значение КАК Длина
ПОМЕСТИТЬ ВТДлина
ИЗ
    ВТ КАК ВТ
    ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ХарактеристикиНоменклатуры.ДополнительныеРеквизиты КАК ХарактеристикиНоменклатурыДополнительныеРеквизиты
    ПО ВТ.Характеристика = ХарактеристикиНоменклатурыДополнительныеРеквизиты.Ссылка
ГДЕ
    ХарактеристикиНоменклатурыДополнительныеРеквизиты.Значение ССЫЛКА ЧИСЛО

Благодаря добавлению условия ССЫЛКА ЧИСЛО, конфигуратор «поймет», что в дальнейшем с полем будут работать только как с числом, и ошибка при использовании ВЫРАЗИТЬ исчезнет.

Особенности разработки в расширениях

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

Важные советы для разработчика:

Всегда старайтесь явно приводить типы, используя проверку ССЫЛКА. Это защитит ваш код от неожиданных ошибок при изменении структуры данных в будущем.
Если вы используете дополнительные реквизиты, помните, что они всегда имеют составной тип. По умолчанию считайте, что в них может быть всё что угодно, и всегда обрабатывайте этот случай через ВЫБОР КОГДА.
Если сложность запроса растет, рассмотрите возможность переноса расчетов в СКД (систему компоновки данных), которая гораздо более гибко работает с составными типами и приведением данных, чем обычный конструктор запросов.

Следуя этим простым шагам, вы сможете избежать «несовместимых типов» и сделать ваши запросы стабильными как в консоли, так и в конфигураторе.