Multi-level configurator mystery

We noticed something weird in a multi-level configurable BOM that we’re developing, so I tried to recreate it in isolation. And it worked… sort of. But I can’t get it to work consistently. I’m not sure if it’s even intended behavior. If it is intended, I’m not sure what triggers it.

In the original multi-level BOM, we have three levels of assemblies: Grandparent, Parent, and Child. Grandparent and Child have configurators. The interesting part is Parent. The revision has “configurable” checked, despite the checkbox being disabled in the UI because Parent has no configurator of its own.

I reasoned that Parent is configurable because it has configurable materials, so this is what I tried to recreate in isolation. I created a new Child with a configurator and confirmed that everything works when it’s put on a quote or order. Then I created a new Parent with no configurator and Child as a material. When I saved and approved everything, “configurable” was not checked on the Parent revision. But then later in the day, it magically was! The mystery is exactly when and how that happened. Any idea what makes Epicor notice that a revision has configurable materials?

Things that don’t trigger it: reapproving the parent revision through the Engineering Workbench, reapproving the parent revision in Part, and reapproving the child configurator and revision in Configurator Entry.

@KevinK That is really odd. I don’t have a solution for you but have you tried change logging that field? I don’t even know if it’s available but seems like it should be.

Alternatively is there a configurator tied to the parent part? I thought that was a requirement for the configurable check box?

This is a shot in the dark, but have you checked the actual database field value to rule out some kind of bug in the UI?

I vaguely recall having similar weirdness with the Configurable and revision Approved checkboxes a while back and it turned out to be a Part Maintenance issue. That was the WinForms client and like v10.0 or 10.1 though.

PartRev.Configured is true in the DB on the parent part that has no configurator. We’re leaning toward Regenerate Configurations being the thing that sets it.

It makes sense to me that it’s set. But it seems like it could and should be set when the revision is checked in.