Ошибка при обмене данными

Подскажите пожалуйста, как можно исправить такую ошибку :

Предыстория. Обмен между двумя УПП. После выгрузки из одной, при загрузке во второй появляется ошибка:

Ошибка записи объекта
ТипОбъекта = Справочник ссылка: Номенклатурные группы
Объект = Блоки бетонные стен подвалов
ОписаниеОшибки = Ошибка при вызове метода контекста (Записать): Ошибка при попытке вставки записи с неуникальным значением ссылки.
таблица Reference130.
ПозицияМодуля = Обработка.ОбменДаннымиXML(3784)
КодСообщения = 26
Ошибка при чтении изменений из файла обмена.
Ошибка записи объекта
ТипОбъекта = Справочник ссылка: Номенклатурные группы
Объект = Блоки бетонные стен подвалов
ОписаниеОшибки = Ошибка при вызове метода контекста (Записать): Ошибка при попытке вставки записи с неуникальным значением ссылки.
таблица Reference130.
ПозицияМодуля = Обработка.ОбменДаннымиXML(3784)
КодСообщения = 26
Чтение данных из файла обмена завершено с ошибками!

Как сие можно исправить?

Решил поменять процедуру Записи в Обработке «ОбменДаннымиXML»:

Возможно ли что это вызовет какие нибудь ошибки в будущем?

Если все это хозяйство уже в попытке, то вылетит по ошибке с надписью «В этой транзакции уже происходили ошибки» или что-то вроде этого.

Но все таки лучше разобраться почему ругается.

Презабавнейшая история битвы с самим собой:

Общая ситуация такая:
Выгружаю данные из БП в УПП с помощью КД. Взял стандратный обмен, он отстает от текущих на 10 версий, довел до ума и тестирую обмен.
При выгрузке справочников выдается ошибка:

Ошибка при загрузке данных: <ВнешняяОбработка.УниверсальныйОбменДаннымиXML(3326)>: Ошибка записи объекта
ОписаниеОшибки = Ошибка при вызове метода контекста (Записать): Ошибка при попытке вставки записи с неуникальным значением ссылки.
таблица Reference102.
Причем, если мы выгружаем все справочники, то ошибка есть, если только контрагенты, то ошибки нет.
Проблема оказалась в том, что при включенной галке «Оптимизированная запись» при записи Свойства объекта происходит не запись, а сохранение объекта в стеке, которое подразумевает отложенную запись.
Но отложенной записи не происходит и получается такая ситуация – в стеке висит структура, которая хранит одновременно объект и ссылку.
Как только требуется обработать еще один объект, мы получаем ссылку по тому же ГУИД, привязываем ссылку к новому объекту и сохраняем. В структуре стека объект отвязывается от нашей ссылки и содержит пустую ссылку с идентификатором «00000000-0000-0000-0000-000000000000». Как только мы, наконец, доходим до самого объекта, он видит, что в стеке есть данные и использует их, причем считая что объект связан со ссылкой, а это, как мы помним, не так.
Все лечится тем, что убираем галку Оптимизированная запись.

Идем вниз по стеку вызовов:

НайтиОбъектПоСсылке перед завершением устанавливает СвойстваОбъектаМодифицированы = Истина; но этот признак никто не обрабатывает, объект зависает в стеке, ссылка теряется и потом мы получаем то, что получаем.

Возможно еще попробовать записать текст ошибки в Настройке плана обмена на закладке «Интерактивные обмен» в Текстах сообщений, которые не являются ошибками. (о как!)

А так уже по 40.000 перенеслось. обмен конечно не самый большой, но ошибок пока не было.

В итоге оставил окончательный вариант следующий:

В обработке ОбменДаннымиXML, в модуле объекта подправил процедуру.

Источник

Обработка ошибок, возникающих при обмене данными в распределенной информационной базе

Общие ошибки, возникающие при работе с XML

Сообщение обмена данными является документом XML, поэтому имеет смысл описать возможные ошибки, которые могут возникнуть во время чтения/записи сообщений обмена данными при использовании средств чтения/записи данных XML, предоставляемых платформой «1С:Предприятие 8». При работе с данными в формате XML может возникать множество различных ситуаций, однако в данной статье будут рассмотрены только те, которые так или иначе имеют отношение к обмену данными в рамках распределенной информационной базы.

