← На главную

При обслуживании бюджетных учреждений и обновлении конфигураций «1С:Бухгалтерия государственного учреждения 2» (БГУ 2) специалисты часто сталкиваются с ситуацией, когда необходимо обновить базу, пропущенную в обслуживании несколько месяцев. Иногда конфигуратор предлагает сразу «перепрыгнуть» через несколько версий, устанавливая самый последний релиз. Давайте разберемся, почему так происходит, безопасно ли это и как правильно выполнять процедуру обновления, чтобы не потерять данные учета.

Суть проблемы: иллюзия доступного обновления

Рассмотрим ситуацию: у нас есть база версии 2.0.102.71. Согласно официальной информации, цепочка обновлений должна выглядеть так: 2.0.102.79 -> 2.0.103.xx -> 2.0.105.69. Однако, при выборе файла обновления в Конфигураторе, система сразу предлагает установить версию 2.0.105.69, минуя промежуточные.

Возникает закономерный вопрос: не приведет ли такой «скачок» к ошибкам в данных? Как показывает практика и анализ механизмов платформы 1С, опасения абсолютно обоснованы.

Различие файлов обновления: CFU против CF

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

1. Файл обновления (.cfu). Этот файл содержит только различия (дельту) между конкретной старой версией и новой. В нем жестко прописано, на какие версии его можно "накатывать". Если вы попытаетесь применить .cfu от 105-го релиза на 102-й, платформа выдаст ошибку «Файл не содержит доступных обновлений».
2. Файл полной конфигурации (.cf). Это полный слепок метаданных конфигурации. Когда вы указываете этот файл при обновлении, платформа работает в режиме сравнения и объединения.

Если конфигуратор предлагает вам обновиться с большим «перескоком» версий, это практически всегда означает, что в каталоге шаблонов лежит файл 1cv8.cf (полная конфигурация), а не 1cv8.cfu.

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

Риск №1: Пропущенные обработчики обновления данных

Это самая критичная проблема при обновлении «скачками». Давайте проанализируем, как происходит миграция данных в 1С.

Когда разработчики выпускают промежуточный релиз (например, 2.0.103), они часто включают в него программный код, который должен выполниться один раз при первом запуске в режиме «1С:Предприятие». Этот код называется обработчиком обновления.

Примеры действий обработчиков:

• Перенос остатков с устаревшего счета плана счетов на новый (согласно приказам Минфина).
• Заполнение новых реквизитов в справочниках значениями по умолчанию.
• Конвертация настроек отчетности.

Если мы обновляемся сразу на 2.0.105, минуя 2.0.103, происходит следующее:

1. Структура базы меняется на новую (счета добавлены, реквизиты созданы).
2. Но код обработчика из 103-го релиза отсутствует в 105-м релизе (разработчик считает, что он уже был выполнен ранее).
3. В результате: новые регистры и реквизиты остаются пустыми, а старые данные либо удаляются, либо становятся недоступными («висят» в базе мертвым грузом, невидимые для пользователя).

Для БГУ это особенно критично, так как бюджетный учет жестко регламентирован, и потеря аналитики или проводок при смене инструкций по учету приведет к некорректной отчетности.

Риск №2: Режим совместимости и реструктуризация

Между релизами (особенно если пропущено много версий) часто меняется свойство конфигурации РежимСовместимости. Например, переход с версии платформы 8.3.21 на 8.3.24.

При последовательном обновлении этот процесс разбит на этапы. При резком скачке происходит одномоментная полная реструктуризация таблиц базы данных. На больших базах это может вызвать:

• Колоссальную нагрузку на сервер СУБД.
• Переполнение логов транзакций.
• Ошибки нехватки памяти и аварийное завершение процесса, после которого базу придется восстанавливать.

Правильная стратегия обновления

Чтобы избежать описанных проблем, давайте сформулируем единственно верный алгоритм действий при обновлении пропущенных релизов.

1. Анализ цепочки обновлений

Перед началом работ зайдите на сайт поддержки пользователей (users.v8.1c.ru) в раздел вашей конфигурации. Посмотрите таблицу релизов. Там указано, с какой версии на какую можно обновляться. Обычно это цепочка: Версия А -> Версия Б -> Версия В.

2. Резервное копирование

Это обязательное действие («Отче наш» любого администратора 1С). Делайте бэкап перед началом всего процесса. В идеале — средствами SQL (если база клиент-серверная) или копированием файла 1Cv8.1CD (если файловая).

3. Последовательное обновление

Используйте файлы .cfu. Обновляйтесь поэтапно, как рекомендует вендор.

4. Запуск в режиме Предприятия после каждого шага

Это ключевой момент, который часто игнорируют для экономии времени. После накатывания обновления в Конфигураторе:

1. Примите изменения.
2. Запустите «1С:Предприятие».
3. Дождитесь окончания выполнения всех регламентных процедур обновления (появится сообщение «Обновление программы выполнено успешно» или можно проверить прогресс в журнале регистрации).

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

Что делать, если ошибочное обновление уже выполнено?

Если вы уже обновились «скачком» через .cf файл и база запустилась, есть риск скрытых ошибок.

Вариант А: Восстановление (Рекомендуемый)

Если с момента обновления в базе никто не работал (или прошло мало времени), лучшее решение — восстановить архивную копию, сделанную до обновления, и провести процедуру заново, последовательно.

Вариант Б: Диагностика (Если бэкапа нет или введены данные)

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

Администрирование -> Обслуживание -> Результаты обновления программы

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

Резюме

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