Всем привет! Есть 5 баз БП3. Нужно их слить в одну базу.
Алгоритм такой:
1. Все базы приводи в единую конфу (и релиз и доработки если есть).
2. Во всех база делаем РИБ по организациям. При этом указываем в4 базах префикс и название базы 5-ой.
3. 4 базы делаем подчиненной.
4. Делаем обмен предварительно зарегив все объекты.
5. от 5й базы делаем копию клон его дружим со своим "родителем" клоном.
6. Пробегаемся по настройкам РИБ и указываем везде нужную организацию. И прогоняем обмен еще раз.

Норм схема? Я ранее не раз так делал.
Спасибо за внимание!

если в 5 базах сделать риб, будет 10 баз, правильно? почему не выгрузить данные в хмл из каждой из баз и загрузить в одну?

только потом надо будет все дубли удалить. они так и так появятся, независимо от схемы

(1) Нет будет так же 5 баз.
Я не собираюсь отпочковывать базы я их просто "подружу" подчиню к одному. Только пятый склонирую .Всего будет 6 баз.

(1) Почему Концепция РИб более предпочтительней мне чем нежели загрузки выгрузки через универсальную обработку. Потому что там не проследишь что надо выгружать а что нет. А в РИб все это давно отработано и отлажено. Ломать голову не надо будет.

(0) Начни с объединения хотя бы двух баз по предложенной схеме.
п.1 не этап, а пожелание видимо
Было бы интересно посмотреть как будет реализован п.3
"Сумлеваюсь я" © Дед Щукарь

В чём великий смысл сливания всех баз в одну кучу? Обычно народ заморачивается с разделением

(3) тогда вы не понимаете смысл риб. это будет просто много лишних действий.

(5) В чем проблема. Я такое проделывал.
п.3 реализуется обработкой которая делает базу подчиненной. при условии что префикс совпадет то начинает без проблем обмениваться.
(6) Я тоже не понимаю но это не моя прихоть. Заказчик захотел. Видимо разово им это нужно. Надо будет уточнить.
(7) НА РИБе я собаку съел. Знаю для чего и как его едят.
Еще со времен 1с77.
А разве выгрузка загрузка через обработки хоть и меньше действий не дает траблу? Я помню там даже предопределенные объекты начинают задваиваться.

(8) "Заказчик захотел" Это не аргумент.
Если конечно оплачивает потом обратный переход )
В подобных случаях я долго пытаю Заказчика о целях объединения, попутно привожу примеры разделения баз, когда владельцы бизнеса разбегаются или надо оставить для аудиторов только одну базу для просмотра

(9) Правильно делаешь. Я точно так же поступаю.
Не делаю тупые глупые заказы. Даже если платят.
Но в моем случае это консультация моему 1с-другу.
Я ему передам ваши мысли и пожелания.
такую работу я делал за всю свою трудовую деятельность раза 2 наверно.
Там что-то типа аля консолидацию какую то захотели. Точно не помню.
А вот организации из одной базы в разные пришлось делить не раз.

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

А потом выясниться что базы рожали почкованием и у всех организаций одинаковый ГУИД

С другой стороны у всех валют (руб) разные гуид и в итоговой базе будет 5 рублей. И тут начнется - а откуда тут валютная проводка, если выбран руб?

(12) При первом обмене же в копии это обнаружится.
(13) Если предопределенные то будут одни вроде если нет то двойников можно объединить.
Хотя это же будет вечная трабла.

(0) Прогнать всё на копии, убедиться что получился полный бардак со справочниками. Бросить эту затею. Или долго и упорно с этим бороться, подключая по 1 базе в месяц.

(8) тогда от нас-то что хотите? раз знаете - делайте.

(16) Ответственное дело. Хотел освежить важные моменты и услышать дельные правильные советы и критику.
А тут некоторые утверждают не совсем правильные не точно проверенные моменты. Вот и апонирую именно в тех вопросах которых я  считаю что уверен.

"Но в моем случае это консультация моему 1с-другу."(10)