Значение URI пространства имен должно соответствовать рекомендации Namespaces in XML (см. http://www.w3.org/TR/REC-xml-names)

Производится попытка записи в XML значения, для типа которого не определена процедура записи в XML. Или производится попытка чтения из XML значения неизвестного типа или типа, для которого не определена процедура чтения из XML.

Ситуации, возникающие при обмене данными в рамках распределенной информационной базы

Источник

Использование инфраструктуры сообщений. Квитирование

Инфраструктура сообщений является неотъемлемой частью механизмов обмена данными платформы 1С:Предприятия 8. Она предоставляет возможности по формированию и анализу сообщений обмена.

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

Для большего понимания процессов, происходящих во время обмена, опишем действия, производимые платформой, при отправке и получении сообщения обмена.

Запись сообщения обмена

Начало записи сообщения обмена

Запись сообщения начинается с вызова метода НачатьЗапись() объекта ЗаписьСообщенияОбмена. В качестве параметров метода передаются объект

(при помощи которого производится формирование сообщения в формате XML) и номер формируемого сообщения обмена. В этот момент происходит формирование заголовка сообщения и блокируется объект представляющий узел-приемник сообщения. После чего объект ЗаписьXML и номер формируемого сообщения становятся доступны через данный экземпляр объекта ЗаписьСообщенияОбмена для формирования тела сообщения обмена.

Выборка и запись изменений данных

Завершение записи сообщения обмена

Получение сообщения обмена

При получении сообщения производится анализ заголовка сообщения:

Начало чтения сообщения

(при помощи которого производится чтение сообщения в формате XML) и допустимый номер сообщения обмена.

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

Чтение тела сообщения

Завершение чтения сообщения

Односторонний обмен

В качестве различных схем реализации одностороннего обмена данными можно предложить следующие варианты:

Все эти случаи предполагают получение ответных сообщений для отработки квитанций о получении данных в узле-приемнике.

Односторонний обмен без необходимости получения ответных сообщений

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

Источник

Номер сообщения меньше либо равен ранее принятому в обмене 1С

Ошибка «Номер сообщения меньше либо равен ранее принятому», наверное, знакома каждому, кто когда-либо связывался с обменами в программах 1С. Рассмотрим, почему возникает такая ошибка, и предложим скачать обработку для исправления ситуации.

Когда происходит обмен данными, система обычно делает специальные пометки в базе данных о том, происходила выгрузка или нет. Узлы планов обменов имеют два специальных стандартных реквизита — Номер принятого и Номер отправленного сообщения (подробно — планы обмена). Именно в этих реквизитах 1С хранит информацию о загруженных/выгруженных пакетах.

Для корректного обмена данными номера сообщений должны попарно совпадать в обменивающихся базах. Т.е. если в базе источник номер отправленного сообщения равен 300, то номер полученного сообщения в базе приемнике должен быть равен 300.

Обработка Регистрация изменений для обмена 1С

Но случаются ситуации, когда номера сообщений начинают расходиться. Это может случится в различных случаях. Например, если одна из баз была восстановлена из архива. В таком случае необходимо выравнять коды сообщений узлов обмена.

Для изменения номера сообщений проще всего воспользоваться типовой обработкой — «Регистрация изменений для обмена».

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

Получите понятные самоучители по 1С бесплатно:

Так и для управляемого:

Для исправления ошибки необходимо нажать на гиперссылку с номерами сообщений (или кнопку Изменить номера сообщений).

В открывшимся окне следует установить сообщения, равные нулю, и нажать кнопку «Записать»:

Внимание! При установки нулевых значений Вы потеряете регистрацию изменений для обмена, т.е. система не выгрузит последний пакет изменений.

Описанные выше обработки обычно в составе типовых конфигураций.

Другие статьи по 1С:

Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):

К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.

Источник

Универсальный обмен оанными в формате XML что я делаю не так?

Мои действия.
— Открыл БП(то что на скрине).
— Зашел в обмен данными с УТ, сохранил правила в XML файл.
— Открыл Универсальный обмен данными в формате XML.
— Выбрал для выгрузки файл XML, базу УТ тоже попробовал.
— Выбрал любой справочник

Нажимаю выгрузить и получаю:

Начало выгрузки: 18.11.2011 13:24:42

Ошибка в обработчике события ПередВыгрузкойДанных (конвертация)
Обработчик = ПередВыгрузкойДанных (конвертация)
ОписаниеОшибки = Ошибка компиляции при вычислении выражения или выполнении фрагмента кода: <(4,52)>: Переменная не определена (УзелДляОбмена)
ПозицияМодуля = Обработка.УниверсальныйОбменДаннымиXML.МодульОбъекта(12759)
КодСообщения = 62

HeadHunter2007 18.11.11 15:19 URL ↓Цитата ↓Ответить

Тогда можешь в эту обработку допилить и выгруженные правила подкинуть.Должно работать.
[+] [−]

HeadHunter2007 18.11.11 15:19 URL ↓Цитата ↓Ответить

Тогда можешь в эту обработку допилить и выгруженные правила подкинуть.Должно работать.

(7) for_vsst, Мне нужно в обе стороны, документы из УТ попадают в УТ, бухгалтер их проводит затем они должны попадать обратно в УТ, плюс еще ПП из банка тоже проведенные.
Спасибо сейчас посмотрю.

вы правы так оно и происходит, есть настроенный мастером настройки обмен, который работает кое как и затирает документы по этому и начал думать как сделать, что бы не затиралось и переносилось только то что нужно(документы имеют префикс УТ).
Настройки XML как раз взяты с этой выгрузки, по ней уже было 28 обменов видно на скриншете.

И что получалось? Можно было кликнуть на кнопку и все синхронизируется как задумано?
Сколько для этого надо было делать изменений в конфигурации?

Если что я не специалист по 1С а в основном программирую на PHP, занемаюсь этим по тому что прошлые специалисты по 1С работающие у нас ничего на эту тему не делали, делали синхронизацию в ручную, удаляя из очереди синхронизации документы которые туда добавлялись при изменении оставляя только нужные.

Источник