Question:
We have a need for certain users (about 6) to access multiple company
codes for the purpose of entering cross company code transactions. FB50, FB60, etc). We do not want them to have access to these multiple co. codes regularly (other tcodes), or view the financial information on other company codes trough other transactions.
We are looking for the best solution. We have reviewed the options
listed and thought better to find out if some other solution already
existed or what the industry believes to be the best solution?
OPTION 1:
1 is to setup a profile that allows access to the appropriate company codes and the appropriate transactions needed for this request
2. as in this ymftest program, temporarily assign this profile either through a frontend with embedded tcode call transactions OR with a user exit if one can be found at the appropriate place
3. then remove either with frontend 'after' the call OR in another user exit after saving the document
The issue (bad or good is debatable).. is that these are traced in the change documents of the user file. You need to run this by Dawn. It's good for audit, .. but can possibly increase the size of the change files. While in this transaction, the user has access only while in the frontend program and in the tcode being used. The frontend program itself, would not allow access. Only while in the call transaction.
Problem with Option 1: The user may create a new session while in this ztcode and the user will have authorization for other company codes for other transactions at that time.
This is not desired.
OPTION 2:
1. also create the profile
2. call a function to read all of the objects and authorizations for this profile
3. update the buffered table with these values directly
the issue here is that there is no audit traill.. this can not be traced, but the change files do not grow either. The other downside is the buffered table is can be resynced during the transaction causing an authorization failure. I don't know how likely this is, but we must consider it..
Same Problem as Option 1.
OPTION 3:
Copying all of the tcodes and commenting out ... This would cause a maintenance nightmare if standard code was changed relating to these transaction that could cause incompatibilities that would not be detected during the hotpack application.
Not desirable due to the impending upgrade of the system next year.
OPTION 4:
Modify SAP code to add additional authorization check for certain users. This might be a little difficult to identify the places to make the changes for each tcode, but would be easily maintained during upgrades.
The core mode will show up during SAP system upgrades.
Let me know if you need anything more!
I have searched Sapfans.com b
_________________
Regards,
Dean Crump
Answer:
Do nothing Clever.. All these options are too Clever. Give these users all the co codes, it is only 6 and move on to something more important.
There are change documents to monitor activities and tcode analysis, but frankly if you trust these 6 to perform cross co transactions then you should trust if the "see" more info....
For those Companies that want to pay the price of extra maintenance and insist on "i want" controls rather than Risk based and potential of occurance controls, is to set up two IDs for these 6 users, one with the user's normal access and one with the cross co access. Then you can target access more strictly on what can be controlled. however many of the SAP tcodes in FI say they are one thing but allow you to do others functionality. SO while you think you are "controlled" you may not be.
Answer:
Cross Company code posting is one of those things that comes up regularly. Usually the pragmatic approach is to let give a very limited number of users access to these company codes in the objects which allow posting for the tx that they need (will allow them to do other stuff too) and put in suitable monitoring controls to mitigate the risk if required