Есть элемент справочника Организации можно ему сделать новый УИН как для  нового?

Только у нового можно УИД поставить. Или запросами прямыми. По сути конечно и в файловой можно, но нужно знать как

а поменять УИД между старым и Новым?

Средствами 1с нельзя

нельзя поменять у существующего уже.
зачем?

(2) Что бы значил твой вопрос?

Создать новый с заданным уидом и подменить им старый во всех ссылках на него.

НовыйОбъект = СтарыйОбъект.Скопировать();
НовыйОбъект.Записать();
СтарыйОбъект.Удалить();

Вот тебе замена ссылки у существующего

Сделай новую организацию и ссылки перебрось

Задачу объясни конкретнее, зачем тебе это надо?

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

(10) Иногда это нужно, например для обмена данными, или прямых запросов, в которых завязано на УИДе

Это будет уже другой элемент, такое проканает только с не ссылочными данными

Много баз сливают в одну. Базы делались из одной "рыбы". Т.е. был объект "Наша организация" со своим УИД. Брали Нашу Организацию и делали из нее ООО "Ромашка". Теперь эти лютики и ромашки надо слить в одну базу. И при заливке через ВыгрузкуЗагрузкуДанныхХМЛ Ромашка затирает Лютик и наоборот. Поэтому было бы хорошо в Ромашке поменять УИД заранее чтоб ничего не затереть.

Делаю как (8) поиск и замена значений, но очень уж долго работает...

(11) Прямые запросы - нарушение соглашения. Для обменов - делается по сути (7), т.е. стандартная поиск и замена ссылок, Или регистр соответсвия объектов ИБ юзается... короче задача решается не таким путём как хочет автор

(10) Как насчет ситуации, когда при обмене у разных объектов совпали идентификаторы?

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

(10) ну почему, сливаем данные из двух таблиц в одну - возможно Уиды совпадут

2(15) такого не бывает.

(16)>>А мне все равно на соглашение
нуну...

2(17) из каких двух таблиц?

(16) Загрузка выгрузка идет по УИДАм

(15)(19) бывает, за 4 года 1 раз словил :)
Но решение не (0), а опять же Поиск и замена значений. Сиречь создание нового элемента и перекидывание на него ссылок во всей базе

(18) теоретически возможно даже если база не потомок

(20) из любых ссылочных

(22)>(18) за 4 года 1 раз словил

Ну так что, граждане, есть выход из тунеля?

2(22) не бывает, разве только сделать так специально. А раз специально сделали - значит думали когда делали.
2(25) и кто же завел в двух разные объектынх таблицах записи с пересекающимися уидами и зачем он это сделал?

2(27) тебе уже сказали, что нет.

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

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

(27) настрой загрузку/выгрузку организаций не по УИДАм ,а  по ИНН , в чем проблема то...

(31) когда нибудь случается в первый раз, у меня так документ по обменам бегал, в 2-х разных узлах создались одинаковые гуиды

(0) Какое-то глупое ограничение платформы тянущееся много лет, может в 9.0 все-таки разрешат.

(34) последствия представляешь? вот автор (0) заменит гуид - и пол базы в битых ссылках. Красота, да

(31) Любая вероятность 50% - либо случится, либо нет. (с)

(33) + вообще - одинаковые гуиды можно найти в больших РИБ базах, но очень редко попадается что они в одном виде документа-справочника

2(34) что разрешат? Что если поменять уид в записи, то во всех других записях уид тоже автоматом поменятся, и это будет происходить мгновенно?

(27) есть, но не такой как в (0). Если сливаешь по обменам - вобще проблем нет же, см (32)

Уид - это "фактически" номер объекта в его таблицы.
Во всех местах, где идёт ссылка на объект, указывается этот номер.
Что будет, если у какой-то записи мы поменяем "номер" - это уже будет другая запись, а от старой останутся неразрешимые ссылки, так как она будет ссылаться на номер, которого нет.
То есть, даже если вам каким-то чудом удастся подменить GUID в таблице объекта, всё равно придётся запускать обработку поиска и замены значений, чтобы поменять все ссылки.

(38) Про мгновенно никто не говорит. Но метод такой необходим. Одним общепринятым извращением станет меньше.

2(41) этот метод реализуем изменением уида в ведущей таблице средствами SQL и во всех ведомых.
Или через поиск и замену значений. Если кто-то не знает этого или не умеет этого - то это уже его проблемы а не 1С.

> Можно ли изменить уникальный идентификатор у уже существующего элемента

База 10 ГБ размером. Как ты себе это представляешь?

(42) Средства скл давно стали стандартными в файловом варианте?

(43) бзик-бзик-бзик в 1000 раз быстрее чем перенести 10Гб документов на новую организацию

2(44) Не стали вообще. НО и создать другой элемент справочника и запустить поиск и замену значений в файловом варианте - тоже не очень долго. Если вдруг это долго, то значит либо базе давно стоит быть в клиент-серверном варианте, либо опять же, не делать вообще

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

(44) думаю, напрямую в таблице SQL можно поменять

2(45) бзик-бзик-бзик и есть перенести документы на новую организацию, и ТС говорит что это медленно у него.

2(47) да нет, типично одинэсный подход говорить что метод которого не должно быть вообще, нужен

(45) > бзик-бзик-бзик в 1000 раз быстрее

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

(51) изменение ссылки во всех таблицах сравниваешь с полным перепроведением документов по новой организации? совесть есть?

2(52) кто сказал о полном перепроведении? ты давно заглядывал в поиск и замену значений?

(52) напиши правила обмена или возьми с БСП

+(54) там есть возможность проассоцииоровать один элемент с другим

регистр соответствий

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

2(57) зачем она отрабатывает? потому что криворукие программисты не поставили проверку на ОбменДанными.Загрузка?

Dunstan , посмотри в своей конфигурации наличие регистра сведений  СоответствиеОбъектовДляОбмена. И если он есть - изучи зачем он нужен и как его использует конфигурация.

(51) Заменить 1 поле быстрее, чем переписывать весь объект.