Здравствуйте! Сливаю две базы ЗУП. Релизы одинаковы.
Создал ФизЛиц(400 штук), дальше создаю Сотрудников. Создавать их получается , в консоли запросов вижу. А в списке сотрудников они не появляются. Пожалуйста , подскажите , в каких ещё местах нужно прописывать сотрудников, чтобы они появились в списке?

По теме: не вижу "проблем" с совместителями. Внутренние - так и останутся внутренними. Чужие внешние - то же самое.
Остаются только перекрёсты:
1. Основной в новой и внешний в старой:
Станет внутренним в новой
2. Основной в старой и внешний в новой:
Внешнего трансформируем в основного, бывшего основного - во внутреннего.

(39) Здесь (при слиянии в новую базу), я думаю, лучше применять документ "Начальная штатная расстановка", это решит  проблему приемов/увольнений.

(29) (39) Видите минусы применения этого документа?

(37) Обработка регистров для простановки головной организации (2 суток колбасило!) + перевод
(38) Это было не на текущем месте, там я в одно рыло все тащил по ЗУПу

(40) Не просто минусы, а в мусорку немедленно и недрожащей рукой.
Исключительно и спокойно док Изменение ШР. В рабочей базе просто датой присоединения добавляются позиции ШР. Не надо здесь никакой началки.

(42) Вы путаете работу с позициями штатного расписания и с сотрудниками. давайте еще раз.

А вот отпускные стажи - да, вводом остатков.

(41) Спасибо.

(41) А как вы перетаскивали все в одну базу? Написать обработки по замене головной организации в многопотоке и обработку по переводу - это фигня, а вот правила по сливанию баз - это немного другое.

(46) Да похоже через РИБ. Хотя способов масса.

(43) Дубль два: на кой ляд нам начальная расстановка, если мы перетащили ВСЕ кадровые доки.
Началка - это когда нет прошлой кадровой информации.

(48) А зачем нам ВСЕ кадровые доки, особенно при слиянии?

(49) Статья 75 ТК РФ. У нас для "новичков" должна остаться вся кадровая история, как если бы они всю жизнь были в текущей базе.

(50) Сомневаюсь, что там именно такая формулировка ))

Переносил в 2018 году не для слияния данные из 77, ни разу никто не спросил предыдущие документы за период до 01.01.2018.

Все же кадровые документы и их отражение в учетной системы - это несколько разные вещи.

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

Потом для слияния фирм в одной ЗУП нужно по вливаемой фирме ввести обычные документы ввода начальных остатков как это делается при переходе с зуп 2.5 на 3.1, то есть еще нужны документы начальной штатной расстановки, ввода остатков отпусков и штатного расписания если ведется, потом уже документами Перенос данных вносить данные по взносам, ндфл и тд... Курите перенос данных из 2.5.

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

Работы ппц...


Метод слияния проверен на практике.

(51) Хорошо. Можно топором обрубить кадровку и потом лазить в архивную базу по надобности. Но зачем?! Когда можно иметь всю историю под рукой. Место мизер займёт.

Это всё понятно. Всем безмерная благодарность за поддержку. Но остаётся вопрос: Есть физлицо , есть сотрудник с этим физлицом. Но этот сотр не виден в справочнике сотрудников. Для видимости необходимо записать сотра в регистр данные для подбора сотрудников? Что то ещё для комплектности, чтобы система показала этих сотрудников в списке?

(54) Приём на работу реальной прошлой датой сделали?

(55) начальная штатная расстановка нужна и все!
Если нужна кадровая история для карточки Т2, то заполнить нужно регистны реестр отпусков и кадровой истории

(56) Не нужна и даже вредна.
Зачем ипошиться с регистрами кадровой истории, если достаточно завести кадровые доки? Или это вид мазохизма?

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

(57) обоснуйте

(46) Они были уже все в одной базе. Но, типа, независимые фирмочки

