Maturity phase change without Revision.

[lgrant]

Wondering who has implemented this?

I did at one med device to allow pre-production CAD items to be promoted to Production when no data had changed if they provided appropriate supporting (validation) documents in the change.

Why:

Forcing a revision creates work that is not needed for the data authors and approvers.

We use the same rev scheme and we can watermark / stamp (cover page) to show the effectivity and state.

[Catalina]

Hi @lgrant 

Thank you for your question. 

Your post appears well documented but has not yet received any response. I am replying to raise awareness. Hopefully, another community member will be able to help.

Also, feel free to add any additional information you think might be relevant. It sometimes helps to have screenshots to better understand what you are trying to do.

Best regards,

[joe_morton]

Yes, this is how we operate. For us, new objects start at revision A.1 with state Work In Progress. They iterate until ready, say A.15, then the user promotes to a released state for prototyping. A.15 is now in the state for Prototype. If there are no further changes to the design (just additional documents), revision A can go to Production. 

If a design change is needed at any point, the user starts a new revision and the design goes to B.1 with state Work In Progress again.

[Ladric]

Hi @joe_morton 

Good to know. We are considering using a different Version series for just the State change.

Something like this:

In concept/development it would be 1.Iteration, 2.iteration (1.1 IN WORK, ... 1.5 Concept, 2. 1 IN WORK... 2.4 Development)

then the Version that would be promoted would have a number added to that Revision if it was not revised.

1.5 Concept would become 1.1.5 Development.

The second digit would only be used on that state change.

1.5 Concept -> 1.1.5 Development, A.1.1 Production

If 1.1.5 Development was revised it would be 2.1

When A.1.1 Production is revised it would be B.1 

In this way, there is what looks like an iteration in the History table with the new change listed above the previous change and a new date etc.

Since the Revision does not change, the associated objects that may reference that version would not need to be revised.

The only issue would be objects that change from numeric to alpha if the associated object had a table that named the Rev. Not all our objects start at numeric and move to alpha.

[joe_morton]

Hi @Ladric

Thanks for the follow up. To be honest, I didn't really follow that completely. From the bit I did follow, I see a red flag I'd recommend you review before proceeding.

The normal Windchill versioning, as you know, is Revision.Iteration but there is at least 1 case where a 3rd indicator is used. You should be extremely careful adding a 3rd indicator and make sure it will be compatible with these cases (and possible more I'm not aware of):

• Projects - These use a 3rd indicator. If you checkout A.1 from a Product/Library, it can be iterated within the Project as A.1.1, A.1.2, etc. When it is checked back in, it will become A.2 in the Product/Library. 
• Manufacturing BOMs - I'm not as knowledgeable here, but there are cases where a 3rd indicator is used

In both of those cases, the 3rd indicator is a lower type of change than the iteration. I think your concept is problematic because in the example you gave, "1.5 Concept -> 1.1.5 Development" the new 1.1.5 would look like the 5th update to 1.1.

[Ladric]

Good Point. BOM Transformer (MAPSB) does not use a 3rd indicator now (use to do that).

This would be a different Revision scheme that would only be used when it makes a maturity change then it would move back on the next rev to the "normal" scheme of rev.iteration.

I will check on Projects to see how that works.

[rhart]

We use a lifecycle with two version series. In the development phase a custom version series is used P1.1, P1.2, P1.3 with several LC states reflecting maturity of the development and can be revised to P2.1, P3 etc

When devepment is complete and the objects are in an approved state they can promoted within the same LC to the next phase (called Detailed Design) which uses the 1.1, 1.2, 1.3 version series.

The promotion workflow revises automatically, it is extra work to promote everything but how much extra is up to you since you define the workflow. We have just two steps which are promotion request and promotion approve.

New objects can be initialised in the dev phase or detail phase based on whether an OIR is enabled in the context. If the OIR is enabled, the object initialises in the development state at version P1 and if not the new object is version 1.

[lgrant]

Yes, same concept. We plan to add a new State name (like Phase Change) and that would use a different Rev scheme on that state in the lifecycle. 

The first time that promotion process is used to move items from Concept Approver to Pre-Production or Pre-Production to Production, the items would Revise in the workflow but copy the Rev letter used and add a _1 to that Rev.

So if A.3 is promoted from Concept to Pre-Production it would be A_1.3

If it is revised by the user (Action/Revise) then it moves back to the In Work state and that uses the same Rev scheme as it started with and the result would be B.0 In Work.

The only trick is that we need a helper to check what rev letter is being used so when it goes to Phase Change it picks that starting letter in it's rev scheme (C_1, or F_1) and then again when it is revised it needs to move to the normal Rev scheme at the next letter used in the Phase Change, (D.0, G.0).