Заранее извините за многословность, Конвертация данных 3.0 - технология для меня новая, пока "с выпученными глазами"...

Есть задача собрать данные из 4-5 баз БП в пустую БП КОРП (разовая загрузка). Все конфигурации версии 3.0.71.89 (и БП, и КОРП), платформа 8.3.12.1685.

Делал всё по статье: http://catalog.mista.ru/public/695523/ Исправлял обе обработки (MD83Exp.epf, Выгрузка правил синхронизации.epf) и обработку "ЗагрузкаПравилСинхронизацииИзФайлов" внутри КД как там написано, вроде всё заработало.

Результат приделывал упомянутым там же методом "подключить расширение, которое полностью подменяет общий модуль с правилами", тоже вроде получилось. Получилось расширение, в котором три общих модуля (два своих, и один заимствованный), и один заимствованный план обмена. Свой модуль "ED_МенеджерОбменаЧерезУниверсальныйФормат" содержит то, что копируется из КД по кнопке "Сохранить модуль менеджера обмена" в КД.

В Предприятии настраивал через "Администрирование" - "Синхронизация данных", через файлы в папке на сервере. Собственно всё, что я менял в стандартных правилах обмена, это поставил у всех справочников "По полям поиска" вместо "Сначала по УИД, потом по полям поиска", чтобы уменьшить задвоения. Кстати, логично ли это?

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

Направление: Отправка.
ПОД: Документ_ПлатежноеПоручение_Отправка.
ПКО: Документ_ПлатежноеПоручение_Отправка.
Объект: Документ объект: Платежное поручение, Платежное поручение КПП-000246 от 31.07.2013 13:26:02 (e1cib/data/Документ.ПлатежноеПоручение?ref=b139441ea13d687411e2fab7f7a5ff2f).

{ОбщийМодуль.ОбменДаннымиXDTOСервер.Модуль(912)}: Ошибка формирования объекта XDTO: Тип свойства <ОбщееСоставноеСвойство>. Имя свойства: <РеквизитыПлатежаБюджет>.

{ОбщийМодуль.ОбменДаннымиXDTOСервер.Модуль(912)}: Ошибка формирования объекта XDTO: Тип свойства <ОбычноеСвойство>. Имя свойства: <ПоказательДаты>.

{ОбщийМодуль.ОбменДаннымиXDTOСервер.Модуль(836)}: Ошибка при вызове метода контекста (Создать)
                        ЗначениеXDTO = ФабрикаXDTO.Создать(Свойство.Тип, ЗначениеСвойства);
по причине:
Несоответствие типов XDTO
по причине:
Ошибка проверки данных XDTO:
Значение: '01.01.0001' не соответствует простому типу:
            ВызватьИсключение СтроковыеФункцииКлиентСервер.ПодставитьПараметрыВСтроку(
            ВызватьИсключение СтроковыеФункцииКлиентСервер.ПодставитьПараметрыВСтроку(

Не понимаю, что за "ПоказательДаты" с пустой датой, и где это вообще искать...

Ну, и ещё вопрос: для решения задачи я верный инструмент выбрал? Была мысль написать обработку с нуля через OLE, но выгрузка разовая, а справочников и документов несколько десятков как минимум, уж больно трудоёмко показалось. Есть ещё способы решения?

какой-то из реквизитов типа дата в поручении пустой, а по правилам выгрузки он пустым не должен быть, наверное бухгалтер его не указывает.
далее - не формируется пакет XML к выгрузке и загрузка падает.

{ОбщийМодуль.ОбменДаннымиXDTOСервер.Модуль(912)}: Ошибка формирования объекта XDTO: Тип свойства <ОбщееСоставноеСвойство>. Имя свойства: <РеквизитыПлатежаБюджет>.

{ОбщийМодуль.ОбменДаннымиXDTOСервер.Модуль(912)}: Ошибка формирования объекта XDTO: Тип свойства <ОбычноеСвойство>. Имя свойства: <ПоказательДаты>.

Разовая консолидация, да еще и между практически идентичными конфигурациями - КД 2 сам бог велел

ну вот открыл старую БП, документ "ПлатежноеПоручение", реквизит в шапке "ПоказательДаты" есть.

(1) Спасибо! Вижу реквизит "ПоказательДаты" у Платежного поручения, и это строка. Сейчас попробую поискать все доки, где пусто...
(2) А не будет ли там той же самой проблемы? Хотя... Наверное, можно попытаться тупо игнорировать этот реквизит, хоть в КД2, хоть в КД3?

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

Нашёл ещё Счета с пустыми Контрагентами, на которых тоже ругнулось.
У меня вопрос: как проще всего запретить выгрузку непроведённых документов в моей ситуации? Желательно, скопом всех. Возможно, это решит проблему...

(0) >> КД 3 ... правильно ли выбран инструмент?
>> (разовая загрузка)

Дальше даже не читал и не вникал.
Для разовой выгрузки однозначно КД 2.

+ к (7) Причем где-то даже читал эту рекомендацию от 1С. Типа EnterpriseData - это для настроек серьёзных обменов на регулярной и долговременной основе, а для разового обмена - не ипите мозг и берите КД2.

(7) ОК, спасибо, понял.

Но всё же, (6)?

Где-то я затупил... Разыскал Платёжные поручения с пустым ПоказательДаты (их несколько десятков было, все непроведённые), просто записал туда "01.01.1000". На форме узла обмена сделал "зарегистрировать" со всеми флажками, выгружаю — ситуация та же самая, синхронизация не удалась, в журнале регистрации кучка тех же самых сообщений про ПоказательДаты.

И там почему-то опять "01.01.0001", а не "01.01.1000".

В журнале, имею в виду.

Наверное, не все нашёл... А какие строки, кроме "", по умолчанию преобразуются в пустую дату?

Тупняк был в том, что оно хочет "0" в этом поле, а была ещё пачка платёжек, где стояло буквально "01.01.0001", а не пустая строка. Получается, разночтения между работой типовых конфигурациий и созданными для них же правилами обмена.

Документы вроде перенеслись, но не перенеслась учётная политика, из-за этого много чего не провелось.

В целом, от КД3 крайне негативные впечатления — по сути, нерабочая вещь. Начиная с того, что всё нужно править только для того, чтобы оно просто запустилось, не говоря уж о работе.

Возможность (6) не нашёл.