Skip to main content
M
MSC121-Visitor
1-Visitor
July 9, 2014
Solved

Windchill 10.2 Revise on checkin

  • July 9, 2014
  • 11 replies
  • 6290 views

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

Best answer by TomU

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".

11 replies

A
AL_ANDERSON12-Amethyst
12-Amethyst
July 9, 2014

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."

VersionExample.gif

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

    M
    MSC121-VisitorAuthor
    1-Visitor
    July 9, 2014

    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.

    S
    SteveVinyard1-Visitor
    1-Visitor
    July 9, 2014

    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.

    C
    CaitlinWheeless1-Visitor
    1-Visitor
    July 10, 2014

    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.

    7-10-2014 3-16-25 PM.png

    2.

    7-10-2014 4-34-20 PM.png


    3.

    after.PNG

    Terms & ConditionsAccessibility statement