← На главную

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

Алгоритм трехстороннего сравнения конфигураций

Штатный механизм обновления через поддержку (меню Конфигурация — Поддержка — Обновить конфигурацию) базируется на концепции трехстороннего сравнения (three-way merge). Чтобы корректно сопоставить данные, платформа анализирует не две, а одновременно три версии метаданных:

1. Основная конфигурация — рабочая база данных, содержащая пользовательские доработки.
2. Старая конфигурация поставщика — эталонная версия предыдущего релиза (общий предок), которая хранится внутри информационной базы.
3. Новая конфигурация поставщика — файл обновления (файл .cf или .cfu), до версии которого выполняется переход.

Сравнивая эти три состояния, платформа определяет, кем именно были внесены изменения в каждый конкретный реквизит, модуль или форму, и на основе этого автоматически принимает решение о расстановке отметок.

Правила автоматической расстановки флажков

Рассмотрим базовые сценарии, с которыми сталкивается платформа при анализе объектов:

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

Почему отсутствует флажок на форме без видимых доработок?

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

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

Практические рекомендации по контролю обновления

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

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