Есть база УТП с режимом поддержки с кучой дописок. Работает на 1с8.2

Долгое время обновляли просто путем переноса и дописывали конфу.
В итоге имеет:
конфигурация базы данных имеет релиз 1.0.17.12 (2011 год)
конфигурация поставщика как ни странно 1.0.8.7 (2009 год)

Последующее одно обновление нужно делать на 8.1
Далее уже на 8.2

Хочу обновить до текущего релиза.
При чем не факт что конфа базы данных по многим объектам уже имеет почти текущий режим.

Как мне быть?

Читатйте "почти текущий режим." как "почти текущий релиз..."

Для меня сложно как конфу поставщика дотянуть хотя бы до релиза где уже обновление идет на 8.2 Иначе если скатываешься вниз то структура базы данных нарушается.

+ (2) Это всего лишь одна ступень.

Сочувствую.

Главная проблема одна: отделить дописки собственного производства от частичных обновлений объектов.

(2) Это как раз не проблема. Снять с поддержки, поставить на поддержку нужным релизом. Без объединения.

(4) " Снять с поддержки, поставить на поддержку нужным релизом" - Как это делается ни разу не делал. Хотя быть может очень давно делал это.
Ведь для этого нужна любая CF до нудног релиза. А если нет где искать?

(5)  Как это делается
-снимается кнопкой с соответствующим названием,
-ставится объединением с конфигурацией поставщика, все галки снять.

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

(6) Самое действие куда что нажать известно.
Но ведь проблема в том что при объединении с конфой поставщика я потеряю не то что настройки но и данные которые сидят на перенесенных вручную объектах...

(7) все галочки снять, и не потеряешь. Только конфигурация поставщика заместится.

(7) если галки снять - не потеряешь, конфа поставщика не имеет отношения к данным. Вот что будет со связями метаданных вопрос

(8) (9) Ах да, вы правы. Что-то вылетело.

Надо найти теперь кону...

(0)
Мои соболезнования.

Какое количество данных и какой объем _используемых_ доработок?

(11) База весит 5 гигов в скуле а выгрузка 384 мб
Период ровно 2 года.

А вот объем доработок предстоит мне узнать.

(12) базе 2 года, а конфигурации 6-8 лет. Значит ставили уже переписанную. Объем используемых дописок ты не узнаешь никогда, потому что его не знает НИКТО.

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

(13) Нет была свертка....

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

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

недавно делал аналогичное для зоопарка различных баз...

делаешь так

1. находишь типовой 1.0.17.12 cf
2. делаешь копию базы, обязательно первую попытку делаем на КОПИИ
3. на копию загружаем (без сравнение объединения) типовой cf (ставим на поддержку), при этом НЕ сохраняем и не обновляем (важно, что не сохраняем!!!).
4. снимаем с поддержки всю конфу (долго, может до часа идти)
5. начинаем через сравнение и объединение с допиленной 1.0.17.12 накатывать изменения, все изменения комментируем и пишем список измененных объектов (это важно, потом на рабочей этот список понадобится)
6. когда все сошлось - сохраняем конфу
7. пробуем запустить реструктуризацию, возможно из-за расхождения внутрених ID очистятся отдельные объекты, все красные замечания записываем в файл
8. тестируем копию, в обязательном порядке запускаем перепроведение минимум квартала, лучше год. Результат сравниваем с рабочей.

9. теперь переходим к рабочей, выгоняем юзеров, блокируем, делаем бекап
10. загружаем (без сравнение объединения) типовой cf (ставим на поддержку), при этом НЕ сохраняем и не обновляем (важно, что не сохраняем!!!).
11. снимаем с поддержки только объекты из списка п. 5
12. через сравнение объединение загружаем полученый cf из тестовой базы
13. обновляем....
14. при необходимости (если очистились отдельные обьекты/реквизиты) переносим данные из бекапа

(16) можно же через обновление со снятыми флажками, гораздо быстрее

(17) не пойдет, у него релиз конфигурации поставщика слишком древний... штатная обновляла выдаст "не найдено обновление"...

