Universal Worklist - TS20000166 (purchase order release) and SWFVISU

Kjetil Kilhavn kjetil.kilhavn at bluec.no
Tue Jun 14 06:28:29 EDT 2011 

 Fredag 10. juni 2011 14.22.46 skrev Mike Pokraka :
> Hi Kjetil,
> 
> > I have to disagree, possibly because I don't understand your solution
> > design.
> 
> I think your possibility is a high probability :)
> What I'm suggesting is:
> 
> Standard or non-workflow process:
> User has ME29N and can release. They can theoretically trawl through MM
> reports and release stuff that's none of their business but they are
> technically authorized to. More applicable to people higher up the chain
> and setups where you have overlapping departmental responsilities.
> 
> Enhanced decision-based process:
> A bog-standard decision task has possible agents based on the same
> security role(s) and is routed to appropriate agents with the PO released
> in background. Forwarding can be taken away compeltely or restricted to
> possible agents.
> ==> People can ONLY release what's available in their inbox, either by WF
> system or having been forwarded to them. No snooping around other
> approvers' orders unless forwarded or substituted.
> ==> By using the same universe of possible approvers, and restricting the
> possible appprovers even further through workflow routing you have
> improved security over the standard scenarios.
> 
> Note: I've simplified the above. Typically you'd have different auth roles
> for different scenarios, and you can create multiple decision tasks based
> on these (e.g. by plant/release code/whatever) and use a dynamic task
> assignments to replicate the concept of different groups of users having
> different auths within ME28. Still not a huge amount of custom developmet
> and not a million miles from standard.
> 
> Make more sense now?
Yes, I understand the thinking behind it now. By removing only the transaction 
code authorization and keeping the other authorizations (release group/code) 
the solution I have for identifying an authorized approver would still work.

I'd have to check the authorization before doing the actual approval, as a 
manager who technically could forward a work item to a subordinate without 
sufficient authorization should not succeed in making that subordinate approve 
the purchase.

So, improved security can be obtained, the direct approval button will be 
there, but at the cost of development (and maintenance) in order to handle 
locking problems, prevent approval by unauthorized agents etc. Sounds like a 
fairly good solution - but currently I'll continue trying to get it solved by 
a simple configuration change so UWL will display additional button(s).

Thanks for the tip - and for the additional explanation for those of us who 
are a little slow sometimes :) 

