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

(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) соответствия приходится строить даже в пределах одной базы, так что Гена не открыл америки тут. Мы при доп реквизитах хранили связи, потом после переноса почистили их.

Вот, очень вовремя и прямо по теме вопроса: https://its.1c.ru/db/answersstaff/content/2442/hdoc

Уж полночь близится обед среды наступает ...
Автор, как у вас успехи с задачей ?

https://buhexpert8.ru/voprosy/voprosy-1s-zup/reorganizatsiya-v-forme-prisoedineniya-perevod-sotrudnikov.html

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

(142) Я тут подумал... Если объём данных некритичен, то можно прямо сейчас Вам спокойно, медленно и в охоточку заняться следующей задачей:
Объединить две базы ЗУП в одну с полным переносом ВСЕХ данных. Думаю, в инете должны быть заготовки.

Если не получится - ну и фиг с ним. А вот если получится, то ко времени "Ч" останется только в уже ОДНОЙ базе офилиалить присоединённую организацию, т.е. превратить её в обособку. Может я слишком оптимистичен, но вроде как достаточно будет подменить головную организацию. В любом случае офилиалить - это вам не присоединять с нуля.

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

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

(145) Сэр, эти предложения напоминают мне страдания китайского комсомола в далекие 1970-е. Им не пришлось участвовать в революциях и войнах, так они создавали себе трудности на ровном месте. Работали в противогазах без света и по пояс в студеной воде там где всего этого не требовалось

(146) Ну нет, так нет - это я так, проба пера )

(141) Пригласили третью сторону. Третья сторона охладила боевой пыл горящего неукротимым огнём некоторой части руководства. Видимо , не так уж и нужно было объединять.

(148) "Пригласили третью сторону"

А именно ?
Кто же рассудил Энгельса с Каутским ?

(140) Премного благодарю за своевременное указание на существенное обстоятельство!

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

(151) Так чего решили-то? Реорганизация же будет - а базы разные оставите?!

(152) Примут на работу новых сотров , как то решат с неотгуляными отпусками.

(153) Т.е. по факту предложение папы Дюка уволить на старом месте и принять на новом.
Очень разумно, молодец начальник, цените его

(150) Сообщение в (140) вообще не имеет отношения к рассматриваемой теме. Это описание увольнения в порядке перевода, а у вас был вопрос про реорганизацию.

Формы реорганизации юр лица перечислены в статьях 57, 58 ГК РФ.

Согласно пункту 1 этой статьи, реорганизация юридического лица проводится (возможна) в форме:

    слияния,
    присоединения,
    разделения,
    выделения,
    преобразования.

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

(155) Сообщение (140) имеет самое прямое отношение к вопросу. По ссылке растолковано что понимается под переводом, потому как очень многие перевод понимают как исчезновение в фирме А и появление в фирме Б. И рассматривают это как способ проведения реорганизации.

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

(156) Да ничего не разойдётся. Поверьте моему опыту. В случае присоединения в 95% случаев всё остаётся как при бабушке. Это же не переезд. Кексы как работали в своём городе - так и продолжают работать. Они даже не заметят реорганизации )
Была фирма "Рога и копыта", а стала "Копыта и рога".
Разве что кто-то ушлый заметит, что был гендир, а стал просто дир в приказах.

(156) Я увольнялся переводом в другой филиал, без реорганизации общества (переезжал) - это всего лишь способ перевестись с одной организации (филиала) в другой. И делал слияния кучи обществ, где ничего не менялось кроме руководства...

(158) Переезд - это как минимум смена места работы и очень вероятно должности. Если остаешься в своем городе - почти наверняка сменится должность и оклад. А это существенные условия ТД, урегулировать их полностью корректно можно только через новый договор.
По итогам ветки делаю вывод:
если есть возможность повлиять, то слияние надо делать через увольнение прием. Если нет - тогда по варианту Гены

В "маточный" ЗУП всегда заливали все данные из ЗУП "пришелец". Со всеми документами, рс и даже регл. отчетами.

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

Служебные регистры по электронным трудовым и ЭДО тоже морока, но решаемо. Некоторые документы переносили с движем, старорелизный "пришелец" не всегда получал такие же движения как в новом релизе. Для тех же электронных трудовых доки логично перенести с движем - потом сложно выровнять ИД, которые ушли в мир.

Остальное - банальная рутина.

Были правила на КД2, при очередном слиянии немного их перепахивали, т.к. таблицы в зуп меняют часто.
"Начальная штатная расстановка" и прочие обрезки не устраивало.
Фины и бухи желали видеть полную историю - все по всем.

(160) >> Для тех же электронных трудовых доки логично перенести с движем - потом сложно выровнять ИД, которые ушли в мир.

Согласен, мне как то досталась база, где только СЗВ-ТД перенесенные и нет полной истории. Все бы хорошо, но ПФР внезапно вздумалось, что переданные 2 года назад мероприятия не совсем корректны и их нужно отменить и отправить заново. )

(161) Пришлось небольшую обработку написать, которая бы обеспечила требуемое (запихивание несуществующих уже мероприятий в нужные ТЧ).

(160) Самое сложное в этом слиянии, как раз написать корректные правила в КД2, в которых обеспечить грамотное сопоставление объектов, с учетом наличия в базе "пришелец" своих видов расчетов и возможно сразу сделать подмену головной организации в движениях. Когда уже есть корректные правила, то не вопрос их допилить до актуального релиза. А вот с нуля разрабатывать - это довольно трудоемко...

(163) Я как-то разговаривал с ЗУП-ером, у нее было мнение, что правила на КД2 быстро устаревают, поэтому лучше взять известную (в узких кругах, видимо) обработку свертки и перенести через "выгрузку-загрузку данных", а потом удалять дубли и снимать признаки предопределенных. В целом ее подход сработал, но иногда бывает в каком-нибудь справочнике находятся неудаленные дубли (должностей, каких-то классификаторов и т.д.).

Но для разовых задач, конечно, КД2 рулит все еще.