Почему уникальный идентификатор в отчете СКД отображается в некорректном виде и как это исправить?

При разработке аналитических отчетов в системе компоновки данных (СКД) разработчики прикладных решений на платформе 1С:Предприятие нередко сталкиваются с необходимостью вывода уникального идентификатора (GUID / UUID) ссылочных объектов. Подобная потребность возникает при подготовке данных для интеграции со сторонними информационными системами, сверке справочников между базами данных, аудите системных записей или выгрузке сведений во внешние хранилища. Начиная с версии платформы 8.3.22, в язык запросов и язык выражений СКД была добавлена встроенная функция УникальныйИдентификатор(), позволяющая получать идентификатор непосредственно при выполнении запроса к базе данных без применения ресурсоемких процедур объектной модели встроенного языка.

Однако на практике разработчик может обнаружить, что вместо привычной шестнадцатеричной строки формата 00000000-0000-0000-0000-000000000000 отчет выводит искаженные знаки, внутренние шестнадцатеричные байты, бинарный код или вовсе пустое значение. Чаще всего эта неполадка проявляется в тяжелых отчетах, где текст запроса содержит множество блоков ОБЪЕДИНИТЬ или ОБЪЕДИНИТЬ ВСЕ и насчитывает сотни или тысячи строк. Ниже подробно рассмотрены механизмы платформы, порождающие такое поведение, а также пошаговые способы диагностики и исправления ошибки.

Особенности системного типа УникальныйИдентификатор в платформе 1С

Чтобы понять первопричину искажения данных, необходимо учитывать внутреннюю структуру и правила обработки идентификаторов в платформе 1С:Предприятие:

• Двоичная природа типа: значение типа УникальныйИдентификатор представляет собой 128-битное двоичное число (16 байт). Оно служит уникальным системным ключом объекта в таблицах СУБД. По самому значению идентификатора невозможно определить, к какой именно таблице метаданных относится объект.
• Тип возвращаемого значения: функция языка запросов УникальныйИдентификатор(Ссылка) возвращает объект системного типа УникальныйИдентификатор, а не готовую текстовую строку.
• Ограничения источников данных: параметром функции может выступать исключительно ссылка на объект стандартной таблицы базы данных 1С. Использование ссылок на таблицы внешних источников данных платформой не поддерживается.
• Поведение конструкции ВЫРАЗИТЬ: оператор ВЫРАЗИТЬ в языке запросов 1С служит исключительно для сужения поля составного типа (выделения одного конкретного типа из группы допустимых). Он не осуществляет динамическое преобразование данных одного типа в другой. Попытка применить выражение ВЫРАЗИТЬ(УникальныйИдентификатор(Ссылка) КАК Строка) приводит к ошибке выполнения запроса, так как системный тип УникальныйИдентификатор не преобразуется напрямую в строку через данный оператор.
• Специфика вывода в СКД: система компоновки данных форматирует системные объекты на основании информации о типах, заложенных в схеме. Если схема не содержит однозначных указаний о типе колонки, система пытается вывести данные в сыром внутреннем формате объекта, что выглядит для пользователя как искажение или повреждение данных.

Почему объединения запросов приводят к искажению вывода

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

В процессе выполнения сложных многоуровневых запросов возникают следующие коллизии:

• Смешивание системного типа с другими типами: если в первой ветке запроса поле формируется функцией УникальныйИдентификатор(Ссылка), а во второй или третьей ветке для этой же колонки передается литерал пустой строки "", число 0, ссылка на другой объект или значение NULL, результирующая колонка получает составной или неопределенный тип.
• Отсутствие типизации неиспользуемых полей: в громоздких запросах на тысячи строк разработчики нередко оставляют неиспользуемые в отдельных выборках поля как NULL КАК ПолеИдентификатора без явного приведения типа. В результате СУБД и платформа 1С не могут жестко зафиксировать системный тип колонки.
• Отказ стандартного механизма форматирования СКД: получая на вход набор данных с составным или произвольным типом поля, процессор компоновки данных не может определить, какое представление должно быть сформировано для объекта. Стандартный механизм преобразования объекта типа УникальныйИдентификатор в строковый GUID отключается, и процессор вывода отдает внутреннее представление структуры в памяти.

Пошаговый алгоритм диагностики отчета

Для выявления конкретного места потери типизации рекомендуется выполнить следующую последовательность действий:

