Доброго времени суток,
из 2 баз БП КОРП необходимо выгружать информацию в "сводную" базу идентичной конфигурации.
я прекрасно понимаю данная тема заезжена и подобных тем множество, однако в этом множестве нет нормального решения:
РИБ тут не подходит т.к. это структура не для РИБ   +  в дальнейшем на эту "сводную" базу будет установлен БитФинанс.
Обработки "Выгрузка и загрузка данных XML" и "Универсальный обмен данными в формате XML" - это разовые выгрузки, а данный обмен необходим на постоянной основе.
Обмен "Другая программа" производит конвертацию объектов, что искажает исходную информацию (напримере: РКО прочий расход с определенной статьей ДДС конвертирует в личные средства предпринимателя)
править правила обмена для универсального обмена не очень хорошая идея т.к. в базе имеются другие обмены использующие правила универсального.

Пытался брать обработку "Выгрузка и загрузка данных XML" и модифицировать:
Создал универсальный обмен в базе и обработкой отслеживал регистрацию изменений и только данные объекты выгружались, далее снимал регистрацию. Чисто теоретически если данную обработку доработать то в принципе это выход из ситуации, но есть ряд нюансов - порядок выгрузки, дубли, отслеживаемость по  номерам сообщений и т.д.

Так вот
есть ли варианты организовать "правильный" обмен между идентичными конфигурациями, хорошо бы с использованием КД2 (с КД3 плохо знаком)

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

Если отказаться от использования термина "идентичные конфигурации" и заменить его на "одинаковые конфигурации", то возможно Вы обнаружите что для большинства типовых конфигураций правила обмена уже были многократно написаны (например, https://v8book.ru/public/673289/ ) Создать самому правила регистрации/обмена между одинаковыми конфигурациями - легко - в КД2 они 99% создаются автоматически.

(0) А в БП Корп нет соответствующего плана обмена "БП-БП" и типовых правил обмена в составе конфигурации?

(1) Я бы посоветовал автору первоначально использовать именно РИБ. Когда (и если) придёт время устанавливать БитФинанс - к тому времени автор освоить в совершенстве конвертацию данных, а РИБ - легко превращается в автономные, независимые друг от друга, самостоятельные базы. Имхо, разумеется.

(3) Более чем уверен, что в БП уже везде используется универсальный обмен в формате EnterpriseData. А у автора с ним отношения не сложились :)

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

Основное направление какими средствами его создать, так чтобы он учитывал порядок выгрузки/загрузки данных, с учитыванием номеров сообщений, чтобы взаимосвязанные объекты выгружались не каждый раз за обмен, регламентная выгрузка/загрузка.

Я понимаю, что универсальный обмен мне в руки, но да с ним не сложилось.

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

Ну например можно так :

Обработка = Обработки.УниверсальныйОбменДаннымиXML.Создать();
Обработка.РежимОбмена = "Выгрузка";
Обработка.ВыводВОкноСообщенийИнформационныхСообщений = Ложь;
Обработка.ИмяФайлаПравилОбмена = Константы.укПутьКФайлуПравилОбменаПТУ_ДляФРС.Получить();
Обработка.ТипУдаленияРегистрацииИзмененийДляУзловОбменаПослеВыгрузки    = 2;
Обработка.ЗагрузитьПравилаОбмена();
    
Обработка.НепосредственноеЧтениеВИБПриемнике = Истина;
Обработка.ТипИнформационнойБазыДляПодключения = Истина;
Обработка.ВерсияПлатформыИнформационнойБазыДляПодключения = "V83";

Обработка.КаталогИнформационнойБазыДляПодключения = Константы.укПутьКБазеУТ.Получить();
Обработка.ПользовательИнформационнойБазыДляПодключения    = "ЭтоЛогин";
Обработка.ПарольИнформационнойБазыДляПодключения = "ЭтоПароль";
    
Обработка.НепосредственноеЧтениеВИБПриемнике = Истина;
Обработка.ТаблицаПравилВыгрузки.Строки[0].СсылкаНаУзелОбмена = ПланыОбмена.ОбменПТУ_Для_ФРС.НайтиПоКоду("УТ");

//фОР = Обработка.ПолучитьФорму();
//ФОР.ОткрытьМодально();
Обработка.ВыполнитьВыгрузку();

