Skip to main content
P
ptc-41092621-Visitor
1-Visitor
November 20, 2012
Question

Windchill Change Tasks

  • November 20, 2012
  • 2 replies
  • 12700 views

I'm setting up Change management in Windchill which broadly seems to be logical and straightforward, except I'm stuck on one bit.

When a user receives a task to make a change as part of a change activity the part doesn't appear to release to enable the checkout and revise or check out, change and then check in. In the test example i'm using, the part is in a 'Released' state as this is the state we will want to be using change control in, and the lifecycle in that state has 'change' and 'revise' ticked (although revise isn't allowed by the access rules for those users in that state). Presumably I shouldn't be allowing the engineers to normally be revising in this state as this would defeat the object of having a change system?!. I'm missing a key point somewhere, i've hung onto the assumption that 'change' in the lifecycle enables the part to be changed by the assigned user without further permissions, but maybe that's wrong?. The part does have the 'pending change exists' flag so it looks like it ready to be changed and all change admin have completed thier actions up to that point. I'm using Windchill 10.0.. Any help appreciated. Thanks

2 replies

M
MikeLockwood22-Sapphire I
22-Sapphire I
November 21, 2012

There is in fact no different permission OTB for objects on a Change vs. not.

For this exact reason, we:

a) Use state based versioning with a two-phase lifecycle and a Revision series consisting of Numbers, then Letters; each uses only a subset of the states in the lifecycle

b) Allow free Revise for numbered Revisions, controlling only state changes (via Revise permission by state)

c) Restrict Revise to a small group authorized to make approved changes for Letter Revisions; this group only Revises as part of creating / executing a Change Task

This is critical for the business process – infinitely confusing though. Fortunately we had two years to study and play with before going live.

Having CAD or Part objects Revised w/o approved changes can lead to all sorts of headaches if they get used in higher assemblies – gets really hard to back out.

GregoryPERASSO
GregoryPERASSO16-Pearl
16-Pearl
November 21, 2012

Transitions in lifecycle states does not define "Access rights"

the transition LifeCycle "change" is only to set the "resulting" state when releasing the objects through the OOTB Change workflow (a workflow robot will set the resulting objects to this state when your change request will be solved)

the transition LifeCycle "revise" is only to define the "initial" state of the new version of the object

you have to add a revise access rules to the released state, to be able to revise the object ... and then once fixed, add it as "resulting objects" in the change activity. the new version will be promote to RELEASE state (due to this transition) when the Change Request will be closed

regards

Gregory

P
ptc-41092621-VisitorAuthor
1-Visitor
November 21, 2012

Thanks for the feedback, in both cases I think you are saying that I have to have access rights for relevant users to be able to Revise in the Released state for the Change workflow to allow the user to carry out the change??.

I wondered if as 'change' is set to define the 'resulting' state to be 'Released' this would mean I can set 'Revise' to flip it into the In-Work state where access rights allow the change and then once the Change workflow was complete that the 'resulting' state would be back to 'Released', but that doesn't work and leaves the part in the In-Work state, as you might expect I suppose..

We also have a lettered version system for In-Work and numbered for Released, but it just seems wrong to allow a Revise to happen to a Released part and rely on users to not Revise unless they are sent a change task.

Perhaps I'm not understanding what you mean though?

Regards

Paul

GregoryPERASSO
GregoryPERASSO16-Pearl
16-Pearl
November 21, 2012

No, you're understanding right. It's my English that is may be not clear 😉

The philosophy of the Change Management is not to authorized to Revise and modify objects (it is the accessrules's job), but to control that the new Version will be reviewed and released to manufacturing, according to your business process.

notably if you decide to publish the new version to an ERP system ...

OOTB change management workflow will control the target state (the Change transition) ... but also set effectivities on parts, or trigger the ERP publishing ...

If your objects does not change to state RELEASED when the Change Request is closed, just be carefull to put the new versions as "resulting objects" in the Change Activities, under the Change Notice.

And do you use the full set of Change Objects ? (Change Issue > Change Request > Change Notice > Change Activities) I do not rember if , OOTB, it is the closure of the Change Request or Notice workflow that release the new versions ....

regards

Gregory

Terms & ConditionsAccessibility statement