Почему в запросах 1С меняется тип данных при использовании ОБЪЕДИНИТЬ ВСЕ и как это исправить?

При разработке отчетов или обработок, использующих сложные запросы с оператором ОБЪЕДИНИТЬ ВСЕ, разработчики часто сталкиваются с неожиданным поведением платформы: значения в результирующей выборке внезапно меняют свой тип. Например, поля, которые должны содержать отрицательные числа (денежные суммы или количества), вдруг начинают принудительно приводиться к положительным значениям или «обрезаются» согласно метаданным более «узкого» типа.

Давайте вместе разберемся, почему это происходит и как заставить платформу 1С работать так, как нам нужно, сохраняя исходные типы данных для корректных расчетов.

Выясняем причину проблемы

Основная причина такого поведения кроется во внутреннем механизме типизации платформы. Когда вы используете ОБЪЕДИНИТЬ ВСЕ, 1С должна привести все части запроса к единой структуре данных. Если в одной части запроса используется поле с типом ОпределяемыйТип.ДенежнаяСуммаНеотрицательная, а в другой — ОпределяемыйТип.ДенежнаяСуммаЛюбогоЗнака, транслятор запросов пытается найти «безопасный» общий знаменатель.

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

Разбираем способы решения

Существует несколько проверенных подходов, которые помогут избежать потери данных и нежелательного изменения типов. Рассмотрим их по порядку.

Способ №1: «Принудительная подсказка» через математические операции

Этот метод считается наиболее надежным и простым в реализации. Суть его заключается в том, чтобы «подсказать» платформе, что в итоговой колонке должны присутствовать значения определенного типа. Мы делаем это, добавляя к полю выражение, которое не меняет математический результат, но принуждает транслятор использовать нужный нам диапазон чисел.

Рассмотрим пример. Если во втором подзапросе данные теряют отрицательный знак из-за неверного приведения типов, мы можем изменить выражение следующим образом:

// Вместо прямого выбора поля используем конструкцию:
-РеализацияТоваровУслугВидыЗапасов.Количество * 0 + РеализацияТоваровУслугВидыЗапасов.СуммаСНДС

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

Способ №2: Использование конструкции ВЫБОР

Если математические хитрости кажутся вам недостаточно прозрачными, попробуйте воспользоваться конструкцией ВЫБОР. Она позволяет явно определить структуру данных для всей колонки.

Проанализируем пример конструкции:

ВЫБОР 
    КОГДА ИСТИНА ТОГДА ПолеСНужнымТипом 
    ИНАЧЕ 0 
КОНЕЦ

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

Рекомендации по проектированию сложных запросов

1. Проверяйте метаданные: Прежде чем объединять таблицы, посмотрите на свойства полей в конфигураторе. Если поля ссылаются на разные ОпределяемыеТипы с разными ограничениями по точности и знаку, будьте готовы к тому, что 1С предпримет попытку «защитить» данные.
2. Тестируйте в консоли запросов: Как показала практика, иногда поведение консоли может отличаться от поведения запроса, встроенного в модуль объекта. Обязательно проверяйте результат выполнения не только в консоли, но и в самой 1С (в файловой или клиент-серверной базе).
3. Разделяйте задачи: Если запрос становится слишком сложным и проблема типизации не решается простыми приемами, рассмотрите возможность выполнения двух отдельных запросов с последующим объединением их результатов в ТаблицаЗначений на стороне кода 1С. Это гарантирует 100% сохранение типов данных, так как платформа сама корректно адаптирует колонки при добавлении строк.

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