«Показывать только дважды измененные свойства» в 1С: назначение, механизм и практические примеры

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

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

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

Что такое «дважды измененные свойства» с технической точки зрения?

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

• 📝 Текущее значение — актуальное состояние свойства.
• 🔄 Предыдущее значение — как свойство выглядело до последнего изменения.
• 📅 Версию конфигурации, в которой было внесено изменение.

«Дважды измененное» свойство — это свойство, которое было модифицировано минимум два раза в разных версиях конфигурации. Например:

1. В версии 1.0 свойство Видимость реквизита было установлено в Истина.
2. В версии 1.1 его изменили на Ложь.
3. В версии 1.2 снова вернули в Истина.

В этом случае свойство считается «дважды измененным», и его можно выделить через соответствующий фильтр.

Где находится опция в интерфейсе 1С?

Функция доступна в нескольких разделах конфигуратора, но чаще всего используется в инструментах сравнения и анализа изменений. Основные места, где можно встретить этот фильтр:

Чтобы включить фильтр, обычно достаточно установить галочку напротив пункта Показывать только дважды измененные свойства в окне сравнения или журнала. В некоторых версиях платформы (например, 1С:Предприятие 8.3.20+) опция может называться немного иначе — Фильтр по многократно измененным свойствам.

Зачем нужна эта функция: 5 практических сценариев

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

1. Слияние конфигураций без конфликтов. При объединении двух версий (например, после параллельной разработки) функция помогает выявить свойства, которые редактировались в обеих ветках. Это позволяет избежать потери данных при автоматическом слиянии.
2. Поиск «забытых» изменений. Иногда свойства модифицируются вручную (например, через прямой доступ к метаданным), но эти изменения не фиксируются в истории. Фильтр помогает их обнаружить.
3. Анализ последствий обновлений. После установки релиза платформы или типовой конфигурации можно проверить, какие свойства были изменены дважды — это укажет на потенциальные проблемы совместимости.
4. Отладка интеграций. При обмене данными между системами (например, через REST API или COM-соединение) дважды измененные свойства могут сигнализировать о некорректной синхронизации.
5. Оптимизация производительности. В крупных конфигурациях анализ всех свойств занимает много времени. Фильтр сужает круг поиска до наиболее «проблемных» объектов.

Пример из практики: при обновлении 1С:ERP с версии 2.4 до 2.5 в одном из проектов было обнаружено, что реквизит ДатаОплаты в документе ЗаказПокупателя дважды менял тип (с Дата на Число и обратно). Без фильтра это осталось бы незамеченным, что привело бы к ошибкам при проведении документов.

Как правильно работать с дважды измененными свойствами: пошаговая инструкция

Рассмотрим алгоритм действий на примере слияния двух версий конфигурации. Предположим, у вас есть основная база (Основная.cf) и база с доработками (Доработки.cf).

Создать резервные копии обеих конфигураций|Открыть основную конфигурацию в режиме «Конфигуратор»|Загрузить вторую конфигурацию через Файл → Открыть|Перейти в Конфигурация → Сравнить конфигурации-->

Шаг 1. Запуск сравнения

Откройте основную конфигурацию и выберите Конфигурация → Сравнить конфигурации. В качестве второй конфигурации укажите файл Доработки.cf. В окне сравнения найдите вкладку Фильтры и установите галочку напротив Показывать только дважды измененные свойства.

Шаг 2. Анализ результатов

Система выведет список объектов и свойств, которые были изменены минимум дважды. Обратите внимание на столбцы:

• 📌 Объект — название справочника, документа или другого элемента.
• 🔧 Свойство — конкретное свойство (например, Видимость, ТипЗначения).
• 🔄 Изменения — история модификаций (что было → что стало).
• ⚠️ Конфликт — маркер, указывающий на расхождения между версиями.

Шаг 3. Разрешение конфликтов

Для каждого свойства из списка необходимо принять решение:

• 🔄 Оставить текущее значение (из основной конфигурации).
• 📥 Принять изменение (из доработок).
• ⚙️ Ручная правка — если ни одно из значений не подходит, отредактируйте свойство вручную.

Шаг 4. Проверка и сохранение

После разрешения всех конфликтов запустите тестирование конфигурации (Конфигурация → Тестирование и исправление) и сохраните изменения. Рекомендуется также проверить работу критичных участков кода, связанных с измененными свойствами.

Типичные ошибки и как их избежать

Работа с дважды измененными свойствами требует внимания к деталям. Вот наиболее распространенные ошибки и способы их предотвращения:

