В общем - я тоже столкнулся
Почитал в интернетах - причины так и не ясны
обновлял копию БП2 с 126 на 128 релиз
Добавлялись релизом счета 68.01.1 и 68.01.2
Но задублировались 68.13, 68.52, 69.02.7 и 69.06.5
В рабочей - все эти счета предопределенные, имена предопределенных совпадают.
обновлял через поддержку, контролировал, правда, только дважды измененные
все таки - в чем причина задвоения, кто знает?
как обойти - указать соответствие при объединении, если разошлись?

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

(0) могли предыдущими обновлениями закосячить

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

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

обновление конфигурации поставщика, если конфигурация снята с замка, там она как бы заново компилируется при получении обновления из CFU

Посмотри, в конфигурации поставщика все нормально?

Но так-то теперь надо обработку писать, которая выберет "лишние" ссылки из РБ и запишет их на "правильные" ссылки.

(5) да в копии не буду обработки пользовать, мне бы при обновлении рабочей этого избежать

(5) в конфигураторе в предопределенных все хорошо - элемент один
как то конфиг поставщика в файлы выгрузить можно? думаю там и гуид видно будет

(7) выгрузи его в cf, загрузи в чистую конфу, выгрузи в файлы?

(8) столько телодвижений )

и если верно про "компилируется", то что мне это даст? думаю, в ней будут те же гуид-ы , что и сейчас

(10) ну да. Раз у тебя в текущей конфигурации только один комплект значений, без дублей, значит он и выгрузился туда из конфига поставщика и заместил собой существовашие ранее по условию "сопоставлять по именам объектов"

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

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

Такое тоже происходит когда базы выгружаешь в другую выгрузкой -  загрузкой
  Я решаю таким образом- сделал чистую конфигурацию идентичную существующей,  выгрузил оттуда план счетов в xml   стандартной выгрузкой загрузкой
затем удаляю непосредственно все предопределенные в рабочей базе и не выходя из программы сразу же гружу из файла.

Тренируемся в копии,  бекапы не забываем.

Кстати, когда у меня идет обновление, то там выскакивает предложение о замене объекта План счетов на тот, что в конфигурации поставщика. Я отказываюсь от этой замены и переношу изменения "ручками" в текущий план.

Но хорошо, что ветка такая появилась :-) Буду смотреть внимательней при переходе на этот релиз.

у меня тоже такое произошло. 12 баз абсолютно одинаковых, ошибка произошла только в одной. из особенностей могу отметить, что там включен учет по подразделениям
1С не смогла обновить один счет на другой с такими же субконто, потому что в конфигурации их три, а в базе их четыре (те же + подразделения).
из изменений в счетах заметил только признак активности-пассивности. почему при этом 1С не может обновить счет, непонятно, говорит, код счета неуникальный, то есть не "видит", что счета есть и создаёт новые. окей.

пришлось сделать так:
1) включить возможность изменения конфигурации, удалить все кривые счета из базы
2) с помощью обработки снять признаки предопределенности у всех 4-х видов субконто
3) снять признаки предопределенности у всех счетов, которые 1Сволочь не смогла обновить (конкретно 68.ОТ и ОТ)
4) пометить на удаление кривые счета
5) восстановить признаки предопределенности у всех 4-х видов субконто
6) наконец, обновиться. признаки предопределенности у счетов восстановились сами, но почему-то если раньше там были УИД, после обновления встали норимальные текстовые имена
7) заменой дублей заменить старые счета на новые. в проводках они не поменялись, там возник Объект не найден
8) перепровести все документы, где участвовали эти счета.
9) вернуть конфигу на поддержку (сохранить конфигу поставщика и загрузить её в базу)

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

сука, ночь пришлось потратить (

(14) думаю, земеля, ты прав, вполне вероятно кто то до меня тыкал в "сопоставлять по именам объектов", не исключаю )

(15) зачем пункт 8? замена ссылок меняет также и в движениях

(17) у меня не поменяла почему-то.

(15) столько ненужных телодвижений..файловая что ле ?

че эт не нужных? на скуль денех нема (

(20) ааа..ну тогда страдай :)

как-то проще табличку проапдейтить, поменяв ид-ники счетов там, ну или признак предопределенных данных воткнуть, куда надо
Кто к чему привык.