1. Проверка описания полей в наборе данных: откройте схему компоновки данных и перейдите на вкладку Наборы данных. В списке полей набора найдите поле, выводящее идентификатор, и проверьте колонку Тип значения. Если тип определен как составной, произвольный или не заполнен вовсе, причина сбоя заключается в неоднородности исходной выборки.
2. Поиск секций объединения: откройте текст запроса и найдите все вхождения операторов ОБЪЕДИНИТЬ и ОБЪЕДИНИТЬ ВСЕ.
3. Сверка позиций полей во всех выборках: проверьте выражение, формирующее поле идентификатора, в каждой ветке запроса. Убедитесь, что в каждой секции на соответствующей позиции стоит строго однородное выражение. Наличие значений NULL, строковых констант или числовых нулей указывает на источник проблемы.
4. Изолированная проверка веток в консоли запросов: если запрос слишком велик, разделите его на отдельные запросы и выполните каждый из них в консоли запросов. Это позволит точно определить, какая из веток отдает некорректный или пустой нетипизированный результат.

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

В зависимости от требований к архитектуре отчета и допустимости изменения текста запроса применяются несколько практических решений.

Способ 1. Получение строкового представления через функцию ПРЕДСТАВЛЕНИЕ в запросе

Наиболее надежный подход, исключающий конфликты системных типов данных при любых объединениях, заключается в преобразовании уникального идентификатора в строку непосредственно в тексте запроса. Для этого применяется встроенная функция ПРЕДСТАВЛЕНИЕ().

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

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
	"" КАК ИдентификаторСтрока
ИЗ
	Справочник.Контрагенты КАК Контрагенты

Условия применения и ограничения: функция ПРЕДСТАВЛЕНИЕ() формирует стандартную 36-символьную строку GUID. В тех ветках объединения, где объект отсутствует, безопасно передается пустая строка "". Поскольку во всех объединяемых выборках колонка имеет строковый тип, СКД корректно отображает значение в отчете. Ограничением метода является то, что результирующее значение становится чистой строкой: его нельзя напрямую использовать в механизмах платформы, ожидающих системный объект УникальныйИдентификатор.

Способ 2. Явное назначение типа на вкладке Наборы данных в СКД

Если в схеме компоновки данных требуется сохранить именно системный тип объекта (например, для программной постобработки или фильтрации), можно жестко зафиксировать тип поля в свойствах набора данных без изменения логики запроса.

1. Откройте схему компоновки данных и выберите нужный набор данных.
2. В списке полей найдите проблемное поле идентификатора.
3. В колонке Тип значения отключите автоопределение и установите точный тип: УникальныйИдентификатор.
4. Если в части объединений поле может принимать пустое значение, убедитесь, что в запросе для пустых значений передается типизированный результат либо обеспечьте корректную обработку через форматную строку.

Условия применения и ограничения: способ эффективен, когда в запросе во всех выборках возвращается либо сам идентификатор, либо NULL. Однако если хотя бы одна из веток объединения вернет значение несовместимого типа (например, число или текст), при формировании отчета произойдет системная ошибка приведения типов.

Способ 3. Настройка выражений представления и вычисляемых полей в СКД

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

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

Условия применения и ограничения: способ универсален и не требует модификации SQL-подобного текста запроса. Небольшим ограничением выступает незначительное увеличение нагрузки на процессор компоновки при обработке сотен тысяч строк.

Способ 4. Архитектурная реорганизация запроса через временные таблицы

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

Порядок рефакторинга:

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

Сравнение способов и практические рекомендации

Выбор оптимального способа устранения ошибки зависит от конкретных задач отчета:

• Использование ПРЕДСТАВЛЕНИЕ(УникальныйИдентификатор(Ссылка)) в запросе: рекомендуется как основной вариант для большинства аналитических отчетов. Он гарантирует корректный вывод данных пользователю, легко объединяется с пустыми строками и не зависит от настроек типов в схеме СКД.
• Явная типизация в наборе данных СКД: предпочтительна в случаях, когда идентификатор используется в дальнейших вычислениях внутри СКД как системный тип данных.
• Выражение представления поля СКД: лучший выбор при необходимости быстро исправить отчет без изменения базового запроса или в типовых конфигурациях, находящихся на официальной поддержке.
• Рефакторинг с разделением на временные таблицы: рекомендуется для сложных комплексных запросов объемом в тысячи строк. Это устраняет не только проблемы с типизацией полей, но и упрощает оптимизацию плана выполнения запроса в СУБД.

Некорректный вид уникального идентификатора в СКД обусловлен потерей строгой типизации данных при объединении разнородных запросов. Преобразование значения к строке через ПРЕДСТАВЛЕНИЕ() либо корректное указание типа поля в наборе данных СКД полностью решает данную проблему и восстанавливает штатный вид идентификатора в отчете.