Responsibility maintenance in Prod?

[Soady, Phil]

Hi Mike,
the direction you are heading is the BADI HRPAD00AUTH_CHECK.
Yes you are entering the scary world of HR authorizations.
Every HR Auth check can be replaced via this BADI.
 
(Best call the standard class method inside the BADI before adding your =
own rules) This is simple enough and used often on HR sites.
 
The HR structural auth check equivalent is HRPAD00AUTH_CHECK .
 
I cant be sure that all of the checks you require are possible in
via HRPAD00AUTH_CHECK.=20
 
Structural authorizations are quite complicated.=20
Avoid them if possible ;-) =20
 
 
Phil Soady
Senior Consultant
Professional Services
SAP Australia
Level 1, 168 Walker Street, North Sydney 2060, Australia.
M   +61 412 213 079
E   phil.soady at sap.com
http://www.sap.com
=20
 
-----Original Message-----
From: Michael Pokraka [mailto:workflow at quirky.me.uk]=20
Sent: Tuesday, August 19, 2003 7:37 PM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Re: Responsibility maintenance in Prod?
 
Thanks all for your inputs. OOCU_RESP does solve half the question - =
ediding responsibilities but not roles.=20
Now, is it possible to restrict someone to creating/assigning/editing =
responsibilities for a specific set of roles? I haven't really had a =
chance to delve too deeply into the scary world of HR authorizations =
yet, but thought I'd ask in case there is a simple answer ..
 
Thanks again,=20
Cheers
Mike
 
On Tue, Aug 19, 2003 at 04:33:25AM +0200, Dart, Jocelyn wrote:
> There's also transaction OOCU_RESP.
> Regards,
>         Jocelyn Dart=20
> Consultant (SRM, EBP, Workflow)
> and co-author of the book
> "Practical Workflow for SAP"=20
> SAP Australia
> email: jocelyn.dart at sap.com=20
> phone: +61 412 390 267
> fax:   +61 2 9935 4880
>=20
>=20
>=20
>=20
> -----Original Message-----
>> From: Vineet Mehta [mailto:Vineet.Mehta at mbusi.daimlerchrysler.com]=20
> Sent: Tuesday,19 August 2003 10:49 AM
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Re: Responsibility maintenance in Prod?
>=20
>=20
> Hi!=20
> If I understand this correctly, you want a display mode for PFAC.=20
>=20
> You can restrict the authorization to PFAC_DIS.=20
> You should take PFAC_CHG, PFAC_CHG, PFAC_DEL, PFAC taken away from=20
> authorization.=20
>=20
> I hope this helps.=20
> Cheers,=20
> Vineet=20
>=20
>=20
>=20
>=20
>=20
>         workflow at quirky.me.uk=20
>         Sent by: Owner-SAP-WUG at MITVMA.MIT.EDU=20
> =09
>         18/08/2003 09:37 AM=20
>         Please respond to SAP-WUG=20
>                 =A0 =A0 =A0 =A0=20
>                 =A0 =A0 =A0 =A0 To: =A0 =A0 =A0 =
=A0SAP-WUG at MITVMA.MIT.EDU=20
>                 =A0 =A0 =A0 =A0 cc: =A0 =A0 =A0 =A0=20
>                 =A0 =A0 =A0 =A0 Subject: =A0 =A0 =A0 =
=A0Responsibility maintenance in Prod?
>=20
> Greetings workflowers,
> Question concerning responsibilities: Should they be maintained in a =
production=20
> environment?
> In the past, I've come across two scenarios, based on the type of key =
used to=20
> determine responsibilities:
> 1. fairly constant data which can be maintained in DEV and =
transported (e.g.=20
> plant, country)
> 2. master data which doesn't necessarily exist in dev (e.g. =
customer). PFAC was=20
> opened in producton and the WF admin would maintain the =
responsibilities.
> =20
> Now I have a high-maintenance situation on a 4.6c system where things =
change=20
> frequently and people outside of IT are to maintain the =
responsibilities and=20
> agent assignments. I notice PFAC has an all-or-nothing attitude, thus =
if we=20
> give someone access, they can maintain all workflow roles and even =
change the=20
> role/rule type. Is there any way to restrict this nicely - Ideally a =
display=20
> mode for PFAC with edit facilities for the individual =
responsibilities would be=20
> nice....
> =20
> Any thoughts and opiniions appreciated,
> Cheers
> Mike
> =20