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

(0) А что говорит конфигуратор?

В первую очередь - РС "Данные для подбора сотрудников"

(1) Конфигуратор говорит много, долго и нудно. Этот совет я и сам знаю, Рома. Благодарю за подсказку.

(0) а они приняты на работу? Иначе могут висеть невидимые, как те, по кому расчеты завершены.

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

(5) Как бы не все так просто. В ЗУП не предусмотрено слияние - только прием и увольнение. Решают обычно так:
1) Переносят базу по второй организации в сливаемую.
2) Делают эту организацию филиалом.
3) Обрабатывают все регистры и заменяют головную организацию.
4) Оформляют перевод к другому работодателю.

Это упрощенно. На самом деле там очень много подводных камней...

(2)(4) Благодарю.

(6)  как раз для пункта 1) и нужно перенести физлица и сотров. Только вот система не отображает их.

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

(9) Благодарю. Перспективы вырисовываются.

(9) В сухом остатке получается , необходимо брать все документы по присоединяемой организации и вливать их с проведением в основную базу. Так ведь 100% , что пойдут расхождения с исходной закрываемой базой? Или я не прав?

Нет ничего проще в ЗУПе для реорганизации путём присоединения. ФЛ перенести, перенести все кадровые приказы с сотрудниками, приём обязательно. Ну и заполнить регистры среднего заработка. Всё.

(12) "..Ну и заполнить регистры среднего заработка." - А вот это самое весёлое!

(13) Полдня работы с перекурами.
Да и вообще подозреваю, что в инете давно есть заполнялки/переноски среднего за плату малую )
Короче, в среду в обед автор ветки всё закончит и отчитается.

(14) У меня с перекурами (100+ сотров) 3 дня получилось...

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

(15) Сойдёт. Когда не горит )

(16) А если есть совместители и там и там? Хрен просто так получится...

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

(19) "...Или не было совместителей.." - вангую, скорее всего.

А в чем сложность при подходе (16)? Будет два физлица, но сотрудники то разные должны быть. Физлица можно объединить типовой обработкой.

(15) А бывш. СЗВ-ТД с признаком "Переименование" проще всего забацать в остающейся в архиве старой базе. Есть такая опция в доке Регистрация трудовой деятельности. Тогда ЕФС-1 Подраздел 1.1. со свистом для всех кексов заполнится.

Да, не вижу никаких проблем в присоединении.

(5) "принять переводом в основную организацию из ликвидируемой"

Принять переводом означает уволить из старой организации и принять в новую. Именно так, а не что то иное. В среде кадровиков и расчетчиков уже второе десятилетие кочует зловредный миф что это можно сделать без увольнения. Нет, это не так.
Альтернативы тут нет: увольнение на стром месте и прием на новом. Не может сотр исчезнуть в фирме А и появиться в фирме Б. Ни с точки зрения ТК, ни с точки зрения отчетности всякими формами ЕФС, перс. сведений и проч.
Ну и соответственно это делает ненужным переносы средних все прочее

(21) Видимо не поняли: На момент слияния ОДНО физлицо Сотр1 в Орг1 на основном , а в Орг2 Сотр2 - совместитель.
Происходит слияние Орг1 в Орг2

(23) Как раз при реорганизации запрещены увольнение/приём. Действие всех трудовых договоров продолжаются. В СФР для них только передаются сведения о переименовании организации.
Для ЗУП в новой базе они должны быть по всем кадрам как если всю жизнь там работали )
И средний заработок учитывается как если всегда они были в новой базе. И отпуска.

(23) а вот без увольнения надо!

(25) +100

(24) Возможно. Придумать думаю все равно что то можно.

(25) Только вот в ЗУП для всего этого нет никаких инструментов. Можно долго пытаться сколхозить что то иное, с риском непонятных косяков, которые фантомами будут вылазить в течение всей последующей жизни базы.

(29) Не пугайте, никто не вылезет. Нам только кадровая история нужна один к одному. А налоги и взносы - заново, ведь организация новая. Тем более они как раз на НГ и сливаются.
Единственно надо не забыть, чтоб зарплату декабрьскую в декабре же выплатили на старом месте. Чтоб не возиться с взаиморасчётами и переходящим НДФЛ.

И вообще, если кто бездельничает, то можно сесть и написать обработку для реорганизации через присоединение. За плату немалую с трёхмесячной поддержкой и с рекламой в инете )
С приятными рюшечками для кадровика. Два окошка: слева присоединяемая база. Этапы переноса. Префикс для новобранцев и их приказов для понимания поиска перводокументов в архивной базе. Если ФЛ уже есть, то на выбор - подменять или оставить. Ну и т.д.

(31) Эх Геннадий, как у вас все просто выходит. Косяки будут однозначно и некоторые нерешаемые в рамках текущей архитектуры ЗУП. Я неоднократно делал такие слияния и скажу, что при наличии инструментов и простой базы это конечно можно сделать за 3 дня, а вот правила переноса и обработки для корректировки данных вы будете писать очень долго. И внешние совместители - это один из них.

(22) Отхватят они проблем с этими СЗВ-ТД, попросит их ПФР отменить и заново отправить мероприятия (приемы, переводы и т.д.) из старой базы, а их нетути. ) Придется обработки писать, костылить.

100 сотрудников, 400... Помнится пришел я на новое место, и в первый же день "ааа, у нас через 3 недели реорганизация с присоединением 10 юрлиц с 45000 сотрудниками...". Вот я тогда вспотел(

(34) Понимаю, а у меня была реорганизация присоединение когда одна база на ERP Lexema, т.е. вообще не на 1с... И несколько тысяч сотрудников - веселуха была на пару месяцев.

(34) вот это я понимаю развлекаться так по полной! )

(34) И понял, почему уволился предыдущий ЗУПовец?

Интересный же опыт. если не секрет, поделись, как решили проблему без увольнений/приемов? Или все же техничски  с приемами пришлось делать?

(37) Там у него зуповцев как блох на барбоске, одних аналитиков по ЗУП аж 15 штук - где-то он упоминал )

По теме: не вижу "проблем" с совместителями. Внутренние - так и останутся внутренними. Чужие внешние - то же самое.
Остаются только перекрёсты:
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) Это лучше не переносить, вручную настроить.

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

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

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

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

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

(138) соответствия приходится строить даже в пределах одной базы, так что Гена не открыл америки тут. Мы при доп реквизитах хранили связи, потом после переноса почистили их.