Как выбрать в запросе 1С записи с «Объект не найден»

Ошибка «Объект не найден» (или отображение ссылки вида «<Объект не найден> (84:8f9a...)») появляется, когда в поле записи хранится ссылка на объект, которого уже нет в базе. Такая ссылка называется «битой»: само значение GUID в поле осталось, но соответствующей строки в таблице объекта не существует. Чаще всего причина — удаление объекта без контроля ссылочной целостности, обмен данными, где объект пришёл раньше своего владельца, или незавершённая загрузка.

Проблема в том, что в запросе 1С битая ссылка ведёт себя неочевидно: она не равна NULL, не равна пустой ссылке, и простое сравнение её не отфильтрует. Если такое поле попадает в отчёт или обработку, пользователь видит непонятный текст «Объект не найден», а код, обращающийся к реквизитам через точку, может вызвать исключение. Поэтому задача «выбрать в запросе объект не найден» обычно означает одно из двух: либо найти все записи с битыми ссылками, чтобы их починить, либо исключить их из выборки, чтобы они не ломали результат.

Ниже разобраны рабочие приёмы на языке запросов 1С: как обнаружить битые ссылки через левое соединение и проверку ЕСТЬ NULL, как массово найти их по всей базе, как безопасно заменить или очистить, и какие ошибки при этом допускают чаще всего.

Что такое битая ссылка и почему она не равна NULL

Битая ссылка — это значение типа «ссылка», которое указывает на несуществующий объект. Внутри хранится GUID и тип объекта, поэтому платформа знает, куда ссылка должна вести, но самой записи в таблице уже нет. При выводе в интерфейсе это выглядит как «<Объект не найден> (84:8f9a0027d5e2...)», где первая часть — внутренний идентификатор типа, вторая — GUID.

Ключевая особенность: битая ссылка не является NULL и не является пустой ссылкой. Условие ГДЕ Поле = &ПустаяСсылка её не найдёт, условие ГДЕ Поле ЕСТЬ NULL — тоже. Более того, битые ссылки с разными GUID не равны друг другу, поэтому сравнение «на равенство с чем-либо» бессмысленно. Единственный надёжный способ определить «объект не найден» в запросе — проверить, существует ли запись в таблице объекта, через соединение.

Выборка записей с «Объект не найден» через левое соединение

Основной приём: соединить таблицу, где хранится ссылка, с таблицей самого объекта по полю «Ссылка» и отобрать строки, где соединение вернуло NULL. Если записи с таким GUID в таблице объекта нет, правая часть соединения даст NULL — это и есть признак битой ссылки.

ВЫБРАТЬ
Реализация.Ссылка КАК Документ,
Реализация.Контрагент КАК БитаяСсылка
ИЗ
Документ.РеализацияТоваровУслуг КАК Реализация
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК Контрагенты
ПО Реализация.Контрагент = Контрагенты.Ссылка
ГДЕ
Контрагенты.Ссылка ЕСТЬ NULL

Этот запрос вернёт все документы, у которых контрагент удалён из справочника. Важно проверять именно поле «Ссылка» правой таблицы, а не произвольный реквизит: реквизит может быть NULL и у существующего объекта, а «Ссылка» — никогда. Если нужно не найти, а наоборот исключить битые ссылки из отчёта, условие инвертируется: ГДЕ НЕ Контрагенты.Ссылка ЕСТЬ NULL.

Для полей составного типа (например, «Основание» документа, которое может ссылаться на несколько видов документов) соединение нужно делать с каждой возможной таблицей и проверять, что все соединения дали NULL. Иначе запись будет ошибочно признана битой, если объект существует, но в другой таблице.

ВЫБРАТЬ Т.Ссылка ИЗ Документ.РеализацияТоваровУслуг КАК Т ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Контрагенты КАК К ПО Т.Контрагент = К.Ссылка ГДЕ К.Ссылка ЕСТЬ NULL

Отличие битой ссылки от пустой и от NULL

