При разработке интеграций, особенно при взаимодействии 1С с внешними скриптами на Python или системами искусственного интеллекта, часто возникает задача поиска конкретного объекта в базе данных, имея на руках только его текстовое представление — Уникальный Идентификатор (GUID/УИД). В этой статье мы подробно разберем, какие возможности предоставляют современные версии платформы «1С:Предприятие 8.3», какие ограничения до сих пор сохраняются в языке запросов и как обойти сложности, если у вас есть возможность передавать только текст запроса.
Начнем с позитивных изменений. Начиная с версии платформы 8.3.22, разработчики получили долгожданную встроенную функцию языка запросов — УНИКАЛЬНЫЙИДЕНТИФИКАТОР(). С ее помощью можно реализовать в том числе массовый поиск объектов по УИН. Рассмотрим подробнее, как она работает и что она возвращает. Проанализируем типичный пример ее использования:
ВЫБРАТЬ
Номенклатура.Ссылка КАК Ссылка,
УНИКАЛЬНЫЙИДЕНТИФИКАТОР(Номенклатура.Ссылка) КАК УИД
ИЗ
Справочник.Номенклатура КАК Номенклатура
ГДЕ
УНИКАЛЬНЫЙИДЕНТИФИКАТОР(Номенклатура.Ссылка) = &ПараметрУИД
Важно понимать: результатом работы функции УНИКАЛЬНЫЙИДЕНТИФИКАТОР() является значение специального типа УникальныйИдентификатор, а не строка. Именно здесь кроется главная проблема для сценариев, где в текст запроса нужно «жестко» прописать GUID в виде строки.
Выясним причину, по которой конструкция типа УНИКАЛЬНЫЙИДЕНТИФИКАТОР(Ссылка) = "b115b076-8636-11e2..." не будет работать. В языке запросов 1С, в отличие от некоторых диалектов SQL (например, T-SQL или PostgreSQL), отсутствуют литералы для типа GUID. Вы не можете написать идентификатор текстом прямо в теле запроса так, чтобы платформа восприняла его как объект. Попытка сравнения типа УникальныйИдентификатор со значением типа Строка приведет к ошибке несовместимости типов данных.
Многие разработчики пытаются использовать функцию ПОДСТРОКА() или ПРЕДСТАВЛЕНИЕ(), чтобы привести GUID к строке и сравнить его. Однако стоит помнить:
ПРЕДСТАВЛЕНИЕ() в 1С возвращает тип, который нельзя использовать в секции ГДЕ для фильтрации (в таких случаях для анализа зависимостей лучше использовать специализированные инструменты — для этого подойдёт универсальная консоль запросов и кода 1С).ПОДСТРОКА() работает только со строками, а УникальныйИдентификатор в базе данных хранится в двоичном виде.Если ваша задача выполняется внутри кода 1С, наиболее правильным и быстрым способом будет предварительное получение ссылки из строки GUID (что также помогает найти и заменять битые ссылки — для этого есть поиск и удаление битых ссылок в 1С) и передача этой ссылки в качестве параметра запроса. Рассмотрим этот алгоритм:
// Предположим, у нас есть строка с GUID
ТекстGUID = "b115b076-8636-11e2-9373-001b11b25590";
УИД_Объекта = Новый УникальныйИдентификатор(ТекстGUID);
// Получаем ссылку (например, для справочника Номенклатура)
СсылкаНаОбъект = Справочники.Номенклатура.ПолучитьСсылку(УИД_Объекта);
// Передаем ссылку в запрос
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Номенклатура.Наименование
|ИЗ
| Справочник.Номенклатура КАК Номенклатура
|ГДЕ
| Номенклатура.Ссылка = &СсылкаНаОбъект";
Запрос.УстановитьПараметр("СсылкаНаОбъект", СсылкаНаОбъект);
Результат = Запрос.Выполнить();
Этот метод является максимально производительным, так как поиск в базе данных будет осуществляться по индексу (Primary Key), что происходит мгновенно даже в таблицах с миллионами записей.
В ситуациях, когда внешний скрипт (например, на Python) взаимодействует с 1С через HTTP, использование чистого языка запросов может быть неудобным из-за ограничений на передачу параметров — в таких сценариях пригодится инструмент анализа производительности HTTP-запросов и API. В этом случае проанализируем возможность использования OData (REST API 1С). Интерфейс OData штатно поддерживает фильтрацию по GUID прямо в URL запроса.
Пример обращения к объекту через OData выглядит так:
http://server/base/odata/standard.odata/Document_ВедомостьНаВыплатуЗарплаты(guid'b115b076-8636-11e2-9373-001b11b25590')
Такой подход полностью снимает проблему формирования текста запроса и преобразования типов, так как платформа сама берет на себя поиск объекта по его уникальному идентификатору.
Если вы ограничены использованием собственного HTTP-сервиса, который принимает только текст запроса, и при этом ИИ или скрипт генерирует этот текст динамически, можно применить стратегию маркеров. Разберем этот метод по шагам:
ГДЕ Ссылка = #GUID_b115b076...#.#GUID_...#.&ПараметрУИД) и программно устанавливаем значение этого параметра в объекте Запрос, предварительно преобразовав найденную строку в Новый УникальныйИдентификатор().Нужно учитывать, что использование функции УНИКАЛЬНЫЙИДЕНТИФИКАТОР(Ссылка) в условии ГДЕ часто приводит к тому, что СУБД (MS SQL Server, PostgreSQL) не может использовать индекс по полю Ссылка. Вместо эффективного Index Seek (поиск по индексу) может произойти Index Scan (сканирование всего индекса), что значительно медленнее.
Поэтому всегда, когда это возможно, стремитесь передавать в параметр запроса саму Ссылку, а не объект типа УникальныйИдентификатор. Платформа 1С оптимизирована именно под работу со ссылочными типами данных в запросах.
Подведем итог: полноценный поиск «по строке» прямо внутри текста запроса в 1С реализовать нельзя из-за отсутствия типизированных литералов. Однако, используя функцию УНИКАЛЬНЫЙИДЕНТИФИКАТОР() (в версиях 8.3.22+), правильную работу с параметрами или интерфейс OData, можно эффективно решать любые задачи по поиску объектов по их GUID.