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

И вот тут регистр где хранится соответствие УИДа источнка - ссылке приемника - очень даже кстати. Так ведь?

Мэппинг не для того что оно быстрее, а для того когда в источнике значения полей поиска поменялись и ты должен как-то найти этот же объект (еще со старыми значениями полей поиска) в приемнике и обновить

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

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

Ну вот лайт-версия - это сначала поиск по УИДу (вместо отдельного регистра).
Тоже работает во всех старых обменах в типовых, где еще не было БСП.

Но плохо подходит если данные уже параллельно введены в источнике и приемнике

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

Вот именно так у меня сейчас. Базам по 10 лет. И я не уверен что предыдущие "обмены" поддерживали эту уникальность на 100%. А заниматься реверс-инжинирингом... как-то вот совсем неохота.

Обычно даже с сопоставлением нси по двум базам есть большие траблы: нужно сидеть и досконально выверять эти справочники, устанавливая такие соответствия. Вполне допускаю, что там у тебя в одной базе 1 элемент, а во второй - минимум 2 (так любят бухи делать, отдельные папки: товар, материал). Либо еще больше, - это когда в твоей нетленке люди все знают, что есть стол и все, а бухи бьют согласно первичным документам: стол чотама, стол_чотама и т.д. Я припоминаю, я 11 таких находил столов - и это был один и тот же стол. В общем случае, можно поискать по наименованию, лайками - но окончательно всегда эксперт определяет - что там стол, а что не стол.

Сначало делать Поиск по уиду, если не нашли, то по регистр у соответсвий если не нашли то по полям поиска.

Автоматом можно делать записи в регистр, и в следующий раз уже найдёт по регистр у.

А если по УИДу нашел, но по факту это совсем другой элемент - не равный тому что пришел из нетленки. Вот что меня смущает в поисках по УИДу в давно живущих база.

Ну тогда без регистра мэппинга никак. А поиск по УИДу либо вообще не делать и не использовать, либо делать с предварительным анализом его применимости в https://t.me/ssl1c/97565

Я так понимаю, если сделать отдельный поиск по УИДу - то результаты поика нужно человеку предъявить на сличение.

После чего запихнуть в регистр маппинга и забыть об этом.

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

Ибо первое что я собирался сделать - это выгрузить все что уже есть - и сопоставить идентификаторы двух баз между собой.

Вот для этого в обмене на БСП есть интерфейс, чтобы первоначально связать объекты. Т.е. в  интерактивном режиме тебе подскажет, что "этот элемент соответствует вот этому" (по полям), но ты можешь выбрать и другой элемент. Или же руками выбрать, если не нашло по полям, но элемент реально есть (например, лишний пробел в названии поставили).

Собственно таков и был план, когда я начал искать регистр который подойдет по "регистр маппинга"