Навеяно с трудностями обновления за кривыми обновлялщиками.
И моими ветками:
Как себе облегчить путь обновления, когда обновляешь за недалекими обновлялщиками?
Как вы обновляете базы бухии с измененным составом предопределенных субконто.

Суть!!!

Есть база БП 3.0 С доработками .
Кто-то (не далекий или криворукий или пофигист) обновляет так что у него:
- релиз основной базы   3.0.25.1 (не пугайтесь это Казахстанские релизы)
- релиз конфы поставщика 3.0.19.3
На столько я понимаю они просто накатывают СФ-шник методом сравнения и объединения.
Меня это бесит и не приемлем такой метод обновлений.

Мне теперь нужно вернуть в нормальное русло как это обычно делаю.
Даже видосик запилил https://www.youtube.com/watch?v=hBgt1_m5ulw&t=9s

Как же мне хочется найти предыдущих "обновляторов" и пожелать больше ума!
Спасибо за то что уделили внимание.
Может кому полезно моя тема- ветка.

+
Подсчитал что мне нужно пройти 7 обязательных обновлений
чтобы догнать по конфе поставщика!

Зачем? Можно сразу с нужным cf поставщика сравнивать. Ну и в любом случае - это же деньги.

(1) бери сразу 3.0.25.1 и накатывай его

(3) Каким методом? Сравнить и объединить? При этом же конфа поставщика не обновиться?

(4) поддержка - обновление-выбор файла cf поставщика - профит

(0) Я тоже так первый раз обновил в далеком 2000 каком-то, но я никого не бесил, сам исправил)

(5) Не всегда под рукой цельная типовая СФ.  И думаю не всегда этот метод поможет.

(5) "Файл не содержит доступных обновлений" :)

Документации по конфигурации поставщика - как кот нассал и никто особо не интересуется. Половина 1Сников не знает - при сохранении конфигурации в файл cf - будет ли в этом файле конфигурация поставщика или нет.

(0) Можно просто в таких случаях взять и дообновлять конфу поставщика, не трогая основную конфу.

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

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

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

(5) Попробовал как вы указали.
Не взлетело. При нажатии кнопки выполнить при объединении куча ошибок.
Ошибки типа такие....:

На удаляемый объект Подсистема.ИнтернетПоддержкаПользователей.Подсистема.Новости.Подсистема.КатегоризацияНовостей есть ссылки в объектах основной конфигурации:
ФункциональнаяОпция.Новости_РазрешенаРаботаСНовостями.Состав
На удаляемый объект Подсистема.ИнтернетПоддержкаПользователей.Подсистема.Новости.Подсистема.НастройкиНовостей есть ссылки в объектах основной конфигурации:
ФункциональнаяОпция.Новости_РазрешенаРаботаСНовостями.Состав
На удаляемый объект Подсистема.ИнтернетПоддержкаПользователей.Подсистема.Новости.Подсистема.РедактированиеНовостей есть ссылки в объектах основной конфигурации:
ФункциональнаяОпция.Новости_РазрешенаРаботаСНовостями.Состав

(13) "Потом не забудь включить поддержку у измененных объектов" - Разве так можно?

(15) она сбросится на "снят", нужно поставить на "редактируется с сохранением поддержки"

(16) Спасибо за совет. Такой метод почти не юзал. Или очень давно возможно пробовал так.

