Как обновить 1С через механизм поддержки и не сломать доработки
Обновление конфигурации 1С через поддержку выполняется в Конфигураторе командой Конфигурация → Поддержка → Обновить конфигурацию, а конфликты решаются в окне Сравнение и объединение: за основу обычно берут изменения поставщика и переносят свои правки точечно. Ниже — короткий рабочий алгоритм и тактика по конфликтам.
Оглавление
Проверки и подготовка перед обновлением
-
Убедитесь, что поддержка поставщика сохранена
Откройте: Конфигурация → Поддержка → Настройка поддержки. Важно, чтобы была доступна конфигурация поставщика и объектная связь с ней не потеряна — иначе «штатное» обновление будет недоступно или бесполезно. -
Сделайте резервную копию и обновляйтесь на копии
Не обновляйте «вживую» на рабочей базе. Правильная схема: копия базы → обновление/merge → тест → повтор на продуктиве в окно обслуживания.
- Проверьте совместимость по платформе и порядок релизов
Если релиз требует минимальную версию платформы или запрещает «прыжок» через версии, сначала выровняйте платформу и/или обновляйтесь по цепочке.
Пошаговое обновление конфигурации через поддержку
- Завершите сеансы пользователей (или перенесите обновление в технологическое окно).
- В Конфигураторе выполните: Конфигурация → Поддержка → Обновить конфигурацию.
- Выберите источник обновления:
- из шаблонов (если релиз установлен в шаблоны),
- из файла
1cv8.cfu(типичный формат обновления).
- Дождитесь формирования различий — откроется Сравнение и объединение (это ключевой этап, где и появляются «конфликты»).
- После принятия изменений обязательно выполните: Конфигурация → Обновить конфигурацию базы данных.
Без этого метаданные в базе не применятся корректно, даже если объединение прошло «без ошибок».
Как решать конфликты обновления: тактика для модулей, форм и структуры
Конфликт означает, что один и тот же объект меняли и вы, и поставщик. Быстрый принцип: типовой релиз берем за основу, свои изменения переносим в него, а не наоборот.
Что обычно выбирать при конфликте (практический ориентир)
| Тип конфликта | Риск «взять старое целиком» | Рабочая тактика |
|---|---|---|
| Модули (код) | Высокий: теряются исправления/новые проверки | Сравнить, взять основу поставщика, перенести свои вставки вручную |
| Формы | Средний/высокий: ломаются команды/реквизиты/события | Принять структуру поставщика, затем вернуть свои элементы и обработчики точечно |
| Структура (реквизиты, ТЧ, типы) | Очень высокий: несовместимость механизмов и данных | Приоритет поставщика, свои изменения встраивать поверх с проверкой заполнения/типов |
Модули: как не потерять исправления поставщика
- Не выбирайте «оставить как было», если поставщик менял модуль: это частая причина новых ошибок после обновления.
- Переносите свои правки как минимальные вставки (идеально — по заранее помеченным блокам).
Если доработки регулярно конфликтуют, выгоднее вынести их в расширение/подписки на события/отдельные обработки — тогда в следующих релизах конфликтов будет кратно меньше.
Формы: проверяйте не только открытие, но и сценарии
После merge форм обязательно прогоните: открытие → ввод → запись → проведение → печать (если есть). Конфликт в форме часто проявляется не сразу, а на событии или команде.
Структура метаданных: думайте о совместимости
Если поставщик добавил реквизит/изменил тип — это может быть частью нового механизма (обмен, проведение, контроль заполнения). Сначала обеспечьте «как у поставщика», затем аккуратно адаптируйте свою логику (запросы, движения, заполнение).
Частые ошибки
- Обновление без бэкапа/без тестового контура — потом нечем откатываться и сложно понять, что именно сломалось.
- «Взяли старый модуль целиком» при конфликте — в итоге пропали исправления и проверки поставщика.
- Забыли Обновить конфигурацию базы данных после объединения.
- Разбирали конфликты «по списку», а не по критичности (сначала нужно трогать обмены/регламентные операции/закрытие периода, потом интерфейс).
- Не проверили расширения/внешние обработки на совместимость с новым релизом — ошибки всплывают уже в работе пользователей.
FAQ
Почему через поддержку лучше, чем загрузка .cf?
Поддержка сохраняет слой поставщика и помогает корректно сопоставлять изменения, что снижает риск «разъехать» типовые объекты и усложнить будущие обновления.
Что делать, если пункт обновления через поддержку недоступен?
Проверьте состояние поддержки: возможно, конфигурация снята с поддержки или потеряна конфигурация поставщика. В таких случаях планируют восстановление поддержки или обновление через ручное сравнение/объединение (на копии).
Можно ли обновиться сразу через несколько релизов?
Иногда да, но безопаснее следовать рекомендованной цепочке: так меньше конфликтов и ниже риск проблем с преобразованием данных.
Как понять, что конфликты решены правильно?
Минимум: конфигурация компилируется без ошибок, обновление БД прошло успешно, ключевые документы/отчеты/обмены выполняются на копии так же, как в рабочем контуре.