Field Level Authorization For Customer and Vendor Master in SAP. - SAP Blogs

12/19/2018 Field level authorization for customer and vendor master in SAP.
| SAP Blogs
Products
Products Industries
Industries Support
Support Training
Training Community
Community Developer
Developer Partner
Partner
About
About
 
Ask a Question Write a Blog Post Login
Field level authorization for customer and

vendor master in SAP.
December 31, 2013 | 8,512 Views |
' MoazzaM '

more by this author
Security
share share tweet share like

1 Follow
Hi folks
This might be a known information for some of you but I am sure that this is
gona be a new learning for most of SCN users. I got a requirement to put field
level authorization restrictions in customer master data and in the first instance
https://blogs.sap.com/2013/12/31/field-level-authorization-for-customer-and-vendor-master-in-sap/ 1/27
12/19/2018 Field level authorization for customer and vendor master in SAP. | SAP Blogs
I thought this might not be possible in standard because although we have

authorization matrix level 2 but these are for some specific fields like sale
order type, sale area etc but not for each and every field.
When I searched in Google and SCN I found some links discussing

authorization object F_KNA1_AEN and I gave it a try and it worked. I thought I
should share it with SCN fellows so here it is.
Go to this following path.
Here create a field group with those fields you want to allow for changes. All
other fields will be in display mode for user.
In my case I want to allow user to change only withholding tax information. All
other fields will be in display mode for this user. I have added all fields which
are available in Withholding tax tab to field group 02.
After this assign this field group in user master’s role.
After Assigning this object and value check in XD02 for customer. All other
fields will be in display mode and only withholding tax fields are in change
mode.
We can use this object for different fields and tabs for customer master data.
For vendor master data authorization object is F_LFA1_AEN and methodolgy

is same. Menu path is also same till Account Payables and Account
Receivables and for Vendors Select Vendor Master and so on.
In short we can use F_LFA1_AEN object for vendors and F_KNA1_AEN for
customers. Helping note is 864058 and SAP help link is here.
Thank$
Alert Moderator
38 Comments
You must be Logged on to comment or reply to a post.
' MoazzaM ' Post author
January 1, 2014 at 6:30 pm
Naresh Krishnamoorthy
Thank you and Happy new year to you 🙂
Thank$
Former Member
I am somewhat surprised to see this security related blog approved by SCN.
The main reason is that it is just a regurgitation of the documentation on the object. That
documentation stares you in the face if you ever build a role for any of the transactions
or hit F1 in one of their fields which can modify master data.
Close on it’s heals is that use of field groups and authorization groups is classed as one
of the dumbest things you can do in SAP. It creates a large increase in retentive
complexity (not least of which on role design and number of them, which is anyway an
art form) but most end users are aware that it is only checked in the screens of a
selected few transactions and not in the APIs, mass processing, LDBs, the larger part of
ALV type controls and batch-input.
That SAP proposes the object for display type core transactions without values such as
XD03 / XK03 is normally a clear indication that it is best to get it out of the way by putting
a * into the field. For the parts where there are no checks at all (you normally notice them
quite quickly) SAP only offers the solution to modify the system.
So… why regurgitate basic information and have you ever actually used these
authorization groups of customers and fields in an organization with more than a handful
of customers and survived it? The motivation for this blog seems suspect to me…
Cheers,
Julius
January 2, 2014 at 5:10 am
Dear Julius von dem Bussche
Thank you for showing your concern and giving your views. As I have
mentioned in my first line that this might be a known thing for many users
but still there are a lot of functional consultants who don’t know this. You are
a security consultant with tons of knowledge so this looks like a basic
information for you. I have shared this in SD forum where I am sure this is
not basic and many of us were not familiar with this.
I have always shared document and blogs which I have used at my

workplace. I am using both objects for customers and vendors.
I received a requirement that withholding tax information is something which

