Versioning Scheme Question

DarinS · ‎May 21, 2009

All,

Does anyone know of a creative way to generate a revision scheme to allow me to select whether or not to go to the next revision (A to B) or create an interim revision (A to A1). The idea would be to "Revise" an object, but select whether or not it would be a STANDARD or INTERIM revision.

My version history might look something like this:

A

B

B1

B2

C

C1

D

My iteration history (without purging) might look something like this:

A.1

IN WORK

A.2

RELEASED (Revision on print would be A)

B.1

IN WORK

B.2

IN WORK

B.3

RELEASED (Revision on print would be B)

B1.1

IN WORK

B1.2

RELEASED (Revision on print would be B1)

B2.1

IN WORK

B2.2

IN WORK

B2.3

IN WORK

B2.4

RELEASED (Revision on print would be B2)

C.1

IN WORK

C.2

IN WORK

C.3

IN WORK

C.4

RELEASED (Revision on print would be C)

C1.1

RELEASED (Revision on print would be C1)

D.1

IN WORK

D.2

RELEASED (Revision on print would be D)

Windchill version 8.0 m050.

Thanks,

Darin Sensabaugh
Manager-Engineering Services
FN Manufacturing, LLC

avillanueva · ‎May 21, 2009

I do not have a solution for you but I am familiar with this style.
Just out of curiosity, what determines when you go to an interim
revision as opposed to a standard revision? In my case, the standard
revision was customer dictated so we were forced (a long, time ago), to
keep track of internal changes (minor stuff) with interim revisions as
you described. What you are describing is not a series since there is no
end to the numeric portion. If you did it with file based versioning,
you would have to list A, A1,A2 ...B, B1,B2 ..., with enough numbers to
account for the highest case ever possible and continue this all the way
up to the highest letter possible in your company. God help you if you
hit a maximum. You would also have to enable versioning where you could
choose the next revision.

DarinS · ‎May 21, 2009

Our scenario is very similar to yours.

For example: We are contracted to produce a component to revision B, then several months may go by and we will receive a change document from the customer listing several FROM-TO changes (we do not receive a new print). Our contract is modified stating that we must produce revision B, plus changes noted in document number 12345. Instead of controlling both documents we update the print (internally) via a change process, releasing a revision B1.

We check-out rev B as an admin (say iteration D.3), check it back in to create iteration D.4 and then set the state of D.4 to "In-work" allowing it to be modified.

Our current iteration history looks like this.

B.1 IN WORK
B.2 IN WORK
B.3 RELEASED (Print states B)
B.4 IN WORK
B.4 RELEASED (Print states B1)

Doing it this way works, but has an extreme overhead and prevents us from utilizing the full capabilities of Windchill.

Thanks,
Darin

DarinS · ‎May 21, 2009

Sorry, corrected as highlighted below.

Thanks,
Darin

mdebower · ‎May 21, 2009

We also keep track of revisions manually on the drawing. For example, the drawing revision when printed out might say 4, but the actual Windchill revision is 1.7 No correlation at all.

I have pointed out that this only adds overhead and prevents us from using Windchill fully. But when I mention changing, I get stupefied looks, and reactions of "We can't do that! Let Windchill manage the revisions?!?! Why that's preposterous!"

So how have other companies made the switch?

- marc
CAD / PDM Manager

AL_ANDERSON · ‎May 21, 2009

What about adding a typed attribute to your drawing object called "Interim
Release Level" that is a drop down box or an integer that starts at blank
or 0.

You would have to manually edit it after the initial release, but it would
allow you to change it whenever you needed to do so as an update to a
checked out iteration.

For example.

V.Iter State Interim Release Level IBA value, and Print on
Released Drawing
B.1 IN WORK 0
B.2 IN WORK 0
B.3 RELEASED 0 Print states B, or perhaps B0
B.4 IN WORK 1
B.5 IN WORK 1
B.5 RELEASED 1 Print states B1
etc.

Al Anderson

"Darin Sensabaugh" <->
05/21/2009 01:05 PM
Please respond to
"Darin Sensabaugh" <->

To
"Villanueva, Antonio" <->,
"-" <->
cc

