Почему при обновлении 1С:Бухгалтерии появляются лишние дважды измененные объекты на замке и как это исправить?

Программист 1С v8.3 (Управляемые формы) 1C:Бухгалтерия IT и автоматизация бизнеса
← На главную

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

Однако при переходе на новые релизы (например, при обновлении «1С:Бухгалтерии предприятия 8» на релиз 3.0.75.70 и выше) и использовании современных версий платформы (семейства 8.3.15, 8.3.16 и новее) возникает крайне неприятная ситуация. Окно сравнения конфигураций внезапно заполняется сотнями объектов, которые находятся на строгой поддержке (на "замке"), но при этом система настойчиво помечает их как "дважды измененные". Нам приходится тратить часы на детальный анализ каждого объекта, чтобы убедиться, что реальных изменений в коде нет. Давайте вместе разберем причины этого системного сбоя и рассмотрим по шагам эффективные методы борьбы с ним. Для упрощения этой задачи можно использовать утилиту для автоматического сравнения и обновления измененных конфигураций.

Выясняем причины: откуда берутся ложные изменения?

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

  1. Особенности хранения и рендеринга справочной информации (HTML). Справочная информация к объектам конфигурации в системе 1С хранится в формате HTML-разметки. Для работы с ней конфигуратор использует системные библиотеки операционной системы Windows (движок MSHTML/Internet Explorer, а в более современных версиях — элементы WebKit). При обновлении платформы или переносе базы на другой сервер системный генератор HTML-кода может автоматически переписать служебные мета-теги в шапке справки. Для платформы изменения в строке вида META name=GENERATOR content="MSHTML..." на байтовом уровне выглядят как полноценная модификация объекта. В результате абсолютно все справки типовых объектов помечаются как измененные вами, хотя вы их даже не открывали.
  2. Изменение режима совместимости конфигурации. В релизах линейки 3.0.75 разработчики «1С» отключили режим совместимости со старыми версиями платформы (в частности, был осуществлен переход с совместимости 8.3.14 на использование новых механизмов 8.3.15). При изменении режима совместимости кардинально меняются правила внутренней сериализации XML-свойств объектов: форм, элементов управления, модулей и макетов. Платформа принудительно трансформирует структуру метаданных под новые стандарты. Если у вас в базе включена возможность изменения конфигурации, эти автоматические системные трансформации форм и отчетов платформа ошибочно интерпретирует как ручные изменения пользователя.
  3. Рассинхронизация связи между основной конфигурацией и конфигурацией поставщика. В процессе частых накатов обновлений (особенно когда обновления устанавливались "через релиз" или использовались только файлы обновлений .cfu вместо полных дистрибутивов .cf) внутренние индексы связей между объектами базы данных и их аналогами в конфигурации поставщика могут нарушиться. В окне настроек сравнения вы можете увидеть предупреждение о том, что основная конфигурация больше не связана с загружаемой конфигурацией поставщика как прямой потомок. Платформа теряет ориентир для корректного трехстороннего сравнения и начинает сопоставлять все объекты "с нуля", выводя их в ложные конфликты.

Решение 1: Восстановление корректной связи с конфигурацией поставщика

Если рассинхронизация связей метаданных приняла массовый характер, лучшим решением будет принудительное "лечение" конфигурации поставщика. Для этого выполним следующую последовательность действий:

  1. Прежде всего, обязательно создадим резервную копию информационной базы (выгрузку в файл .dt) или снимок базы на уровне СУБД (MS SQL / PostgreSQL).
  2. Найдем или скачаем чистый, полностью типовой дистрибутив (файл .cf) той версии конфигурации, которая установлена у вас в данный момент (до начала обновления). Очень важно использовать именно тот же релиз.
  3. В режиме Конфигуратора перейдем в меню Конфигурация — Сравнить, объединить с конфигурацией из файла... и укажем путь к скачанному чистому файлу .cf.
  4. В открывшемся окне сравнения и объединения снимем абсолютно все флажки со всех объектов метаданных. Наша задача — не изменить код, а заставить платформу восстановить внутренние идентификаторы связей (UUID).
  5. Нажмем кнопку Выполнить. Платформа синхронизирует структуру основной базы с эталонным файлом поставщика.
  6. Сохраним изменения в конфигурации (нажав клавишу F7). После этой процедуры ложные конфликты при последующем накате нового релиза должны исчезнуть.

Решение 2: Экспорт и чистая загрузка конфигурации поставщика

Рассмотрим еще один профессиональный метод, который отлично помогает избавиться от "хвостов" старых обновлений в конфигурации поставщика:

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

Этот простой шаг заставляет платформу полностью перестроить внутренние таблицы метаданных конфигурации, удаляя мусорные записи в системных таблицах СУБД и нормализуя связи между основной конфигурацией и поддержкой.

Решение 3: Локальное исправление правил поддержки для объектов

Если вы точно знаете, какие именно объекты (например, конкретные отчеты или общие модули) вы никогда не редактировали, но они упорно выходят в списке дважды измененных, мы можем принудительно вернуть их на строгую поддержку. Проанализируем, как это сделать:

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

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

Решение 4: Очистка кэша конфигуратора и реструктуризация базы данных

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

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

// Рекомендуемые настройки тестирования и исправления:
// 1. Проверка логической целостности конфигурации - Да
// 2. Проверка ссылочной целостности - Да (с очисткой или восстановлением ссылок)
// 3. Реструктуризация таблиц информационной базы - Обязательно Да
// 4. Переиндексация таблиц - Да

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

Резюме и практические рекомендации

Мы подробно разобрали, почему современные платформы 1С могут "капризничать" при сравнении конфигураций и как технические факторы (изменение версий HTML-рендерера, смена режима совместимости и сбои кэширования) порождают ложные конфликты.

Для минимизации подобных проблем придерживайтесь простого правила: при переходе на новые технологические платформы (например, при скачке с платформы 8.3.14 на платформу 8.3.16) сначала запустите базу на новой платформе, проведите ее полную реструктуризацию через тестирование и исправление, убедитесь в стабильности ее работы, и только вторым шагом приступайте к обновлению релиза самой конфигурации. Такой подход убережет вас от ложных срабатываний системы сравнения и сохранит ваше рабочее время!

← На главную