Каталог решений - Обновление Бухгалтерии 3.0, в состоянии расхождения объектов по внутренним идентификаторам

База Бухгалтерии 3.0 — клиенту известно, что изменения есть, но их не должно быть много, касаются нумерации некоторых документов.

При сравнении с базой поставщика, через Поддержка-Настройка поддержки,  дает значительный разбег конфигураций — примерно 40% измененных объектов + 20% удаленных и новых, все объекты базы "разрешены изменения" у многих "снят с поддержки".  

Однако, при сравнении с файлом (конфигурация поставщика выгружена в файл) — фактических различий в конфигурациях 1-2%.

Видимо в какой-то момент обновляли путем сравнение-объединение с файлом конфигурации поставщика —  как в свое время делалось в 7.7 — и все новые объекты получили свои новые внутренние идентификаторы и не соотносятся с аналогичными в типовой.

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

Объясняю, почему нельзя просто загрузить типовую конфу — теряем данные, сохраненные в тех объектах, которые разъехались по идентификаторам — их просто затрёт. 

В данном примере повезло — кривое обновление базы не затронуло серьёзных объектов, содержащих данные — в основном макеты, формы, отчеты, обработки, модули . Но сначала это было не явно — присутствовали и регистры, и константы, и документы.  

Опишу этапы, по которым действовала, может, кому поможет, кого-то наведет на мысль . 

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

2. В базе данных проверяем объекты, которые хранят информацию и "разъехались" с типовой — есть ли в них информация.

В моем случае несказанно повезло: 3 регистра,  2 константы и 1 вид документа оказались не использованы — данных по ним не было и сохранять не нужно было — с ними я поступила аналогично 1 пункту.

В общем случае, когда данные есть — путей 2: либо эти объекты так и оставляем — "разъехавшимися" и каждое обновление обновляем их индивидуально, либо сохраняем "старый" объект с данными под другим именем и готовим обработку по переносу данных из него в типовой объект — переносим и удаляем "старый" объект.

Итого получаем конфигурацию более приближенную к типовой — в которой оставлены только нужные изменения.

3. При обновлении на следующий релиз через Поддержка-обновление на форме настройки поддержки указываем, что "новые объекты" — "не редактировать", "идентичные объекты"  — "не редактировать". Так мы вернем "под замок" объекты, которые не отличаются от типовых.