Доброго времени суток.
Возникла вот какая проблема:
Есть ЦБ + 25 ПБ. Для справочника Контрагенты настроен способ
миграции "Место создания и центр". В ЦБ данные не заносятся, она служит исключительно для консолидации информации. Так вот с какого то момента (точно не знаю с какого) получилось в двух разных ПБ два разных элемента с одним UID - метод ЗначениеВСтрокуВнутр возвращает два одинаковых значения. т.е. ЗначениеВСтрокуВнутр(ОбъектПБ1) = ЗначениеВСтрокуВнутр(ОбъектПБ2).... какой то брееед.
В ЦБ видим такую картину - ВСЕ ссылки на ОбъектПБ1 заменяются на ОБъектПБ2, как такое возможно и самое главное как теперь это излечить??? у кого какие мысли?

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

В одной из ПБ создать нового контрагента и заменить ссылки (обработка "Замена значений").

А вот удалять старого контра в ПБ надо аккуратно - провернуть полный автообмен, удалить старого контрагента и очистить файл 1SUPDTS.dbf (в файловой версии) - теперь модно говорить "план обмена" :)

(1) Спасибо за совет. Кстати база и так скульная. и ПБ и ЦБ.
Создать нового и заменить на него все ссылки, это походу единственный выход. Жаль что придется много доков перепроводить... есть вариант прямым запросом таблицы переписать, но боязно че то, могу чего то не предусмотреть ... завтра буду пилить...

Самое главное - природа данного явления НЕПОНЯТНА!!!
(2) Спасибо за совет.

УИДа в клюшках нет.есть ИД. А вотнасчет " в двух разных ПБ два разных элемента с одним UID - метод ЗначениеВСтрокуВнутр возвращает два одинаковых значения." я бы попросил  уточнить... Ибо "ЗначениеВСтрокуВнутр(ОбъектПБ1) = ЗначениеВСтрокуВнутр(ОбъектПБ2)" невозможно, если у разных ПБ разные  иды баз... "Кто-то врёт"©

(0) теоретически это возможно - доля вероятности очень мала - ты в эту долю попал :) чему тут удивляться.

(5) есть уид в клюшках, только не все это знают :)

(5) неа ...не вру :) иначе зачем бы мне тут помощи искать... :)

ID элементов в таблицах одинаковые.

(6) тут ведь вот какая штука - как в эту долю не попасть далее ? :)

"Самое главное - природа данного явления НЕПОНЯТНА!!!" - откуда ноги растут хочешь знать? Журнал регистрации расскажет кто и где из одного элемента сделал "два разных".

Изменение наименования записей справочников (а также номера и даты документов) фиксируются в журнале и легко отлавливаются.

если ид одинаковые то прямым запросом удаляем любой из них,для 1с это одна сущность

(5) элементарно же делается, взяли и переименовали контрагента. В восьмерке мы даже специально делали, когда в разных городах один и тот же контрагент по-разному называется. Например, Сбербанк.

(9) и последние 3 символа ИДа - тоже одинаковые? И вообще, неплохо было бы их тут привести...

(14) Данные по ПБ (ID базы = 025)

ЗначениеВСтрокуВнутр = {"B","0","0","0","0","0","       440      8624006"}

ID в таблице '   6NK006'

Данные по ЦБ (ID базы = 001)

ЗначениеВСтрокуВнутр = {"B","0","0","0","0","0","       440      8624006"}

ID в таблице '   6NK006'

Вообщем элемент справочника создан в базе C ID = 006. 'nj понятно, НО как он попал в базу с кодом 025???? если для справочника установлен способ миграции Место создания и центр...  его там по определению быть не должно...

(11) в журнале регистрации к сожалению нет данных по данному объекту когда его и кто завел... как буд то он там был с момента создания периферийной базы, т.е. есть данные о том что его записывали, открывали и т.д. НО с признаком НОВЫЙ нет ни одной записи.
вообще вот о чем подумал... у меня в базе есть справочник Фирмы - способ миграции - Все ИБ, у справочника фирмы есть реквизит "Контрагент". так вот может быть такое, что при создании новой ПБ в нее помимо фирмы был записан и контрагент, невзирая на то что установлен способ миграции для справочника контрагенты - Место создания и центр ????

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

В общем  сообщаю, если кому интересно конечно,
проверил все базы на наличие таких вот "касячных двойников", для чего написал обработку соответствующую (огромное спасибо 1cpp).
Выявил что такие касяки только в одной базе и таких элементов 5 штук, короче определил размер "трагедии".
Ну и стандартной обработкой по замене значений исправил ссылки на новые элементы как предлагал (2).
Вот так. Всем спасибо за обсуждение!