Как правильно обновлять модифицированную УТ 11 при пропуске нескольких релизов

← На главную

Обновление сильно или средне модифицированной конфигурации 1С:Управление торговлей (УТ 11) — это всегда вызов для технического специалиста. Ситуация осложняется, когда база не обновлялась длительное время (например, более года), и количество пропущенных релизов исчисляется десятками. Перед программистом встает дилемма: идти по «методичке», последовательно накатывая каждый релиз, или совершить «прыжок», обновившись сразу на финальную версию. Разберем подробно оба подхода, их риски и технические нюансы.

Анализ рисков при пропуске промежуточных релизов

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

Трансформация метаданных: В процессе развития конфигурации фирма «1С» часто меняет структуру хранения данных. Реквизит может сменить тип, переехать из одного справочника в другой или быть заменен регистром сведений. В таких случаях старый реквизит помечается префиксом Удалить....
Процедуры миграции БСП: Библиотека стандартных подсистем (БСП) содержит обработчики обновления, которые переносят данные из полей Удалить... в новые структуры. Если мы пропускаем релиз, где это поле существовало, и сразу переходим на версию, где оно уже окончательно удалено из состава метаданных, обработчику обновления просто не из чего будет читать данные.
Цепочки обработчиков: Обработчики обновления в режиме предприятия часто строятся иерархически. Обработчик релиза N+2 может рассчитывать на то, что данные уже подготовлены обработчиком из релиза N+1. При «прыжке» эта логика может нарушиться, что приведет к некорректным остаткам или битым ссылкам.

Вариант 1: Последовательное обновление по ключевым релизам

Рассмотрим наиболее безопасный путь, который минимизирует риски потери данных. Этот метод часто называют «обновлением по контрольным точкам».

Шаг 1: Определение ключевых релизов. Нет необходимости накатывать каждый промежуточный .cfu. Достаточно выбрать релизы, на которых меняется версия БСП или происходят глобальные изменения в учете (например, переход с 11.4 на 11.5). Список таких релизов можно найти в файле 1cv8upd.htm в дистрибутиве обновления.

Шаг 2: Последовательная накатка. Мы обновляем конфигурацию поставщика, сохраняя свои объекты, и обязательно запускаем систему в режиме предприятия после каждого ключевого этапа. Необходимо дождаться завершения всех регламентных заданий обновления.

Проанализируем состояние процедур обновления через РегламентныеЗадания или специальную форму «Результаты обновления программы». Пока статус не станет «Обновление успешно завершено», переходить к следующему релизу нельзя.

Вариант 2: Прямое обновление на целевой релиз

Если бюджет или время ограничены, рассматривают «рискованный» вариант. Рассмотрим его механику:

Делаем полную копию базы.
В конфигураторе выполняем сравнение и объединение с полным файлом .cf целевого релиза.
Важно использовать механизм трехстороннего сравнения. При объединении мы подключаем старую конфигурацию поставщика, чтобы система понимала, где наши изменения, а где изменения вендора.
После объединения и сохранения конфигурации базы данных запускаем 1С.

Важный нюанс: Даже если вы обновили .cf «одним махом», при запуске БСП увидит разрыв версий (например, с 11.4.11 на 11.4.13) и попытается запустить все пропущенные обработчики последовательно. Проблема возникнет только в том случае, если в целевом .cf уже физически отсутствуют объекты, к которым обращаются старые обработчики.

Работа с модификациями: вынос в расширения

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

Рассмотрим алгоритм переноса:

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

Пример программного добавления обработки в расширении для минимизации конфликтов при обновлении:


&НаСервере
&После("ПриСозданииНаСервере")
Процедура Мой_ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
    // Добавляем программно кнопку или меняем видимость
    НовыйЭлемент = Элементы.Добавить("МояСпециальнаяКнопка", Тип("КнопкаФормы"), Элементы.ГруппаКоманд);
    НовыйЭлемент.Заголовок = "Дополнительное действие";
    НовыйЭлемент.ИмяКоманды = "МояКоманда";
КонецПроцедуры

Использование инструментов автоматизации (Обновлятор)

Проанализируем ситуацию с рутинными операциями. Если база модифицирована не критично (например, добавлены только новые объекты и минимум изменений в типовом коде), можно использовать специализированное ПО, такое как «Обновлятор-1С». Он позволяет:

Автоматически скачивать всю цепочку нужных релизов.
Последовательно накатывать их, запуская режим предприятия для отработки БСП.
Логировать ошибки на каждом этапе, что позволяет вовремя заметить «отвалившийся» реквизит.

Итоги и рекомендации

Подведем итог. Выбор методики зависит от глубины модификации:

Для сильно кастомизированных баз: Только последовательное обновление по ключевым релизам с тщательным тестированием каждого шага. Это дороже, но гарантирует сохранность данных учета.

Для баз с минимальными правками: Допустимо прямое обновление через .cf, но с обязательным предварительным тестированием на копии и проверкой отчетов (Оборотно-сальдовая ведомость, Ведомость по товарам) до и после процедуры.

Помните, что контроль версий и регулярное создание бэкапов перед каждым этапом объединения — это единственная страховка от критических ошибок. Если в процессе отложенного обновления данных в режиме предприятия возникли ошибки, не игнорируйте их, так как это «мина замедленного действия», которая может привести к неверному расчету себестоимости или ошибкам в налоговой отчетности спустя месяцы работы.