Как исправить рассогласование версий конфигурации и конфигурации поставщика в 1С

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

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

Почему возникает рассогласование версий: техническая причина

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

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

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

В результате такого действия:

• Программный код, формы и свойства основной конфигурации обновились (поэтому корневой узел показывает актуальную версию 1.2.43.1).
• Конфигурация поставщика осталась старой версии (1.2.41.1), так как механизм сравнения-объединения не умеет перезаписывать конфигурацию поставщика.
• Платформа 1С при поиске обновлений всегда ориентируется исключительно на версию конфигурации поставщика. Для нее база числится как устаревшая (1.2.41.1), и новые файлы обновлений, предназначенные для наката на версию 1.2.43.1, система просто игнорирует.

Далее подробно рассмотрим по шагам, как исправить эту ситуацию на рабочей базе данных.

Способ 1. «Холостое» последовательное объединение (Метод автора темы)

Этот метод подходит в случаях, когда разрыв между версией основной конфигурации и версией поставщика невелик (1–3 релиза). Мы заставим платформу перезаписать конфигурацию поставщика без изменения наших доработанных объектов.

Рассмотрим алгоритм действий по шагам:

1. Обязательно сделайте резервную копию базы данных (создайте файл .dt). Любые манипуляции с метаданными выполняются только на копии!
2. Подготовьте полные файлы конфигураций (файлы с расширением .cf, а не файлы обновлений .cfu) промежуточных релизов. В нашем примере понадобятся чистые типовые файлы версий 1.2.42.2 и 1.2.43.1.
3. Перейдите в меню Конфигурация — Поддержка — Обновить конфигурацию.
4. Выберите вариант «Выбор файла обновления вручную» и укажите путь к типовому файлу .cf версии 1.2.42.2.
5. Дождитесь окончания анализа метаданных. Когда откроется окно сравнения и объединения, снимите абсолютно все флажки со всех объектов дерева метаданных. Нажмите кнопку «Выполнить».
6. Платформа спросит о необходимости обновления конфигурации поставщика. Согласитесь. Поскольку галочки со всех объектов были сняты, ваш измененный программный код не затрется, но сама конфигурация поставщика обновится до версии 1.2.42.2.
7. Повторите пункты 3–6 для следующего файла .cf версии 1.2.43.1.

После выполнения этих шагов конфигурация поставщика и основная конфигурация синхронизируются на релизе 1.2.43.1, и следующее штатное обновление до версии 1.2.44.2 пройдет в штатном режиме.

Способ 2. Быстрое восстановление через снятие с поддержки (Рекомендуемый метод)

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

Разберем процесс поэтапно:

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

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

Способ 3. Сборка здоровой конфигурации на «чистой» базе

Если в базе данных наблюдаются серьезные повреждения структуры метаданных или уникальных идентификаторов (UUID) объектов, безопаснее всего собрать конфигурацию заново в пустой базе-доноре.

Выясним алгоритм этой процедуры:

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

Важные нюансы при работе с базой данных

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

Синхронизация конфигурации базы данных (БД)

Если при открытии конфигурации БД (меню Конфигурация — Конфигурация БД — Открыть конфигурацию БД) вы видите старую версию (1.2.41.1), это означает, что предыдущее изменение основной конфигурации не было окончательно применено к физическим таблицам СУБД. Любые операции по восстановлению поддержки можно начинать только тогда, когда основная конфигурация и конфигурация БД полностью согласованы. Нажмите F7 и убедитесь, что обновление базы данных проходит без критических ошибок SQL-структуры.

Очистка кэша платформы 1С

Платформа 1С агрессивно кэширует конфигурацию поставщика на локальном компьютере разработчика. Из-за этого даже после успешного восстановления поддержки система может продолжать утверждать, что обновлений нет. Чтобы решить эту проблему, обязательно очистите локальный кэш конфигуратора.

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

rmdir /s /q "%LocalAppData%\1C\1Cv8"
rmdir /s /q "%AppData%\1C\1Cv8"

Также самым простым и надежным способом является удаление информационной базы из списка запуска 1С и добавление ее заново под тем же путем — при этом создается новый чистый каталог кэша с уникальным GUID.

Использование файлов .cf вместо .cfu

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