Есть в базе два плана обмена с галкой "риб".

Если меняется конфа главного узла, то обновления конфигурации подчиненного узла приходят по двум планам обмена. В результате периодически возникает рассинхронизация.

Можно ли сделать так, чтобы в одном из планов обмена не регистрировались изменения конфигурации?
Или какие есть еще варианты?

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

снять галку риб...

(2) ага, не все так просто.

(0) два плана обмена с галкой РИБ - не сильно офигенная идея

(0)тебе ж сказали как сделать уже)

лучше сделать по схеме
ЦБ - узел(ЦБ)- узел

что такое рассинхронизация?

(0) Отделим мух от тараканов.
1. "обновления конфигурации подчиненного узла приходят по двум планам обмена". До того как заюзали такую схему вы об этом не знали? Или это скрыто в документации?

2. "В результате периодически возникает рассинхронизация." Рассинхронизация возникает не от режима работы узла с галкой РИБ. А от "узких" каналов обмена файлами выгрузки.

Если уж есть необходимость именно в такой организации РИБ - позаботтесь о своевременной доставке файлов обмена и БуитВамМногаСчастия.

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

(3) На самом деле, все как раз просто. Галка "РИБ" и отвечает за регистрацию изменений конфигурации.

(8) Структура РИБ - "Снежинка". Заказчег хочет много-много отправлять вверх, и редко-редко получать ответ сверху....

В результате разработаны три плана обмена:
- служебной инфомации - поток снизу-вверх на 90%, на 10% вниз, жестокие ограничения по миграции данных.
- справочной инфы - поток сверху-вниз, миграция в рамках правил "риб"
- универсальный план обмена -документ "УтверждениеДокумента" (много буков и кода).

Затык в том, что при активном использовании обновления по плану "СправочнаяИнфа" + изменения конфы, возникает рассинхронизация конфы по плану обмена "служебнаяИнфа".

+(11) Универсальный обмен по планам обмена в целом не приемлем, т.к. нужна жесткая структура и в указанные сроки не реально написать много буков.

(11)между двумя ИБ должен быть задействован 1 РИБ.

*РИБ обмен

(13) Сразу и настаивал на одном РИБ. Но тогда придется каждый объект данных анализировать по жестким правилам принадлежности к уровню узла.
Архитектор не знает как реализовать универсально (как "носки" сравнить с организацией и куратором), а я написал универсальную процедуру, которая (по сути) не пускает ничего.
Итог: в реквизитах сплошные идентификаторы :(

(15)архитектора - уволить

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

(17)отдел разработки..хм)
в каком франче работае?

(18) очень крупный франч... его франчем даже не назвать...

(18) устроился не так давно - там час работать, остальное дело в носу ковырять...
Ушел... потянуло, млин, на приключения...

без приключений жизнь наша скучна)