Пример взят из УПП

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

(9) Обработка находится в конфигурации. Но можно и на внешнюю поменять - не вопрос.
Переносятся только зарегистрированные на перенос (у нас не автоматическая регистрация при изменении - а нами в коде прописана. Ибо там есть доп. условия. Но это не важно.). Ну и после переноса там убирается регистрация объектов в узле.

Кстати, в дополнение. Есть обработки контроля. Сверка всё ли перенеслось. Там вообще всё просто. Получаем запросом объекты, которые должны быть перенесены (незакрытый период). Запрос выгружает данные в таблицу значений. Таблица тупо пишется в файл. Обработка в конфигурации-приёмнике считывает из файла в таблицу значений и передаёт в запрос на создание временной таблицы. Делаем соединение с выборкой объектов, которые перенесены (соединение - просто по ссылке) - и тут же получаем не перенесённые :-)

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


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

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

(7) "в данном центральном узле будут произведены некоторые изменения конфигурации для направления управленческого учета, которые естественно не должны попасть в другие базы..." - это не повод отказываться от РИба, а повод для дальнейшего изучения программирования 1С и алгоритмов типовых конфигураций. Если какой-то алгоритм не должен работать, до достаточно использовать в условиях ПланыОбмена.ГлавныйУзел(), например:

Функция ЭтоПодчиненныйУзелРИБ() Экспорт
    Возврат ПланыОбмена.ГлавныйУзел() <> Неопределено;
КонецФункции

(10) Такой вот вопрос, с правилами обмена более менее понятно стало после тестов, но есть все равно некоторые вопросы с этим методом, если в правилах делать по правилу "один в один" то нужно ли в объектах прописывать выполнение "После загрузки" по типу Справочники.Организации.ОбновитьИспользуемыеВидыОрганизаций(); для заполнения регистров может каких либо и т.д. Или же достаточно будет того что система прогрузит один в один объект и ей этого будет достаточно.

Я понимаю что фундаментальные объекты типа как Организации после загрузки нужно будет проверять данные и корректировать их, или включать в обмен выгрузку регистров.

(14) лучше все грузить и ничего не обрабатывать

(15) Возникает тогда вопрос, как быть с документами которые имеют ручные корректировки. Регистров множество взаимосвязано с объектом, допустим "ОтчетОРозничныхПродажах", а если бухи сделали корректировки ручные то в любом случае грузить полностью все регистры так получается? или писать определенный алгоритм по выгрузке сделанных корректировок.

(16) перегружай регистры. проводить ничего не нужно и даже вредно

Лучше всего на SQL написать, грамотно используя таблицы изменений. Хотя конечно все еще зависит от объема.

Элементы справочников идентичны в конфигурациях?
или хотя бы похожи?

+(19) я бы наверно так пробовал.
Сериализацию за основу бы взял, ей бы все таскал, базы то идентичные.

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

как добьешься идентичности справочников, пишешь выгрузку документов, выгружаешь из 2-х баз, и в момент загрузки их в базу консолидации подмениваешь у них у документов УИД, генерируешь свой, и для истории что поменял, и какой документ получился в базе консолидации пишешь в регистр публичные идентификаторы.

Сериализацией  все таскается на ура, мы перенос делали из ЕРП в ДО. Идентичные справочники. перенеслись без проблем, и кода не много.

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

Вопрос автору ветки. Почему РИБ не к месту? Обоснуй.
Тут РИБ самое то и не надо заморачиваться.

(23) ИМХО по причине "в дальнейшем на эту "сводную" базу будет установлен БитФинанс." - т.е. завтра это будут разные конфигурации, что не отменяет использования планов обмена. Обмениваются же в конце концов ЗУП и БП

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

(20) Такой план и был, взять одну базу, слить инфу данных второй и далее обмен.

У нас также было - 4 БПКорп разных филиалов, организаций и запускали Битфинанс. Для нас не было смысла выгружать данные из БП в Битфинанс, т.к. внедряли казначейство и бюджетирование, эти подсистемы тесно связаны с платежами. В итоге, из двух баз БП сделали общую, избавились от дублей в справочниках. Потом на эту БП накатили Битфинанс. И уже из Битфинанса своими правилами выгружали данные в отдельные БП.