Каждый разработчик и администратор баз данных «1С:Предприятие» рано или поздно сталкивается с ситуацией, когда при обновлении нетиповой конфигурации два абсолютно одинаковых объекта (например, перечисления, справочники или роли) отказываются сопоставляться автоматически. В окне сравнения и объединения один из них отображается как «Новый» (со стороны поставщика), а существующий в нашей конфигурации помечается «На удаление».
В этой статье мы подробно проанализируем, почему возникает эта проблема, разберем опасные заблуждения участников форума, рассмотрим внутреннее устройство платформы в части идентификации объектов и предложим единственно верное, безопасное и штатное решение этой проблемы.
Главная и единственная причина, по которой платформа не связывает два внешне идентичных объекта — это различие их внутренних уникальных идентификаторов (GUID / UUID). Для СУБД и платформы «1С:Предприятие» имя объекта (например, Перечисление.СтатусыЗаказов) — это лишь текстовое представление для разработчика. На уровне базы данных все связи строятся строго по 128-битным уникальным идентификаторам.
Рассмотрим подробнее три типичные ситуации, когда GUID объектов расходятся:
GUID гарантированно различаются.Важно понимать фундаментальное различие в механизмах сопоставления платформы в зависимости от режима работы:
На форумах часто предлагают «простые» решения: удалить старый объект, принять новый из обновления поставщика, а затем запустить поиск и замену дублей в пользовательском режиме. Выясним, почему такой подход крайне опасен для работающей информационной базы.
Риск 1: Потеря ссылочной целостности (битые ссылки)
Если вы согласитесь на удаление старого объекта (например, перечисления Перечисление.ВариантыОплаты) и примете новый от поставщика, то во всех документах, где было выбрано это перечисление, значения очистятся. На уровне СУБД ссылки будут указывать на старый, уже несуществующий идентификатор. На форме это отобразится как грустная надпись <Объект не найден...> или значение просто сбросится в Неопределено. Вся историческая аналитика за прошлые периоды будет мгновенно разрушена.
Риск 2: Скрытые ссылки в программном коде
Участники обсуждения часто проверяют ссылки только в пользовательском режиме с помощью типовых обработок. Однако программный код конфигурации может обращаться к объектам напрямую. Проанализируем пример кода:
Если ЗначениеЗаполнено(СсылкаНаДокумент.ВариантОплаты)
И СсылкаНаДокумент.ВариантОплаты = ПредопределенноеЗначение("Перечисление.ВариантыОплаты.Безналичный") Тогда
// Выполнение логики оплаты
КонецЕсли;
Если вы удалите старое перечисление и создадите новое, его предопределенные значения получат новые GUID. В результате старые документы, в которых записан старый GUID значения Безналичный, перестанут проходить эту проверку, так как для платформы это будут разные элементы, несмотря на одинаковое текстовое представление.
Риск 3: Сбои в механизмах интеграции и обмена данными (РИБ, КД)
Если база является главным узлом в Распределенной информационной базе (РИБ) или участвует в обменах через «Конвертацию данных», замена GUID объекта приведет к гарантированному зацикливанию обменов, дублированию записей во всех подчиненных узлах или полному отказу приема пакетов синхронизации.
Вместо опасных манипуляций с удалением и последующим поиском дублей, воспользуемся штатным инструментом платформы «1С:Предприятие 8» — ручным сопоставлением объектов непосредственно в окне сравнения и объединения конфигураций.
Разберем этот процесс по шагам:
.cf / .cfu).Почему это абсолютно безопасно и правильно?
При ручном сопоставлении платформа сохраняет внутренний идентификатор (GUID) вашего существующего объекта. Никакие данные в СУБД не изменяются и не затираются. При этом платформа фиксирует связь между вашим GUID и GUID поставщика в служебных таблицах поддержки базы данных. При всех последующих обновлениях эти объекты будут сопоставляться полностью автоматически!
Если вы все же сомневаетесь, использовался ли несопоставленный объект ранее в движениях или реквизитах, мы можем написать небольшую обработку для детальной проверки. Рассмотрим программный код, который выполняет поиск всех ссылок на проверяемый объект метаданных:
// Создадим массив для поиска ссылок
МассивПоиска = Новый Массив;
// Получим все значения проверяемого перечисления
Для Каждого ЗначениеПеречисления Из Перечисления.ВариантыОплаты Цикл
МассивПоиска.Добавить(ЗначениеПеречисления);
КонецЦикла;
// Выполним поиск ссылок по всей базе данных
ТаблицаСсылок = НайтиСсылки(МассивПоиска);
Если ТаблицаСсылок.Количество() > 0 Тогда
Сообщить("Внимание! Обнаружены ссылки на проверяемый объект в количестве: " + ТаблицаСсылок.Количество());
Для Каждого СтрокаТаблицы Из ТаблицаСсылок Цикл
Сообщить("Ссылка найдена в: " + СтрокаТаблицы.Данные + " (Реквизит: " + СтрокаТаблицы.Метаданные.Имя + ")");
КонецЦикла;
Иначе
Сообщить("Объект полностью чист. Ссылки в базе данных отсутствуют.");
КонецЕсли;
Этот простой алгоритм гарантирует, что вы не упустите ни одной скрытой ссылки в документах, регистрах сведений или регистрах накопления перед тем, как принимать окончательное решение по обновлению конфигурации.
Столкнувшись с рассинхронизацией объектов поставщика при обновлении конфигурации 1С, никогда не прибегайте к деструктивным методам удаления и пересоздания объектов «на живой базе». Всегда используйте штатный механизм платформы «Установить соответствие объектов» в окне сравнения и объединения конфигураций. Это сбережет целостность вашей базы данных, сохранит историю транзакций и избавит вас от бессонных ночей, потраченных на восстановление сломанной аналитики.