← На главную

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

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

Почему возникает ошибка, если номер релиза совпадает?

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

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

К рассинхронизации обычно приводят следующие факторы:

1. Некорректное предыдущее обновление: если ранее базу обновляли через команду Сравнить, объединить с конфигурацией из файла вместо штатного обновления, основная конфигурация получила новые метаданные и сменила номер релиза, а конфигурация поставщика осталась старой версии.
2. Несовпадение идентификаторов поставщика: в файлах обновлений проверяется не только номер версии, но и точное совпадение строковых реквизитов Имя и Поставщик в корне конфигурации. Если франчайзи или прошлый разработчик правил свойства корня либо установил релиз смежной ветки (например, КОРП вместо ПРОФ или базовую вместо ПРОФ), платформа заблокирует применение файла.
3. Повреждение таблицы поддержки: при многократных снятиях с поддержки и повторных постановках без очистки кэша в таблицах Config и ConfigDumpInfo могут возникнуть коллизии.

Шаг 1. Создание резервной копии базы данных

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

1. Откроем информационную базу в режиме Конфигуратор.
2. В главном меню перейдем в раздел Администрирование → Выгрузить информационную базу....
3. Сохраним файл выгрузки .dt в надежное место. Если база данных работает в клиент-серверном варианте, создадим резервную копию средствами СУБД (SQL dump).

Шаг 2. Подготовка эталонного файла конфигурации поставщика

Выясним точный номер версии конфигурации, зафиксированный в настройках поддержки. Для этого перейдем в меню Конфигурация → Поддержка → Настройка поддержки и посмотрим на поле «Версия конфигурации» напротив поставщика «Фирма 1С».

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

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

Шаг 3. Полное снятие с поддержки и восстановление конфигурации поставщика

Теперь восстановим корректную конфигурацию поставщика в проблемной базе. Разберем по шагам правильный алгоритм:

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

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

Шаг 4. Обновление конфигурации поставщика до актуального релиза

Если основная конфигурация ранее уже была обновлена до более свежего релиза, а конфигурация поставщика отстала, обновим ее без затирания объектов базы:

1. Перейдем в Конфигурация → Поддержка → Обновить конфигурацию.
2. Укажем полный файл .cf следующего или целевого релиза. Теперь платформа успешно примет файл, так как исходная конфигурация поставщика совпадает по требованиям обновления.
3. Когда откроется окно сравнения и объединения основной конфигурации и конфигурации поставщика, снова снимем все флажки со структуры объектов и нажмем кнопку «Выполнить».
4. Конфигурация поставщика обновится до нового релиза, не затронув изменения в основной конфигурации.
5. Применим изменения клавишей F5.

Дополнительные рекомендации при проблемах с обновлениями

Если после выполнения описанной процедуры ошибка сохраняется, обратим внимание на следующие нюансы:

1. Очистка кэша конфигуратора: закроем все запущенные сеансы «1С:Предприятия» и конфигуратора. Удалим содержимое каталогов временных файлов пользователя по путям %LOCALAPPDATA%\1C\1cv8 и %APPDATA%\1C\1cv8 либо удалим базу из списка запуска 1С и добавим ее заново под другим наименованием.
2. Проверка линейки продукта: убедимся, что для обновления базы версии ПРОФ не используется файл от базовой версии или версии КОРП. Сравним название в окне «О программе» с названием дистрибутива в файле UpdInfo.txt из архива обновления.
3. Отказ от файлов .cfu при сбоях: файл .cfu представляет собой разностный бинарный патч, крайне чувствительный к состоянию метаданных. При любых проблемах с версионностью надежнее использовать полные файлы поставки конфигурации .cf.