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

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

Может есть другие (более правильные) способы?
1 RomaH
 
naïve
31.05.18
07:26
Потом идет выгрузка с помощью обработки переноса данных в идентичную ИБ.
После идет уничтожение дублей соответствием по наименованию.

вот эти два пункта объединить
2 RomaH
 
naïve
31.05.18
07:27
и зачем в справочниках префиксы?  ... да и в документах
3 s202
 
31.05.18
07:28
(0) Это будет nиздец. Но ты держись.
4 K1RSAN
 
31.05.18
08:10
(2) Чтобы не было путаницы? Чтобы было видно, что эта номенклатура или документ пришли извне. Потому что не всегда удаление дублей сработает на 100%, там могут быть слегка другие наименования.
5 K1RSAN
 
31.05.18
08:13
(3) Главное, чтобы всё выгрузилось. А далее проблемы тех, кто решил в свое время разделить базу на 2 куска.
Единственный вопрос с счет-фактурами - надо будет всё тщательно проверить.
6 Фрэнки
 
31.05.18
08:13
летело N гусей...
не, N гусей малова-то будет - летело 2хN гусей

что вообще обсуждается?!
7 Фрэнки
 
31.05.18
08:14
я так думаю, что эти базы таки на 1С, но версия какая-то 6.0 или там 7.5, например?
8 DrShad
 
31.05.18
08:14
Юзай комментарии и пиши туда откуда пришло
9 K1RSAN
 
31.05.18
08:15
(6) Спрашиваю о методах слияния двух баз в одну. Организация одна и та же, но данные были разные (хз как и почему, поставили перед фактом)
10 K1RSAN
 
31.05.18
08:15
(7) Извиняюсь. Базы 8.3 Бухгалтерия.
11 DrShad
 
31.05.18
08:20
(9) какие еще могут быть методы?
анализируешь как и на сколько синхронизируются данные
пишешь правила в КД
сливаешь

в начале года 3 торговых БД, 6 бухгалтерских и 2 ЗУП - слил в одну УПП
все нормально и без префиксов, правда подготовка много времени заняла
12 DrShad
 
31.05.18
08:21
(10) и да, нет таких конфигураций
13 Сияющий в темноте
 
31.05.18
08:21
В двух базах могут быть одни и те же документы?
Если базы по филиалам,то не должно быть пересечений и,в принципе,можно успешно обьединить.
Если же базы себя дублируют,то лучше забить первичку вручную,чем навоз разгребать
14 Фрэнки
 
31.05.18
08:24
(10) конфигурации идентичные полностью и это какая-то версия БП3?

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

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

Можно в подчиненную выгрузить справочники, а затем там сделать замены. Перенос сам по себе универсальной обработкой можно, которая между идентичными базами работает без проблем.
15 DrShad
 
31.05.18
08:26
(14) [Перенос сам по себе универсальной обработкой можно, которая между идентичными базами работает без проблем]

можно конечно, но ведь она по гуидам переносит, а через КД можно в разы уменьшить количество дублей
16 Фрэнки
 
31.05.18
08:29
(15) тут будет важно для разработчика есть ли у него опыт практического использования КД. Вангую, что при наличии такого опыта он не стал бы задавать такой вопрос (как слить в одну) форуму.
17 DrShad
 
31.05.18
08:32
(16) без наличия такового  опыта - лучше не браться за такую работу
18 K1RSAN
 
31.05.18
08:48
(17) Делал простые обмены, изменял правила уже действующих обменах, но это по мелочи.
Ну и надо же на чем-то учиться.
(15) Тут осложняется тем, что вели разные люди. И если посмотреть справочники - там банально название по-разному могут занести. Один написал "АТФ Банк", второй "АТФБанк", и сиди думай, по какому полю их можно будет соотнести. Ну, допустим, разобрался с банками. А далее идут банковские счета - казалось бы можно синхронизировать по банку (если смог соотнести) и по номеру счета - но реальность такова что один и тот же счет используется разными контрагентами - а в контрагентах может быть та же ситуация, что и с банками, только вот банков десятки, а контрагентов сотни.
И думаешь, либо потратить кучу времени на всю эту фигню - или пусть бухгалтера сами избавляются от дублей так, как им надо
(13) В одной базе заведены документы по реализациям, во второй заведены там один документ итоговый за неделю, только чтобы числа пошли. А заводить первичку с нуля - ну хз, за 2 месяца захотят ли (чтобы с начала квартала).
19 DrShad
 
31.05.18
08:52
(18) [Один написал "АТФ Банк", второй "АТФБанк"] про БИК слышал?
20 unregistered
 
