Can someone help me out in creating a bpm to not allow a po to be saved/approved until a promise date is filled in at the release level.
I’m pretty sure I need to use pre-processing. I’m also pretty sure In actions (raise exception) then fill in the verbiage.
Do I use Po as the business object? Then use update?
What’s throwing me also if the behavioral conditions. I put " the po rel.promisedt field of an unchanged row is equal to the null value raise exception based on a template.
But I think I have something backwards. Or am clearly missing something.
Any help is always appreciated. I am on vantage 8.03.410 progress
It sounds like you’re heading in right direction. On our sales orders we have many pre-processing bpms to ensure data completion as needed. Pre-Processing directive on the SaleOrder.Update method, condition example,
the OrderDtl.ProdCode field of the changed row is equal to the “” expression
action example:
the OrderDtl.ProdCode field of the changed row is equal to the “” expression
You mention using Unchanged row. Is this maybe your problem? Don’t forget to enable it to get it to run.
that does work. however the problem I have (correct me if I’m wrong) is that you have to go to the releases tab for it to function.
Problem here is purchasing sometimes does not do that. they simply add lines then approve. the promise date is left blank.
I just realized, you’re dealing with date here. I think the problem might be the empty string comparison. To get around this on one of our sales order bpms, we do the compare to a ud date that’s not filled in, and intentionally kept incomplete. Therefore the condition is like this:
the OrderHed.RequestDate field of the changed row is equal to the ttOrderHed.Date05 expression
In my opinion, you definitely want this on the pre-processing of the update method. There are some business objects that call a separate method (like Customer Shipment Entry has a “ChangeStatus” when you’re opening or closing a pack slip), but I think changing the PO to approved is just the update method. You can verify that by doing a trace.
Also, you’ve got two issues with trying to put it on the update of the release. First, as you said, they may not always update the release directly, it may be getting that from the line. Second, and perhaps more importantly, the business flow may be such that the user doesn’t know the promise date at the time of data entry. Often times with purchasing, they’ll get the order in (or it’s getting created from suggestions), and the promise date is not found out until your buyer contacts the vendor. So, the best place to put that edit is on the APPROVE.
I usually just go to the ABL code with this. I find it easier than dealing with the queries, and you’re probably writing code that’s more efficient than the code the query is generating anyway. Something like:
for each ttPOHeader where ttPOHeader.RowMod = 'U":
if can-find (first PORel where PORel.Company = ttPOHeader.Company and PORel.PONum = ttPOHeader.PONum
and PORel.PromiseDate = ?) then do:
{lib/PublishEx.i &ExMsg = “‘There is at least one release missing a promise date.’” &ExType = {&MESSAGE_ERR}}
RETURN.
end.
end.
You can get a bit fancier in the code, looping through each release that’s missing a date, so you’re telling the user WHICH releases are missing a date, but you get the gist.