Переход с редакции 2.5 на 3.1 — это сложный процесс, в ходе которого данные трансформируются из одной структуры в другую. Часто после завершения миграции пользователи обнаруживают в документах или регистрах записи вида «Объект не найден» (битые ссылки). Проблема осложняется тем, что стандартное Тестирование и исправление с настройкой «Очищать ссылки» не всегда помогает, так как ссылки могут быть зашиты глубоко в движениях технических документов. В этой статье мы разберем, как выявить причину появления таких ссылок и как их корректно устранить.
Рассмотрим ситуацию: перенос был выполнен несколько месяцев назад, база файловая, и chdbfl не находит ошибок. Почему же битые ссылки продолжают появляться? Проанализируем механику переноса. Данные из ЗУП 2.5 попадают в ЗУП 3.1 через специальные документы ПереносДанных. Если в процессе выгрузки какой-то объект (физическое лицо, сотрудник или должность) был помечен на удаление или имел дубли, правила обмена могли создать ссылку на идентификатор, который в итоге не был перенесен в справочник новой базы.
Важно понимать, что при переносе 1С старается сохранять GUID (уникальный идентификатор) объектов. Это наш главный ключ к решению проблемы. Если мы найдем GUID «битого» объекта в новой базе, мы сможем однозначно определить, что это был за объект в старой базе.
Если мы видим в документе ПереносДанных строку «Объект не найден», нам нужно узнать, на что именно она ссылалась. Посмотрим, как это сделать программно в старой базе ЗУП 2.5. Для этого нам понадобится строковое представление идентификатора (например, 8bc1...). Выясним его в новой базе (через консоль запросов или обработку поиска ссылок) и перейдем в старую базу.
В ЗУП 2.5 запустим консоль запросов или напишем небольшой скрипт в обработке:
// Пример поиска физического лица по известному GUID
ИдентификаторТекст = "5f2e8a10-1234-11ef-80c2-00155d011f05"; // пример GUID из битой ссылки
УникальныйИд = Новый УникальныйИдентификатор(ИдентификаторТекст);
СсылкаНаОбъект = Справочники.ФизическиеЛица.ПолучитьСсылку(УникальныйИд);
Если СсылкаНаОбъект.ПолучитьОбъект() = Неопределено Тогда
Сообщить("Объект в старой базе не найден, возможно, он был удален до переноса");
Иначе
Сообщить("Это объект: " + СсылкаНаОбъект);
КонецЕсли;
Таким образом, мы выясним, кого именно «потеряла» программа. Если это реальный сотрудник, его придется восстановить или перевыбрать вручную.
Проанализируем документы с префиксом ПР (Перенос данных). Именно они являются источником записей в регистрах. Если битая ссылка находится внутри такого документа, стандартное Тестирование и исправление может бессильно «удалять» её, но при попытке перепроведения документа она может появиться снова или заблокировать проведение.
ПереносДанных (через «Администрирование» — «Переносы данных» или «Все функции»).Разберем ситуацию, когда битых ссылок сотни. В этом случае эффективно использовать стандартную обработку «Поиск и замена дублей». В поле «Искать в» выберите нужный справочник (например, Физические лица), а в критериях поиска укажите «Ссылку». Обработка позволит найти все вхождения «Объект не найден» и заменить их на одно корректное «эталонное» лицо, которое вы создадите для этих целей (например, с наименованием «Неизвестное лицо после переноса»).
Часто битые ссылки «прячутся» в регистрах, которые не видны в обычном интерфейсе. Проанализируем список наиболее вероятных мест:
Для исправления очистим записи в этих регистрах через «Все функции» (или «Функции для технического специалиста»). Если мы видим строку, где в поле Физическое лицо значится идентификатор, необходимо либо удалить эту запись (если она дублирующая), либо подставить актуальное значение.
Если битых ссылок слишком много и они касаются целых справочников (например, пропали Должности или Подразделения), рассмотрим метод восстановления через универсальную обработку ВыгрузкаЗагрузкаДанныхXML.
Алгоритм действий следующий:
ВыгрузкаЗагрузкаДанныхXML.GUID и «наполнит» битые ссылки реальными данными.Этот метод особенно хорош тем, что он не создает дублей, если GUID объектов совпадают, а просто восстанавливает отсутствующие записи справочников, на которые ссылаются регистры.
Разберем важный момент, упомянутый опытными специалистами: иногда проблема кроется в настройках ПКО (Правил конвертации объектов). В некоторых версиях правил обмена стоит галочка «Искать объект приемника по внутреннему идентификатору объекта источника». Если вы планируете делать повторный дозалив данных, попробуйте снять эту настройку для справочника ФизическиеЛица. Это заставит систему искать людей по полям поиска (ФИО, СНИЛС, Дата рождения), а не только по жесткому идентификатору, что часто спасает от появления «пустышек».
Подведем итог: Борьба с битыми ссылками после переноса — это всегда сочетание технической очистки (ТиИ, замена дублей) и аналитической работы в документах ПереносДанных. Главное — не спешить удалять «Объект не найден», не выяснив, какие данные за ним стояли в старой базе ЗУП 2.5.