← На главную

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

Механизм работы трехстороннего сравнения

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

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

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

Причина 1: Рассинхронизация конфигурации поставщика

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

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

Причина 2: Различия в кэше и версиях платформы

Проанализируем ситуацию, описанную автором темы: на одном компьютере всё прошло успешно, а на другом — возникли проблемы. Это часто связано с локальным кэшем метаданных. Платформа кэширует результаты сравнения, и если кэш поврежден, фильтры могут работать некорректно. Также стоит убедиться, что на обоих серверах/компьютерах используется одна и та же версия платформы 1С, так как алгоритмы сравнения некоторых свойств (например, макетов или форм) могут незначительно меняться от версии к версии.

Решение проблемы через загрузку готового файла (CF)

Если вы уже подготовили эталонную конфигурацию на одном компьютере (провели сравнение, объединение и проверку), нет смысла повторять этот трудоемкий процесс на другой базе. Рассмотрим наиболее правильный и безопасный алгоритм:

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

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

Разбор ситуации с удалением объектов

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

Посмотрим на риски такого подхода:

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

Рекомендации по исправлению «засоренной» поддержки

Если вы решили все же разобраться с фильтром, выполним следующие шаги по шагам:

Шаг 1: Проверка настройки поддержки. Перейдем в меню Конфигурация — Поддержка — Настройка поддержки. Проверим, какая версия поставщика там указана. Если она не совпадает с той, на которой вы фактически работали до обновления, значит, произошла рассинхронизация.

Шаг 2: Очистка кэша. Закроем конфигуратор и удалим содержимое папок кэша (обычно находятся в %LOCALAPPDATA%\1C\1Cv8\). Это заставит платформу заново пересчитать контрольные суммы объектов при сравнении.

Шаг 3: Тестирование и исправление. Иногда помогает запуск процедуры Администрирование — Тестирование и исправление с выбранным пунктом «Проверка логической целостности конфигурации». Это может выявить «битые» ссылки в метаданных, которые мешают фильтру «дважды измененные» работать адекватно.

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

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