JBoy,

Нет здесь простого и легкого способа - чтобы существующие автономные базы объединить в одну распределенную.
Номенклатура в магазинах скорее всего похожая, поставщики в основном те же. А внутренние идентификаторы объектов таковы, что при простом объявлении существующей базы "периферийной" в ЦБ начнется борьба одних объектов за уничтожение других - с теми же идентификаторами, полученными когда-то в другой базе

Этапы примерно такие:
1. Развести в существующих базах нумерацию документов - ввести префиксы, если они еще не используются, перенумеровать все существующие.
2. Решить, как вы будете объединять справочники. По кодам - бессмысленно, по наименованиям? тогда начинать единообразить наименования товаров и контрагентов - в каждой торговой точке. Так , чтобы одинаковая номенклатура/контрагенты из разных баз имели шансы слиться в один элемент справочника при объединении. Про более мелкие справочники тоже не забывать. Можно, конечно, и потом, в объединенной базе сливать элементы справочников,оказавшиеся разными - но тогда такая работа не имеет шансов закончиться. Что-то здесь и автоматизировать можно - хотя бы по минимуму, очистив наименования от ведущих и двойных пробелов.
2.1 и продумать, как и где в дальнейшем ваши справочники будут пополняться, в условиях распределенной базы - чтобы дублирования элементов избежать

3. Определиться со схемой миграции данных. Исходя из этого породить пустую систему из центральной и периферийных баз. С префиксами, которые рабочие базы, пока еще автономные, уже используют.
4. начинать заливать данные из рабочих баз в периферийные - через XML (так, чтобы в правилах переноса было отражено, что вы там решили в п.2), или любым другим доступным вам способом. Для каждой действующей базы - своя периферийная в будущей системе, куда её данные заливаются.
5. Смотреть, что при этом получается в центральной базе - с объединением справочников. Если получается плохо - пересматривать и корректировать все пункты плана, начиная с 2.
6. Когда начнет получаться с объединением - моделировать текущую работу в этой системе: как там происходит миграция данных, ожидаемо - или надо дорабатывать решения из п.3. Можно, впрочем, и раньше моделировать - даже тогда, когда справочники объединяются плохо.

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

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

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

JBoy,

Есть еще один способ - через прямую правку полей в sql-таблицах, потенциально быстрый:
Если:
- не ставить задачу слияния элементов справочников из разных баз при объединении
- и структуры данных в каждой автономной базе идентичны на (т.е. бинарно идентичны все 1cv7.dds)

то можно сделать следующий финт:
1. придумать для каждой базы префикс РБД
2. sql-скриптом записать значение этого префикса в 1ssystem и в во все ссылочные поля всех таблиц БД. Это не то первые три, не то последние три символа каждого такого поля. Где эти три символа в полях типа "Документ" или "Справочник" (любого типа) - надо уточнить.
3. породить пустую схему из нужного количества баз с теми же префиксами, и перенести из них в действующие базы заголовок периферийной базы в 1ssystem и 1sdbset
4. пометить все объекты в каждой базе для выгрузки (sql-скриптом заполнить маркерами объектов таблицу 1supdts, или простой обработкой 1с все объекты перезаписать)
5. сделать выгрузку изменений из каждой БД (которые в п.4 стали периферийными),и загрузку их в центральную.

Все.

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

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

Об этом уже написал:
Собрать несколько баз в распределенную несложно - но при условии абсолютной идентичности их структуры, при бинарно-идентичных 1cv7.dd(s).
Добавить префикс надо очень тщательно - во все идентификаторы объектов и во все ссылки на них, включая 1sjourn, ключи в ТЧ документов, регистровые движения и остатки, а также 1sconst,1sblob,1scrdoc

А добавить все объекты в 1supdts - самое простое здесь - даже никаких удаленных объектов здесь еще нет, и все ссылки абсолютно единообразны.
А можно еще проще заполнить ЦБ - как только Ид объектов во всех базах сделаны уникальными присвоением префиксов - сделать дамп всех таблиц из рабочих баз, кроме 1ssystem 1dbset 1supdts 1sdwnlds - и эти дампы залить в ЦБ.

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

Технически это такой подход очень прост и быстр. Но практика показывает, что как только новая база начнет работать - "наведение порядка" происходит очень вяло, и может никогда не закончиться

JBoyзначит 1-м вопросом по слиянию баз в урбд надо поставить достижение идентичности имен полей таблиц? все же наверное перелив в пустую ПФ через хмл обмен наиболее прост в реализации

именно так

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

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