There isn’t any way to set this type of restriction if Subclass B can have other items in its BOM.
If Subclass B shouldn’t ever have ANYTHING in its BOM – you could disable the BOM tab.

Hi Danny,

Yes it does – subtype B has a BOM as well… What I´m trying to prevent is having a user to be able to place an assembly as a component of a bolt (no CAD system involved, of course :))

Thanks for your prompt reply and best,

Clovis Chenaud Jr.

You can check that during a change order workflow and prevent that an item could be released if doesn’t match that condition

Hi, Antonio,

Interesting idea – do you mean we could use a Criteria inside the CO workflow to do that?? However, I can’t seem to find an Affected Item option inside a Criteria to check the item type contained on the Affected Item’s BOM. Pls advise.

If you mean we could only visually inspect the BOM and reject the workflow step so that the user could adjust the BOM, we´ve been doing that – what I was looking for was a mechanism to prevent the user adding an “invalid” component  during the BOM creation.

Your further comments are very much welcome!!

Best regards,

Clovis Chenaud Jr.

Hi Clovis,

It is not a built in feature so it is necessary to create a custom PX to check that. You can configure an Event PX on Workflow change status and set it as PRE Synch event, blocking the execution if fails.
In your code, you will trigger an ActionResult.Exception in case of BOM Check fails, otherwise a normal ActionResult.STRING. In this way, you can customize your checks and have the same result of a Criteria check (with a better and user friendly message)
Let me know if you need an example of JAVA Event PX with that

Hi Antonio,

Yes, I´d really appreciate if you could send me an example for that!!

public class BOMStructureCheckerPX implements IEventAction {

@Override
public EventActionResult doAction(IAgileSession session, INode n, IEventInfo eventInfo) {

IObjectEventInfo event = PXEventFactory.getEvent(eventInfo);
IDataObject dataobject = event.getDataObject();

if(myChecker.checkFails()){
return new EventActionResult(eventInfo, new ActionResult(ActionResult.EXCEPTION, new RuntimeException(“ITEM Doesn’t contain a valid BOM”));
} else {
return new EventActionResult(eventInfo, new ActionResult(ActionResult.STRING,”Check Passes”));
}
}

}

in this case you have to implement the muchecker.checkFails where you have to use your API to navigate into the Affected Items of a change and for each item heck the BOM.

Creating the PX in this way, Agile will prevent to change status on the change if the check fails. 

OK Antonio, thank you very much!!

Best,

Clovis

Hi Clovis.
We have a very powerful yet simple “Change Validator” tool to deal with this type of requirement. The tool is rule-based so the Agile admin can edit and configure rules as the need arises.
The “power” factor is in the validation possibilities this tool makes available.
You can compare values in fields on and between the Change, Affected Item, BOM and AML tabs.
You can configure BOM rules such as “Don’t allow a certain item to exist in a BOM” (I think this is what you need) or “Confirm there is at least one item of a certain kind in the BOM” (good for validating the BOM structure).
You can define conditions on AML and attachments (confirm an item has an attachment of a certain type).
You can validate revision increments and lifecycle phase progression.

If you’re interested I can get you a price quote and demonstrate. We have a “per rule” pricing model that should make the tool affordable even if this is the only rule you need.

Please let me know if you would like more information,

Best wishes,
Jason – jason_r@top-group.co.il

Hi Jason,

Thanks for the information!!

I would have to discuss both options with our customer: either going for a PX customization or your tool.Anyway, it’s good to know there are such tools available on the market!!

Best regards,

Clovis Chenaud Jr.