Skip to main content

We’ve noticed some strange behavior with Control Plan triggers and SO status; it’s possible to have an SO header move to “Started” (which correctly triggers a control plan) but with a certain sequence of operations (If product is issued to a shop order, the SO header status goes to Started, then if it’s unissued goes back to Released, then re-issued, back to Started again)

Below is an example of an order that spawned three Control Plans, but we’ve seen many more orders with just two. It looks like there’s no duplicate detection on the start shop order trigger; is there a better way to handle this? Is this expected behavior?

IFS Apps 10 UPD 21

 

 

Hi @JBurke-HexA,

 

I checked this in IFS Cloud 24R1 (the latest) and observed the same behaviour at there as well. Each time the Shop Order goes to Started state an Analysis is created, no duplicate detection.

This is the intended behaviour as per the help documentation as well.

If you want to avoid this then I believe you will have to go for a customisation.

 

Workaround

 

Or, you can set the Trigger Type as “Manual” in the Control Plan. So the user can manually create an Analysis for the Shop Order.

 

To make sure that the user does create an Analysis, you can add that as a Subtask Work Guideline Type in the Shop Order Operation Work Guidelines.

This will ensure that the Analysis is created by the user before the Shop Order is closed.

This is a known drawback, so from 24R2 there will be a new trigger “Start Operation” this will trigger when the Operation is Started only, so it will have no effect from material issue and un issue. 

Reply


Terms & ConditionsCookie settings