(59) Пожалуйста. Зачем специально возиться с каждым реквизитом РС, если достаточно просто перетащить и провести кадровый док, его двигающий. И не только его. Не забывайте про 14 интервальных регистров, в основном как раз кадровых. Док двигает, точнее обновляет и их. А Вы вручную будете ковыряться сто лет.

(61) попытка перенести всеееееее это самоубийство, вы никогда не сможете дать гарантию, что все проводясь по новой не даст новые цыферки, поэтому начинать нужно условно сказать со свертки старой базы, путем переноса остатков в документы ввода этих остатков и оттуда прододжать жить! А так как это слияние фирм, то нужно и подмены делать попутно, хотя бы орг структуры. Но тут тоже дело такое, может слияние проходит с сохранением подразделений старой фирмы и уже потом будут кадровые переводы, если нужно

(62) Дубль три: мы переносим не "всеееееее", а только кадровые доки - и это правильно.

Устал. Делайте что хотите.

(61) я в 2015 году, 2017 и 2019 на этом собаку сожрал
980 сотров фирма на 3.1 переход на ЗУП
Слияние 14 фирм в одну, 500 челов, розница из КА 1.х в ERP
В эту же ERP переводили завод на 1000 челов из УПП
Потом розница слияние было с заводом

(63) и история заработков средних не надо переносить? Для отпусков, для больничных?

Это доками перенос данных делается

(65) Регистры среднего - обязательно. Это даже не обсуждается. Спор о кадровой истории.
Как кадровик - я бы послал на три буквы проект с начальной штатной расстановкой - и нанял бы других программистов.

(66) для переноса кадровой истории предназначены два регистра системы реестр отпусков и кадровой истории и они прекрасно выводят данные в Т2! Вся история кадровых переводов видна!

(61) На больших объемах такой подход будет крутится до посинения. Пробовал на той базе просто перепровести доки по одной организации, установив у нее головную, чтобы типа регистры сами все прописались. Одна организация проводилась порядка 12 часов...

(67) Про интервальные регистры слышали?
(68) Да хоть сутки. Лучше один раз сделать нормально. С реальным доком регистратором.

(66) у меня на инфостарте даже две обработки есть для кадровиков чтобы они могли комфортно и наглядно править их. Так же есть обработки позволяющие текстовые названия должностей и подразделений там менять на ссылки при большом желании. И кадровую начальную расстановку я обработкой разрывал помню отдельно сотры и их должности с начислениями, и отдельно выделял вводы остатков отпусков, которые можно править вообще не сыкая, что в доках начисления зп перерасчеты полезут, а кадровики в остатки отпусков лезут ВСЕГДА!! Нет фирм где там нет грехов

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

(70) Речь не о начале работы в программе. Да и то я считаю, что приёмы надо заводить реальные.
Речь о присоединении. Это сейчас актуально, когда взяли за жопу дробителей бизнеса.

(71) Сталин тоже сначала дал только год на создание нашей АБ.
Мало ли кто хочет за выходные присоединить многотысячную базу.

(69) про документы ввода данных "периоды оплаченные до начала эксплуатации" Слышали? Они покрывают часть проблем, если сотрудник на момент ввода остатков был например в отпуске, или беременел еще раз...
Вы обрекаете человека вообще все кадровые доки тянуть и проводить и сверять, и кучу мертвых душь тоже тянуть, ибо они в списочных доках фигурировали, либо же выфильтровывать их. Вы на календарь посмотртье. До нового года фиг да нифига времени на такие изврашения

(0) посмотрите как строится динамический список в справочнике "Сотрудники" и в обработке "СписокСотрудников".

По слиянию: посмотрите, как работает документ "Перевод к другому работодателю" (данные в документах на вкладке "3. Оформление перевода" делаются фиктивные без галок выплата зп и отпусков и удержаний, отображение трудовой деятельности, чтобы потом не улетело никуда, только для ввода остатков по типовым регистрам по типовому алгоритму).

Также дополнительно необходимо будет перенести через документ "Перенос данных":

