BPM guidance - set custom flag on OrderHed based on custom field in OrderRel

I am re-developing a DPAS customization for SOs with DoD contractors. OrderRel carries the rating/program data with UserCodes, but I want to indicate on the Summary tab, so I’ve added a boolean field to the OrderHed table which I intend to bind to an epiShape. So, my strategy is to trigger a BPM off changes to the custom field on OrderRel and set my OrderHed boolean accordingly.

I’ve been able to copy/modify existing BPMs with good success in the past, but struggling here. How would you do it?

Do you have an appropriate bpm to trigger from?

Or in English, when do you want this to fire?

Whenever someone saves a change that includes these custom fields on OrderRel, ideally.

I’m not sure if that’s update or masterupdate, and I’m not sure if it sends the header row when a release changes.

Can’t run a trace right now, but if you can, that would be helpful in advising you.

I read your comments in another similar thread… I’m not especially good at harvesting tracing data, either - but I’ll re-read and try some things.

If you can’t I’ll run one later, or someone with this knowledge already will probably see it.

If the header row isn’t sent, you’ll have an issue, because if you modify the header outside of the normal operations, Epicor may complain, or you will have to refresh, or both. So some outside of the box thinking, or alteration of your plans may be in order.

you mentioned re-developing. Is this an existing Method?

I was initially thinking Data Directive.

What happens when you have three rels with different UD data? What does the OrdHead represent?

No - the existing version just had the DPAS fields on the OrderHed, which turned out to be not granular enough for the Customers’ requirements. My concern is that fields set on the Rels will be “too buried” and that we ought to indicate this somewhere more visible. So I started down the epiShape rabbithole and that led me here in a roundabout way.

The summary tab should indicate whether any Rels with any level of DPAS rating are present. So, a condition widget would potentially filter the OrderRel data for any “non-zero” values in the primary custom field, and if 1 or more rows come back, then DPAS=TRUE and epiShape should turn orange or something.

We have used the epiShape in a similar way.

Create a BAQ that creates the calculated field (0 green, 1 yellow, 2 red). Then publish/subscribe on the ordernum to have epiMagic do the work. Use the calculated field to drive the epiShape…

then you aren’t needing another field in the DB.

Played with trace logging … and it looks like everything is here. If that makes sense.

I’m intrigued, but not quite following – What executes the BAQ? And I’m not sure what channel we’re publishing/subscribing on. New concept for me.

Believe it or not, we’ve never really adopted dashboards here. We just have lots of queries and some clever Excel work. I have dabbled in it, but none of my users has ever really been able to tell me what data they need in dashboard form, just that they think they need more… I digress.
That said, I digested your suggestion some after hours and I am exploring this path now. I made a super simple BAQ that trades a SO num for a true/false evaluation and put it in a dashboard with default settings. Now I’ll try to get my form/shape to subscribe…

Take a peek at this thread. Might help.

How To: Kinetic BAQ Grid Pub-Sub - Experts’ Corner - Epicor User Help Forum (epiusers.help)