Создание РИБ с двух независимых баз. Хочу освежить в памяти порядок. #800125

Задача №1 1. Есть база БП упраленка 2. Есть база БП бух 3. Конфы иденитчны за исключением того факта что в ряде документов есть реквизит (галочка) ну типа "Реглучет" типа булево. 4. Есть обработка переноса данных в одну сторону из Упр в регл базу. Встала задача перехода из 2й в 3ю редакци. Хочу в момент перевода сразу сделать эти базы РИБ. Почему не хочу создавать новый Пб и делать образ с нуля? Потому что в базе регл за 2 года есть куча своих доков типа закрытие месяца ЗП и прочее, кторое не приходит из упр базы а создаются тут же. Как намерен потупить? 1. Обновляют обе базы до 3й редакции. 2. из первой базы конфу обновляю во вторую. 3. В правилах обмена меняю код согласно требуемому фильтру. 4. В первой базе создаю ПБ и назначаю код. 5. Во второй базе создаю узел. Делаю базу подчиненной. 6. Произвожу обмен туда и обратно. Взлетит?

Так РИБ или правила обмена? )

Или ПОД для одноразового переноса? Зачем тогда описывть это

1. Есть актуальная база 2. Бух попросил сделать копию. 3. Проходить время и бух гвоорит надо теперь в базу копию всегда докидывать новые данные с актуальной. Но при этом не переносить данные до опред даты. Созадавать РИБ с нуля и чтоб она опять делала обработку даных за прошлый период жалко ее труда. Хочу просто их сделать связанными в РИБ (ЦБ и ПБ) переделать правила обмена. Взлетит?

Именно риб надо сделать и на постонной основе. а на счет правил обмена исправлюсь. точнее будет надо изменить план обмена.

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

Наверно вы правы. Просто я привык к РИБу. РИБ самоконтролирующаяся вещь. И настраивать проще и быстрее. Хотя есть минусы.

Я обычно беру и меняю полный план обмена или план омена по организации. Потому что почти 100% они потом не используюся по своему назначению.

Я вот боюсь что могут быть дубли Потому что обмен до того не велся по внутреннему идентификатору.

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

так на РИБ там и были раньше внутренние идентификаторы, разве нет?

Ну на это случай я иногда просто делаю копию и даю новое название. Раньше была какая-то левая обработка который вообще без КД был сделан. Но потом мы с другом  переписали в КД. А вот теперь опять на КД для 3й редакции не хотелось бы допиливать. Вот и пришла идея РИБ. А вот те боекты ранние они то если случайно придут во вторую база то могут быть просто двойниками тесть дублями. не важно будь справочник или документ.

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

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

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

Бух в принципе не против чтоб я сделал ей начальный образ ПБ. Она согланса сама заново закрыть месяцы и свои дела повторить по другим докам. Но боюсь что она не очень все оценила. И хочется облегчить ее труд. А вот со второй задачей раз база чистый клон то думаю легче сделать ее рибом. Тем более там полностью все идет но фильтр токо запрет переноса до определенной даты.

просто у меня, например, большие сомнения насчет работоспособности РИБ после смены редакции БП на 3.0

но на 3.0 я его не использовал.

У меня наоборот мнение что РИБ обактывают типовики как надо в отличие других обменов. Простой пример при обмене между БП3 и УТ3 надо следить релиз самого правила обмена.

Всем привет! Есть еще соображение и советы. И самое главное предупреждения?

Так ты в трех словах опиши, что хочешь. А то в нулевом посте простыня плоховоспринимаемая

Две базы БП перевожу с 2й на 3ю ред. При переходе хочу отказатся от обработки переноса данных между ними. Хочу их насильно сделать ЦБ и ПБ в РИБ. Возможно ли и правильно ли я выбрал путь?

Нам отсюда не видно, зачем раньше использовались ПОД (правила обмена данными). Если то же самое можно сделать с помощью РИБ и поддержание их в одинаковом состоянии возможно (синхронное обновление), то делай РИБ.

там есть галка ОтражатьВБухУчете походу. То есть не одинаковое состояние регистров, справочников и т.п и т.д.

Почти угадал Есть в 31 документах реквизит под именем "белый". )))

ну вот. Значит движения по регистрам будут разные в двух базах. И применение РИБ под большим вопросом. Нужна ли она.

Я же собиаю в РИБе фильтры поставить.... на спр на доки и на регистры прямо по списку...

Друг мне пишет. думаю можно использовать хот РИБ, хот без РИБ н по любому надо использовать план обмена и я с ним согласен.