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.
So there must be some way to refresh the display (perhaps using “Execute Custom Code” widget)?
I suspect that users may not always read the raise exception message, so they will think they have confirmed the PO and move on but the PO will remain unconfirmed (but the display will look like it is confirmed).
Calvin,
If you post this link in this thread (the one I started), I will mark your post as the solution (I did not start the other thread, so I cannot mark your post in that thread as the solution). That way the post marked with the solution will link to the other thread (and you will get credit for the solution).
Have you ever discovered a way to refresh the display as you were trying to in this post? I have been looking for this specific solution for a number of BPMs and this specific function would be so helpful, because, as you mention, users don’t bother to read any message that isn’t an error.
Thanks for any help or insight you may have.