Обновление типовой конфигурации сразу на несколько релизов (8.2) [не для начинающих]
Скажу сразу – у описываемого метода есть свои подводные камни, поэтому перед его применением советую дочитать статью до конца. Если у вас есть интернет и доступ к пользовательскому разделу сайта 1С, а конфигурация у вас «родная» от 1С и в ней есть обработка «Обновление конфигурации» (см. меню Сервис) – воспользуйтесь ею и обновите конфигурацию через интернет. Будет и проще, и надежнее (хотя вряд ли быстрее).
Обработка обновления точно есть в конфигурации «Бухгалтерия предприятия» ред. 2.0, а также в несколько урезанном варианте – в УПП ред. 1.3 (находится в подменю «Интернет-поддержка пользователей» меню Сервис). В этих обработках есть справка, причем довольно подробная. Про остальные конфигурации от 1С точно сказать не могу, но подозреваю, что и в них подобные обработки присутствуют. Попробуйте с их помощью обновить конфигурацию через интернет и возвращайтесь к данной статье, если потерпите неудачу.
Статья не рассматривает вопросы перехода на новую редакцию типовой конфигурации, а также иные сложные случаи. Они успешно описаны более опытными в этих вопросах коллегами, так что если ваш случай сложный – вам сюда: //infostart.ru/public/18596/ (комментарии также есть смысл почитать). Ну а в данной статье описан процесс обновления не слишком запущенной конфигурации, зато по возможности подробно и с комментариями.
Итак, что же делать, если интернета/доступа к сайту 1С у вас нет, а желание сэкономить время и упростить себе жизнь есть? Даже в этом случае можно схитрить и не ставить все обновления последовательно. Для этого нужна возможность тем или иным способом получить конфигурацию поставщика из другой базы, уже обновленной до интересующего вас (очевидно, последнего) релиза.
Выгрузка конфигурации поставщика, или "где взять новую конфу?"
- Иногда бывает, что вы сами или ваши коллеги ранее установили себе "полный" установочный комплект новой конфигурации, а дистрибутив затем благополучно потерялся. Не беда: открываете каталог шаблонов (обычно он находится тут: "C:\Users\ИмяВашегоПользователяWindows\AppData\Roaming\1C\1Cv82\tmplts"), и в соответствующей подпапке (например, "1c\Accounting\2_0_47_5") находите файл 1Cv8.cf от нужной вам версии конфигурации. Не перепутайте с .cfu, он вам не подойдет. Если файла .cf в папке шаблонов найти не удалось, то вам не повезло - у вас был дистрибутив обновления, а не полный установочный комплект.
- Если готовый .cf конфигурации поставщика найти не удалось, пробуем найти у себя или знакомых базу нужной вам конфигурации. Она может быть и нетиповой, но должна быть корректно обновлена до нужного вам релиза.
- В конфигураторе через меню «Конфигурация – Поддержка – Настройка поддержки» проверяем номер версии конфигурации поставщика. Если версия подходящая, то прямо оттуда по кнопке «Сохранить в файл» выгружаем файл .cf – он-то нам и нужен.
Описанным выше способом вы из любой базы выгрузите именно ТИПОВУЮ конфигурацию основного поставщика, причем именно той версии, которая указана в окне настроек поддержки (см. статью «Настройка поддержки» с ИТС). Если база находится у знакомых, то попросите их выгрузить конфигурацию поставщика (можно под вашу диктовку), а полученный .cf прислать вам с почтовым голубем.
Если совсем нет возможности найти готовую конфигурацию - ищем наиболее свежий дистрибутив (установочную версию конфигурации). Дистрибутивы есть на партнерских дисках ИТС либо установочных дисках из комплекта поставки конфигурации, так что наиболее свежий дистрибутив проще всего найти у того, кто покупал программу недавно, или у франчайзи. Найденный дистрибутив устанавливаем к себе на компьютер и создаем новую базу по шаблону из данного дистрибутива (НЕ демо, т.к. данные из демки нам не нужны!).
Если дистрибутив был установлен, но после этого "потерялся", нужные вам файлы все равно можно найти. Как это сделать - см. выше (пункт 1 в списке). В папке с шаблоном конфигурации ищите файл 1Cv8new.dt - это архив пустой базы соответствующего релиза. Если нашли, то создаем новую информационную базу без конфигурации, открываем ее Конфигуратором и разворачиваем в нее найденный архив 1Cv8new.dt (меню «Администрирование - Загрузить информационную базу»).
Затем:
- Находим и устанавливаем на компьютер более поздние обновления конфигурации. Проще установить их все, т.к. механизм обновления потом сам предложит вам пропустить те релизы, которые могут быть пропущены. Но вы также можете последовать советам из //infostart.ru/public/18596/ и сами составить себе цепочку из необходимых релизов, а затем установить только их.
- Открываем пустую базу в конфигураторе, начинаем последовательно применять к ней обновления через меню «Конфигурация – Поддержка – Обновить конфигурацию – Поиск доступных обновлений».
- Информационную базу НЕ обновляем (незачем тратить на это время, т.к. база-то у нас пустая).
- По окончании процесса выгружаем .cf-ник итоговой конфигурации поставщика («Конфигурация – Поддержка – Настройка поддержки - Сохранить в файл», заодно проверим версию). Его будем использовать для обновления рабочей базы.
Выполнение обновления с помощью конфигурации поставщика
Вариант с использованием обработки «Обновление конфигурации»
Открываем базу в режиме предприятия, запускаем обработку. Выбираем способ получения обновлений «Локальный или сетевой каталог», на следующей странице указываем путь к получившемуся у нас файлу .cf. Далее на все соглашаемся, в случае сомнений смело пользуемся справкой (напомню, она весьма подробная).
Обработка сама создаст вам резервную копию, обновит конфигурацию и проверит результат обновления, а в случае ошибки автоматически восстановит базу в исходное состояние. Место сохранения резервной копии настраивается отдельно: по умолчанию создается временная копия, которая после успешного обновления удаляется, но я рекомендовал бы указать свой путь сохранения.
Вариант с использованием конфигуратора
- Обновляем платформу, если необходимо
- В конфигураторе открываем базу, которую нужно обновить.
- Делаем резервную копию (меню «Администрирование - Выгрузить информационную базу»).
- Через меню «Конфигурация – Поддержка - Обновить конфигурацию - Выбор файла обновления» указываем путь к нашему .cf-нику с последним релизом конфигурации поставщика.
- Обновляем конфигурацию.
- Соглашаемся на обновление информационной базы
- Читаем внимательно список изменений перед тем, как принять их! Если сомневаетесь - отклоняйте!
- Открываем базу в режиме предприятия.
- Соглашаемся на все и ждем выполнения обработки обновления.
- Проверяем, чтобы обработка обновления базы запустилась и выполнилась без ошибок, последовательно от исходного релиза до текущего.
- Внимательно читаем служебные сообщения!
- Если все прошло хорошо – радуемся.
Мне таким образом удалось обновить конфигурацию БП с релиза 2.0.22.1 до 2.0.32.4 и затем через .cfu до 2.0.32.6. База файловая, платформа 8.2.15.289. Результат всех удовлетворил, обновление (через конфигуратор) заняло менее пяти минут.
Альтернативные способы быстрого обновления типовой базы - такие, например, как снятие с поддержки и загрузка .cf - работают не быстрее (проверено лично с секундомером), а лишних телодвижений требуют больше, поэтому рекомендовать их не стану.
ВНИМАНИЕ!
Если мы проскочим при таком обновлении через ключевой релиз, в котором выполнялось удаление или замена каких-либо объектов метаданных, возникает риск потери данных. В особо ответственных случаях желательно перепроверить себя через сравнение и объединение и в случае малейших сомнений обновляться классическим методом (как минимум - до последнего ключевого релиза), не забывая запускать базу в режиме предприятия после каждого обновления и внимательно отслеживать ход выполнения обработок обновления ИБ.
P.S. Есть информация, что у кого-то после такого обновления были проблемы с дальнейшим обновлением базы через .cfu.
Я подозреваю, что просто база была битая, но для пущей надежности можно сделать .cf-ник предпоследнего релиза и обновить базу на него. Затем отдельно обновить до последнего релиза через .cfu и лично убедиться, что база благополучно обновляется. Впрочем, на мой взгляд, при таких опасениях вообще не следует пользоваться подобными "ускоряющими" методиками. ))
Удачи в работе!
Искренне Ваш, Владислав Рожевский (СПб, 2013)
Вступайте в нашу телеграмм-группу Инфостарт
обновление конфигурация поставщика релиз
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Инструменты администратора БД Обновление 1С Системный администратор Разработчик 1С 8.3 Абонемент ($m)
Если обновление 1С уже падало с "Записи регистра сведений стали неуникальными", вы знаете, что платформа называет только первый такой регистр, и каждый следующий всплывает новым запуском обновления. Проверьте заранее: снимите слепок регистров в базе с новой конфигурацией и нажмите "Проверить" в рабочей. Обработка покажет все регистры сведений, где записи после обновления совпадут по измерениям, и сами группы таких записей: укороченная строка, меньше знаков после запятой, укрупнённая периодичность, убранный из составного тип. Удалённое измерение называет, но записи по нему не считает. Что разобрать не может, называет с причиной и в "дублей не найдено" не записывает. Только чтение, без доступа к таблицам СУБД.
10 стартмани
09.11.2026 183 0 nedomolkov.ivan 0
Корректировка данных Обновление 1С Системный администратор Разработчик 1С 8.3 1С 8.5 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Россия Абонемент ($m)
Сама поднимает новый релиз во временной копии и проверяет на нём обработки, отчёты, расширения и ваши доработки: пропавшие методы, объекты, поля запросов, перехваты, готовность к 8.5. В рабочую базу ничего не пишет.
5 стартмани
05.11.2026 266 2 Iliaelagin 0
Архивирование (backup) Обновление 1С Системный администратор Разработчик 1С 8.3 Бесплатно (free)
Платформа 8.3.17, MS SQL Server: обновление конфигурации падает через 15 секунд на этапе обновления предопределённых данных, и конфигуратор при каждом входе предлагает только повторить. Проверьте у себя, когда сделана последняя полная копия базы: у нас её не было почти месяц. Разбор по минутам: что не помогло (перезапуск агента сервера 1С, перезагрузка, пакетный /UpdateDBCfg, три совета со стороны) и почему. Как ibcmd достал .dt из базы, которая не открывается, и как новую базу подставили под старым именем в кластере 1С через rac, не трогая пользователей. Простой 57 минут, потерь данных нет. Отдельно ошибки ИИ-агента Claude, который работал на сервере, и порядок действий на случай, если это случилось у вас.
03.11.2026 536 nedomolkov.ivan 12
Обновление 1С Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Бесплатно (free)
Вторая часть серии о переходе ERP 2.5 на 2.6. Я сравнил чистые выгрузки 2.5.27.88, 2.6.1.70 и 2.6.2.59 и выписал то, чего нет в официальных описаниях версий: какие экспортные методы удалены поимённо, какие документы больше нельзя создать и при каком условии, что переименовали без предупреждения. Из двенадцати механизмов, от которых отказывается 1С, к 2.6.2 удалены только два, а большая часть удалённого к ним не относится. Отдельно разбираю, почему перехватчики &ИзменениеИКонтроль ломаются на процедурах, где поменялся только английский текст, и почему доработки выгоднее готовить сразу под 2.6.2. Будет полезно разработчикам, которые сопровождают расширения и внешние обработки на ERP 2.5.27, и тем, кто планирует сроки перехода.
20.10.2026 950 lexatsch 6
Обновление 1С Разработчик 1С 8.3 1С 8.5 Абонемент ($m)
Перед обновлением типовой конфигурации обработка читает код ваших доработок — внешних обработок, отчетов и расширений — и сверяет каждое обращение к конфигурации со старым и новым релизом. Результат — один отчет по всем доработкам: файл и строка, сам фрагмент кода и понятная причина («метод теперь принимает один параметр», «значение перечисления удалено», «перехватываемый метод не найден»). Исходники релизов и обработок можно подготовить прямо из обработки — пакетным запуском Конфигуратора.
3 стартмани
19.10.2026 320 1 InShallaH 0
Обновление 1С Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Бесплатно (free)
1С считает, что перейти с ERP 2.5 на 2.6 не сложнее, чем обновиться между версиями длительной поддержки, а обязательным переход станет не раньше 30 апреля 2027 года. Я решил проверить это заранее на нашей доработанной ERP 2.5.27, где есть два больших расширения и 517 внешних отчётов и обработок. Форма готовности нашла четыре механизма, которые надо перевести, а про код промолчала. Проверка применимости на чистой 2.6.1 выдала 478 проблем, и настоящих среди них меньше сотни. А сверка кода со словарём изменений нашла ещё 63 проблемы, которых проверка применимости вообще не видит. Часть из них не даст открыть модуль, остальные вылезут уже у пользователей. Рассказываю, как проверить применимость расширения к 2.6.1 без записи в базу, что ловит компилятор, что ломается чаще всего и чем это заменить.
16.10.2026 650 lexatsch 0
Обновление 1С 1С:Предприятие 8 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1C:ERP Бесплатно (free)
Партизанские методы оптимизации обновления тяжёлых баз
13.10.2026 1333 1c-intelligence 2
Инструментарий разработчика Обновление 1С Разработчик 1С 8.3 Бесплатно (free)
Бесплатная внешняя обработка: до обновления типовой показывает, какие ваши внешние обработки и печатные формы после него упадут. Находит в их коде вызовы общих модулей и менеджеров типовой и сверяет каждый с текущей конфигурацией и с выгрузкой нового релиза: есть ли метод, экспортный ли, сходится ли число параметров. Обработки берёт из справочника или из папки .epf и .erf, без конфигуратора. У каждого вызова статус, строка и причина.
29.09.2026 1188 140 nedomolkov.ivan 2
Собственно, Вы велосипед не изобрели: так обновляются по бухне уже миллион лет. Одинэсники там бомб замедленного действия никогда не подкладывали.
Но соглашусь, что если такая обработка в конфигурации есть, то имеет смысл воспользоваться ей, т.к. в ней многое удобно автоматизировано. В случае отсутствия интернета или доступа к пользовательскому сайту 1С (для чего, в общем-то, статья и писалась) можно указать ей принудительно в качестве файла обновления подготовленный нами файл .cf.
Для ранних релизов КА, УПП, ЗУП - да.
Сейчас и одинэсники поумнели, да и пользователи стали соблюдать гигиену - перестали ждать, когда релиз протухнет
Перестаньте истерить, уважаемый. Вы думаете, что мальчик-ИТСник, которого вызвали к клиенту(за час оплаты), с которого он в ЛУЧШЕМ случае получит 200-300 рублей, будет последовательно обновлять 5-10 релизов на полудохлом компе пол-дня? Или будет "марьиванне впаривать", что за один час ее обновить импасибл? Мол, дайте еще три раза по столько? Да вся страна так клиентов обновляет!
Так что при написании статьи расчет именно на конечных пользователей не делался, хотя им она тоже может пригодиться.
А советами в любом случае надо пользоваться с осторожностью, да и предупреждений на этот счет в статье более чем достаточно.
Обработка обновления информационной базы при таком обновлении тоже запускается, и все необходимые действия выполняются последовательно (заполняются константы, справочники и т.п.). Только не для одного релиза, а для нескольких подряд. Думаю, что если 1С штатно предусмотрела такой функционал в своей _типовой_ обработке, то им можно пользоваться. Необходимость читать и анализировать служебные сообщения, которые выводит обработка, никто не отменял, в статье об этом сказано.
Не всё так просто. Если после обновления вылазит отдельная форма, предлагающая запустить некую обработку, то перепрыгивать через такой релиз НЕЛЬЗЯ! К счастью, такого рода подводные камни до сих пор встречались в ЗУП, УТ, КА, УПП. В бухне пока их не наблюдалось.
В УПП 1.2 подобная обработка тоже была, помню (мы даже допиливали ее напильником под наши нужды, когда обновляли сильно нетиповую УПП сразу на много релизов). Думаю, что аналоги есть и в УПП 1.3, и в УТ, и в КА, просто времени сейчас нет заглянуть и проверить.
Всем знакомы случаи, когда бухгалтера говорят "До вашего (1с) обновления принтер/excel работал, а теперь -- нет". Доказываешь потом, что ты не верблюд. А тут сам подставляешься.
При мне был случай, неправильно обновили 77 бух базовую на 77 бух обычную. База не заработала и копии не осталось. Я пытался исправить и что-то там не получалось. В конце-концов наш директор сказал той фирме -- "Мы нелицензионные программы обновлять не обязаны" :). Косвенно и меня виновным сделали.
Если конфа изменённая, то нужно накатывать .cf через сравнение и объединение.
Если типовая, то снимаем с поддержки и тупо загружаем последний .cf-ник. Система сама предложит вернуться на поддержку.
Даже если у вас конфа измененная, то обновлять ее через предусмотренную для этого функцию "Обновить конфигурацию" намного удобнее и быстрее.
Про "удобнее": если в вашей конфигурации есть какие-то изменения, то откроется такое же окно, как при сравнении и объединении. Но при этом у вас заранее галочками отмечены только те объекты, которые были изменены в новой конфигурации (по сравнению с конфигурацией поставщика). Пример: вы включили возможность изменений в своей конфигурации и что-то сделали с документом "Авансовый отчет". Потом вышло обновление, в котором фирма 1С что-то изменила в счет-фактуре. При обновлении через меню "Обновить конфигурацию" у вас будут видны все различия (и в авансовом отчете, и в счет-фактуре), но галочкой отметится только счет-фактура, т.к. по сравнению с конфигурацией поставщика изменился только этот документ. Вам остается только пробежаться по всем объектам, помеченным галочками, чтобы проверить, были ли внесены в них изменения вами.
Про "быстрее":
через "сравнить и объединить" у вас, фактически, 3 операции: снять с поддержки --> сравнить и объединить --> поставить на поддержку
через обновление у вас одна операция (да и та только в том случае, если вы вносили изменения в конфигурацию): сравнить и объединить
Я вас не понял. Может, вы что-то перепутали? Я писал:
(28)
Если конфа изменённая, то нужно накатывать .cf через сравнение и объединение.
Если типовая, то снимаем с поддержки и тупо загружаем последний .cf-ник. Система сама предложит вернуться на поддержку.
Ответили: (31) (36) (50)
[+] Tarlich; [−]
Изменено: cratos2 - 17.02.12 11:13
Если ТИПОВАЯ, то без снятия с поддержки вы никак не сможете ЗАГРУЗИТЬ НЕ СРАВНИВАЯ, к примеру 2.0.22.1 до 2.0.31.1 (если конечно не создавался специальный .cfu для такого прыжка). - минимум действий (два, а не 3 как вы описали - на поддержку платформа сама предложит встать), максимум эффекта.
Если нетиповая, то я написал что нужно делать. Читайте внимательнее.
Вообще-то в статье как раз описывается штатный способ обновления в такой ситуации, безо всякого снятия с поддержки.
Откуда такая уверенность, что типовой механизм обновления конфигурации через новый .cf поставщика отработает хуже/медленнее, чем снятие с поддержки и последующая загрузка того же нового .cf?
Работая в фирме-франчайзи, слышал множество фактов обновления баз самими клиентами через интернет с убийством базы. Понимаю, что дело могло быть в обрыве интернет-связи, либо в ошибках в коде обработки обновления, либо еще что-нибудь, но факт оставался таким - база не работала.
Даже при снятой поддержке [типовой конфы], при выполнении команды Загрузить конфигурацию из файла платформа анализирует .cf и выдаёт сообщение о возможности сравнения и объединения (чем я и предлагаю воспользоваться). Далее, если это действительно потомок текущей конфигурации, то платформа предложит встать на поддержку. Остаётся нажать F7 и фокус-покус удался!
Все делается предельно просто - меню "Конфигурация --> Поддержка --> Обновить конфигурацию --> Выбрать файл вручную --> [указать готовый cf-ник последней версии]". Все.
Платформа 8.2.15.289. Обновлял файловую версию демо-базы типовой БП 2.0.22.1 на 2.0.32.6.
Железо: ноутбук с win7 x64, core i3, hdd 7200rpm, 4gb ram.
Обновлял непосредственно из конфигуратора, без обработок. В случае появления диалоговых окон отвечал сразу, задержка составляла не более секунды на 1 окно.
Результаты:
Через стандартное обновление от нажатия на кнопку "Обновить" до окончания обновления ИБ - 3 мин. 30 сек.
Через снятие с поддержки и загрузку .cf от нажатия на кнопку "Включить возможность изменения" до окончания обновления ИБ - 3 мин. 40 сек. Конфигурация действительно встала на поддержку автоматически, но в целом для обновления ручных операций потребовалось больше (что и так было очевидно).
Возможно, обновлять ИБ не следовало, но при одинаковом железе и одинаковых демо-базах это было допустимо, я полагаю.
Резюме: метод обновления, предложенный cratos2 как более эффективный, никакого реального выигрыша во времени не дает.
Еще раз повторю свою рекомендацию, на сей раз словами hulio:
Напоминаю, что исходная статья была об обновлении _типовой_ конфигурации, снимать которую с поддержки не вижу ни малейшего смысла.
Во-первых, обновление через инет по CFU и обновление через CF - это крайне противоположные вещи, и одно как раз исправляет проблемы другого.
Во-вторых, если вы накатываете CF на СУЩЕСТВУЮЩИЕ данные методом Загрузить конфигурацию - у вас крайне высока вероятность, что не совпадут идентификаторы объектов. И база вообще не поднимется, т.е. потеряете все данные.
CFU сделан именно для правильного и ЧАДЯЩЕГО обновления конфы.
Если никак через CFU - то с CF на рабочей базе ТОЛЬКО через Сравнение-Объединение.
Статья же - обрывки методик обновления, сваленные в кучу, не понятые автором и вводящие в заблуждение других.
А самое главное, из-за чего статья не имеет право быть в таком виде - нет никаких предупреждений и разбора последствий подобных обновлений. А наоборот, советы "так и делать".
Считаю, что стаья крайне вредна и должна быть переработана полностью, вместе с повышением квалификации автора.
Как мне кажется, вы просмотрели статью невнимательно и сделали из нее неверные выводы (что, впрочем, отчасти также и моя вина - если один человек смог понять ее неправильно, то сможет и другой). Постараюсь как-то по пунктам ответить на замечания, а затем подумаю, как переработать статью во избежание подобных непоняток в будущем.
Во-первых, НИГДЕ в статье не сказано про использование метода "Загрузить конфигурацию". Этот метод, на мой взгляд, применим только для нетиповых конфигураций и к типовым вообще применяться не должен. Я предлагаю использовать штатные методы обновления типовых конфигураций, находящихся на поддержке, которые предлагает сама фирма 1С.
Да, в статье рассматривается несколько таких методов: через интернет, через типовую обработку в режиме предприятия, и через поддержку средствами конфигуратора. Методы эти вполне рабочие и, на мой взгляд, настолько безопасные, насколько это возможно.
Как видно даже здесь из комментариев, ряд пользователей регулярно использует их и никаких особых проблем не испытывает.
Во-вторых, о предупреждениях. Они в статье присутствуют, но негативные последствия действительно подробно не разбираются, поскольку об этом много говорилось в других статьях здесь же и на ряде других ресурсов. Если в этом есть необходимость, то можно проговорить их еще раз, но повторять многократно сказанное другими авторами мне не хотелось бы.
Объясните пожалуйста, в чем разница?
Это уже не обновление.
Статья ИМХО правильная, только непонятно зачем лишние телодвижения с пустой базой.
Чтобы убедиться что этот метод в вашей конфигурации сработает, посмотрите с какого релиза может обновляться конфигурация без доп. обработок. Если текущий релиз позже первого допустимого, то можно обновляться, предварительно сделав backup.
Кстати, возможно очевидное, но мне в свое время помогшее дополнение к пункту 2: типовой релиз (но древний) всегда есть у нас в поддержке самой базы. Как всем известно "подзамочные" конфы обновляются куда быстрее, чем даже просто открытые для изменения ради разнесчастного дополнительного отчета/подписки на событие. Поэтому сохранение ЦФ из поддержки, загрузка его в пустую базу, последовательное обновление получившейся подзамочной и обновление рабочей базы на получившийся ЦФ последнего релиза может сэкономить время в 2-3 раза легко. Уж не говоря о том, что свои доработки придется переносить всего один раз.
в конфигураторе базы нужной версии создать файл поставки cf (меню Конфигурация\Поставка конфигурации\Создать файлы поставки и обновления конфигурации) и обновляться на него. Файл поставки будет такой же как и на партнерском диске, а не какая-то левая конфигурация которая не обновляет конфигурацию поставщика.
Ваш комментарий имеет смысл только в случае, когда мы выгружаем новую конфигурацию (ту, на которую хотим обновиться) из нетиповой базы. Но я в таком случае рекомендовал бы выгружать именно конфигурацию поставщика через "Конфигурация-Поддержка-Настройка поддержки-Сохранить в файл", как и было указано в статье. Зачем создавать себе трудности в виде новой поставки и нового поставщика?
Таким образом, по информации непосредственно от фирмы 1С из диалога настройки поддержки сохраняется именно "конфигурация поставщика последней версии".
Получается, что если уж вообще заморачиваться на то, чтобы выгружать из чьей-то нетиповой базы конфигурацию поставщика для последующего обновления на нее, то делать это следует именно так, как рекомендует фирма 1С и как описано в данной статье.
P.S. Почему-то создаётся впечатление, что здесь все говорят об одном и том же, только разными словами.
Как в детском садике: один малыш говорит «Мама – моя!».
Другой с ним спорит: «Нет! Мама – моя!».
«Нет, моя мама!»
«Нет, моя!!!»
И до слёз :)
Но вообще-то методы обсуждались разные, причем предлагаемый в комментариях изначально казался мне менее корректным. Но хотелось все же проверить утверждение о том, что он более эффективен. Проверка показала, что это не так, и я успокоился. ))
Для того, что узнать есть ли ключевой релиз среди десятка-другого промежуточных - это в идеале надо просмотреть их все. Что, порой, бывает дольше, чем установка этих релизов и обновление через "Поиск доступных обновлений". Хотя, каждому - свое. В видео Насипова достаточно подробно объясняется почему не рекомендуется делать такой "накат".
Насчет ключевого релиза: узнать заранее действительно сложно. А вот когда при обновлении ИБ тебе выкатывают список измененных объектов метаданных, а в нем есть что-то кроме добавления - сразу должно возникать подозрение о том, что пропущен ключевой релиз.
Именно поэтому в статье сказано, что список изменений нужно ЧИТАТЬ ВНИМАТЕЛЬНО.
Да, можно поинтересоваться, о каком именно видео Насипова идет речь? У Фарита их много...
А насчет последнего абзаца - если честно, я не понял... зачем его куда-то переносить? или речь о предпоследнем?
Действительно, в новой чистой базе конфигурация ИБ будет идентична конфигурации поставщика. Я не стал упоминать это, чтобы у читателя твердо закрепился в голове универсальный рецепт, откуда следует брать конфигурацию поставщика. И так уже здесь в комментах разные нездоровые идеи возникали... )))
- в конфигурации с поздним релизом: меню: Конфигурация - сохранить конфигурацию в файл
- в конфигурации с застарелым: меню: Конфигурация - Сравнить, объединить с конфигурацией из файла
я сегодня практиковался, таким образом обновляя УТ через кучу релизов; пакет обновлений не везде прошел
выдавались некие ошибки. Но в целом обновился.
Осталось только выяснить, будут ли эти ошибки при стандартном обновлении, пошагово
У клиента интернета нет или очень медленный.
Обновления давно не устанавливались.
У меня на флешке с собой есть десяток файлов обновлений (последовательных), я их (шаблоны cfu) установил.
Задача.
Как мне обновить все эти релизы последовательно, затратив на это минимум телодвижений? Т.е. чтобы не каждый релиз поотдельности, а как-нибудь пакетно, нажал "обновить из папки все релизы" и поехал домой, а оно само все обновляет? Интересно, что из режима 1С:Предприятия программа предлагает через интернет установить все обновления пакетно, сама скачивает, распаковывает и устанавливает. А вот если они уже установлены приходится в каждое обновление тыкать ее носом, почему пакетом нельзя подсунуть ей папку с релизами?
Кто как решает подобные задачи?
Лично наблюдала такую ситуацию у коллеги на БГУ. Чем все закончилось не знаю, наши пути разошлись.
Обычно по запросу бухгалтеров.
Ключевой момент - сделать архив базы. Для небольших баз проще всего скопировать файл .dt в отдельную папку непосредственно перед обновлением - это защитит от неожиданностей обновления.
Для больших баз имеет смысл обновляться регулярно ). Тем более, что к большим базам обычно приставлен специальный человек - администратор 1С. Ну или тестовое обновление на тестовой базе перед прыжковым обновлением рабочей).
Конечно, переходы с редакции на редакцию и с платформы на платформу таким способом не проходят (как и редкие случаи "критичных" обновлений), о чем в статье прямым текстом и говорится.
ЗЫ.
перелез недавно с семерки ... ваша статейка с экономила много времени.
Есть БП 2.0 типовая, поддержка с возможностью редактирования. Есть не существенные изменения, но они важны в плане переноса. Есть ограничение по времени с выполнением обновления, поэтому захотелось его сэкономить, т.е. я обновил копию перенес все необходимые изменения, сохранил внешний цф, но не тут то было(( в принципе влоб обновляется, версия релиза меняется простым объединением, но не меняется релиз Поддержки, а если делать загрузку цф как описано в статье, выдает что "Не содержит обновлений", я понимаю что мой вопрос смешен, и все сделано для таких "умных" как я, но не смешно ночью когда в базе никого нет, сидеть и руками это переносить....
Или я делаю что то не так?
Меня интересует вопрос глобальный почему 1С не стремится к совершенству не делает попыток разделить содержимое разработок на значимые и не значимые. Я не претендую на значимость своих разработок, но я не хочу все время бояться что они будут снесены при следующем обновлении мной или не мной.
Пусть ознакомятся с реализацией подобных механизмов в зарубежных серьезных системах, язык не поворачивается произносить в суе их названия и сравнивать с 1С. Почему там "типовые разработки" изменить нельзя, но можно сделать свои изменения которые при работе будут иметь больший приоритет выполнения, но при этом всегда можно откатить к начальной конфигурации. Видимо наши отстали во всем.
Первое правило - ОБЯЗАТЕЛЬНЫЙ бэкап.
Второе правило - обновить платформу до последней доступной версии, а уж потом возиться с обновлением базы.
Если конфигурация стандартная - пользовал CF-ку из последнего доступного полного дистрибутива этой конфигурации (та что в \AppData\Roaming\1C\1Cv82\tmplts).
Если доработаная, то обновлять старался последовательно, т.е. по цепочке ключевых релизов на КОПИИ базы, затем выгружал CF-ку и обновлял рабочую базу готовой выгрузкой (уже без промежуточных).
Переход на 8.3 одновременно с переходом на Бух3.0 делал с рекомендуемого релиза Бух2.0 (т.е. 2.0 обновил прыжком на рекомендуемую 2.0 на последней платформе 8.2, а потом уже CFU-шкой на платформе 8.3!! перешел на 3.0).
Описаный способ обновления пока не подводил. Пару раз возникали предупреждения при таком обновлении, решалось просто - искал ключевой релиз, прыгал на него, и дальше на последний доступный.
Но все то, о чем вы пишете, здесь уже многократно обсуждалось.
В статье НЕСКОЛЬКО раз написано, что статья НЕ для чайников, а для опытных внедренцев, ответственно подходящих к задаче.
Что метод НЕ ПОДХОДИТ для сложных случаев, в том числе для перехода через ключевые релизы, о которых пишет (90).
Статья висит на ИС уже больше 2 лет, за это время здесь в комментах не объявилось ни одного пострадавшего.
На практике та же БП, которую 1С крайне редко обновляют радикально в пределах одной редакции, почти в 100% случаев благополучно обновляется этим методом.
аха, на "красный" тоже можно если осторожно :)
Аха и представь трудозатраты чтобы ответить на вопрос "а сложный ли это случай"?!
Я нашел в свое время для себя интересный и удобный способ обновить запущенную типовую БП у знакомых. Времени на проверку результатов обновления я тогда потратил меньше, чем на последовательное обновление. Вот и решил описать процедуру в деталях - себе на память, и вдруг кому еще сгодится...
Не было цели описать универсальный волшебный алгоритм. Думаю, что его и не существует - у любого способа есть риски и связанные проблемы разного рода.
Читайте, думайте и решайте сами, пользоваться или нет...
Это же как - удалять объекты без контроля ссылочной целостности.
Более точные знания процесса, полагаю, можно получить либо в самой фирме 1С, либо пробовать через технологический журнал.
(не считая переходов с 1.6 на 2.0, и на 3.0)
я вот тут тоже обновляю сейчас на 30+ релизов
начал апдейтами, потом сравнил с цф, ни одного удаления. Переименования - да. Удалений - нет.
Прочитал комментарии: вывод один, кто поступает согласно таким советам, либо никогда не разбирался в алгоритме работы процесса обновления 1С, либо не дорожит клиентами.
Вообще на 3-4 релиза обновиться на cf еще терпимо (с учетом анализа изменений), более уже критично + обновлять платформу на последний релиз тоже не всегда можно.
//по поводу удаленных объектов - они не обязательно должны быть - переименовав объект и "перепрыгнув" несколько релизов, обработку обновления тоже можно поставить в тупик
вывод: такой способ возможен только в теории, т.к. если работаешь со "своим" клиентом, так делать не будешь; а если франчайзи - то вопрос дальнейшей работоспособности базы просто никого не волнует...
(сам через все это прошел)
Просто вы еще не обновляли не типовые, когда только реструкторизация после изменения плана счетов идет несколько часов. Никто в этом случае не отключит от работы базу на день только для того, чтобы вы смогли пройтись по всем cfu последовательно.
//да и вообще то реструктуризация плана счетов не зависит от того cfu это или cf; и к тому же обновление нетиповой можно просто последовательно подготовить на тестовой базе, сохранить релизы, а на рабочую только последовательно залить.. и поверьте не будет это дольше, т.к. cf-ники грузятся довольно быстро
//а если такое и будет, то неоднократно измененный объект в Вашем случае будет иметь только последнюю версию (а промежуточных для обработки обновления данных уже не будет) !! - и обновление просто некорректно отработает (это и является основной проблемой такого рода обновлений)
ЗЫ
Так же был случай в ЗУП, когда 1С в одном релизе портили данные в базе, если обновлять последовательно на cfu не пропуская один из них.
Обновление через cfu:
1. Бэкап
2. Обновление на 2.0.0 - 2.0.1
3. Запуск базы, реструкторизация (2 часа)
1. Бэкап
2. Обновление на 2.0.1 - 2.0.2
3. Запуск базы, реструкторизация (2 часа)
Обновление через cf:
1. Бэкап
2. Обновление на 2.0.0 - 2.0.2
3. Запуск базы, реструкторизация (2 часа)
Разве разница не очевидна? :)
Если изменений в реквизитах не было тогда и смысл последовательно базы в промежутках запускать - сразу обновить на все cfu и запустить?
ЗЫ вечером посмотрю тему. Сейчас ухожу.
А по поводу cfu и сразу запустить - опять все сводится к тому: анализ+риск, либо последовательное обновление.
//да если уж на то пошло, то в первом обновлении при запуске в эти данные может быть, обработкой обновления, перенесена информация (которая будет исп. в послед. обновлении) - и как это все учесть??
Но после обнаружения в конфигурации справочников и регистров с префиксом "Удалить" стало очевидно, что "мир меняется, но не становится лучше"(древнегреческое).
Можно, сэкономив время на обновлении, нарваться а дыру в данных и "пожалеть о потраченном времени"
Как думаешь что произойдет если в промежуточном обновлении будут добавлены новые метаданные, а старые будут с префиксом(не использовать, удалить) и в обработке обновления будет функция переброски данных, а ты проскочишь это обновления ?
По этому перескакивать через релизы, можно только когда ты уверен в том что в промежуточных не было изменения архитектуры хранения данных. В остальных случаях можно, но осторожно :)
я понимаю, что саму статью уже давно никто не читает (а зачем, если можно пофлудить в комментах?), но там написано о том, что обработка обновления должна отработать от ИСХОДНОГО до ТЕКУЩЕГО релиза.
Так что переброска данных произойдет в любом случае при первом же запуске в режиме предприятия, если только исходные реквизиты не будут физически удалены из конфигурации (а на такие случаи методика не рассчитана, о чем в статье неоднократно говорится).
И если не сложно, кроме как в теории (или целей тестирования), приведите пример, когда реально имеет смысл использовать такой механизм.
//потому что лично я с учетом анализа изменений релизов (+ к тому же придется все равно отслеживать и релизы платформы) не вижу здесь выигрыша во времени, что бы это реально можно было использовать у клиента
//к тому же обновить порелизно проще, чем сидеть и гадать ("анализировать") "прокатит" обновление или нет
Пример: был у контрагента реквизит "Менеджер", а стал "УдалитьМенеджер", зато появился РС "МенеджерыКонтрагентов".
Обработка обновления выполняется ПОСЛЕ обновления метаданных, поэтому возьмет данные из реквизита "УдалитьМенеджер" и поместит в РС. И только если реквизит "УдалитьМенеджер" будет реально удален из конфигурации или еще раз переименован, обработка выполнится с ошибкой.
На практике подобные ситуации КРАЙНЕ редки.
Имеется 1С:Предприятие 8.2 (8.2.14.519) , старая конфига "Управление торговлей", редакция 10.2 (10.2.5.4), вот необходимо все это дело поставить на свежую не бел. 8.3 чтобы все отгрузочные печатались на современный лад, ну и счет распечатывался в excel форме. Отдельно печать выставляемого счета с цифровой подписью и печатью (в pdf например).
Вообще реально ли такую старую конфигу в современную вытащить, там много контеров и номенклатура...
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 116882
Создание 13.02.12 22:38
Обновление 19.03.14 18:33
Просмотры 207844
Загрузки 0
Рейтинг
87
Комментарии 139
Код открыт Да
Рубрики Обновление 1С
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Windows
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