⚠️ Внимание: В некоторых версиях платформы (например, 1С:Предприятие 8.3.18–8.3.19) опция фильтрации может работать некорректно при сравнении конфигураций с большим количеством объектов (более 10 000). В этом случае рекомендуется разбивать сравнение на части (по подсистемам или типам объектов).

• 🚫 Игнорирование «некритичных» свойств. Даже изменение свойства Подсказка или Цвет может влиять на пользовательский опыт. Всегда проверяйте контекст.
• 🔍 Некорректный порядок слияния. Если сначала слить доработки, а затем обновить типовую конфигурацию, дважды измененные свойства могут «затеряться». Всегда обновляйте типовую часть первой.
• 📂 Работа без резервной копии. Перед слиянием обязательно создайте бэкап обеих конфигураций. В 1С это можно сделать через Администрирование → Выгрузить информационную базу.
• 🔄 Автоматическое разрешение конфликтов. Никогда не используйте опцию «Принять все изменения» без предварительного анализа. Это может привести к потере бизнес-логики.

Пример ошибки: в одном из проектов после автоматического слияния свойство ПроверкаЗаполнения реквизита Контрагент было сброшено в Ложь, хотя в обеих версиях оно было Истина. Причина — конфликт из-за разных типов проверки (в одной версии стояло ВыдаватьОшибку, в другой — ВыдаватьПредупреждение).

Сравнение с другими инструментами анализа изменений

Функция «показывать только дважды измененные свойства» — не единственный способ отслеживать модификации в 1С. Рассмотрим, как она соотносится с альтернативными инструментами:

Главное отличие нашей функции — фокус на свойствах с многократными изменениями, что особенно ценно при:

• 🔄 Слиянии веток разработки.
• 📦 Обновлении типовых конфигураций с доработками.
• 🛠️ Поиске причин нестабильной работы после обновлений.

Для максимальной эффективности рекомендуется комбинировать инструменты. Например, сначала использовать Журнал изменений для общего анализа, а затем применить фильтр «дважды измененные свойства» для детальной проверки.

Примеры из реальных проектов

Разберем несколько кейсов, где анализ дважды измененных свойств помог избежать серьезных проблем.

Кейс 1: Обновление 1С:Бухгалтерии с 3.0 до 3.0.120

При обновлении типовой конфигурации было обнаружено, что свойство Длина реквизита Комментарий в документе ПоступлениеТоваров дважды менялось:

1. В версии 3.0.80 длина была увеличена с 100 до 250 символов.
2. В версии 3.0.100 длина была уменьшена обратно до 100 (из-за ошибки в типовом обновлении).
3. В локальной доработке длина была установлена в 500 символов.

Без анализа дважды измененных свойств при слиянии было бы принято значение 100, что привело бы к обрезке комментариев в существующих документах.

Кейс 2: Интеграция с внешней системой

При настройке обмена данными с 1С:УТ и Bitrix24 возникла ошибка синхронизации номенклатуры. Анализ показал, что свойство ИспользоватьПрефиксы в справочнике Номенклатура было:

• Изначально Ложь (в типовой конфигурации).
• Изменено на Истина в доработке для интеграции.
• Сброшено обратно в Ложь после обновления типовой части.

Это привело к дублированию элементов в Bitrix24. После ручного восстановления значения обмен заработал корректно.

Кейс 3: Миграция с 8.2 на 8.3

При переносе конфигурации с платформы 8.2 на 8.3 было обнаружено более 200 дважды измененных свойств, связанных с:

• 🔹 Изменением типов реквизитов (например, Строка → Число).
• 🔹 Модификацией прав доступа.
• 🔹 Переносом реквизитов между объектами.

Благодаря фильтрации удалось выявить и исправить проблемы до начала эксплуатации.

FAQ: Частые вопросы о дважды измененных свойствах

Процедура ЭкспортироватьДваждыИзмененныеСвойства()
Сравнение = Новый СравнениеКонфигураций;
Сравнение.ЗагрузитьИзФайла("путь_к_файлу_сравнения.cf");
Сравнение.УстановитьФильтрПоДваждыИзмененнымСвойствам(Истина);

Текст = Новый ТекстовыйДокумент;
Для Каждого Объект Из Сравнение.Объекты Цикл
Если Объект.Свойства.Количество() > 0 Тогда
Текст.ДобавитьСтроку(Объект.Имя);
Для Каждого Свойство Из Объект.Свойства Цикл
Текст.ДобавитьСтроку(Строка(Свойство.Имя) + ";" + Свойство.Изменения);
КонецЦикла;
КонецЕсли;
КонецЦикла;

Текст.Записать("дважды_измененные_свойства.csv");
КонецПроцедуры

Если Свойство.ИсторияИзменений.Количество() >= 3 Тогда
// Логика обработки
КонецЕсли;