Send to a friend
Print this article

PDMWorks revision schemes
Level = Intermediate

Personal Edition 2004 offers nonusers hands-on experience with SolidWorks software

When setting up PDMWorks®, one of the important decisions made is the revision scheme – the Vault Admin tool within the software.

The Revisions tab offers administrators a number of options in setting up a revision scheme. This document attempts to illustrate how some commonly used schemes could be achieved.

Example 1

In this scenario the customer would like to have a revision scheme where nonreleased documents would have a numeric revision and released documents would have a single alpha character. For this particular customer, the first released document would not have a revision letter, rather it would have a dash character (-) to designate the first release.

An example of this is: 1, 2, 3, 4, 5, -, -1, -2, -3, -4, A, A1, A2, A3, A4, A5, B, B1, B2, C, C1, C2, C3

In the above example, the user created five versions of a document before releasing it as revision -. Then, the dash revision underwent a series of changes resulting in four versions before being released as A. Then, the A revision underwent a series of changes resulting in five versions before being released as B. The B revision underwent a series of changes resulting in two versions before being released as C. Finally, the C revision underwent a series of changes, resulting in three versions thus far. The next version could either be C4 or released as D.

To achieve the above scenario the following setup was established via the VaultAdmin Revision Scheme tab:

The Primary revision field will represent the released revisions and the secondary field will represent the nonreleased revisions. Additionally, it is important to select "Last revision type optional?".

You will notice that the Primary field utilizes a list while the Secondary utilizes a range. A list is used for Primary because additional characters were desired outside of a numeric (1-9) or alpha (A-Z) range. Additionally, a list is desirable when you want to omit characters from a range (many companies omit the letters I (confused with a one), O (confused with a zero), S (confused with a five), and Z (confused with two)). So why @ as the first character in the primary list? This character (it could be something else) merely serves as a placeholder for the first series of nonreleased document revisions.

Let's look at the above setup in action: Create a new part and perform the first check-in. Note that the first check-in is presented as an @. The @ sign is from the released list (Primary) which is not what we want. We want a nonreleased revision.

If we select the revision pull-down we will be presented a list of other available options.

From the list, select @01 to create the first version of the document. Now all subsequent check-ins will create nonreleased revisions until such time as I choose to create a released revision.

In the example below, nonreleased revisions @02 and @03 are created and finally the first released version (-) is created by selecting from the list on check-in.

On the next check-in the user must once again determine if they are creating a nonreleased or a released revision.

Example 2

In this scenario the customer would like to have a revision scheme where released documents would have a numeric revision and nonreleased documents would also be a numeric (appended and separated by a dot [.]). The first released revision would start at the number one (1).

An example of this scheme is: -.01, -.02, -.03, -.04, -.05, -, 1, 1.01, 1.02, 1.03, 1.04, 2, 2.01, 2.02, 2.03, 2.04, 2.05, 3, 3.01, 3.02, 4, 4.01, 4.02, 4.03

In the above example, the user created five versions of a document before releasing it as revision 1. Then, the first released revision underwent a series of changes resulting in four versions before being released as 2. Then, the second released revision underwent a series of changes resulting in five versions before being released as 3. Revision 3 underwent a series of changes resulting in two versions before being released as 4. Finally, revision 4 underwent a series of changes resulting in three versions thus far. The next version could either be 4.04 or released as 5.

To achieve the above scenario, the following setup was established via the VaultAdmin Revision Scheme tab:

The Primary revision field will represent the released revisions and the secondary field will represent the nonreleased revisions. Additionally, it is important to select "Last revision type optional?".

You will notice that the Primary field utilizes a list while the Secondary utilizes a range. A list is used for Primary because additional characters desired outside of a numeric (1-9) range.

So why a dash (-) as the first character in the primary list? This character (it could be something else) merely serves as a placeholder for the first series nonreleased document revision.

Let's look at the above setup in action: Create a new part and perform the first check-in. Note that the first check-in is presented as a dash (-). The dash sign is from the released list (Primary) which is not what we want. We want a non-released revision.

If we select the revision pull-down we will be presented a list of other available options.

From the list, select -.01 to create the first version of the document. Now all subsequent check-ins will create nonreleased revisions until the user chooses to create a released revision.

In the pictured example below, nonreleased revisions -.02 and -.03 are created and finally the first released version (1) is created by selecting from the list on check-in.

On the next check-in the user must once again determine if they are creating a nonreleased or a released revision.

Conclusion

The revision scheme is flexible and can be used in many different ways. Understand what can be done and more importantly, how your company works, and fit the revision to your environment.