We just implemented Vault Professional 2013 in our company couple of months ago. We have been debating whether we need to use Vault Revisions or not.
Vault revisions make more sense for companies that issue drawings based on Revisions. If a drawing is issued at Rev A for a machine#101 this year, same drawing can be issued at Rev B with a change for new machine#102 next year. If they ever build machine#101 Rev A can be issued again.
We don’t work like that; we don’t issue drawings with Historical Revisions. We always issue latest Revisions. If a change has to be made to a drawing that functionality of previous machines we create a new drawing with new number. This way it doesn’t affect legacy data.
Using Vault Revisions is taking lot of our time, if someone accidently changes state of a released file to Work in progress instead of doing quick change there is a Rev Bump and we have to go back and delete file and add it again. There are files with preveious revisions being vaulted for the first time and we have to manually change their revisions. Parents become dirty as we manually change revision for any child and its becomes difficult to release the parent until its checked out and checked back in after capturing the revision for child.
I am leaning towards following two options.
1) No Vault Revisions for all design files, manual revision table in drawings. All design files will be assigned null revision scheme.
2) Vault Revisions and Vault Revision Table only for drawings.
Vault Revisions are new to me. I need feedback from someone who has more experience. I am not sure if using Versions with Lifecycles (file locking) has any downside? The only downside I can think of is getting previous versions.
I think of one of the key reasons for using revisions is more about the historical record than anything else.
Often there are legal implications to what revisions of a part within a specific revision of the assembly.
Using revisions on the models maintains that historical record and makes it easy to retrieve it again when needed.
Here are some ideas that can help. These suggestions wont be applicable to everyone, do what makes most sense for you.
Hope these help.
Thanks for your input. I understand your point regarding maintaning historical data makes complete sence. Attached is our life cycle defination. Quick change is same as edit in your example, WIP is same as commit edit.
What I follow from your suggestion is to get rid of the transition from released to WIP (shown in phantom). Make it mandatory for everyone to go from release to quickchange first (no rev bump) later change state from quick change to WIP if we want commit to change. This way we can avoid accidental rev bumps
I didnt follow this sentence in your post "Change the security on Lifecycle so that only select people can go from Edit to Released and everyone else must always go to Commit Edit first." Why do we want to make it mantdatory for everyone to go to commit edit? Can you please clarify.
It would make more sence if it was "Change security setting on Life cycle so that only select people can go from Released to Commit edit, everyone else must always go to Edit first."
Can't find what you're looking for? Ask the community or share your knowledge.