Почему измененные объекты не попадают в дважды измененные при обновлении 1С и как не потерять доработки?

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

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

Причины некорректного поведения фильтра «Дважды измененные свойства»

Проанализируем архитектуру механизма объединения конфигураций. В платформе 1С реализован алгоритм трехстороннего слияния (3-way merge). Для корректного определения конфликта платформа анализирует состояние трех конфигураций:

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

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

1. Рассинхронизация конфигурации поставщика в базе. Если в прошлом обновлении кто-то выполнил загрузку изменений через меню Конфигурация → Сравнить, объединить с конфигурацией из файла вместо штатного механизма поддержки Конфигурация → Поддержка → Обновить конфигурацию, конфигурация поставщика в базе осталась старой либо не обновилась вовсе. Для платформы изменения поставщика считаются отсутствующими, и объект классифицируется как измененный только пользователем.
2. Разница между синтаксическим парсингом и текстовым diff. Команда «Показать различия в модулях без учета структуры» выполняет прямое построчное текстовое сравнение. Дерево же объединения опирается на синтаксический разбор модуля по процедурам, функциям и директивам компиляции. Если правки затронули пробельные символы, комментарии, переводы строк (CRLF против LF) или мета-структуру, синтаксический анализатор платформы может не зафиксировать конфликт логических блоков.
3. Ошибки и кэширование конкретных релизов платформы. Сбои расчета контрольных сумм модулей метаданных периодически встречаются в различных версиях платформы 1С. В таких случаях кэш структуры конфигуратора выдает неверное состояние метаданных.

Самопроизвольный возврат объектов на поддержку: почему появляются «замки»

Нередко разработчики сталкиваются со связанной проблемой: после завершения объединения объекты конфигурации самопроизвольно переходят в статус «Не редактируется» (получают пиктограмму «замок»), хотя исходный код доработок может визуально остаться на месте. При следующем же обновлении такой заблокированный объект обновляется «в глухую», и весь доработанный код стирается.

Разберем по шагам, почему это происходит:

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

Пошаговый алгоритм исправления правил поддержки

Если вы обнаружили, что измененные объекты встали на «замок» или пропали из фильтра конфликтов, выполним правильную последовательность действий:

1. Откат на резервную копию. Восстановим информационную базу из выгрузки .dt или бэкапа СУБД, сделанного строго до начала обновления.
2. Проверка и ручная корректировка правил. Откроем конфигуратор и перейдем в меню:

   Конфигурация → Поддержка → Настройка поддержки

   Найдем объекты, по которым возникают ошибки. Убедимся, что для них явно установлено правило «Редактируется с сохранением поддержки». Если правило сбито, установим его вручную, нажав кнопку «Установить правила» для нужной ветки или конкретного объекта метаданных.
3. Очистка локального кэша конфигуратора. Удалим каталоги временных файлов конфигуратора пользователя в %LOCALAPPDATA%\1C\1cv8\ и %APPDATA%\1C\1cv8\, чтобы исключить влияние поврежденных кэшей структуры конфигурации.
4. Повторный запуск обновления. Выполним процедуру Конфигурация → Поддержка → Обновить конфигурацию. При появлении окна объединения перепроверим наличие объектов в дереве.

Надежные способы контроля доработок при обновлении

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

1. Подключение внешних программ трехстороннего слияния

В платформе 1С встроен механизм вызова внешних утилит сравнения (KDiff3, Beyond Compare, Araxis Merge, P4Merge). Для их интеграции перейдем в конфигураторе:

Сервис → Параметры → вкладка Сравнение/объединение → Модули

Выберем внешнюю программу для трехстороннего объединения. В отличие от штатного парсера, внешние инструменты (например, KDiff3) выполняют математически строгое сопоставление трех файлов (Base — старый релиз поставщика, Mine — текущая база, Theirs — новый релиз поставщика) и физически не позволяют пропустить конфликт строк.

2. Формирование контрольных отчетов сравнения

Перед началом любого обновления выполним превентивный контроль:

1. В окне Настройка поддержки нажмем «Сравнить конфигурацию с конфигурацией поставщика».
2. Сохраним подробный текстовый отчет о различиях (через меню Действия → Отчет о сравнении конфигураций). Этот файл — точный реестр всех внесенных в систему доработок.
3. После выполнения объединения с новым релизом поставщика повторно сформируем аналогичный отчет и сверим оба текстовых файла любой diff-утилитой. Все ранее присутствовавшие модификации должны остаться на месте.

3. Перенос доработок в расширения с аннотацией &ИзменениеИКонтроль

Современным стандартом разработки в среде 1С является вынос изменений из основного модуля во внешние расширения (cfe). Если требуется модифицировать логику типового метода (например, ОбработкаПроведения), используем аннотацию &ИзменениеИКонтроль:

&Вместо("ОбработкаПроведения")
Процедура Расш_ОбработкаПроведения(Отказ, РежимПроведения)
    #Вставка
    // Наш кастомный алгоритм перед стандартным проведением
    Если Не ПроверитьДополнительныеРеквизиты() Тогда
        Отказ = Истина;
        Возврат;
    КонецЕсли;
    #КонецВставки

    #Удаление
    // Типовой код, который необходимо отключить
    #КонецУдаления

    // Выполнение оставшегося типового кода поставщика
    ПродолжитьВызов(Отказ, РежимПроведения);
КонецПроцедуры

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