31.05.18
08:52
ИМХО, вариант автора можно использовать только если объем данных небольшой, а пользователи достаточно грамотные, чтобы суметь проверить результат объединения и выправить все косяки, коих останется огромное количество (включая некорректно удаленные дубли, которые на самом деле окажутся не дублями). Но при малых объемах возможно проще будет вручную забить первичку из одной базы в другую.

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

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

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

В любом случае лучший вариант зависит от конкретного набора данных в каждой из баз - насколько разошлись, насколько идентичны, как много данных наколочено после разделения, как много исходных (изначальных) данных менялось после разделения, какого рода данные вносили в каждую из баз (одинаковые или различные).
21 K1RSAN
 
31.05.18
08:52
(19) Ну я по БИКу и синхронизировал. Это просто для примера
22 DrShad
 
31.05.18
08:53
(19) [что и с банками, только вот банков десятки, а контрагентов сотни] ИНН+КПП, не ?
23 unregistered
 
31.05.18
08:55
(18) > пусть бухгалтера сами избавляются от дублей так, как им надо

Это обязательный подготовительный этап, которого не избежать.
Для каждого справочника/регистра сведений/документа необходимо будет определить правила нормализации (приведения к единому виду) - по кодам, по наименованиям, или по каким-либо еще критериям (полям, реквизитам, измерениям).
И пользователям придется сесть и ручками эти данные нормализовать.
24 K1RSAN
 
31.05.18
08:59
(22) К сожалению, это не панацея, есть контрагеты даже в одной базе, отличающиеся ТОЛЬКО наименованием. Банковские счета одинаковые - номер и банк, только сделаны 2 элемента, и договора по такому же принципу.

З.Ы. сначала подумал, что действительно удастся так сделать, спасибо за идею, но наткнулся на такие вот копии...
25 unregistered
 
31.05.18
09:00
(22) > ИНН+КПП, не ?

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

Это тоже часть подготовительной работы - выявить все проблемы в справочниках (дубли, неполноценные и пр. косяки) в исходных базах ДО слияния.
26 K1RSAN
 
31.05.18
09:08
(23) Осталось сказать бухгалтерам это...
27 Nikoss
 
31.05.18
09:13
еще момент про универсальную выгрузку - если она делает выгрузку по ГУИДам, а базы делались из одной, может получится так что одни объекты перетрут другие, т.к. ГУИДы одинаковые
28 unregistered
 
31.05.18
09:19
(27) Это к вопросу о том, что надо писать правила в КД, где все эти моменты по каждому объекту метаданных для каждой базы (источник/приёмник) можно уточнить - где затирать, где не менять, где новые создавать (делать принудительно дубли).
29 Nikoss
 
31.05.18
09:20
(28) на да, я это и имел введу
30 K1RSAN
 
31.05.18
09:21
(27) да уже понял) хорошо хоть, что конфигурация одна и та же, главное определиться по каким полям будет идти сравнение
(28) спасибо за советы
31 hhhh
 
31.05.18
09:30
(24) там не только наименования, информация может быть разная. Адреса, фамилии, телефоны. И тогда уже наступает (3). Потому что программист не может выбрать на основании своих ощущений, какой из адресов или телефонов правильный. А пользователи не помнят нихера. А какие-то пользователи уволились уже.
32 K1RSAN
 
31.05.18
09:31
(31) Контактная информация почти не ведется судя по тому, что я там увидел. Думается, что дублей таки будет достаточно много, постараюсь их хоть немного уменьшить
33 DrShad
 
31.05.18
09:32
(31) но и это еще ерунда - самое интересное начнется, когда начнут сравнивать ОСВ ))))
34 DrShad
 
31.05.18
09:33
+(33) не говоря уже об регистрах накопления и отчетности )))
35 hhhh
 
31.05.18
09:37
(32) как раз из-за этого двоякая ситуация: если один и тот же контрагент, но в двух городах расположен, или 2 офиса, то нужно сделать дубли. А если всё совпадает, то эти дубли наоборот убрать надо.
36 hhhh
 
31.05.18
09:39
(33) да если слить движения по двум контрагентам, то может получиться удивительный результат.

лучше вообще контрагенты не сливать, пусть с дублями работают,  хотя бы первые год-два после объединения.
37 DrShad
 
31.05.18
09:41
(36) да и это все ерунда, гораздо веселее по материальным счетам и счетам косвенных затрат
38 DrShad
 
31.05.18
09:41
+(37) а с ОСами тоже много приколов )))
39 DrShad
 
