Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Role and Naming concpets

pradeepmathewch
Employee
Employee
0 Kudos

Hello All,

While creating custom roles(Z&Y), could anyone explain the importance of having a good naming convention?

Thanks a lot in advance.

Regards, Pradeep

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Pradeep,

You should create a naming convention in order to make your life easier in the future.

Imagine having a bunch of roles with numbers that you don't know. I suggest you to do something like this:

Yxx:vvv.yy_vvv

xx = to module

vvv = sequence

yy = to contry code (yf you do not have different contries than you could use company code, or plant)

Any questions let me knwo.

Best Regards,

Lucas

9 REPLIES 9

Former Member
0 Kudos

It's a bit of a no brainer really

good naming convention:

- Easy to identify purpose of role

- Identify important restrictions (e.g. org level/business unit)

- gives consistency

- makes role admin easier

- Reduces communication errors

- Makes role reporting easier

there are plenty more reasons which I'm sure others will chip in

Former Member
0 Kudos

Hi,

Others coventions you can use is that you can differenciate between different type of roles:

for eg

M for master roles

D for derived

C for composite roles

S for single roles

These are just examples..Y ou can use your own naming coventions so that you can differenciate between these types of roles

Regards,

Tajinder

Former Member
0 Kudos

Pradeep,

You should create a naming convention in order to make your life easier in the future.

Imagine having a bunch of roles with numbers that you don't know. I suggest you to do something like this:

Yxx:vvv.yy_vvv

xx = to module

vvv = sequence

yy = to contry code (yf you do not have different contries than you could use company code, or plant)

Any questions let me knwo.

Best Regards,

Lucas

0 Kudos

The example Lucas is giving is a good starting point, but remember that there are more positions available so you can use more than the 2 positions in the example given for each.

However be sure to Allways have the same kind of information on the same position, when evaluating your roles with a query that is a must.

Also try to think ahead about all variants you might need so be sure to have your naming convention fit.

and a problem i have seen often: do not try to have a meaningfull name in the technical name of the role, as then the company might try to force you to use more positions then you have designed in your format. Losing all query functionallity

0 Kudos

I (think) agree with Auke, I am now tending towards using a numbering system instead of a description in the title as role contents can change over time, as can role titles. I have used the descriptive approach successfully before so will not write it off!

0 Kudos

Hi

As mentioned earlier by our other friends, here is one more thing to be considered.You will also have to take care of the organization/companies for ease of maintenance. Big companies have number of operating comapnies and to differentiate these companies there should be some standard

for example

1st character is Z

2nd would be the organization identifier

3rd would be Module or functional area.

then a separator indicating whether it is single role.derived role or composite role.

and make a matrix for such standards.

Hope this helps

Thanks

Santosh kumar

0 Kudos

Certainly you have to make the standard fixed and describe it. Try to get the document describing your naming convention signed off at highest management level!

On Org qualifiers be certain to get the right info from business. I have seen big mess made out of that

as finance people wanted the financial Org Qualifiers to show in the naming convention while others wanted to stick to the organisation like company , plant etc.

Best approach is to look at how the organization is fiscally situated, like in which office/companies sit and make it as simple as possible.

One more thing about Org Qualifiers (derived roles) be sure not to use them simply because they are there but ONLY when there is a risk leaving them on STAR (*) this mostly limits the number of qualifiers to be populated to a reasonable number and also gives a nice handle on how to organize your Org Level naming convention.

Tip Company code is 4 positions in SAP so why not use that code in the naming convention, mostly it looks like 0040, 0060 etc. If you need to go deeper (like to office or plant level you might use 0021, 0022 etc.

On naming Convention with regards to composites and Singles be sure to make a distinction, here are some examples I have used in the past:

SINGLE ROLE: Z: or A: or Z_

Composite role Y: or C: or C_

What you use is not so important (advise do not use S as that is the starting letter of SAP standard roles)

The format I prefer : Z:R3_FIN001_0200

Z= single role

R3 = SAP R/3 , also BI or BW etc

FIN= Finance role

001 = first role in sequence

0200 = company code as in Org level field BUKRS and for the master roles (basis for derivation) i use XXXX and for roles that have wide access CCCC. If the roles does not contain org fields I use the XXXX varaint in the composites.

Hope this helps you on the way?

Former Member
0 Kudos

I'm a developer (non-ABAP) turned security admin, so it was a no brainer for me after programming for 15 years. We've developed a standard to support our entire landscape of systems with a consitent naming standard.

<h2>Role Names</h2>

Role names will be prefixed with Z, followed by three identifiers that are separated by an underscore.

Z<System Type><Role Type>_<Group ID>_<Description>

<h2>System Type</h2>

The following table lists the valid System Types

ID Description

E ECC

G GTS

B BW

X XI

<h2>Role Type</h2>

The following table lists the valid Role Types

ID Description

M Master Role

D Derived Role

S Single Role

C Composite Role

T Test Role

<h2>Application Identifier</h2>

ID Description

CO Controlling

FI Finance

LE Logistics Execution

QC Quote to Cash

RP Request to Payment

BC Basis

BI Business Intelligence

DV Development

<h2>Description</h2>

u2022 Meaningful abbreviation of role purpose

u2022 To include clear indications of functional job role, an indication of purpose, and a possible identifier for organizational value indicators (i.e. division / plant / company code) that are used for derived roles.

Examples

u2022 ZEM_QC_CUST_SERV_REP

o Master Role for Quote to Cash Customer Service Representative

u2022 ZED_QC_CUST_SERV_REP_1340

o Derived Role for Quote to Cash Customer Service Representative for Sales Organization 1340

Former Member
0 Kudos

Hi,

For Roles definetly naming convention should be maintained.

It will be easy for us to make work easy.

See make naming convention of roles in such a way that for Roles having transaction codes can be named as zt_..... and roles that contain only infotypes can be named as za.......It can be easy to differentiate roles and easy to assign to users or to do modificationswhen required.

Regards,

Parimala