This should be simple but I am missing something simple.
We have set up the PO Approval process in E9. We have set the PO limit and Approver person with email. When the PO is over the limit the $$ amount we get the message that the PO needs to be approved by the correct person but that person never gets the email. We have the Global/Email Alerts running.
That is only in E10 correct. I am working in both E9 and E10. In E9 we have a Email Server process that runs. but in E10 there is no such process. I checked with someone else running E9 and they do not have a BPM and it is working.
Here are the two data directives, as E9 examples, one for an email that a PO Needs to be Reviewed going to the Approver and another one for an email back to the Buyer after an action has been taken. You don’t have to use ABL code for the action and instead use a few different actions and the email action
:
define variable vFrom as character no-undo initial "".
define variable vTo as character no-undo initial "".
define variable vCC as character no-undo initial ''.
define variable vSubject as character no-undo initial ''.
define variable vBody as character no-undo initial ''.
define variable hEmailEx as handle no-undo.
for each ttPOApvMsg where ttPOApvMsg.RowMod = "A" or ttPOApvMsg.RowMod = "U":
for each PurAgent where PurAgent.Company = ttPOApvMsg.Company
and PurAgent.BuyerID = ttPOApvMsg.MsgTo
no-lock:
assign vTo = PurAgent.EMailAddress.
end.
for each PurAgent where PurAgent.Company = ttPOApvMsg.Company
and PurAgent.BuyerID = ttPOApvMsg.MsgFrom
no-lock:
assign vFrom = PurAgent.EMailAddress.
end.
assign vSubject = "PO " + string(ttPOApvMsg.PONum) + " Needs Approval" .
assign vBody = "PO " + string(ttPOApvMsg.PONum) + " Needs Approval" + chr(13) +
"Company: " + ttPOApvMsg.Company + chr(13) +
"From Buyer: " + ttPOApvMsg.MsgFrom + chr(13) +
"Approval Status: " + ttPOApvMsg.ApproverResponse + chr(13) +
"Comments (if any): " + ttPOApvMsg.MsgText + chr(13) + chr(13) + chr(13) + chr(13) + "DD.POApvMsg.Std.10".
run Bpm/BpmEmail.p persistent set hEmailEx.
run SendEmail in hEmailEx (false, CUR-COMP, vFrom, vTo, vCC, vSubject, vBody, '':U).
if valid-handle(hEmailEx) then delete procedure hEmailEx.
end.
define variable vFrom as character no-undo initial "".
define variable vTo as character no-undo initial "".
define variable vCC as character no-undo initial ''.
define variable vSubject as character no-undo initial ''.
define variable vBody as character no-undo initial ''.
define variable hEmailEx as handle no-undo.
for each ttPOApvMsg where ttPOApvMsg.RowMod = "A" or ttPOApvMsg.RowMod = "U":
for each PurAgent where PurAgent.Company = ttPOApvMsg.Company
and PurAgent.BuyerID = ttPOApvMsg.MsgTo
no-lock:
assign vTo = PurAgent.EMailAddress.
end.
for each PurAgent where PurAgent.Company = ttPOApvMsg.Company
and PurAgent.BuyerID = ttPOApvMsg.MsgFrom
no-lock:
assign vFrom = PurAgent.EMailAddress.
end.
assign vSubject = "PO " + string(ttPOApvMsg.PONum) + " has been " + ttPOApvMsg.ApproverResponse .
assign vBody =
"Company: " + ttPOApvMsg.Company + chr(13) +
"From: " + ttPOApvMsg.MsgFrom + chr(13) +
"Response: " + ttPOApvMsg.ApproverResponse + chr(13) +
"Comments (if any): " + ttPOApvMsg.MsgText + chr(13) + chr(13) + chr(13) + chr(13) + "DD.POApvMsg.Std.20".
run Bpm/BpmEmail.p persistent set hEmailEx.
run SendEmail in hEmailEx (false, CUR-COMP, vFrom, vTo, vCC, vSubject, vBody, '':U).
if valid-handle(hEmailEx) then delete procedure hEmailEx.
end.
Yes, as far as I can tell a BPM has always been required.
I have worked with several companies on E9 and E10 and a BPM is required.
The email address is there so you have somewhere to store the data.
I think only Shop Alerts worked without a BPM in V8.
In the E10 help they finally added wording explaining that there is not ANY AUTOMATIC emailing and all require a BPM. The nice thing is that in most places there is a nice table like POApvMsg to put a Data Directive on to easily trigger it and get all the content that would have been in an email message.
Kimberley,
My understanding was that this was for E9, so what I posted here is for E9 and this would be ABL.
In E10 there are data fields for BPMData such as Shortchar01, etc, however in E10 I accomplished this completely differently since there are more widget options in Data Directives in E10. You can create all the variables you want and the BPMData fields do not need to be used. The other post is an example for E10.
Also, different people have different ways of writing BPMs. My preference is to use as much of the provided BPM widgets/actions as possible and write as little ABL/C# as possible. I believe this makes it easier to maintain and during upgrades I think there is a better chance of conversion tools converting properly as opposed to custom code.
Others are more comfortable with writing custom code directly, both can work.
I tired using just an email alert in E9 for actions but it did’t work at all. I understand your code completely just not skilled enough to write it…i can just read it.
I am still not sure I understand why you used ShortChar01 in E10. Sorry I am not grasping this or missing something.
In E10 I used ShortChar10 just to hold the variable, I could have sent the mail directly from the code, or stored it in a variable in the code, but I prefer to use widgets as much as possible. it was just a preference.
The E9 BPM was written around 2012 and the E10 I did 3 or so years ago, I just changed my methodology after I went through the process of E9 to E10 conversions and had to deal with ABL code that did not convert. I noticed that BPM’s that used the built in widgets and functions converted fine and so I decided to try to stick with the built in tools.
I have a simpler verision of the E9 BPM somewhere, where I used more of the built in actions.
As for the email alert not working, did an error pop up?
You also have to make sure that your Epicor Email Configuration in Company Maintenance is setup to work with your Email Server, things like the Authentication mode your server is requiring and making sure that your server will accept Emails from your Epicor server are typical issues.