Guid что это такое в 1с

Программирование 1С 8.х для начинающих

• Вы здесь:  
• Уникальный идентификатор

Общие вопросы

Уникальный идентификатор

•  Печать 
• E-mail

Уникальный идентификатор (GUID)

Если Вам встречались в базе записи «<Объект не найден>», то значит настала пора познакомитсья с Уникальным идентификатором .

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

de80b7c8-aa22-11dc-a0f4-0011d85708ff

Т.е. это набор из 32 шестнадцатеричных цифр разделенных дефисами.

Надпись <Объект не найден> появляется в базе когда есть ссылка(уникальный идентификатор) на объект, а объекта в базе нет. Такое может возникнуть или при удалении объектов без проврки ссылочной целостности или при обмене между базами.

Разберем для примера надпись: <Объект не найден> (36:9c4e0022642fda9811e10393c0d776fd)

Для начала узнаем какой тип объекта был удален, для этого используем метод ПолучитьСтруктуруХраненияБазыДанных(), он возвращает таблицу значений(по умолчанию в формате SDBL) где указано соответсвие внутренних идентификаторов и объектов метаданных.

Например можно написать такой код:

В ней мы находим идентификатор который в конце содержит 36 (цифры до двоеточия), но только не в составе числа( Document2836 ), а точное соответсвие. В нашем случае это следующая строка:

Reference36

Справочник.Номенклатура

Значит удаленный элемент был элементом справочника «Номенклатура».

Как Вы заметили внутри скобок находится тип объекта и уникальный идентификатор строкой.

Теперь мы можем на одной из архивных копий найти удаленный элемент, добавив дефисы в имеющуюся у нас строку идентификтора:

Зная все значения полей мы можем вручную или с помощью обработок воссоздать удаленный элемент, но у них будет одно главное отличие — разные Уникальные идентификаторы. А если мы хотим восстановить элемент, то и идентификатор нужно восстановить тот же. Для этого нужно использовать метод «УстановитьСсылкуНового«, например так:

Механизм сопоставления данных при обмене через универсальный формат

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

Для решения этой задачи как раз и предназначен механизм сопоставления данных.

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

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

В некоторых случаях данные не могут быть сопоставлены по GUID по причине его отсутствия (особые случаи, которые не рассматриваются в данной статье).

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

Узел информационной базы ПланОбменаСсылка Ссылка на узел плана обмена (настройку обмена), для которой хранится соответствие. Ссылка

СправочникСсылка,
ПланВидовХарактеристикСсылка,
ДокументСсылка Ссылка на объект текущего приложения. Идентификатор Строка (36) GUID объекта, полученного от приложения-корреспондента.

При получении данных записи в регистре могут появляться на нескольких этапах (см. рисунок 1). Подробное описание самих алгоритмов сопоставления см. далее.

Рисунок 1. Этапы, на которых могут быть сделаны записи в РПИ

Этапы, помеченные пунктиром, опциональные: при выполнении сеанса обмена в автоматическом режиме отсутствуют этапы 1 и 2, при выполнении в интерактивном режиме этап 2 может быть пропущен пользователем.

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

В процессе обмена данные РПИ обеспечивают следующую функциональность:

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

Рисунок 2. Использование данных РПИ при получении и при отправке данных.

Прикладная логика, определяющая порядок автоматического сопоставления объектов при получении, содержится в правилах конвертации объектов (ПКО), предназначенных для получения данных.

Все компоненты (правила обработки данных, правила конвертации объектов и т.д.), определяющие прикладную логику обработки данных в процессе их получения, либо отправки (подробнее в статье Методика работы с конфигурацией «Конвертация данных 3.0» ) формируют так называемый менеджер обмена . Код менеджера обмена разрабатывается в общем модуле (подробное описание см. в документации по БСП , в разделе Обмен через универсальный формат ). Модуль создается автоматически с помощью КД3.0 на основе настроенных правил обмена либо вручную в конфигураторе (см. пример — общий модуль _ДемоМенеджерОбменаЧерезУниверсальныйФормат демо-конфигурации БСП ).

Вариант автоматического сопоставления (идентификации) объектов при получении задается с помощью свойства ВариантИдентификации ПКО и может принимать одно из трех значений:

1. ПоУникальномуИдентификатору — идентификация по GUID,
2. СначалаПоУникальномуИдентификаторуПотомПоПолямПоиска — идентификация по GUID и полям поиска,
3. ПоПолямПоиска — идентификация по полям поиска,

Еще одним свойством, определяющим логику сопоставления, является массив полей поиска, определяемый в свойстве ПоляПоиска ПКО.

Рисунок 3. Настройки идентификации в модуле менеджера и в КД3.0.

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

Этап анализа данных (при загрузке через помощник синхронизации данных)

Ручное сопоставление (при загрузке через помощник синхронизации данных)

Идентификация по РПИ .

Идентификация по GUID.

