← На главную

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

Выясним причины появления ложных расхождений

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

1. Разные версии платформы при разработке: Поставщик (фирма 1С) может собирать релиз на одной версии платформы (например, 8.3.22), а вы открываете и сохраняете конфигурацию на 8.3.25. Разные версии могут по-разному записывать одни и те же свойства. Типичный пример: <color #FF0000> превращается в <color #ff0000>. Для платформы это разные строки, и она фиксирует модификацию.
2. Особенности файлов обновления (cfu): Файл обновления содержит только дельту изменений. При его применении происходит процедура, похожая на «сравнение и объединение». В процессе этого объединения идентификаторы (UUID) некоторых внутренних элементов могут не заменяться на эталонные из конфигурации поставщика, а сохраняться из вашей основной конфигурации.
3. Скрытые свойства и кэши: В формах и макетах существуют невидимые в редакторе идентификаторы элементов. Если вы случайно переместили кнопку и вернули её назад, её внутренний порядок в XML-структуре может измениться. Обычное визуальное сравнение это не покажет, но побайтовое сравнение выявит разницу.

Способ 1: Загрузка полного файла конфигурации (наиболее эффективный)

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

Важно: Перед выполнением этих действий обязательно создайте резервную копию базы данных!

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

Рассмотрим, что происходит в этот момент: платформа полностью переписывает таблицы Config и ConfigSave в базе данных. В отличие от объединения, загрузка полностью удаляет старые записи и записывает новые, что гарантирует идентичность UUID и всех скрытых свойств. Однако помните, что этот метод затрет все ваши доработки. Чтобы их сохранить, используйте комбинированный подход, описанный ниже.

Способ 2: Метод «Базы-донора» для сохранения доработок

Когда нам нужно и «вернуть замок», и оставить свои изменения, мы можем применить стратегию переноса через промежуточную базу. Проанализируем этот алгоритм:

1. Создадим новую пустую базу того же релиза, загрузив в нее чистый .cf от поставщика.
2. В рабочей базе выгрузим конфигурацию в файл (work.cf).
3. В «чистой» базе выполним Конфигурация — Сравнить, объединить с конфигурацией из файла, выбрав наш work.cf.
4. В появившемся окне сравнения снимем галочки со всех объектов, которые должны быть «на замке» и где возникли фантомные расхождения. Оставим только реально доработанные объекты.
5. Выполним объединение и сохраним конфигурацию.
6. Теперь выгрузим полученный результат из этой «чистой» базы обратно в .cf.
7. В рабочей базе выполним Загрузить конфигурацию из файла.

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

Способ 3: Работа через выгрузку в файлы (XML)

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

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

Этот метод хорош тем, что он принудительно обновляет описание объекта в базе данных, игнорируя «интеллектуальные» алгоритмы объединения платформы, которые иногда и создают проблему.

Дополнительные рекомендации

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

Очистка кэша конфигуратора. Иногда расхождения существуют только в локальном кэше вашего компьютера. Перед радикальными мерами попробуйте полностью удалить базу из списка и добавить её заново или запустить конфигуратор с параметром /ClearCache. Это заставит платформу заново считать структуру метаданных из таблицы Config.

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

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

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