Добрый день.
Есть конфигурация (бухгалтерия) на 8.3.20
Был добавлен один документ без использования расширения, при появлении новой конфигурации, физически добавляем в новую конфигурацию путем копированием данный документ.
Но когда загружаем (не сравнить объединить) в базу со старым релизом, то данные данного документа удаляются.
А типовые документы норм обновляются.
Этот документ при сравнении 2х конфигураций, не отображается, т.к. идентичные.
https://ibb.co/h270pL3 при реорганизации
Данный принцип работал со дня изменения конф с долгой протяженностью, но сегодня не сработал.
Подскажите пжста в чем может быть дело?

"добавляем в новую конфигурацию путем копированием данный документ." - методически неверный подход (изменяются внутренние идентификаторы)
"Но когда загружаем [конфигурацию], то данные данного документа удаляются." - внутренние идентификаторы не совпадают.
"Этот документ при сравнении 2х конфигураций, не отображается, т.к. идентичные." - вероятно сравнение происходит по свойству "Имя" объекта.

"Особенности сравнения и объединения конфигураций в режиме обновления"
https://its.1c.ru/db/metod8dev/content/2299/hdoc

Для сопоставления объектов при объединении конфигурации в 1С:Предприятии 8 используются свойство "Имя" объекта метаданных и его внутренний идентификатор. Однако в различных вариантах сравнения алгоритм сопоставления объектов разный. Прежде чем подробно описать различные варианты, сначала опишем правила изменения внутреннего идентификатора. Идентификатор в пределах одной конфигурации никогда не изменяется. Идентификатор не изменяется при выгрузке конфигурации в cf или dt файлы (включая файлы поставки cf и обновления cfu). Идентификатор не изменяется при использовании механизма групповой разработки (в процессе перемещений между конфигурацией и хранилищем). Идентификатор всегда изменяется при копировании объекта, в том числе в процессе объединения конфигураций...

(1) обычно CtrlC, CtrlV прокатывает и идентификатор тот же. Наверно, нестандартная ситуация - идентификатор такой уже есть в новой базе.

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

(2) внутренние  идентификаторы там невооруженным взглядом не видно. имена объектов - это не внутренние идентификаторы. надо пользоваться сравнением и объединением конфиг. а сейчас уже и расширения нормально работают.

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

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

(6) я так реквизиты табчасти спасал один раз. Но данные удалось не потерять

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

Т.е. изначально есть прод-база.

Сниаем с нее копию для разработки. И начинаем вносить изменния в конфигурацию. При этом, сама конфигурация не должна откуда-то извне перезаливаться.
Разработали в ней чего-то. Обновляли в типовом смысле, доливали, дописывали. Дошли до готовности переноса конфиги на прод.
Выгружаем конфиг в файл.
Открываем прод-базу - и можно даже залить базу на прод из файла (не сравнивая и не объединяя, а просто залить) Но надо понимать, что заливаемая конфига для прод-базы явялется потомком - прямым наследником. И тогда все будет хорошо.

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

Т.е. в данном конкретном случае очевидно, что манипуляция с копированием документа из прода в конфигурацию для разработки происходит при том, что конфига для разработки "не родная" для этого прода.