Запись соответствий в РПИ: делается, если соответствие нашлось при выполнении п.3.

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

Запись соответствий в РПИ: делается по результатам сопоставления.

Идентификация по РПИ .

Идентификация по GUID среди объектов, отсутствующих в РПИ .

Запись соответствий в РПИ: делается для либо с исходным GUID, либо с вновь сгенерированным, п. 1 не дал результата но объект с таким GUID уже есть в РПИ .

По GUID и полям поиска

Аналогично варианту «По GUID».

Идентификация по РПИ .

Идентификация по GUID.

Запись соответствий в РПИ: см. выше.

По полям поиска

См. колонку «Загрузка данных»

Функция ручного сопоставления недоступна.

Запись соответствий в РПИ: не делаются.

Таблица 1. Правила работы настроек идентификации.

Происходит последовательное применение вариантов поиска, заданных в свойстве ПоляПоиска ПКО, используемого при загрузке объекта.

Ограничение.
При сопоставлении на этапе анализа данных применяется только 1-й вариант поиска.

Переход к следующему варианту осуществляется в двух случаях:

1. У загружаемого объекта не заполнено какое-либо из полей, которое указано в варианте поиска.
2. Вариант поиска не дал результата.

Если в загружаемом объекте есть информация об исходном GUID и вариант идентификации для объекта «По GUID» или «По GUID и полям поиска», то поиск выполняется среди всех объектов заданного типа, кроме тех, для которых в РПИ уже установлены соответствия.

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

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

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

Особенность.
На этапе загрузки данных вариант поиска Номер + Дата для документов работает следующим образом: номер искомого документа проверяется на точное соответствие, дата определяет интервал, в котором проводится поиск по номеру. Сам интервал определяется как период уникальности номеров документа, в который входит указанная дата. Например, если номера документов уникальны в пределах месяца и задана дата 10 декабря 2001 года, то поиск будет проводиться в интервале с 01 по 31 декабря 2001 года.
На этапе анализа данных этот вариант поиска будет работать как обычно: оба поля будут проверяться на точное соответствие.

Как получить уникальный идентификатор GUID в 1С

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

В Базе данных для каждого объекта предназначен свой глобальный уникальный идентификатор — GUID (Globally Unique Identifier). Он представляет из себя ссылку из 32 символов, разделенных дефисами, которая состоит из 16 октетов. В первой части содержится время генерации уникального идентификатора, во второй – счетчик и MAC-адрес. Отсчет времени для генерации кода Guid идет с 15 октября 1582 года с интервалом на 100 наносекунд.

Вот так выглядит GUID БД 1С: 3de72ee8-f8b2-11e4-92f1-0050568b35ac

Его UUID можно получить по ссылке.

e1cib/data/Документ.ПриходныйОрдерНаТовары?ref=92f10050568b35ac11e4f8b23de72ee8

Это зеркальное отражение уникального идентификатора в 1С 8.3.

Совпадений разных объектов одной базы крайне малы, т.к. общее количество сгенерированных ключей составляет (2128 или 3,402 * 10в38).

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

2. Чем отличается GUID от UUID?

UUID – универсально-уникальный идентификатор по данным всемирной организации стандартизации версии RFC4122. Этот термин используется в спецификациях протокола Windows как синоним GUID в 1С. Он должен быть полностью технически совместим с RFC4122. Из рекомендаций Международного стандарта «Все стандарты UUID, соответствующие этой Рекомендации, должны иметь биты варианта с битом 7 октета 7, установленным в 1 и бит 6 октета 7, установленным в 0».

3. Как получить уникальный идентификатор зная UUID в 1С

Итак, как же получить GUID зная UUID в 1С?

В конструкторе запроса необходимо создать запрос:

СправочникСсылка=Справочники.ИмяСправочника.НайтиПоНаименованию(«Наименование»);
GUID=СправочникСсылка.УникальныйИдентификатор()

Для установления соответствия объектов разных БД используется GUID.

Необходимо указать узел обмена и тип объекта (склад, договор, контрагент и т.д.). В «источнике» базы данных нужно указать объект, с которым будет устанавливаться соответствие с объектом из «приемника» БД.

УИД или уникальный идентификатор

УИД это определенное значение, однозначно идентифицирующее объект ссылочного типа данных, другими словами, это и есть ссылка уникальная в рамках одной конкретно взятой таблицы, например у справочника номенклатура. УИД есть у любого объекта имеющего ссылочный тип данных, из синтаксис помощника следует, что УИД имеет следующий вид: "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX", где Х — символы обозначающие шестнадцатеричное число. Прочитать какой текущий уникальный идентификатор существует у ссылки можно с помощью метода УникальныйИдентификатор() например:

Использование своего УИД при создании объекта

Изменить УИД у существующего объекта, штатными средствами встроенного языка нельзя. Зато можно при создании нового объекта указать свой УИД. Для этого нужно сделать несколько действий:

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