Windchill Change Tasks

[ptc-4109262]

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

[MikeLockwood]

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]

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

[ptc-4109262]

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]

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

[GregoryPERASSO]

I confirm, OOTB, it is in the Change Notice workflow that the "resulting new versions" Objects are released.

You do not need to create a Change request, but at least a Change Notice and a Change Activities (and put the new resulting versions in the Change activities)

[ptc-4109262]

I think I understand how all this fits together now, I had to allow assigned users to be able to Revise while in Release state (which still doesn't quite make sense to me) but with this done it all works very well. We are using Problem reports through to, requests, notices and tasks although we will probably do it all in Fast track as we are a small comany and in most cases we are not required to assess the fate of stock etc as a review board.

I also missed the point that we would need to be creating 'resulting objects' as part of the task first rather than a CAD user just being assigned the task and carrying out the change in Creo and checking back in, then confirming they have completed the task (although this does work as well).

Thanks for the help

Paul

[MikeLockwood]

In English, "Revise" is pretty much same as "Edit" or "Amend" or "Modify," etc. In Windchill, Revise means to leave the old one alone and "Save As" for the new. So, given Rev B Released, Revise results in Rev C, In Work.

For a change, Rev B Released is the Affected Data, Rev C is the Resulting. A (very important) robot in the Change Notice workflow sets all Resulting Objects to Released (or as mapped in the LC for the Change transition - or as mapped to the selected state if this is used, as of 10.x).

[GregOlson]

Mike,

Would it be possible for you to post pictures of what your robot looks like and the text associated with it to push resultant items to released? We are having issues with CN leaving items at Under Review....I just want to make sure I have it correct.

Thanks,

Greg Olson

WC Admin

[MikeLockwood]

We're using the OTB robot - which only has one line of code that calls the OTB method.

The problem must be in your lifecycle "Change" Transition.

If you like we can have a web session to look at it.

[GregOlson]

Mike,

I am thinking that the OOTB got changed somehow....could you send me the line of code that is called out?

Thanks,

Greg

[MikeLockwood]

In the OTB Change Notice workflow template, it's the robot labeled "Release Changeables." These two expression lines exist - only the first has effect unless you have the Airospace module with hanging change.

com.ptc.windchill.pdmlink.change.server.impl.WorkflowProcessHelper.promoteChangeables((wt.change2.WTChangeOrder2)primaryBusinessObject);

com.ptc.windchill.pdmlink.change.server.impl.WorkflowProcessHelper.approveHangingChanges((wt.change2.WTChangeOrder2)primaryBusinessObject);

the method is "promoteChangeables" - this acts on the "Resulting Objects" on all related Change Task objects according to their lifecycle Change transitions.

[GregOlson]

Mike,

Huh...that's exactly what we have. If you have time for a webex this afternoon that would be great! I'll message you with my email and phone number.