Работа с версиями, изменение утвержденного состава Лоцман 2011

[exl13]

при изменении версии одной детали, находящейся в глубине дерева обязательно создавать версию всех вышерасположенных сборок? (состав утвержденный) или как-то можно обойтись изменением одной сборки?
сборка 1 (серия)
**-сборка 2 (серия)
*******-сборка 3 (серия)
************-деталь1 версия 1(серия)

деталь 1 версия 1 нужно заменить на деталь 1 версия 2, я так понимаю чтобы включить ее в состав, нужно создать версии всех вышестоящих сборок(по факту всего изделия до головной сборки), а затем все изделие версии 2 согласовывать и утверждать? 



или можно как-то обойтись меньшей кровью

p.s. капча очень жестокая у вас

[KiDim]

Лоцман имитирует стандартный процесс изменений в изделии. Естественно, может возникнуть необходимость в изменении одной детали и Лоцман такую возможность дает. Проблема может быть только в одном. У Вас наверняка где то ранее уже была использована эта сборка. И там была деталь версии 1. После изменения на деталь 2 этот состав сборки к ранее выпущенным будет не применим. Если этот момент учли, то все будет хорошо.

[exl13]

. Естественно, может возникнуть необходимость в изменении одной детали и Лоцман такую возможность дает.

не подскажете как сделать правильно? конструктор версию сделал, она доступна на вкладке версии, но в составе остается версия 1. Чтобы версию 2 прикрепить, получается надо изменить уже утвержденную сборку сборку 3 которая, в свою очередь еще куда то входит?

[Chipollino]

Зря не пользуетесь модулем извещений - там это всё предусмотрено.

Конкретно в этом случае. чтобы заменить версию в сборке надо иметь права на редактирование этой сборки - т.е. выпустить новую версию сборки и всех сборок, куда она должна входить или обратиться к администратору.
Модуль извещений даёт возможность создать новую версию детали и заменить без создания новых версий сборок. При этом версия детали будет заменена везде куда она входит.

[KiDim]

Зря не пользуетесь модулем извещений - там это всё предусмотрено.

Очень верное замечание. Посмотрите мануал. Он не большой и там все достаточно доступно изложено. https://yadi.sk/i/NVeGU6PRg8N2v

[Danila]

Да, модуль извещений предусматривает логику глубины затрагиваемых версий.

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

Мы у себя не затрагиваем изменение состава выше первого уровня, если о том не указано отдельно в вышестоящих сборочных единицах.

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

[Danila]

не подскажете как сделать правильно? конструктор версию сделал, она доступна на вкладке версии, но в составе остается версия 1. Чтобы версию 2 прикрепить, получается надо изменить уже утвержденную сборку сборку 3 которая, в свою очередь еще куда то входит?

Заменить можно - через операцию "Заменить версию", при чем во всех объектах, вопрос наличия права доступа. Если не возможно это сделать самому, то это должен сделать администратор.

А по сути замена должна производиться автоматически при проведении извещения. Но какая сейчас там в этом логика - если честно не помню. Давно не используем стандартный модуль извещений.

[exl13]

Спасибо всем ответившим, все сообщения по теме и с полезной информацией. Локальная проблема решена, подумаем об извещениях чтобы в будущем проблем не иметь, когда объемы данных возрастут

[rain]

могу ошибаться, но, по-моему, в 11 лоцмане при создании новой версии объекта имя файла все еще меняется на *имя_файла_v2. Из-за этого нужно изменять ссылки на файл в вышестоящих сборках, а это геморрой тот еще. даже модуль извещения не поможет. а вот в 14 лоцмане при создании новой версии имя файла остается прежним, что позволяет особо не заморачиваться со ссылками на файл в сборках. требуется просто открыть и обновить сборку

[Warlock-72]

