Переход со старых редакций конфигураций, таких как 1С:Бухгалтерия предприятия 1.6, на современные версии (БП 3.0) — это сложный многоэтапный процесс. Часто он осуществляется через промежуточную выгрузку в редакцию 2.0. В процессе такой миграции программисты нередко сталкиваются с ошибками конвертации, которые блокируют выгрузку данных. Одной из самых распространенных проблем является исключение в обработчиках событий, связанное с отсутствием ссылочных данных.
В этой статье мы подробно разберем ситуацию, когда при выгрузке остатков по отгруженным товарам или входящим счетам-фактурам возникает ошибка Объект не найден, проанализируем причины ее появления и разработаем пошаговый план решения.
Рассмотрим структуру ошибки, которую выдает стандартная обработка УниверсальныйОбменДаннымиXML. Типичный текст сообщения выглядит следующим образом:
ПКО = ДокументРасчетовСКонтрагентомДляВНО
ПКС = 4 ( --> ДоговорКонтрагента)
Объект = <Объект не найден> (178:94099c8e9954d66211e6abca4d30adc3) (Поступление доп. расходов)
Проанализируем эти данные. Ошибка возникает в правиле выгрузки данных (ПВД) Остатки_ТоварыОтгруженные. Это означает, что система пытается собрать остатки по счету 45 или аналогичным регистрам, где фигурирует документ расчетов. В процессе выгрузки ПКО (Правило Конвертации Объекта) пытается обратиться к свойству ДоговорКонтрагента у объекта Поступление доп. расходов. Однако самого этого документа в базе уже не существует, хотя ссылка на него сохранилась в движениях регистров или в реквизитах других документов.
Выделим основные причины возникновения такой ситуации:
Первым делом нам необходимо попытаться исправить базу штатными средствами платформы 1С. Для этого воспользуемся процедурой Тестирование и исправление информационной базы. Однако простого запуска недостаточно — важно правильно выставить настройки.
Разберем алгоритм действий:
Если ТиИ не помогло, нам придется вручную найти записи в регистрах, которые ссылаются на несуществующий GUID. Рассмотрим, как это сделать. Мы знаем идентификатор из ошибки: 178:94099c8e9954d66211e6abca4d30adc3.
Воспользуемся консолью запросов. Нам нужно проверить регистры, отвечающие за товары отгруженные и расчеты. Проанализируем пример запроса для поиска записей с незаполненными (битыми) ссылками в регистре накопления:
ВЫБРАТЬ
Рег.Период,
Рег.Регистратор,
Рег.ДокументРасчетов
ИЗ
РегистрНакопления.ТоварыОтгруженные КАК Рег
ГДЕ
Рег.ДокументРасчетов.Ссылка ЕСТЬ NULL
И НЕ Рег.ДокументРасчетов = ЗНАЧЕНИЕ(Документ.ПоступлениеДопРасходов.ПустаяСсылка)
Такой запрос покажет строки, где ссылка формально заполнена (не пустая), но указывает на несуществующий объект. После обнаружения таких записей их необходимо либо скорректировать вручную (выбрать правильный документ), либо очистить через обработку «Выгрузка и загрузка данных XML» или специализированные инструменты по замене дублей и битых ссылок.
При попытке отладить правила конвертации в старых базах (БП 1.6 на платформе 8.1 или в режиме совместимости) часто возникает ошибка Поле объекта не обнаружено (НАСТРОЙКАИБ). Это происходит из-за несовместимости кода, генерируемого современными версиями Конвертации данных 2.1, и кода обработки выгрузки.
Чтобы успешно запустить отладку, выполним следующие рекомендации:
УниверсальныйОбменДаннымиXML.epf, которая поставлялась именно с тем релизом «Конвертации данных», в котором создавались правила.Если данные в базе исправить невозможно или их слишком много, мы можем внести изменения в сами правила обмена (ПКО). Наша задача — заставить систему игнорировать объекты, которые не удается прочитать.
Разберем, как добавить проверку в конфигурации «Конвертация данных»:
ДокументРасчетовСКонтрагентомДляВНО.
Если Объект = Неопределено Тогда
Отказ = Истина;
ИначеЕсли Объект.Ссылка.ПолучитьОбъект() = Неопределено Тогда
// Дополнительная проверка на физическое существование объекта
Отказ = Истина;
КонецЕсли;
Эта проверка позволит правилу просто пропустить «битый» объект, не прерывая весь процесс выгрузки. Также стоит проверить свойство ДоговорКонтрагента в этом ПКО. Если для него установлен флаг Обязательное, его стоит снять, так как при пустом договоре (даже если документ существует) выгрузка может аварийно завершиться.
Проанализируем еще несколько важных аспектов, которые помогут успешно завершить переход:
1. Очистка базы перед выгрузкой. Одной из частых причин «битых» ссылок является неполное удаление объектов. Перед началом миграции обязательно выполните операцию Удаление помеченных объектов. Это поможет очистить ссылки из регистров, если они были настроены на автоматическое удаление при стирании объекта.
2. Версионность релизов. Конвертация 1.6 -> 2.0 -> 3.0 сильно зависит от релизов. Убедитесь, что БП 1.6 обновлена до финального релиза (обычно это 1.6.31.1), а правила выгрузки взяты из состава актуального дистрибутива обновления БП 2.0. Правила часто находятся в макетах конфигурации под именем ИзБП16.
3. Перенос только остатков. Если база 1.6 велась долго и содержит много ошибок, перенос всех документов за все годы (истории) — плохая идея. Рассмотрите вариант переноса только остатков на начало текущего отчетного года. Это позволит минимизировать количество конвертируемых объектов и избежать обработки старых битых данных, которые уже не влияют на текущий учет.
4. Использование GUID для поиска. Если ошибка повторяется, вы можете программно найти владельца битой ссылки. Создадим небольшую внешнюю обработку:
ГУИД = Новый УникальныйИдентификатор("94099c8e-9954-d662-11e6-abca4d30adc3");
Ссылка = Документы.ПоступлениеДопРасходов.ПолучитьСсылку(ГУИД);
Если Ссылка.ПолучитьОбъект() = Неопределено Тогда
Сообщить("Объекта действительно нет в таблице документов");
КонецЕсли;
Обратите внимание, что в тексте ошибки GUID часто представлен в формате 178:94099c8e..., где 178 — это внутренний код типа метаданных. При поиске через УникальныйИдентификатор используйте только вторую часть строки.
Таким образом, комбинируя методы исправления данных в исходной базе и корректировку правил в «Конвертации данных», мы можем преодолеть ошибки ссылочной целостности и успешно выполнить переход на новую редакцию программы.