В практике регулярно путают три состояния ссылочного поля: NULL (нет значения, например из соединения), пустая ссылка (значение задано, но объект не выбран) и битая ссылка (объект был, но удалён). Каждое требует своего условия в запросе, и смешение этих условий — главный источник неверных выборок.

Обратите внимание: проверка Поле = &ПустаяСсылка не ловит битые ссылки, а проверка на NULL не ловит ни пустые, ни битые. Если задача — «выбрать все проблемные записи», условия нужно объединять через ИЛИ, а битые ссылки добавлять отдельным соединением.

Как исключить «Объект не найден» из отчётов и выборок

Когда битые ссылки мешают отчёту или обработке, их проще отфильтровать, чем чинить немедленно. Для этого в запрос добавляется то же левое соединение, но с обратным условием: остаются только записи, где объект существует, либо поле изначально пустое (если пустое значение допустимо по логике).

ВЫБРАТЬ
Продажи.Номенклатура,
СУММА(Продажи.Сумма) КАК Сумма
ИЗ
РегистрНакопления.Продажи КАК Продажи
ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Номенклатура КАК Товары
ПО Продажи.Номенклатура = Товары.Ссылка
ГДЕ
НЕ Товары.Ссылка ЕСТЬ NULL
СГРУППИРОВАТЬ ПО
Продажи.Номенклатура

Альтернативный вариант без соединения — виртуальный метод через ВЫРАЗИТЬ и обращение к реквизиту: если объект не существует, его реквизиты возвращают NULL. Например, условие ГДЕ Продажи.Номенклатура.Код ЕСТЬ NULL И Продажи.Номенклатура <> &ПустаяСсылка тоже выявит битые ссылки. Однако этот способ хуже читается и может работать медленнее на больших таблицах, поэтому соединение предпочтительнее.

Массовый поиск битых ссылок по всей базе

Если нужно найти «Объект не найден» не в одном документе, а по всей конфигурации, запросы строятся динамически через метаданные. Алгоритм: перебрать все объекты метаданных (справочники, документы, регистры сведений и накопления), для каждого реквизита ссылочного типа построить запрос с соединением и собрать результаты в таблицу.

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

1. 1
   Сделайте резервную копию базы перед любыми исправлениями.
2. 2
   Определите список таблиц и реквизитов ссылочного типа через метаданные или штатную обработку.
3. 3
   Для каждого реквизита выполните запрос с левым соединением и условием ЕСТЬ NULL.
4. 4
   Соберите найденные записи в сводную таблицу: где хранится ссылка, какой GUID отсутствует.
5. 5
   Примите решение по каждой группе: восстановить объект, заменить ссылку или очистить поле.
6. 6
   Повторите проверку после исправлений и убедитесь, что выборка пуста.

Способы исправления найденных записей

Найти битые ссылки — половина задачи. Дальше нужно решить, что с ними делать, и универсального ответа нет: правильное действие зависит от того, почему объект пропал и нужны ли данные для учёта.

Если объект удалён по ошибке, его можно восстановить: создать новый объект и присвоить ему прежний GUID через метод УстановитьСсылкуНового(), передав туда ссылку, полученную из битого значения. Тогда все существующие ссылки снова станут рабочими без изменения документов. GUID битой ссылки извлекается из её строкового представления или через структуру значения.

Если объект не нужен, ссылку заменяют на существующий объект (например, на элемент «Не указан») или очищают поле, записав пустую ссылку. В документах прошлых периодов это делают осторожно: изменение проведённого документа меняет движения и может исказить отчётность за закрытый период. В таких случаях безопаснее ограничиться исключением битых ссылок из отчётов, а не правкой старых документов.

Типичные ошибки при работе с «Объект не найден»

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

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

Как проверить результат после исправлений

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

Дополнительно полезно открыть несколько исправленных документов в интерфейсе и убедиться, что вместо «Объект не найден» отображается реальный объект, а отчёты, которые раньше показывали битые ссылки, формируются корректно. Для баз с обменами имеет смысл дождаться очередного сеанса обмена и повторить проверку — так исключается ситуация, когда «битость» была временной.

Частые вопросы