Как правильно устанавливать цепочку обновлений на измененную конфигурацию 1С:ЗУП

При обслуживании нетиповых конфигураций «1С:Предприятие» перед специалистом часто возникает задача установки целой цепочки релизов (например, 5–7 ключевых обновлений подряд). На этапе тестирования обычно выполняется полный цикл: последовательное обновление конфигурации, переносы доработок, сохранение настроек объединения и запуск системы в режиме «1С:Предприятие» для выполнения служебных алгоритмов.

Однако на этапе работы с продуктивной (рабочей) базой возникает искушение сэкономить время и загрузить итоговый файл конфигурации (.cf), полученный на тестовой базе. Разберем по шагам, почему такой подход несет серьезные технические риски и как правильно организовывать процесс накатывания нескольких релизов.

Почему нельзя просто загрузить итоговый cf-файл в рабочую базу

Загрузка полного файла конфигурации через меню «Конфигурация — Загрузить конфигурацию из файла» или простое сравнение/объединение с финальным cf-файлом в один шаг кажется быстрым решением, но имеет несколько критических недостатков:

1. Утрата логики переноса данных Библиотеки стандартных подсистем (БСП). В современных типовых решениях (включая 1С:ЗУП 3) процесс обновления состоит не только из изменения структуры метаданных, но и из работы специальный обработчиков переноса/расчета данных. Алгоритмы БСП запускаются последовательно для каждого релиза. Если перескочить сразу через несколько версий, БСП попытается вызвать обработчики пропущенных релизов, когда структура таблиц уже изменилась. Это приводит к тихим ошибкам переноса данных или к сбоям фоновых заданий.
2. Удаление промежуточных объектов и реквизитов. Рассмотрим распространенную ситуацию: в релизе №3 разработчики 1С добавляют новый реквизит и регистр для пересчета исторических данных, а в релизе №5 удаляют старый реквизит за ненадобностью. Если загрузить сразу финальный релиз №7, старый реквизит удалится мгновенно, а обработчик из релиза №3 не сможет прочитать из него данные для заполнения новых таблиц. В результате данные закрытых периодов будут утрачены или искажены.
3. Рассогласование конфигурации поставщика. При обычном сравнении и объединении с внешним cf-файлом без выполнения процедуры стандартного обновления поддержка не переводится на новый релиз. Конфигурация поставщика остается старой, и при попытке установить следующее обновление через файл .cfu платформа выдаст ошибку о неверной применимости обновления.

Правильный алгоритм последовательного обновления рабочей базы

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

1. Предварительная подготовка и создание резервной копии. Выполним полное резервное копирование информационной базы. Дополнительно убедимся, что из базы удалены все временные патчи и исправления (файлы с расширением .pm), так как старые патчи могут блокировать выполнение монопольных обработчиков обновления.
2. Последовательное обновление метаданных. Для каждого промежуточного релиза выполняем стандартное обновление конфигурации поставщика (через меню «Конфигурация — Поддержка — Обновить конфигурацию») либо объединение с сохранением настроек, ранее подготовленных на тестовой базе (файл .xml).
3. Применение изменений структуры БД. Сохраняем конфигурацию базы данных (клавиша F7).
4. Запуск в режиме «1С:Предприятие». В обязательном порядке запускаем сеанс 1С под пользователем с административными правами. В этот момент выполняются монопольные процедуры обновления БСП.
5. Контроль выполнения отложенных обработчиков. Переходим в раздел Администрирование — Обслуживание — Результаты обновления и дополнительная обработка данных и убеждаемся, что все отложенные задания по пересчету данных успешно завершены и не содержат ошибок. Только после этого переходим к установке следующего релиза.

Автоматизация процедуры через командную строку

Чтобы не выполнять рутинные действия вручную во время технологического окна, весь цепочный процесс можно автоматизировать с помощью сценариев командной строки. Посмотрим на пример параметров для обновления структуры и автоматического запуска процедур БСП:

Для обновления конфигурации базы данных из файла обновления или конфигурации:

"C:\Program Files\1cv8\8.3.23.1852\bin\1cv8.exe" CONFIG /F "D:\Bases\ZUP_WORK" /N "Admin" /P "Password" /UpdateCfg "D:\Updates\zup3_1_27_100.cfu" /UpdateDBCfg

Для запуска режима «1С:Предприятие» с выполнением процедур обновления в авто-режиме:

"C:\Program Files\1cv8\8.3.23.1852\bin\1cv8.exe" ENTERPRISE /F "D:\Bases\ZUP_WORK" /N "Admin" /P "Password" /C ВыполнитьОбновлениеИЗавершитьРаботу

Использование флага /C ВыполнитьОбновлениеИЗавершитьРаботу позволяет автоматически запустить процесс обновления БСП в монопольном режиме и закрыть сеанс после его завершения, что существенно сокращает затраты времени при работе с большой цепочкой релизов.

Как аргументировать необходимость последовательного обновления

Если коллеги или руководство настаивают на нерегламентированной «прямой» загрузке cf-файла ради экономии времени, проанализируем следующие ключевые аргументы:

Ускорение обновления за счет пропуска промежуточных запусков создает скрытые ошибки в регистрах накопления и сведений (например, по НДФЛ или страховым взносам). Выявление и исправление таких ошибок в будущем потребует в десятки раз больше времени, чем последовательная установка обновлений в выделенное технологическое окно.

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