КД 2.0 из dbf в ЗУП 3.0

[y-nov]

Правильно понял, что придется этот код писать в ЗУП? т.е. создавать дополнительное поле и сразу снимать с поддержки.
Не хотелось бы. Хочется хоть немножко поработать с конфой на поддержке

причем тут ЗУП?
я про КД говорю!

Нужно поставить соответствие между справочниками ФизЛица и сотрудники.

Получается, что в первом ПКО я гружу ВнешнийКод в ЗУП в справочник ФизЛица

А в ПКО для Сотрудники Поиском нахожу соответствие  по ВнешнемуКоду и устанавливаю связь.

Но тут изменять конфу нужно.
Или я неверно понимаю как составить ПКО по внешнему коду.

[cska-fanat-kz]

1. у ФизЛица есть комментарий
2. вроде на месте стандартный механизм свойств...

[y-nov]

Без использования КД, я бы сделал

А кто вам мешает именно так и сделать? Загружайте физ лица через КД, а затем своей обработкой создавайте сотрудников.

Через КД как-то более наглядно получилось бы.
В файле dbf 160 полей. Паспортные данные, смена фамилий, кадровые перемещения и т.д. Это все отдельные справочники, регистры, документы.

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

Добавлено: 16 фев 2016, 14:38

1. у ФизЛица есть комментарий
2. вроде на месте стандартный механизм свойств...

В таблице dbf 10000 строк. ЗУП сейчас пока файловый.
Боюсь, что поле "комментарий" сильно подкосит скорость загрузки.
Но пока это лучший вариант. Займусь его реализацией. Спасибо!

[cska-fanat-kz]

перегруз одноразовый или постоянный?

[y-nov]

теоретически - одноразовый. Раз выгрузишь, что-то не пойдет или не  понравится еще раз загружать..
Думаю, что сделать временную базу ЗУП с индексным полем внешнего ИД. А из него уже грузить в чистую рабочую базу с нетронутой конфой.

[cska-fanat-kz]

что-то не пойдет или не  понравится еще раз загружать

не аргумент.
ну и пусть что еще раз.
я бы тогда не парился о производительности.