как соединить несколько организаций в одной базе?

Нет. И в общем случае они не объединяемые без хреновы тучы методологической работы.

скопировать 1cv8.1cd с режимом объединением :)

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

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

давайте пока предположим, что нет одинаковой номенклатуры и контрагентов
вопрос, что ещё задвоится при переносе ? вылюты например или единицы измерения ?

сейчас у меня две задачи по объединению
15 баз в одну
5 баз в одну

делаю через кд2 
всем справочникам задаю поля поиска 

если по полям не нашёл НСИ, то пишу их код обязательно с префиксом

(6) можешь ей грузануть, если основные справочники не пересекаются

но потом ИРом надо будет вычистить НСИ системное

КД2, для справочникоы - не по ИД а по нпименованию правила забить. это так. навскидку.

(6) Одинаковые записи есть. Независимо от размера базы. По определению есть.

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

(0) первое и обязательной условие такого объединения - делать все в рамках распределенной информационной базы. Почему? чтобы не ловить геморрой при последующем разделению этой общей базы по организациям. Поверь: такая задача будет обязательно поставлена через какое-то время.

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

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

(14) Мне повезло - владелец один, но держит яйца в разных корзинах.

(7) "15 баз в одну" - о, госпади! в этом есть реальный профит?

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

(17) В чём профит? )

(17) "Есть" - отличный ответ, коллега)

(18), (19) Как бы покороче. В единообразии процессов, времени на обновление, на подготовку и сверку отчетности, управление активами (товары, дебиторка и т. п.), сводная задолженность по дебиторам и кредиторам и т. п. нематериальная и трудноизмеримая хрень-брень

(20) Трудноизмеримое = "мы сами не понимаем, зачем оно нам".

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

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

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

Пример - создание и выгрузка отчетов СЗВ-М в зарплатных базах. Создает отчеты, выгружает в один каталог, потом в СБИС грузим все файлы из этого каталога и отправляем одной кнопкой, экономится масса времени. Заодно выполняется анализ отчетов, благо, что отчет достаточно простой и формируется по понятным правилам.

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

(21) Ну, и нахер тратить время и деньги на обновлятор? Писать склеивающие обработки, когда можно совершенствовать сами отчеты? Через сколько после обнаруженной ошибки консолидированный отчет поправится? А формирование отчетности по заранее неизвестным фильтрам по неполному списку филиалов в любой момент времени и из любой точки мира? Можно конечно жить и по вашему принципу, но тогда отчет исправленный в течение часа сложно получить. А торговая сессия на бирже два-три часа всего.
Про регламентированный учет я написал уже своё мнение.

(22) "Ну, и нахер тратить время и деньги на обновлятор" 

900 рублей за вечную лицензию?

" Писать склеивающие обработки, когда можно совершенствовать сами отчеты? "

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

У вас вид деятельности не такой, как у нас, и вам наши методы не подходят, но посмотрите шире немного.Я поделился своим опытом, применимым к нашему виду деятельности, вы - к вашему.

(20) Это иллюзия. В сухом остатке профита будет немного и спорного, а проблем - ведром не вычерпать.

(21) А бекапы всех этих многочисленных баз вы делаете? Если делаете с какой глубиной? Проверки бекапов методом восстановления делаются?

+25, наверное в этом случае удобнее купить/сделать свой фреш, где данные в базе разделяются, и нет проблем потом с него "съехать", в случае необходимости.

(25) Конечно делаем, это же базы наших клиентов. Храним в течение года. Проверки бэкапов методом восстановления - не очень понял, о чем вы, и зачем это делать. Не админю.
(26) Возможно, но нам как-то удобнее на своем сервере все хранить.

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

Приходят клиенты со своими базами, кидать их во фреш в ту же базу? Не понял, в чем тут удобство.
Часть клиентов работает у себя и те проверки, о которых я писал в (21), легко применимы и к ним тоже.

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

И еще предлагающие всех в одну базу загнать - а монопольное насилие над данными клиента как тогда проводить? Всем остальным ждать? В общем, аргументы в пользу решения "загнать всех в одну базу, под одну гребенку"... это слабенькие аргументы.

(29) В нашем случае, все базы клиентов в отделе ведения учета - типовые без изменений и даже без расширений. Поэтому их легко обновлятором обновлять.

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

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

риб не поможет в данном случае? и слить потом номенклатуру-контрагентов?

(31) :-)

(32) тут нужно конкретизировать - что именно через РИБ предлагается в данном случае?

а вообще, попытки слияния с использованием РИБ и на Мисте в том числе были озвучены... Не удовлетворительные результаты оказались. Грубо говоря, трудоемкость не соответствует стоимости результата.

(34) Просто сейчас собираюсь тоже самое со своими базами провернуть, но там 2 базы почти чистых, просто надо на аудит отдать 2 компании. Создам потом свою тему с вопросами.

> Но они никак понять не могут настоящую причину, по которой мы их не сливаем - это не наши базы!

да это ясно, что базы не ваши, и что вы работаете в так называемой "аудиторской" компании.

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

(23) Дочитывать пост надо. Базы для фискальных органов соединять крайне не рекомендую по причинам озвученным выше. А вот для оперативного управления часто удобно держать всё в одной

(37) Так о том и речь. Я вам то же самое писал, надо было просто дочитать ))

(0) я бы сделал через обмен

(36) У нас не аудиторская компания. Впрочем, не понял, что вы хотели этим сказать..

(35) С выгрузкой на в базах на новых БСП - актуальных типовых, скажем так - там есть готовые обмены РИБ по Организации, как правило.
Обычно все работает нормально. Именно для аудита более чем достаточно выгрузить этим РИБ и ни о чем не думать.

Но это именно выгрузить, а не слить в общую.