Windchill 10.2 Revise on checkin

[MSC12]

Is there a way to choose for a file to advance the version of a document or CAD file when it is being checked in? It can be done after it has been checked in but that is AFTER a new iteration has already been made.

For example:

File.doc Version A.1 is checked out, revised and checked back in. This a new version and idealy I would like to be able to specify that so when I check it back in it becomes File.doc Version B.1. What happens now is it auto advances the iteration to A.2 then I have to manually "revise" it in windchill to be B.1. I can see this causing confusion in the future because the file history will say A.1-->A.2-->B.1 instead of A.1-->B.1.

Is there a setting or option I am missing that will allow me to do this? Has anyone run into this before? Thanks

[AL_ANDERSON]

This should not be your process: A.1-->A.2-->B.1 .

Instead, if A.1 is "Released" and you want to make a revision, then you would do this: A.1 --> B.1 (inheriting the A.1 content initially) --> B.2 (after your update the object to replace its content file).

By definition, Windchill's version control scheme works like this.

"Every revisable object has a version. A version consists of a letter followed by a separator such as a period (.), followed by a number (for example, A.1). The letter represents the revision of the object and the number represents the iteration of the object."

Your original post seems to want no iterations, but only Revisions. ProjectLink, interestingly, has both a Revision and an Iteration, but it does not "Revise" - it only Iterates. In Windchill, you get the full Version allowing you to create an In Work Version, update it, possibly rework it, and finally Release it - freezing that Version and therefore forcing you to make a new Revision to a new In Work Versino in order to make a change.

Al

[MSC12]

I do not want A.1-->A.2-->B.1 to be the proccess. A.2 and B.1 of those are the same file and it could cause confusion. I want to find a way to advance the revisions without creating a new iteration before hand

Youre suggesting the better way to do it would be to 'Revise' the file before any changes are made so insead of A.1-->A.2-->B.1 it is A.1-->B.1-->B.2 with A.1 and B.1 being the same? That seems more confusing to me. Iterations are only used in our costing process. Everything is A.X until it has been approved for production then it gets moved to B.1. Maybe I am misunderstanding the way windchill handles versioning.

[SteveVinyard]

Al is right on here. I also tend to try to get away from any sort of "Smart Revisioning" scheme as well. No intelligence built in as its too limited and has holes in the logic. Lifecycle State does a great job of indicating the true maturity of a part (In Work, Under Review, Prototype, Release, Obsolete). Its also not coded and in plain english and you can have dynamic watermarks based on it as well to further protect your IP with no extra manual labor required compared to manually revising an object just so it can then be released.

[MSC12]

So there is no way to revise a file without creating a redundent copy in that files history?

[SteveVinyard]

Correct, not without customization. FYI I don't view that as a negative either.

[AL_ANDERSON]

We created a Custom Java service that listens for "Revise" on documents of light Type "Drawing" (our WTDocument subtype) and automatically removes the primary content that is inherited from the original revision. We had trouble with this customization and even had to back it out of production the first time we deployed it, then fix it to avoid conflicts with another customization we have, then put it back in. Moreover, we had to make a site-Preference to do this change by context since all Data Owners could not agree on whether they wanted this change or not.

In general,I would like to see a PTC enhancement that allows for a Preference to "Inherit Content on Revise" where the default "Yes" is what we have now, and "No" erases all primary and secondary content on the new revision for all documents in a context that has that "No" preference.

Would anyone vote for that idea? If I see a bunch of people who like it, then I'll log the idea and we can vote for it.

Al

[TomU]

This is probably going to sound nuts, but I'd rather see the revise action only happen to the temporary copy of an object that is created when you check it out. If you decide to delete the revised and checked out object from your workspace (without every checking it in), then the revise effectively never took place. Fundamentally I think its crazy to make the last iteration of one revision exactly the same as the first iteration of the next revision.

If you want to change something that's released, you should do a "revise and checkout". If you later cancel the checkout, the revise should be cancelled (or undone) as well.

The first iteration created at a new revision should actually be something new.

Right now, for every single revise you do, you have a corresponding version that (as far as I know) isn't good for anything.

[MSC12]

Tom, that is exactly what I am trying to say. You worded it much better. I imagine a senerio where someone goes to make a part change, says "Dont send off Rev B, its being changed. Send off Rev C!" and as the part is being changed, Rev C.1 gets sent off even though it is the same as Rev B.X.

Realistically this probably wouldnt happen but like you said, fundementally it doesnt make sense to have the same part listed as two different revisions

[Marco_Tosin]

Al,

I'll sure vote your idea.

Thanks

[TomU · Accepted solution]

Like Steve said, what you're missing is the state change. If everything is left at "in work", then there is nothing stopping you from continually making changes to the "released" A.1. Someone can create an A.2, A.3, A.4, and so on. By promoting (or manually changing the state) of A.1 from "in work" to "released", you effectively lock the 'A' revision series from any more changes (new iterations). Once the state has been changed to released, the only way to get permission to make new changes is to first revise to 'B'. This process makes a copy of the released version to the first iteration of the new revision (A.x --> B.1).

To help prevent confusion here I have the copy forward functionality for representations turned off on the revise action. That way if someone tries to view any first version objects (that have been revised but not modified yet), they won't see anything (in Creo View). In a perfect world, permissions would be setup so that people who are viewing the information (but not creating it) would ONLY be able to view information once the state is set to "released".

[CaitlinWheeless]

Short-term workaround on a more granular level: With regards to documents, you can achieve this using the "Insert Document" action. (You can also do this with a part.)

1. Doc 1 A.1 --> checkout to lock/hold OR just don't check it out
2. Modify the primary content
3. Perform the Insert Document action. Here you can upload the modified primary content and set the same attributes you would set during a check in operation.
4. Results:
   Doc 1 A.1 -- old content
   Doc 1 B.1 -- modified content
5. If you checked out Doc 1 A.1 to lock it, you can just perform an undo checkout

See "Inserting a Document"

Limitations -

• Straightforward but requires a little more effort.
  • The Insert Document window includes a step where you are required to copy/paste the object number to find it. You can't preselect the document like you can with check in/revise.
  • You are required to upload/change the primary content. There is no option to keep the existing file and modify the attributes only.
  • It is essentially treating the action like a New Document action. Meaning that if there are required fields in a New Doc layout, they will also be required here. However, you can use the Type & Att manager to change some of this.
  • The "Revision" field is a little clunky. It doesn't automatically assign the next revision label unless you click the "Select Revision" button. Not difficult; just more clicks.
• Only available from Folder Contents > Actions
• No Collect Objects step as there is for the Revise action
• Can't contribute checkin comments

1.

2.

3.