Authorizations to create substitutes

Hassine, Felix Felix.Hassine at pmintl.com
Thu Aug 21 13:22:44 EDT 2003


Thanks for everyone for the input.
 
As I expected, the restriction of the substitution ability is driving us
into developped solutions.
 
In other words, we have to integrate this as a development constraint, and
tell workflow designers around our company that the effects and weaknesses
of substitution need to be addressed at the workflow design levels.
 
Conceptually, I don't think the workflow coding is the right place to
auto-protect itself against bad substitutions, because this is an admin
task, inherent to the role of the Workflow Business Administrator.
 
 
In the meantime, I think a must-have is the ability to restrict the
substitute functions (workflow settings) with an authorization object.
 
Jocelyn, a BADI could be a solution. If this is of any interest, here are my
basic requirements:
 
        - Have a  user-exit on the substitution screen
        - Have a Task-dependant or task-group-dependant substitution
mechanism (should't be difficult, after all this is all infotype links
between HR-defined objects, is it not?). The reason is that I want different
substitutions for an A/Payable workflow than for a procurement workflow.
 
For individual developments, implementing this with functions (such as
RH_SUBSTITUTION_MAINTAIN as proposed by Swami) is very heavy. On top of it,
I see no way of restricting access in 4.6 to the substitute transaction....
 
Sorry to look so negative, as an Internal Controller I usually promote SAP
workflow, and this weakness now pops up....
 
Thanks for all responses, and best regards.
 
Felix
 
 
-----Original Message-----
From: Dart, Jocelyn [mailto:jocelyn.dart at sap.com]
Sent: Thursday, August 21, 2003 3:52 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Authorizations to create substitutes
 
 
Hi Felix/Vineet,
Unfortunately, as a substitute executes the work item under the original
user's access to the work item, changing the possible agents won't help. And
option 3 results in a work item in error. Regards,
        Jocelyn Dart
Consultant (SRM, EBP, Workflow)
and co-author of the book
"Practical Workflow for SAP"
SAP Australia
email: jocelyn.dart at sap.com
phone: +61 412 390 267
fax:   +61 2 9935 4880
 
 
 
 
 
-----Original Message-----
From: Vineet.Mehta at mbusi.daimlerchrysler.com
[mailto:Vineet.Mehta at mbusi.daimlerchrysler.com]
Sent: Thursday,21 August 2003 11:45 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Authorizations to create substitutes
 
 
I am not sure how you have it configured but here are few things you can
check:
 
1. If it is set up as a "general task" and open to everyone, then everyone
can execute it (including substitutes). 2. If that is true, then you may
want to use "wf role assignment..  job or position" to restrict them. (when
you do agent assignment for the Task) 3. Another possibility is to check
authorization for the transaction to approve the task.. (check with Security
folks if they can restrict).
 
These are just some pointers. I am not sure how your specific workflow is
setup but should give you some ideas.
 
Let me know if I can help.
Regards
Vineet
 
 
 
 
 
 
 
Felix.Hassine at pmintl.com
Sent by: Owner-SAP-WUG at MITVMA.MIT.EDU
20/08/2003 11:53 AM
Please respond to SAP-WUG
 
 
        To:     SAP-WUG at MITVMA.MIT.EDU
        cc:
        Subject:        Authorizations to create substitutes
 
Hi everyone,
 
We have a workflow related to approval of invoices with monetary limits
assigned to different agents. Unfortunately, some agents may conturn our
internal rules  by assigning their own substitutes (who may not have this
level of approval...). If a user can assign up to 10000 USD or invoices,
assigning user X to his substitute authorizes this user X to execute the
approval task (Based on a DECISION step...).
 
Is there any way to restrict users from maintaining their own substitutes?
 
I would like to avoid re-coding the DECISION step in order to verify the
monetary limit of the approver. Has anyone encountered such situation?
 
Thanks for any info.
 
Best regards,
 
Felix
 


More information about the SAP-WUG mailing list