Не могу понять в процедуре
ПриПолученииДанныхОтГлавного
что значит параметр <ОтправкаНазад>

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

Из этого описания СП ну не пойму ...

Прилетевший из источника в приемник объект регистрируется в приемнике на узле, с которого отправляются данные в источник...

Обычно так не делают, ибо это вызывает нежелательную волну миграции данных

Но если, например, с объектом в приемнике при записи / проведении происходят изменения, которые нужно обратно передать в источник, то ставь "Истина"

Я вот чего не пойму:

Вот на главном узле делается изменение документа, это изменение передается на подчиненный. Зачем его обратно передавать на главный?

Ведь он с главного пришел такой, зачем его такой же снова назад гонять

(3) Если потом изменения произойдут, то это уже будут изменения и они же итак будут передаваться как изменения, зачем эта отправканазад?

Имхо, это управление приоритетом изменения данных. Если данные между сеансами обмена изменили в обеих узлах, то остаться должно только одно изменение. Вопрос: какое именно? :)

У нас же есть план обмена в нем есть состав документов

(7) Но я не понимаю смысл этого "ОтправкаНазад"

Не понимаю разницы, что оно дает

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

Либо статус документа в приемнике передать в источник - тоже годный сценарий

(11) что значит сразу - если мы допустим обмениваемся XML-файлом, мы из XML, который сформирован на отправителе берем данные для обновления - куда мы обратно будем отправлять - в XML?

При помощи этого обработчика можно изменить обмен так, как вам хочется. Хоть как Бог черепаху.

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

(14) Наверное, но непонятен этот флаг ОтправкаНазад - что он меняет

(13) (15) Я вроде бы все рассказал. Если есть вопросы - задавай с указанием фразы, тебе непонятной

(13) Предполагается что обмена данными у вас двунаправленный. При однонаправленом обмене "ОтправкаНазад" не имеет смысла (за отсутствием оного).

(11) Если сумма итоговая поменялась, значит и документ поменялся, а значит он должен быть передан согласно плану обмена или как?

(19) Вне зависимости от этого ОтправкаНазад

(0) Таким образом, если изменения элемента данных для узла-отправителя уже зарегистрированы, то никаких действий не производится, а если не зарегистрированы, то производится регистрация изменений

Эта фраза вообще непонятна

(11) Я вот тут не понял, документ назад передается или проводки? Или проводки передадутся как измененные, или их не надо передавать?

(12) Не пойму зачем статус передавать назад, если у нас есть основная база и есть основной статус, заменять его на статус оттуда?

В режиме ОбменДанными.Загрузка = истина регистрация в таблице изменений вроде бы не делается.

(24) это к чему было сказано?

К тому что изменения с объектом в приемнике (в процедуре ПередЗаписью, например, или по подписке) происходят в этом режиме и соответственно не регистрируются в таблице изменений для отправки обратно.

(26) Ну уже что-то понятно, но непонятна фраза из СП (21)

(22) Емнип, проводки никогда отдельно не передаются, только вместе с объектом

(27) А че непонятного. К моменту загрузки изменений из файла обмена объект в базе приемнике уже может быть изменен пользователем и соответсвенно уже зарегистрирован в таблице изменений и значит его не надо еще раз регистрировать.

(29) Это уже другая ситуация, коллизия называется

(29) Не пойму там написано про отправитель, Вы пишете про приемник ...

(28) А что здесь под проводками понимается?

(32) Записи в регистрах, они же могут не передаваться XML, а формироваться на приемнике при проведении

(30)Почему другая? Коллизия не влияет на порядок отрабатываемых процедур регистрации в планах обмена. Обработку коллизий можно тоже сделать как тебе нужно, например не принимать изменения от базы-отправителя если в базе-приемнике объект был изменен.
(29) перечитай вдумчиво еще раз, вроде все понятно написал.

(33) Вообще интересно, если и документ и регистр накопления по нему или регистр бухгалтерии в плане обмена, то какие проводки сформируются - из источника или проведение в приемнике?

(29) (34) Да Ваша запись понятна, если флажок поставлен что данные изменились то повторная установка флажка ничего не дает, вопрос не в том, мне непонятна формулировка - последнее предложение в описании параметра в СП (0), особенно "Таким образом" и вообще о чем это последнее предложение?

(36) В последнем предложении описывается происходящий в базе процесс

(37) То есть надо читать так его: "Таким образом в базе происходит процесс типа черный ящик"

