Flexible Change and Resulting Object cardinality

[mwaite]

Under "Legacy" change there was a built in rule that prevented a revision from being the result of more than one Change Notice.  As soon as someone tried to add the revision to the results table of a second task, Windchill stopped them and threw up an alert telling them they could not do that.

That rule does not seem to be enforced under "Flexible" change.  I can have Rev A of the same Document be the result of any number of Change Notices.  That doesn't make sense in our company.

Does anyone know if there is a way to configure that rule in Flexible change?

[PASI-Consulting]

Hi 

Isn't the idea behind flexible change is to be able to manage cardinality between objects as you want ? have you tried to check if cardinality rule can handle your case ?

Regards

[mwaite]

Using article CS268023 as a reference.

https://www.ptc.com/en/support/article/CS268023



The relation between the Change Task and the Resulting object is ChangeRecord2.

That didn't change with Flexible Change.



In past versions of Windchill there was a rule that the resulting object could only be in one ChagneRecord2 relationship.

That is no longer the default behavior.

I don't see a way to configure that behavior with the Change Association rules.

[d_graham]

Hi,

I usually write a listen to handle situation like this.

In short, you have a standard and you want the users to be forced to comply with it automatically. Correct?

If I understand you correctly a listener can be written to listen for the event in question. In this case, adding a resulting object to a Change Activity.

When your listener is triggered by the event code runs that checks if the standard is adhere to.

If it is not an exception is thrown which presents a window to the user with whatever you want to explain to them. In this case maybe something like object X is already a Resulting object on Change Activity Y on Change Notice Z and cannot be added to a second open Change Notice.

Is this the kind of thing you’re looking for?

David

David

[mwaite]

Hi David,

Thank you for the response. I see how that would work, but ...

we have a strict "no customization" policy.

I know there is a fine line between configuring and customizing.



This used to be "Out of the Box" functionality in 10.2.

I'm hoping there is a way to "configure" Windchill to go back to the old behavior.

It's baked into all our training.



If Document 123 Rev A is a result of more than one CN, then the first CN to finish sets the state to "Released" and the second CN has lost the capability to re-work that Document.



I have a ticket open with PTC. Waiting to see what they say about it.