31.05.18
09:42
и ведь после всего этого еще нужно внести корректировки по ошибкам учета....
40 Обработка
 
31.05.18
09:50
(0)
1. Напиши обработку сравнения элементов спр по ГУИДУ. Оцени каков процент совпадений.
2. Напиши обработку сравнения спр по реквизитам кроме кода. Оцени процент совпадений и по каким реквизитам.
3. Сделай выводы по двум первым пунктам напиши КД и механизм синхронизации выбери и в зависимости от анализа.
4. ДАй списки спр или саму базу с указанием спр. юзерам чтоб они привели их в однотипные названия или реквизитыю
5. Сливай в одну.
6. удаляй двойников.
41 Serg_1960
 
31.05.18
09:57
Сливал базы. Сначала синхронизация справочников в автономных базах и только потом можно говорить о самом слиянии данных.

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

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

Далее КД, правила и само слияние с поиском по кодам... короче ничего интересного.
42 hhhh
 
31.05.18
10:06
(41) ну сам понимаешь, что если это одна организация, то в результате слияния всё полетит, и партионный учет полетит, и если нет партионного, то учет по среднему всё полетит, закрытия месяцев все переделывать по новой, взаиморасчеты с контрагентами полетят.
43 Serg_1960
 
31.05.18
12:45
(42) Не факт, есть слабая надежда что взлетит :) Учитывая фразу ТС "В каждой делается своя часть учета"(0)
44 K1RSAN
 
31.05.18
13:00
(43) Это очень странный момент. Каждый ведет свою часть учета, а чужую часть вводит "сторно" (так вроде это называется), в смысле вместо 10 реализаций он делает 1 документ, который сделает соответствующее движение денежных средств. Какова была цель такого существования - думаю даже бухгалтера уже не помнят
45 aka AMIGO
 
31.05.18
13:35
46 Serg_1960
 
31.05.18
15:57
(44) Почему бы и нет :( У нас, например, некоторое время прежде чем купить ЗУП, кадры и зарплату стали вести в отдельной базе, мигрируя в основную рабочую базу только сводные данные.
47 Фрэнки
 
31.05.18
18:49
(46) причем, можно и вообще заморочиться с дроблением - в каждой из баз должно быть сотрудников не больше заданного ограничения и все будет прекрасно работать, а в центральной отражать зарплату сводно.
48 K1RSAN
 
01.06.18
06:40
(46) а смысл так вести? Если и там и там бухгалтерия? Просто сеть провести, rdp или Линк? Это же сколько проблем из-за дроблений
49 kovalev_oleg
 
01.06.18
06:53
С предопределенными элементами в том числе плана счетов будут траблы, но это решаемо
Все так и делаю, уже много раз.
50 Мимохожий Однако
 
01.06.18
07:48
Надо выбрать одну базу за основную, долить туда недостающие справочники и вбивать вручную недостающие документы по первичке. Или переносить точечно документы по мере обнаружения нехватки в основной базе, если они соответствуют первичке. А изначально делать всю работу программисту на основании бесед с бухгалтерами и анализом базы - это бесконечный геморрой.
51 Mankubus
 
01.06.18
10:18
(44) не сторно, а сводно
52 Serg_1960
 
01.06.18
12:02
(48) Смысл есть для реализации защиты персональных данных. Эти данные были "физически" изъяты из общей базы и перемещены в другую базу с максимально ограниченным доступом (к самой базе и компьютеру базы).
53 K1RSAN
 
05.06.18
07:18
(52) Разве нельзя просто правами доступа реализовать всё необходимое? Хотя в 8.2 еще нет механизма профиля групп - но при желании настроить можно. А делить базу на куски - тоже имеет все основания превратиться в геморрой
54 Alexor
 
05.06.18
08:51
(0) Проверь, что бы базы были идентичные и настройки одинаковые.
Проблемы могут быть с предопределенными элементами.

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

Если база не большая и отчетность еще не сдавала похоже, то я за 1 пункт. Через ПоискиЗамену дублей, пробегая глазами, можно избежать ошибок объединения (ну например у разных контрагентов ИНН одинаковый или нет его, или наименование одинаковое, а контрагенты разные).
55 K1RSAN
 
05.06.18
09:53
(54) ну пока что задача отодвинута до конца месяца - потому у меня есть время поэкспериментировать.
Проблема есть в разных контрагентах с одинаковым ИНН - возможно придется глазами просто их высматривать. Переносить данные планируется начиная со второго квартала, остальное в случае необходимости будет доноситься ручками.
Ошибка? Это не ошибка, это системная функция.