← На главную

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

Разберем причины возникновения таких ошибок, выясним логику работы платформы с метаданными и рассмотрим практические способы безопасного выравнивания поддержки и обновления базы без потери данных.

Причины проблемы и риски при обновлении

Чтобы понять, почему нельзя просто «накатить» новое обновление, проанализируем внутренние механизмы платформы 1С:

1. Рассинхронизация внутренних идентификаторов (UUID): если реквизиты, документы или справочники переносились через буфер обмена или прямое объединение без поддержки, платформа присваивает им новые уникальные внутренние идентификаторы (GUID). При последующем сравнении с типовым обновлением система воспринимает такие объекты как чужие: старые объекты помечаются на удаление, а типовые добавляются как новые. Принятие изменений в таком виде приведет к полной очистке таблиц в СУБД.
2. Ограничения файлов обновлений (.cfu): файл .cfu содержит только дельту между строго определенными версиями, зашитыми в его внутреннем манифесте. Если конфигурация поставщика не совпадает с ожидаемой, штатный механизм обновления просто не увидит файл или выдаст ошибку.
3. Пропуск процедур обновления данных: при переходе через несколько релизов должны последовательно отрабатывать обработчики обновления в режиме «1С:Предприятие». Если просто заменить конфигурацию на самую свежую, база не сможет корректно работать из-за несоответствия структур данных в таблицах.

Способ 1. Восстановление конфигурации поставщика через объединение со снятыми флагами

Этот метод позволяет обновить конфигурацию поставщика до реального релиза базы данных без изменения структуры объектов и без риска удаления пользовательских данных.

Разберем пошаговый порядок действий:

1. Создаем резервную копию базы данных: любые манипуляции с поддержкой выполняем строго на копии информационной базы.
2. Находим типовой файл конфигурации (.cf): нам потребуется полный файл поставки ровно того релиза, которому сейчас фактически соответствует конфигурация базы данных.
3. Открываем сравнение и объединение: в меню выбираем Конфигурация -> Сравнить, объединить с конфигурацией из файла и указываем подготовленный файл .cf.
4. Снимаем все флаги объединения: в открывшемся окне сравнения полностью снимаем корневую галку, чтобы ни один объект основной конфигурации не был затронут и изменен.
5. Настраиваем правило сопоставления: через меню «Действия» окна сравнения обязательно выполняем команду «Установить соответствие по именам». Это гарантирует, что одинаковые по названию метаданные сопоставятся корректно, даже если их UUID разошлись.
6. Применяем объединение: нажимаем кнопку «Выполнить». Платформа обновит только внутренний макет конфигурации поставщика, оставив пользовательские доработки и данные нетронутыми.
7. Сохраняем конфигурацию: сохраняем конфигурацию и обновляем конфигурацию базы данных (F7). Окно реорганизации структуры при этом не должно содержать предупреждений об удалении таблиц и колонок.

Способ 2. Полная поэтапная актуализация и выделение доработок (Three-way merge)

Если объем доработок неизвестен и необходимо аккуратно перейти на актуальный релиз, применяем классическую методику трехточечного сравнения (Three-way merge).

Разберем этот алгоритм подробно:

1. Подготавливаем три конфигурации:
   • Конфигурация А: Исходная чистая типовая конфигурация текущего релиза поставщика.
   • Конфигурация Б: Рабочая конфигурация базы данных с доработками.
   • Конфигурация В: Новая целевая типовая конфигурация, до которой планируется обновление.
2. Формируем отчеты о сравнении: сравниваем конфигурацию А с конфигурацией Б. Полученный отчет дает нам исчерпывающий список всех кастомных доработок (измененные модули, добавленные реквизиты, новые объекты).
3. Сравниваем типовые конфигурации: сравниваем конфигурацию А с конфигурацией В, чтобы увидеть изменения самого вендора (удаленные процедуры, переименованные реквизиты, новые подсистемы).
4. Пошагово переносим доработки: обновляем рабочую базу на промежуточный или целевой релиз поставщика через файл .cf. В окне объединения включаем только типовые объекты, а для модифицированных объектов вручную объединяем код модулей с сохранением логики кастомных правок.
5. Контролируем окно реорганизации: перед нажатием кнопки «Принять» в окне реструктуризации внимательно проверяем список действий. Если система предлагает удалить реквизит или таблицу с данными, прерываем операцию и вручную перенастраиваем соответствие объектов по имени.
6. Запускаем отработку процедур обновления: открываем базу в режиме «1С:Предприятие» под пользователем с полными правами и дожидаемся завершения регламентных процедур перехода на новый релиз.
7. Проверяем проведение документов: запускаем групповое перепроведение документов минимум за один закрытый квартал (или год) на тестовой копии и сравниваем движения регистров с рабочей базой.

Альтернативный вариант: перенос данных в чистую типовую конфигурацию

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

1. Разворачиваем чистую типовую конфигурацию последнего актуального релиза.
2. Переносим нормативно-справочную информацию и остатки с помощью конфигурации 1С:Конвертация данных (КД2) или универсальной выгрузки/загрузки XML.
3. Необходимый кастомный функционал переносим не в основную конфигурацию, а оформляем в виде внешних отчетов, обработок и печатных форм, либо реализуем через расширения конфигурации. Это оставляет конфигурацию на полной типовой поддержке и исключает подобные проблемы в будущем.