Обновление конфигурации 1С на прежней версии платформы

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

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

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

Почему платформу и конфигурацию можно обновлять порознь

Платформа — это среда исполнения. Конфигурация — прикладной код и структура данных, которые в этой среде работают. Файл конфигурации собирается в какой-то версии платформы и несёт в себе порог: ниже этой версии платформа просто не откроет конфигурацию.

Два сценария, которые путают:

• 🔹 Обновить конфигурацию , не трогая платформу — штатная ситуация. Пока релиз укладывается в вашу версию платформы, обновляйтесь сколько угодно раз.
• 🔹 Запустить новый релиз на старой платформе, которая его не тянет — невозможно. Если релиз собран под платформу 8.3.24, на 8.3.20 он не откроется.

За нижнюю границу отвечает свойство конфигурации Режим совместимости. Вендор задаёт его так, чтобы релиз работал на платформах не ниже определённого номера. Пока режим совместимости релиза допускает вашу платформу — обновление пройдёт.

Как узнать, какую платформу требует релиз

Сначала посмотрите, что у вас стоит, потом — что требует целевой релиз.

Текущая версия платформы:

1. В Конфигураторе или в режиме 1С:Предприятие откройте Справка → О программе.
2. Первая строка — версия платформы (например, 8.3.21.1644). Важны первые три числа: 8.3.21.

Минимальная платформа для релиза конфигурации указывается вендором для каждого выпуска. Где искать:

• 📄 в описании обновления (файл с описанием идёт в составе дистрибутива обновления);
• 📄 на странице релиза конфигурации в разделе поддержки — там для каждой версии стоит «рекомендуемая версия платформы»;
• 📄 в свойствах уже установленного обновления: Конфигуратор покажет требуемую версию при попытке обновиться, если платформа не подходит.

Логика выбора простая. Если минимальная платформа релиза не выше вашей — обновляйтесь. Если выше — этот релиз на текущей платформе не пойдёт, нужен промежуточный выпуск (об этом в разделе про упор в версию).

Подготовка: копия базы и монопольный доступ

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

Резервная копия. Для файловой базы достаточно закрыть все сеансы и скопировать папку с файлом 1Cv8.1CD. Надёжнее — выгрузка в .dt: Конфигуратор → Администрирование → Выгрузить информационную базу. Для клиент-серверной базы делайте копию средствами СУБД или тем же .dt. Без свежей копии обновление не начинайте — откат возможен только из неё.

Монопольный доступ. Финальный шаг обновления — «Обновить конфигурацию базы данных» — реструктуризирует таблицы и требует, чтобы в базе не было других сеансов.

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

Обновление из файла через Конфигуратор

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

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

На шаге 8 и происходит реструктуризация. Отсюда и требование монопольного доступа.

Чем .cfu отличается от .cf

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

Файлы обновлений ставятся из дистрибутива обновления (его setup распаковывает .cfu/.cf в каталог шаблонов). Тогда в окне обновления вместо «Выбор файла» можно использовать «Поиск доступных обновлений» — Конфигуратор сам найдёт подходящий релиз в каталоге шаблонов.

Конфигурация поставщика и сравнение версий

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

Посмотреть состояние поддержки: Конфигурация → Поддержка → Настройка поддержки. Там видно, с какой конфигурацией и версией вы сравниваетесь и включена ли возможность изменения (замок).

Если нужно разобрать изменения вручную — например, в доработанной конфигурации, — используйте Конфигурация → Сравнить, объединить с конфигурацией из файла. Инструмент показывает три стороны: ваша конфигурация, конфигурация поставщика, новый релиз. Для доработанных баз это ключевой момент: объединение покажет, где ваши правки конфликтуют с изменениями вендора, и даст выбрать, что оставить.

Три типовых состояния объекта при обновлении доработанной базы:

• ✅ изменён только вендором — принимаем изменение;
• ✅ изменён только вами — оставляем вашу версию;
• ⚠️ изменён и там, и там — разбираем вручную, иначе затрём либо правку вендора, либо свою доработку.

Если база типовая и вы в ней ничего не меняли, конфликтов нет — объединение проходит по умолчанию.

Если релиз требует платформу выше установленной

Это основная причина, по которой «обновить, не трогая платформу» иногда не выходит. Варианты:

Взять промежуточный релиз. Часто нужный функционал (например, новая форма отчёта) появился в релизе, который ещё работает на вашей платформе. Найдите последний релиз конфигурации, чья требуемая платформа не выше вашей, и обновитесь до него. Дальше — только с обновлением платформы.

Проверить режим совместимости. У некоторых релизов режим совместимости допускает более старые платформы, чем кажется по дате. Решает именно свойство релиза, а не год выпуска, — поэтому сверяйтесь с требуемой версией, а не «на глаз».

Обновить платформу — отдельно от конфигурации. Если без свежего релиза никак, платформу можно поставить рядом: новые версии ставятся параллельно, старая не удаляется. После установки запуск базы можно привязать к нужной версии платформы через список информационных баз или файл 1CEStart.cfg. Это уже не «без обновления платформы», но обновление конфигурации и платформы остаются двумя независимыми действиями.

Типичные ошибки при обновлении на старой платформе

Отдельно про .cfu-цепочку: вендор выпускает обновления «от версии к версии». Если вы пропустили несколько релизов, одним .cfu не обойтись — либо идите по цепочке промежуточными файлами, либо ставьте полный .cf целевого релиза.

Проверка после обновления и ввод в работу

Обновление структуры прошло — не спешите пускать пользователей.

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

Если на шаге 2 или 4 что-то пошло не так — откатывайтесь на резервную копию и разбирайте причину до того, как в базе начнут работать люди. Копия, снятая на этапе подготовки, для этого и нужна.

Только после успешной проверки снимайте монопольный доступ и пускайте пользователей.

Частые вопросы