Прежде чем что-то начать делать, Вам нужно узнать у "1С-друга" в какой последовательности и как именно создавались эти пять баз. У меня есть сильные сомнения, что все они создавались "с нуля". Скорее всего полным или частичным копированием. Это раз. Второе: нужно узнать как именно "взаимодействуют" (или нет) базы между собой в настоящее время...

Далее можно написать простенькую обработку, которая проанализирует  уникальность GUID в пределах этих баз данных. Анализ количества совпадений покажет Вам насколько всё запущено и плохо в этом зоопарке.

Идеальный вариант - это когда все GUID уникальны. Иначе пункт №4 "Делаем обмен предварительно зарегив все объекты" может доставить Вам много неприятных "сюрпризов".

(18) Из того что известно.
ЦБ куда будет сливатся все другие чисто управленческая.
В нем только отчеты будут крутить.
Нужно сделать обмен только в одну сторону.
А на вопрос как создавались базы заказчик вряд ли ответит. Наверняка приходящие 1сники делали, их там наверно сейчас днем с огнем не найдешь.

(20) Гуиды только организаций или же и других объектов.
Например для номенклатуры это же наоборот классно.

учитывай, что гуиды предопределенных элементов в разных базах скорее всего разные.

по этому по всякие "статьи" и прочее могут разможится....

(23) Это я допускаю. Сталкивался.
Приходилось избавляться.

(24) Полдня обсуждаем...Ясно, что процедура объединения затратная и геморройная.
Но ответа на главный вопрос я не увидел. Повторюсь: В чём конечная цель подобной задачи в понимании Заказчика?

(22) "Например для номенклатуры..." - а если в этих якобы "копиях" объектов с одинаковыми GUID, будет различаться их содержимое (например, значения реквизитов)? Как Ваш "алгоритм" слияния баз это "переварит"?
"There can be only one!" :( Коннор Маклауд :)

(25) Цель, имхо, банальна: получить консолидированную отчетность. А вот методика ТС... эээ... пока что на уровне автоматизации хаоса :)

(0) Кривое решение.
Даже если не было почкования - то получить дубли справочников - контрагентов (с одинаковым ИНН), банков, единиц, валют, стран - это очень плохо..

Правильная на мой взгляд концепция:

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

Ладно у номенклатуры и ладно если полностью. А если было почкование и до одного момента GUID одинаковый, а потом разбежался. Ладно у номенклатуры по наименованию или еще какому признаку их совместили. Но у нее куча своих подчиненных справочников. Которые где то дублируются где то разные.
Для разового слива ИМХО РИБ слишком проблемно.

(28) Вот это уже очень дельный совет. С учетом замечаний на счет гуидов. Принято во внимание.

Давайте тогда обсудим другой метод (схему).

1. Приводим все базы в единую.
2. Универсальной обработкой по переносу в идентичную базу выгружаем данные с каждой.
3. Все что мы выгрузили загружаем в чистую 6-ую базу.
4. Это работу проделываем с определенной периодичностью, при этом каждый раз выбираем период. что не все грузить.

Что тут мы теряем и какие траблы?

Двойники так же могут быть так же?

Еще одна схема это то что в 28 озвучено только без риба а просто с универсальным XML-обменом действовать.

алгоритм должен быть такой

1. реализовать единый центр НСИ, что-бы всю НСИ заводили/меняли только в этом центре
2. делее пьем пиво и ждем когда пользователи наиграются и скажут - мы так не можем и снимут сабж

(27) Спасибо за ответ. Но "хотелось бы услышать начальника транспортного цеха", т.е. ТС

(34) Стоит напомнить, что ТС из Казахстана, а че там и о чем люди думают, хз.

(34) (35) Выше вроде отвечал.

Задача прилетела моему знакомому 1Снику.
Я ему как советчик-консультант, он с такими задачами не имел опыта работы.

С его слов бух хочет сливать каждый день в один "котел" и с этого "котла" строить всякие отчеты.
Он эту ветку внимательно читает.
Я ему сказал все что тут обсуждалось и какие траблы возможны озвучь буху-заказчику.
Дальше поглядим.

