Как обновить доработанную конфигурацию 1С и не потерять свои изменения

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

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

Чем доработанная база отличается при обновлении

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

Состояние базы видно в Конфигураторе: Конфигурация → Поддержка → Настройка поддержки. Там три типичные ситуации:

• 🔒 Конфигурация на поддержке без возможности изменения. Доработок в основной конфигурации нет. Обновление штатное, через .cfu.
• ✏️ На поддержке с включённой возможностью изменения. Часть объектов изменена. Обновление — через сравнение и объединение.
• ✂️ Конфигурация снята с поддержки. Связи с поставщиком нет, файл .cfu не применится. Нужен полный .cf и ручное сравнение.

У каждого объекта в настройке поддержки есть свой режим:

Самые опасные объекты — дважды изменённые: их поменяли и вы, и поставщик в новом релизе. В окне сравнения их можно отобрать отдельным фильтром. Именно на них уходит основное время.

Что сделать до запуска обновления

Подготовка занимает больше времени, чем само объединение. Без неё ошибку в объединённом модуле обнаружат пользователи, а не вы.

1. Выгрузите базу в .dt. Администрирование → Выгрузить информационную базу в Конфигураторе. Для клиент-серверной базы дополнительно сделайте бэкап средствами СУБД.
2. Сохраните основную конфигурацию в .cf. Конфигурация → Сохранить конфигурацию в файл. Это быстрая точка отката именно для кода.
3. Составьте список доработок. Откройте Конфигурация → Сравнить конфигурации и сравните основную конфигурацию с конфигурацией поставщика. Отчёт о сравнении покажет все изменённые объекты — это ваш реестр «что проверить после».
4. Уточните путь обновления. В описании релиза указано, с каких версий допустимо обновление и какая нужна версия платформы. Если вы пропустили несколько релизов, возможно, придётся пройти промежуточные.
5. Скачайте дистрибутив. Для доработанной базы удобнее полный дистрибутив с .cf: он нужен, если конфигурация снята с поддержки или файл .cfu не подходит.
6. Разверните копию. Создайте новую базу и загрузите в неё .dt. Все эксперименты — только там.

Выбор способа обновления при доработках

Способ зависит от того, сколько изменено и как именно.

Если доработок немного, есть смысл подумать о переносе их в расширения. Тогда следующее обновление сведётся к штатной процедуре, а основную конфигурацию можно будет вернуть на полную поддержку.

Обновление конфигурации с доработками вручную: по шагам

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

Шаг 1. Запуск сравнения

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

Шаг 2. Разбор отличий

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

• 🟢 Взять из новой конфигурации поставщика — для объектов, где ваших правок нет или они больше не нужны.
• 🟡 Объединить с приоритетом основной конфигурации — ваши правки важнее, при конфликте остаётся ваш вариант.
• 🟠 Объединить с приоритетом новой конфигурации поставщика — при конфликте берётся код поставщика.
• ⚪ Не объединять — объект останется как есть.

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

Формы и модули: на что смотреть отдельно

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

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

Шаг 3. Объединение и разбор ссылок

Нажмите «Выполнить». Если новая версия ссылается на объекты, которые вы не стали брать, программа выведет список неразрешённых ссылок. Не закрывайте его не читая: обычно это реквизит или общий модуль, без которого объединённый код не скомпилируется.

Шаг 4. Проверка кода до обновления базы данных

1. Запустите Конфигурация → Проверка конфигурации.
2. Отметьте синтаксический контроль модулей, логическую целостность и поиск неправильных ссылок.
3. Исправьте всё, что относится к вашим доработкам.

Шаг 5. Обновление базы данных

Выполните Конфигурация → Обновить конфигурацию базы данных (F7). Здесь нужен монопольный доступ, если меняется структура хранения. Программа покажет список изменений структуры — примите его.

Шаг 6. Первый запуск в режиме Предприятия

Откройте базу пользователем с полными правами. Запустятся обработчики обновления данных. Дождитесь окончания и не прерывайте процесс.

Отложенные обработчики продолжат работу в фоне. Их состояние видно в Администрирование → Обслуживание, в подразделе о результатах обновления.

Если база снята с поддержки

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

Если база подключена к хранилищу

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

Как автоматизировать обновление доработанной 1С

Когда объединение отработано на копии и настройки сохранены, повторять его на рабочей базе можно в пакетном режиме Конфигуратора. Пример bat-файла для файловой базы:

set V8="C:\Program Files\1cv8\<версия>\bin\1cv8.exe"
set IB="D:\Bases\Buh"

rem 1. Выгрузка базы перед обновлением
%V8% DESIGNER /F %IB% /N "Администратор" /P "" /DumpIB "D:\Backup\buh_before.dt" /Out "D:\Logs\1_dump.log"

rem 2. Обновление конфигурации с сохранёнными настройками объединения
%V8% DESIGNER /F %IB% /N "Администратор" /P "" /UpdateCfg "D:\Updates\1Cv8.cfu" -Settings "D:\Updates\merge.xml" /Out "D:\Logs\2_update.log"

rem 3. Обновление конфигурации базы данных
%V8% DESIGNER /F %IB% /N "Администратор" /P "" /UpdateDBCfg /Out "D:\Logs\3_db.log"

Для клиент-серверной базы вместо /F указывают /S "сервер\имябазы". Перед запуском скрипта завершите сеансы пользователей: без этого обновление структуры не пройдёт.

Что ещё помогает:

• 🛠 vanessa-runner на OneScript — открытый набор команд для выгрузки, обновления и запуска тестов из скриптов.
• 🧪 Vanessa Automation — сценарные тесты: один раз описываете проверку доработанной формы, после каждого релиза запускаете автоматически.
• 📦 Хранилище конфигурации — история изменений и откат кода к любой версии.

Новая версия платформы и ваши доработки

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

Что учесть при доработках:

• 🔄 Режим совместимости. Поставщик может сменить его в новом релизе. Ваш код, написанный под старый режим, начнёт вести себя иначе: например, синхронные вызовы и устаревшие методы дадут ошибки или предупреждения.
• 🖥 Одинаковая версия у всех. В клиент-серверном варианте версия клиента должна совпадать с версией сервера 1С. Обновите сервер и все рабочие места в одно окно.
• 🔌 Внешние компоненты и обработки. Свои компоненты и внешние печатные формы проверьте на новой платформе отдельно.

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

Проверка базы после обновления

Объединение прошло, база запустилась — это ещё не результат. Проверьте:

1. Доработки из реестра. Пройдите каждый изменённый объект: откройте форму, проведите документ, сформируйте отчёт.
2. Расширения. Откройте Администрирование → Печатные формы, отчеты и обработки → Расширения. Если расширение не применилось, программа покажет ошибку при запуске.
3. Внешние обработки и печатные формы. Их обновление не затрагивает, но они могут обращаться к реквизитам, которые поставщик переименовал.
4. Права пользователей. Новые объекты релиза добавляются в типовые профили. Свои роли проверьте вручную: в них новых объектов не будет.
5. Обмены. Запустите синхронизацию с другими базами на тестовом узле и проверьте, что правила обмена не сломались.
6. Сравнение отчётов. Сформируйте оборотно-сальдовую ведомость в копии до и после обновления — суммы должны совпасть.

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

Ошибки, из-за которых теряются доработки

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

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