При настройке и эксплуатации регулярного обмена данными между конфигурациями 1С:Управление торговлей (редакция 11) и 1С:Бухгалтерия предприятия (редакция 3.0) пользователи часто сталкиваются с неприятной ситуацией: нормативно-справочная информация (справочники) переносится без каких-либо нареканий, но при попытке выгрузить документы процесс завершается аварийно. При этом система выдает крайне неинформативную техническую ошибку:
{Обработка.ПомощникИнтерактивногоОбменаДанными.Форма.Форма.Форма(2365)}: ВызватьИсключение РезультатАнализа.СообщениеОбОшибке;
В этой статье мы подробно разберем, почему возникает эта ошибка, как заглянуть «под капот» механизма синхронизации БСП (Библиотеки стандартных подсистем), выяснить истинную причину сбоя и успешно восстановить обмен документами между базами.
Прежде всего проанализируем, почему платформа выдает столь абстрактное сообщение вместо конкретного описания проблемы. Дело в том, что современный интерактивный обмен данными в 1С выполняется асинхронно — через фоновые задания на сервере. Это сделано для того, чтобы разгрузить интерфейс пользователя при обработке больших пакетов XML.
Когда вы запускаете сопоставление или загрузку данных, интерактивный помощник передает задачу фоновому заданию. Если это задание завершается аварийно (например, из-за нехватки памяти, критической ошибки СУБД или сбоя XDTO-пакета), оно возвращает структуру, содержащую описание сбоя в переменной РезультатАнализа.СообщениеОбОшибке. Если фоновый процесс «упал» мгновенно или жестко прервался операционной системой, эта переменная остается пустой. Программа все равно выполняет метод ВызватьИсключение, и мы видим лишь сухую системную строку кода без объяснения причин.
Рассмотрим, как выглядит этот уязвимый участок кода в конфигураторе:
// Фрагмент общего модуля или обработки обмена БСП
Если РезультатАнализа.Свойство("СообщениеОбОшибке") И ЗначениеЗаполнено(РезультатАнализа.СообщениеОбОшибке) Тогда
ЗаписатьВЖурналРегистрации("СинхронизацияДанных", УровеньЖурналаРегистрации.Ошибка,,, РезультатАнализа.СообщениеОбОшибке);
ВызватьИсключение РезультатАсключения.СообщениеОбОшибке;
ИначеЕсли РезультатАнализа.ЗаданиеВыполненоСОшибкой Тогда
ВызватьИсключение "Фоновое задание обмена данными завершилось аварийно без возврата описания ошибки.";
КонецЕсли;
Для того чтобы локализовать проблему, нам необходимо добыть детальное описание ошибки. Обычного просмотра текущих записей в Журнале регистрации (ЖР) интерфейса зачастую недостаточно. Применим два профессиональных метода диагностики.
Способ А. Правильная фильтрация Журнала регистрации
Когда пользователи заявляют, что «в Журнале регистрации только та же самая ошибка», они обычно смотрят события, отфильтрованные по своему текущему пользователю. Но фоновые задания выполняются под системным пользователем (или вообще без привязки к конкретному сеансу в файловом варианте). Чтобы увидеть реальную картину, выполним следующие действия:
Способ Б. Отладка фонового задания в Конфигураторе
Если Журнал регистрации молчит, программисту необходимо запустить сеанс отладки. Разберем этот процесс по шагам:
ПомощникИнтерактивногоОбменаДанными, откроем основную форму и перейдем к строке с вызовом исключения (в районе строки 2365).ВызватьИсключение РезультатАнализа.СообщениеОбОшибке;.РезультатАнализа в Табло отладчика и детально изучим всю структуру — в ней будут находиться подробные свойства исключения СУБД или платформы.Практика показывает, что если справочники переносятся успешно, а документы вызывают падение системы, проблема кроется в логических ограничениях, объеме данных или повреждении конкретных объектов. Проанализируем эти сценарии подробнее.
Интерактивный обмен пытается прочитать и сопоставить весь пакет документов за один сеанс. Если документов зарегистрировано слишком много (например, за несколько месяцев или лет), и обмен выполняется на 32-битной версии сервера «1С:Предприятие» или в файловом режиме, процесс падает из-за нехватки оперативной памяти. Справочники весят мало и проходят проверку, а тяжелые транзакционные документы вызывают критический сбой фонового процесса.
Решение: Временно откажемся от интерактивного обмена в пользу автоматического обмена по расписанию (в фоновом режиме порциями) либо существенно сократим объем передаваемых данных (см. Шаг 3).
Очень часто в базу попадает документ с некорректной структурой данных (например, битая ссылка в табличной части, пустой склад, неверно указанная ставка НДС, незаполненный договор). При попытке сериализации такого объекта в формат XML/XDTO валидатор обмена выдает критическую ошибку и прерывает транзакцию.
Решение: Нам необходимо локализовать и временно исключить сбойный документ из выгрузки, чтобы остальной пакет прошел успешно.
В конфигурации 1С:Бухгалтерия 3.0 встроены жесткие механизмы проверки заполнения реквизитов, необходимых для регламентированного учета (счета учета номенклатуры, счета расчетов с контрагентами, договоры). Если в 1С:УТ 11 эти реквизиты заполняются по упрощенной схеме или отсутствуют, то при попытке записи документа в БП срабатывает отказ, блокирующий весь пакет обмена.
Даже если конфигурации обновлены до последних релизов, в самой настройке обмена может остаться жестко зафиксированная старая версия формата (например, EnterpriseData 1.5 вместо актуальной EnterpriseData 1.15). В новых релизах изменился состав реквизитов документов, и при попытке прочитать их по старым правилам БСП аварийно завершает работу.
Выполним последовательно шаги для быстрого исправления ситуации без необходимости глубокого программирования:
Перейдем в раздел настроек синхронизации в УТ 11. Нажмем кнопку «Состав отправляемых данных» (значок с синей шестеренкой или детализацией отправки). Проверим, какое количество документов зарегистрировано к отправке. Если там висят десятки тысяч объектов, очистим регистрацию для документов. Для этого выделим корневой узел документов, нажмем правой кнопкой мыши и выберем «Отменить регистрацию».
Зарегистрируем к обмену вручную всего 1 или 2 заведомо корректных документа за сегодняшний день. Запустим синхронизацию. Если эти документы успешно перенеслись в БП 3.0, значит, проблема гарантированно заключалась либо в объеме данных (нехватке памяти), либо в наличии конкретного сбойного («битого») документа в прежней очереди отправки.
Убедимся, что в настройках синхронизации в УТ 11 дата начала выгрузки документов не установлена слишком ранним числом (например, началом года, за который уже закрыт период). Также проверим в 1С:БП 3.0 в разделе Администрирование -> Настройки пользователей и прав -> Даты запрета изменения данных, не установлена ли дата запрета загрузки для пользователей обмена. Если дата запрета стоит позже, чем даты выгружаемых документов, БП заблокирует запись документов, вызвав сбой обмена.
Если сбой происходит систематически из-за устаревшего формата обмена, откроем настройки синхронизации данных, перейдем в параметры подключения и запустим мастер обновления правил обмена. В ряде случаев самым быстрым решением является полное удаление старой настройки синхронизации в обеих базах (с предварительной очисткой зарегистрированных изменений) и создание нового подключения с нуля через современный веб-сервис или общий каталог.
Используя предложенный комплексный подход — от детального анализа структуры фонового задания до точечной фильтрации очереди регистрации документов, — мы сможем оперативно устранить ошибку синхронизации и гарантировать корректное ведение регламентированного и управленческого учета в компании.