Как правильно обновить сильно измененную конфигурацию

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

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

Я бы не стал обновлять конфигурацию. Тут только программиста вызывать!

Для обновления использую Конфигурацию АК 47 (Анализатор Коллизий).

Очень рекомендую.

процесс обновления наглядно отслежуемый.

(1) А так ли нужно все обновлять в вашем случае, может обновить только то, что необходимо для работы, а то что и так работает не трогать?

Свою конфигурацию сравниваешь с таким же релизом, но типовым. Затем переносишь изменения в типовую последнего релиза (что ручками, что через объединение конфигураций). Затем этот конфиг накатываешь на свою базу. Естественно, не нужно забывать про копии.
ЗЫ Но лучше конечно специалиста вызвать.

Нужно определиться какой из 2х вариантов потребует меньше работы и с помощью него обновить конфу:
1) Сравнить типовую конфу(не измененную) с релизом как у рабочей - с конфой рабочей(измененной). И внести различия в последний релиз конфы (до которого нужно обновить). Таким образом получим обновленную конфу.
2)Сравнить типовую конфу(не измененную) с релизом как у рабочей - с конфой псоледнего релиза( до которой нужно обновить). И внести различия в рабочую текущую конфу. Таким образом получим обновленную конфу.

Может быть это чем-то поможет. http://infostart.ru/public/18551/

Может быть нужно взвесить все за и против и обновить только нужные объекты с соответствующими исправлениями иначе рискуете нарваться на конкретный кусок работы.

Никак ты бы еще спросил как после изменения в 8ке, в которой это называется "снятие с поддержки". Конфу когда правил надо было записывать что изменял, если записывал и помнишь что делал, переходи к сравнению конф, что нужно там и ставь галки. Можно попробовать внешними обработками. По опыту сам работаю на измененной, ну не нужны там 1сковские обновления, чего не так дописываю, прикрепляю. Да и не забывай бэкапит базу!!!
Узнать можно что там тебе такого понадобилось в обновлении, что ты без этого обойтись не можешь?

Вот тут написано
http://infostart.ru/public/18562/

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

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

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

(1) nutmeg,
Однозначного рецепта нет.
но...
Есть рабочий алогоритм действий ( сталкивались несколько раз с подобной ситауцией) .
1. сделать бэкап.
2. при объединении ( ставишь галку - приоритет загружаемой) - вывести ПОДРОБНЫЙ ОТЧЕТ от изменениях.
3. особое внимание обратить на :
* изменение длин кодов в МЕНЬШУЮ сторону
* изменение уникальности кодов - по всему спр/в пределах подчинения
* изменение ТИПОВ кодов и номеров Документов
* изменение периодичности реквизитов
* изменение типов регистров - Остатки <-> Обороты (тут будет сложнее)
* нумераторы и последовательности
4. разобрать старую конфу утилитой GComp (через поиск гуглом/яндексом - найдешь сам)
5. критичные модули/формы , где вносили изменения - можно будет потом обратно также вставить - утилита двунаправленная

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

Мы в таких случаях цепляем 1с++ и все что нужно выносим в классы.
Через объект Перехватчик - можно динамически менять код в зависимости от обстоятельств.
Это - самый безболезненный и эффективный вариант, т.к. позволяет :
* совместить типовой код и дописанный
* обеспечить минимальное вмешательство в типовой код на уровне конфигурации
Все вышеописанное - при необходимости сохранить дописанный функционал.
Удачи.

Типа никак, да и смысла нету, всё что появляется можно внешними прикрепить, что нельзя то можно и самим исправить, конфу ведь правили, тобишь знаете зачем и откуда ручки растут, сможете и в этот раз поправить.

В торговле и складе, как бы сильно ничего не меняется, это тебе не УСН которые каждый день чот новое. Внешними цепляй.

Посмотри здесь. http://support.radico-intel.com/KB/a13/1-v8.aspx

только сравнивать конфы

Когда правил конфу надо было внешними цеплять, не пришлось бы теперь голову ломать.

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

(1) Обновление сильно измененной конфы, которую до тебя несколько лет курежили разные люди - это искусство. Судя по вопросу - вы это не потянете. При таком обновлении зачастую можно проигнорировать до 90% изменений, т.к. сейчас они уже не используются. Бывает, проще внести несколько нужных объектов (новая с/ф), чем обновлять всю конфу. Чисто индивидуальный подход, короче.
"потом стал ставить приоритет её выше, чем у той которой обновляю" -однозначно НЕТ.

1. сделать бэкап.
2. при объединении ( ставишь галку - приоритет загружаемой) - вывести ПОДРОБНЫЙ ОТЧЕТ от изменениях.
3. особое внимание обратить на :
* изменение длин кодов в МЕНЬШУЮ сторону
* изменение уникальности кодов - по всему спр/в пределах подчинения
* изменение ТИПОВ кодов и номеров Документов
* изменение периодичности реквизитов
* изменение типов регистров - Остатки <-> Обороты (тут будет сложнее)
* нумераторы и последовательности
4. разобрать старую конфу утилитой GComp (через поиск гуглом/яндексом - найдешь сам)
5. критичные модули/формы , где вносили изменения - можно будет потом обратно также вставить - утилита двунаправленная

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

Мы в таких случаях цепляем 1с++ и все что нужно выносим в классы.
Через объект Перехватчик - можно динамически менять код в зависимости от обстоятельств.
Это - самый безболезненный и эффективный вариант, т.к. позволяет :
* совместить типовой код и дописанный
* обеспечить минимальное вмешательство в типовой код на уровне конфигурации
Все вышеописанное - при необходимости сохранить дописанный функционал.
Удачи.