регистры накопления за необходимый период "Данные о времени для расчета среднего (общий) ", "Данные о начислениях для расчета среднего заработка (общий)", "Данные страхователей для расчета среднего заработка ФСС", "Бухгалтерские взаиморасчеты с сотрудниками", "Взаиморасчеты с сотрудниками", "Зарплата к выплате",

регистр сведений "Данные состояний сотрудников".

Также необходимо перенести данные мест для получения зарплаты, для сотрудников: посмотрите на форме сотрудника "Выплата зарплаты".

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

(74) Мы говорим не об остатках вхаиморасчётов, а о кадровой истории. Как раз при её наличии вообще не будет проблем с отпусками, беременными и т.п.

Если база типовая, то наверно проще действительно правила разработать по переносу и свертке базы в документ "Начальная штатная расстановка". Я даже писал года 4 назад такие правила и сделал одну миграцию так. Но если доработанная как у нас, где есть специфичные кадровые регистры, которые этим документом не устанавливаются (типа периодичности суммированного учета, видам вахты и т.п.) - то лучше делать перенос полностью кадровой истории. По части перепроведения этих документов, то можно их перепроводить в многопотоке по сотрудникам. Но нужно учесть, что разработать корректные правила по свертке и замене головной организации, должностей, видов отпуска и т.д. с переносом информации о личных данных сотрудников, данных о среднем заработке, остатках отпусков и т.п. займет какое то время... по моей оценке - недели 3.

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

(78) По сути это увольнение и прием, как и говорил т. El Duke

(78) Так а я же и написал про документ "Перевод к другому работодателю" в сообщении? Что поменялось?

(76) Еще и доки отпусков переносить? Ну дела...

(75) регистр сведений "Данные состояний сотрудников" - по состояниям отличающимся от "Работает", который будет при оформлении приема, к примеру, в декрете, болеет и тд.

(69) "Да дуракаваляние ... Конгресс какой то, немцы какие то ... Голова пухнет !"

На кой черт все это надо ?
Даже если присоединяемая база велась идеально, возможны куча косяков. Типовой перенос не затрагивает кадровые доки, не получите вы кадровой истории. Регистры для формирования Т-2 заполнятся при типовом, а доки не переедут. Придется лепить свои правила переноса, а с этим вы к обеду среды не управитесь.
По нормальному, такое надо делать через увольнение сотров и прием на новое место работы. И предусмотреть для этого подходящий по ТК вид поглощения фирмой А фирмы Б.

(81) Ну как бы исправление документов оплаты по среднему - головная боль таких переносов.

(81) Обязательно! При условии, что они продолжаются, т.е. дата присоединения сидит внутри их интервала.

Хм... такое впечатление, что я остался в одиночестве...
Кто голосует за Кайтанова?
)
https://www.youtube.com/watch?v=AL32fFzoqik&t=140s

(79) фиктивный (обсуждали с кадровиками, если он не будет делать записей в "Мероприятиях" и тд, то пойдет), который поможет, внести данные по новым сотрудником со старых, а в документе "Перевод к другому работодателю" будет информация по старому и новому, что поможет в дальнейшем написать обработки для переноса данных, по необходимым регистрам.
+ необходимо корректно оформить остатки, на вкладке "3. Оформление перевода" данного документа и делаются нужные документы по вводу остатков + перенос данных по доп необходимым данным + сами регистры типа "Лицевые счета", "Места выплаты зп" и необходимые.

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

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

(86) Так вы из другой лиги, Гена. С одной стороны те, кто такой перенос делал и знают технические особенности и подводные камни, а  с другой - ваше сферическое ТЗ в вакууме. Спору нет, вы правы, но реальность вносит свои коррективы.

Перевод к другому работодателю делают кадровики и проверяют все, программист после этого делает необходимые переносы и обработки, консультант со своей стороны помогает программисту и кадровикам.
Руководители устанавливают сроки и порядок и контроллят, помогают в сложных организационных ситуациях и решают организационные вопросы.

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

