Коллеги, как бы вы решили такую задачу:

Есть некая база, которая отправляет данные в другие, например, магазины. Состав данных у всех должен быть идентичен. Обмен автоматический, выполняется каждый день.
Важно - это не распределенная база данных! Обмен через регистрацию изменений и правила обмена.

В центральной базе решили добавить, например, новый реквизит в справочник, участвующий в обмене. Этот же реквизит надо добавить и в справочники узлов.
Проблема в том, что магазин1 уже добавил себе этот реквизит, обновил правила и ждет данные. А магазин10 тянет кота за хвост и не обновляет.
И центральная база не может начать заполнение этого реквизита, ведь когда магазин10 не получит все данные. Ведь когда(через неделю) он обновит свой справочник и правила, он потеряет все зарегистрированные для изменения за эту неделю с новым реквизитом.

Как сделать так, чтобы в центральной базе добавить этот реквизит и "хранить" регистрацию изменений этого реквизита до тех пор, пока узел не будет готов их получать?

Игнорировать подтверждение обмена конкретно для этого справочника

все базы подключить к хранилищу

(2) и что это даст?

(1) так разве можно? Узел отправляет ответ "сообщение принял" и цб очищает всю регистрацию для него.
решение, по возможности, нужно такое, чтобы не ломать штатный механизм синхронизации данных

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

(5) справочник - это для примера. Там может быть и новый справочник и новый РС и все, что угодно

(6) Хмм... ради "накопления" регистрации изменений, в план обмена можно добавить "левый" узел и паралельно регистрировать изменения для магазина и этого узла. Обмен идёт с магазином - регистрация сбрасывается, с "левым" узлом нет обмена - регистрация изменений "накапливается".

Потом, когда "синхронизируются" конфигурации, перерегистрируйте нужные Вам регистрации изменений с узла на нужный Вам магазин.

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

(8) да. Но как это можно автоматизировать?
Добавили новый справочник и новый реквизит к другому справочнику. И новый РС добавили. Магазин10 справочник добавил, реквизит добавит через 4 дня, а РС добавит хз когда.
Об этом нам сообщили почтовым голубем, а записку унесло ветром. И приходится все держать в голове и для каждого такого магазина изобретать правила переноса регистрации с одного узла на другой.
А если таких магазинов с сотню?

(10) как вы сейчас узнаете в центре, что пб обновила конфу ?

(10) Могу только посочувствовать и пожелать успехов в автоматизации хаоса :( Я с такой ситуацией столкнулся значительно ранее - собственно говоря, меня в своё время пригласили в фирму, чтобы я помог устранить бардак. Я внедрил РИБ.

У нас помесь из риба и обмена по правилам. Все справочники и прочий мусор редактируются в центре и летят по правилам в пб, а доки, наеборот, меняются и создаются в пб и летят рибом в цб.

Часть рс и служебных справочников так и живут и создаются в пб и ниуда не летят.

И да, проще внедрить риб)) хотя бы гарантирует однородность конфы

(11) в чате

(16) а...т.е никакой автоматизации.
Ну хз, прикрутить разве что риб, чтоб конфа у всех соответствовала.
Ну или ипаться со вторым планом обмена, в котором будет узел пб и регистрация, повторяющая все объекты плана обмена для ПБ и дальше как в (7).

Т.е добавить не только узел, и и сам второй план и в нём все узлы.

Как только тебе в чате сообщили, что ПБ обновлена, так все изменения из второго плана для нужного узла переносишь в рабочий план обмена по нужному узлу, меняешь правила и удаляешь регистрацию для узла во втором плане.

Один хрен, это полуручной режим, который всё равно приведёт к бардаку. :)

(17) риб точно не вариант. Базы разные

(20) тогда только еще один план обмена, дублирующий первый и в нём те же узлы...

и потом если есть подтверждение, регим всё из второго плана по узлу в первом плане (основном) и чистим регистрацию во втором.
если сразу измененмя в пб, то просто чистим регистрацию во втором

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

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

(24) праильно, во втором регим только то, что затронуло изменения в cf-нике, грубо храним типы регистрируемых объектов где-то еще.

в рс, каком нить

А разве версии не могут использоваться в качестве такого дополнительного регистратора изменений?

(0) >он потеряет все зарегистрированные для изменения

С чего бы? Если я ничего не путаю, регистрация изменений хранится для каждого узла отдельно.