Где-то прочитал на формуе, что можно сравнить объекты конфигурации не по именам объектов, а по их идентификаторам. Однако в настройках конфигуратора такого не вижу... Можно ли это как-то сделать?

(0) А что хочешь увидеть в итоге?
Допустим есть справочник с GUID1 в одной конфигурации, и есть регистр сведений с GUID1 в другой конфигурации. Что это даст?

(1) Дело в том, что при обычном сравнении  различия не показываются, а когда дело доходит до обновления из хранилища - то вылазят такие косяки, что один и тот же справочник или реквизит документа был добавлен в разные конфигурации по отдельности, и воспринимаются конфигурацией как разные объекты, и затираются при обновлении. Хотелось бы выявить такие объекты на этапе сравнения конфигурации с другой конфигурацией.

Сравнение и объединение — всегда по именам.
Обновление релизов через поддержку — всегда по идентификаторам

(0) Попробуй через сравнение двух конфигураций, выгруженных в файлы. То есть сравнить два cf файла, а не сравнение рабочей конфигурации с файлом.

https://its.1c.ru/db/v8322doc#bookmark:dev:TI000001076

В дополнение к основному режиму сравнения и объединения конфигураций, ..., при котором одна из сравниваемых конфигураций всегда выбирается основной, конфигуратор предоставляет возможность сравнить две произвольные конфигурации, например, расположенные в файлах, или конфигурацию хранилища (с выбором любой версии) и поставки и т. д.

Выбрать сравниваемые конфигурации можно с помощью меню Конфигурация ‑ Сравнить конфигурации.

Если сравниваемые конфигурации не являются потомками друг друга и поэтому для них не может быть произведена установка соответствия по внутренним идентификаторам, нужно установить флажок "Установить соответствие по именам объектов".

Логично предположить, что если флажок "Установить соответствие по именам объектов" снять, то сравнение будет производиться по идентификаторам.
Но это неточно... Прямо об этом в документации не написано.

(4) Попробовал, к сожалению, так тоже не показывает различия, если у объектов разные идентификаторы(

(3) переименовал в тестовой справочник и сравнил с исходной - всё сопоставилось. Т.е. сравнение НЕ всегда по именам

(6) >> сравнение НЕ всегда по именам

Разумеется. В документации об этом напрямую сказано.

При автоматической установке соответствия программа анализирует объекты конфигураций, имеющие одинаковые имена. Например, Справочник.Товары в одной конфигурации и Справочник.Товары в другой считаются одним справочником; им устанавливается соответствие, и они будут сравниваться.
Среди объектов, имеющих разные имена, отдельно проводится сравнение внутренних идентификаторов,...

(7) Да, тест это подтверждает: добавил спр с исходным именем и сопоставилось по имени, переименованный повис без сопоставления

Ситуация такая: используется несколько типовых доработанных баз УТ и несколько доработанных отраслевых УТ. Доработки в типовых и отраслевых одинаковые по сути и именам (например, добавлены свои справочники, перечисления, реквизиты), но добавлены они в базах независимо друг от друга. Возникла задача перевести типовую доработанную УТ на отраслевую. В момент простого сравнения различий между добавленными объектами не показывает, так как имена у них одинаковые. Но в момент, когда подключаешь базу к хранилищу отраслевой - если сравнить основную конфигурацию и конфигурацию базы данных - то показывает, что объекты с одними и теми же именами различаются, система воспринимает их как разные, потому что у них разные идентификаторы.
Хотелось бы как минимум сравнить по идентификаторам, а как максимум - заменить идентификаторы в обновляемой базе, чтобы объединить её с отраслевой без потерь.

(9) имхо без переноса данных при смене ИД метаданных не обойтись.

(6) При переходе ERP на 2.5 через сравнение и объединение у многих (может и у всех - не проверял) объектов поле СтавкаНДС сопоставляется с полем СтавкаНДС, хотя должно было сопоставиться с УдалитьСтавкаНДС, т.к. старое поле было переименовано в УдалитьСтавкаНДС, и добавлено новое поле СтавкаНДС.

(9) "... если сравнить основную конфигурацию и конфигурацию базы данных - то показывает, что объекты с одними и теми же именами различаются, система воспринимает их как разные, потому что у них разные идентификаторы." - вот с этого и надо было бы начинать ветку.
Рекомендую: "Общие правила обмена объектами метаданных между конфигурациями" - https://its.1c.ru/db/metod8dev/content/2291/hdoc - "Для обеспечения корректного сопоставления объектов уровень механизмов нельзя понижать."(с)

Имхо:
- сохранить основную конфигурацию в файл (А);
- сохранить конфигурацию БД в файл (Б) и загрузить(!) конфигурацию из файла (Б);
- сравнить, объединить с конфигурацией из файла (А);
- сказать "Спасибо" если помог чем мог :)

