Как устранить разрыв версий между основной конфигурацией и конфигурацией поставщика в 1С

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

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

Почему возникает разрыв версий?

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

Проанализируем техническую сторону: в базе данных 1С хранятся три состояния конфигурации:

1. Конфигурация поставщика: Неизменяемый эталон от вендора.
2. Основная конфигурация: То, с чем работает программист и пользователи.
3. Конфигурация базы данных: Реальная структура таблиц в SQL или файловом хранилище.

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

Метод 1: Выравнивание через фиктивное обновление (рекомендуемый способ)

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

Выполним следующие шаги вместе:

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

После этой процедуры версия поставщика станет 2.0.65.20. Теперь мы можем спокойно запускать штатное обновление на следующий релиз 2.0.67.22 через обычный .cfu.

Метод 2: Полная перестановка на поддержку (радикальный способ)

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

Разберем алгоритм по шагам:

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

Настройка правил поддержки для объектов

Выясним причину, почему не стоит бездумно использовать режим «С возможностью изменения для всех объектов». В сообщении №16 автор темы включил этот режим для всей конфигурации. Рассмотрим, к чему это может привести:

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

Рекомендуемая практика:

• Оставлять объекты, которые вы не планируете менять, в статусе «Объект поставщика редактированию не подлежит» (замочек).
• Для объектов, в которые вносятся изменения, использовать статус «Объект поставщика редактируется с сохранением поддержки».

Дополнительные рекомендации по обслуживанию

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

1. Закройте Конфигуратор.
2. Очистите временные файлы 1С (папки в %AppData%\1C\1Cv8).
3. Запустите Тестирование и исправление базы (меню Администрирование).
4. Выберите пункты «Проверка логической целостности конфигурации» и «Проверка ссылочной целостности». Это поможет убедиться, что структура метаданных не нарушена перед обновлением.

Использование пакетного режима через командную строку также может помочь опытным администраторам. Например, команда для принудительного обновления конфигурации выглядит так:

1cv8.exe DESIGNER /F "ПутьКБазе" /N "Логин" /P "Пароль" /UpdateCfg "ПутьКФайлу.cf"

Однако для визуального контроля процесса выравнивания версий лучше использовать интерактивные методы, описанные выше.

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