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

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

(1) Я же могу откатиться с помощью дтшника который снял до обновления?

(2) Можешь

(0)Давно занимаешься 1С ?

(4) ну буквально 2-3 месяц

Появляется вопрос, чувак который работал до меня обновлял по этому принципу, что собственно мне и передалось и делал он это на протяжении 3 лет. Как я понимаю никаких ошибок конфликтов не было

(6) Вот представь себе ситуацию. Есть у тебя регистр сведений в нем какие-то данные. И тут 1С решила, что не нужен этот регистр, а данные будем хранить в справочнике. Они создают справочник, регистр пока не удаляют, а переносят данные из регистра в справочник, а регистру к имени добавляют слово Удалить. А вот в следующем релизе регистр уже удаляют.
  Если ты делаешь обновления подряд, то у тебя всё правильно, в первом релизе создался справочник, во втором удалился регистр. А если ты прыгнешь через релиз, то получится, что создастся пустой справочник, а регистр вместе с данными удалится.
   И обновления 1С так и работают.

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

внутри одного релиза (третье число в версии) нормально все будет

(9) даже тут я бы не рисковал

(7) (8) Теперь систему понял, хорошо что успел дтшник старый накинуть до съедения бухгалтерами. Спасибо.

(0) "база нетиповая" а вот с этого места поподробнее.

(10) На странице с обновлениями, есть перечень релизов с какого на кокой можно перепрыгивать.

(13) Это понятно. Я про то, что после обновления на каждый новый релиз по цепочке надо запускать дополнительные обработки для реструктуризации и пересчета. Т.е. запускать пользовательский режим

не надо нагнетать
вполне можно обновляться как в (6)

(15) можно, когда ты проверяешь много нюансов и главное понимаешь их. Тут же человек 2 месяца назад 1С увидел впервые

(6)
А если бы он с крыши прыгать пошел - ты бы за ним? По такому же принципу

(15) ну в какой-то момент можно и попухнуть. Не обязательно сразу, но тем более жетко

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

(17) К чему агрессия не понимаю, я пришел на работу мне показали как делать я так и делал. Ну если вам так интересно с крыши прыгать, то желаю удачи

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

(20) ну смотри. Ты пришел на работу и краном нужно положить плиту. на плите снизу есть метка центра, и такая же метка есть на земле. Матерый крановщик попросил тебя встать на метку и смотреть, когда метка на плите будет над тобой. Тоже согласишься? Ну а чего, у этого крановщика плита ни разу не падала

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

если у тебя возникают подобные (0) вопросы - нельзя

(23)+ когда база небольшая по объему данных
а типовых релизов (прыжков) ну сильно много
бывает проще и быстрей развернуть свежую чистую базу последнего релиза - и перелить данные (неважно как)

(24) ты сейчас научишь его. Перельет данные БП, а отчетность, ЭДО, НДФЛ со страховыми и закрытые периоды потом сюрпризом будут. А если в ней еще и кадровый учет велся?

Спасает от последствий таких обновлений как в (0) только то, что 1С достаточно долго не удаляет переименованный на "Удалить..." объект метаданных, поэтому при регулярных обновлениях, может быть все нормально, но если база долго не обновлялась и решили таких способом накатить кучу релизов, то наверняка будут потери данных.

(11) Обновляешься, конечно, не всеми релизами подряд, а по цепочке, которая есть на сайте ИТС.

(26) 1с даже может его еще годы не удалять, но обработчики переноса он пропустит, увидят это сильно не сразу. Выправлять потом нужен будет уже специалист с опытом.

опять же речь идет о бухгалтерии с изменениями. Надо еще внимательно смотреть на эти художества. Снятие с поддержки бухгалтерии говорит о многом о том кто это делал. С учетом того, что есть расширения, снимать БП с поддержки такое себе

(28) >>  обработчики переноса он пропустит

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

Самое страшное, что может случиться, это ошибки в коде этих самых обработчиков обновления.
Например, в некоем обработчике обновления есть обращение к какому-то реквизиту НашРеквизит. В каком-то из последующих релизов этот реквизит был переименован в УдалитьНашРеквизит. Разумеется такой обработчик вывалится с ошибкой при обращении к реквизиту по старому имени. Разработчики в 1С за такими коллизиями не следят. Придётся править код обработчика самому.
Хуже когда похожие коллизии возникают в результате изменения логики прикладного решения. Например, поменяли типы значений реквизитов, какие-то особенности заполнения, или предусматривалась ручная обработка данных пользователем (установить какую-то константу надо было после определённого обновления). Ошибку в таком случае обработчик может не выдать, но и отработать некорректно.

(30) А как же отложенное обновление ИБ ?

(20) Мальчик, веди себя хорошо!

(15)По вашему компания 1С не советует обновляться если не выполнены обработчики обновления на текущий релиз и выводит вот такую картинку просто так?

(15) Это надо знать, в каких релизах удаляли какие данные и обработчики обновлений совсем. К примеру, в ERP 2.5.12 поудаляли "исторические" обработчики обновлений, а в 2.5.17 выпилили пачку регистров накопления и, до кучи, регистр с присоединенными файлами. Я, кстати, как то, было дело давненько, заливкой типовой CF-ки в БП (тоже типовую, но полученную обновлением с версии 2.0) прибил регистр с присоединенными файлами, т.е. старая отчетность перестала открываться, благо им она не нужна была.
Кстати, впредь можете в таких случаях хранилище создавать, обновлять копию к примеру, а потом класть в хранилище и подтягивать в рабочую.

(30) "Все обработчики обновления отрабатывают последовательно вне зависимости от того с какого и на какой релиз конфигурации ты обновляешься. Из конфигурации эти обработчики не удаляются."
Удаляются только так, по крайней мере, в EPR между релизами это обычное дело.