Речь об изменениях, которые до начала обмена сделал с объектом в базе-приемнике ПОЛЬЗОВАТЕЛЬ, а не о прищедших сейчас с обменом.

(39) нет в этом предложении слов о базе-приемнике, там написано про узлел-отправитель

(32) Ясно же, движения подчиненные регистратору не передаются независимо от регистратора. Если на узле приемнике формируется движения отличные от движений на узле источнике и эти изменения необходимо передать обратно на узел источник, то надо оперировать с этим флагом.

(40) Т.е. тебе не ясно, в какой базе описывается происходящий процесс?

Т.е. в обоих базах уже есть некий документ РТиУ. В базе отправителе он был кем-то изменен и попал в файл обмена. Я сижу в базе-приемнике и тоже изменил этот же документ(он уже зарегистрирован в таблице изменений плана обмена), и в этот момент в мою бахзу загружается файл обмена из базы отправителя.

(41) (42) Хорошо, в базе-приемнике, просто по обмену от источника. Но тогда непонятно, почему они пишут "Таким образом"

(44) http://new.gramota.ru/spravka/punctum?layout=item&id=58_715

(43) И как это относится к описываемому параметру "ОтправкаНазад" ?

(44) Еще раз объясняю.
По умолчанию В РИБ движения документа передаются вместе с регистратором. Объект по умолчанию в узле-приемнике не проводится, все движения получены из XML. Ну нет смысла проводить тысячи документов в узле приемнике.

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

(46) То есть если мы установили "ОтправкаНазад", то пришедшие данные не будут восприняты в коллизии, а назад отправятся данные из приемника?

(48) То есть ОтправкаНазад меняет поведение по умолчанию и при коллизии делает данные подчиненного документа более приоритетными?

(48) Коллизия тут совершенно не причем, вообще это параллельная ситуация. Конкретно ничего могу сказать, надо смотреть в зависимости от ситуации.

(49) "То есть ОтправкаНазад меняет поведение по умолчанию и при коллизии делает данные подчиненного документа более приоритетными?"

Не путай причину и следствие. Флаг "ОтправкаНазад" в обработчике лишь влияет зарегистрируется ли объект (с новыми проводками или нет - не важно ) как измененный после обработчика. Обычно им не пользуются, используют "ОбменДанными.Загрузка = истина"

(50) А по моему Вы путаете с параметром
<ПолучениеЭлемента>

Тип: ПолучениеЭлементаДанных.
Значение данного параметра может быть переприсвоено в обработчике. Оно определяет, будет ли прочитанный элемент данных записан в базу данных или нет.

(51) "Я тебе про лысого, а ты мне про седого"

(52) Не понял

Кто-нибудь, разъясните, где правда?

Я вроде все ответил уже.
Если остались вопросы по теме - задавай.

(48) и (49) верно?

(56) Без понятия - коллизия к теме не относится и лично мне неясно, что под этим подразумевается.
Еще вопросы, относящиеся к теме, есть?

(57) коллизия в данном случае (ПриПолученииДанныхОтГлавного) это когда в приемнике (подчиненном) передаваемый элемент уже изменен пользователем приемника

(57) У меня вопрос - при коллизии (58) документ изменится в приемнике при такой передаче или же наоборот передача не состоится, а состоится потом передача назад при обмене?

Недостаточно описания, ибо все это управляется прикладным кодом

(60) Ну я так расшифровал это последнее предложение

ЖКК почитал, там вообще ничего не понял

Там такая штука рассмотрена - что документ может быть удален из одного  филиала и помещен в другой филиал. Так вот, в другой филиал он попадает по стандартной схеме ПриОтправкеДанныхПодчиненному по равенству атрибута, а по неравенству отправляется удаление этого документа из старого филиала. Так вот там описан пример использования "ПриПолученииДанныхОтПодчиненного" и при неравенстве артибута (то есть когда в филиале изменили уже атрибут) мы делаем отправку назад с тем, чтобы удалить в старом месте и поставить в новом. Вот, щас написал и понял использование в ЖКК. Теперь надо понять мой случай.

точнее говоря удалить в старом, ведь в новом уже поставлено

то есть мой случай это некое мифическое распространение документа от корней к дереву

В общем ОтправкаНазад это просто установка после принятия изменений признака для отсылки его назад, а то, что написано в СП одному богу известно.

(66) Всё правильно написано в СП. Первое предложение говорит о том, что никаких специальных действий при получении данных не будет сделано, кроме стандартных. Второе предложение описывает суть специальных  действий вместо стандартных. Третье предложение конкретизирует как именно это будет сделано.