they want to give a specific user. He’ll have access of XD02 but he
shouldn’t be able to change any other field except withholding tax. We are
also suppose to show him all other fields. What would be the best possible
control or solution for this requirement? Please share your views on this.
Thank$
Former Member
Hi MoazzaM,
Does the optional use of groups for master data records and
fields not belong to basic training in the SD module? That
surprises me somewhat – hence I see this document as a
regurgitation of standard documentation which anyone with
basic training should already be aware of.
As optional feature it protects fields which the attribute (group)

is added to. Permitting access to one field (set) only means
that you must have created an alternate field group and
assigned that to all other fields in all other tabs of master data
maintenance. Although that only has the unfortunate
consequence of doubling the number of roles for master data
maintenance, further attempts to have a naming convention
within a 2 CHAR field to create different slices of access to
different fields for a limited person or time very quickly creates
a mess.
I certainly question such requirements before considering a

solution with a big impact (e.g. it might just be an apprentice
who they want to have maintaining some master data fields for
a few days – no need to turn the security relevant customizing
on it’s head for that..). Even so there is an alternate after-the-
fact control if you use the check flag “Not authorization
relevant” on the field -> you can then have a batch job running
looking for changes to the fields outside of the group by user
NE the user and IF FOUND then send an alert mail to the MD
team. That is certainly more security friendly and if the
business process changes you can easily change the variant
for what is monitored and not have to turn customizing and
master data around again.
A blog on the pro’s and con’s of preventative vs. detective

controls in master data maintenance would be interesting to
read about what works for others. Repeating help.sap.com
documentation is not interesting (at least it is not for me and I
rather read the help.sap.com documentation of the current
release I am on incase something changes – eg. the search
helps were extended for authorization relevance recently but
that is not in the 4.0 documentation…).
Cheers,
Julius
Hi Julius
Thanks for explaining in this much detail 🙂
If I explain customer group fields KNVV-KONDA,

KNVV-KVGR1 to KVGR5 here then those would
be basic from SD point of view. I have been
working as SD guy since 2009 and I got to know
about this authorization control last week. This
might not be the case with everyone else but may
be for some knowledge seekers like me.
I have shared SAP help document and sap note

for more clarification and for references. In help
document they have explained the use of object
and I have added a real time business
requirement and some screens with menu paths
etc. I know this is not that much technical or
advanced for you or other senior members but
here in SCN we have users and members from
different career level and unfortunately no
document was there in SCN. I actually searched
in SCN and google and couldnt find any
document explaining this with screens and
example so I posted this document here.
The process you have explained is another

alternative solution for this and that can be
chosen by some very big clients where they have
big teams for MD but in our case we have one
user who maintains master data for customers in
SAP. Finance guys were always with an excuse
that sales guys are in a habit to put wrong
information in withholding tax fields. So the
requirement was to give this authorization
permanently to FI guy and now whenever a
customer master data is opened in SAP
withholding tax data will be maintained by FI guy.
I did some R&D and this was the best possible

solution which I came up with and have
implemented for customers and vendors both.
I have shared some very technical documents as

well but it is not always for experts and gurus like
you. Sometime we have to take care of beginners
and middle level users as well. I am including
myself in middle level users because still I am not
familiar with many of the things which I should

know. Thank you for your concern again and I
appreciate that you noticed it and shared your
views.
Thank$
Former Member
Well, if anyone ever did encounter

this requirement or even the thought
of it then they could do the same
search as you did and also find all of
the same (repeated) information all
over *.sap.com sites.
https://www.google.ch/#hl=de&q=site
:sap.com+how+to+maintain+only+so
me+fields+in+master+data
Now there is one more.. that is why I

don’t see the benefit of the
information outweighing the noise
factor.
Cheers,
Julius
When I was searching in Google I

actually had seen this link. There are
two things I want to tell you about
this link. The discussion was not
marked as answer as the issue was
not exactly resolved. In this whole
disccusion Ravi Sankar Venna is
most senior user and see his reply.

He said that in FI we don’t have this
kind of structural authorization.
Well you could find another link

which has more relevancy and Atif
has explained it well. Just check this
link.
http://scn.sap.com/message/104970
10#10497010
Thank$
Former Member
Hi MoazzaM,
Attn: Julius.
Very Happy New Year to you both

