PR Release WF - GRC ME54N

[Kjetil Kilhavn]

onsdag 24. august 2016 15.00.14 CEST skrev Mark Pyc:

> Some clients, such as this Govt example, have such complicated rules
> regarding who should approve what based on who ordered, what was ordered
> and where it was costed to that Release Codes are simply impractical both
> from a definition, config and security allocation perspective.
> 
> Beyond this my statement around SoD is that security alone (Release Code
> based or otherwise) can not prevent self approval. There are many instances
> where someone needs to have the ability to key documents and approve
> identical documents, just not approve the documents they keyed. I've heard
> this quaintly referred to as "the four eyes principle".
> 
> WFs based on User Decision steps (where there is no authority check) with
> WF-BATCH performing the Release is my preferred method where either such
> requirement exists. Users have no access to the direct Release transactions
> at all, and the WF agent determination logic, however it's implemented (be
> it Resp Rules, BRF+, custom code) is the source of control, not allocation
> of security Roles. The power of "excluded" agents provides more control
> than Security ever can.
As I thought, I wasn't seeing it from the right perspective :-)
I previously thought you argued for just replacing the approval task, still 
using different release procedures. As I now understand it your are in such 
cases as described not really using release procedures, other than as a 
mechanism for preventing conversion to purchasing document. 
It makes more sense now.

I've implemented the Purchase Requisition/Order Business Add-In to prevent 
releasing one's own document. That works well, but as you say there are other 
issues with release codes.


> Regarding updating change logs to say something other than WF-BATCH, I push
> back on this. WF-BATCH did perform the Release. If you want to know who was
> involved in the approval review the WF log. 
I agree completely :-)
 
> Have fun,
> Mark
> 
> On 24 August 2016 at 08:44, Kjetil Kilhavn <list.sap-wug at vettug.no> wrote:
> > onsdag 17. august 2016 07.37.43 CEST skrev Mark Pyc:
> > > I'm all for user decision, system update. It's the only practical way to
> > > ensure true instance level SoD
> > 
> > Could you be bothered to elaborate on that?
> > I fail to see any advantages in terms of Segregation of Duties (assuming
> > that
> > is what you refer to) achieved by letting the user execute a user decision
> > task as opposed to, in this case, a task that starts transaction ME54N?
> > My point being that I don't see what you can do in your decision task that
> > you
> > couldn't just as well do with the task delivered by SAP. So, perhaps its
> > just
> > because I am not looking at it from the right perspective.
> > 
> > > 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.
> > 
> > It's not really an issue of background release, but when a user approves
> > the
> > release code in ME54N or ME28 an event terminates the work item. This
> > means
> > you can also hook up other workflows.
> > 
> > Plus, if you are preventing business users from using ME28/ME54N:
> > >From a user perspective: choice between ME28/ME54N  and workflow inbox.
> > >From a solution design perspective: you can choose to not use workflow
> > 
> > for some
> > release codes.
> > --
> > Kjetil Kilhavn / Vettug AS (http://www.vettug.no)
> > _______________________________________________
> > SAP-WUG mailing list
> > SAP-WUG at mit.edu
> > http://mailman.mit.edu/mailman/listinfo/sap-wug


-- 
Kjetil Kilhavn / Vettug AS (http://www.vettug.no)