(88) Поддержу вас коллега
Одно дело быть правым в теории и совсем другое когда для реализации этой правоты нет никаких инструментов. А попытка слепить что то грозит неиллюзорными проблемами в дальнейшей жизни базы. Может в небольшой базе на сотню гавриков эти проблемы со временем вычистятся. Но там где многие сотни и тысячи морд переносятся - будет весело.
В этом случае слияние должно отталкиваться от технической стороны вопроса, на первое место выходит мнение сопровождающих прога и конса, а не кадровиков и каких то высоких управленцев.

(91) У Вас нет инструментов переноса кадровых доков между базами одной конфигурации?
Самому не смешно?

(90) Забудьте Вы про этот док перевода к другому работодателю - он чисто для формирования пакета печатных форм такого увольнения.

(92) Сэр Генри, вы ж математик, ну взгляните на проблему под этим углом. "Наука только тогда достигает совершенства ..."  - помните ?
Здесь в явном виде бритва Оккама и Ошибка выжившего. Дальше надо пояснять ?

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

(94) Хорошо.
Поверьте хоть в то, что хотя бы реальные приёмы надо перенести! О большем я уж вас и не прошу...
)

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

(97) Чушь. Ну какое "вспоможение" от увольнения.

(92) Давайте я вам поясню, что означает инструмент по переносу кадровых документов. Допустим вы переносите прием на работу сотрудника. Мало того что вам надо перенести сотрудника и физическое лицо, вам надо перенести:
1) Организацию.
2) Подразделение
3) Позицию штатного расписания.

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

(94) Причем каждая сторона видит "слона" по-своему

1. расчетчики - да что вы там возитесь с кадровыми документами, сделайте нам свертку суммы к выплате и текущие условия оплаты труда на 01.01.2018, да и будем считать

2. кадровики - а сделайте нам так, чтобы программа не считала остатки отпусков, мы всегда сами считаем. Но кадровые приказы перенесите все!

3. главбух - да вам лишь бы денег с нас содрать! просто сделайте чтоб все работало правильно и подешевле!

4. программисты - да зачем мы только в это влезли.. в бюджет не пролезаем с таким объемом работ

P.S. Все совпадения случайны.

(96) Я за вариант увольнение-прием, так что реальный прием на новом месте конечно нужен. Без вариантов :)

(97) Если у вас базы физически разные, то про перевод можно забыть

(99) Не морочьте голову, вы программист или кто? Вот вам три рубля и завтра чтобы все работало.

(99) Про префиксы слышали?
Так и так префиксовать надо. Не думаю, что открыл Америку.

(102) Шутка юмора, а между тем много где реально практикуют подобное. Правильный подход в таком случае - нанять проектную команду. И чем больше присоединяемая фирма, тем больше проектных ролей в ней должно быть. Это дорого, но правильно
А там где экономят, мыслят так: "Наш генеральный папа Полиграф Полиграфыч решил что переход должен быть сделан способом Х ! Поручаем его реализацию прогу Васе, пусть напишет обработку с одной кнопкой "Перейти !". Неделю ему на все это, тут вообще делать то нечего. Если справится - выпишем премию в размере оклада."

(103) Получим Агвиевы конюшни неиспользуемых элементов в половине справочников. Кто их потом разгребать будет и сколько времени это займет ?

(104) Я бюджетникам перенос делал. А там еще и конкурс.

И похоже, предстоит слияние баз с филиалом из другого города , вот  про это думаю с содроганием.

(0) БЕГИТЕ!!!
Тут собрались душнилы.
Каждый душнит на своем языке)))

(106) А судьи кто? )

(107) Я про судей ничего такого не говорил…
)

Смотрю адептов "фиктивного" увольнения хватает.

(109) да, особенно наперекор требованию директора и главбуха, которые и оформляют документально все перед гос органами и требуют не увольнять))

(110) Директор и главбух это непогрешимые Будда с Заратустрой что ли ? Если они лучше знают как сделать, то что им тогда стоит сесть и перенести самим ?

(111) Вот возьмём и перенесём. Чем тратить время на растолковывание азбучных истин.

