Коллеги, добрый вечер. Натолкните на мысль.

Я занимаюсь загрузкой справочников из внешней системы (SaaS). У меня есть элемент справочника во внешней системе с ИД например "1675". Соответственно при загрузке элемента я хочу собственноручно формировать для него уникальный идентификатор в 1С и присваивать его исходя из ИД внешней системы, чтоб если я вдруг его удалил из справочника 1С и затем загрузил обратно, у него сформировался абсолютно тот же уникальный идентификатор (чтоб избежать Объект не найден). Как бы Вы решали подобную задачу ?

Я как-то криво объяснил условие задачи, могу попробовать объяснить на примерах, чего хочу добиться.

Если ИД реально короткий, то можно захардкодить типа

ИД = "1234";
уи = Новый УникальныйИдентификатор("066f6492-9c9e-43e4-abb4-435f38e2" + ИД);
Сообщить(уи);

Коллеги, добрый вечер. Натолкните на мысль.

Я занимаюсь загрузкой справочников из внешней системы (SaaS). У меня есть элемент справочника во внешней системе с ИД например "1675". Соответственно при загрузке элемента я хочу собственноручно формировать для него уникальный идентификатор в 1С и присваивать его исходя из ИД внешней системы, чтоб если я вдруг его удалил из справочника 1С и затем загрузил обратно, у него сформировался абсолютно тот же уникальный идентификатор (чтоб избежать Объект не найден). Как бы Вы решали подобную задачу ?

Я как-то криво объяснил условие задачи, могу попробовать объяснить на примерах, чего хочу добиться.

Я понимаю, но наверняка из строки можно например как нибудь расчитать хэшсумму, которую успешно с конвертировать в ГУИД как вариант

1. Это очень плохая идея. Так как глобальный уникальный идентификатор становится локальным уникальным идентификатором.
Алгоритмы (как платформы, так и БСП на это не рассчитаны).
2. В целом это неправильный подход. Правильно:
- либо один раз создать ГУИД в центральной системе SaaS точно по тем же правилам, что в 1С:Предприятии (не помню, чтобы эти правила были документированы), хранить его постоянно и отправлять этот ГУИД в остальные системы при обмене;
- либо делать сопоставление при загрузке (впервые загруженный элемент отмечается в регистре в виде пары Код, новый ГУИД).

Да нормальный подход. Чо там может сломаться то? Ну стал уид ууидом, а не гуидом, и чо? Какой алгоритм в БСП или в платформе от этого начнет работать неверно?
А вот с РСом можно сделать херню и за значительно большее время

Например, ГУИД, созданный системой при автоматическом добавлении служебного пользователя совпадет с существующим.

Да и вообще, если сам zeegin сказал, что так можно делать, значит любая неправильная работа в БСП и в платформе означает, что там есть косяк.

Какова вероятность?