and to all of the readers of this post
🙂!
MoazzaM, I share your passion of

sharing knowledge so that people
who have lesser experience than us
get new inputs and expand their SAP
Knowledge. This trait of yours is
commendable and not many people
do this now a days.
I love reading your replies in these

posts and you being a Top
Contributor to the group is a nice
example of the gift of sharing of that
knowledge.
While what you may read further

might look like condescending
statements from my side, the
intention is purely to try to bridge the
gap of understanding and
interpretation of the concerns from
different worlds. You have already

done your part in this direction, but
coming from a third person like me
might help further help the case.
Also, I have some minimum

exposure to working together with
Basis / Security so that makes me a
little comfortable in sharing my
thoughts here.
Here are my two cents:
What Julius may be pointing out is

that while it may look like there is a
easy / direct solution to problems we
face for field level authorizations in
the Customer / Vendor Master
specifically, this type of document is
more in tune with a narrow
interpretation of Authorization
Groups usage and Authorizations in
general.
As pointed out, this might turn out

more of a bigger impact item than
what may appear to be a simple
solution. Further, most of the times,
the SD / FI Users are not even be
privy to having authorizations for
such activity. Most likely that is the
case, everywhere. This has to be
done by Security/Basis in
conjunction with SD / FI Folks rather
the other way round which this
document may unintentionally
convey.
This post has reopened my eyes on

the difficult walk of sharing
knowledge yet not assuming that a
solution is easy / robust / has low /
no impact to other modules. I myself
have been a culprit in such situations
in the past so try to be very careful.
When we give documentation on any

topic we may want to limit ourselves
as much as possible on what is
normally considered as regular
feature of our specific module.
This document might give a wrong

sense of security [pun unintended] to
people who are new / less
experienced in SAP as having
specific solutions whereas this may
lead to more head aches for
Security/Basis to deal with.
Personally for me, SAP being an

integrated system, this kind of
information[without going into the
debate that this is redundant /
regurgitation ] when shared does
expand the existing cross module
knowledge of SAP Consultants, but
as said earlier [ to the point of
repeating ] has the danger of
imparting half baked wisdom for
some Functional Folks. That I think
is one of the concerns shared by
Julius and I fully subscribe to that
too.
Julius : I do have to share my

experience in this point. I have been
around in SAP for sometime and I
did undergo proper in depth SD
Consulting Training but this is not
something which was covered as a
basic topic. May be in that sense my
training was probably not so detailed
after all 🙁 .
That being said, I do know of this