(111) Закон запрещает слияние без увольнения? Нет? Делайте без увольнения!
Меньше слов, больше дела!

(112) У вас 2 часа, вперед!)

(114) Ну чего так жестко-то?  К утру успеют, и нормально.

(112) А сколько возьмёте?

(113) К РФ Статья 75. Трудовые отношения при смене собственника имущества организации, изменении подведомственности организации, ее реорганизации, изменении типа государственного или муниципального учреждения

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

(117) Как тебе такое, Илон Маск?

(115) От принятия решения о реорганизации до регистрации таковой проходит немало времени. Надо быть полными идиотами, если не продумать и не обкатать схему заранее.

(118) Кши! )

(120) Стадия первая - отрицание.

(119) "От принятия решения о реорганизации до регистрации таковой проходит немало времени. Надо быть полными идиотами, если не продумать и не обкатать схему заранее."

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

(121) Вы же не в ОДНОЙ базе имеете две организации. Оставьте этот док в покое.

(123) Тогда чем вам начальная штатная расстановка не нравится (ну, кроме как потерей истории, которая все равно никому не нужна) ?

Полная история в исходной базе.

(122) Успею. Если с толковым программистом, который быстро делает и не задаёт глупых вопросов.

(112) (122)

(119) Тот случай когда конфа не успевает за НПА
И значит надо выбрать такой способ объединения, который не нарушает ст.75. Например ликвидация организации, с постепенным переходом сотров в состав новой.
К сожалению этот подход встречается редко. Процветает волюнтаризм, когда какой то чиновник принял решение нисколько не заботясь о том как его реализовать в софте

(126) Практика критерий истины. Выбираем утро, я подсоединяюсь по удалёнке. У программиста, который умеет быстро переносить справочники, регистры среднего и доки, открыты обе копии баз.
И засекайте время.

(128) Зря вы Дюка не слушали. Быстро можно перенести туда, где структура данных это позволяет. Впрочем, я бы посмотрел на шустрого программиста, который бы взялся работать по вашему ТЗ, очень любопытно было бы видеть. как скоро он, увидев структуру данных ЗУП, сольется.

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

В филиале, к примеру, он был на основном месте работе, а станет внутренним совместителем. А в приказе четко сказано - он основной!

Так нужна ли ВСЯ кадровая история или все же достаточно среза в начальной кадровой расстановке?

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

(130) Перекрёсты я ещё не продумал. Писал сходу. Но уверен, что можно продумать схему.

(131) Да и правда, чего это я... Можно же просто проигнорировать структуры данных в ЗУП и просто перенести. Вот дураком был..

(133) У автора одинаковые конфигурации и даже релизы. С чего это структура данных будет разная?

(134) Крайне редко бывает что в старой фирме будет востребован весь штат новоприобретенной. Не говоря о том что при вашем подходе в старую фирму должны благополучно приехать еще один директор, главбух, финдир и прочие топы, секретарша и прочий адм.аппарат. Что потом делать с двумя директорами, кто главней ? Расчетчикам какого из главбухов слушать ?
То то же.
При ликвидации можно решать кого взять или не взять, появляется гибкость в решениях, возможность управлять процессом. А при реорганизации такого нет, берешь всех скопом, а потом думай куда девать двойной функционал.

(135) Эти вопросы уже решены. Гена работал на полставки и там и тут , главбух свалила в давно звавшую её контору в Москве. Начальник ИТ стал заместителем нашего начальника. А функционал контор разный. Область одна , функции разные.

(136) Означает ли это что теперь на фирме будут 2 директора на полставки каждый ?

(137) Это лучше не переносить, вручную настроить.

Вот кстати Гена прав во многом, можно те же виды расчета настроить заранее и переносить по некоему идентификатору, который привязать к виду расчета и в первой базе, и во второй, можно через допреквизит.

И не создавать их и не анализировать во время переноса. А проанализировать заранее. Если в двух базах используется один вид расчета, так его и прописать.

То же касается должностей, подразделений и прочей условно-постоянной информации.

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

Ну и так далее.