(11) смотри (7) (8)

(12) У него A=Б
ИМХО Подготовить конфигурацию с правильными идентификаторами меньшая проблема, бОльшая - перейти на неё, данные придётся переносить

(14) А если сделать свою поставку конфигурации и через обновление накатить?

RomanYS sorry, Вы не в теме. У автора A<>Б по внутренним идентификаторам.

(14) Способ в (12) как раз для того, чтобы избежать потери данных и не использовать "перенос данных"/конвертацию/ там, где она не нужна.

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

(0) Может EDT такое могёт?

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

рецепт как избегать такой херни: обновлять боёвку ТОЛЬКО из хранилища. хотя бы в части метаданных, модули уж ладно, можете руками туда сюда сравнивать.
как исправить:
0) берем CF с боёвки, захватываем корень хранилища рекурсивно
1) делаем "сравнить конфигурации" и сравниваем основную с CF, снимаем галочку "Устанавливать соответствия по именам объектов". увидим расклад по несовпадающим метаданным.
2) делаем тут же, "Сравнить объединить..."
2.1 ищем тут метаданные которые вылезли в 1)
2.2 - правый клик - "Отменить соответствие"
2.3 - в настройках объединения разрешаем удалять объекты.
2.4 - прокликиваем галочки Удалить МойОхнныйСправочник(гуид1) Добавить МойОхнныйСправочник(гуид2)
2.5 - пересматриваем ролевую модель.
2.6 - применить, залить в хран
3) делаем "сравнить конфигурации" и сравниваем основную с CF, снимаем галочку "Устанавливать соответствия по именам объектов". наслаждаемся результатом.

(18) Угу. Такой фокус можно делать до подключения базы к хранилищу. В принципе есть вариант и с учетом хранилища, но насколько я понял "Но в момент, когда подключаешь базу к хранилищу отраслевой..."(9), автору нужно решение для синхронизации идентификаторов ДО момента подключения к хранилищу.

(16) Возможно я неправильно понял, и под А и Б Вы понимаете разные конфигурации, а не основную конфигурацию и конфигурацию БД в одной базе.
(17) У него уже базы с разными идентификаторами мд и они уже содержат данные. Избежать переноса уже не получится. Ваш рецепт чтобы таких ситуаций избежать, но уже поздно пить боржоми в ситуации ТСа

(22) Именно так утверждает автор :( - "...если сравнить основную конфигурацию и конфигурацию базы данных... объекты с одними и теми же именами различаются... потому что у них разные идентификаторы."

(23) так это при подключении к хранилищу. Конфигурация А в его случае - это конфигурация хранилища. Загрузить Б он не сможет без отключения от хранилища, а при подключении он снова получит ту же проблему.
Т.е. выбор или поломать ИД в хранилище под базу (и получить проблемы с другими базами) или переносить данные между старыми и новыми метаданными.

(24) Хмм... автор в терминах небрежен, а я невнимателен :( Sorry.

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