Лоцман 10.0

[Дмитрий22]

Недавно приобрели Лоцман 10.0 До этого стоял 8.5. Обнаружили следующие неудобства в работе. При многопользовательской работе с сборочными единицами часто возникает ошибка "Не могу построить дерево по спецификации, т.к. объект не взят на изменение в текущем проекте" и не строится дерево.
Пример: Есть сборка А в сборке Б. Человек берет ее в работу и пытается построить дерево по спецификации. Лоцман выдает ошибку (см. выше) т.к. сборка Б взята в работу другим человеком (сборку Б взяли в работу чуть позже). В результате, чтоб построить дерево сборки А нужно найти человека, взявшего в работу сборку Б и попросить его из работы выйти, чтоб другой человек смог построить дерево сборки А. В Лоцмане 8.5 такого издевательства не было точно. Ладно если человек сидит рядом, а если он в другом здании находится, а если еще он работает со сборкой Б и из работы возвращать никак не входит в его планы?
В техподдержку звонили, говорят, ребята из Аскон ввели дополнительные проверки в интегратор и после этого построить дерево стало сложнее. Вывод такой: Лоцман 8.5 проще и работоспособней.

[Вячеслав]

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

[Дмитрий22]

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

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

[b_leo]

На мой взгляд в данном случае логика работы более правильная. Как я могу работать со сборкой если во входящей в нее подсборке кто-то "ковыряется"? Исходя из логики работы ЛОЦМАНа, распределение прав происходит, как правило, по принципу "кто выше - у того и прав больше" (ну прямо как в жизни ), учитывая, что сборка А входит в сборку Б, более главный тот кто взял сборку Б (т.к. она на уровень выше).
Вообще-то все определяется правами на сборку. Так что проверьте может у того кто взял в работу сборку Б просто прав больше?

[YorikER]

Посмотрите на эту проблему с другой стороны... Пользователь вообще то работает, как правило с документами, а не с объектами, которым они принадлежат. Логичнее объекты брать в работу только тогда, когда уверенно меняется информация в их атрибутах, а не в течении работы, после изменения информации объекты желательно сразу же возвращать в БД. А в работу в долгосрочном порядке брать только документы... Как-то на одной из встреч с АСКОНОМ я им предложил эту мысль (мы ее реализовали в своем клиентском приложении - и все проблемы сняли), но вижу, что до сих пор она так и не реализована... Жаль... Хотя бы вариант такой работы в виде специальной настройки в ЛОЦМАН-Клиенте предложили бы...

[b_leo]

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

Разработчик схемы какого либо электронного устройства, согласно планов и сроков разработал документ "Схема электрическая принципиальная". В срок отчитался, в срок получил свою премию и передал данную схему конструктору для дальнейшей работы.
Тот разработал в срок конструкцию устройства, начал разрабатывать печатную плату: выбрал элементы, конструктив и занимается трассировкой ПП.
В это время схемотехник вдруг обнаружил, что мягко говоря дал маху и схема работать не будет. Втихушку взял схему в работу и поменял элементы, саму схему ect.
Конструктор, который уже отработал со схемой доводит свою работу в положенный срок до благополучного конца. А схемотехник "молчит в тряпочку".
В результате проект не сделан. Результатов 0. Схемотехник с премией, а конструктор с пилюлями, а то и вообще "на улице".

По вашему это правильная организация?

Кстати пример этот не надуманный а из жизни. И на моей памяти к сожалению не единичный.

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

[YorikER]

Это во многом уже организационный вопрос, необходимо зафиксировать контрольную точку окончания определенного этапа работ в ЛОЦМАНе с помощью состояний. Схемотехник закончил свою работу и обязан перевести объект из состояния "схема" в состояние "проектирование" (например). В состоянии "проектирование" уровень доступа для схемотехника - "только чтение", для конструктора "чтение-запись". Таким образом схемотехник не сможет изменить объект (в том числе и документы его, если их тоже переводить в соответствующее состояние), не создав новой версии, но это сразу же отразится в структуре... Успехов...

[Дмитрий22]

Вышло обновление Лоцмана 10.0.1.85. Исправлен баг, при котором не строилось дерево, если входящие объекты заблокированы другими пользователями. Спасибо. Остальные глюки никуда не исчезли. Бывает, тыкаешь в дереве мышкой, а он тебе вот такую ошибку: (см вл. файл) В 8.5 такого никгода не было.

[Дмитрий22]

Вышло обновление Лоцмана 10.0.1.93. Исправлена предыдущая ошибка. Спасибо. Остальные глюки никуда не исчезли. Бывает, пытаешься построить дерево по спецификации, а он тебе вот такую ошибку (см. файл во вложении). Лечится установкой админовских прав на сборочный чертеж, что тоже никуда не годится.

[Максим Хмеляр]

Дождитесь официального выхода пакета обновлений 2 (SP2) на ЛОЦМАН:PLM V10.
В нем исправлена эта ошибка.

[Дмитрий22]

А вот эта будет исправлена?

[Дмитрий22]

Или скажем вот эта?