Привет всем. Сложилась такая ситуация: две компании объединяются, в каждой БД примерно по 500 сотрудников. А вот как мне объединить 2 БД в одну и что бы там все информационные данные по сотрам были и ЗП и все выплаты за 2 года, ну и все такое вытекающее. Оставить 2 БД не вариант, бухи и расчетчики поднимут вой, по то что им нужна общая среднесписочная ну и все отчеты по одной БД.
По теме из базы знаний
- Вопросы разработки, анализа производительности и оптимизации приложений 1С под управлением СУБД ORACLE
- Объединение организаций в ЗГУ (ЗУП) 3.1 при реорганизации (слияние, присоединение)
- Упрощаем разработку взаимодействия с СУБД в http-сервисах OneScript
- Объединение организаций в ЗУП при реорганизации с переносом данных из ЗУП 2.5 в ЗУП 3.1
- Автоматическое сравнение-объединение баз данных с мини-конфигурацией
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) evgaid, Если перевод идет через увольнение из одной и приём в другой, то объединять (в полном смысле слова) не только не нужно, а скорее нельзя... (из-за дальнейших проблем, если учет останется на 77). Перенос сотрудников - да, но не более. Выплаты за 2 года по уволенным (в полном смысле этого слова) не нужны. Стандартный приём и справка с предыдущего места работы. Вот автозаполнение справок - не вопрос, остальное лишнее.
(1) evgaid, (3) Cooler,
Выгрузка данных из ХML и загрузка данных в XML проводят новый документы, но потом тащат выгруженные записи расчетов. При нормальном ( не аварийном завершении работы ) и записи тоже перенесутся. Лично я вижу такое решение проблемы при условии что базы идентичны на уровне md-ников.
Сначала установка префиксов для каждой базы. Чтобы не было случайных пересечений.
затем конфигурация "конвертация Данных. Автонастройка правил обмена." Ну и выгрузка, загрузка через XML в одну из двух баз. Готов взяться за эту задачу.
Выгрузка данных из ХML и загрузка данных в XML проводят новый документы, но потом тащат выгруженные записи расчетов. При нормальном ( не аварийном завершении работы ) и записи тоже перенесутся. Лично я вижу такое решение проблемы при условии что базы идентичны на уровне md-ников.
Сначала установка префиксов для каждой базы. Чтобы не было случайных пересечений.
затем конфигурация "конвертация Данных. Автонастройка правил обмена." Ну и выгрузка, загрузка через XML в одну из двух баз. Готов взяться за эту задачу.
(1) evgaid, сдается мне, что вы ни разу не расчетчик и понятия не имеете, какие данные понадобятся для расчета зарплаты. А посему идеально начать в чистой базе (и 100% брать 8ку, про 7.7 забыть т.к. сейчас стооолько новых законодательных наворотов, что на 7.7 могут оставаться, только если численность до 50 чел). Дальше либо кидаете фронт работы на расчетчиков (7.7 оставляете для подглядки), и у них встанет все на автомат в худшем случает через 2 года, либо приглашаете не просто 1Сника, а набившего руку на переносах по зик. Хотя... в любом случае надо приглашать 1Сника, хотя бы для первичной настройки надбавок и вообще посмотреть, может у вас и базы были допиленные.
Если мне не изменяет склероз, то записи журналов расчета не переносятся при выгрузке-загрузке. Соответственно, просто выгрузить все данные из одной базы и подгрузить в другую не получится - придется перепроводить все загруженные документы. И не факт, что результат проведения совпадет с исходным.
Если базы DBF, то как вариант видится программа на чем-то типа FoxPro или даже обработка на 1С, подменяющая ID всех объектов в копии одной из баз с последующим слиянием их на уровне файлов DBF.
Но и в этом случае подводных камней может вылезти немерено, например, в случае дублирования сотрудников.
В-общем, работенка эта, по моим понятиям, потянет в лучшем случае на пятизначную сумму.
Если базы DBF, то как вариант видится программа на чем-то типа FoxPro или даже обработка на 1С, подменяющая ID всех объектов в копии одной из баз с последующим слиянием их на уровне файлов DBF.
Но и в этом случае подводных камней может вылезти немерено, например, в случае дублирования сотрудников.
В-общем, работенка эта, по моим понятиям, потянет в лучшем случае на пятизначную сумму.
"две компании объединяются" - это как? создается 3-я новая? сотры из одной переводятся в другую? или все-таки увольняются?
я бы оставил эти 2 базы и для новой компании перенес только справочники.
я бы оставил эти 2 базы и для новой компании перенес только справочники.
согласен с (4), в любом случае "объединение" - это новая третья фирма или одна "вливается" в другую?
в первом случае новая база - с импортом справочников, во втором - перенос справочников и документов и пересчет по "втянутой" фирме с проверкой и корректировкой, если что-то "пошло не так"...
в первом случае новая база - с импортом справочников, во втором - перенос справочников и документов и пересчет по "втянутой" фирме с проверкой и корректировкой, если что-то "пошло не так"...
Радикальное решение: перенести данные из двух ЗиК 7.7 в одну ЗУП 8. Мне кажется, это оправданно для двух крупных компаний, и руководство будет в восторге от отчетов.
Также есть случай, когда учет ведется в большом количестве разных баз ЗУП, а потом данные собираются в одну общую, где строятся нужные отчеты.
Также есть случай, когда учет ведется в большом количестве разных баз ЗУП, а потом данные собираются в одну общую, где строятся нужные отчеты.
(5) ptica-voron,
перенести данные из двух ЗиК 7.7 в одну ЗУП 8
Тут всё сильно зависит от уровня кастомизации "семерок". Хотя вариант 77->2.5->3.0 вполне рабочий (при условии, что это "Ваш огород"). Вариант 7.7->3.0 с большой вероятностью намного более трудоёмок.
Абсолютно оправдано, что не нужно сливать их вместе, достаточно перенести сотрудников из одной организации и принять их на новое место работы с переносом данных о среднем заработке и выплатах страховых взносов. Так как я работаю с зуп 2.5 и плохо знаю регистры и учет зик, то я бы перевел бы обе базы на 8 типовыми средствами, а затем бы перенес сотрудников, либо в крайнем случае перенес бы полностью данные, с учетом того, что Головной Организацией является одна из организаций, а обособленным подразделением Другая. То тут конечно же лучше специалист, который занимается 7.7, так как правильно говорится, если работает, то нетрожь.
(19) evgaid, есть еще такой документ: "данные с предыдущего места работы за 2 года".
туда можно залить готовые годовые суммы по каждому сотруднику. для начисления больничных к примеру. чтоб не тащить все начисления за прошедшие 2 года.
туда можно залить готовые годовые суммы по каждому сотруднику. для начисления больничных к примеру. чтоб не тащить все начисления за прошедшие 2 года.
(22) evgaid, если у вас идет увольнение и прием во вторую организацию. То тут только ввод первички делайте! А базу с уволенными сотрудниками оставьте бухам пусть открывают и настольгируют сколько угодно! Простая логика! В новой компании они еще не работали, а уже 3 года как зп получали?) Думаю теперь и буху будет ясно, что так не делается, а вот первичку перенести не проблема. Только обработку нужно найти или написать.
А вот как вариант если оставить 2 БД, одну потом просто переименовать, все расчеты вести в двух БД, то можно ли столкнуться с отчетностью в фонды (ПФР, Налоговая) из двух БД??? Отчетность сдаем через Контур?
(23) evgaid, не "можно", а обязательно столкнётесь. Переносите сданные по сотрудникам и не в коем случае не пытайтесь переносить остатки. Намучаетесь с последствиями. Лучше автоматизируйте процесс принятия новых сотрудников на работу, как вам уже посоветовали в (18). Даже если переход будет оформляться через перевод, то, насколько я помню, в ЗиК есть возможность оформить сотрудника по переводу. Автоматизируйте заполнение документов по оформлению новых сотрудников, если готовы взять на себя ответственность за это. Я бы на вашем месте настаивал на том чтобы оформлением документов о переводе/принятии на работу в конечной базе занимались кадровики, а сам бы перенёс только справочные данные по сотрудникам.
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот