8.х Обновление измененной конфигурации

Добрый день!

Есть база УПП 1.2.29.1 сильно измененная.
Добавлены новые документы, константы, регистры, перечисления, отчеты, обработки, интерфейсы.
Добавлены новые реквизиты в стандартные документы (реализация, заказы, отчет производства и др.), соответственно изменены формы этих документов.

Есть большое желание эту базу обновить до текущей версии 1.2.34.1 ,
поскольку в этой же базе ведется регламентированный учет, обновление необходимо бухгалтерии.

Процесс обновления измененной конфигурации примерно представляю себе. Для перехода на следующую версию необходимо в новую конфигурацию перенести все изменения старой версии (по сравнению со стандартной конфигурацией поставщика) и уже этой конфигурацией обновлять базу.
Но как лучше это сделать при переходе через несколько версий (после 29 релиза были еще 30,31,32,33)?

Обновляться сразу на 34 релиз боязно - вдруг потеряются какие-то данные. Возможно промежуточные релизы были ключевыми.
Недавно обновлял стандартный 29 релиз УПП так - сначала сразу на 32, потом 33, 34. Вроде все нормально перенеслось, ничего не пропало.

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

Подскажите правильно ли собираюсь сделать?
На что еще обращать внимание при таком обновлении?
Поделитесь, у кого есть опыт или где можно почитать о подобном...

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

Спасибо, что подтвердили мои догадки, примерно так это себе и представлял...

Нет! Никаких сравнение-объединение! Только через пункт меню "поддержка".
Конфигурация какая, по номеру релизов понять не могу. Неизвестно что там в типовых менялось.

Сделайте так. У себя на копии готовите 27 релиз (чтобы конфигурация была измененной рабочей).
К клиенту приезжаете, накатываете последовательно типовые 26, 27 релизы через пункт меню поддержка (следите только чтобы добавленные реквизиты-справочники не затерлись, но по-умолчанию все и так ок должно быть). После каждого релиза не забываем запускать базу в режиме 1С:Предприятия. После этого уже через пункт сравнить-объеденить накатываете ваш подготовленный 27 релиз.
Обязательно - резервная копия базы клиента перед началом работы.

В теории все верно, но только для добавленных объектов, которых нету в типовой конфигурации (Ваш справочник "Города").

Если у Вас есть типовые объекты конфигурации, которые дорабатывали программисты, а также которые изменялись при обновлении 1С - получится нехорошо.
Например, программист что-то добавил в модуле объекта "Реализации товаров и услуг" (встроенную печатную форму с соответствующим кодом вывода на печать).
А 1С в новые обновления что-то внесла новое в модуль проведения этого документа, влияющее на записи в регистры.

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



Озадачился тут обновлением еще более старой УПП.
Была сильно дописаная 1.2.5.1 , обновлял на текущую (на момент начала работы это была 1.3.17.1, сейчас уже 1.3.21 вышла ), причем было много дописанных типовых документов.
В результате не стал именно обновлять старую конфу.
А сделал чистую базу из 1.3.17.1, внес туда все изменения и залил все данные из старой (с 2008 года, баз весила 5Гб).
С 1 января вроде все работает, кто-то даже не заметил, что база обновилась...

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

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

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

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

Тем более, что отловить изменение кода через сравнение очень просто, а отловить, что изменилось на форме штатно никак (элемент подвинулся, привязки изменились и т.п.): только на глазок. :angry:

У меня вручную форма не правится. Если необходимо - все элементы передвигаются, создаются, устанавливаются исключительно программно. Код создания-расстановки для всех элементов вынесен в отдельный модуль. Сделал один раз и забыл про формы.

[off]Респект, все бы так делали...
На "отрисовку" одной формы наверно много времени уходит по сравнению с обычной правкой?[/off]

[off]

Ну естественно зависит от того что надо переделать на форме. Есть хорошая обработка для этих целей АнализИДекомпиляцияФорм как-то так называется, брал если не ошибаюсь на инфостарте. Вначале на копии базы расставляем на форме элементы как нужно, потом с помощью этой обработки декомпилируем форму, там на выходе получается код формы. Соответственно находим там код для создания наших элементов, и переносим его. Код там конечно не на 100% идеальный на выходе, кое что править надо, но основную работу обработка делает. Потом так, можно сказать мелкие правки.

Справедливости ради отмечу, что встречаются формы, которые так наскоком не победить (ну мне нормально не удалось). В частности из типовой это форма обработки подбора номеклатуры. Там насколько я понял причина в том, что эта форма привязывается к правой границе (т.е. растягивается по высоте) + на самой форме есть разделитель. В общем не хотела она отображаться нормально, съезжали элементы формы. Задача у меня там была в том, чтобы на эту форму над полем с номенклатурой добавить чекбокс. В итоге решил по другому: не стал добавлять чекбокс на форму, а в панели с кнопками этой формы добавил еще одну кнопку, ну которая запоминает состояние нажата-не нажата, получился аналог.
[/off]

Спасибо, как то не обращал внимания на эти публикации Инфостарта.
Скачаю, буду изучать.