Могу поделиться своим опытом. Когда-то делала так:
!!!Если обновления вносились не вами и не выделены в тексте комментариями, то находим типовую того релиза, который стоит у вас.
1) "Объединение конфигураций" и смотрим какие именно изменения вносились. Я их складываю в отдельный файл и сохраняю - это потом будет нужно при каждом обновлении. НАзовем список этих объектов - СПИСОК_ИЗМ
2) делаем копию нашей базы не через конфигуратор, а просто копирую дирректорий, подключаю его и дальше работаю с ним.
3) "Объединение конфигураций" ( обновляем уже нужным вам новым релизом). Смотрим объекты, которые попали в СПИСОК_ИЗМ - встаем на них -"Сравнить" - смотрим каких изменений больше - тех, что сделали мы(или до нас :-))) или тех, которые появились в обновлении. В зависимости от этого делю для себя эти объекты на 3 группы: 1гр- старых изменений намного больше, чем новых; 2гр- наоборот; 3гр - это объекты, которых вообще нет в типовой.
Далее
а) оставляю галочки у тех объектов, которые не подвергались изменениям ранее и их можно безболезненно обновить. И у тех, в которые старые изменения легко внести заново. Приоритет у "загружаемой", Метод "Замещать объекты". ОК. Внести изменения, если это надо. Сохранить конфу.
б) снова "Объединение конфигураций" - галочки у тех, которые вошли в 1 группу - ставлю приоритет у "текущей", Метод "Объединять объекты". ОК. Захожу в каждый объект, анализирую( все внесенные изменения при объединении выделяются "скобками" {MRG}) и вношу нужные исправления.
в) снова "Объединение конфигураций" - галочки у тех, которые вошли в 2 группу - ставлю приоритет у "загружаемой", Метод "Объединять объекты". ОК. Захожу в каждый объект, анализирую( все внесенные изменения при объединении выделяются "скобками" {MRG}) и вношу нужные исправления. Сохранить.
С 3 группой: Они просто остаются и все.
4) Полученным файлом конфигурации обновляю рабочую базу. ОБЯЗАТЕЛЬНО перед этим выполнить сохранение!!!!!!!


Другой вариант-последнее время все чаще применяю именно его:

1) делаем копию нашей базы(назовем ее СТАРАЯ)
2) разворачиваю пустую базу с новым релизом
3) в одном окне открываю в Конфигураторе старую базу(пусть ОКНО1), во втором окне в конфигураторе новую типовую(ОКНО2).
4)В ОКНО1 запускаю "Объединение конфигураций", сравниваю с типовой того же релиза, что и старая база. Смотрю каждый измененный объект- какие именно изменения вносились.
Анализирую эти изменения- нужны нам в дальнейшем? иногда внесенные когда-то изменения давно уже не используются и нет смысла их поддерживать. Бывает и такое(правда довольно редко), что этот механизм уже реализовали в типовой. Выбираем, какие изменения все-таки надо сохранить.
Если это объекты, которых вообще нет в типовой(документы, справочники, перечисления ) - просто выписываю их себе. В дальнейшем при обновлении они просто останутся нетронутыми.
для остальных объектов -
5)"сравнить" и из ОКНА1 переношу изменения в соответствующий объект в ОКНЕ2. Сохранить
6) Полученным файлом конфигурации обновляю рабочую базу. ОБЯЗАТЕЛЬНО перед этим выполнить сохранение!!!!!!!

А вообще-то,не зная размер и характер ваших изменений, сложно рекомендовать что-то конкретнее. Сколько баз - столько и вариантов.

нужно, брать новую конфу переносить все изменения и объединять, либо если изменения небольшие то повторить их в рабочей бд

Для сильно изменных конфигураций я обычноделаю так:Читаю файл release.txt, смотрю что изменилось.Сравнивая мою конфигурацию и обновление, аккуратно внощу изменения в рабочую. Конечно долго, зато все измения останутся на месте и ты курсе что изменилось, где были ошибки. Стоит раз проделать эти изменения, следующий раз делать обновления будет на много проще. Я все релизы ставлю по очереди, через много релизов не перепрыгиваю.

Торговлю обычно не обновляют до последних релизов, все зависит от того, какие изменения Вам нужны. Если берем счет-фактуры (изменения 2012года), так мы установили внешние формы. Так дешевле и проще.
А если все же решили обновлять:
1. Сравнение базы с типовым релизом(номер релиза совпадает с релизом базы)
2. Сравнение типовых релизов (старый и новый)
3. Анализ приоритета изменений. Берем переносим изменения Нашей базы в новый релиз, или наоборот изменения между релизами в нашу базу.
4. Объединяем Нашу базу с измененным md файлом нового релиза(если в него внесли сами изменения).
Выверка получается долгая, но ...

На самом деле сравнение объединения не всегда правильное решение.
Иногда приходиться код написанный в старой программе переноситься частично и отлаживать.
А чему писать в торговли чтобы помом обновлять ?

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

для сильно изменных конфигураций я обычно:
1. Читаю файл release.txt, смотрю что изменилось
2. Сравнивая мою конфу и обновление, аакуратно внощу измеения в рабочую.

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

Спасибо. Но дело в том, что база несколько лет не обновлялась, и что теперь поднимать все релизы по очереди?

Сравниваешь с неизмененной той же версии и перетаскиваешь изменения по частям в чистую новую.

http://develop.iservice.ru/adm/print.php?id=1114756949&archive=

Обновлял с 7.70.927 на 7.70.988 сразу, т.к все до определенного момента устраивало. Но с переходом на маркированный товар пришлось. Как итог процесс не особо долгий, но чтобы свое не порушить пришлось повозиться. Единственное долго проходили внутренние пересчеты базы, когда после обновления открыл само Предприятие.