Уникальный идентификатор (UUID) объекта в 1С 8.3

Идентификатор объекта в 1С — это UUID (он же GUID): 128-битное число, которое платформа присваивает каждому элементу справочника, документу, записи регистра и любому другому ссылочному объекту в момент создания. Выглядит он как 32 шестнадцатеричные цифры, разбитые дефисами на пять групп: a1b2c3d4-e5f6-7890-abcd-ef1234567890.

Этот идентификатор не виден в карточке объекта и не совпадает ни с кодом справочника, ни с номером документа. Он живёт внутри базы и нужен платформе, чтобы однозначно отличать один объект от другого — даже если у них одинаковое наименование, код или дата. Код можно поменять, наименование переписать, а UUID остаётся тем же всю жизнь объекта.

Ниже — что это за число по своей природе, где оно лежит в таблицах базы, как его достать из ссылки и как по нему обратно найти нужный элемент.

Что скрывается за аббревиатурами UUID и GUID

UUID расшифровывается как Universally Unique Identifier — универсально уникальный идентификатор. GUID (Globally Unique Identifier) — то же самое, просто другое название того же стандарта, пришедшее из мира Microsoft. В контексте 1С это синонимы: в документации и на форумах встречаются оба варианта, означают они одно и то же 16-байтное значение.

Главное свойство UUID — практическая уникальность. Алгоритм генерации устроен так, что вероятность получить два одинаковых идентификатора на разных компьютерах и в разное время ничтожно мала. Поэтому платформа может раздавать UUID локально, не спрашивая никакой центральный сервер, и быть уверенной, что совпадений не будет.

В 1С идентификатор присваивается автоматически:

• 📌 новому элементу справочника — при первой записи;
• 📄 документу — при создании, ещё до проведения;
• 🗂️ значению перечисления — на этапе конфигурирования (они фиксированы);
• 🔑 узлу плана обмена, счёту, виду характеристик — так же, при создании.

Строковое представление всегда имеет вид 8-4-4-4-12 символов. В ссылке внутри платформы это же значение хранится в двоичном виде — 16 байт, без дефисов.

Чем идентификатор отличается от кода и от ссылки

Три понятия часто путают, хотя у каждого своя роль.

Код (или номер) — это реквизит, который видит и настраивает пользователь. Код справочника задаётся в свойствах объекта метаданных, у документа это номер. Код можно изменить вручную, он уникален только внутри своего справочника и своей серии нумерации, а не во всей базе. Два разных справочника спокойно содержат элементы с кодом 000000001.

Ссылка — это значение встроенного языка типа СправочникСсылка.Номенклатура, ДокументСсылка.РеализацияТоваровУслуг и т.п. Ссылка — то, чем вы оперируете в коде и чем реквизиты одного объекта указывают на другой. Внутри ссылки как раз и «зашит» UUID плюс информация о типе объекта.

Идентификатор (UUID) — это «ядро» ссылки, то самое неизменное 16-байтное число. Ссылка = тип объекта + идентификатор.

Где идентификатор физически лежит в базе данных

Каждый ссылочный объект хранится в своей таблице СУБД. Справочники — в таблицах с именами вида _Reference123, документы — _Document456, записи независимых регистров сведений — _InfoRg... и так далее. Имена платформа генерирует сама, поэтому напрямую по ним ничего не понять.

В таблице справочника есть служебное поле _IDRRef — это первичный ключ, двоичное поле на 16 байт. Именно в нём лежит идентификатор объекта. Когда один объект ссылается на другой (например, в документе указана номенклатура), в таблице документа хранится поле вида _Fld...RRef с тем же 16-байтным значением — это и есть физическая реализация ссылки.

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

Соответствие = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого Строка Из Соответствие Цикл
    Сообщить(Строка.ИмяТаблицы + " — " + Строка.Метаданные);
КонецЦикла;

В файловом варианте (1Cv8.1CD) принцип тот же, просто таблицы лежат внутри одного файла базы, а не в отдельной СУБД.

Как узнать идентификатор объекта

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

Способ 1. Через встроенный язык (самый точный).

У любой ссылки есть метод УникальныйИдентификатор(), возвращающий значение типа УникальныйИдентификатор. Чтобы получить строку — оберните результат в Строка():

Идентификатор = Ссылка.УникальныйИдентификатор();
СтрокаИД = Строка(Идентификатор);
Сообщить(СтрокаИД); // a1b2c3d4-e5f6-7890-abcd-ef1234567890

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