+ к (35) А что люди в КЗ другие? Учет там совсем другой. Или 1С там совсем другой. Вроде мы обсуждаем темы не касаясь нац учта. РИБы и гуиды они и в Африке будут такими же. И траблы те же.

Все зависит от целей иногда достаточно поддерживать синхронизацию 2-3 справочников. Товары, клиенты и т.п. и 5-6 документов или строить консолидируемую отчетность по 5 базам или сделать 6 чисто под эти отчеты.
Когда народ н лет работал в 5 и вдруг решает работать в 1 надо понять что ему нужно на самом деле и как это правильно реализовать. Универсальные механизмы удобны для разовых работ, если действие надо часто повторять то лучше написать свой экспорт, отчет и т.п.

(36) Да все нормально...
Сначала объединяем не забесплатно, потом разъединяем, тоже не забесплатно.
Предупреждать об этом не обязательно, разве что заказчик нормальный знакомый.
Овцу можно стричь довольно долго.
Но есть проблема, если твой "знакомому 1Снику" работает на окладе, так делать не стоит.
Один раз сделал - дальше это твоя обязанность. Ему это надо?

(23) А если статьи не размножатся, может ждать сюрприз (от франц. "неожиданность") - в одной базе статья "Материальные расходы" идёт как "ОСН", а в другой - как спецрежим (ПСН/ЕНВД).

(0) Алгоритм тупой
Правильней вручную слить данные (через КД2 или своей обработкой через JSON) в одну общую базу
Почистить ее, настроить и сделать РИБ на нужное число баз

вообще для (0) в 1с есть специализированый продукт - УХ (Управление холдингом)

(0) Не взлетит

(37) Я отвечал людям, которые думают, зачем оно нужно в принципе. Понятно, что в условиях РФ, это кроме гемора ничего не даст. А может в КЗ это архиважно. ВОт про что.

Рассказываю что было дальше.
1. Попробовали через РИБ залить. Многие спр задвоились. Одна база ни как не захотела в РИБ вступать. Лечили не помогло
2. Попробовали через обработку выгрузки и загрузки в идентичную конфу. Опять задвоились. Та же база глюкавая не поддалась нам для загрузки.
3. Решили писать ПОД в КД2.
Сейчас знакомый сидит и пилит ПОД в КД2 и учиться переносить.
Что собственно и озвучивали многие.

(45) Главное чтобы потом не пришлось разделять обратно

(46) Это база чисто для отчета работа все равно ведется в тех разных базах.
Если клиент поймет что это ничего им не дало просто проект уйдет в утиль и все.

РИБ тоже работает через КД в плане преобразования данных, так что по сути нет двух вариантов это одно и то же.

(48) Правила там другие. Чтоб не задвоились поиск организуем не по гуиду а по ИИН, наименованию итп

Из опыта, проще иметь общую базу и "разделять", выпиливая всё ненужное, чем постоянно собирать информацию ради пары отчетов. Варианты что с РИБ, что с КД при периодических обменах никакой критики не выдерживают. Это для мазохистов от ИТ.

(50) Все это всем и так известно.
Но ситуация у заказчика так сложилось и задача стоит именно собрать базы.

начинать всегда надо с НСИ. определиться с составом общих справочников, сделать доп реквизит в который прописать из какой базы каждый загружен, прописать или выбрать готовые обработки слияния/объединения дублей/замены в документах.
когда с этим разобрались грузить остатки.
получить основные отчеты совпадающие по суммам с расшифровками в старых и новой базе. уже после перехода к новой НСИ.
радоваться)

(47) Ничто так не радует, как работа, сделанная дважды, которая пошла в утиль.

(51) Так и собирайте в одну общую, где все будут вести операционную деятельность. Можно по очереди, согласно плану. Вполне возможно что можно обойтись вводом остатков на определённую дату, тогда и справочники придётся курочить куда как меньше.

Скрыто модератором, как возможно недостоверная информация

