В процессе эксплуатации конфигурации «Зарплата и управление персоналом 3.1» пользователи и администраторы часто сталкиваются с неприятной ситуацией: в документах или отчетах вместо фамилии сотрудника или физического лица отображается непонятная строка вида <Объект не найден> (403:81100cc47a203e3f11e9cd4e645d822a). Это так называемая «битая ссылка». Она возникает, когда в базе данных существует запись, ссылающаяся на объект, который физически был удален из таблицы справочника.
В данной статье мы подробно разберем, как найти все упоминания такого объекта и какими способами можно исправить ситуацию, сохранив целостность данных в вашей системе.
Прежде чем приступать к поиску, давайте проанализируем, что именно нам известно. Строка 403:81100cc47a203e3f11e9cd4e645d822a несет в себе важную техническую информацию. Рассмотрим её структуру подробнее:
Для того чтобы использовать этот GUID в программном коде 1С, нам необходимо привести его к стандартному виду (8-4-4-4-12 символов). Для нашего примера 81100cc47a203e3f11e9cd4e645d822a превратится в 81100cc4-7a20-3e3f-11e9-cd4e645d822a. Это преобразование критически важно для корректной работы методов поиска.
Самый быстрый и точный способ найти все места, где «засветилась» битая ссылка — использовать встроенный метод глобального контекста НайтиПоСсылкам. Рассмотрим, как это реализовать с помощью небольшой внешней обработки или в консоли кода.
Проанализируем алгоритм: сначала мы восстановим объект ссылки по имеющемуся текстовому идентификатору, а затем попросим систему найти все зависимости. Пример кода будет выглядеть следующим образом:
// Определяем текстовый GUID (уже в стандартном формате)
ТекстGUID = "81100cc4-7a20-3e3f-11e9-cd4e645d822a";
НужныйGUID = Новый УникальныйИдентификатор(ТекстGUID);
// Получаем ссылку на объект (даже если его нет в базе, ссылка будет создана в памяти)
СсылкаНаФизЛицо = Справочники.ФизическиеЛица.ПолучитьСсылку(НужныйGUID);
// Помещаем ссылку в массив, так как метод НайтиПоСсылкам работает с массивами
МассивСсылок = Новый Массив;
МассивСсылок.Добавить(СсылкаНаФизЛицо);
// Выполняем поиск
ТаблицаСсылок = НайтиПоСсылкам(МассивСсылок);
// Обходим результат и выводим информацию
Для Каждого Строка Из ТаблицаСсылок Цикл
Сообщить("Найдена ссылка в объекте: " + Строка.Данные + " (Метаданные: " + Строка.Метаданные.Имя + ")");
КонецЦикла;
Этот метод хорош тем, что он просматривает не только реквизиты документов, но и записи в регистрах сведений, накопления и расчета, что крайне важно для конфигурации ЗУП 3.1.
Иногда нам нужно не просто найти ссылки, но и понять, что это был за объект, или временно «заткнуть дыру» в учете, чтобы отчеты перестали выдавать ошибку. В этом случае мы можем программно создать элемент справочника с тем же самым GUID, который указан в битой ссылке.
Выполним следующие шаги:
ФизическиеЛица.Посмотрим на пример реализации:
ГуидТекст = "81100cc4-7a20-3e3f-11e9-cd4e645d822a";
НовыйЭлемент = Справочники.ФизическиеЛица.СоздатьЭлемент();
// Устанавливаем ссылку ДО записи объекта
НужнаяСсылка = Справочники.ФизическиеЛица.ПолучитьСсылку(Новый УникальныйИдентификатор(ГуидТекст));
НовыйЭлемент.УстановитьСсылкуНового(НужнаяСсылка);
НовыйЭлемент.Наименование = "Восстановленное физлицо (битая ссылка)";
НовыйЭлемент.Записать();
Сообщить("Объект успешно создан. Теперь во всех документах вместо <Объект не найден> будет отображаться указанное наименование.");
После выполнения этого кода битая ссылка превратится в обычный элемент справочника. Теперь вы сможете использовать стандартную обработку «Поиск и удаление дублей», чтобы заменить это временное лицо на корректное (существующее) во всех местах использования.
Если вы не хотите писать код, можно воспользоваться стандартным инструментом конфигуратора. Однако здесь нужно быть предельно осторожными. Выясним причину появления битых ссылок: часто это результат некорректного обмена данными или удаления объектов без контроля ссылочной целостности.
Перейдем в Администрирование — Тестирование и исправление. Нас интересует пункт «Проверка ссылочной целостности». Рассмотрим два варианта настройки:
Если вам нужно проанализировать ситуацию без внесения изменений, воспользуемся консолью запросов. Простой поиск ГДЕ ФизЛицо = &Ссылка может не сработать, если ссылка действительно «битая». В таких случаях мы рекомендуем проверять наличие ссылки, которая не соединяется с основной таблицей справочника.
Разберем пример запроса, который ищет битые ссылки в регистре сведений ДанныеФизическихЛиц:
ВЫБРАТЬ
Регистр.ФизическоеЛицо КАК БитаяСсылка,
Регистр.Регистратор КАК ДокументОснование
ИЗ
РегистрСведений.ДанныеФизическихЛиц КАК Регистр
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ФизическиеЛица КАК Справочник
ПО Регистр.ФизическоеЛицо = Справочник.Ссылка
ГДЕ
Справочник.Ссылка ЕСТЬ NULL
И Регистр.ФизическоеЛицо <> ЗНАЧЕНИЕ(Справочник.ФизическиеЛица.ПустаяСсылка)
Этот запрос покажет все записи регистра, где ссылка на физлицо заполнена, но самого физлица в таблице справочника не существует. Подобный подход можно применить к любому документу или регистру в ЗУП 3.1.
Проанализируем специфику конфигурации. В «Зарплате и управлении персоналом» битые ссылки чаще всего возникают в двух сценариях:
Соответствия объектов информационных баз.Выяснив причину и найдя все вхождения, мы рекомендуем следующий план действий:
Таким образом, мы рассмотрели комплексный подход к решению проблемы «Объект не найден». Помните, что в сложных учетных системах, таких как ЗУП 3.1, простое удаление ссылки — это крайняя мера. Лучшим решением всегда будет восстановление объекта или его корректная замена на существующий аналог.