Если изменить элемент справочника, а потом документ, проводки которого привязаны к элементу, то это не все равно, если сделать наоборот. Отсюда вопросы:
1.Бывает, что в принимающей стороне все отработает именно в обратном порядке?
2.В базе хранятся все предыдущие состояния выгружаемых объектов ?
3.Существует какой-нибудь низкоуровневый идентификатор записей подтверждающий выгрузку запись в запись (например, чтобы увидеть сироту)? Или выгрузка идет с интеллектуальной обработкой (типа сначала это, потом то?

Похоже, у всех уже пятница

Что значит "проводки которого привязаны к элементу"?

В проводку попадает реквизит справочника

Прочел 0 пост, потом прочел его задом наперед, все равно ничего не понял. Отсюда вопрос: "Простите, кто на чем стоял?!" (с)

Например, Сотрудник имеет ревизит Отдел (это тоже справочник и у него реквизит Начальник). В проводку должен попасть начальник.
Так вот если у отдела сменить начальника, а потом провести документ, то это не все равно, если провести документ, а потом поменять начальника.

Интересует вариант, когда проведение документа долетело раньше изменения начальника. Это возможно?

(5) зависит от того какпрописана логика программы.

Во всяком случае в перую очередь нужно менять начальника а потом перепроводить документ.

(6) При УРБД документ если прилетел может вообще не проводится. Поэтому если раньше сменили начальника а потом прилетел документ, то в проводках останется старый начальник.

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

Какая логика? Это же УРБД, а не выгрузка\загрузка. В моем представлении физическая запись должна падать в физическую.
да?
Вопрос в том в каком порядке эта физическая запись выберется из источника (согласно плану обмена) и может ли долететь раньше чем следующая выбранная запись

(9) получается надо всегда слать и записи в регистрах?

(11) поидее так и делается всегда почти, если у вас не шлётся и используется отложенное проведение - надо думать и предусматривать

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

у меня например, для некоторых нужд в УРБД,  специально прописано проведение документа, после того как он прилетел из другой базы. ТОлько это проведение после полного прочтения файла обмена.

(8) проводки тоже переносятся. поэтому сначала перенесутся со старым начальником. Потом при следующим обменом с новым.

(13) вот, да. Я считаю, что добиться идентичности баз путем УРБД нельзя. Надо дописывать сравнивалки.

А на случай вариантов состояния объекта: в таблицах регистраций изменений должны хранится все состояния объекта. Это же какой объем старья (на каждый дурной ОК будет заводится строчка)?

И какая из этих строчек будет посылаться - последняя, как не устаревшая, или  все по-очереди?

чо за бред? ВСЁ идентично в РИБ, с миграцей движений.

1. Изменил справочник
2. провел документ
Движения дока с новым начальником. так?

1. провед документ
2. изменил справочник
Движения дока - со старым.

Так и будет, и в источнике и в приёмнике

(16) РИБ гарантирует согласованность данных. У неё нет устаревших. Если выгрузилась "устаревшая", то в следующую выгрузку попадёт актуальная

1.Изменил справочник 2. Провел документ.
Где гарантия что в файл обмена попадет сначала справочник?

(19) без разницы как в файле расположены данные. Они будут либо загружены все, либо не загружено ничего. Это парадигма РИБ, которая гарантирует согласованность данных

Согласованность данных можно обеспечить, если во-первых,у записей в таблицах обмена существует идентификатор, поддерживаемый в приемной базе и, во-вторых, эти записи должны хранить полное состояние выгружаемого объекта.
Это так реализовано?

(21) да, идентификатором выступает Номер сообщения

(19) рассинхрон быть может в этом случае. Пример:
1)Создал новый элемент справочника
2)Указал в документе его в реквизите А
3)У тебя в документе в зависимости от реквизита А перед записью устанавливается реквизит Б.
3)Все пошло в риб в произвольном порядке
4)В РИбе не анализируется "если загрузка.Обменданными = Истина". ВРибе у тебя перед записью документа возможна не та установка реквизита Б т.е. элемент справочника идет позже.

Получается УГ.

(23) в типовых перед записью в каждую щель напихано - Если Обменданными.Загрузка Тогда
///игнор всего, что делается в перед записью, при записи, подписках и прочих, что может выполнится при записи объекта в ИБ.

Если это не предусмотреть - то конечно, но виновата не 1с, а недопрограммирование доработок своих

>>В РИбе не анализируется "если загрузка.Обменданными = Истина"
это хоть почему? очень даже анализируется. Если забыл вставить - кто виноват?)

(9) При обменах не происходит проведение????
А как же обмен ут - бу?

(26)Это конкретно надписанно для конкретного обмена.

(26) РИБ или не РИБ, вот в чем вопрос!
Тут риб стандартный, в типовых не извращаются с этим гемором отложеных проведений

(28) мы не знаем что у него за риб и что у него за конфа.

(29) судя по (21) таки обычный РИБ, и в (0) он собсно спрашивал техническукю реалитзацию в п.3.

(30) РИБ обычный, конфа не тронутая
Вопрос, собственно, писать сверялки ЦБ с периферией или нет.
Когда эксплуатировалась 7.7 это было актуально. Сравнивалась физическая структура DBF, а теперь куда глядеть, чтобы увидеть ?

Сравнивалось физическое содержимое DBF - находились дубли, слипание, зависание IDD. Причем на пользовательском уровне это становилось заметным, только когда программисты пальцем тыкали.
А теперь куда глядеть? Или это штатно делается?

(31) не писать, 1с тебе гарантирует, что все косяки добровольные будут синхронизированы

Йохохо, поделись уверенностью. Доказательства, ссылка?