(18) даст, надо просто ей cf указать

(19) я говорю - не даст, я пробовал... только через загрузку типового cf

(20) там проблема в другом, надо все модули проверять, могли процедуры перенести в другие модули, можно конечно ждать ошибки, если репутации не жалко

(20) а так обновляет, за милую душу, именно cf, если явно указать

(22) если конфа поставщика есть в списке манифеста в cf - то обновит, если более древняя - будет ошибка...

(23) можно сначала сравнить на потомка предыдущий релиз, а потом обновить на нужный

(16) Спасибо за список. Пригодится...

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

(24) в сабже главная проблема - это

"как обновить конфигурацию поставщика", она обновляется только 3 способами
1. штатными обновлениями
2. загрузкой типовой cf без сравнения объединения
3. и есть еще один не штатный способ (копирование таблиц)

(26)
0. Сравнить с конфигурацией из файла с постановкой на поддержку.

(25) попробуй просто через cf обновить с установкой на поддержку

+(28) со снятыми флажками

(0) горевать. Простого решения нет. Надо напильник и много времени.

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

(10) А чего искать? Сохраняй конфигурацию поставщика в файл и догоняй до текущего релиза.

(12) Гроши. Смело переводи на типовой релиз. Добавленные реквизиты можешь оставить.

(26) Есть еще способ снять с поддержки полностью, и сделать сравнить / объединить с цфкой поставщика, тогда конфиг поставщика встанет (спросит при обновлении поставить на поддержку или нет). В сабже я так понял основная проблема как разделить доработки, то что уже обновлено, то что требуется обновить, ответ на этот вопрос - руками, больше никак.

(31) с учетом (25) отличный совет.
Представьте себя на месте заказчика: вы много лет пилили управленческий учет, пришел новый 1сник и обновил базу на типовую потому, что ему так обмены удобней настраивать!

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

(35) зачем ему всё это? У него и так всё обновлено. Просто надо догнать конфу поставщика до нужной. Для этого простозапускать обновления со всеми снятыми галками.

Подтянуть конфигурацию поставщика до актуальной версии? Это не сложно - всего одно обновление.

Тоже как-то возился с аналогичной проблемной базой. Полностью снимал с поддержки и накатывал последний cf с постановкой на поддержку. Но была проблема с тем, что одинаковые по имени метаданные не стыковались друг с другом. Если объединить не глядя, данные будут удалены...
Приходилось работать руками. Сделал. 90% метаданных были на поддержке.
Прикол был позже. Очередной программист не смог добавить свой быдлокод и снял всё с поддержки, удалив конфигурацию поставщика. И опять мне дали обновлять эту базу. Повысил им ставку часа, клиент отпал.

(36) На заметку

(36) при этом будут удалятся новые реквизиты...

я так пробовал, сильно хуже чем описанная мною методика....


(25) сейчас пишу подсистему "ЛО" легкий/локальный обмен внутри холдинга. В качестве идеологии беру старый МОД + отдельное MS-SQL хранилище.

То есть все настройки хранятся внутри узла, а все связи в хранилище.

Подсистема полностью автономна (не меняет ни один типовой объект), меню подключаются через расширение.

Минусы:
1. затачивается только на план счетов.
2. по функционалу уступает КД
3. требует включения себя в конфигурацию (снятие с поддержки с невозможностью обновления в пакетном режиме)

Плюсы:
1. настраивать может пользователь а не админ
2. не нужна КД
3. работает на абсолютно любых конфигурациях где есть план счетов
4. Не требует снятия с поддержки ни одного типового объекта
5. Не требует изменения правил при смене версий источника/получателя (кроме критичных где есть удаление метаданных)

(40) Новый БиТ-финанс? :)

(40) не удаляются новые реквизиты.

(41) нет, это чистый обмен и не обязательно с 1с...

у нас планируется на нем
примерно 20 баз 1с, 2 системы оракла и возможно еще чего будет, там посмотрим... Делается в противовес кривому обмену УХ (как потомку консолидации).