Hi,
I am trying to use the Method directives to check the status of the PO Order enter where the status is pending to send an email notification.
I have turned on the tracing and use the “GetList” but it doesn’t seem to detect the approval status. I also try to use the “update” method and some other methods that I found in the trace log. All don’t seem to work.
Does anyone know what could be the cause?
The changed field is only going to be able to know if it’s changed if it’s one of the methods that have 2 rows. (the unchanged and the changed). The get list method is simply a method to return something from a search. So there is nothing “changed”.
Update should be what you want. Start with simple message box pop ups to see what’s happening. Start with no criteria, and makes sure it’s firing when you expect. Update fires when you hit save, and sometimes when you change records. But it usually doesn’t fire when just just change something on a record.
A good tool to be able to watch traces as they happen is baretail. You can open the trace and it doesn’t lock the file, so you can watch it as it’s writing the trace so you know when the call is actually happening. It helps trying to figure out if the call is actually happening when you expect it to.
@gohhy You look to be going about this correctly with trace log. And if you want to trigger a BPM based off of the approval status manually going from U to P, using BO.PO.Update is a good way to do that.
Is your BPM post-processing? That might explain why your criteria isn’t working. Switch it to pre-processing. Changed field criteria unintuitively don’t work on post processing directives. You need to use call context for your situation (see below, ty @jtownsend ).
You might also want to know that the ApprovalStatus field can also change with other methods, eg POSuggestions auto sets it to Approved for some dumb reason. If you need to capture those then you might look at Data Directives. But if you go that route then BOs (eg sending emails) are more difficult to use.
And to further answer your question as to how to track down what methods are firing, sometimes I look in the list of available methods, and make temporary BPMs on potential methods. Add a simple messagebox popup like @Banderson suggests to confirm it is firing.
Eg there are also these methods that you could check, eg POApvMsg.Update might be what you’re looking for.
Personally, I don’t trigger emails on BPM’s much anymore. I just create a function that queries the DB on a schedule and fires out emails based on any records found. Otherwise, yeah, you’d want a post-proc BPM on the Update method.
One needs to remember the BPM process flow: Pre-Proc → Base Logic → Post-Proc
Email alerts should always go on post-proc BPM’s because those fire after the update has been written to the database. Pre-proc fires before the base/canned logic. Which means you could have an email fire off and then have your edit blocked by the system because you forgot the Ship Via (or whatever). Then you fix your problem, save again, and users now has two emails for one PO. Users are either worried or annoyed by duplicate emails. Even worse, you forget to correct your issue and by the time you get back around to it, the user is looking for a PO/line/change/etc. that doesn’t exist.
If you ever have a situation where the Pre-Proc has a bit of data that the Post-Proc doesn’t have, the safest route is to copy the value(s) to the CCBPM fields in pre-proc and then read those same fields from the post-proc. That’s basically what CCBPM fields are for.
Thanks, Brandon, for the insight of the change field and get list method.
Tried the baretail tool. Indeed it’s much better than the need to keep opening the trace log to see the changes. 
Hi Terry,
Thanks for your time to explain in detail. Great to know that Approval status can be change with other methods too. Else I will be caught unaware.
You’re right that I am using post processing. Am still trying with the pre-processing and analyzing the trace packet as I don’t seem to see the change value of the released job when I unchecked the release.
Thanks, John, for your advice.
Good point . Indeed, I have never thought of the duplicate emails from pre-processing.
