При обновлении доработанных конфигураций 1С специалисты часто сталкиваются с ситуацией, когда система помечает объект как измененный (отличный от типового), но при сравнении модулей текста выясняется, что программный код абсолютно идентичен. Это вызывает закономерные вопросы: что именно было изменено, нужно ли сохранять эти правки и как их вообще увидеть? В рамках данной статьи мы разберем методику поиска «невидимых» изменений и выясним, на что стоит обратить внимание в первую очередь.
Рассмотрим ситуацию, когда МодульОбъекта или МодульМенеджера не содержат правок. В этом случае изменения, скорее всего, затронули свойства самого объекта метаданных. Проанализируем основные свойства, которые могут влиять на статус модифицированности:
ПланыОбмена, изменения часто кроются не в модуле, а во вкладке «Состав». Проверим список объектов, входящих в обмен, и признаки авторегистрации для каждого из них.Разберем ситуацию с формами. Если код МодульФормы чист, «фантомные» изменения могут скрываться в визуальной части или в настройках элементов. Выясним, что именно могло измениться:
Порядок обхода: Изменение последовательности перехода между полями по клавише Tab — это одно из самых труднозаметных отличий. В дереве свойств формы это выглядит как изменение коллекции элементов, хотя визуально всё может оставаться прежним.
Свойства элементов формы: Проанализируем настройки колонок в табличных частях или полей ввода. Если заголовок, ширина или видимость установлены в значение, отличное от «Авто», это будет считаться доработкой. Также стоит проверить привязки (в обычных формах) и настройки группировки (в управляемых формах).
Обработчики событий: Проверим, не назначены ли элементам формы пустые обработчики. Бывает, что в свойствах кнопки указано событие ПриНажатии, но сама процедура в модуле отсутствует или была удалена вручную — такая «битая» ссылка на событие делает форму измененной.
Для того чтобы точно увидеть, в чем заключается разница, воспользуемся штатным сервисом вывода отчета. Выполним следующие шаги:
Такой детальный отчет выведет все свойства объекта в виде таблицы, где измененные значения будут выделены цветом. Проанализируем полученный документ: если в нем нет значимых отличий в реквизитах, макетах или коде, а изменены лишь второстепенные свойства (например, версия платформы, в которой сохранялся объект), такие изменения можно проигнорировать.
Иногда 1С показывает различия из-за особенностей внутреннего хранения данных. Рассмотрим основные причины возникновения «технического шума»:
Разница версий платформы: Если конфигурация-поставщик была сохранена в одной версии платформы (например, 8.3.18), а ваша рабочая база — в другой (8.3.22), внутренняя структура XML-файлов метаданных может незначительно измениться. Платформа распознает это как модификацию.
Уникальные идентификаторы (UUID): Если какой-то реквизит был удален и создан заново с точно таким же именем, он все равно будет считаться новым объектом из-за несовпадения внутреннего UUID. Это часто случается при некорректном переносе доработок между базами.
Скрытые символы: Разберем ситуацию с макетами и текстами. Наличие невидимых символов (разные типы переноса строки, неразрывные пробелы) часто приводит к тому, что макет или текстовый документ помечается как измененный, хотя визуально текст идентичен.
Если стандартный отчет не помогает внести ясность, применим самый надежный метод — сравнение XML-структур. Выполним выгрузку обеих конфигураций в файлы через меню Конфигурация -> Выгрузить конфигурацию в файлы. После этого можно использовать внешние утилиты сравнения текстов (например, WinMerge). Это позволит увидеть изменения в структуре объекта вплоть до каждого тега и символа. Это особенно полезно для анализа ОбщихФорм и сложных Документов, таких как ИнвентаризацияТоваров.
Резюме: Если после детального анализа выяснится, что изменения носят технический характер или не несут смысловой нагрузки, при обновлении рекомендуется заменить такой объект объектом из новой типовой конфигурации. Это позволит «снять» признак модифицированности и облегчит последующую поддержку системы.