При обновлении типовых конфигураций «1С:Предприятие» специалисты часто сталкиваются с парадоксальной ситуацией: объект метаданных (например, отчет, обработка или макет), который находится на полной поддержке поставщика («на замке») и гарантированно не редактировался пользователем, внезапно попадает в фильтр «Дважды измененные объекты». В этой статье мы подробно разберем, почему это происходит, насколько это опасно и как правильно реагировать на подобные сообщения платформы.
Для начала проанализируем, как платформа «1С:Предприятие» понимает, что объект был изменен. В процессе сравнения и объединения участвуют три конфигурации: Основная конфигурация (ваша рабочая база), Старая конфигурация поставщика (хранится внутри вашей базы с момента прошлого обновления) и Новая конфигурация поставщика (из файла обновления .cf или .cfu).
Объект считается «дважды измененным», если:
Когда объект находится «на замке», второе условие теоретически выполняться не должно. Однако на практике платформа сравнивает не только визуальные свойства, но и контрольные суммы (хэш-суммы) внутренних файлов объекта. Если хэш-сумма объекта в вашей базе не совпадает с хэшем в «памяти» поставщика, платформа помечает его как измененный пользователем.
Чаще всего в список «фантомных» изменений попадают объекты, содержащие макеты или схемы DataCompositionSchema. Проанализируем ситуацию подробнее. Внутри XML-структуры макета или СКД хранятся не только настройки полей, но и служебная информация: версии форматов, настройки принтера по умолчанию, системные идентификаторы и даже метаданные о версии редактора, в котором этот макет сохранялся.
Если разработчик типового решения (поставщик) изменил версию инструментария или просто пересохранил макет во внешнем редакторе перед включением в релиз, идентификаторы внутренних узлов XML могут перестроиться. В результате, несмотря на то что визуально и функционально макет не изменился, его двоичный состав стал другим. Платформа видит это различие и интерпретирует его как изменение.
Выясним причину, связанную с целостностью базы. Иногда при предыдущих обновлениях (особенно если они выполнялись в режиме «динамического обновления») могла возникнуть ситуация, когда основная конфигурация обновилась корректно, а конфигурация поставщика, хранящаяся в системных таблицах, записалась с ошибкой или не обновилась вовсе.
В этом случае при следующем обновлении платформа будет сравнивать текущий объект с «битой» или устаревшей версией из старой конфигурации поставщика. Естественно, она обнаружит различие и решит, что вы сами правили этот объект, даже если замок стоит на месте.
Рассмотрим влияние механизма патчей. Современные типовые конфигурации активно используют автоматическую установку исправлений (патчей). Патч — это по сути расширение, которое временно перекрывает логику объекта. В некоторых версиях платформы механизм сравнения при обновлении может ошибочно учитывать изменения, внесенные активными патчами, как ручные изменения пользователя в основной конфигурации. Перед серьезным обновлением рекомендуется убедиться, что все временные патчи, которые уже вошли в новый релиз, корректно удалены.
Если обновление или загрузка конфигурации производится через выгрузку/загрузку в XML-файлы или с использованием утилиты ibcmd, стоит учитывать, что этим механизмам зачастую «все равно» на установленные замки. При загрузке структуры из XML платформа может перезаписать объект, изменив его внутреннее представление (например, порядок следования реквизитов в файле), что при последующем штатном сравнении вызовет срабатывание фильтра «дважды измененные».
Если вы столкнулись с этой проблемой, рассмотрим основные варианты действий:
В большинстве случаев это изменение является косметическим. Если на объекте стоит замок и вы точно знаете, что не снимали его, вы можете просто оставить настройку по умолчанию: «Взять из конфигурации поставщика». Платформа просто перезапишет объект актуальной версией от «1С», и в следующем цикле обновления он уже не будет беспокоить вас как измененный.
Если «фантомное» изменение раздражает или мешает анализу реальных доработок, можно попробовать сбросить состояние объекта. Разберем, как это сделать:
.cf файлом поставщика этой же версии.Это заставит платформу пересчитать контрольные суммы и синхронизировать основную конфигурацию с конфигурацией поставщика.
Иногда помогает стандартная процедура тестирования и исправления. Выполним следующие шаги:
Резюме: Появление объекта на замке в списке измененных — это в 90% случаев особенность работы платформы с хэш-суммами макетов и СКД, а не признак взлома поддержки. Проанализируем состав изменений в окне сравнения: если отличия только в «свойствах параметра» или невидимых глазу структурах XML — смело обновляйте объект версией поставщика.