Всем привет! У нас реализован РИБ из 4 уровней. Рабочие базы на 4 уровне. Центральная база на 1 уровне. Уровни 2 и 3 промежуточные сервера. Все работали на 4 уровне и не было никаких проблем. Но вот начался переход на 1С ERP. Первым перешли кадры. Кадровые документы создаются в ERP и обменом падают в центральную базу и дальше расходятся во все рабочие базы 4 уровня. Проблема в том что когда для примера сервер 2 уровня получает данные обменом и регистрирует их для дальнейшего обмена на сервер 3 уровня там объекты идут без движений. Проверил отладкой подписку перед записью регистра сведений или накоплений и выявил что в файле обмена по структура движений идут раньше объектов. И получается что при регистрации движений еще нет объектов и соответственно не можем получить организацию и далее узел обмена. И получается сервер 2 уровня на сервер 3 уровня регистрирует только объекты.

Это конечно не всегда а только с определенными видами документов. По тем объектам проблема, где в файле обмена движения идут раньше чем объект по порядку. А один объект делает движения по двум регистрам и один регистр идет раньше а другой позже и соответственно на сервер 3 уровня регистрируется то движение которое после объекта.

http://www.picshare.ru/view/8388865/

да пофигу по идее что идет раньше. Если раньше придут движения, то у ниж прото будет <Объект не найден> в регистраторах. Это совершенно не мешает им регистрироваться для дальнейшего обмена.Потом придут регистраторы и все встанет на место

(3) А как он встанет куда-то на регистрацию если нет объект и соответственно нет узла? Куда встанет на регистрацию?

В этом-то и проблема что обмен по организации и надо регистрировать в соответствующем узле.

(4)Движения встают в обмен независимо от регистратора, и регистратор независимо от движений. Это же разные объекты метаданных

(5)Организация же не из регистратора надеюсь берется для фильтра, а из измерений регистра

(0) проблема обсуждается гипотетически? может по факту нужно собрать по завершению обмена отдельным заданием актуальный список объектов на регистрацию, а не доверять регистрации объектов в автоматическом режиме самого плана обмена?

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

Если для фильтра маркером является сама битая ссылка, присутствующая в записи регистра, то все нормально

Допиши регистрацию всех движений, когда приходит сам регистратор. Правда, это не спасет от независимых регистров, а также от ситуации, когда сам объект может и не придти вообще, а движения должны дальше улететь...

(11) Дописать не проблема.  Там конфига типовая что касается плана обмена. Как решить проблему я знаю. Не знаю почему такая проблема возникает. По умолчанию в подписке перед записью регистра сведений в истонике стоит отбор по регистратору только и только оттуда можно вытащить узел обмена через организацию.

(12) Что за конфигурация?

(12) глупо брать организацию из регистратора. Берите организацию из регистра, тогда этой проблемы не будет и работать будет обмен в несколько раз быстрее

Наверное, если новое измерение в регистр добавлять накладно, то можно добавить реквизит-маркер в этот регистр?

(3) А если при перепроведении в одном из узлов пойдет разброс по времени с вышестоящим и приедут движения из разных баз? Я встречался со случаями, когда у документа были движения задвоены или затроены.

По умолчанию выгружаются "справочник" - "Документ" - "Движения". Если нет сбоя в получении данных, и никто номера полученных/отправленных пакетов не менял.

Любопытно, как при такой выгрузке ведет себя партионный учет.

(12) Не в несколько раз. И не в каждом регистре есть организация.

(12) Правила регистрации не должны влиять на порядок выгрузки объектов. Если у тебя загрузка идет сначала в центр, и узлы между собой напрямую не общаются - коллизий быть не должно.