Как обновить базу 1С с доработками

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

Объём работы зависит от того, как именно внесены доработки. Если они реализованы через расширения конфигурации, обновление часто проходит почти как в типовой базе. Если же изменения внесены непосредственно в модули, формы и объекты конфигурации (режим «конфигурация на замке снята»), потребуется сравнение и объединение с ручным переносом правок.

Ниже разобран полный цикл: от подготовки и резервной копии до проверки результата и типичных ошибок. Инструкция ориентирована на конфигурации на платформе 1С:Предприятие 8.3 (УТ, ERP, Бухгалтерия, ЗУП и подобные).

Оцените, как внесены доработки

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

Также полезно собрать реестр доработок: какие объекты изменены, зачем и кем. На практике часто встречаются правки, сделанные годы назад, о назначении которых никто не помнит. Такие изменения — главный источник риска: при объединении непонятно, сохранять старую правку или принимать новый код поставщика.

Сделайте резервную копию и подготовьте стенд

Никогда не обновляйте рабочую базу напрямую. Минимальный набор перед началом: полная резервная копия базы (для файловой — копия каталога или выгрузка в .dt, для клиент-серверной — средствами СУБД) и выгрузка текущей конфигурации в файл .cf через «Конфигурация» → «Сохранить конфигурацию в файл». Файл .cf понадобится, если при объединении что-то пойдёт не так и потребуется откатить именно конфигурацию, а не всю базу.

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

Получите обновление и проверьте требования

Загрузите дистрибутив обновления с портала 1С:Обновление программ или через сервис автоматического обновления. Внимательно прочитайте файл описания поставки (обычно ReadMe или сопроводительная информация): там указано, с каких версий возможно обновление, требуется ли последовательная установка промежуточных релизов и какая минимальная версия платформы нужна.

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

Выполните сравнение и объединение конфигураций

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

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

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

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

Обновите конфигурацию базы данных и проверьте обработчики

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

В типовых конфигурациях ход обновления виден в разделе «Обновление версии программы» (или «Результаты обновления»). Убедитесь, что все обработчики завершились без ошибок. Ошибки отложенных обработчиков часто связаны именно с доработками: например, ваш код изменил структуру данных, которую обработчик поставщика ожидает в типовом виде.

Контрольные точки

Как проверить результат обновления

Номер версии в разделе «О программе»

Норма

Соответствует целевому релизу

Тревожный признак

Версия старая или обновление завершилось с ошибкой

Статус обработчиков обновления

Норма

Все обработчики выполнены, ошибок нет

Тревожный признак

Есть зависшие или завершившиеся с ошибкой обработчики

Работа доработанных функций

Норма

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

Тревожный признак

Ошибки в изменённых объектах, пропавшие кнопки или реквизиты

Проверка конфигурации в конфигураторе

Норма

Проверка модулей проходит без ошибок

Тревожный признак

Синтаксические ошибки в объединённых модулях

Что делать с расширениями конфигурации

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

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

Расширение или прямая доработка конфигурации

Расширение конфигурации

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

Прямая правка конфигурации

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

Внешние обработки и отчёты

Подходят для дополнительных печатных форм и отчётов без изменения конфигурации вообще. Не подходят для изменения логики проведения документов

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

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

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

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

Можно ли обновить доработанную базу через автоматическое обновление из интернета?

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

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

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

Как понять, какие объекты были доработаны?

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

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

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

Обязательно ли переносить доработки в расширения?

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