Как получить гуид объекта в 1с в запросе

В платформе 1С каждый объект метаданных и каждая запись в базе данных имеют глобальный уникальный идентификатор (GUID), который используется на уровне платформы для однозначной идентификации данных. В прикладной разработке GUID особенно важен при интеграциях, синхронизациях между базами, обмене через веб-сервисы и анализе расхождений данных, когда ссылка или код объекта оказываются недостаточными.

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

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

Грамотно построенный запрос на получение GUID позволяет избежать типичных ошибок: лишних соединений, неявных преобразований типов и неконтролируемого роста времени выполнения. В статье рассматриваются практические подходы к извлечению GUID объектов 1С именно на уровне запроса, с акцентом на точность, производительность и предсказуемость результата.

Расположение уникального идентификатора объекта в данных 1С

В платформе 1С уникальный идентификатор объекта (GUID) хранится на уровне данных и не зависит от прикладной логики. Для ссылочных типов (Справочники, Документы, Планы видов характеристик и др.) GUID физически присутствует в таблицах СУБД и используется платформой для однозначной идентификации записи.

В файловом и серверном вариантах хранения каждый объект имеет внутреннее поле _IDRRef (для ссылок) или _RecorderRRef / _OwnerIDRRef (для подчинённых записей). Это бинарное поле длиной 16 байт, соответствующее GUID в формате UUID. Именно оно является первичным идентификатором объекта на уровне СУБД.

В таблицах ссылочных объектов поле _IDRRef присутствует всегда, независимо от конфигурации и состава реквизитов. Например, таблица справочника содержит колонки с пользовательскими данными и служебное поле _IDRRef, которое не отображается в конфигураторе, но доступно в запросах.

В языке запросов 1С GUID напрямую не возвращается в привычном строковом виде. При обращении к ссылке (например, Справочник.Номенклатура.Ссылка) платформа оперирует объектным типом, а не значением идентификатора. Для получения GUID используется обращение к служебному полю через псевдоним таблицы и последующее преобразование.

Для регистров сведений и накопления уникальный идентификатор записи как отдельное поле отсутствует. В этом случае платформа формирует идентификацию записи на основе состава измерений и, при необходимости, поля _RecorderRRef, если регистр подчинён регистратору. Это важно учитывать при попытках сопоставления данных между базами.

При обменах, интеграциях и синхронизации GUID берётся именно из поля _IDRRef, а не из представления ссылки. Поэтому при написании запросов для внешних систем рекомендуется явно извлекать это поле и приводить его к строковому формату, чтобы избежать неоднозначностей при сопоставлении объектов.

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

Использование функции УНИКАЛЬНЫЙИДЕНТИФИКАТОР() в тексте запроса

Функция УНИКАЛЬНЫЙИДЕНТИФИКАТОР() в языке запросов 1С применяется для явного приведения значения к типу «УникальныйИдентификатор». Это особенно важно при работе с GUID, полученными из внешних источников, временных таблиц или параметров запроса, где тип данных изначально не определён однозначно.

На практике функция используется в секции ВЫБРАТЬ, УСЛОВИЯХ и при соединении таблиц. Например, при сравнении значения строкового типа с полем, содержащим GUID объекта, без явного приведения запрос не выполнится или вернёт пустой результат. Применение УНИКАЛЬНЫЙИДЕНТИФИКАТОР() устраняет эту проблему за счёт строгой типизации.

При передаче GUID через параметр запроса рекомендуется заранее гарантировать корректный формат строки (32 символа без фигурных скобок). В тексте запроса параметр следует оборачивать функцией УНИКАЛЬНЫЙИДЕНТИФИКАТОР(), чтобы обеспечить корректное сравнение с полями типа ССЫЛКА или УникальныйИдентификатор, особенно при работе с регистрами сведений и независимыми таблицами значений.

В соединениях (JOIN) функция полезна при связывании данных, где одна из сторон формируется динамически. Например, при соединении временной таблицы, содержащей GUID в виде строки, с основной таблицей метаданных использование УНИКАЛЬНЫЙИДЕНТИФИКАТОР() позволяет избежать неявных преобразований и снижает риск ошибок выполнения.

