здравствуйте, у нас такая беда, нужно слить в одну базу две организации, у нас присоединение компаний, люди со всеми своими договорами и всеми обязанностями переходят в другую ооо, как перекинуть (добавить) из одной ЗиК сотрудников, у нас их больше 40 человек, уже скоро зарплата и отпуска, больничные, помогите советами и какими обработками воспользоваться. Выгрузкой /загрузкой попробовали - вылетает что код не уникальный (спр.Записать();
{C:\DOCUMENTS AND SETTINGS\ADMIN\РАБОЧИЙ СТОЛ\А+ Ж\333333\IMPORT77.ERT(1474)}: Код не уникальный!), хотелось бы перекинуть справочник сотрудники, а также все начисления по ПФР для расчета пособий и отпуска, а так же НДФЛ. Заранее спасибо.
{C:\DOCUMENTS AND SETTINGS\ADMIN\РАБОЧИЙ СТОЛ\А+ Ж\333333\IMPORT77.ERT(1474)}: Код не уникальный!), хотелось бы перекинуть справочник сотрудники, а также все начисления по ПФР для расчета пособий и отпуска, а так же НДФЛ. Заранее спасибо.
По теме из базы знаний
- Пометка тестовой копии рабочей базы через механизм оповещений и раскрашивание форм (Управляемое приложение)
- Конструктор сравнения таблиц значения, в том числе из внешней базы
- Объединение баз ЗУП
- Обновление нетиповой конфигурации ЗУП одним махом через 19 релизов + решение глюков обновлений (памятка)
- Порядок слияния баз ЗУП 3.1, используя Конвертацию данных 2.1
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) 2011b11,
Для начала, разумеется потренироваться на копиях баз.
Если я не ошибаюсь в этом, то единственным путем мне видится объединение баз на уровне слияния файлов DBF, причем в одной из них надо перенумеровать ID всех объектов, чтобы не произошло наложения.
В-общем, работа сложная, долгая, нудная и совсем не для неподготовленных.
хотелось бы перекинуть справочник сотрудники
Ну, это не сложно: перенумеровать справочник в одной из баз обработкой Uchoice.ert, а потом выгрузить и загрузить его при помощи Tranref.ert.
Для начала, разумеется потренироваться на копиях баз.
а также все начисления по ПФР для расчета пособий и отпуска, а так же НДФЛ
А вот с этим желанием - дело плохо: если мне не изменяет склероз, записи журнала расчетов не переносятся, никак и ничем. Надо переносить все документы и проводить их, причем это не гарантирует идентичности результата.
Если я не ошибаюсь в этом, то единственным путем мне видится объединение баз на уровне слияния файлов DBF, причем в одной из них надо перенумеровать ID всех объектов, чтобы не произошло наложения.
В-общем, работа сложная, долгая, нудная и совсем не для неподготовленных.
(1) 2011b11,
навскидку:
бэкапы базы1 и базы2
если в базе1 "многолетний учет" - свернуть ее, оставить последние года 3-4 (как скажут в бухгалтерии)
перенумеровать все справочники и документы в базе1 (не меняя номер, меняя префикс - чтобы нумерация всяко-разных приказов не изменилась)
перенести (к примеру через OLE) все-все объекты из базы1 в базу2
вот и всё)
P.S. вам нужен специалист, имхо...;-)
навскидку:
бэкапы базы1 и базы2
если в базе1 "многолетний учет" - свернуть ее, оставить последние года 3-4 (как скажут в бухгалтерии)
перенумеровать все справочники и документы в базе1 (не меняя номер, меняя префикс - чтобы нумерация всяко-разных приказов не изменилась)
перенести (к примеру через OLE) все-все объекты из базы1 в базу2
вот и всё)
P.S. вам нужен специалист, имхо...;-)
(1) 2011b11, есть еще вариант: попробовать перейти на 8-ку, там есть загрузка из 7.7
загрузить из одной базы, потом попробовать из другой. надеюсь, при второй загрузке не будет ругаться и с табельными номерами должно нормально все пройти.
при загрузке идет заполнение и заработка с предыдущей программы, значит с журналом расчетов или документами не надо будет париться.
если ж выбирать все-таки 7.7, можно перенести сотрудников и потом для БЛ заполнить заработок с предыдущего места работы. с НДФЛ придется помучаться немного, возможно, его нужно будет собирать руками из двух частей(двух баз).
загрузить из одной базы, потом попробовать из другой. надеюсь, при второй загрузке не будет ругаться и с табельными номерами должно нормально все пройти.
при загрузке идет заполнение и заработка с предыдущей программы, значит с журналом расчетов или документами не надо будет париться.
если ж выбирать все-таки 7.7, можно перенести сотрудников и потом для БЛ заполнить заработок с предыдущего места работы. с НДФЛ придется помучаться немного, возможно, его нужно будет собирать руками из двух частей(двух баз).
как вариант:
1. отключить контроль уникальности кодов для справочника.
2. перенести справочник.
3. перенумеровать коды. хотя и не обязательно
4. включить контроль уникальности. опять же необязательно
либо подправить обработку что бы при записи генерировала новый код.
но тут нужно смотреть, может она ссылки именно по коду ищет.
бэкап базы сделали?
1. отключить контроль уникальности кодов для справочника.
2. перенести справочник.
3. перенумеровать коды. хотя и не обязательно
4. включить контроль уникальности. опять же необязательно
либо подправить обработку что бы при записи генерировала новый код.
но тут нужно смотреть, может она ссылки именно по коду ищет.
бэкап базы сделали?
"В-общем, работа сложная, долгая, нудная и совсем не для неподготовленных. " - и, скорее всего ненужная.
Если орг-я 1 закрывается - сотры переходят не переводом а через увольнение. И все отчеты по ним должна сдать орг-я1, а во второй начать с нуля.
Если орг-я 1 закрывается - сотры переходят не переводом а через увольнение. И все отчеты по ним должна сдать орг-я1, а во второй начать с нуля.
(9) dump,
Хотя, подчеркиваю, в обоих случаях на учет организация становилась как новая.
и, скорее всего ненужная
Это не нам с вами решать. И, скорее всего, это решать даже не автору ветки: у меня был случай, когда клиент реорганизовывался, менялась ОПФ со сменой ИНН и рег.номера в ПФ. Так одно из этих ведомств (ИФНС и ПФР) захотело две отчетности - до даты реорганизации и после нее, а другое - одну общую, с начала года.
Хотя, подчеркиваю, в обоих случаях на учет организация становилась как новая.
Крайне не рекомендую вам по зику сливать в одну базу, почему? Потому что там номерация сквозная и уникальная по журналам расчета, номера присваиваются записей расчета исходя из номеров первички. Если отключить контроль уникальности первички там такая каша потом получиться. Если сливать в одну базу подумайте о табельных номерах которые не лить и т.д. тут организационный момент нужен, перенесите справочники и остатки, прошлые периоды нельзя будет слить, нету таких методик ибо ссылки журналов расчета перемешаются с одинаковыми номерами и если даже удастся оптом поднять базу после краша при расчете, то у вас каша будет, чужие начисления по разным людям.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот