Нужны советы в следующем - когда-то 1 база была разделена на две. Они НЕ РИБ. В каждой делается своя часть учета. Организация одна и та же. В итоге было решено их слить в одну ИБ. НО так как они не были как РИБ - у номеров нет префикса. Как лучше всего реализовать перенос данных в одну базу?

На данный момент план действий такой:
Для всех элементов справочников и документов (кроме счет-фактур) программно ставится префикс - запросом перебираются метаданные и заменяется первые 1-2 символа на нужный префикс.
Потом идет выгрузка с помощью обработки переноса данных в идентичную ИБ.
После идет уничтожение дублей соответствием по наименованию.
Далее пользователь избавляется от оставшихся дублей.

Может есть другие (более правильные) способы?

Потом идет выгрузка с помощью обработки переноса данных в идентичную ИБ.
После идет уничтожение дублей соответствием по наименованию.

вот эти два пункта объединить

и зачем в справочниках префиксы?  ... да и в документах

(0) Это будет nиздец. Но ты держись.

(2) Чтобы не было путаницы? Чтобы было видно, что эта номенклатура или документ пришли извне. Потому что не всегда удаление дублей сработает на 100%, там могут быть слегка другие наименования.

(3) Главное, чтобы всё выгрузилось. А далее проблемы тех, кто решил в свое время разделить базу на 2 куска.
Единственный вопрос с счет-фактурами - надо будет всё тщательно проверить.

летело N гусей...
не, N гусей малова-то будет - летело 2хN гусей

что вообще обсуждается?!

я так думаю, что эти базы таки на 1С, но версия какая-то 6.0 или там 7.5, например?

Юзай комментарии и пиши туда откуда пришло

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

(7) Извиняюсь. Базы 8.3 Бухгалтерия.

(9) какие еще могут быть методы?
анализируешь как и на сколько синхронизируются данные
пишешь правила в КД
сливаешь

в начале года 3 торговых БД, 6 бухгалтерских и 2 ЗУП - слил в одну УПП
все нормально и без префиксов, правда подготовка много времени заняла

(10) и да, нет таких конфигураций

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

(10) конфигурации идентичные полностью и это какая-то версия БП3?

Я бы попробовал сделать из будущей центральной базы подчиненный узел РИБ, а затем вторую базу подложить взамен его. После синхронизации будут дубли справочников - это само собой. Но дубли они в любом случае будут.

Но мало вероятно, что такой способ понравится. Нужно на конвертации, на КД перенос сделать.

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

(14) [Перенос сам по себе универсальной обработкой можно, которая между идентичными базами работает без проблем]

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

(15) тут будет важно для разработчика есть ли у него опыт практического использования КД. Вангую, что при наличии такого опыта он не стал бы задавать такой вопрос (как слить в одну) форуму.

(16) без наличия такового  опыта - лучше не браться за такую работу

(17) Делал простые обмены, изменял правила уже действующих обменах, но это по мелочи.
Ну и надо же на чем-то учиться.
(15) Тут осложняется тем, что вели разные люди. И если посмотреть справочники - там банально название по-разному могут занести. Один написал "АТФ Банк", второй "АТФБанк", и сиди думай, по какому полю их можно будет соотнести. Ну, допустим, разобрался с банками. А далее идут банковские счета - казалось бы можно синхронизировать по банку (если смог соотнести) и по номеру счета - но реальность такова что один и тот же счет используется разными контрагентами - а в контрагентах может быть та же ситуация, что и с банками, только вот банков десятки, а контрагентов сотни.
И думаешь, либо потратить кучу времени на всю эту фигню - или пусть бухгалтера сами избавляются от дублей так, как им надо
(13) В одной базе заведены документы по реализациям, во второй заведены там один документ итоговый за неделю, только чтобы числа пошли. А заводить первичку с нуля - ну хз, за 2 месяца захотят ли (чтобы с начала квартала).

(18) [Один написал "АТФ Банк", второй "АТФБанк"] про БИК слышал?

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

Верный вариант только в (11) от DrShad
Любые другие либо породят слишком много ошибок (не все из которых удастся выявить в ходе проверки - скрытые ошибки), либо результат будет вообще неработоспособным.

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

Кстати говоря, если в обе базы били значительное количество одинаковых данных, то можно поставить вопрос о некоем гибридном варианте. Например, часть данных, которые вносили только в БД2 и НЕ вносили в БД1, перенести в БД1 собственными самописными правилами или универсальной обработкой (не суть важно). Какие-то проблемные данные (сложно написать правила или данные менялись в БД2 после расщепления исходной базы) перенести вручную.

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

(19) Ну я по БИКу и синхронизировал. Это просто для примера

(19) [что и с банками, только вот банков десятки, а контрагентов сотни] ИНН+КПП, не ?

(18) > пусть бухгалтера сами избавляются от дублей так, как им надо

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

(22) К сожалению, это не панацея, есть контрагеты даже в одной базе, отличающиеся ТОЛЬКО наименованием. Банковские счета одинаковые - номер и банк, только сделаны 2 элемента, и договора по такому же принципу.

З.Ы. сначала подумал, что действительно удастся так сделать, спасибо за идею, но наткнулся на такие вот копии...

(22) > ИНН+КПП, не ?

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

Это тоже часть подготовительной работы - выявить все проблемы в справочниках (дубли, неполноценные и пр. косяки) в исходных базах ДО слияния.

(23) Осталось сказать бухгалтерам это...

еще момент про универсальную выгрузку - если она делает выгрузку по ГУИДам, а базы делались из одной, может получится так что одни объекты перетрут другие, т.к. ГУИДы одинаковые

(27) Это к вопросу о том, что надо писать правила в КД, где все эти моменты по каждому объекту метаданных для каждой базы (источник/приёмник) можно уточнить - где затирать, где не менять, где новые создавать (делать принудительно дубли).

(28) на да, я это и имел введу

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

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

(31) Контактная информация почти не ведется судя по тому, что я там увидел. Думается, что дублей таки будет достаточно много, постараюсь их хоть немного уменьшить

(31) но и это еще ерунда - самое интересное начнется, когда начнут сравнивать ОСВ ))))

+(33) не говоря уже об регистрах накопления и отчетности )))

(32) как раз из-за этого двоякая ситуация: если один и тот же контрагент, но в двух городах расположен, или 2 офиса, то нужно сделать дубли. А если всё совпадает, то эти дубли наоборот убрать надо.

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

лучше вообще контрагенты не сливать, пусть с дублями работают,  хотя бы первые год-два после объединения.

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

+(37) а с ОСами тоже много приколов )))

и ведь после всего этого еще нужно внести корректировки по ошибкам учета....

(0)
1. Напиши обработку сравнения элементов спр по ГУИДУ. Оцени каков процент совпадений.
2. Напиши обработку сравнения спр по реквизитам кроме кода. Оцени процент совпадений и по каким реквизитам.
3. Сделай выводы по двум первым пунктам напиши КД и механизм синхронизации выбери и в зависимости от анализа.
4. ДАй списки спр или саму базу с указанием спр. юзерам чтоб они привели их в однотипные названия или реквизитыю
5. Сливай в одну.
6. удаляй двойников.

Сливал базы. Сначала синхронизация справочников в автономных базах и только потом можно говорить о самом слиянии данных.

Справочники типа "Контрагенты" не доставили проблем - они просто обязаны слиться по ИНН/КПП :) Написал обработку, которая помогала юзверям выявить одинаковых контрагентов по ИНН/КПП, но разных по наименованиям и "наоборот"(когда похожие наименования у контрагентов с разными ИНН/КПП) - пусть сами между собой разбираются какое наименование "правильное" и у кого какое ИНН/КПП.

Более подробно на примере справочника "Номенклатура":
- используя префиксы, изменил коды записей так, чтобы они стали уникальными в обеих базах;
- для автоматизации синхронизации написал обработку, которая, используя различные варианты неявного(нечеткого) поиска по наименованию, определила соотношение найденных/не найденных соответствий (примечание: вместо этого можно использовать полнотекстовый поиск);
- когда добился приемлемых результатов - изменил коды на равные у соответствующих друг другу записей. Не найденные записи (их было всего пара десятков) - ручками исправили юзверя.
- ещё одна обработка потребовалась в помощь юзверям для "самоопределения" между собой какое из наименований оставить у найденных позиций.

Далее КД, правила и само слияние с поиском по кодам... короче ничего интересного.

(41) ну сам понимаешь, что если это одна организация, то в результате слияния всё полетит, и партионный учет полетит, и если нет партионного, то учет по среднему всё полетит, закрытия месяцев все переделывать по новой, взаиморасчеты с контрагентами полетят.

(42) Не факт, есть слабая надежда что взлетит :) Учитывая фразу ТС "В каждой делается своя часть учета"(0)

(43) Это очень странный момент. Каждый ведет свою часть учета, а чужую часть вводит "сторно" (так вроде это называется), в смысле вместо 10 реализаций он делает 1 документ, который сделает соответствующее движение денежных средств. Какова была цель такого существования - думаю даже бухгалтера уже не помнят

https://www.youtube.com/watch?v=dqzlFKw1dSw

(44) Почему бы и нет :( У нас, например, некоторое время прежде чем купить ЗУП, кадры и зарплату стали вести в отдельной базе, мигрируя в основную рабочую базу только сводные данные.

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

(46) а смысл так вести? Если и там и там бухгалтерия? Просто сеть провести, rdp или Линк? Это же сколько проблем из-за дроблений

С предопределенными элементами в том числе плана счетов будут траблы, но это решаемо
Все так и делаю, уже много раз.

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

(44) не сторно, а сводно

(48) Смысл есть для реализации защиты персональных данных. Эти данные были "физически" изъяты из общей базы и перемещены в другую базу с максимально ограниченным доступом (к самой базе и компьютеру базы).

(52) Разве нельзя просто правами доступа реализовать всё необходимое? Хотя в 8.2 еще нет механизма профиля групп - но при желании настроить можно. А делить базу на куски - тоже имеет все основания превратиться в геморрой

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

А так 3 пути:
1. Через универсальную выгрузку загрузку и потом чистить дубли.
2. Через КД. Правила заполняются автоматом, только выставить реквизиты поиска у элементов.
3. Переносить все руками.

Если база не большая и отчетность еще не сдавала похоже, то я за 1 пункт. Через ПоискиЗамену дублей, пробегая глазами, можно избежать ошибок объединения (ну например у разных контрагентов ИНН одинаковый или нет его, или наименование одинаковое, а контрагенты разные).

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