Не рекомендуется применять функцию к полям, которые уже имеют тип УникальныйИдентификатор или ССЫЛКА. Избыточное приведение ухудшает читаемость запроса и может негативно сказаться на оптимизации. Оптимальный подход – использовать УНИКАЛЬНЫЙИДЕНТИФИКАТОР() только на входных значениях, тип которых не гарантирован.

При отладке запросов с GUID стоит отдельно проверять результат выражений с УНИКАЛЬНЫЙИДЕНТИФИКАТОР(), так как ошибка формата входного значения приводит к ошибке выполнения запроса, а не к пустому результату. Это упрощает выявление некорректных данных на раннем этапе.

Получение GUID для ссылок справочников и документов

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

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

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

В запросах рекомендуется явно указывать тип УникальныйИдентификатор, чтобы избежать неявных преобразований и потери производительности. Полученное значение GUID можно использовать для сопоставления данных между базами, хранения внешних ключей или формирования универсальных идентификаторов при обмене.

Важно учитывать, что GUID ссылки остаётся неизменным на протяжении всего жизненного цикла объекта, включая изменения реквизитов, перепроведение документов и изменение иерархии. Это делает его предпочтительным выбором по сравнению с кодами и номерами при построении устойчивых связей.

При массовой выборке GUID для справочников и документов рекомендуется ограничивать набор полей только ссылкой и необходимыми реквизитами. Это снижает нагрузку на СУБД и ускоряет выполнение запроса, особенно при работе с большими объёмами данных.

Извлечение GUID по отбору на реквизиты или код объекта

GUID объекта в 1С однозначно соответствует его ссылке. В запросах GUID извлекается через функцию УникальныйИдентификатор(Ссылка), поэтому ключевая задача – корректно получить саму ссылку по заданному отбору.

При поиске по коду справочника используйте точное равенство по реквизиту Код и ограничение результата. Это снижает нагрузку и исключает неоднозначность: добавляйте условие ВЫБРАТЬ ПЕРВЫЕ 1 и обязательно проверяйте, что код уникален в конфигурации.

Для отбора по пользовательским реквизитам применяйте параметры запроса и явные условия равенства. Отборы с LIKE и приведение типов ухудшают использование индексов и замедляют выполнение, особенно на больших объемах данных.

Всегда учитывайте системные признаки: ПометкаУдаления = ЛОЖЬ позволяет избежать получения GUID логически удаленных объектов; для иерархических справочников при необходимости добавляйте отбор по Родитель или ИсключитьПодчиненные.

Для документов отбор по Номер и Дата должен быть совместным. Один номер без даты может повторяться. При наличии периодичности используйте диапазон дат, а затем извлекайте ссылку и GUID через УникальныйИдентификатор(Ссылка).

Если реквизит не индексирован, а поиск выполняется часто, целесообразно добавить индекс на уровне конфигурации. Это существенно ускоряет получение GUID без изменения логики запроса.

В интеграционных сценариях фиксируйте правило уникальности отбора: если запрос потенциально возвращает несколько строк, выбирайте бизнес-правило приоритета (актуальность, дата создания) до извлечения GUID, а не после.

Передача GUID из результата запроса в прикладной код 1С

GUID, полученный в запросе, всегда возвращается в строго определённом типе данных, и корректная передача его в прикладной код зависит от способа выборки и дальнейшей обработки результата. На уровне запроса GUID формируется как УникальныйИдентификатор, а в коде 1С должен быть принят без неявных преобразований.

При использовании объекта Запрос ключевым моментом является чтение результата через Выборку. Значение GUID доступно напрямую как поле результата, без дополнительных преобразований в строку или бинарный формат.

• GUID передаётся в код как тип УникальныйИдентификатор, если поле запроса имеет соответствующий тип.
• При чтении через Выборка.Выбрать() доступ к GUID осуществляется как к обычному свойству строки результата.
• Дополнительное преобразование требуется только при передаче GUID во внешние системы или при сериализации.

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

• Для сохранения GUID в переменной: используйте прямое присваивание значения поля результата.
• Для передачи GUID в параметры другого запроса: передавайте значение как есть, без Формат() и Строка().
• Для сравнения GUID: сравнивайте значения типа УникальныйИдентификатор, а не их строковые представления.

