Перенос данных между базами 1С с помощью конфигурации «Конвертация данных 2.0» (КД2) — это стандартная задача, однако режим «Не выгружать объекты свойств источника по ссылкам» часто приводит к появлению «битых» ссылок. Это ситуации, когда в документе ссылка на объект (например, на склад или контрагента) есть, но самого объекта в целевой базе не существует, и платформа отображает текст «<Объект не найден>...».
В этой статье мы подробно разберем, почему стандартное проведение документов не гарантирует отсутствие ошибок, и рассмотрим несколько эффективных способов быстрого поиска некорректных данных, не прибегая к долгому полному тестированию и исправлению (ТИИ).
Разберем ситуацию: многие пользователи полагают, что если документ успешно провелся, то в нем нет битых ссылок. Это опасное заблуждение. Проанализируем, как работает механизм проведения. Программная логика модуля проведения обычно проверяет только те реквизиты, которые критичны для формирования движений по регистрам (например, Номенклатура, Склад, Количество).
Второстепенные реквизиты, такие как Комментарий, Дополнительные сведения или даже Ответственный, могут содержать битые ссылки, но документ при этом проведется без ошибок. Однако в будущем это «выстрелит» при формировании аналитических отчетов или при попытке выгрузить эти данные в другие системы. Поэтому проверка ссылочной целостности обязательна.
Это самый быстрый способ для программиста. Нам не нужно перебирать все объекты программно, достаточно использовать механизм соединения таблиц в SQL-запросе, который платформа выполняет автоматически при обращении «через точку».
Рассмотрим логику: если мы обращаемся к реквизиту ссылочного типа и пытаемся получить его свойство (например, Наименование), то для битой ссылки платформа вернет значение NULL. Напишем запрос, который выявит такие документы:
ВЫБРАТЬ
ТвоиДокументы.Ссылка КАК ДокументСсылка,
ТвоиДокументы.Контрагент КАК БитаяСсылка
ИЗ
Документ.РеализацияТоваровУслуг КАК ТвоиДокументы
ГДЕ
ТвоиДокументы.Контрагент.Наименование ЕСТЬ NULL
И НЕ ТвоиДокументы.Контрагент = ЗНАЧЕНИЕ(Справочник.Контрагенты.ПустаяСсылка)
В этом примере мы проанализируем ситуацию, когда в поле Контрагент есть ссылка, которая не является пустой, но при этом ее Наименование не может быть получено из базы (возвращается NULL). Это явный признак того, что объект в справочнике отсутствует.
Если вы используете расширение или портативный вариант «Инструментов разработчика», процесс значительно упрощается. Рассмотрим алгоритм работы с этим инструментом:
Преимущество этого метода в том, что инструмент умеет сканировать не только основные реквизиты, но и табличные части, а также движения по регистрам. Последнее особенно важно, так как битая ссылка в регистре накопления может привести к тому, что итоги в отчетах будут «расползаться», а найти причину в самом документе будет невозможно.
Если нам нужно выполнить точечную проверку конкретного набора документов в коде, мы можем воспользоваться методом ПолучитьОбъект(). Проанализируем следующий фрагмент кода:
Выборка = Документы.РеализацияТоваровУслуг.Выбрать();
Пока Выборка.Следующий() Цикл
СсылкаНаОбъект = Выборка.Контрагент;
Если СсылкаНаОбъект.ПолучитьОбъект() = Неопределено И Не СсылкаНаОбъект.Пустая() Тогда
Сообщить("Найдена битая ссылка в документе " + Выборка.Ссылка + " | Поле: Контрагент");
КонецЕсли;
КонецЦикла;
Важно помнить, что этот метод работает значительно медленнее, чем запрос, так как при вызове ПолучитьОбъект() система пытается считать все данные объекта из базы данных. Используйте его только для небольших выборок или когда требуется сложная логика обработки ошибки «на лету».
Если база данных невелика или у вас есть время на регламентные операции, можно воспользоваться штатным механизмом. Чтобы ускорить процесс, выясним, какие галочки действительно необходимы:
В таком режиме система просто выведет список всех проблемных мест в окно сообщений, не тратя время на создание пустых объектов-заглушек или пересчет итогов. Это надежный способ, который гарантированно найдет все «хвосты» во всех таблицах базы данных.
Для очень больших баз (сотни гигабайт), где платформенные инструменты работают часами, мы можем применить прямой запрос к СУБД. Посмотрим на логику LEFT JOIN:
Мы берем таблицу документа (например, _Document150) и соединяем ее с таблицей справочника (например, _Reference80) по полю идентификатора (GUID). Если в таблице документа идентификатор заполнен (не является набором нулей), а в связанной таблице справочника запись отсутствует (поле ID справочника равно NULL), мы нашли битую ссылку.
Внимание: работу с SQL-запросами напрямую следует доверять только опытным администраторам БД, так как это требует понимания структуры таблиц конкретной конфигурации 1С.
Для оперативного поиска битых ссылок после работы КД2 оптимально использовать Консоль запросов с проверкой на NULL по представлению или специализированные Инструменты разработчика. Если же требуется полная уверенность перед сдачей проекта, стоит запустить выборочное ТИИ в режиме «только отчет». Это позволит вам быть уверенными в чистоте перенесенных данных и избежать проблем с отчетностью в будущем.