Доброго времени суток.
Есть две базы 1С - руины КА и база на библиотеке стандартных подсистем. Между ними посредством конвертации данных версии 2.1.8.1 настроен обмен. Используется одна платформа 8.3.6.2390. Проблема заключается в том, что обмен идёт через файлы и в файл помещаются все накопленные изменения, поэтому, если изменения не могут быть корректно обработаны другой стороной, то обмен прекращается. Хотелось бы, чтобы в один файл помещались изменения связанные по смыслу, а в случае поломки файл с ошибками сохранялся в отдельном каталоге и не мешал дальнейшему обмену. Подскажите, пожалуйста, возможно ли это сделать не сильно переписывая выгрузку и загрузку файлов?

А ты готов описать алгоритм того, как определить "изменения связанные по смыслу"?

Краткий ответ: нет.

Интересно, если я поменяю контрагента, а потом номенклатуру. И всё это выгружу в одном сеансе - это сильно по смыслу будет связано?

(1) Алгоритм связанности данных по смыслу не представляет никакой сложности. В данном случае в одном пакете надо выгружать заказ и его статус (если были оба изменены).
(2) Какая разница по каким правилам у меня связываются изменения данных? Алгоритм выборки связанных данных, можно реализовать в кд в правилах выборки. Вопрос - каким образом разделить файл на много маленьких.

Не сильно переписывая такой возможности нет.
В кое-каком стороннем (платном) решении есть режим "гибкого" обмена с пропуском ошибочных объектов, т.е. обмен не останавливается из-за ошибки при загрузке / выгрузке. Но это отдельная конфигурация, т.е. мало подходит под "не сильно переписывая"...
Если же самому хочется делать - ну кури события загрузки, обработку исключений при записи объектов и хранения этих объектов и передачи их обратно для регистрации в источнике...

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

(4) Спасибо.
(5) Не совсем, некоторые сущности по сути справочники разбросаны в нескольких РС, в одном основная таблица, а в других табличные части.

(6) Тогда выбирай изменения (перебрасывай) с одного узла на другой, который не участвует в регистрации объектов при их записи в БД, и работай уже только с этим узлом. Выбирай с него изменения, распределяй по отдельным узлам и выгружай

(7) Спасибо.

(0) напиши сам через ком. будет гораздо лучше.

(7) тогда на стороне приемника придется плодить столько планов обмена, сколько будет узлов выгрузки в источнике (т. к. ЭтотУзел может быть только один в плане обмена)

Может проще систематизировать и устранить причины, по которым "изменения не могут быть корректно приняты другой стороной"?
Например поставив, нужные проверки при записи объектов?

(9) Не везде есть ком, приведённая в примере пара, только верхушка айсберга.
(11) Проблема таких ошибок в том, что их невозможно заранее предусмотреть. Особенно. когда владеешь только половиной обмена.

>> если изменения не могут быть корректно обработаны другой стороной, то обмен прекращается.

Грузи их в режиме обменданными.загрузка = истина. На стороне-приемнике отключай все проверки, если производится обмен данными.

Фиксацию транзакции поставь поменьше.

(3)А что, на основании заказа ничего больше у вас не делается? Ни счетов, ни реализация, ни оплат?