Default Change Task Questions

[pwilliams-3]

Hi Everyone,
We are soft typing the Change Notice to the Engineering Change Notice and the Manufacturing Change Notice. Additionally we are soft typing the Change Task to the Engineering Change Task and Manufacturing Change Task. We also know that Windchill Relationship Constraints does not yet support constraining the relationship between change objects.

With all that said, how can I configure Windchill to ensure that the default task that is created for the ECN is an ECT? Similarly with MCN and MCT? I can't use the preferences to control the defaults because default task is dependent upon the soft type of change notice and should not be a global setting.

Should I prevent the creation of the default task as this PTC/User Solutions post<">http://portal.ptcuser.org/p/fo/st/topic=16&post=91466#p91466> suggests and make the user do it manually every time? If I force this solution, what happens to the object data if the user creates the CN from the right-click menu?

Do you have any better suggestions?


Patrick Williams | Engineering Systems | c: 616.947.2110
[cid:image001.jpg@01CE7E2F.F6473EB0]

[pwilliams-3]

So where in the workflow does this robot execute? I ask this because when a CN is created you must also create a CT. Or do you mean you have a customization within the CN Create Wizard?

Patrick Williams | Engineering Systems | c: 616.947.2110
[cid:image002.jpg@01CE7E44.B3369DE0]

[ddemay]

The other option would be to override the form processor that creates one of
that type. A little messier and of course need one or ability to hire one
capable to maintaining such.

[SteveVinyard]

Hi Patrick, what needs to be different between the ECT and MCT?

In the past, when it was only a workflow difference, I simply handled it in a single universal Change task but altered the workflow to check for what the parent type is (ECN or MCN) and then went down the appropriate branch.


[cid:image002.gif@01CE80D3.A1F0A300]

Steve Vinyard
Senior Solution Architect

[pwilliams-3]

The roles that participate in the MCT are not the same roles that participate in the ECT and the MCT will definitely not follow the same workflow as the ECT. Additionally there might be reporting requirements in the future to tract MCTs vs. ECTs.

Patrick Williams | Engineering Systems | c: 616.947.2110
[cid:image001.jpg@01CE8173.5C9DCA30]

[pwilliams-3]

Agreed

Patrick Williams | Engineering Systems | c: 616.947.2110
[cid:image003.jpg@01CE8175.73BA0290]

[SteveVinyard]

Will a single CT with branching Workflow (different roles too) work for you then? It didn't sound like you needed unique attributes.

[cid:image001.gif@01CE8205.A833FDB0]

Steve Vinyard
Senior Solution Architect

[pwilliams-3]

It might but to be honest I have delved into the roles yet. I just know they will be different. As far as attributes go I don't know if the MCT will have additional/different attributes vs. the ECT.

Patrick Williams | Engineering Systems | c: 616.947.2110
[cid:image003.jpg@01CE82BC.554C7660]

[SteveVinyard]

Roles shouldn't be an issue if you branch things, lots of flexibility there. Yeah your "members" section of the task details might have an extra role or two in it but that would be a cosmetic issue.

[cid:image001.gif@01CE82C6.E28278E0]

Steve Vinyard
Senior Solution Architect

[sdrzewiczewski]

We have used the branched WF for Change Activity Workflow and it is a maintenance nightmare!

When there is a simple change in one of the branches, often times you need to regression test the other Change Notice types.

Yes the approach does work, but less then optimal!

Steve D.