Во-первых, если такая ошибка возникает на главном узле после передачи на подчиненный сообщения с обновлением, до устранения этой проблемы не желательно править конфигурацию главного узла, т.к. можем запросто получить на подчинённом проблему «конфигурация не соответствует ожидаемой»!
Лучше глубже проанализировать суть ошибки, тем более, что в тексте этой ошибки указывается номер строки и колонки того места, где произошла ошибка.
Тем не менее, перед тем, как приступать к глубокому анализу файла сообщения, проверьте не открывается ли этот ларчик гораздо проще: на узле-отправителе проблемного сообщения откройте обработку ВыгрузкаЗагрузкаДанныхXML.epf (из состава конфигурации «Конвертация данных», находится в каталоге шаблона конфигурации после её установки), нажмите в самом низу кнопку «Недопустимые символы в плане обмена» и выберите узел-получатель. Если проверка выдаст ошибки, то вам достаточно будет устранить их непосредственно в указанных объектах и проблема будет решена.
Если недопустимых символов не найдено — копаем дальше. Откройте XML файл сообщения (лучше всего открывать прямо в 1С:Предприятие 8) и посмотрите по указанному номеру строки, на каком объекте остановился прием.
Если чисто визуально с ним всё в порядке — имеет смысл сравнить сериализованный объект, на котором «затыкается» чтение, с каким-нибудь аналогичным объектом БД получателя. Для получения сериализованного представления объекта можно воспользоваться обработкой СериализацияОбъектаВXML.epf в приложении этой статьи. Сравнение нужно производить по структуре объекта! Т.е. проверить, чтобы все элементы метаданных сравниваемых объектов были одинаковы и был соблюден порядок их следования (это важно!). В случае структурных различий поступаем одним из 2-х способов: или разбираемся, почему не произошло обновление конфигурации периферийного узла и устраняем причину; или обращаемся к первой методике из публикации //infostart.ru/public/65456/.
Удачных Вам обменов!
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Все просто и понятно. Минимум слов максимум полезности. 💡 ❗
Образцовое оформление.
(0) Я так полагаю что все статьи будут по очереди и потом все вместе одним файлом? 😉
Авансом плюс.
(1) Спасибо, эту серию постараюсь выдерживать в таком же стиле…
(2) Насчет «мемуаров» ala «всё-и-сразу» подумаю… Спасибо за идею… А серию — да, планирую дополнять по мере возникновения ошибок… Благо в них — то недостатка не испытываю… практически каждый день что-то новенькое…
Параллельно, кстати, запустил ещё менее серьёзную серию , но думаю, что и она своего читателя найдёт…
Спасибо за статьи!
Очень нужны и оказались очень вовремя!
Несомненно +!
(4) Рад, что статьи пришлись «в пору»… 🙂
Поймали вчера данную ошибку. Узел обмен принимает нормально, а вот центр от узла нет. Обработка ВыгрузкаЗагрузкаДанныхXML.epf показала что все норм. Отловить на какой строке хмл валится 1с не получается,просто вываливается сообщение «Ошибка преобразования данных XML» без указания номера строки. Проверили конфигурации узла и центра..идентичные,прогнали тестирование и исправление баз-все нормально,проверили хэши в файлах обмена-все нормально. Что ещё может быть?
Спасибо. очень помогло
Полезная штука
Мерси!
Спасибо за, то что поделились опытом.
Помогло =)
спасибо, надо протестировать. как раз такие грабли появились.
Кратко, понятно и актуально
Спасибо. Актуально.
вчера тоже словила эту ошибку, что только не делала, ни чего не помогало. В итоге решила удалить временные файлы 1с в папке, которая указана в ошибке, и обмен пошел нормально
и еще, если не помогает удаление файлов, или это сделать проблематично (работает много пользователей) берем создаем в указанной папке текстовый файл, сохраняем его с именем, как указано в ошибке ( к примеру v8_B_1a.xml) и удаляем его. и обмен работает. Вот только интересны причины возникновения этой ошибки. я довольна часто вношу изменения в конфигурацию, и после сегодняшнего изменения эта ошибка уже выскочила со стороны центрального узла при обмене с узлом, где ошибка наблюдалась ранее, хотя на той стороне обмен прошел нормально
Столкнулся с такой же ошибкой.
1С 8.3.3.641. Создал РИБ, все стандартно, авторегистрация для всех объектов. Начальный образ создался нормально. В дальнейшем при загрузке данных в периферийную базу выдается «Ошибка преобразования данных XML».
Методом тыка выяснил, что не загружаются именно записи регистра бухгалтерии. Справочники переносятся, документы, если их не проводить тоже, а проводки — нет. Пробовал все способы, что нагуглил, не помогли.
В ошибке указывает номер строки. По этому номеру — разные теги блока проводки. Логики никакой не прослеживается. Сейчас, например, ругается та такую строку:
</AccountingRegisterRecordSet.РегистрПланСчетовОсновной>
До этого ругался та такую:
<Сумма>-421.5</Сумма>
Что делать ?
При открытии обработки вышла ошибка — «Внешняя обработка не может быть прочитана текущей версией программы» Для какой платформы и конфы она писалась?
Вчера поймали у клиента такую ошибку, при загрузке в узел РИБ вылезала «Ошибка преобразования данных XML» без указания строки файла. Жизнь сильно осложняло еще и то, что файл обмена был размером 34 Мб (много чего перепроводили в центральной базе) — «методом тыка» было никак не найти, на чем именно спотыкается обмен.
Помогло следующее: я случайно открыл журнал регистрации в базе-приемнике как раз тогда, когда там шла загрузка. Увидел незафиксированную транзакцию и стал ждать, чем все закончится. Через некоторое время увидел, что транзакция отменена (строки в журнале регистрации стали серыми). А когда вчитался в лог, понял, что последний объект, который записывался в отмененной транзакции — это тот самый объект, следом за которым идет «виновник торжества». Нашел этот объект в файле обмена и посмотрел, какой объект следующий. А потом в базе-источнике просто отменил регистрацию этого объекта в плане обмена.
Следующий обмен уже прошел без проблем.
Сейчас вот буду пытаться разобраться, в чем проблема с этим злополучным объектом.
(18) Спасибо за наводку… при помощи просмотра журнала регистрации (незафиксированных транзакций) действительно удобно находить «виновника торжества»… а разрабы 1С могли бы и конкретизировать ошибки…