Здравствуйте!

Мне нужно было обновить релиз торговли 10.3 до актуального не типовой конфигурации.
Текущий релиз конфигурации 10.3.71.1

https://i.postimg.cc/26xrRD1g/pic00.png

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

https://i.postimg.cc/RZbWywkw/pic01.png
https://i.postimg.cc/c4CZjP05/pic02.png

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

https://i.postimg.cc/T3Wx2myV/pic03.png

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

Подскажите как обновить такую конфигурацию до актуального релиза.

P.S. Я знаю, что торговля 10.3 снята с поддержки, но тем не менее обновить нужно до 10.3.88.3

(0) Обратись в Визард, чтобы они тебе подсказали, как сначала вернуться к типовой УТ, а потом уже обновляй УТ

Понятно, что начать надо с (1), а потом меня смущает вот этот момент <"На первом этапе нужно накатить все апдейты на рабочую конфигурацию, а потом переносить изменения.">.
  Каким образом ты собираешься это делать? Изменения надо переносить из релиза в релиз иначе у тебя пропадет основная конфигурация, в которую вносились изменения. И как ты потом будешь понимать откуда выплыли изменения в конечной конфигурации? Из типовых релизов или ваших доработок?

(2) "Изменения надо переносить из релиза в релиз" - зачем?
Если много релизов - это долго и достаточно бессмысленно.
Берем правленую конфу, делаем копию. Обновляем конфу до нужного релиза, затирая все правки, с приоритетом новой конфигурации поставщика.
Сравниваем копию с конфой поставщика(старой) - видим все правки, которые были до обновления. Сверяем обновленную конфу с конфой поставщика(новой) - видим, какие правки пережили обновление, какие нет.
Проверяем/актуализирум/пишем заново то что не пережило обновление.

(3) <"Обновляем конфу до нужного релиза, затирая все правки, с приоритетом новой конфигурации поставщика.
Сверяем обновленную конфу с конфой поставщика(новой)">

Какие изменения ты тут надеешься увидеть?  Основная конфигурация будет равна Конфигурации поставщика

Из того что ты написал напрашивается вывод вообще обновлений не делать. Взять последнюю конфигурацию поставщика и сравнивать ее со старой рабочей

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

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

(4) "Из того что ты написал напрашивается вывод вообще обновлений не делать. Взять последнюю конфигурацию поставщика и сравнивать ее со старой рабочей" Нет. Так ты не поймешь, где изменение кода поставщика, а где местный колорит (в то, что все правки помечены комментариями я "не верю")

(5) Можно, но зачем? после обновления на 100500 релизов расхождений между новой и старой конфой будут тысячи. И каждое надо проверить, есть там коммент или нет.

Правки прекрасно видно на копии. Просто надо проверять, остались ли они в обновленной.

(7) Можно самому пометить комментариями, до проведения обновлений. С (6) согласен, не учел что какие-то изменения останутся. Но их количество будет минимальным, лучше наверное самому пометить правки, как я писал выше.

(8) Хорошо, возможен и такой вариант

В окне поддержки я выбрал конфигурацию поставщика "Визард" и снял с поддержки.
https://i.postimg.cc/zB2dLfyT/pic01.png
https://i.postimg.cc/fR7BcC3z/pic02.png

Теперь осталась одна конфигурация поставщика
https://i.postimg.cc/cJXhjJMP/pic03.png

Пробую обновиться на релиз 10.3.71.2 и опять получаю окно что файл не содержит доступных обновлений.
https://i.postimg.cc/66Rj6B94/pic04.png

Провал.

Заново захожу в настройку поддержки и сохраняю конфигурацию поставщика.

Потом снимаю с поддержки основную конфигурацию
https://i.postimg.cc/XY2x1Jgm/pic05.png

Затем через меню сравнить и объединить конфигурации из файла пытаюсь обратно на поддержку конфигурацию, выбрав сохраненную конфигурацию поставщика
https://i.postimg.cc/B6FgvCGf/pic06.png
https://i.postimg.cc/mgry94Gw/pic07.png

В окне настройки правил поддержки выбираю "Объект редактируется с сохранением поддержки"
https://i.postimg.cc/5thBDFQ7/pic08.png

Сохраняю конфигурацию.

Опять пытаюсь обновиться до релиза 10.3.71.2, но получаю окно, что файл не содержит доступных обновлений.

Я пробовал обновиться через скачанный на сайте cfu-файл и через ввод логина и пароля в конфигураторе (через сайт 1с)

Такой способ тоже не работает.

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

Не понятно в чём проблема с базой.

/* Мне нужно было обновить релиз торговли 10.3 до актуального не типовой конфигурации */

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

Можно пойти другим путём. Задаём вопрос : "А для чего обновлять" ? Если для реглам. отчётности то идея плохая - десятка же больше не обновляется. Ставим рядом 11, делаем обмены, десятку используем как управленку.

Если для чего-то непонятного нужна именно последняя десятка - ставим рядом именно её (апрельская вроде), обмены будут проще.

(12) Эту Десятку никто бы не трогал, но бухгалтер решила прикрутить модуль работы с ДиаДок, а он будет работать с более свежими релизами торговли.

(12) Для меня обновление не типовой конфы не такая сложная задача. Единственная проблема в том, что не получается накатить типовой релиз, на рабочую конфу. Если пройти этот этап, то дальше пойдёт всё как по маслу.

(14) Может из рабочей базы удалить конфигурацию "Визард сервисы" (тем более что ими никто не пользуется).

Что-то типа Две конфигурации - как одну удалить

Ну, дык, накати сравнением, объединением с cf

(15) Я так делал. Убрал конфу Визарда, но такой способ тоже не помог.

(17) А просто залить типовую конфу 10.3.71.1 без всяких сравнений-объединений не пробовали ?

Вроде как всю фигню должно вычистить.

(18) Загрузкой конфигурации? Типовую надо подготовить с доработками иначе она всё затрёт в рабочей базе

(19)

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

На выходе у Вас база без сюрпризов - все отклонения от типовой Вы контролируете.

(13) /* бухгалтер решила прикрутить модуль работы с ДиаДок, а он будет работать с более свежими релизами торговли */

Кстати, не пробовали разобраться чего он не работает ? Может можно его просто допилить.

Надо попробовать обновить хотя бы один раз с сайта downloads.v8.1c.ru. Конфигуратор сам найдет, какое обновление ставить.

(22) Я пробовал так делать, но 1С пишет, что обновления не найдены.

Написал ещё в техподдержку 1С, но они не охотно помогают по нетиповым конфигурациям.

(0)Если из cfu не встает обнова, надо пробовать из cf. Для этого в тестовой нужно взять типовую конфу и догнать ее обновлениями до нужного релиза.

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