Объединение нескольких баз БП 2.0 в одну #722090

Суть в том что существует 10 баз БП 2.0 все приведены к единому релизу сейчас потребовалось их объединить в одну. Кто с такой задачей связывался и какие могут быть подводные камни?

как собираешься объединять ?

насколько пересекаются данные? а вообще - КД в руки и вперед.

Пробовал через выгрузку загрузку данных в формате XML тогда задваиваются справочники валют и обычной обрабокой поиск и замена значений не могу их заменить в целом данный вариант устраивает но справочники валют напрегают

см. КД тебя спасет.

А движение документов она перетянет чтобы их не трогать?

движение документов обязательно надо трогать.

А вообще какие могут быть подводные камни?

Что необходимо после переноса проверить где могут быть дубли или же где то могут измениться какие то движения?

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

зачем их трогать ?

Прежде чем объединять базы нужно проверить настройки учета. Так как они задаются для БД, а не для организации. Может случиться так, что объединять будет нельзя. Потом проверять учетную политику, общие важные НСИ - валюты, контрагенты вычищать, подразделения, статьи затрат, ном. группы. Потом ОСВ сравнивать - убежали или нет остатки и обороты. Короче, это дело очень темное, и нужно быть твердо уверенным, что нужно переносить все с движениями. Я бы объединила остатками на начало какого-то периода. А эти оставила как архив для использования

вообще геммор еще тот. Однозначно писать свои правила. При этом например контрагент. Надо поиск по наименованию деалть? Как бы не так. В одной базе будет ООО "Василек" инн 5555222555, а в другой - ООО "Василек" инн 222666999. Делать по ИНН? хрен вам: пользователи ИНН не ввели ("а зачем, это же покупатель а не поставщик"). В общем, однозначно после переноса останутся дубли контрагентов, договоров, сотрудников и т.п. Так что мне очень нравится решение : вводить остатками в новой базе. Тут и с 2,0 на 3,0 перейдете заодно)

учётка идёт по юрикам, контрагентов/статьи перезаменить

ну заведётся два контрагента и ужасного, если это можно будет руками перезаменить ? ведь от ручной проверки не уйти никак...

Просто перетащить справочники и чтобы ввели начальные остатки это супер но бухи их будут править до закрытия года, так что танцы будут до сдачи годовой отчетности

проблема в том, что многие гл.бухи встают в позу "ты программист - вот и выправляй данные". А там 100500 дублей.

В принципе бухи наоборот хотят чтобы контрагенты у каждой организации были свои и обычной обработкой выгрузка загрузка данных в формате XML и как она перетащила движения бухов устроило но там один вопрос как заменить рубли принудительно и оставить только один элемент рубли

Просто при попытки заменить валюту в договорах вылетает ошибка что есть документы проведенные по данному договору

какие проблемы ? почасовая оплата

давай вам перенесу всё

Варианты: Первый: 1. Привести в единообразие НСИ во всех базах (контрагенты, валюта, статьи ДДС и т.д. и т.п) 2. Сливать все в одну базу с помощью КД (лучше остатками, как посоветовали выше) Второй: 1. Сделать для новой БП РИБ, загрузить в нее единообразную НСИ, обеспечить миграцию НСИ во всем пространстве РИБ. 2. Загружать каждую базу в свой узел РИБ с помощью КД. 3. После окончания всех загрузок настроить полную миграцию в центр. Пока грузим, можем вести учет в узлах. 4. Получаем в центре все данные, отключаем РИБ, ведем учет только в центре.

Объединял четыре базы бухгалтерии 7.7 в одну БП 2.0. Сначала каждую базу в свою БП 2.0. Потом создал полные правила обмена, чуть-чуть их дописал и слил все в одну базу. Кое-чего поправилось обработками потом, кое-чего руками. В целом - нормуль.

нам бы твои проблемы. Ну вставь там строчку в Поиск и замену значений, где запись: или проверь, может она там уже есть.

+ можно еще при загрузке в каждый узел РИБ использовать РС "Соответсвие объектов для обмена", предварительно нарисовав формочку для удобного сопоставления НСИ из текущей базой и единообразной НСИ. То есть выгляди так: есть единообразная НСИ, гуляет по РИБу. Берем текущий филиал, из него выгружаем НСИ по отдельным правилам. Загружаем в соответсвующий узел РИБ, ничего не создаем, а только заполняем РС (или свою какую-нибудь таблицу). Далее юзеры проставляют соответсвия типа ООО "Вася и сыновья" = ООО "Василий и дети". Потом уже выгружаем основные данные.

как сложно придумал

В твоем случае я бы сделал так: 1. Проанализировал список РН, РС, РР, которые будут выгружаться. 2. Проанализировал все объекты ссылочного типа из первого списка. 3. Для всех объектов из пункта 2 написал бы правила выгрузки в КД. Правила написать таким образом, чтобы при выгрузке объекты не создавались, а заполнялась некая таблица значений (или РС "Соответсвий объектов"), но ТЗ предпочтительнее, кмк. В ТЗ попадают все объекты, не найденные по назначенным в правилах ключевым полям поиска. 4. Выгружаем по этим правилам из первой базы. Сажаем юзеров сопоставлять ненайденные объекты. 5. На основании первых правил пишем вторые, уже для основной выгрузки данных. Правила пишем так, чтобы выгружаемый объект подменялся на сопоставленный (в случае наличия такого сопоставления). Еще правила пишем так, чтобы источником выгрузки были регистры, а все остальные объекты из измерений подтягивались рекурсивно (таким образом можно избежать выгрузки мусора). 6. Выгружаем. Проверяем. 7. Берем следующую БП, повторяем для нее все с пункта 4. Можно сделать одновременное сопоставление для всех БП, но тогда: 1. Все объекты из пункта 2 должны быть единообразны и уже лежать в БП-Приемнике. 2. Таблица соответствий для каждой БП должны быть своя. З.Ы. Хранить ТЗ соответсвий можно в самой БП-Приемнике - в любом объекте, где есть ресурс ХранилищеЗначений.

я просто как раз сейчас решаю такую задачу (50 ЗУПов консолидирую) и изложенная схема уже себя оправдывает... Еще нюанс - советую перед выгрузкой убедиться в уникальности ГУИДов во всех ИБ... Совет не праздный... Неизвестно, как там учет велся, что и как загружалось в исходные базы... У меня была ситуация, когда в рамках одного объекта в одной ИБ были одинаковые ГУИДы, так как кто-то до меня криво загрузил два справочника в один... (в режиме ОБменДанными.Загрузка = Истина, получается, возможно задублирование ГУИДов)

Спасибо всем буду ковырять дальше

Благо время ещё до конца года есть может все таки бухи и решат сделать ввод начальных остатков