Порядок выгрузки объектов в файл по плану обмена #648835

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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