Замена одного объекта на другой везде и сразу. ЛОЦМАН PLM 2013

Автор Setis, 12.03.19, 14:45:09

« предыдущая - следующая »

0 Пользователей и 1 гость просматривают эту тему.

Setis

Здраствуйте! Имеем на работе 13-ый лоцман. И вот теперь срастили его с УПП 1-С в связи с чем возникла проблема-задача, например, имеется к.-либо объект "Кнопка зеленая 1", которая входит в сборки 1,2,3. И есть объект "Кнопппка зеленая 1", которая входит в сборки 3,4,5. Это одна и та же кнопка, но создавалась в разное время разными людьми. Вопрос: как заменить один объект на другой во всех сборка и входимостях сразу? К тому же у некоторых объектов уже архивный статус ::)

Дмитрий22

Добрый!
Мы тоже столкнулись с похожей проблемой. У нас скопилось много дубликатов материалов и покупных изделий отличающихся одной буквой/цифрой. Это произошло из-за того, что базы материалов и покупных изделий появились позже самого Лоцмана.  Для этого обратились в офис Аскон. Они нам предложили разработать за отдельную плату "Модуль исключения дубликатов материалов, стандартных и покупных изделий". Но мы приостановили этот процесс потому,что прежде хотим перейти на новую версию Лоцмана.

Setis

Цитата: Дмитрий22 от 12.03.19, 15:26:48
Они нам предложили разработать за отдельную плату "Модуль исключения дубликатов материалов, стандартных и покупных изделий".


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

Chipollino

Если вы о модуле ChangeReference, то это не совсем то, что вам нужно - он для существующего объекта взятого из внешнего справочника просто меняет ключевой атрибут (_PRODUCT) и ссылку на объект справочника. Если такой объект с правильным наименованием уже был в лоцмане, то "слияния" вы не получите, а получите ошибку. Эта кнопка существует только потому, что объекты из справочников получают свой _PRODUCT из него и в интерфейсе он отредактирован быть не может.

Правильный вариант - это как раз и написать плагин, который будет делать замену одного объекта на другой путём создания новой связи и удаления старой. Но так как это будет новая связь, то технически (например если вы используете ЭЦП на объект "Сборочная единица"), это будет внесение изменений в ЭСИ со всеми вытекающими. Естественно нужно будет иметь права на редактирование всех родительских объектов куда входит неправильный объект. Но ещё раз - это будет процесс создания новой связи и удаления старой.
Например:
В состав "Сборка1" входит объект "Винт М6х15 ГОСТ ..."
В "Сборка2" входит этот же винт, но с названием "Винт М6*15 ГОСТ ..."
Надо создать связь между "Сборка2" и "Винт М6х15 ГОСТ ..." с тем же количеством и атрибутами на связь, что и с объектом "Винт М6*15 ГОСТ ...". После этого связь с неправильным винтом удалить.

Есть вариант для отчаянных - заменить _ID_VERSION для дочернего объекта по существующей связи с неправильного на правильный, но любые изменения напрямую в базе это очень скверно и чревато последствиями. Что называется - на свой страх и риск!  :um:

Danila

в свое время также столкнулись с проблемой множества одних и тех же компонентов в системе.

Проблема решалась технически и организационно.

Технически: решали проблему на уровне БД.
создавали соответствующее "сличенное" имя: переведенное в латиницу без некоторых спецсимволов. (сейчас в Лоцмане есть похожий механизм)
для каждого сличенного имени находили похожие имена и аннулировали неправильные.
Именно аннулировали, чтобы было видно, где применяется неправильный элемент, чтобы потом скорректировать спецификации.
Если же неправильные (аннулированные) элементы удалить, то опять они могут появиться. А если у конструктора выгрузится аннулированный элемент - то это будет ему сообщением о некорректных данных.
Если учитывать, что на самом деле это один элемент - то также на уровне БД заменяли inIdChild в составе изделий.
Да, ЭЦП слетала, но это был признак, что надо проверить, что все корректно.


Организационно: назначались ответственные, кто разгребал все двойные/тройные неправильные элементы.
А также запрещено было создавать всем новые элементы. Новые элементы создавались только ответственными специалистами по определенным правилам.

В конечном итоге в 1С:УПП в состав попадают только корректные выверенные элементы.