feature and use based off my
knowledge in the practical project
environments and my generic
knowledge of Auth. Roles and
Profiles Creation using PFCG sitting
with Basis[not security as it is

segregated today
MoazzaM: You may want to include

some caveats on the potential bigger
impacts on Authorizations / Security
related issues which would crop up
on trying to implement this specific
solution.
I rest my rant 🙂
Apologies if some part of my

statements may not be agreeable to
anyone.
Have a good day gentlemen.
Thanks.
Dear Dee Sea
Thank you very much for showing

your interest and sharing your views
in this detail.
As I mentioned earlier that this is just

a way to control this and I have done
this with my ?BASIS guy. Even
though I know a little about roles and
authorization objects etc but I have
always taken concerned person in
loop whenever I made any change in
some other area other than SD. This
was the best possible solution for us
and its working fine. As far as this
document is concerned I am in a
view that this is just a knowledge
sharing and I have tried to simplify it.
If someone hit in Google with text
field level restriction and he finds this
document, he will obviously analyze

it, discuss it with their BASIS guy
and then decide whether to go for
this option or not? This document is
not mandatory to implement.
In SAP sometimes we have many

alternative ways to control one thing
these ways can vary for every user
depending on their business, culture
or may be requirement’s background
etc.
Thank you once again for showing

your interest.
Thank$
G Lakshmipathi
MoazzaM
These sort of activities are purely lies with Security team. Also since you yourself have
indicated
I have shared some very technical documents as well but it is not always for
experts and gurus like you. Sometime we have to take care of beginners and
middle level users as well.
definitely, no beginners or middle level users should try this considering the fact that in a
real time projects, they would not be handling this.
Also, ideally, this blog is applicable to beginners or middle level users of Security and not
functional consultants. Hence, this can be moved to Security forum.
G. Lakshmipathi
Sir
Ideally this is security team’s responsibility to control and manage this kind
of authorizations and this is also SAP best practice. Being on functional
side we should at least know this whether it is possible or not and if
possible how we can do this. This is my personal opinion which you or other
users can agree or disagree.
Since it is regarding customer fields so I posted it here. If you think this

should be posted in security forum then you can move it. If you and Julius
think this document shouldn’t be posted in any of forum you can remove or
hide it. I am saying this with positive attitude and I don’t want to go against
community rules.
Thank$
Former Member
I certainly agree with you that application security goes hand-

in-glove with application functionality and a functional
consultant who participates in solutions is worth gold. For sure
it should not be the responsibility of basis to make such
decisions and a functional consultant who is closer to the
application owner is the best option for bridging the gap
between the system and it’s use.
In reality out here they however mostly just memorize SPRO

paths and go to meetings… 😉
Cheers, Julius
Dear Julius
You would be surprised to know that I am SD guy

but I have worked on authorization roles, objects
and fields a lot. We had to create new users and
our BASIS guy asked us to create roles in DEV

server and they just downloaded those roles and
then uploaded in PRD. This is the reason we
have to work with these security issues as well
and I have tested this document on my own and
then asked BASIS guy to just give authorization
of this field group to user.
Although this is not our duty but sometime we

have to do it so its better for our learning and
knowledge. I think having knowledge of multiple
areas is not a bad thing.
Thank you for agreeing with me. Thank God there

is at least one person who agreed with my one
point 😀
Thank$
G Lakshmipathi
Thank God there is at least

one person who agreed with
my one point 😀
This is not a positive statement

MoazzaM !!!
G. Lakshmipathi
Sir
As you can see a big smile at end of

the message and it shows that I said
this just for fun. There is nothing
serious or negative attitude in my
statment. I didn’t mean that what you

understood and this is drawback of
written communication that you can’t
show your emotions even though I
tried but I think I am failed in that. I
am sorry if you took it in wrong
sense but I said that just for fun.
Regards
Jyoti Prakash
Document moved from SAP ERP Sales and Distribution (SAP SD) to Security
Dear Suseelan Hari
Please test this and update me if you feel any issue. I have shared SAP note relevant to
this document. You can take help from that note too.
Thank$
Former Member
Sure Moazzam! Thanks
Former Member
Hi MozzaM,
I really appreciate your passion to share knowledge.
Infect though this is technical information, its very useful for functional
consultants considering, sometimes new Technical consultants does not
know all these points and these questions comes to us for answering that is
it possible in standard SAP or not.
Thanks for sharing.
Have you come across similar requirement on Sales order or Delivery or

any other SD transaction creation where User is supposed to change only
One field. And that is only if he has authorization for that specific field
change?
Regards,
MJ.
Former Member
Hi Mahendra,
What you have seen is authorizations specific to the Objects

Customer Master and Vendor Master. These are master data
related transactions.
Sales Order, Deliveries and Billing are Business Process

related Transactions. These have different controls than
Master Data.
It may not be feasible so easily for these as there are different

controls for them, but I leave it to MoazzaM to answer that.
MoazzaM: You may need to set the right reader expectations

from this document with respect to limitations and caveats.
Thanks.

Hi Mahendra Jani
Thank you for your words and yes I came across such
requirement for sales documents. For that we can use custom
authorization object. We have to create object in SU21 and
then assign that in respective userexit with authority check
logic.
Dee Sear is right that these objects are for master data. For
transactional data there are different controls. Sometimes we
can can control through custom objects and sometimes
through SHD0 variant.
Thank$
Former Member
Hi MoazzaM,
I like your confidence in these things. Happy to

note that this is doable. 🙂
Even though I have extensively worked with

Basis/Security, personally, I would like to be on
the safer side of things 🙁 and think of having
extremely limited knowledge on this topic.
From what I was made aware of by Security Guys

[worked with some big Industry Gurus on that]
there are certain limitations on this topic with
respect to Transaction Data.
I believe Transaction Process Programs are more

complex than Master Data and there are lots of
different points in the program where these
Authorization Specific Fields could be potentially
get called on. Whereas the Authorization Checks
basically take place only on certain initial screens
and further checks do not take place or they are
not effective.
Anyways, what I am discussing here is a

theoretical topic and every requirement for these
kind of transaction can be different so will leave it
at that.
That being said, happy to know that you seem to

have a grip on this subject, which is true Cross
Module Knowledge[something rare between SD &
Security].
My sincere advice to you would be, to write a

document with different scenarios [especially the
Sales Order one] on this topic and may be publish
for the benefit of SAP – SAPPHIRE audience.
That will be a good exposure.
I will log off from this discussion now. I don’t think

I will be a good contributor any longer for this
topic.
Have a good one.
Thanks.
Hi Dee Sea
For security and authorizatin we

have authorization objects and
screen variants etc sometimes there
are many ways to control one field
and we have to see which option is
suitable for it.
For sale order process we have

certain userexits where we can add
customized authorization object for
any field and can control it user wise.
Thank you for your advice and I will

see if I could do that.
Thank$
Former Member
Hi MoazzaM,
I do understand many of those

things[if not all] being in this field[pun
unintended] for a good enough
amount of time.
I may not know the exact object

names, user exits, Auth. Profile
names, Etc. for the particular
mappings, but that is I believe in the
larger scheme of things should be
not so difficult.
I get the whole nine yards with

respect to the concept, the touch
points and that is enough for me.
Thanks and Hats off to you for that.
I had other points which I think at this

stage are irrelevant and to repeat
again, I dont think I am any longer a
positive contributor in this post, so I
will close my rant for the last time
and for sure, stop following this post.
You have a good day.
Thanks.
PS: The above being said, you can

still think of sharing this knowledge
with SAP SAPPHIRE audience. I
believe it is worth the effort. 🙂
Shiva Vasireddy
September 10, 2014 at 8:32 am
Hi moazzam,
This is excellent learning for us,Thank you for the contribution
Hidayathulla Hasan
September 10, 2014 at 1:35 pm
MoazzaM,
Nice document. Keep sharing and rocking on SCN.
Thank$
Hidayath
Former Member
February 20, 2016 at 12:34 pm
Dear Moazzam,
Really helpful document.
I have tried to do same with Vendor Master, the only issue I have faced with the process
is that I’m not able to find out Fields related to vendor master.
Every time it is saying that “field name ‘xyz’ is not allowed.”
Can you please provide me list of fields for the same which can be applicable to Vendor
Master.
I want to allow user to change only withholding tax information. All other fields will be in
display mode for this user in T-code XK02.
Please help me with this…
Regards,
Parth Raval
March 10, 2016 at 2:32 pm
Hi
I hope you would have found some solution. I am sorry I couldn’t respond
you timely. Let me know if you have still the same issue.
Thank$
Former Member
March 11, 2016 at 12:48 pm
Dear Moazzam,
I have done this through screen variant finally.
Please let me know how we can do this in vendor master using

field authorization. I want that list of fields.
Thanks in advance.
March 15, 2016 at 9:38 am
Hi
I can see all the fields available for vendor in

below node. Please check again and follow the
document steps for vendor. You should be able to

do this as this is standard functionality.
Thank$
Former Member
March 16, 2016 at 5:20 am
Thanks MoazzaM for answering my

queries.
But as you have mentioned in your original

post, I want field names for withholding tax
tab for vendor master same as given by
you for customer master.
Please find below snap from your post.
” In my case I want to allow user to change

only withholding tax information. All other
fields will be in display mode for this user. I
have added all fields which are available in
Withholding tax tab to field group 02.
Thanks and Regards,
Parth Raval
March 16, 2016 at 11:52 am
Hi
I can see the fields. See in this below

screen and follow the steps
explained in this document.
Former Member
March 17, 2016 at 5:49 am
Thanks a lot Moazzam. I will try the

same using these fields and get back
to you if face any other issue.
Can you please also share the path

where do you find these fields..??
March 17, 2016 at 10:02 am
Hi
You are most welcome to ask but

please don’t expect spoon feeding
from me.
Thank$
Former Member
March 17, 2016 at 10:12 am
Agreed and accepted.. 😀
Former Member
October 3, 2017 at 9:25 am
Hi MoazzaM,
thx for this really useful manual, I had to create a new role for a customer which in XD02
would not be able to edit Payment Transaction fields but all the others, so creating a field
group with that bank data and assign that field group to the auth object works! 🙂
The thing is, I need to do the opposite, I mean, grant access only to Payment
Transactions fields but not to the rest of the XD02… I could create another field group
and add ALL these fields .. but could be really hard …. Is there any other way to do this?
to have the whole XD02 not editable but only some few fields from Payment Transaction
tabs by a role?
Thx!
Hi
Sometimes in life we need to take hard decisions and I believe this is one of
those for you 🙂
I don’t see any other way without using ABAP or screen variants. In
standard this is the only way I know dear.
Thank$
Former Member
Well, life is hard sometimes XD
thanks for your prompt answer!!
Share & Follow
Privacy Terms of Use
Legal Disclosure Copyright
Trademark Cookie Preferences
Sitemap Newsletter

Field Level Authorization For Customer and Vendor Master in SAP. - SAP Blogs

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Field Level Authorization For Customer and Vendor Master in SAP. - SAP Blogs

Hochgeladen von

Copyright:

Verfügbare Formate

12/19/2018 Field level authorization for customer and vendor master in SAP.

Field level authorization for customer and

' MoazzaM '

share share tweet share like

I thought this might not be possible in standard because although we have

When I searched in Google and SCN I found some links discussing

Go to this following path.

After this assign this field group in user master’s role.

For vendor master data authorization object is F_LFA1_AEN and methodolgy

' MoazzaM ' Post author

January 1, 2014 at 6:30 pm

Thank you and Happy new year to you 🙂

January 1, 2014 at 8:43 pm

I am somewhat surprised to see this security related blog approved by SCN.

' MoazzaM ' Post author

January 2, 2014 at 5:10 am

Dear Julius von dem Bussche

I have always shared document and blogs which I have used at my

I received a requirement that withholding tax information is something which

January 2, 2014 at 9:58 am

As optional feature it protects fields which the attribute (group)

I certainly question such requirements before considering a

A blog on the pro’s and con’s of preventative vs. detective

' MoazzaM ' Post author

January 2, 2014 at 10:41 am

Thanks for explaining in this much detail 🙂

If I explain customer group fields KNVV-KONDA,

I have shared SAP help document and sap note

The process you have explained is another

I did some R&D and this was the best possible

I have shared some very technical documents as

familiar with many of the things which I should

January 2, 2014 at 11:14 am

Well, if anyone ever did encounter

Now there is one more.. that is why I

' MoazzaM ' Post author

January 2, 2014 at 11:38 am

When I was searching in Google I

most senior user and see his reply.

Well you could find another link

January 2, 2014 at 7:55 pm

Very Happy New Year to you both

MoazzaM, I share your passion of

I love reading your replies in these

While what you may read further

different worlds. You have already

Also, I have some minimum

Here are my two cents:

What Julius may be pointing out is

As pointed out, this might turn out

This post has reopened my eyes on

When we give documentation on any

This document might give a wrong

Personally for me, SAP being an

Julius : I do have to share my

That being said, I do know of this

with Basis[not security as it is

MoazzaM: You may want to include

Apologies if some part of my

Have a good day gentlemen.

' MoazzaM ' Post author

January 3, 2014 at 5:57 am

Dear Dee Sea