<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Whaaaaat?!?? For real??</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Just when I thought WUG was dead it delivers some gold!</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">My memory isn't great but I don't remember having any problems using background release of PR by WF-BATCH based on user decision approval. I'm all for user decision, system update. It's the only practical way to ensure true instance level SoD. That's certainly the standard I've set at my current govt client and 2.5 years in we're about to introduce PRs (it's all been Carts so far). </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">If anyone does know of issues of background release I'd love details. I don't intend to hack around them, I'll be bitching to SAP to get them resolved. Luckily on this project we have their attention and can get things fixed. <br><br>Many thanks!</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Have fun,</div><div id="AppleMailSignature">Mark</div><div><br>On 17 Aug 2016, at 3:35 AM, Bill C <<a href="mailto:billtcraig@gmail.com">billtcraig@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div><div><div><div>Jeffrey,<br></div>I was on a project that did not want users to access ME54N. After about a year of my life and many issues they decided to allow users access. The problems we faced were not so much the simple release of the PR but rather all the integration into FM budgetary ledger etc. It seems that the simple release from the business object BUS2105 does not invoke any of these integration points. One step I added was executing program RFFMRP34N to create the follow on documents etc., then trying to figure out how and who should review and handle any errors...the list goes on and on. <br><br></div>My advice, and I understand that it is not always easy, would be to convince them there is a reason the standard workflow uses ME54N. I would certainly try Florin's approach rather than trying to work around ME54N.<br><br></div>Thanks,<br></div>Bill Craig <br><div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 16, 2016 at 12:01 PM, <span dir="ltr"><<a href="mailto:sap-wug-request@mit.edu" target="_blank">sap-wug-request@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send SAP-WUG mailing list submissions to<br>
<a href="mailto:sap-wug@mit.edu">sap-wug@mit.edu</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://mailman.mit.edu/mailman/listinfo/sap-wug" rel="noreferrer" target="_blank">http://mailman.mit.edu/<wbr>mailman/listinfo/sap-wug</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:sap-wug-request@mit.edu">sap-wug-request@mit.edu</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:sap-wug-owner@mit.edu">sap-wug-owner@mit.edu</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of SAP-WUG digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. PR Release WF - GRC ME54N (Jeffrey A. Rappaport)<br>
2. Re: PR Release WF - GRC ME54N (Florin Wach (SI))<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Tue, 16 Aug 2016 09:43:55 -0400<br>
From: "Jeffrey A. Rappaport" <<a href="mailto:Jeff@business-workflow.com">Jeff@Business-Workflow.com</a>><br>
Subject: PR Release WF - GRC ME54N<br>
To: "SWUG \(SAP\)" <<a href="mailto:SAP-WUG@mit.edu">SAP-WUG@mit.edu</a>><br>
Message-ID: <<wbr>470D0CB4BF7448E4A6EA169CDB3512<wbr>E4@jrapp123><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hey WUG?ers,<br>
<br>
Has anyone had any Clients out there that wound up restricting their Users from having access to both ME51N/ME52N with ME54N, due to real tight GRC ?Segregation of Duties? outcomes? And ended up having to redesign the entire PR Release WF process due to no one having access to ME54N?<br>
<br>
Thanx for your feedback,<br>
<br>
Jeffrey A. Rappaport<br>
Business Workflow Inc.<br>
Voice: <a href="tel:%2B1%20%28561%29%20508-2555" value="+15615082555">+1 (561) 508-2555</a><br>
Fax: <a href="tel:%2B1%20%28866%29%20301-7666" value="+18663017666">+1 (866) 301-7666</a><br>
Email: <a href="mailto:Jeff@business-workflow.com">Jeff@Business-Workflow.com</a><br>
Web: <a href="http://www.Business-Workflow.com" rel="noreferrer" target="_blank">www.Business-Workflow.com</a><br>
Link: <a href="http://www.linkedin.com/in/businessworkflow" rel="noreferrer" target="_blank">www.linkedin.com/in/<wbr>businessworkflow</a><br>
<br>
<br>
<br>
The information contained in this message may be privileged, confidential and protected from disclosure. If the Reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error and would like to be removed from any future mailings from this Sender, please hit 'Reply' to this email with "REMOVE" in the Subject line.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://mailman.mit.edu/pipermail/sap-wug/attachments/20160816/3c138b1a/attachment-0001.html" rel="noreferrer" target="_blank">http://mailman.mit.edu/<wbr>pipermail/sap-wug/attachments/<wbr>20160816/3c138b1a/attachment-<wbr>0001.html</a><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 16 Aug 2016 16:08:33 +0200<br>
From: "Florin Wach (SI)" <<a href="mailto:florin.wach@systems-integration.net">florin.wach@systems-<wbr>integration.net</a>><br>
Subject: Re: PR Release WF - GRC ME54N<br>
To: "SAP Workflow Users' Group" <<a href="mailto:sap-wug@mit.edu">sap-wug@mit.edu</a>><br>
Message-ID:<br>
<<a href="mailto:6D971557-D407-4C76-9995-DA3288B728D5@systems-integration.net">6D971557-D407-4C76-9995-<wbr>DA3288B728D5@systems-<wbr>integration.net</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
? what the heck :-) ? or hack :-)<br>
<br>
Well, in a way yes and no: Normally the releasers, which are involved during the process are cost center owners, project managers or similar ? so they usually can ALSO create or change manual requisitions for the own duties.<br>
During the release transaction, the ME54N allows for changes within certain limitations (e.g. change of total value) and otherwise the release procedure will be reset.<br>
<br>
However, your requirement might be somewhat easy to achieve via customizing, when you change the release indicator that you?re using DURING the approval, and modify the setting to ?No change possible?.<br>
This way, the requisition cannot be changed, while it?s in approval. If someone needs to make a change, the releases need to be reset ? somehow? you got to try that out ;-)<br>
<br>
<br>
Other option: Get a screen user exit or BADI during post that prevents the requisition from beeing changed, other than the release codes.<br>
<br>
<br>
<br>
<br>
Mit freundlichen Gruessen / With kind regards<br>
Florin Wach<br>
Senior Workflow Engineer<br>
Systems-Integration<br>
<br>
------------------------------<wbr>--------------------<br>
<a href="http://www.systems-integration.net" rel="noreferrer" target="_blank">http://www.systems-<wbr>integration.net</a> <<a href="http://www.systems-integration.net/" rel="noreferrer" target="_blank">http://www.systems-<wbr>integration.net/</a>><br>
> Am 16.08.2016 um 15:43 schrieb Jeffrey A. Rappaport <<a href="mailto:Jeff@business-workflow.com">Jeff@Business-Workflow.com</a>>:<br>
><br>
> Hey WUG?ers,<br>
><br>
> Has anyone had any Clients out there that wound up restricting their Users from having access to both ME51N/ME52N with ME54N, due to real tight GRC ?Segregation of Duties? outcomes? And ended up having to redesign the entire PR Release WF process due to no one having access to ME54N?<br>
><br>
> Thanx for your feedback,<br>
><br>
> Jeffrey A. Rappaport<br>
> Business Workflow Inc.<br>
> Voice: <a href="tel:%2B1%20%28561%29%20508-2555" value="+15615082555">+1 (561) 508-2555</a><br>
> Fax: <a href="tel:%2B1%20%28866%29%20301-7666" value="+18663017666">+1 (866) 301-7666</a><br>
> Email: <a href="mailto:Jeff@business-workflow.com">Jeff@Business-Workflow.com</a> <mailto:<a href="mailto:Jeff@Business-Workflow.com">Jeff@Business-<wbr>Workflow.com</a>><br>
> Web: <a href="http://www.Business-Workflow.com" rel="noreferrer" target="_blank">www.Business-Workflow.com</a> <<a href="http://www.business-workflow.com/" rel="noreferrer" target="_blank">http://www.business-workflow.<wbr>com/</a>><br>
> Link: <a href="http://www.linkedin.com/in/businessworkflow" rel="noreferrer" target="_blank">www.linkedin.com/in/<wbr>businessworkflow</a> <<a href="http://www.linkedin.com/in/businessworkflow" rel="noreferrer" target="_blank">http://www.linkedin.com/in/<wbr>businessworkflow</a>><br>
><br>
><br>
><br>
> The information contained in this message may be privileged, confidential and protected from disclosure. If the Reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error and would like to be removed from any future mailings from this Sender, please hit 'Reply' to this email with "REMOVE" in the Subject line.<br>
> ______________________________<wbr>_________________<br>
> SAP-WUG mailing list<br>
> <a href="mailto:SAP-WUG@mit.edu">SAP-WUG@mit.edu</a><br>
> <a href="http://mailman.mit.edu/mailman/listinfo/sap-wug" rel="noreferrer" target="_blank">http://mailman.mit.edu/<wbr>mailman/listinfo/sap-wug</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://mailman.mit.edu/pipermail/sap-wug/attachments/20160816/2b1375b8/attachment-0001.html" rel="noreferrer" target="_blank">http://mailman.mit.edu/<wbr>pipermail/sap-wug/attachments/<wbr>20160816/2b1375b8/attachment-<wbr>0001.html</a><br>
<br>
------------------------------<br>
<br>
______________________________<wbr>_________________<br>
SAP-WUG mailing list<br>
<a href="mailto:SAP-WUG@mit.edu">SAP-WUG@mit.edu</a><br>
<a href="http://mailman.mit.edu/mailman/listinfo/sap-wug" rel="noreferrer" target="_blank">http://mailman.mit.edu/<wbr>mailman/listinfo/sap-wug</a><br>
<br>
<br>
End of SAP-WUG Digest, Vol 138, Issue 1<br>
******************************<wbr>*********<br>
</blockquote></div><br><br clear="all"><br></div></div></div></div></div></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>SAP-WUG mailing list</span><br><span><a href="mailto:SAP-WUG@mit.edu">SAP-WUG@mit.edu</a></span><br><span><a href="http://mailman.mit.edu/mailman/listinfo/sap-wug">http://mailman.mit.edu/mailman/listinfo/sap-wug</a></span><br></div></blockquote></body></html>