Может ли платформа 1С повторно присвоить GUID удаленного объекта?

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

Штатное поведение платформы и алгоритмы генерации GUID

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

Платформа 1С использует специализированные алгоритмы для формирования уникальных идентификаторов:

1. Модифицированный UUID версии 1: при автоматическом создании новых элементов в информационной базе платформа формирует УИД на основе системного времени и последовательного инкремента. Значения идентификаторов в рамках одной сессии строго возрастают, что минимизирует фрагментацию кластерных индексов в СУБД (MS SQL Server, PostgreSQL). Так как временная метка непременно движется вперед, новый GUID никогда не совпадет с ранее созданными.
2. UUID версии 4: при явном программном вызове функции Новый УникальныйИдентификатор() генерация происходит на основе псевдослучайных чисел. Длина GUID составляет 128 бит (2¹²⁸ возможных комбинаций), поэтому математическая вероятность случайного совпадения двух идентификаторов исчезающе мала.

В информационной базе 1С отсутствует какая-либо таблица «б/у идентификаторов» для их повторной утилизации. Каждому новому объекту всегда выделяется абсолютно новый GUID.

Исключительные случаи: когда GUID может продублироваться

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

Разберем основные причины возникновения коллизий:

1. Программный обмен данными (РИБ, XML, JSON, Web-сервисы): при синхронизации данных стороннее приложение или обработка обмена может явно передать записанный ранее УИД. Если объект с таким GUID был удален в одной базе, но передан из другой, платформа запишет новый элемент с зафиксированным идентификатором.
2. Использование метода УстановитьСсылкуНового(): разработчик может явно задать ссылку перед первой записью объекта в базу. Посмотрим на пример кода:

УИДСтарый = Новый УникальныйИдентификатор("12345678-1234-1234-1234-123456789abc");
СсылкаНового = Справочники.Контрагенты.ПолучитьСсылку(УИДСтарый);

НовыйЭлемент = Справочники.Контрагенты.СоздатьЭлемент();
НовыйЭлемент.УстановитьСсылкуНового(СсылкаНового);
НовыйЭлемент.Наименование = "Новый контрагент";
НовыйЭлемент.Записать();

Если разработчик вручную передаст в метод ПолучитьСсылку() GUID ранее удаленного элемента, система применит именно его.

3. Клонирование виртуальных машин и откат времени: если сервер 1С развернут на виртуальной машине и происходит откат к предыдущему снимку (снапшоту) или сбой системного времени назад, генератор UUID v1 может выдать уже использованную ранее последовательность.
4. Загрузка данных из внешних систем: при интеграции с внешними СУБД или сервисами, где алгоритмы формирования GUID реализованы некорректно или используют фиксированный шаблон.

Как предотвратить и исправить коллизии уникальных идентификаторов

Выясним, какие правила следует соблюдать при разработке и администрировании, чтобы избежать проблем с дублированием ссылок:

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

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