Обновление конфигурации 1С: как сохранить свои изменения

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

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

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

Как определить, какие изменения есть в конфигурации

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

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

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

Резервная копия и тестовая база: обязательная подготовка

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

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

Обновление через объединение: как не потерять доработки

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

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

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

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

Расширения конфигурации: способ не трогать типовую

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

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

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

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

Ручное объединение конфигураций

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

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

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

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

Подходит для печатных форм и отчётов без изменения метаданных. Не решает задачи изменения поведения типовых объектов

Снятие объекта с поддержки

Объект перестаёт обновляться, доработка сохраняется, но исправления поставщика в этот объект придётся переносить вручную

Настройка поддержки: что означают режимы

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

Распространённая ошибка — снимать объект с поддержки «для надёжности». Это сохраняет доработку, но отрезает объект от исправлений поставщика: со временем расхождение накапливается, и вернуть объект на поддержку становится сложно. Снимайте с поддержки только при реальной необходимости полностью переопределить поведение объекта.

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

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

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

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

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

Добавленные реквизиты и объекты

Норма

Присутствуют в конфигурации и содержат данные

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

Объект отсутствует или данные очищены — восстанавливайте из копии и повторяйте объединение

Доработанные модули

Норма

Ваши процедуры и изменения на месте, код компилируется

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

Изменения перезаписаны типовым кодом — конфликт был решён не в вашу пользу

Проведение документов и отчёты

Норма

Документы проводятся, отчёты формируются без ошибок

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

Ошибки в модуле объекта или набора записей — смотрите текст ошибки и журнал регистрации

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

Норма

Подключены, применяются, не выдают ошибок совместимости

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

Расширение отключено платформой из-за несовместимости — требуется его доработка

Типичные ошибки и как их избежать

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

Ответы на частые вопросы

Потеряются ли добавленные реквизиты при обновлении типовой конфигурации?

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

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

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

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

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

Стоит ли переносить доработки в расширение, если конфигурация уже изменена?

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

Как проверить, что резервная копия действительно рабочая?

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