Решил свернуть базу (RA328 уже 1 750 000 000). Со сверткой Центральной базы проблем вроде нет, неоднократно проверена.
А вот создать новые периферйики - долгий процесс (из-за пересчета итогов при загрузке выгрузки в ПБ первый раз)
Идея сделать одну а остальные 5 клонировать. Но надо же в таблицы которые непосредственно для УРБД
правильно записать данные (что в ЦБ что во всех ПБ).
Подскажите как правильно сделать?

(0)
Да легко.
1)Копия базы (теперт считаем, что это наша периферийка)
2) в 1sdbset текущей ставим 'M', у центральной 'P', остальные удаляем
3) в 1ssystem  dbsign меняем на код текущей
4) чистим 1supdts
5) чистим 1sdwnlds
6) Обмен ЦБ-ПБ-ЦБ
7) не забудь сменить префикс (намедни забыл, сильно матерился.)
8) отсылай пиво почтой
©@Mikeware

(1) 2) в 1sdbset текущей ставим 'M', у центральной 'P', остальные удаляем. M и P английсие конечно?
То есть вообще ничего не надо выгружать и загружать?
Просто копии раскидать и в ЦБ и во всех ПБ очистить 1supdts 1sdwnlds ну и заменить код в систем
Есть как бы два вида документов которые только "место создания и центр" - чеки и затраты.
Есть несколько справочников которые миграция "место создания" и их в ЦБ нет вообще от других ПБ, а есть только для ЦБ

Да, благими намерениями вымощена дорога известно куда

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

(2) это инструкция, как из ЦБ сделать ПБ

сделать из ПБ еще ПБ..еще проще

(5) Для при одинаковости правил миграции для всех ПБ это точно.
Зря я выходит мудрил с праивлами миграции у объектов. И потом всегда русске буквы использовал в кодах и названиях ПБ.
Ладно. Надо сначала будет все по-старому сделать. Хотя с другой стороны можно же создать одинаковые и потом удалить из них все лишнее с учетом условий для каждой базы. Хотя если скажем у РКО - место создания и центр, то если я удалю из как ыб ПБ все что ее не касается как ыб все это на фиг не удалилось и в ЦБ и амба тогда.

(6+) Значит надо удалять из 1supdts. Ну вот да, дожился, озадачился. Леь тратить часы на ерунду когда можно потратить несколько часов на мозговую деятельность и не творить многочасовую рутину

(6) ё..упдс очистил и привет, и никто никуда не полетел

(8) Очистил упдтс или удалил и потом само создастся?

(9) delete from 1supdts.dbf

(10) ясно удалить все записи pack или ZAP

(11) Да просто удалить табличку. И зайти монопольно

(12) Еще что-то надо сделать с регистром Заявки. RG намного больше RA. Я закрыл его но совсем недавно. Ну ладно регистр "Резервы" еще понятно - нужен и остатки по нему, но резервы более-менее закрывались. Может вообще убить файлы RA и RG по регистру заявок. Ну и пусть заново формируются? Буду за квартал проводить ну опять немного подрастет но с нуля. Равно как и регистры Книга покупок и продаж. Ведь тоже самое - я их не закрываю в торговле - все только в бухгалтерии. Ну и из регистра партий уберу ЦенаПрод. Она все равно используется.
Интересно что мой супер крутой сервер 2013 года работает мделеннее чем обычная моя новая рабочая станция с 8 ГБ оперативки и хдд без всяких ССД.

если "со сверткой центральной базы проблем вроде нет, неоднократно проверена" -- то вообще не вижу проблем и причин огород городить.
0) документы ввода остатков - б/миграции ("только место создания")
1) сделать полную синхронизацию баз ("полный" обмен цб-пб-цб)
2) в обработке свертки - перед каждым изменением данных(док,спр) вставить ".РегистрацияИзменений(0);"
3) выполнить обработку свертки во всех базах - параллельно, автономно, монопольно и "одновременно".
в итоге получатся свернутые корректно данные без всяких монструозных обменов (и без потерь немигрирущих данных в периферийках).
те периферийки, которые на вменяемых серверах - свернуть прямо "на месте" (параллельня свертка с дикой экономией времени и обменов); которые на невменяемых - забрать на норм.сервак, свернуть на нем и вернуть свернутое обратно.
делал неоднократно так - получалось быстрее, безгиморнее и безошибочнее прочих (не считая, возможно, "вылизанных" до нечеловеческого блеска сверток на прямых запросах).

(14) Спасибо. Я просто уже полльзуюсь много времени обработкой Свертка ИБ. Я даже чего-то в ней под себя модифицировал когда-то. Проблема в том что яплохо владею логистикой УРБД. Ну в смысле сделать всякие подмены в базах 1sdbset 1swndls ну и в 1ssystem, ну и возможно хоть по ОЛЕ как-то выправлять в нужную мне сторону  1supdts.

(13) Все заявки, независимо от их вида - неподтвержденная или на склад или на поставку - НАДО ЗАКРЫВАТЬ. регулярно. ровно тогда когда заявка признана мертвой/потерявшей актуальность

(16) Ну вот резервы регулярно закрывались. А заявки - да прозевал их. Теперь закрыл, но все равно РГ распух

(16) Ну вот другое - миграция как бы настроена двумя группами + справочники некоторые заполняются отдельно на каждой ПБ. Сделал копию, поменял (как ЕПРСТ написал - чтобы вроде как получились ПБ затем удалить из ПБ то что их не касается на самом деле. Вот теперь буду экспериментировать до упора

(17): ну так какой он распухший до закрытия был - такой и останется, старые-то итоги останутся в нем не исправленными (не закрытыми). просто в дальнейшем при открытии периодов в таблице итогов регистра будет меньше (записей) итогов добавляться...

(18): почему не (14) то? и - лишнего точно не удалил? а мусора точно не оставил? а итоги пересчитал? а оно сошлось? а зачем тебе столько геморроя?

(20) Вот как раз ничего не удалял. БУду экспериментировать когда все образуется - и магазины заработатют на свернутой базе. Пока создаются заново периферийки из свернутой базы ЦБ. Долго нно как-то надежнее и не первый год так - но конечно совершенно неоптимально

(17) в принципе, возможно он и не нужен, достаточно часто можно его вообще удалить и оставить только резервы

(20) Да я бы документ который все остатки аккумулирует сделал бы - место, но как быть с партиями. Ведь свертка меняет приходный документв справочнике партий. Ну вот зачем они партии в такм виде приудмали? Куда правильноее быдо ыб как в 8-ке - по документу расчета партионный учет вести. Ну по ДатаПартии соответственно в регистре ПартииНаличие - остатки

(23)+ Место создания - миграция.ю нет проблем если б не регистр партий в который ССылка на этот сводный документ как приходный документ теперь установилась. Если так на каждой периферийке - каша получится в результате первого же обмена.