User Creation Date...

Table USR02 - GLTGV (field) is the date from when user is permitted to use the sstem.So let suppose if
ou !reated the User "# on 0$%0$%20$$ and wants to allow him%her from0&%0$%20$$ then user !reation
date would be 0$%0$%20$$ but USR02-GLTGV holds the 'alue0&%0$%20$$ .(!tuall user !reation date is
USR02 - )R#(T.
Locked value in USR02
0* +ot Lo!,ed
$-* .ster 'alues
&2* Lo!,ed b /U(
-0* Lo!,ed b Sstem administrator
$21* Lo!,ed due to in!orre!t lo2ons
$32* user is lo!,ed b admin and user tries to lo2on with in!orre!t passwords and 2ets lo!,ed
What is the difference between USOB!C and USOB"!C#
The table US4567/ defines whi!h authori8ation !he!,s are to be performed within transa!tion
and whi!h not (despite authorit- !he!, !ommand pro2rammed). This table also determines
whi!h authori8ation !he!,s are maintained in the 9rofile Generator.
The table US45T7/ defines for ea!h transa!tion and for ea!h authori8ation ob:e!t whi!h default
'alues an authori8ation !reated from the authori8ation ob:e!t should ha'e in the 9rofile
Generator.
Su22 vs$ Su2%
SU22 displas and updates the 'alues in tables US45T and US456; while SU20 does the same in tables
US45T7/ and US4567/. The 7/ stands for /ustomer.
The profile 2enerator 2ets its data from the 7/ tables. "n the US45T and US456 tables; the 'alues are
the S(9 standard 'alues as shown in SU20. <ith SU2= one !an (initiall) transfer the US45T 'alues to
the US45T7/ table.
Restrict to &articular tables in S'()
Suppose we ha'e to !reate a Role that !an onl ha'e #ata 5rowser t !ode (S)$-) with table USR02 and
(GR7US)RS #ispla (//)SS.
"n S)$-; onl one authori8ation ob:e!t (S7T(5U7#"S) is !he!, maintained in SU20.
5efore that we ha'e to !he!,; what are the authori8ation 2roup for those tables (USR02 and (GR7US)RS)
So go to Data Browser (SE16) and Type Table TDDAT. It stores Table auth group.
9ut table name USR02.So, we get SC s the auth group !or the table "S#$%.And SS s the auth
group !or table A&#'"SE#S.
+ow add transa!tion !ode S)$- to the newl !reated Role >7T/S.+ow 2o to authori8ation tab and fill
the profile name and !li!, /?(+G) (UT?4R">(T"4+#(T(.
Sear(h S'TAB"'DIS, !han2e #"/5)R/LS ((UT? GR4U9).Go to !han2e (pen!il "!on) to
#"/5)R/LS field. (nd add those two (UT? GR4U9 (S/ and SS).
User Buffer *roble+
Suppose; Two user 6 and @ both ha'e Role ((SU0$#; S)$-). User 6 is able to run the SU0$# but @
"s not bein2 able to Run the SU0$#.
)ay be user (o*parson s not done properly !or the user +.
+ou (an re!resh the "ser Bu!!er (,ogo!! and ,ogn )
User buffer !an store maAimum of &$29rofile; it ma be possible user (@) has more than &$2 9rofiles.
(<h &$2 9rofiles* 5e!ause user buffer is Strin2 buffer whi!h !an hold maAimum &B=0 !hara!ters. (nd a profile !ontains
$2 !hara!ter; so a user !an hold maAimum &B=0%$2 C &$2 profile.)
Solutions*
9lease assi2n a referen!e User to user @. (nd assi2ned Role ( to the referen!e user; So @ !an a!!ess
Role (.
,n user is assi-ned a certain ROL'$ .ow to find /how +an0 tables a user can access in sa&$
$. So at first we ha'e to !he!, whi!h role !ontains those (uthori8ation 4b:e!ts. Go to SU". and
R4L) -D Roles b !ompleA sele!tion /riteria Sele!t User as 5"E4@ and (uthori8ation 4b:e!t as
S7T(5U7#"S. @ou !an sele!t both (uth 4b:e!ts.
2. (s " 2ot roles ( and 5 whi!h !ontains authori8ation ob:e!ts as S7T(5U7#"S.
&. +ow we ha'e to find how man authori8ation 2roups are present in these roles.
0. Go to S) $-(#ata 5rowser) -D (GR7$2=$(table)
=. 9aste the Roles ( and 5. (lso the authori8ation ob:e!ts S7T(5U7#"S.
-. ?ere we 2ot FS/G;GSSG authori8ation 2roups.
B. +ow we ha'e to find how man tables are asso!iated with this authori8ation 2roups.
1. Go to S)$-(#ata 5rowser)-DT##(T(table)
3. "n !!lass (field) enter FS/G;GSSG authori8ation 2roups; ou will find out how man tables a user
!an a!!ess.
(GR7$2=$* Hor a parti!ular Role; the asso!iated authori8ation ob:e!t; authori8ation; authori8ation fields
and its 'alues.
.ow to assi-n Reference User to a Dialo- User
Referen!e user is when a user 2ets his authori8ations from another user "#. This !an be pra!ti!al for internet
users. @ou need to be !areful about this tpe of a!!ess; as it will not show up in our ordinar SU".0
reportsI 4r (GR7US)RS.
Referen!e user is used onl to assi2n additional authori8ations. ou !annot lo2in b usin2 referen!e
user User tpe for 2eneral; non-person related users that allows the assi2nment of additional identi!al
authori8ations; su!h as for "nternet users !reated with transa!tions SU0$. @ou !annot lo2 on to the sstem
with a referen!e use.
To assgn a re!eren(e user to a dalog user, spe(!y t when *antanng the dalog user on the
#oles tab page. In general, the appl(aton (ontrols the assgn*ent o! re!eren(e users. Ths
assgn*ent s -ald !or all syste*s n a Central "ser Ad*nstraton (C"A) lands(ape. I! the
assgned re!eren(e user does not e.st n a C"A (hld syste*, the assgn*ent s gnored.
There are two roles /'0oy and /'1ew
>7+)< !ontains T/4#)Js of S.&- and S.=3.
/'02+ (ontans TC2DE3s o! SE16, S"$1D and S"I)
And we (reated a #E4E#E1CE type user //2T$$$1.
<hi!h has >7E4@ Role (S)$-; SU0$# and SU".).
1ow we (reate a new Dalog user //2T$$$% and assgn role /'1E5 to t.
(nd assi2n the R)H)R)+/) user >>4T000$ to Referen!e user field in the Roles tab.
+ow lo2in throu2h >>4T0002 user it onl shows >7+)< roles. (S.&- and S. =3).
5ut when ou eAe!ute S)$- it will eAe!ute with no authori8ation errors.

@ou should be 'er !autious when !reatin2 referen!e users.

"f ou do not implement the referen!e user !on!ept; ou !an dea!ti'ate this field in a!!ordan!e with
S(9 +ote &&00-B.
<e also re!ommend that ou set the 'alue for the /ustomi8in2 swit!h R)H7US)R7/?)/K in table
9RG+7/UST to L)M. This means that onl users of tpe R)H)R)+/) !an then be assi2ned. /han2in2
the /ustomi8in2 swit!h affe!ts onl new assi2nments of referen!e users. )Aistin2 assi2nments are
retained.
<e further re!ommend that ou pla!e all referen!e users in one parti!ularl se!ure user 2roup to prote!t them from
!han2es to assi2ned authori8ations and deletion.
?ow to disable fields in a Transa!tionN
S?#0 O .aintain Transa!tion Variants.
Transa!tion 'ariants allow us to sele!ti'el mas, !ertain fields in S(9 transa!tions%s!reens.
Thou2h stri!tl not a se!urit tool; transa!tion 'ariants !an ha'e appli!ations in se!urit b
helpin2 to pre'ent users from updatin2 fields whi!h are not prote!ted throu2h authori8ation
ob:e!ts
Transa!tion Variants are !reated throu2h the S?#0 t-!ode. The initial s!reen S?#0 is 2i'en
below. To !reate a transa!tion 'ariant we mention the name of the parent transa!tion; 2i'e a
name of the 'ariant and !li!, the !reate button.
"n our eAample below; we !reate a transa!tion 'ariant >SU0$ for the 'er !ommon SU0$ t !ode.
The transa!tion 'ariant allows an administrator onl to reset passwords and hides all other
fun!tions of SU0$. )a!h transa!tion 'ariant !ontains of one or more s!reen 'ariants dependin2
on the number of s!reens bein2 !alled in the entire transa!tion flow. <e donMt ha'e to manuall
,eep tra!, of the s!reen 'ariants when we are wor,in2 with transa!tion 'ariants. (s we mo'e
from one s!reen to the neAt; S?#0 automati!all !reates and appends a new s!reen 'ariant to the
sePuen!e.
4n !li!,in2 the !reate button for >SU0$; we are ta,en to the standard SU0$ s!reen. <e enter a
user name and !li!, the !han2e password button. ( pop-up window appears with a list of the
s!reen fields. This window !ontains the attributes of our first s!reen 'ariant. "tMs here where we
enter a name of the s!reen 'ariant and !an sele!ti'el mar, s!reen fields to in'isible%output
onl%rePuired; et!.
The s(reen -arant wndow has a button !or 6)enu 4un(tons7 where we (an sele(t-ely hde8de9
a(t-ate *enu te*s or toolbar buttons. Sn(e our ntenton s to dsable e-erythng e.(ept
password (hange optons, we end up wth below s(reen.
4n !li!,in2; the sa'e and eAit button we are ta,en to the o'er'iew s!reen for the transa!tion
'ariant. (s shown below; this s!reen 2i'es the definition of the indi'idual s!reen 'ariants whi!h
form part of the transa!tion 'ariant. 4n sa'in2 our entries; we are ta,en to the S?#0 initial
s!reen whi!h shows the transa!tion 'ariant and the s!reen 'ariants defined under it.
S?#0 pro'ides a test button here we !an !he!, if the newl !reated transa!tion 'ariants wor,s as
per our rePuirement. 4n!e tested we !reate a new > transa!tion (>SU0$) for the transa!tion
'ariant b followin2 the menu path GotoD/reate Variant Transa!tion.
4n!e set up; this new transa!tion !an be assi2ned to a userMs role :ust li,e a normal transa!tion.
)Ae!utin2; >SU0$ displa a modified form of SU0$ s!reen with all fun!tions other than !han2e
password button is disabled.
Or-ani1ational Levels
5 (ninda; on +o'ember -th; 20$0
F4r2ani8ational Le'elsG (4r2 Le'els) as opposed to authori8ation fields is another of the !ore
!on!epts that we !ome a!ross while !reatin2 roles in 9H/G. <e !an a!!ess the or2ani8ational
le'el 'alues defined for a role b !li!,in2 the For2 le'elG button in the main toolbar within
9H/G.
"n the role below; we see 4r2 Le'els li,e /ompan /ode; 9ur!hasin2 4r2; 9ur!hasin2 Group;
Sales 4r2; #i'ision; 9lant; et!.
9H/G - 4r2 Le'els
"n the eApanded 'iew of the authori8ation data in 9H/G; the or2 le'els defined earlier appear
side-b-side with the authori8ation fields. 2n fact/ all or- levels are also authori1ation fields
but not all auth fields are or- levels. Hor eAample; the or2 le'el 9lant appears as an
authori8ation field in two ob:e!ts; .7LH9L74RG and .7.(T)7<RK. 4n the other hand the
field ,ctivit0 is not an or- level. 4n!e we maintain a parti!ular 'alue for an or2 le'el in a role;
all authori8ation ob:e!ts usin2 the same or2 le'el as a field will automati!all ta,e the same
'alue. "tMs te!hni!all feasible to break an or- level; so that for a parti!ular ob:e!t; its 'alue is
different from its defined or2 le'el 'alue but this defeat a purpose of definin2 somethin2 as an
or2 le'el.
(nother differen!e between or2 le'els and normal auth fields !ome to li2ht while deri'in2 a role
from another master role. ( normal auth field will be inherited b the !hild role with the same
'alue as maintained in the parent but an or2 le'el !an be maintained in the indi'idual !hild roles.
9H/G - 4r2 Le'els 's (uth Hields
Or-ani1ational Levels in +ost cases are intrinsicall0 linked to the enter&rise structure of an
or-ani1ation and lar-el0 deter+ined durin- the custo+i1in- ste&s for the S,* s0ste+s$ The
below s!reen-shot from the S9R4 transa!tion shows the options for !onfi2urin2 different or2
le'els li,e !ompan !ode; !ontrollin2 area; pur!hase or2; sales or2 et!. So its not reall0 the
securit0 ad+inistrator who defines the or- levels$ .e can onl0 use the e3istin- or- levels
defined durin- functional confi-uration$
S9R4 - )nterprise Stru!ture
"ts possible to !han2e an authori8ation field to an or2 le'el for the purpose of se!urit b
eAe!utin2 the pro2ram *4C5!OR542'LD!CR',"'. ?owe'er; sin!e this pro2ram impa!ts
all roles whi!h !ontain the or2 field it should onl be run after a thorou2h analsis of all
impa!ted roles. (lso !ertain auth fields li,e ,ctivit0 !an ne'er be !han2ed to an or2 le'el.