Давно собирался узнать мнение коллег по поводу критериев изменения версий объектов в ЛОЦМАНе.
Хотелось бы услышать мнение той части аудитории, которая успешно применяет подобные критерии в практической повседневной деятельности.
Мы работаем с ЛОЦМАНом довольно продолжительное время. Объекты в базе данных меняем исключительно с заменой их версии, и с этим проблем нет. Однако, так и не сформулировали для себя принципы, по которым необходимо заменять версии "родительских" объектов.
Казалось бы, все просто - например, изменил что-то на уровне детали (выпустил ИИ на деталь), следовательно, изменился и "родительский" объект, т.е. сборочная единица, куда эта деталь входит, и далее - по всей иерархии "дерева". При таком подходе, в случае если "дерево" имеет сильно разветвленную структуру, исчисляемую десятками уровней, неизбежно получим объект верхнего уровня с номером версии, стремящимся к бесконечности. Мягко говоря, подобный подход не будет отражать логику "эволюции" изделия, т.к. понять из-за чего появилась его новая версия будет проблематично, а скорее всего и вовсе невозможно.
Другой пример... Допустим, выпускаем ИИ на сборочный чертеж (или любой другой документ), при этом изменяем только технические требования. Т.е. мы имеем следующую версию документа, следовательно, нужно менять версию соответствующей сборочной единицы?
А если учитывать нюансы объектов с исполнениями в ЛОЦМАНе (кто с ними знаком)... Допустим, имеем групповой чертеж детали, соответственно, базовое исполнение объекта типа "Деталь" + N-ое количество объектов-исполнений. Нужно нам добавить еще одно исполнение - значит, мы выпускаем ИИ на деталь, а это - изменение номера версии объекта типа "Чертеж детали", следовательно, - новая версия ранее созданных объектов типа "Деталь" (ведь странно же будет выглядеть, если "Деталь" имеет версию "1", а "Чертеж детали" - версию "2", не так ли?). При этом базовый объект этой детали мы фактически не меняем! Как разобраться что какой версии соответствует? 
В общем, получается, что вся эта версионность - категория очень-очень-очень условная, которая лишь добавляет по факту головной боли, т.к. контролировать замену версий в нужных объектах при многоуровневой структуре изделий просто не реально.
Может, кто поделится опытом работы с версиями? Есть ли в них смысл?

[KiDim]

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

[Дмитрий22]

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

Мы дошли до 255 версии и Лоцман отказался строить дерево для 256 версии. Пришли к выводу, что у Лоцмана ограничение в 255 версий. Для себя решили не плодить лишний раз версии. Если меняется деталь, создаем версию ТОЛЬКО для детали (если, конечно масса у сборки не меняется). Меняется сборка - вышестоящую сборку не трогаем, создаем версию только для измененной сборки. Уже 5 лет так работаем и все понятно.

[Danila]

Давно собирался узнать мнение коллег по поводу критериев изменения версий объектов в ЛОЦМАНе.
Хотелось бы услышать мнение той части аудитории, которая успешно применяет подобные критерии в практической повседневной деятельности.
...
В общем, получается, что вся эта версионность - категория очень-очень-очень условная, которая лишь добавляет по факту головной боли, т.к. контролировать замену версий в нужных объектах при многоуровневой структуре изделий просто не реально.
Может, кто поделится опытом работы с версиями? Есть ли в них смысл?

Мы для себя сформулировали примерно следующий набор правил, с учетом собственного модуля извещений и контроля за проведением извещения.

1. Мы определили ряд ведущих документов, которые определяют состав:
Спецификация (СП) - полностью основной состав ДСЕ: материалы, стандартные, прочие, ЭРИ, комплекты, ДСЕ и т.д.
Сборочный чертеж (СБ) - информация о покрытиях.
Схема электрическая принципиальная(Э3) и перечень элементов(ПЭ3) - информация об Электрорадиоизделиях (ЭРИ).
Чертеж детали (ЧД) - информация о материале, покрытиях, нормах (массе), используемых заготовках (других деталях, Прочих изделий).

2. Изменение любого ведущего документа порождают изменение состава, или требуют его перевыверки. Поэтому при коррекции такого документа появляется новая версия ДСЕ.

3. Изменение любого ведущего документа определяет все ДСЕ, которые определяет данный документ. То есть все исполнения, которые указаны в данном документе.

4. Коррекция только СБ (без коррекции других определяющих документов) не порождает новую версию ДСЕ . Информация о покрытии обновляется через специальный механизм. Информация о покрытии у нас хранится в специальных атрибутах.

5. Изменения по присвоению литеры (без изменения содержимого, а только с установкой литеры) новую версию ДСЕ не порождают. Так как состав не изменился.

6. Информация о полном составе изделий (суммы всех спецификаций) в любой момент хранится в учетной системе. В PDM системе информацию о составе на любой момент времени любого изделия мы не предоставляем.

7. Любые вышестоящие ДСЕ извещениями не затрагиваются.

8. После проведения извещения старые версии ДСЕ заменяются автоматически на новые по определенным правилам в зависимости от состояния, вхождения в извещения и т.д.