Была одна ЦБ - сделал 5 копий (5 организаций)
у каждой организации - свое количество ПБ

Захотели ГЛАВНУЮ ЦБ (объединение всех ЦБ)

в каждой цб создан узел ("XXX") с условием , что это только получатель (можно снять , но не суть)
каждая база выгружает файл
000001-XXX.zip их пять
(поэтому выгружаются в папку ОБМЕН\1,ОБМЕН\2 и.т.д

6 база принудительно сделана Периферийной
свой узел "ХХХ" центр "000001"

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

(0) А как справочники сопоставлять будете? Представляете, что в одной базе номенклатура Фэйри, а в другой Чистящее средство и это одно и то же. Коды и ГУИД-ы разные.

(33) 👍 Зачот!!!

у нас когда много и больших баз объединяли до полугода уходило только на то чтобы НСИ причесать.

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

(59) Не факт, что даже отчетность заполнится нормально.

(59) А за ради отчетности сливать — на уровне бреда. Неужели нельзя складывать цифири без ненужных обменов. Это как тонзиллэктомия через анальное отверстие.

(59) Что за отчёт? Не проще ли строить 5 отчётов в отдельных базах и потом их консолидировать?

(62) Сказали "консолидированные отчеты: баланс доходы и убытки и т.д."

(63) То есть каждый подельник должен из отчетов исключить внутригрупповые обороты? И только? Зачем базы ради этого объединять?

Ради отчета сливать не стоит, проще привести справочники к общей иерархической структуре. Например для номенклатуры заводим группу Колбаса во всех 5 базах с номенклатурой колбасы, консолидацию делаем только по этим общим группам.

(59)  "глав бух или зам гл бух хочет какой-то консолидированный отчет"...а идея слить для этого базы не ее была?

(59) Наконец-то нам озвучили настоящую задачу. Хоспади...

Базы остаются отдельными.
Нужно сопоставление по НСИ.
Предлагаю завести MDM-базу для этого. В ней прописать сам объект и ID объекта каждой базы.
Далее формировать отчётность в каждой базе отдельно и поднимать наверх для консолидации и свёртки по элементам.
Исключить внутренние обороты для отдельных показателей, например, продажи-покупки типа интеркампани, чтобы не завышать обороты по группе компаний.

(63) Как-то же работали раньше без общей базы?
Значит уже много лет ГБ делала сводные отчёты в ручном режиме. Вот посмотрите и запишите на бумаге её действия.
Например, из базы 1 она берёт то-то, из других баз - это, затем складывает, вычитает и заносит искомое в такую-то то ячейку сводного отчёта.

После чего рисуете макет, тащите из баз инфу и после функции заполняете макет.

А делать для этого общую базу - ахинея.

А скажите пожалуйста в КД2 как передавать проводки и движения РН?
Почему при авто-создании ПОД они не создаются?

(63) Как уже сказали, ради этого не надо сливать базы. Надо консолидировать отчёты.
https://buh.ru/articles/1s-konsolidatsiya-8-novyy-produkt-dlya-resheniya-zadach-sovremennogo-biznesa.html
Сейчас, ЕМНИП, отдельно не продаётся. Входит в состав "Управления холдингом". Ценник, правда, недетский.
Но я бы в эту сторону копал.

Есть ещё один инструмент консолидации отчётов от 1С: "Свод отчётов". Он заточен под бюджетников, но позволяет создавать собственные формы отчётов. https://v8.1c.ru/svod/sobstvennye-vidy-otchetov/

Консолидация была написана именно для этого. На форуме нельзя писать, куда деваются заброшенные вендором релизы, ну и не будем.
Единая база - это, как написали евшие кактусы коллеги - совсем другого масштаба ОРГАНИЗАЦИОННАЯ работа. Просто получив (во что не верю) идеально вычищенную базу, через неделю пользователи, работающие по-старому, загадят её дублями.

(75) За вами карма...

(0) сначала сдружи справочники между базами, чтобы не было дублей. Потом всё остальное