Community Tip - Did you know you can set a signature that will be added to all your posts? Set it here! X
I find that I have lifecycle or domain policies a little too strict.
Once a EPMDocument is released, user cannot check-out until the EPMDocument is "In Work".
However, the only way for a user to get it to "In Work" is to go through a revision (new rev letter).
We need to allow users to get the EPMDoc to "In Work" and check-out without revising.
At first, I thought to give them "Set State" in the domain policy.
Or maybe enable "Set State" in the life cycle (at Released state).
Or both of the above.
I suspect I might be giving the users too much authority with any of the above.
Recommendations?
Gerry
Several people have asked why we need this functionality.
There are several reason:
Gerry
In Reply to Gerry Champoux:
I find that I have lifecycle or domain policies a little too strict.
Once a EPMDocument is released, user cannot check-out until the EPMDocument is "In Work".
However, the only way for a user to get it to "In Work" is to go through a revision (new rev letter).
We need to allow users to get the EPMDoc to "In Work" and check-out without revising.
At first, I thought to give them "Set State" in the domain policy.
Or maybe enable "Set State" in the life cycle (at Released state).
Or both of the above.
I suspect I might be giving the users too much authority with any of the above.Recommendations?
Hi Joseph
there must be some historical background to maintain 2 different systems to do the same thing. I see, personnally no advantages in doing so. Anyhow to answer Gerry. We have the same situation but we did not grant everyone access to change the state back to development or In Work directly with a Set State. It was difficult enough to explain the users why they needed to change the set to Released at the first place and what a Revision level was (surprisingly enough but there are historical reasons for it). So to ensure released data are revised when they are supposed to be revised and simply change to development when they are supposed to, we have identified and trained a limited but sufficient number of users (we call Super Users) who have the authority to change the state back to development without creating a new revision.
We try to educate our users that a new revision if when any of the 3F changes otherwise there is no need. In case of doubt they ask one of our super users who in turn will reexplain the user the differences and take the appropriate action. Nonetheless, all users can change back to development but only with New Revision
This seems to work pretty well so far.
Gerry
I'll chime in in this one, I think you have created these lifecycle or domain policies correctly and for good reasons. They are not to strict in my opinion and they are the same at most companies. There are also sloppy proe users at every co. I have ever been at that do not follow good modeling practices. "people not using the proper start parts, not using the proper layers, blanking layers that contain needed datums, axis, points etc." Then when they have the model and drawings checked in and released to production. They come back and say I need to change the released model back to in-work without chaging the Revision so I can make some small changes to it?
Simple answer No! I've been burnt by these types of request to many times, engineers or designers come back and say I just need to turn on this layer or create a contruction datum plane I'm not going to change anything else.... yeah I've heard that one before,and then they notice some hole doesn't line up exactly or they add something else to the model that they missed etc... This will later get discovered by a vendor or manufacturing or somewhare else down the line and all of the sudden the integrity of the whole data base is in question!. The answer is a polite No!
Send me an email request letting me know what you need done and I or someone on the administration staff will set it back to in work and turn on the layers, create the costruction datum plane, etc... and set it back to released.
It only takes one inconsistancy in the engineering database to be discovered and from that point on people will not fully trust the integrity of the data.
Dave
In Reply to Gerry Champoux:
I find that I have lifecycle or domain policies a little too strict.
Once a EPMDocument is released, user cannot check-out until the EPMDocument is "In Work".
However, the only way for a user to get it to "In Work" is to go through a revision (new rev letter).
We need to allow users to get the EPMDoc to "In Work" and check-out without revising.
At first, I thought to give them "Set State" in the domain policy.
Or maybe enable "Set State" in the life cycle (at Released state).
Or both of the above.
I suspect I might be giving the users too much authority with any of the above.Recommendations?
Gerry
Dave McClinton
MCAD System Administrator
McKesson Automation
724 741 7760
Thanks to everyone that responded.
Although we cannot do some Windchill things identically as we did in 3.4, all of your input and advice was very helpful in understanding how Windchill is intended to work.
As I suspected, what we want to do is not practical in Windchill.
However, we can develop some new policies & procedures to meet our needs.
Thanks again.
Gerry
In Reply to Gerry Champoux:
Several people have asked why we need this functionality.
There are several reason:
- Some drawings that are not controlled by configuration management, users are allowed to check-out and repromote at the same rev letter. At least, this is what we do in Intralink 3.4.
- Sometimes, a model needs to be tweaked in a manner that does not affect its' drawing. For example: Adding datum features to aid assembly.
- We often have multiple manufacturing plans for a part at a single revision. Therefore, we allow (in 3.4) to check-out a released drawing & planning models, and make changes at the same revision letter. We have parameters to identify the differences.
In Reply to Gerry Champoux:
I find that I have lifecycle or domain policies a little too strict.
Once a EPMDocument is released, user cannot check-out until the EPMDocument is "In Work".
However, the only way for a user to get it to "In Work" is to go through a revision (new rev letter).
We need to allow users to get the EPMDoc to "In Work" and check-out without revising.
At first, I thought to give them "Set State" in the domain policy.
Or maybe enable "Set State" in the life cycle (at Released state).
Or both of the above.
I suspect I might be giving the users too much authority with any of the above.Recommendations?
Hi Gerry,
Due to our experience, I would not recommend to try to implement the I3.4 behavior (allow new iteration at same revision for a released CAD doc).
We had some of those objects in Ilink3.4 and when migrating to PDMLink we discovered that when trying to retrieve 'latest released' objects in an assembly configuration, it would miss the correct iteration. Let explain, you have Part1 in Asm1. Part1 has those version.iteration status :
1.3 Released
2.5 Released
2.6 In work
When you will retrieve (add to WS, or checkout) Asm1, with Latest Released configuration, you will get 1.3 in your Workspace. That was really annoying for us. It's less if you always use As Stored configuration. We've seen other cases (search I think), where the 2.5 iteration was missed by the system.
For PTC, it was working as designed in this case.
No one else noticed this pb in PDMLink 9.1 ?
Best Regards
Xavier LEGER