Способ 2. Через навигационную ссылку.

В интерфейсе «Такси» у открытого объекта или выделенной строки списка есть стандартная команда получения навигационной ссылки (в меню Ещё или через главное меню → Сервис). Платформа покажет внутренний адрес вида:

e1cib/data/Справочник.Номенклатура?ref=a1b2c3d4e5f67890abcdef1234567890

Всё, что стоит после ref= — это и есть идентификатор объекта, только записанный без дефисов, 32 символа подряд. Способ удобен тем, что не требует кода: скопировали ссылку — получили UUID.

Способ 3. Через запрос с выгрузкой в код.

Если нужно собрать идентификаторы по целой выборке, делают запрос, который возвращает поле Ссылка, а затем в цикле обходят результат и вызывают УникальныйИдентификатор() для каждой строки — как в способе 1.

Как по идентификатору найти объект

Обратная задача встречается не реже: есть строка UUID, нужно получить по ней ссылку. Для этого у менеджера каждого справочника и документа есть метод ПолучитьСсылку():

ИД = Новый УникальныйИдентификатор("a1b2c3d4-e5f6-7890-abcd-ef1234567890");
Ссылка = Справочники.Номенклатура.ПолучитьСсылку(ИД);

Чтобы убедиться, что объект реально есть, прочитайте его:

Объект = Ссылка.ПолучитьОбъект();
Если Объект = Неопределено Тогда
    Сообщить("Объекта с таким идентификатором нет в базе");
Иначе
    Сообщить("Нашли: " + Ссылка);
КонецЕсли;

Если вместо строки с дефисами у вас 32 символа подряд из навигационной ссылки — расставьте дефисы по схеме 8-4-4-4-12, иначе конструктор Новый УникальныйИдентификатор(...) не примет значение и выдаст ошибку формата.

Нужен совершенно новый случайный идентификатор (например, для технических целей) — создайте его без параметров:

НовыйИД = Новый УникальныйИдентификатор();

Зачем идентификатор нужен в обмене данными

Идентификатор — это основа синхронизации между базами. Когда настроен обмен (планы обмена, «Синхронизация данных», форматы EnterpriseData, Конвертация данных 2.0/3.0), объекты выгружаются в XML или JSON вместе со своим UUID.

Работает это так:

1. 🔄 При выгрузке каждый объект получает в файле атрибут-ссылку со своим идентификатором.
2. 📥 При загрузке в приёмнике платформа ищет объект по этому же UUID.
3. ✳️ Нашёлся — обновляет существующий; не нашёлся — создаёт новый с тем же идентификатором.

Благодаря этому один и тот же справочник номенклатуры в двух базах «склеивается» в единый объект: изменили цену в одной базе — обмен донесёт правку именно до нужного элемента в другой, не создавая дубль.

Для сопоставления объектов между базами по UUID есть служебные механизмы (регистр соответствия объектов информационных баз). Поэтому при проектировании обмена всегда думают, что считать ключом сопоставления — идентификатор или бизнес-поля вроде ИНН и кода.

Отдельный случай — предопределённые элементы (счета плана счетов, фиксированные значения справочников, заданные в конфигураторе). У них в разных базах идентификаторы, как правило, разные, но есть стабильное имя предопределённого элемента. Именно по этому имени, а не по UUID, их и сопоставляют при обмене и ищут в коде через Справочники.Имя.ИмяПредопределённого. Опираться на идентификатор предопределённого элемента между базами не стоит.

Если UUID нужно сохранить в текст или передать во внешнюю систему, применяют сериализацию:

СтрокаДляОбмена = XMLСтрока(Ссылка.УникальныйИдентификатор());

Функция XMLСтрока возвращает идентификатор в каноническом виде 8-4-4-4-12, пригодном для записи в файл обмена и обратного разбора через XMLЗначение.

Частые проблемы с GUID и как их избежать

Большинство бед с идентификаторами — следствие копирования баз и ручного вмешательства. Разберём по симптомам.

Общее правило: не относитесь к UUID как к бизнес-ключу, одинаковому во всех системах. В каждой базе 1С у «того же самого» контрагента будет свой идентификатор, если базы не связаны обменом. Для сопоставления с внешними учётными системами надёжнее ИНН, артикул или собственный код, а UUID оставьте платформе для её внутренних нужд.

Частые вопросы