Здравствуйте уважаемые!

Вопрос наверное теоретический, поэтому начнем с конца - как можно управлять порядком выгрузки объектов в файл обмена (Message_000_001) по плану обмена? Функция ПланыОбмена.ЗаписатьИзменения() не предполагает нужных параметров.
Зачем это нужно? Потому что в приемнике, при загрузке данных, стоит триггер, который отбирает загружаемые данные. Например, загружаемый документ "Накладная" анализируется по полю "Получатель". А сам получатель идет в этом же файле обмена, но позже накладной. При загрузке документа он ессно еще не виден.
Мне видится единственное пока решение - упорядочить объекты внутри файла обмена.
Каково ваше мнение?

как вариант самому формировать файл обмена, см.
ВыбратьИзменения(<Узел>, <НомерСообщения>, <ФильтрВыборки>)

А что делает триггер?

(0) наше мнение таково: триггеры при загрузке - не самая лучшая идея...

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

(2) Триггер принимает решение, выгружать ли документ в другие базы на основании поля Получатель.
(3) Без триггеров не обойтись, т.к. там каскадная цепочка - документ попадает в получатель, а у того еще свои получатели есть, куда нужно выгружать этот же документ
(4) спасибо, мудрый совет. Если действовать по второму варианту - будет ли в конце первого прохода выгрузки видны результаты? Или это надо обработать транзакциями?

(0) "При загрузке документа он ессно еще не виден. "
Это не так. Загружается сразу и ссылка на получатель. В твоем случае получателя не будет только в одном случае. Если получатель - новый элемент. Но у тебя это не так, ибо количество получателей фиксированно и оно однозначно уже есть в базе

(6) Поверьте, такие ситуации могут быть. Я упростил пример, для лучшего понимания. В реальности, анализ идет каскадно - У Накладной есть поле Контрагент, у которого есть поле Получатель. Как-то так. Да, сам получатель известен, но контрагент может быть новым элементом.

(7) Перенести контрагент в реквизит документа и заполнять автоматом при выборе контрагента

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

(5) Тут еще такой момент. Если рулить на стороне загрузке, то удобнее, чтобы был не 1 файл на все, а отдельный файл на каждый объект. Тогда сначала прогружаешь только то, что без ошибок, а вторым проходом идешь по незагруженному. Но тоже не без недостатков.
Если идет 1 блоком, то все грузить в 1 большой транзакции не стоит (транзакция на запись пары сотен документов будет забавна). Значит вполне реально сохранить документ (например) с битой ссылкой, закинуть в массив для пост обработки. А в конце загрузки обработать массив - там уже получатель должен быть заполнен.
Как вариант еще пытаться обработать документ при загрузке и если проблемы (нет получателя, например), то только в этом случае писать в массив.
Еще может быть вариант, что система отправитель сама будет отдавать кому надо в зависимости от получателя при выгрузке.

(7) Если нетиповая выгрузка - выгружать получателя как виртуальный реквизит или как 8

(10) Т.е. при загрузки писать в РС "Загруженные обеъекты"
А при выгрузки анализировать этот РС и выгружать при необходимости

(1)(9) - Пробовал так, но в этом случае не срабатывает триггер  ПриОтправкеДанныхПодчиненному() на стороне отправителя. А это тоже нужно:) Если заставить срабатывать это событие при такой "ручной" выгрузке - было бы замечательным решением!

Самым приемлимым, на мой взгляд, управлением на стороне загрузки - это собирать непонятные объекты в конце выгрузки и анализировать еще раз.
А вот вариант с управлением на стороне выгрузки - я писал уже, что пробовал. Через ВЫбратьИзменения(), потом ЗаписатьXML(). Но при этом не срабатывает событие ПриОтправкеДанныхПодчиненному(). Может я что-то не так делаю?

(14) может ничего не предпринимать? Просто запустить два обмена подряд. В первом обмене получатель подхватится, накладная не пройдет, поэтому она автоматом на следующий обмен зарегистрируется. НУ и во второй раз спокойно загрузится.

(15)+ при этом новые получатели у вас наверняка не каждый день появляются, а так, изредка.

(15) Тоже вариант, не столь красивый, но все же
(16) Да верно, но какое это отношение имеет к алгоритму? Алгоритм должен обрабатывать все возможные варианты

С управлением выгрузкой никто ничего не подскажет? ВыбратьИзменения() позволяет выбирать изменения конфигурации? Наверное нет? План обмена у меня распределенный, или как правильно выразиться.