При работе с менеджерами объектов GUID из результата запроса можно напрямую использовать для получения ссылки, если GUID относится к ссылочному типу. В этом случае отсутствует необходимость повторного запроса к базе.

1. Получить GUID из результата запроса.
2. Передать GUID в прикладную логику как УникальныйИдентификатор.
3. Использовать GUID для поиска, сравнения или восстановления ссылки.

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

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

Ограничением является невозможность прямого получения GUID для ссылочных полей через произвольные SQL-подобные конструкции. GUID доступен только через системные поля, такие как Ссылка или УникальныйИдентификатор, и только в рамках поддерживаемого синтаксиса языка запросов 1С.

Распространённая ошибка – использование GUID объекта другого типа метаданных. GUID справочника, документа и регистра могут совпадать по формату, но не по контексту. Сравнение GUID разных типов всегда возвращает пустой набор, даже если визуально значения идентичны.

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

Запросы с фильтрацией по GUID плохо оптимизируются при отсутствии индексов на системных полях. В больших информационных базах это приводит к значительному снижению производительности, особенно при использовании GUID в условиях ИЛИ или подзапросах.

Использование GUID оправдано только для идентификации объектов без необходимости доступа к их данным. Во всех остальных случаях предпочтительнее работать со ссылками, так как они сохраняют тип, оптимизируются системой и корректно обрабатываются механизмом запросов 1С.

Вопрос-ответ:

Зачем вообще получать GUID объекта через запрос, если в 1С уже есть ссылка на объект?

Ссылка подходит для работы внутри одной базы, но при обменах, синхронизации или хранении данных вне 1С она теряет смысл. GUID позволяет однозначно распознать объект между разными базами и внешними системами. Через запрос его удобно получать массово — например, для списка элементов справочника или документов за период, без перебора объектов в цикле.

Какой реквизит таблицы запроса содержит GUID и всегда ли он доступен?

GUID хранится в поле УникальныйИдентификатор. Оно есть у объектов метаданных, которые поддерживают уникальные идентификаторы: справочники, документы, планы видов характеристик и другие. Если объект создан давно, идентификатор всё равно присутствует — он формируется автоматически платформой и не зависит от даты создания.

Почему в результате запроса GUID приходит в бинарном виде, а не строкой?

Платформа возвращает уникальный идентификатор как значение типа УникальныйИдентификатор. Для вывода или передачи его обычно преобразуют в строку средствами языка 1С. Такое поведение связано с тем, что бинарный формат удобнее для внутренних операций и сравнений, а строковое представление нужно уже на прикладном уровне.

Можно ли получить GUID по ссылке, переданной в параметрах запроса?

Да, ссылка спокойно используется как параметр. В тексте запроса её можно выбрать и обратиться к полю УникальныйИдентификатор. Такой подход часто применяют, когда есть ссылка из формы или внешней обработки, а нужен именно GUID для записи в регистр сведений или передачи наружу.

Есть ли отличия при получении GUID у объектов разных типов, например документа и элемента справочника?

С точки зрения запроса отличий почти нет: поле называется одинаково и выбирается схожим образом. Разница появляется на уровне таблицы источника — для документов используется таблица документов, для справочников таблица соответствующего справочника. Сам GUID при этом ведёт себя одинаково и сравнивается без дополнительных преобразований.

Почему при получении GUID объекта через запрос в 1С я вижу одно значение, а при обращении к тому же объекту из кода — другое?

Такое поведение обычно связано с тем, что в запросе используется ссылка на объект метаданных, а в коде — уже сам объект, полученный по этой ссылке. В 1С GUID хранится на уровне ссылки, и именно он возвращается при запросе к полю типа «СправочникСсылка», «ДокументСсылка» и т.п. Если же в коде был создан новый объект или выполнено копирование, GUID у него будет отличаться, несмотря на совпадение реквизитов. Также расхождение возможно, если GUID берётся из разных источников: например, в запросе используется поле Ссылка, а в коде вызывается метод УникальныйИдентификатор() у другого экземпляра объекта. Для совпадения значений нужно получать GUID из одного и того же представления объекта — либо всегда работать со ссылкой, либо явно передавать её между запросом и кодом.