← На главную

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

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

Механизм работы фильтра «Дважды измененные свойства»

Для начала выясним, как платформа понимает, что свойство изменено «дважды». При обновлении система сравнивает три состояния объекта:

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

Если свойство в основной конфигурации отличается от старой конфигурации поставщика И при этом оно же изменилось в новой конфигурации поставщика, платформа помечает это как конфликт. Проблема заключается в том, что «отличие» в основной конфигурации может появиться само собой, без участия программиста.

Причина 1: Изменение порядка объектов и методов

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

Выясним, как это проверить в окне сравнения:

1. Найдем проблемный объект (например, справочник или обработку).
2. Нажмем на знак «+» рядом с объектом, чтобы развернуть его состав.
3. Обратим внимание на наличие иконок в виде синих стрелочек («вверх-вниз»). Эти стрелочки сигнализируют о том, что объект переместился в списке или внутри него изменился порядок подчиненных элементов.

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

Причина 2: Скрытые свойства платформы и Мобильный клиент

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

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

Причина 3: Сбои при расчете хеш-сумм (CRC)

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

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

Причина 4: Справочная информация и картинки

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

Алгоритм решения проблемы

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

Шаг 1: Использование отчета о сравнении

Перед тем как принимать решение, проанализируйте, что именно изменилось. Правой кнопкой мыши кликните по объекту в окне сравнения и выберите «Отчет о сравнении». Если в отчете указано только изменение порядка или «Справочная информация», значит, фактических изменений кода нет.

Шаг 2: Установка режима «Взять из конфигурации поставщика»

Для объектов, которые вы точно не меняли, выполните следующие действия:

1. Выделите группу таких объектов (можно воспользоваться множественным выделением через Shift).
2. Нажмите правую кнопку мыши.
3. Выберите пункт «Установить режим: Взять из конфигурации поставщика».
4. Убедитесь, что галочка объединения в колонке основной конфигурации снялась или заменилась на стандартное обновление.

Шаг 3: Техническое «переподключение» объектов (Сброс CRC)

Если после обновления объекты продолжают «фонить» в следующих релизах, применим более радикальный метод — «перезамок»:

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

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

Шаг 4: Межоперационный запуск Предприятия

При переходе между версиями (например, с 11.3 на 11.4) критически важно запускать 1С:Предприятие в обычном режиме или с ключом /UpdateCfg после каждого шага обновления. Это необходимо для того, чтобы отработали внутренние обработчики обновления данных. Эти обработчики могут изменять структуру метаданных «на лету», и если пропустить этот шаг, при следующем обновлении платформа обнаружит несоответствие структуры, которое она примет за ваше ручное изменение.

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