Как перенести новый релиз в доработанную конфигурацию и сохранить свои правки

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

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

Почему доработанная конфигурация обновляется иначе, чем типовая

У типовой конфигурации одна правда — код поставщика. Новый релиз просто заменяет старый. У нетиповой при обновлении сталкиваются три версии:

• 📦 старая конфигурация поставщика — тот релиз, с которого вы когда-то начинали доработки (платформа хранит его внутри базы);
• 🛠 основная конфигурация — то, что у вас сейчас, с вашими правками;
• 🆕 новая конфигурация поставщика — релиз, на который переходите.

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

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

Как узнать, в каком состоянии ваша конфигурация

Откройте Конфигурация → Поддержка → Настройка поддержки. Там видно версию конфигурации поставщика и режим:

Подготовка к обновлению нетиповой 1С

Обновление доработанной базы никогда не делают сразу в рабочей базе. Последовательность такая.

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

Какой способ обновления нетиповой конфигурации выбрать

Способов несколько, и они отличаются не только трудоёмкостью, но и тем, во что превратятся будущие обновления.

Если сомневаетесь, ориентир простой: доработки сделаны «по всему коду» и их десятки — обновление через поддержку. Правок 5–15 и они касаются форм и печати — разумнее один раз вынести их в расширение.

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

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

Пошаговое обновление нетиповой 1С через сравнение и объединение

Ниже — сценарий для конфигурации на поддержке с разрешёнными изменениями. Все действия — в тестовой копии.

Шаг 1. Запуск обновления

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

Шаг 2. Отфильтруйте только конфликты

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

Шаг 3. Разберите каждый дважды изменённый объект

Для объекта выбирают режим объединения:

• ✅ Взять из новой конфигурации поставщика — ваша правка пропадёт. Годится, если поставщик сам сделал то, что вы когда-то дописывали.
• 🔀 Объединить с приоритетом основной конфигурации — сливаются обе версии, при конфликте в одной строке побеждает ваша.
• 🔀 Объединить с приоритетом новой конфигурации поставщика — то же, но спорные места берутся у поставщика.
• ⛔ Не объединять — объект остаётся вашим, новшества поставщика в нём не появятся.

Для модулей не доверяйте автоматическому слиянию вслепую. Откройте сравнение модуля и просмотрите процедуры, которые изменились у обеих сторон. Типичная ситуация: поставщик переименовал процедуру или добавил ей параметр, а ваш код вызывает её по-старому. Слияние пройдёт без замечаний, а ошибка вылезет при проведении документа.

Шаг 4. Сохраните настройки объединения

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

Шаг 5. Выполните объединение и проверку

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

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

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

Расширения конфигурации: как упростить следующие обновления нетиповой 1С

Расширения появились в платформе 8.3.6 и с тех пор стали главным способом дорабатывать типовые решения без снятия их с поддержки. Идея в том, что основная конфигурация остаётся типовой, а все правки лежат в отдельном слое .cfe.

Что удобно выносить в расширение:

• 🖨 печатные формы и макеты;
• 🧾 новые реквизиты и элементы на формах;
• ⚙️ дополнительную логику при записи и проведении — через аннотации &Перед, &После, &Вместо;
• 📊 собственные отчёты и обработки.

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

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

1. Обновите основную конфигурацию как типовую — разбирать нечего.
2. Откройте расширение в Конфигураторе и проверьте его на ошибки.
3. Если поставщик изменил перехваченные процедуры, поправьте расширение под новый текст и сохраните.
4. Выполните обновление конфигурации базы данных, загрузку расширения и обновление базы — это разные шаги, ни один не пропускайте.

Что проверить после обновления доработанной базы

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

Учёт

• 📑 Сформируйте оборотно-сальдовую ведомость за прошлый закрытый период в копии до и после обновления. Суммы должны совпадать до копейки.
• 🔁 Перепроведите несколько документов прошлого месяца каждого ключевого вида и сравните движения.
• 📆 Пройдите закрытие месяца в тестовой копии.

Доработки

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

Обмены и интеграции

• Выполните обмен с другими базами в тестовом контуре, не с рабочими узлами.
• Проверьте выгрузки на сайт, в банк, в ЭДО, если они настраивались программистом.

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

Где чаще всего ломается обновление нетиповой конфигурации

Ниже — ситуации, которые встречаются на практике, с причиной и выходом.

Автоматизация обновлений нетиповых баз

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

"C:\Program Files\1cv8\8.3.25.1000\bin\1cv8.exe" DESIGNER /F "D:\Bases\Buh_test" /N "Администратор" /P "пароль" /UpdateCfg "D:\Updates\1Cv8.cfu" /UpdateDBCfg /Out "D:\Logs\update.log"

Для серверной базы вместо /F указывают /S "сервер\имя_базы". Номер платформы в пути замените на свой.

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

1. Программист разбирает конфликты один раз на эталонной копии и сохраняет настройки.
2. Скрипт ночью выгружает .dt, обновляет конфигурацию с этими настройками и обновляет структуру базы.
3. Утром результат проверяют по журналу /Out и короткому регрессионному прогону.

Для командной разработки используют хранилище конфигурации или 1С:EDT с Git: доработки видны как история изменений, а не «где-то в модулях». Сборку и прогон тестов подключают через OneScript, vanessa-runner и CI-сервер вроде Jenkins.

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