Синхронизация данных между типовыми конфигурациями (например, 1С:Бухгалтерия предприятия 3.0 и 1С:Управление нашей фирмой) — это мощный механизм, работающий на базе технологии Enterprise Data (универсальный формат). Однако, как только мы начинаем дорабатывать конфигурацию «под себя», добавляя новые предопределенные элементы в стандартные справочники, отлаженный механизм обмена может дать сбой. В этой статье мы подробно разберем, почему возникают ошибки XDTO при передаче контактной информации и как их правильно устранять.
Рассмотрим ситуацию: в конфигурации 1С:Бухгалтерия предприятия был добавлен новый предопределенный элемент в справочник Виды контактной информации (например, «Юр адрес контрагента в акт»). После этого при попытке синхронизации с УНФ система выдает критическую ошибку:
Ошибка формирования объекта XDTO: Тип свойства <Таблица>. Имя свойства: <КонтактнаяИнформация>.
Не найдено правило конвертации для значения предопределенных данных.
Проанализируем причину. Современный обмен через «Универсальный формат» работает на основе строгих схем XML. Когда система встречает ваш новый предопределенный элемент, она не знает, как сопоставить его с типами данных в приемнике, так как в правилах обмена (встроенных в модули менеджера) этот элемент попросту отсутствует. Система пытается найти соответствие (алиас) для нового значения, не находит его и прерывает процесс выгрузки.
Первым делом нам необходимо убедиться, что обе базы (Источник и Приемник) обновлены до актуальных релизов. Часто разработчики 1С вносят изменения в механизмы обмена, делая их более «терпимыми» к неизвестным данным. Разберем шаги, которые помогли автору темы:
Как показывает практика, в свежих релизах механизм обмена может просто игнорировать неизвестные виды контактной информации, не вызывая падения всей синхронизации. Однако, если обновление не помогло, перейдем к более глубоким методам.
Если нам не нужно передавать этот «Юр адрес в акт» в другую базу, мы можем программно скрыть его от механизма обмена. Рассмотрим, как это сделать, не снимая основную конфигурацию с поддержки, с помощью механизма Расширений.
Нам нужно перехватить процесс формирования данных для выгрузки. В типовых решениях за это отвечают процедуры в модулях менеджеров объектов. Для справочника Контрагенты это может быть процедура, отвечающая за заполнение данных XDTO. Проанализируем пример кода, который можно разместить в расширении (модуль менеджера справочника Контрагенты):
&После("ПКО_Справочник_Контрагенты_Отправка_ПриОтправкеДанных")
Процедура Расш1_ПКО_Справочник_Контрагенты_Отправка_ПриОтправкеДанных(ДанныеИБ, ДанныеXDTO, КомпонентыОбмена)
// Выясним, есть ли в выгружаемых данных наша табличная часть
Если ДанныеXDTO.Свойства().Получить("КонтактнаяИнформация") <> Неопределено Тогда
Индекс = 0;
Пока Индекс < ДанныеXDTO.КонтактнаяИнформация.Количество() Цикл
СтрокаКИ = ДанныеXDTO.КонтактнаяИнформация[Индекс];
// Проверяем вид контактной информации по имени предопределенного элемента
Если СтрокаКИ.ВидКонтактнойИнформации = "ЮрАдресКонтрагентаВАкт" Тогда
// Удаляем строку, которую формат Enterprise Data не может переварить
ДанныеXDTO.КонтактнаяИнформация.Удалить(СтрокаКИ);
Иначе
Индекс = Индекс + 1;
КонецЕсли;
КонецЦикла;
КонецЕсли;
КонецПроцедуры
Этот метод хорош тем, что мы не лезем в сложные дебри Конвертации данных 3.0, а решаем проблему «на лету» в момент отправки сообщения обмена. Объект XDTO очищается от проблемных записей до того, как система начнет проверять их на соответствие правилам.
Рассмотрим ситуацию с точки зрения архитектуры 1С. Создание предопределенных элементов в справочниках, участвующих в обмене — это всегда риск. Выясним, можно ли обойтись без этого. Рекомендуемый подход от фирмы 1С заключается в использовании Дополнительных реквизитов и сведений.
Если вместо создания предопределенного элемента в конфигураторе мы добавим «Вид контактной информации» в пользовательском режиме:
Виды контактной информации в режиме 1С:Предприятие.В этом случае механизм обмена Enterprise Data, встретив пользовательский (не предопределенный) элемент, либо проигнорирует его (если не настроено сопоставление), либо передаст как дополнительное свойство, что не вызовет критической ошибки Не найдено правило конвертации для значения предопределенных данных. Это связано с тем, что для предопределенных элементов система ищет жесткую привязку к внутренним именам формата, а для обычных элементов — нет.
Если вы все же решили идти путем профессиональной разработки правил обмена, вам придется познакомиться с конфигурацией КД 3.0. Разберем по шагам, что нужно сделать в этой программе:
EnterpriseData.Контрагенты.ЮридическийАдрес).Важный нюанс: в отличие от КД 2.0, в версии 3.0 правила обмена чаще всего живут внутри самой конфигурации в виде кода. Это ускоряет работу обмена, но требует обновления модулей при любом изменении логики.
Проанализировав ситуацию, мы видим, что проблема кроется в несоответствии метаданных и логики их сериализации в формат XML. Чтобы ваша синхронизация работала стабильно, придерживайтесь следующих правил:
Помните, что любая ошибка в модулях обмена данными — это повод заглянуть в Журнал регистрации. Там часто можно найти полный текст XML-пакета, на котором споткнулась система, что позволит точно определить «виновника» сбоя.