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