← На главную

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

Как работает фильтр «Показывать только дважды измененные»

Рассмотрим поведение платформы при включении данного фильтра. Кнопка Фильтр в окне сравнения и объединения управляет исключительно видимостью строк в дереве метаданных. Она не сбрасывает и не переключает флажки объединения объектов.

Проанализируем, что происходит со скрытыми объектами в момент выполнения объединения:

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

Таким образом, скрытые фильтром объекты полноценно участвуют в объединении в соответствии с заданными для них правилами.

Почему после объединения объекты конфигурации не обновились

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

1. Объект снят с поддержки. Если объекту метаданных ранее был установлен статус Снят с поддержки, штатный механизм обновления полностью исключает его из анализа. Платформа воспринимает такой объект как полностью пользовательский: правила обновления поставщика на него не действуют, и изменения вендора автоматически игнорируются.
2. Несовпадение внутренних идентификаторов (UUID). Платформа 1С идентифицирует элементы метаданных по внутренним идентификаторам (UUID). Если типовой объект в прошлом был случайно удален и создан заново с тем же именем, платформа считает его новым объектом. Изменения поставщика к нему не привяжутся.
3. Использование файла обновления (.cfu) вместо полного релиза (.cf). Файл .cfu содержит только дельту изменений между конкретными релизами. Если в истории базы были пропущены промежуточные обновления конфигурации поставщика или реальная версия метаданных не совпала с ожидаемой, часть изменений не применится.
4. Переименование объектов разработчиками 1С. При переименовании объекта вендором автоматическое сопоставление по имени не срабатывает. В дереве это выглядит как удаление старого объекта и добавление нового, что требует ручного сопоставления.

Как вернуть снятые объекты на поддержку

Если причиной отсутствия обновлений стало снятие объектов с поддержки, выполним восстановление правил поддержки по шагам:

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

Правила трехстороннего объединения дважды измененных объектов

Для качественного слияния дважды измененных модулей рекомендуется использовать трехстороннее сравнение (3-way merge) во внешних программах слияния, таких как KDiff3. Проанализируем правильный порядок сопоставления версий:

1. Базовая версия (Base / A): старая конфигурация поставщика (исходный типовой релиз, на котором находилась база до обновления).
2. Локальная версия (Mine / B): рабочая конфигурация с вашими кастомизациями и доработками.
3. Версия поставщика (Theirs / C): новая конфигурация поставщика из файла обновления.

Такой порядок позволяет алгоритму точно определить, какие строки были модифицированы разработчиком базы, какие изменения внесены фирмой «1С», а где возник прямой конфликт параллельного редактирования. Перед выполнением любых операций с конфигурацией всегда обязательно создавайте резервную копию информационной базы.