How to "lock" assembly to ignore new parts revisions

[tomsed]

Hi all,

Please can the local experts here help us with following?

Example: In 2012 we created assembly and its drawing. It has been delivered to the client.

Now in 2014 we need to make a change in this assembly and drawing to make an improvement there, but during those years - parts in the assembly (same for many other assemblies) have been modified many times and when we open the assembly, it loads all new updates and the newest revisions automatically.

But our client has product from 2012 with older parts and we need to work with those. 

Is that somehow possible to "lock" the assembly to prevent loading new revisions into it and keep it using old revisions (and have "As sold" version)?

I hope I explained the problem enough. I always can insert older version of the part into assembly, but if we are talking about hungreds or thousands, than its not really possible to set up a few years old assembly.

We are currently wotking with Inventor 2013 and Autodesk Vault profesional 2013

Thank you in advance for every comment or proposal.

Tomas

[tmoney2007]

This isn't possible because the files that get referenced are the ones that are in the local workspace, and the only options for a "get" to the local workspace are "latest released" or "latest checked in" versions. It isn't a function of anything in the top level assembly itself. Short of doing a pack and go at the time of release, it would be very cumbersome to fully roll back an assembly.

There is a pedantic argument about form, fit and function in there somewhere,... but I only mention it because that is one of the best practice principles that the logic for Vault was built around. 

I do think that a "latest released as of X date would be a useful tool.

Generating DFW's of your assemblies/drawings would be useful (as long as you save them separately from the vault visualizations so that they don't get updated accidentally.) I'm pretty sure they can be configured to contain a fully indented BOM table. This way you could find the specific parts that need repair and locate the active revision of those parts on the operative date.

[brendan.henderson · Accepted solution]

If in 2012 you were using Lifecycles (Released, WIP, etc...) when data set was released (locked against alterations) then yes, you can load up that version of the data set.

See the below picture (I'm on 2014 so the client looks different to what you have). Here there are 2 released (APPD FOR MAN) states and some others. I can load (or get local) the dataset I want so even though Rev 2 is the latest I can get the local files at Rev 1. You need to be careful with the local workspace. Generally when I need to get historic data sets I clear out the workspace and then Get from Vault (or Open from Vault in Inventor which also gives you the ability to load a specific released dataset). By default my release of Inventor and Vault will open with Latest (use newer edits) but by selecting the options I can load a specific release. This is the very basis of Lifecycles and Revisions, the ability to roll back to a previous release (revision) and if need be to promote that to the latest (new) release/revision.

If you were not using Pro and Lifecycles in 2012 then the task may be very difficult. You could try to Get via the History tab. Find the Version of the assy/IDW you need and get it local, but you way need to use some optiosn (like put it all into a separate folder) to ensure that newer versions of parts.assemblies/content centre data is not used. Again, clearing out the local workspace of files works the best IMO.

[tmoney2007]

Does this work if you only use released lifecycle states as opposed to ECO's?

Also, does it roll back all of the components to their states at the time of release of the parent?

[brendan.henderson]

Lifecycles (Change Management) and ECO's are 2 different things that can exist together and they rely on the other.

From Help :-

A lifecycle definition uses states to identify the object's status in the lifecycle. Examples of states are Work in Progress, For Review, or Released. An object moves from one state to another based on the lifecycle definition's transition rules. These transition rules determine when the state change happens, if it can occur manually or automatically (or both), based on criteria determined by the administrator. The lifecycle definition also determines if any other automatic behaviors occur based on a state change.

For example, a lifecycle definition can be configured to automatically revise a file when it moves from a Work in Progress state to a Review state. Or if a user changes a folder's status to obsolete, the lifecycle definition can automatically apply security settings to the folder so that only an administrator can modify the folder and its contents or reinstate it for use.

From Beyond The Box blog :-

Autodesk Vault uses an Engineering Change Order or Engineering Change Notice to record events in a change management cycle and controls how design changes are managed and released. Change Orders can be created to describe changes to a design as well as manage the progression of that Change Order as it is reviewed, approved, or rejected. Change Orders provide a historical record of why, how, and when changes were made.

A further layer to both of these is Items which I do not use so I won't comment on that.

Put as simply as I can, Lifecycles control transitions of the file from beginning to end and death (Obsolete) and back to beginning again with rules and conditions along the way. ECO's are an additional layer that record the details of the files also has rules. For example, in my setup (which is quite common), files at a released state (APPROVED FOR MANUFACTURE) must be added to an ECO before the files can transition back to WORK IN PROGRESS for updates and changes. The ECO then controls when (and who) can transition the lifecycle back to WIP and the lifecycle transition cntrols the bump of the revision value.

For your last question, yes it does as long as all of the files (children including Content Centre files) where also released (lifecycle) with the parent assy/IDW. There are rules in the Lifecycle state transition to make sure that all children must also be released so that the parent can be released.

I've probably stuffed the explanation up. I know how and why it works but explaining it in text is difficult. If someone else has a better explanation of how this functions please chime in.

[K_Kampouris_GizelisSA]

Nine years later and the problem is still there unsolved. We ca not have assemblies with Serial number that remain unchanged when subassemblies or included parts are revised!!!!!