How can I control behavior of BOM on revision up
Hi community, Here is an use case that User want to control Part by item that make the BOM are float or fixed when revision up. I read some solution that you can use a customized property and replace the action when creating a new revision. But I need more explain on doing this. Thanks to read this.
How can I control/track floating behavior of Parts?
Hi community, I use floating behavior on certain Parts in the BOM. This way the BOM will always show the latest Part as long as the Parent hasn´t been released yet. But I wished we would have more control about the float action it self. I don´t want to use "fixed" behavior. It would be helpful to know that a automatic "float" occurred and which Parts were affected. I am thinking about two possible concepts: 1. Inform user before a float update will occurs (include information regarding the affected elements) 2. Track somewhere in Innovator which BOM elements were updated via "float" Does anyone know a solution for something like this? Or has any other idea how to use the "float" behavior in a more controlled way? Any input welcomed! Many thanks! Angela
Relation and versioning
Hi, I have an ItemType STUDY with a property (type=Item) pointing on an ItemType CONTEXT. The CONTEXT is versionable and has a simple lifecycle WIP => REL. I would like that: When the relation is created, the STUDY is pointing on the last version/generation of the CONTEXT When the CONTEXT is modified (same version), the STUDY is pointing on the last version/generation of the CONTEXT When the CONTEXT is released (LF set to REL), then all STUDIES are now fixed on this version/generation To do that: I set the "Item behavior" of the property to "Float" On the LifeCycle, I set the ""Item behavior" of the state "REL" to "Fixed" But, the point (3) of my expectations doesn't work, if I create a new version, the study is pointing now of this new version. What should I do?
Purge and float
Hi, I create Itemtype A and B , both are version controlled and A has B as an item property defined as float. I create an instance of both and relate instance B to instance A . I modify both multiple times so they both go up several generations. When I purge instance A it goes to the previous generation with still referencing the latest generation of instance B . When I purge instance B I get an error instead stating that that specific generation of instance B is still referenced by instance A . 1. what is the Aras standard way of dealing with this situation? 2. what is the Aras standard way of dealing with a similar situation, but instead applied on relationship itemtypes? I'm having a hard time finding information on how to deal with the above 2 situations. Regards, /MB
Will Item Behaviour set on Life Cycle take precedence to a property Item too?
I have an Item “ItemA” which has a property “PropA” of type Item with Item Behavior as Float. If I set the Item Behavior on the LifeCycle of the “ItemA” to be Hard Fixed. Will “PropA” behave as “Float” (as set) or “Fixed” (by taking the precedence from Parent’s Life Cycle state)? I tried mocking this up. But “PropA” still has Float behavior (I expect it to behave it as Fixed :(). The Parent’s Life Cycle State’s Item Behavior does not take precedence in this case. Please clarify. Thanks in advance.