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