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).
You might need to use some custom code to actually query the db context and get the additional details for the validation.
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
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.
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.
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.
The following should work:
The below has a bug. See about 4 posts down for the fix
Set PONumStr widget expression:
ttPOHeaderRow.PONum.ToString()
Condition0:
Query in Condition0
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).
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 am pretty sure that “All Rows” means that all rows must match the condition.
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.
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?
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).
You might want need to do your check in a UI customization.
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).
Here:
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.
I think many people may be using the widget “Invoke BO Method” and call GetByID to refresh the display.
Give it a try and let me know if this works.
