Method Directive to prevent save if conditions are met

BKen · March 4, 2021, 9:47pm

I am putting together a Method directive that will prevent Confirming a PO if any releases have one of 4 GL codes.
My first condition looks like (to fire when someone tries to save with the confirmed checkbox true):

My second condition looks like (to only look at releases with trans type Other):

My third condition looks like (to see if it has one of the 4 bad GLs):

So when all three conditions are true, then I raise exception and my message pops, but it does not undo the “Confirmed” checkbox and allows the record update to process.

So I tried to just show a message (telling the user the GL is wrong) and then used a Set Field widget to uncheck the checkbox. That works, but if I hit refresh, the record has already saved as “Confirmed”. I have even tried to add the Invoke BO Method (to update the PO with the Confirmed unchecked) but that had the issue “Business object method parameters not mapped: ‘ds’”.

Can anyone provide me with tips or tricks to get this BPM to either stop the attempt to save, or undo the Confirmed checkbox and re-save?

Jonathan · March 4, 2021, 9:53pm

Are you using a pre-processing directive on the correct method(update, updatemaster, etc)?

Can you access other tables like ttPORel/ttPORelTGLC from this method?

Keep in mind I don’t work with BPMs so this might be obvious.

BKen · March 4, 2021, 9:58pm

@Jonathan I am using a Post Processing Method directive on the Erp.BO.PO.Update
from there I am able to access the ttPORel and ttPORelTGLC and those pieces are working.
My problem is when I use the Raise Exception widget, it still saves the Confirmed checkbox (in stead of preventing that save from taking place).

Jonathan · March 4, 2021, 10:01pm

That is the problem, the Update has already happened and processed the PO, if you want to prevent it then it should go before the actual Update.

BKen · March 4, 2021, 10:06pm

So should I be using a pre-processing? When I started down that path, the tt data was null, so my conditions all were showing up false.

Jonathan · March 4, 2021, 10:28pm

As far as I know yes, how the bpm would be constructed I’m not sure.

I think this could also be done as a UI customization, assuming these tables are part of the client dataset.

See another similar thread

BKen · March 4, 2021, 10:51pm

So I have tried a pre-processing Method Directive, but the ttPORel.TranType is null, the ttPORelTGLC.SegValue1 is null, so I cannot determine if my conditions have been met. I am able to see that ttPOHeader.Confirmed went from False to True and I put a message after that (to tell me what the previous two fields are; TranType and SegValue1).

Here is the message fields:

Here is the message when it pops (all are null, that is why I jumped to a post processing method directive):

Jonathan · March 4, 2021, 11:02pm

You might need to use some custom code to actually query the db context and get the additional details for the validation.

Hogardy · March 5, 2021, 1:23pm

You are indicating ALL ROWS. I am reading this as if all rows must = PUR-UKN.

I never used this. but it my understantding… ?

For exemple for myself I wanted to prevent saving if the detail classid was missing.

Then used the exception message to prevent saving…

Pierre

ckrusen · March 5, 2021, 2:02pm

First off, do you really want to check on the change of the Confirmed box? I’d think you wouldn’t want to be able to Approve a PO with “bad accts”

Either way, I think you’re going to need to use a condition type of “The number of rows in the designed query …” to determine if any of the releases meet your condition. Because the some of the data you want to check (the GL acct on the release) isn’t being updated when the Confirmed box is checked. It was most likely already saved.

jkane · March 5, 2021, 2:23pm

I agree with @Hogardy , I would use Changed and Unchanged.

I also agree with @ckrusen , it would probably be best to do it before approval.

Also, not sure if the data is there, but I would think about checking the line level instead of the release level for the data.

ckrusen · March 5, 2021, 2:28pm

Waiting to do the check when the Confirmed box is checked makes this much more difficult. Typically, the PO has already been saved (i.e. Updated), back when it was approved. Setting the Confirmed box will only update the POHeader. So you’d have to check the ttPOHeader.Changed, but the PORelTGLC (not the temp table) for already saved Releases with the offending GL Acct.

BKen · March 5, 2021, 2:32pm

Pierre,
I agree that I do not like how the phrase is written, but based on the choices available, I suspect this is a setting to determine which rows are being evaluated (the added row, the deleted row, the updated row, the changed row, all changed rows, or all rows).

So I suspect, it is not stating that all rows must equal “PUR-UKN”, but evaluate all rows to see if at least 1 equals “PUR-UKN”. In my post-processing Method Directive have confirmed that even though not all rows are “PUR-UKN”, that my condition for all rows does become true.

ckrusen · March 5, 2021, 2:42pm

The following should work:

edit

The below has a bug. See about 4 posts down for the fix

end edits

Set PONumStr widget expression:
ttPOHeaderRow.PONum.ToString()

Condition0:

Query in Condition0

BKen · March 5, 2021, 2:43pm

Calvin,
We want this set on the Confirmed box because many of our POs are time sensitive. We do not want to slow down the issuing of a PO, but we do not want to receive the goods in with a wrong GL (and we have this set on our company config).

For this reason, we want to check the GL when the confirmed checkbox goes to true. You are right, that there are probably no changes or updates to the lines or releases at this stage, which is why I was evaluating All Rows. My post-processing Method Directive conditions do become true.
Is there a better way to prevent the Confirmed checkbox change if one of my conditions is true?
Should I be using a Pre-processing method directive? But then my tt are null. On a pre-processing MD what widget would I use to query the table to find out if any rows meet my conditions?

ckrusen · March 5, 2021, 2:48pm

See my post that came in while you were composing yours.

There is a shortfall, in that the Confirmed box on the UI would remain checked, even though POHeader.Confirmed is not true. A refresh of the UI form would update this UI field.

The MD’s workflow I described, may work in a In-Tran DD on POHeader. And that, I believe, would keep the UI in synch with the DB tables.

jkane · March 5, 2021, 2:49pm

I am pretty sure that “All Rows” means that all rows must match the condition.

ckrusen · March 5, 2021, 2:53pm

I found a bug (or two…) in my solution… it would bomb on updates to that didn’t touch the ttPOHeader table. Because with no data in the ttPOHeader table, the “Set PONumStr” widget’s expression would raise an error (can’t use the .ToString() method on a null)

Put the two conditions into two separate condition widgets:

The first checks for the change of ttPOHeader.Confirmed You have to do this first, to see if the tt POheader table even exits. If it doesn’t then you couldn’t set the PONumStr variable.

BKen · March 5, 2021, 3:34pm

Calvin,
I have not used a condition of the query before, but it is really nice. Here is what mine looks like:

So is there a widget or way to refresh after the raise exception (to show the checkbox’s true state)? Or should I set the Confirmed field to false, show a message, and then is there a widget to save at that point?

ckrusen · March 5, 2021, 3:38pm

The “Raise an Exception” widget prevents the BPM from completing. So the Confirmed flag is actually still not set. In that Exception widget you can display a message to the user that the Confirmed flag was not set, and that they need to refresh their screen.

Luckily, since the Confirmed field can only be changed on an Approved PO, no other fields could have been changed, and not saved.