> 
> Cheers,
> Mike
> 
> On Mon, June 6, 2011 2:15 pm, Kjetil Kilhavn wrote:
> >  Tirsdag 31. mai 2011 12.06.38 skrev Mike Pokraka :
> >> Hi Kjetil,
> >> 
> >> The standard solution is specifically designed around GUI. By applying
> >> the
> >> same ME54N auths as you give your users to a decision task, you are
> >> replicating the same level of security. By adding workflow routing and
> >> taking away ME54N you are enhancing security.
> > 
> > I have to disagree, possibly because I don't understand your solution
> > design.
> > How can I enhance the security by taking away ME54N, or in my case
> > ME29N/ME28?
> > 
> > A custom decision task would have to replicate a lot of the standard task
> > functionality to handle significant changes, rejections and of course
> > approvals. That is unnecessary duplication of work in my opinion - but of
> > course the customer will get it if they require it.
> > 
> > If the users themselves don't have ME29N authorization and the
> > authorization
> > for the release codes they are authorized to handle, I would have to use
> > a system user for the actual release. That's where I see a big problem
> > in improving security which you claim is possible. Forwarded work items
> > could be
> > executed by unauthorized users unless I implemented exactly the same
> > authorization checks that SAP already implements in ME29N.
> > 
> >> I've often said that workflow can enhance or blow away security,
> >> depending on good design or lack thereof.
> > 
> > The previously implemented solution blew all security away. Any user
> > getting
> > his/her hands on a work item could release any purchase order - the
> > user's authorization to release was not checked, nor the amount limits.
> > 
> > The new solution identifies the release agent depending on the release
> > code.
> > For some codes the customizing is used, for others organization hierarchy
> > climbing is necessary - and in those cases I check the identified user's
> > authorization for the release code in order to find the correct release
> > agent.
> > It would of course be possible to give the users authorization to the
> > release
> > codes without giving them authorization to ME29N, but I fail to see the
> > point
> > of this. Some users will use the UWL to release purchase orders, some
> > will use
> > ME29N or ME28 directly because they don't have UWL available, and some
> > will be
> > using both methods.
> > 
> > The standard task now has possible agents defined, and the properties
> > have been set to prevent forwarding to others than the possible agents.
> > I've also
> > classified the task and created a possibility to define substitutes for
> > purchase approvals. All of this would also have to be done to a user
> > decision
> > task, and with a user decision task I would have to have subsequent tasks
> > checking the work item (executing) agent's authorization and then either
> > call
> > a function module with RFC destination to release the purchase order with
> > another user ID, or perform the release in a background task - adding the
> > complexity of handling various error situations that could occur in that
> > background task too.
> > 
> >> Whilst I agree with you in sticking close to SAP standard in most cases
> >> is
> >> a good thing, IMHO the SAP Standard for many +workflow+ scenarios is
> >> little more than a "Quick and dirty" to get folks up and running with
> >> minimal fuss. ESS is a prime example - you dont't even need UWL or SBWP
> >> for the simplest setup. Purchasing workflows are a bit dated to say the
> >> least, and there's nothing wrong with a well thought out solution that
> >> fulfils business requirements.
> > 
> > I agree. The problem is in creating a "well thought out solution" :-)
> > The previous solution was certainly not well thought out. It didn't have
> > authorization checking or possible agent specification, and didn't handle
> > rejections properly. The approver could choose to reject, but the
> > purchase order was not updated with the new status and this meant in
> > most cases no new
> > workflow would be started automatically since the purchaser could not
> > cancel
> > the rejection after e.g. changing the account assignment.
> > 
> > It may be true that the purchasing workflows are a bit dated, but they
> > work
> > pretty well I think. The purchasers are notified about approved and
> > rejected
> > purchase orders too, which I initially thought they wouldn't want - but
> > they
> > like it because then they don't have to keep track of this manually.
> > 
> >> Just my 2p,
> > 
> > Your 2p are always appreciated - and usually I don't disagree :-)
> > 
> >> Mike
> >> 
> >> On Fri, May 27, 2011 1:45 am, Kjetil Kilhavn wrote:
> >> >  Tirsdag 24. mai 2011 17.48.24 skrev Griffiths, Mark :
> >> >> I would copy and change the workflow to use a user decision and then
> >> 
> >> use
> >> 
> >> >> a
> >> >> UWL view to process the approvals.  The workflow could then release
> >> 
> >> the
> >> 
> >> >> PO
> >> >> using a BAPI in a background task.
> >> > 
> >> > That is precisely what I *don't* want to do. I want the solution to
> >> 
> >> stay
> >> 
> >> > as
> >> > close to SAP standard as possible. Less maintenance, hopefully. At
> >> 
> >> least
> >> 
> >> > it
> >> > will be done that way initially. In my opinion people are dismissing
> >> > standard
> >> > far too quick, and only later realize the maintenance cost.
> >> > Since the company who first implemented a solution did such a poor job
> >> 
> >> it
> >> 
> >> > is
> >> > easier to persuade them to try SAP standard so they get proper
> >> > authorization
> >> > checking etc.
> >> > 
> >> > ObFrust: The other day I had to check (EhP 4 post-upgrade check/fix) a
> >> > report
> >> > which was a copy of SAP standard report. And for what? To remove one
> >> > field from the standard output setup, add another field to the
> >> 
> >> standard
> >> 
> >> > output setup
> >> > ... and finally to add a new field to the available output fields and
> >> 
> >> to
> >> 
> >> > the
> >> > standard output setup. Using implicit enhancement points everything
> >> > except for
> >> > one statement could be implemented. This statement had to be
> >> 
> >> "replaced"
> >> 
> >> > in a
> >> > modification to read configuration for standard transaction codes when
> >> > the special transaction codes are used, and of course execute as
> >> 
> >> normal
> >> 
> >> > when the
> >> > ordinary transaction codes are used.
> >> > 
> >> >> Regards,
> >> >> 
> >> >> Mark
> >> >> 
> >> >> -----Original Message-----
> >> >> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
> >> 
> >> Behalf
> >> 
> >> >> Of
> >> >> Dart, Jocelyn Sent: 20 May 2011 05:55
> >> >> To: SAP Workflow Users' Group
> >> >> Subject: RE: Universal Worklist - TS20000166 (purchase order release)
> >> >> and
> >> >> SWFVISU
> >> >> 
> >> >> Hi Kjetil,
> >> >> So you've taken away a user decision task or WebDynpro app?
> >> >> And replaced it with a SAPGUI task...
> >> >> 
> >> >> SWFVISU is a possibility.
> >> >> You could also use the UWL XML config and use the function module
> >> >> launcher
> >> >> to call the relevant BAPI to release the PO. You might need to create
> >> 
> >> a
> >> 
> >> >> wrapper function module to simplify it a bit... but that approach
> >> 
> >> works
> >> 
> >> >> ok. You could even allow mass approval with the checkbox options
> >> 
> >> (check
> >> 
> >> >> out the standard WorkItemApprovals view).
> >> >> 
> >> >> Regards,
> >> >> Jocelyn
> >> >> 
> >> >> 
> >> >> -----Original Message-----
> >> >> From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On
> >> 
> >> Behalf
> >> 
> >> >> Of
> >> >> Kjetil Kilhavn Sent: Thursday, 19 May 2011 12:39 AM
> >> >> To: sap-wug at mit.edu
> >> >> Subject: Universal Worklist - TS20000166 (purchase order release) and
> >> >> SWFVISU
> >> >> 
> >> >> I have a request to give the users back the button they say I have
> >> >> removed.
> >> >> I haven't really removed anything, just switched from a custom
> >> 
> >> workflow
> >> 
> >> >> full of security problems to the SAP standard workflow which doesn't
> >> >> circumvent authorizations....
> >> >> 
> >> >> Anyway, the users would like to be able to approve (possibly also
> >> >> reject,
> >> >> but that's less important to them I believe) the purchase orders
> >> >> directly
> >> >> from the work item display in Universal Worklist. Now, there is the
> >> >> wonderful world of SWFVISU, but is there a SAP standard application
> >> >> which
> >> >> can be used for this purpose. Currently they see the task
> >> 
> >> description, I
> >> 
> >> >> think they still want to see that.
> >> >> 
> >> >> Any low-hanging fruits, or do I have to tell them it will take 42
> >> 
> >> days?
> >> 
> >> > --
> >> > Kjetil Kilhavn (+47 40220607)
> >> > Blue Consulting AS (http://www.bluec.no)
> > 
> > --
> > Kjetil Kilhavn (+47 40220607)
> > Blue Consulting AS (http://www.bluec.no)
> > _______________________________________________
> > SAP-WUG mailing list
> > SAP-WUG at mit.edu
> > http://mailman.mit.edu/mailman/listinfo/sap-wug
> 
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug

-- 
Kjetil Kilhavn (+47 40220607)
Blue Consulting AS (http://www.bluec.no)

More information about the SAP-WUG mailing list