Всем доброго дня!
Тема вроде много раз обсуждалась, но абсолютной уверенности я не имею. Достаточно ли в 8.3 уникальности GUID в пределах вида метаданных? Всегда считал, что достаточно, но в глубине души это не нравится и вызывает некоторое беспокойство ) И вот реальный случай, делаю выгрузку из УСН 7.7 в БП3 и Справочник.Контрагенты из 7.7 может мигрировать в справочники "Контрагенты" и "ФизическиеЛица" БП3. Оставить при обмене один
исходный (сгенерированный в 7.7) GUID, полагаясь на достаточность уникальности в пределах вида или заморочиться и ввести дополнительный признак при выгрузке?

а как эти GUID выглядят? 36 знаков? если да, то они достаточно уникальны, чтобы ни с чем не совпасть на планете.

(1)как положено - 36. Генерирую с помощью 1с++

(0)

Документ "ПередачаТоваровМеждуОрганизациями" с  GUID_1 из УТ приходит в БП и превращается в два документа "ПТУ" и "РТУ" с тем же самым GUID_1
Партнер и контрагент может иметь один GUID (так же смотри обмены)

И т.д. и т.п.

Это типовой код.

(3)Спасибо

Склоняюсь к тому, что использование ключа сущности как ключа миграции - неверное решение. Мухи отдельно, котлеты отдельно. В типовых теперь используется РС ПубличныеИдентификаторыСинхронизируемыхОбъектов.

(5) ну так это для ручного сопоставления, а когда делаешь перенос в пустую базу, там нечему храниться.

(5)и что конкретно это меняет в моем случае? Что использовать как ключ миграции?

Мой идентификатор задвоится в этом регистре сведений

(6) (7) Ключ миграции генерируется при первой миграции. Сопоставление хранится как в базе источнике, так и в приемнике.
Примеры:
1. в источнике Номенклатура может использовать Характеристики, но не на все товары. В приемнике требуется получать отдельную номенклатуру под каждую характеристику, если она есть.
2. в источнике документы приходный и расходный кассовый ордер должны мигрировать в приемник в один вид документа - кассовая операция.

(9)я так понимаю, что в этих случаях предполагается двусторонний обмен, ну хотя бы регистрация ответа в какой-либо форме?

(10) ответы безусловно требуются, иначе источник просто не будет знать получены ли данные в приемнике. Но это при любом регулярном обмене требуется

(0) " the probability to find a duplicate within 103 trillion version-4 UUIDs is one in a billion."
https://en.wikipedia.org/wiki/Universally_unique_identifier
если вероятность в одну миллиардную встретить дубль среди 100 триллионов уидов слишком высока - конечно делайте доп проверки.

(11)Про безусловно не соглашусь. У меня много лет эксплуатируются односторонние обмены с тупой выгрузкой за период (всех или помеченных видов и конкретных документов). И источник совсем не страдает от незнания все-ли в приемнике загрузилось или нет.
Но регистр сведений может устранить в принципе вопрос темы, если немного переделать загрузку данных. Тогда UID в приемнике будут только собственные
(12)Вопрос не про совпадение uid на планете. Вопрос про последствия совпадения (которое заведомо будет) при выгрузке одного справочника в 2 разных

(13) На уровне платформы никаких последствий нет, если ты про это. А на уровне прикладного кода последствия возможны (но маловероятны), и больше зависят от твоего творчества.

(13) "с тупой выгрузкой за период" - закат вручную? Если работает - почему нет

(14)ну возможная прикладная кривизна вся на моей совести ) Подобные обмены давно работают. Но тут надо догрузить документы из УСН 7.7, основной обмен с торговлей 7.7
В этом тоже была определенная сложность.

(0) УИД не уникален в пределе страны.  :)

+ (0) Ознакомьтесь, у вас меньше будут вопросов :)

Получение даты и времени создания объекта (по УИД)
https://infostart.ru/public/337631/

(16) главное, не делать одинаковый уид на справочниках партнер и контрагент. обычно связь делается через что-то одно, например, контрагент. хуже, когда в уид зашит вид справочника. я такое постоянно вижу в 1С.

(19)UID генерируется внешней компонентой. Правильность на их совести. У меня контрагенты мигрируют в контрагенты и в физические лица. Так уж устроены типовые базы УСН и БП3
Без дополнительных телодвижений один uid будет и в контрагентах и в физических лицах. Обмен  почти разовый, чтобы из УСН догрузить ручные документы, в ней еще полно импортных из торговли. В принципе если использовать упомянутый регистр сведений, то можно вообще избежать этой проблемы.  Но переделывать не хочется.

(20) проблем с одинаковым УИД в разных справочниках быть не должно.

Всем большое спасибо и хорошего дня!

(21) по ссылке-уиду потом открыться может не то, что нужно ) ну и при повторной синхронизации по уидам

(23) Нет "ссылки-уид", есть УИД и есть ссылка (УИД+тип)

(23)Все прекрасно откроется и открывается хоть после первой, хоть после 1001 синхронизации )