Администрирование · 11 мин
Как обновлять 1С с расширениями без сбоев
Как безопасно обновить конфигурацию 1С с подключёнными расширениями: проверка совместимости, адаптация, типовые ошибки и порядок действий после обновления.
Расширения конфигурации — удобный способ доработать типовую 1С без снятия её с поддержки. Но именно они чаще всего становятся источником проблем при обновлении: после установки нового релиза расширение может отключиться, выдавать ошибки или молча искажать данные. Причина проста — расширение «знает» структуру той версии конфигурации, под которую его разрабатывали, и любое изменение типовых объектов может нарушить эту связь.
Хорошая новость в том, что обновление базы с расширениями — вполне управляемый процесс, если действовать по порядку: сделать копию, проверить совместимость на тестовой базе, адаптировать расширения и только потом переносить изменения в рабочую среду. Ниже разобран весь цикл — от подготовки до проверки результата, с типичными ошибками и критериями, по которым можно понять, что обновление прошло успешно.
Почему расширения ломаются при обновлении
Расширение конфигурации накладывается поверх типовых объектов: форм, модулей, запросов, ролей. Когда поставщик выпускает новый релиз, типовые объекты меняются — переименовываются процедуры, изменяется состав параметров, перестраиваются формы. Если расширение заимствовало изменённый объект или вызывало изменённый метод, возникает конфликт.
Платформа умеет выявлять часть таких конфликтов автоматически: при загрузке расширения выполняется проверка применимости, и проблемное расширение помечается как неприменимое. Однако не все ошибки видны сразу — некоторые проявляются только при выполнении конкретных операций, например при проведении документа или формировании отчёта.
Поэтому правило простое: отсутствие ошибок при загрузке расширения — необходимое, но недостаточное условие. Нужна ещё функциональная проверка тех сценариев, которые расширение затрагивает.
Подготовка: копия, тестовая база и список расширений
Первый шаг — резервная копия рабочей базы. Для файловой базы достаточно скопировать каталог или выгрузить базу в файл .dt через конфигуратор. Для клиент-серверной базы используйте штатные средства СУБД или выгрузку .dt. Проверьте, что копия восстанавливается: бэкап, который нельзя развернуть, не является бэкапом.
Второй шаг — тестовая база. Разверните копию рабочей базы в отдельном каталоге или на отдельном сервере и выполняйте все эксперименты только там. Это позволяет спокойно обновляться, ломать и переделывать, не рискуя данными пользователей.
Третий шаг — инвентаризация расширений. Откройте в конфигураторе или в режиме «Предприятие» список подключённых расширений и зафиксируйте: название, версию, назначение, наличие исходников (файл .cfe) и ответственного разработчика. Если расширение делал сторонний подрядчик, заранее уточните, обновляет ли он свои решения под новые релизы.
- 1Сделайте резервную копию рабочей базы и проверьте её восстановление
- 2Разверните тестовую базу из копии
- 3Составьте список расширений: версия, назначение, наличие .cfe-файла
- 4Уточните наличие обновлений расширений у их разработчиков
- 5Скачайте дистрибутив нового релиза конфигурации
Обновление конфигурации на тестовой базе
Обновление выполняется штатно: через конфигуратор («Конфигурация → Поддержка → Обновить конфигурацию») или через интернет-поддержку в режиме «Предприятие». Если пропущено несколько релизов, обновляйтесь последовательно по цепочке, указанной поставщиком, — пропуск промежуточных версий может привести к ошибкам обработчиков обновления данных.
После завершения обновления конфигурации базы данных откройте список расширений. Платформа автоматически перепроверит их применимость. Расширения, которые перестали соответствовать конфигурации, будут отключены или помечены — это сигнал, что их нужно адаптировать.
Не поддавайтесь искушению просто удалить «мешающие» расширения, чтобы быстрее завершить обновление. Если расширение добавляло данные (например, дополнительные реквизиты через свои объекты) или использовалось в бизнес-процессах, его удаление может привести к потере функциональности и накопленных сведений.
Адаптация расширений под новый релиз
Адаптация выполняется в конфигураторе на тестовой базе. Откройте расширение на редактирование — конфигуратор покажет заимствованные объекты, которые изменились в основной конфигурации. Для каждого конфликта нужно решить, как привести код расширения в соответствие с новой версией типового объекта.
Изменённые формы
Если расширение дорабатывало типовую форму, а в новом релизе форма перестроена, заимствованную форму нужно синхронизировать. В конфигураторе для этого есть механизм обновления заимствованной формы: платформа подтянет изменения типовой формы, сохранив добавленные расширением элементы. После синхронизации проверьте, что добавленные поля и команды по-прежнему работают.
Изменённые процедуры и функции
Если расширение вызывало типовые методы, которые переименованы или у которых изменился состав параметров, код придётся править вручную. Найдите в новом релизе актуальный аналог метода — часто поставщик оставляет устаревшую процедуру-обёртку, но иногда метод удаляется полностью. После правки выполните синтаксическую проверку модулей расширения.
Аннотации «Вместо», «После», «Перед»
Особого внимания заслуживают методы с аннотациями перехвата. Если типовой метод, который расширение оборачивало через «Вместо», изменился, логика расширения может конфликтовать с новой логикой типового кода. Сравните старую и новую версии типового метода и убедитесь, что перехват по-прежнему уместен. По возможности заменяйте «Вместо» на «Перед» или «После» — так расширение меньше зависит от внутреннего устройства типового кода.
Храните исходники расширений (.cfe) в системе контроля версий и для каждого релиза конфигурации фиксируйте, какая версия расширения с ним совместима. Это превращает адаптацию из поиска по памяти в контролируемый процесс и позволяет быстро откатиться, если новая версия расширения работает хуже старой.
Проверка результата перед переносом в рабочую базу
После адаптации прогоните на тестовой базе ключевые сценарии, которые затрагивают расширения: создание и проведение документов, печатные формы, обмены, отчёты, регламентные задания. Проверяйте не только отсутствие ошибок, но и корректность результата — например, что печатная форма содержит все данные, а документ делает правильные движения.
Полезно запустить тестирование и исправление информационной базы на копии, а также проверить журнал регистрации на предмет ошибок, возникших во время обновления данных. Ошибки обработчиков обновления, оставленные без внимания, проявятся позже в самый неподходящий момент.
Как проверить результат
Все расширения активны, статус применимости без ошибок
Расширение отключено или помечено как неприменимое
Документы проводятся без сообщений об ошибках
Ошибки вызова методов или отсутствующих объектов
Формируются и содержат полные данные
Пустые поля, ошибки компоновки, пропавшие макеты
Нет ошибок обработчиков обновления
Записи об ошибках при обновлении данных
Перенос обновления в рабочую базу
Переносите обновление в нерабочее время, предупредив пользователей. Перед началом сделайте ещё одну резервную копию рабочей базы — именно в текущем состоянии, а не ту, что делали в начале работ. Завершите сеансы пользователей и отключите регламентные задания на время обновления.
Порядок переноса зависит от того, как вы работали. Если тестовая база была копией рабочей и с тех пор в рабочей накопились новые данные, обновляйте рабочую базу тем же дистрибутивом, а затем загрузите адаптированные версии расширений из файлов .cfe, сохранённых на тестовой базе. После обновления проверьте применимость расширений и прогоните сокращённый набор проверок уже на рабочей базе.
Как снизить зависимость обновлений от расширений
Если каждое обновление превращается в адаптацию, стоит пересмотреть подход к доработкам. Используйте штатные механизмы дополнительных отчётов и обработок (БСП), дополнительные реквизиты и сведения — они обновлению не мешают. В расширениях минимизируйте число заимствованных объектов и предпочитайте аннотации «Перед» и «После» аннотации «Вместо».
Также имеет смысл регулярно пересматривать список расширений: часть доработок со временем появляется в типовой конфигурации, и расширение можно просто отключить. Чем меньше расширений и чем они «легче», тем дешевле и быстрее проходит каждое обновление.
Что важно запомнить
Обновление 1С с расширениями безопасно только через тестовую копию: бэкап, обновление, проверка применимости, адаптация, функциональное тестирование — и лишь затем перенос в рабочую базу. Свежая резервная копия перед обновлением рабочей базы обязательна.
Частые вопросы
Можно ли обновлять 1С, если расширение стало неприменимым?
Технически платформа позволит обновить конфигурацию, а неприменимое расширение просто отключится. Но делать это в рабочей базе стоит только если функциональность расширения не критична. Иначе сначала адаптируйте расширение на тестовой копии и переносите обновление вместе с исправленной версией.
Что делать, если нет исходников расширения, а разработчик недоступен?
Если расширение подключено в базе, его можно открыть в конфигураторе и сохранить в файл .cfe — исходный код сохраняется вместе с расширением, если при разработке не включалась защита. Дальше адаптацию может выполнить любой специалист по 1С. Если код защищён паролем поставщика, без исходников останется только искать замену расширению.
Нужно ли отключать расширения перед обновлением конфигурации?
Специально отключать их не требуется — платформа сама перепроверит применимость после обновления. Отключение имеет смысл в одном случае: если известно, что расширение конфликтует с обработчиками обновления данных. Тогда обновите конфигурацию без него, адаптируйте и подключите обратно.
Как откатиться, если обновление прошло неудачно?
Единственный надёжный способ — восстановить базу из резервной копии, сделанной непосредственно перед обновлением. Поэтому копия должна быть свежей и проверенной на восстановление. Обратите внимание: данные, введённые пользователями между копией и откатом, будут потеряны.
Чем расширение лучше прямой доработки конфигурации при обновлении?
При прямой доработке типовые объекты изменяются в самой конфигурации, и при обновлении каждое изменение нужно вручную сопоставлять в режиме объединения — это долго и чревато ошибками. Расширение хранится отдельно, типовая конфигурация остаётся на поддержке, а объём ручной работы при обновлении существенно меньше.
Как понять, какие именно объекты расширения конфликтуют с новым релизом?
Откройте расширение в конфигураторе на обновлённой тестовой базе: изменённые заимствованные объекты будут подсвечены в дереве, а при проверке применимости платформа выдаст список конкретных несоответствий с именами объектов и причинами конфликта.