Почему не работает обработчик «После загрузки данных» в Конвертации данных 2.1 и как это исправить?

При настройке обмена данными между конфигурациями, особенно когда одна из них работает на обычных формах (например, УТ 10.3), а другая — на управляемых (например, БП 3.0), разработчики часто сталкиваются с ситуацией, когда программный код в обработчиках «1С:Конвертация данных 2.1» (КД) ведет себя непредсказуемо. Одной из самых частых проблем является «молчаливое» невыполнение кода в глобальном обработчике После загрузки данных.

В этой статье мы подробно разберем, почему это происходит, как правильно диагностировать проблему и какие архитектурные решения в КД 2.1 будут наиболее надежными.

Причина №1: Особенности выполнения серверного кода в управляемом приложении

Проанализируем ситуацию: разработчик пишет в обработчике стандартную команду Сообщить("Ура, загрузили"); и не видит результата. Первое, что нужно понять — где именно выполняется этот код. В современных конфигурациях на базе Библиотеки стандартных подсистем (БСП), таких как Бухгалтерия предприятия 3.0, загрузка данных происходит на стороне сервера в контексте фонового задания.

Функция Сообщить() в серверном контексте при фоновом обмене данными просто записывает сообщение в массив сообщений сеанса, который часто не возвращается пользователю в визуальное окно. Выясним причину глубже: если загрузка идет через прямое подключение (COM) или через веб-сервис, интерактивного окна для вывода сообщений просто не существует.

Рекомендация по отладке: Вместо использования Сообщить() всегда используйте запись в журнал регистрации. Это гарантированный способ проверить, заходил ли интерпретатор в ваш обработчик. Рассмотрим пример кода для проверки:

ЗаписьЖурналаРегистрации("ОбменДанными.ПроверкаОбработчика",
    УровеньЖурналаРегистрации.Информация,
    ,
    ,
    "Обработчик 'После загрузки данных' успешно запущен.");

Причина №2: Место хранения и обновления правил в приемнике

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

Если вы обновили правила в конфигурации-источнике (УТ 10.3), это не всегда означает, что приемник (БП 3.0) автоматически начнет их использовать, особенно если обработчик должен выполняться на стороне приемника. В некоторых режимах совместимости и при определенных настройках обмена, код обработчика После загрузки (на уровне ПКО) или глобальный обработчик берется из так называемых корреспондентских правил.

Посмотрим, что нужно сделать для исправления:

1. Зайдите в базу-приемник (БП 3.0).
2. Перейдите в раздел Администрирование — Синхронизация данных.
3. Откройте Параметры синхронизации данных для вашего узла.
4. Найдите пункт загрузки правил и убедитесь, что вы загрузили актуальный файл правил (xml) именно туда.
5. Крайне важно нажать кнопку «Записать и закрыть», чтобы кэш правил обновился.

Причина №3: Глобальный обработчик против обработчика ПКО

Рассмотрим ситуацию, когда в глобальном обработчике После загрузки данных планировалось заполнение счетов учета. Глобальный обработчик выполняется в самом конце, когда все объекты уже загружены и транзакции зафиксированы. Если в процессе загрузки возникла ошибка в одном из объектов, выполнение всей цепочки может прерваться.

Проанализируем, почему перенос логики в обработчик «После загрузки» конкретного ПКО (Правила Конвертации Объектов) является более правильным решением:

• Контекст объекта: В ПКО вам сразу доступна переменная Ссылка, которая указывает на только что созданный или обновленный объект.
• Надежность: Код выполняется сразу после записи объекта. Если вам нужно заполнить специфические регистры (например, счета учета или дополнительные реквизиты), лучше делать это «по горячим следам».
• Производительность: Вам не нужно заново искать загруженные объекты в базе, как пришлось бы делать в глобальном обработчике.

Рассмотрим пример кода, который лучше разместить в ПКО документа в обработчике После загрузки:

// Заполнение счетов учета для документа
Если ТипЗнч(Ссылка) = Тип("ДокументСсылка.ПоступлениеТоваровУслуг") Тогда
    ОбъектОбъект = Ссылка.ПолучитьОбъект();
    // Вызываем типовой механизм заполнения счетов
    ЗаполнениеДокументов.ЗаполнитьСчетаУчетаВТабличнойЧасти(ОбъектОбъект, "Товары");
    ОбъектОбъект.Записать(РежимЗаписиДокумента.Запись);
КонецЕсли;

Как гарантированно проверить работу обработчика?

Если вы все же решили использовать глобальный обработчик После загрузки данных, выполните следующие шаги для диагностики:

1. Проверка режима отладки: Убедитесь, что загрузка не падает с критической ошибкой до того, как дойдет до конца файла. Если загрузка прерывается, глобальный обработчик не вызовется.
2. Использование параметров: В КД 2.1 есть коллекция Параметры. Вы можете передавать флаги из обработчиков ПКО в глобальный обработчик. Например, в ПКО установите Параметры.Вставить("ДанныеЗагружены", Истина);, а в глобальном обработчике проверьте наличие этого ключа.
3. Журнал регистрации: Как упоминалось выше, пишите информацию о каждом этапе в журнал. Если записи нет — правила в базе-приемнике не обновились или файл правил не содержит вашего кода (проверьте XML-файл правил текстовым редактором на наличие вашего текста).

Выясним еще один момент: режим совместимости. Хотя автор темы упоминал, что смена режима не помогла, для корректной работы БСП 3.0 и выше рекомендуется использовать актуальные версии платформы и не блокировать работу фоновых заданий отладкой без необходимости.

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