Save revision rows at each revision bump regardless of "Released" versioning.

[f_calebh]

I'd like to the ability to save Revision Row contents between every revision bump regardless of released versioning.

Currently when a revision is bumped, unless the previous revision row was "released", the row is overwritten.

As an example: Revision 0 was active the last time the document was "Released".  The next project may have 5 different revision changes prior to it being released again, and this is the result:

All information between 0 and 1.5 is lost.

During this project example. The secondary revision level was bumped 5 different times, but each time the secondary revision was bumped the row was overwritten and the descriptions of what happened during the previous 4 bumps is lost.

The only way to make these rows stick at every bump would be to release the print at each one of these bumps. This is not possible during many design processes.  During development phases I need to track changes to a document before it's actually released.  

As one example:

A designer designs a component and this document is sent out to a supplier for quoting purposes. During communications with the supplier, some modifications to the component are deemed necessary. The designer will then make these changes to the document and re-submit the quote with a new revision level.  It's possible that this document may be updated multiple times during the design process prior to the document being released. (Our company uses secondary level bumps during the design phases and primary level bumps for each document release)

We lose an awful lot of design information in our revision blocks because I'm unable to simply choose to save rows at each bump.

[ihayesjr]

@f_calebh 

Thank you for posting the idea. Can you tell us why it is important to include each secondary revision bump in the revision table? Most would only want only the last version of the revision in the table. The history is kept inside of Vault with each version of the drawing.

[f_calebh]

Sure,

It gives visibility of changes throughout the design process without needing Vault access. It also provides a single location for all historical changes in the most important location. The document's rev block.

We have many document consumers who don't need file edit controls and as a result don't have a Vault license. This gives them visibility of all the changes involved in the design process by simply viewing the visual file.

We have our own PDM system that provides visual files of documents related to various "change orders". If the visual file doesn't show this information there's a good chance that key changes to a document aren't identified or even realized during this review process. A key revision description identifying a change for one of these document consumers could easily get missed.  As an example, the last revision bump may be relative for the purchasing department but that will hide a previous bump related to Quality control.

We also review our documentation at the end of a project prior to release, so this would give the reviewer or redliner visibility of all changes that were made throughout the project by simply opening the dwf for redline purposes.  That approver is basically approving all those secondary revision bumps for the final approval so it makes it difficult if the information needs to be found by shuffling through the file history tab in Vault.  It's a huge convenience factor in this regard.

I didn't have these columns in my snippet, but we also include the drafter's name and date with our revision rows so we can see what drafter made what change and when they made it by simply looking at the print.  Available in Vault, but again, it's very helpful information when working on a team with multiple members who may not all have Vault access. The Project Manager may just want to look at what changes have all been made throughout a print's project lifecycle, and showing it on the print in the revision block, gives them that summary. 

[f_calebh]

@ihayesjr 

I would also mention that not having this option conflicts with some ASME documentation.

ASME Y14.35.

Section 5.5 - Revision Symbol

Our company doesn't use Revision Symbols, but if we did; without maintaining revision rows, Symbols referencing specific revision levels would have no reference.

Section 6 - Recording Revisions:

"Changes to drawings shall be recorded in the Revision History Block. "

Overwriting previous history prevents this from being achieved.

Honestly, nowhere do I see the overwriting of previous revision explicitly allowed outside of section 6.1.3 which is specific to the Description column and related to an individual revision level.

As I mentioned in the previous reply, All revisions should be approved according to ASME Y14.1.  Since we approve secondary revisions together during the design phase, It's hard to approve revisions or indicate revision approval if they're not shown in the Revision History block.

ASME Y14.1 

Revisions of Engineering drawings and associated lists shall be in accordance with ASME Y14.35. Revisions to drawings and associated documents require appropriate approvals or approval indicators.