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 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).
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).
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.
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.
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.
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?
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.
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.
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?
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.