Но вот сравнил конфу базы с текущим релизом поставщика.
Разница приличная даже план счетов другой ((( Короче без описания хотелок тяжко.

Как-то несколько дней восстановил подобную отраслевую конфигурацию с двумя конфигурациями на поддержке. С целью облегчить себе работу на будущее.  Будущего не наступило. Заказчик менял программистов как перчатки и однажды конфигурация опять оказалась в состоянии полного снятия с поддержки без конфигураций поставщика. Кто-то печатную форму не смог по другому доработать. Бросил это неблагодарное дело.

Еще вы замечали что конфа поставщика отличается от основной даже если не снято с поддержки?

Думаю это косяки разрабов, которые на скорую руку собирают апдейты.

(18)к сожалению только долгосрочные контракты могут являться гарантиями в подобных вопросах... остальное - лотерея

(14) Все галки снять надо. Тогда обновится только конфигурация поставщика.

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

1. Снял с поддержки.
2. Нашел типовую базу с релизом конфы текущей базой для обновления.
3. Выгрузил конфу типовую 3.0.25.1
4. Обновил как советовали в (11).
5. Все вроде норм. Потом вернул подержку всем объектам.
6. Но вот при обновлении на следующий релиз стандартным методом подозрительно обнаружил большую разницу во многих объектах.
7. Сравнил базу самописку с типовой в релизе 3.0.25.1 вижу много отличий. И как понимаю даже в одной типовой редакции могут быть отличия конфы поставщика и конфы самой базы, даже не тронутые нами. То есть это видимо в самих типовых такое различие от разрабов (((

(22)чем вариант в (5) не подошел?
http://forums.kuban.ru/showthread.php?p=22885234&posted=1
"Обнови конфигурацию поставщика.
Поддержка-Обновить конфигурацию-выбираешь cf 2.0.31.7
В окне сравнения конфигураций снимаешь все галки и нажимаешь Выполнить.

Уже давно сталкиваюсь с данной проблемой но сейчас решил навести порядок.
Есть измененная конфига, при обновлениях стал вываливать весь список объектов конфигурации, а отличие только одно, изменен порядок следования объектов.
Добавленные объекты в низ списка двигал, объединял с конфигурацией, с признаком взять порядок из файла, и все равно порядок не сходиться.
Решение оказалось достаточно простым просто надо было знать где у него кнопка.
Конфигурация -> Поддержка -> Настройка поддержки...
Кнопка "Сравнить и объеденить".
Произойдет сравнение основной конфигурации с конфигурацией поставщика в режиме "взять порядок из конфигурации поставщика". И вуаля, порядок востановлен."

(23) Ответ в (11)

(0) Меня удивляет, когда криво обновляют вроде нормальные люди, не новички, не первый год в профессии. В отпуск сходил, коллеги каким-то образом обновили БП3 за 3.0.67 на 3.0.69 так, что куча объектов перестала соответствовать конфигурации поставщика. Хз что это было, объединил с подходящим cf-ником, вроде нормально. Немного стул прогорел, но в итоге не стал даже спрашивать что курил тот, кто обновлял.

Бесит когда говорят что кто-то делает неправильно, а как исправить и сами не знают.

(26) Детей делают?

(26) Я знаю. Но это очень сложно.
До сих парюсь после обновы ошибки в предриятии.

Хочешь дам базу обновить всю выручку за обновы отдам тебе сам ни копейки не возьму?

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

(29) если не обновлять конфу поставщика типовые обновления нельзя использовать от слова "совсем"

(30) можно иметь отдельную типовую базу для получения полного cf-ника поставщика (в ней данные вообще не нужны). Хотя сейчас уже многие конфигурации на сайте обновления доступны в виде полного cf-файла.
Это если доработок большое количество.

(31) Если предполагается что база всегда будет обновляться типовыми обновлениями с учетом доработок то пусть и будет конфа поставщика. Не зря же ведь все это придумано? Так проще обновлять.

(29) Чтоб дважды измененные можно было сделать

(0) А чего жаловаться, они ж тебе работу дают :)

Чем вам не нравится восстановление конфигурации поставщика через "Загрузить конфигурацию из файла"?

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

(22) "То есть это видимо в самих типовых такое различие от разрабов" - не совсем так. Почитай ссылку https://its.1c.ru/db/metod8dev#content:2299:hdoc начиная с предложения "Теперь рассмотрим алгоритмы сопоставления объектов. Существуют три варианта...", подумай.
Грубо говоря, сравнение и объединение, когда есть или отсутствует конфигурация поставщика, происходит по различным вариантам.

PS: Обновление конфигурации сродни алгебре с её правилами работы с числами. Минус/плюс конфигурация поставщика - самые простые правила "математики" конфигураций :)

(36) Да всегда это происходит. Я даже не обращаю на эти мелочи. Но ведь еще бывает то код даже отличается!

(35) Что и куда предлагается загружать?

1. Выгружаешь конфигурацию поставщика.
2. Создаешь пустую файловую базу. Туда заливаешь конфигурацию поставщика.
3. В этой файловой базе обновляешь конфигурацию до релиза основной конфигурации рабочей базы.
4. Убираешь замки и накатываешь через сравнение/объединение нетиповые изменения из основной конфигурации.
5. Выгружаешь cf из файловой базы и загружаешь в рабочую базу. Все.

(41) Пункт 4 предлагаешь что ли каждый раз делать? Затрахаешься замки убирать там, где доработано. Короче ты геморройный вариант предложил :)

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

(43) "Это вариант как исправить текущую ситуацию, когда версия конфы поставщика отличается от основной" // Так через ту же поддержку можно конфу поставщика догнать до актуального релиза, не?
"Дальше все обновлять правильно - через "поддержка - обновить конфигурацию"" // Когда готовишь файл - да. На проде флажки расставлять некогда (штатное сохранение этих флажков не работает от релиза к релизу, плюс имеет скрытые ошибки, т.е. ненадежное), туда уже полную загрузку конфы, подготовленной таким образом.
"в этой базе и так сняты все замки, раз обновляли релизы через "сравнение/объединение"" // Конечно же ошибочный вывод.

(41) - (44) Я вот вчера хотел сделать так.

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

И после этого залить не методом обновления а прямо загрузить конфу.

Так не? опасно???

(45) Не опасно. Можно перестраховаться: перед загрузкой конфы в рабочую базу сравнить два cf-ника. Должно быть так: основные конфигурации не отличаются, а конфигурации поставщиков отличаются (изменения по типовым релизам)

(45)(46) у новых объектов могут быть разные уиды. Я бы не стал так делать

(40) Например в конфе один добавленный реквизит. Пр этом конфигурация поставщика не соответствует.

1 - Выгружаем нетиповую конфу в файл.
2 - Загружаем типовую конфу. Конфигурацию ИБ не обновляем.
3 - Снимаем с поддержки нужные объекты.
4 - Сравнение объединение с нетиповой конфой. Отмечаем нужные объекты.
5 - Сохраняем все.

Внутренние УИДЫ остались те же, добавленные реквизиты не очистились.

Кто то миф пустил еще в середине - конце 2000х что через загрузку нельзя обновлять. До сих пор миф ходит по головам одинесников с 10-15 летним стажем.
Вот здесь описано что у меня УИД должен был измениться https://its.1c.ru/db/metod8dev#content:2291:hdoc, но он не изменился, и реквизит не очистился. Наверное играет роль режим копирования в сравнении объединении.

(48) Можно и так.
В этом методе главное F7 по привычке не нажать)

(49) Сам лично восстановаливал когда-то затертый мною же реквизит дока. Полагаю ты просто сделал грамотно.

(47) Как они будут разными, если ты в продуктив _загружаешь_ конфу? Конфа будет полной копией загружаемой как по УИДам, так и по парам УИД основной - УИД поставщика

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

(52) А, понял о чем ты - о доработках в "старой" конфе, которые потом переносятся в типовую сравнением-объединением и обратно накатываются на ту же инфобазу, где были эти же самые доработки в "старой" конфе. Я б тоже не стал так делать.

(49) "здесь описано что у меня УИД должен был измениться" // Только если флажок копирования поставишь, и то он для совместимости с легами оставлен:
"По умолчанию при объединении конфигурации объекты, отсутствующие в основной конфигурации, добавляются в нее с теми идентификаторами, которые существуют у них в загружаемой конфигурации.

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

"Кто то миф пустил еще в середине - конце 2000х что через загрузку нельзя обновлять" // Ну вот из 8.0, максимум из 8.1 походу это легаси и тянется )

Я тоже против!

Но это приносит офигеть сколько денег!!!!!!!!
Все что 1С творит требует обновления разработок. И клиенты приходят!

В тот момент когда 1С прекратит чудить с кривыми обновлениями и своими переписками .... так все можно считать конец эпох 1Сников.

(58) И без этого хватает куча работ. Причем гораздо интересных чем тупое обновление. Тут нужно усидчивость и внимательность. И никакого творчества.

(59) Ты манин мерс видел?

Маня косяки делает когда накатывает свой мегапрайс на базы клиентов. Вылазит потом "Порядок объекта изменен" по всем объектам метаданных. Маня накатывай аккуратней.

наобновлял!

(0) ты не бесись, ты научись ставить на поддержку за 1 проход

(48) Это примерно как курить на складе пиротехники: идентификаторы и связь с данными могут отличаться в разных версиях одной конфигурации поставщика. Поэтому есть немаленький шанс грохнуть данные.

(49) Ну, повезло. А мог бы и поменяться.

(52) А структура хранения данных?

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

*не поменяется

(68) Это только если идентификаторы в типовой совпадали с теми, что в реальной базе, что не всегда бывает так. Например, если был переход с базовой версии, или с УТ на ERP, например. Да и просто при обновлении бывает что меняются - не зря стали полные конфигурации выкладывать - иногда при последовательном обновлении странные глюки вылезают.

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

(70) Да не факт
1С переименовывает регистр ВычетыНДФЛ в УдалитьВычетыНДФЛ и добавляет новый регистр ВычетыНДФЛ, через 2 релиза старый удаляет.

(71)Ну это да. В (49) кстати интересно написано про конфы на поддержке без включения изменений:

Три уровня работы механизмов
Таким образом, механизмы переноса объектов можно разделить по трем уровням:

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

(70) Идентификаторы типовых. Идентификаторы нетленки как раз скорее всего перенесутся как надо. А вот с типовыми может быть сюрприз у конфигураций с историей.

(73) +1