← На главную

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

Причина возникновения «фантомных» различий

Основная причина, по которой визуально идентичные объекты считаются разными — это различие их внутренних идентификаторов (GUID). Для платформы «1С:Предприятие» имя объекта (например, Перечисление.СтатусыЗаказов) является лишь строковым представлением, в то время как уникальность объекта в структуре метаданных определяется скрытым уникальным ключом. Если объект был удален и создан заново с тем же именем или если он был добавлен в двух разных базах вручную, их GUID не совпадут. В окне сравнения и объединения такие объекты будут восприниматься как разные, что мешает корректному обновлению и «мозолит глаза» специалисту.

Метод 1: Ручное сопоставление объектов в окне сравнения

Самый простой и эффективный способ, предусмотренный современными версиями платформы 8.3, — это механизм ручного сопоставления. Рассмотрим подробнее, как им воспользоваться:

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

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

Метод 2: Сброс признака модифицированности через «Настройку поддержки»

Если объект «висит» в измененных из-за некорректных правил поддержки, проанализируем ситуацию через специализированное окно. Посмотрим на алгоритм действий:

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

Метод 3: Использование конфигурации поставщика

Часто разработчики сравнивают основную конфигурацию с внешним файлом, забывая, что внутри базы данных хранится еще и «Конфигурация поставщика». Выясним, как использовать её для синхронизации:

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

Метод 4: Безопасное переименование и перезапись (для перечислений)

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

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

Метод 5: Глубокое исправление через XML и 1C:EDT

Для опытных специалистов рассмотрим вариант исправления GUID напрямую. Это исключает необходимость переименований и поиска ссылок в данных. Проанализируем шаги работы с файлами:

Современный инструмент 1C:Enterprise Development Tools (EDT) позволяет работать с конфигурацией как с набором XML-файлов. Схема действий такова:

1. Импортируем конфигурацию в проект EDT.
2. Находим XML-файл нужного объекта (например, Enum.ТипОплаты.xml).
3. В структуре XML находим тег Uuid. Это и есть тот самый идентификатор, который «не нравится» системе сравнения.
4. Открываем в текстовом редакторе аналогичный файл из полностью типовой конфигурации (также выгруженной в файлы).
5. Копируем правильный Uuid из типового файла в свой рабочий проект.
6. Выполняем экспорт проекта обратно в информационную базу.

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

Метод 6: Очистка кэша и проверка целостности

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

• Полностью очистить кэш конфигуратора. Удалите папки из %AppData%\1C\1Cv8\.
• Выполнить процедуру «Тестирование и исправление». Обязательно установите галочку «Проверка логической целостности конфигурации».
• Иногда помогает выгрузка конфигурации в .cf, создание чистой базы и загрузка этого .cf обратно. Это пересобирает внутренние индексы метаданных.

Резюме

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