При выполнении масштабных проектов по миграции данных, например, при переходе с 1С:УПП на 1С:ERP, технические специалисты часто сталкиваются с необъяснимым на первый взгляд поведением платформы. Одной из таких проблем является различное отображение битых ссылок в документах на разных версиях платформы (8.3.15, 8.3.16 и 8.3.17). Рассмотрим детально, почему одна и та же база данных может выглядеть «здоровой» на одной версии и «битой» на другой, и как механизмы платформы влияют на визуализацию ошибок в режиме 1С:Предприятие.
Проанализируем сценарий: имеется файловая база ERP, в которую загружаются данные (остатки и НСИ) через стандартные правила обмена в формате XML. При использовании платформы версии 8.3.15.1656 битые ссылки в документах Ввод начальных остатков не видны до проведения глубокого тестирования. В то же время на версиях 8.3.16.1204, 8.3.16.1224 и 8.3.17.1091 те же самые документы сразу открываются с пометками <Объект не найден>.
Выясним причину такого поведения. Это не означает, что тестирование в 15-й версии «ломает» данные. Напротив, оно лишь выявляет то, что новые платформы умеют определять «на лету» благодаря оптимизированным и более строгим алгоритмам проверки ссылочной целостности.
Начиная с версии 8.3.16, фирма «1С» существенно переработала внутренние механизмы работы с базой данных и кэшированием. Рассмотрим основные отличия:
Расчетный документ имеет сложный составной тип. При загрузке через XML может возникнуть ситуация, когда тип ссылки определен, но сам уникальный идентификатор (GUID) является «пустым» или некорректным. Новые платформы быстрее распознают такие «фантомные» ссылки и отображают их как битые..1CD) данные и индексы хранятся в страницах. Если при записи больших объемов данных (например, справочника Номенклатура) произошел микро-сбой, индекс может указывать на страницу, которой нет. Платформа 8.3.15 часто «доверяет» индексу до последнего, пока не будет запущена реструктуризация.Рассмотрим, что происходит во время запуска ТИИ с включенной опцией «Проверка физической целостности». Этот процесс полностью перестраивает индексы таблиц. Если в основной таблице (например, таблице документов) запись отсутствует, а в таблице движений или в реквизитах другого документа на неё есть ссылка, ТИИ удаляет запись в индексе, которая вела в никуда. После этого ссылка окончательно переходит в статус <Объект не найден> во всех версиях платформы.
Важно понимать: если после ТИИ появились битые ссылки, это означает, что они уже были в базе в неявном виде. Платформа 8.3.15 просто позволяла системе работать с ними, не выбрасывая предупреждений в интерфейс, что потенциально опаснее, так как ведет к накоплению логических ошибок.
В контексте переноса данных из УПП в ERP особое внимание уделим аналитике авансов и расчетным документам. Проанализируем типичную ошибку: При выгрузке из УПП правила могут пытаться подтянуть документ расчетов, который не вошел в выборку выгрузки (например, из-за фильтров по дате или организации). В результате в XML-файл попадает ссылка на объект, которого нет в приемнике. Платформы 8.3.16 и 8.3.17 при десериализации такого XML сразу проверяют наличие объекта в базе ERP. Если объекта нет, создается «битая ссылка» (Object Not Found). 8.3.15 могла обрабатывать этот процесс менее строго, создавая запись в таблице, но не помечая её как проблемную до момента физического обращения к полям объекта.
Если мы хотим убедиться в чистоте данных, не прибегая к долгому процессу ТИИ, воспользуемся следующими методами:
Для Каждого СтрокаТЧ Из ДокументОбъект.Расчеты Цикл
ЗначениеРеквизита = СтрокаТЧ.РасчетныйДокумент;
Если ЗначениеЗаполнено(ЗначениеРеквизита) И ЗначениеРеквизита.ПолучитьОбъект() = Неопределено Тогда
Сообщить("Найдена битая ссылка в документе: " + ДокументОбъект.Ссылка);
КонецЕсли;
КонецЦикла;
Метод ПолучитьОбъект() вернет Неопределено, если ссылка битая, что является надежным способом диагностики вне зависимости от версии платформы.
.1CD. Это исключит проблемы со структурой страниц базы данных, которые могут искажать результаты загрузки на разных платформах.Как показывает практика и разбор данной темы, часто «странности» платформы оказываются следствием ошибок в исходных данных или в логике их подготовки. В рассматриваемом случае выяснилось, что проблема крылась в данных, подготовленных экономистами и бухгалтерами в исходной базе УПП. Если в источнике аналитика заполнена некорректно или содержит ссылки на удаленные объекты, то любая версия платформы при переносе создаст битые ссылки.
Рекомендация: При обнаружении битых ссылок в ERP после переноса из УПП, первым делом проверьте заполнение этих же полей в базе-источнике. Скорее всего, там вы обнаружите аналогичную картину, либо отсутствие данных, которые правила обмена пытаются сопоставить.
Подводя итог нашему анализу, зафиксируем основные выводы:
Для стабильной работы рекомендуется использовать актуальные версии платформы из одной ветки (например, последние релизы 8.3.18 или 8.3.22), чтобы избежать «зверинца» версий и непредсказуемого поведения механизмов кэширования.