Обновление типовой конфигурации 1С без потери доработок

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

Почему обновление ломает доработки

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

Отсюда типичные проблемы:

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

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

Расширение или изменение конфигурации: что проще обновлять

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

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

Подготовка: что сделать до начала обновления

От подготовки зависит большая часть результата. Мой список:

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

Отдельное внимание обменам: интеграции с сайтом, банками, кассами и другими базами нередко ломаются именно после обновления. О том, где у таких схем узкие места, я писал в статье про обмен 1С с сайтом.

Как проходит обновление на поддержке

Стандартный путь для конфигурации на поддержке выглядит так:

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

Ключевое: не нажимайте «взять из новой типовой» всей пачкой ради скорости. Так исчезают доработки, и вы узнаете об этом от пользователей через неделю.

Хорошая практика при ручном объединении модулей: смотрите на разницу построчно и оставляйте комментарии в коде в месте вашей правки, например:

// ДОРАБОТКА: проверка лимита скидки, см. ТЗ по доработке, дата правки
Если Скидка > ДопустимаяСкидка Тогда
    ВызватьИсключение "Скидка превышает допустимую";
КонецЕсли;
// КОНЕЦ ДОРАБОТКИ

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

Что проверить после обновления

Обновление базы завершилось без ошибок, это не означает, что всё работает. Нужна проверка по сценариям:

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

Хорошая привычка: смотреть журнал регистрации сразу после тестового прогона. Ошибки, которые пользователь не увидел, в журнале обычно есть.

План отката и безопасность данных

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

Практические правила:

• Обновление рабочей базы выполняется только после успешного прогона на копии.
• Между копией и рабочей базой не должно быть расхождений, которые вы забыли перенести (настройки, права, расширения).
• Не обновляйтесь в пиковое время и накануне отчётности.
• Сообщите пользователям о сроках и о том, что делать при проблемах.

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

Если каждое обновление превращается в нервный проект, проблема в архитектуре доработок, а не в самих релизах. Что помогает:

• Новые доработки делать в расширениях, а при изменении конфигурации минимизировать вмешательство: добавлять свои процедуры в отдельные модули и вызывать их из типового кода одной строкой.
• Вести реестр доработок: объект, цель, исполнитель, дата, ссылка на постановку. Хорошая постановка сама становится частью реестра, поэтому полезно знать, как писать техническое задание на доработку 1С.
• Не откладывать обновления на годы. Разница между версиями растёт, а вместе с ней растёт число конфликтов. Регулярные небольшие шаги дешевле одного большого скачка.
• Хранить исходники в системе контроля версий (выгрузка конфигурации в файлы) и фиксировать каждое обновление отдельным коммитом.
• Избегать дублирования типового функционала: если можно настроить штатными средствами, доработка не нужна.

Кто и когда должен участвовать в обновлении

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

Документирование результата

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

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

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

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

Как часто нужно обновлять типовую конфигурацию?

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

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

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

Нужен ли программист для обычного обновления?

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

Если нужна помощь с обновлением или переносом доработок, расскажите о задаче через страницу про доработку и интеграции 1С либо напишите в Telegram.