Можно ли сделать так:
1. Забрать базу у клиента, они пусть пока работают.
2. Сделать обновление, внести необходимые изменения, на копии.
3. Выгрузить цф-ку.
4. Прийти к клиенту и просто загрузить цф. Безо всяких объединений и т.д.

Всё ли сядет нормально?

На 1 релиз можно.

4-й пункт лучше делать через обновить конфигурацию и указать цф-ку

если ничего не удалишь, то да

(1) пачиму? я и на 5-ть прыгал с легкостью не превзойденной.

(0)Если они ничего разрабатывать не будут, то да, делай так, все нормально будет

(5) разрабатывать не будут. Волнует только данные. Не может ли потереться ссылка на какой-нибудь объект конфигурации и при загрузке цф-ки потереть данные этого объекта?

(0) без обновить конфигурацию - у тебя не обновится конфигурация поставщика

+(7) ну её можно потом типовой CFкой обновить при объединении без всяких галочек

(7) обновится.

(6) чем (2) не устраивает?

(9) согласен

(10), ну, например, скоростью. Проще прийти, нажать загрузить конфигурацию и всё, без объединений и сравнений.

(4) говорят, что гуид объектов/реквизитов меняются от релиза к релизу

(12) ну я так делаю. У меня 2 одинаковые базы. Одну как обычно: делаю "обновить". Потом выгружаю cf-ник и загружаю его во вторую базу. Вроде проблем не было.

(13) и что обновлением тоже поломается?

(12) разница в 5-ть мин, макс

я так понимаю, что при обновлении(или сравнении/объединении) объекты сопоставляются по имени. А при полной загрузке ЦФ-ки? Тоже?

Не может получиться так, что у одного и того же, допустим, реквизита изменится гуид. При загрузке ЦФ-ки гуид будет не найден и создастся новый реквизит, соответственно потерев данные из старого реквизита.

(12) у тебя же почасовая оплата. Куда торопиться? У нас ребята приходят, сначала раскладывают пасьянс. Потом если не получается, второй раз раскладывают. Ну и потом запускают обновление.

(17) при обновлении - жестко по УИДам. При загрузить конфигурацию - тоже.

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

ВСЕ.

(20) грит долго, много денег можно получить. А он хочет быстро и мало денег.

(21) быстро и много - это не про 1С, точно

(0) слушай вот его (20). после первых 5 постов остальные даже читать не хотелось

(20) А что с изменениями будет?

(20) в CFU будут данные обновления конфигурации поставщика?

(24)  "Обновляешь полностью свою базу" - означает, что ты обновляешь свою базу с учетом всех изменений.
(25) да, там будет все

(26) Свою = развернутую копию?

(27) да

(0) конфигурация поставщика не обновится

(29) обновится.

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

(31) А я по старперски сравнением объединением и плевал я на конфу поставщика. Зачем она вообще нужна?

(32) Можно сравнивать текущую конфу с конфой поставщика и сразу видеть отличия. Да и при поднятии релиза система именно ее юзает, когда смотрит может ли данная конфа этим апдейтом подниматься.

(30) тоже так раньше думал

(34) у меня обновляется. И, судя по этой ветке, не только у меня.

+(35) все зависит от того как подготовлено само обновление.

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

(37) ну есть типы, которые готовят через сравнение - объединение и т.п..

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

(39) Конфа снимается с поддержки и тупо - загрузить файл.

(33) Это я знаю и поэтому считаю, что это мелочь не стоящая внимания. Но по большому счёту лучше конечно чтобы конфа поставщика была правильная, особенно если делаешь не себе, а клиенту, например.

(40) ты не поверишь, но при загрузке конфа не спрашивает встать ли ей на поддрежку. Загружается и становится не на поддержке. Поборолся я с ней тогда...

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

(20) что то твоя методика не прокатила. По крайней мере следующий апдейт конфы не видит. Опиши поподробнее, если не в лом конечно.
Делал на релизе 8.2.19.68. Траблы начались с того, что сохраненная конфа не прокатила - орет, что не файл поставки и точка.

(44) точно сохранил у себя базу через
Конфигурация - Поставка конфигурации - создать файлы поставки и обновления?

(45) делал и так и типовую поставку сохранял. Сейчас еще разок проверю. Само обновление прокатывает, но следующий апдейт от 1С его не видит.

Danilov ты не с ДИТ случаем?

(44) вынуть руки и воткнуть в плечи

походу хамство на мисте становится просто нормой.

(0) Всегда так и делаю.
Но нужно учесть, что перепрыгивать на много релизов(много это 10 и больше, хотя тут не угадаешь и как повезёт) не хорошо и могут быть проблемы с потерей данных.

Если кому интересно - возился 2 дня, но воспроизвести методику описанную в (20) не удалось. Текущее обновление происходит без проблем, но последующее обновление 1С его не видит. Тестирование проводил на релизе платформы 8.2.19.68.
Релизы конфигурации КА 1.1.39.1, 1.1.40.2 (до которого собственно и делался промежуточный подъем) и далее 1.1.41.1 (который результатов подьема до 1.1.40.2 по предложенной методике не видел).

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

разбираясь с проблемой - накопал на ИТС параллельно
.....Восстановление автоматической поддержки конфигурации поставщика

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

В общем по итогам разборов метод обновления конфигурации через сохранить файл и загрузить - самый безопасный. Поскольку главное - соответвтствие внутренних иденитифкаторов рабочей конфигурации и конфигурации базы данных (при обновлении конфигурации базы данных используется соответствие по идентификаторам, если его нет, то летят данные). Более подробно тут - http://its.1c.ru/db/metod81#content:2291:1.
Все остальное - в топку, как лишний геморрой.

(0) Если будет та база, которую обновляешь не у клиента работать нормально, то и у клиента будет работать. Другое дело, что ты ее не протестишь в полном объеме. Если через кучу релизова то работать не будет почти наверняка, т.к. должна сработать обработка обновления ИБ.

(55) обработка обновления сработает в любом случае.

со старыми объектами которые уже удалены из базы только придется повозиться. Но - это несложно.