Auto-Approve PO using BPM


Have a standard data directive on JobOper that works for creating Purchase Orders for our intercompany subcontract operations. I can open the PO that is created, check approve and get no errors. However, as soon as I try to automate the approval itself, I run into issues.

I decided to run a trace on the approve switch, the methods called, in order, are ChangeApproveSwitch, CheckBeforeUpdate and Update.

I tried replicating this in my BPM, but getting this error:

I looked through the BOs under PO and I’m not seeing any called setPORelShipToAddress. What’s really odd is this to the job, not an order number or a drop ship, so I’m not sure why it’s asking for a ship to when it’s not required.

Any suggestions or ideas?

Is your DD trying to create the whole PO, or just approve an existing one (that is fully filled out)?

Trying to create and approve the whole PO. I can get it created, and I can go in and manually approve it. But if I try automate the approval it errors out.

This much works:


But doing this much does not:

And here’s the methods I’m calling:


Are us doing an update (like doing a “Save” in the UI) before trying to approve it?

Typically, creating the PO Line automatically makes the PO Release… when the Line is saved.

In the UI, you can’t mark a PO Approved, until you save after creating a line

In the following GIF, the Approved button isn’t enabled until after I save the line.

You probably need to call PO.Update before PO.ChangedApproveSwitch

Yes sir, I use an “Update” widget after creating the line, setting the transaction type and setting the Job, Assembly and Operation. It will create the PO, and if I go look at the PO the line/release exist, the approve box is active. I just can’t get it to do the approval through the BPM.

Although I’m calling PO.ChangePOSwitch and not PO.ChangedPOSwitch… hmmm

ChangedApproveSwitch. Not ChangedPOSwitch

Sorry, yes, that’s what I meant lol. I’m calling PO.ChangeApproveSwitch not PO.ChangedApproveSwitch

Changed the methods around and made no difference, still fails with the same null reference exception, referring to the method “setPORelShipToAddress”. PO is still created, line and release is there, Approve is active but not checked. The release shouldn’t need a ship to, it’s for a subcontract operation on a job. The Ship To Cust field is greyed out on the release.

The PO Summary tab, Approve is active:

The release:

You must be on a new version than I. In 10.2.300, DD’s only have an “Invoke External Methods” widgets. I’d have to use a MD to use the “Invoke BO Method”.

Also, I don’t get that nice list of ‘Actions’ in the Workflow Designer. :frowning:


D’Oh! - I see that it becomes a list when you select more than one.


Yes, we are on 10.2.500, are you looking at in-trans DD? This is a Standard DD. Standard DDs should give you the invoke BO method.

10.2.300 Data Directive Workflow Designer


As a debugging test, split it into 2 MPM’s   BPM’s

  • The first creates the PO (which you said works).
  • The second just does the approval part. Hardcode the PONum into the 2nd(just for testing)

Dumb question, MPM?

LOL … Typo of “BPMs”

Or maybe it means “Method directitive business Process Management”

as opposed to a “DMP”

Data directitive business Process Management”


1 Like

Same exact issue, null reference for setPORelShipToAddress



just to double check myself, I’m a complete noob with BPMs, could you tell me if this looks correct to you?


I’m not entirely sure what to enter as the viewName. In the trace it refrences POHeader, so that’s what I entered.

Why do you need the CheckBeforeUpdate and Update 1 after the ChangeAppSwitch?

I’m not saying that you definitely saying that you don’t need them. I’d have though that the ChangeAppSwitch would be the last thing to do on the PO.

I thought the same thing, as it seems to me the ChangeAppSwitch triggers the CheckBeforeUpdate and Update methods anyway.

So, I removed them and I’m back to square one. Null Reference Exception for setPORelShipToAddress

I think I may have stumbled on to it …

There’s a two distinct BO method’s (with very similar names) that are called when you approve a PO via the UI.


A trace of just clicking the Approved box, shows (in order):

  1. PO.ValidateAcctForGLControl
  2. PO.ChangeApproveSwitch
  3. PO.CheckBeforeUpdate
  4. PO.Update
  5. PO.ChangedApproveSwitch

Lines 2 and 5 are different methods!

I’ll give it a go