Subject
[solutions] - RE: Versioning Scheme Question

HugoHermans · ‎May 21, 2009

For about 20 years, the revision on our drawings is managed by a
database driven application. So far so good. BUT ... our designers
have the possibility to modify a drawing without changing the revision.
Just like in the era of the drawing board. Officially, they only do it
for very small changes. Practically, I see all kinds of changes without
revisioning passing by, for all kinds of reasons. Nevertheless, I have
the ambition to change this some time.

Regards, Hugo.

DarinS · ‎May 21, 2009

I should have mentioned before that we are implementing ERP connector and need the internal revision relayed to our ERP system, if there is no other solution we will be adding a part attribute called "FN Revision" which will be passed via the connector.

The main issue with this process is not being able to use the "Revise" functionality in the ECN change activities and manually manipulating objects outside of our change processes.

Thanks,
Darin

AL_ANDERSON · ‎May 21, 2009

I am not sure that you could "use the 'Revise' functionality in the ECN
change activities" even if Windchill allowed for this kind of interim
revision changing because the ECN workflow wouldn't know when to skip from
a numeric next revision to a new letter with no numeric next revision
unless you rewrote that code anyway. And if you rewrote that code, then
you can write in almost anything you want, including picking up a
concatonated Version + FN Revision value to sent to the ERP system as a
single value. In other words, you could have Revision A with an FN
Revision attribute of 2 go to your ERP system as "A2." Alternatively, you
could modify your ERP system to add an attribute called FN Revision so
that you send Revision A and Interim Revision 2 as two separate values,
"A" and "2".

Al

Darin Sensabaugh <->
05/21/2009 01:26 PM

To
"Al X. Anderson" <->
cc
"Villanueva, Antonio" <->,
"-" <->
Subject

avillanueva · ‎May 22, 2009

A thought occurred to me with this topic since we are talking about
ECNs. The processes of "re-releasing" items in the same revision branch
will fall apart with ECNs. As far as I know, the affected and resulting
items sections of the change activity task link to a version of an
object. When clicked, you are directed to the "lastest" iteration of
that version. So, a user would see an item going from B to B on the ECN.
If they wanted to inspect that item, they have no clue as to what actual
iteration is the affected item.

DarinS · ‎May 22, 2009

After reviewing the file based versioning scheme documentation (albeit the logic would be quite lengthy), the user would have the option to revise revision B to either B1 or C.....if the revision was D2, the option would be D3 or E and so on.

I think this would work with the ECN process.

Agree.....Disagree?

Darin

avillanueva · ‎May 22, 2009

Yes but users can make mistakes. Related items could get out of sync.
Say they choose C when it should have been B2. You would have to delete
C and re-revise. Messy if already on EC and work has been done.

ptc-4452123 · ‎May 26, 2009

2 Thougths, though you may have to do further research to see how they are used with effectivity, part configurations and part instances.

1) "New One-Off Version" - allows you to create a special copy of a version of an object that can be modified and is based of the initial version taken

Per PDMLink Help: A one-off version is a branch version taken from any version within the normal version sequence (for example, A, B, C). A one-off version is labeled with the version from which it is created, followed by a dash and number, such as B-1. This one-off version is used to record a unique modification to a released design. It is intended to support the modification of parts that have been recorded in a configuration, used to create an instance, and then modified. The fact that a part has been altered must be recorded in the system, so a one-off version of the altered part is created.

2) A new view based on the part.

Per Business Admin Guide: Within Windchill, a part is assigned a view when created. A part may be view-dependant object, if serveral versions of the part are required to address the needs of various organizations working on it.

Therefore, all design parts could be of the view "Design". Any changes to the design forced by the vendor afterwords can be created as a "New View" version (ie: Manufacturing). Therefore as you do these post "revisions" of the part, you are always revising the Manufacturing View. Therefore you can look at the latest full view, ie: A (Design), or you can look at its "minor" revisions, ie: A.A (Mfg), A.B (Mfg), A.C (Mfg), ... until there is a complete "Revise" to B (Design), where it starts over again B.A (Mfg), B.B (mfg), etc.