Добрый день, имеем РИБ УПП, находятся в одной локальной сети. РИБ полный. Причина разделения:
к одному РИБ (РИБ БУХ) подключены все службы (бух, менеджеры и прочее), ко второму (РИБ ПР) производство и самое главное через него идет постоянный автоматический учет поступления выпущенной продукции (rfd карщики).
Разделили с целью возможности проводить обновление базы для бухгалтеров, без остановки работы по учету выпуска продукции, потом выбирали время и с меньшей переодичностью останавливали РИБ ПР и проводили обновление. Теперь появилась необходимость получать информацию из производства оперативно, соответственно если в основную базу были внесены изменения РИБ перестает меняться и требует обновления. Может быть в новой платформе появился механизм который позволяется меняться файлами по не измененым объектам, какие еще есть варианты кроме написать свои правила.

Есть такой механизьм.
называется "планы обмена и правила конвертации"...

Демоническое обновление, муахаха!

(0) Если вы хотели обновления узлов базы проводить в различное время (и иметь возможность обмениваться информацией с базами различной конфигурации), то вам не РИБ нужен был, а план обмена "УПП-УПП" (т.е. обмен между двумя самостоятельными, автономными базами, независимыми друг от друга).

(3) +1
танцуешь с дьяволом - танцуй до конца.
Конфигурация у них могла при этом быть из одного хранилища без каких-либо проблем. Просто - в разное время натягиваете и всё.

Мы у себя для связки "Рабочая база - Тестовая база" используем сторонний продукт. Вносим изменения в тестовую постоянно, а данные хотим в ней иметь свежие (из рабочей).
Через планы обмена, да (без правил конвертации).

(1) Гениальный совет, только чуть чуть до конца не дочитал "... какие еще есть варианты кроме написать свои правила"
(3)(4) как раз таки не хотели проводить обновление узлов базы в разное время, так как УПП кроме как обновляется еще и дорабатывается, был выбран вариант с РИБ что бы исключить двойную работу по внесению изменений. Пробовали выгружать cf и накатывать обновлением, возникли какие то проблемы (согласен что скорее решаемые), но так как не было необходимости в оперативном обмене вариант с РИБ подошел больше. Но с Вашим вариантом согласен что это решение.

(5) Как это через планы обмена но без правил конвертации? Я знаю только один вариант РИБ :)

Иногда самый быстрый способ обновления узлов - это классика жанра - "Выгрузил конфигурацию, отвязал ПУ, загрузил конфигурацию, привязал ПУ" Имхо, естественно :)

(6) две базы могут не быть объеденены одним УБРД-планом обмена, но иметь при этом одинаковую конфигурацию - просто натягивайте один и тот же комплект поставки на них обеих по очереди или, там, синхронно. Как хотите.

Я, работая с риб-базами, привык говорить о "идентичных" конфигурациях. Во всех остальных случаях конфигурации - различные (даже если они одинаковые). Потому так и сказал в (3) - "различные конфигурации".

"какие еще есть варианты"

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

Делиться подробностями не буду, боюсь проклянут православные адепты :), только намекну: танцы с бубном для подмены заголовков в файлах сообщений обмена.

(11)
научишь щас...

(7) план обмена - только для регистрации (накопления) измененений в источнике, которые должны быть переданы в приемник. Далее - сериализация и выгрузка в файл обмена (например, через ЗаписатьXML()). В приемнике - десериализация и загрузка, но конечно же не через ПрочитатьXML().
Правила обмена данными для родственных конфигураций не нужны.