Edit SAP Table without Authorization

It does not matter what access you have for table editing (S_TABU_DIS). Just use the command &SAP_EDIT in the command field in SAP and off you go: you can edit table content directly. This works if you have debug with changes access for object S_DEVELOP, but S_TABU_DIS is ignored as well as the system settings regarding changes. If you use this function for transaction, master data or other tables that cannot be changed with SM30, you can cause quiet some damage. So, use with caution and this is NOT a Best Practice by all means, but to educate you on a little documented feature:

Step 1: Use transaction UASE16N, SE16N or transaction N (yes, there is a transaction called just ‘N’) and enter a table of your choice, for example SKA1 G/L Account Master (Chart of Accounts)

 

 

2) In the command field enter ‘&SAP_EDIT’ and press enter. The maintenance indicator in SE16N will switch on.

 

 

 

 

 

 

 

 

3) Limit the search of your data or execute for all values and you will see, that the table entries can be edited:

 

 

 

 

 

 

 

 

 

 

If you limit the users access not to have access to S_DEVELOP with change activities for object type DEBUG, this function will not be possible (tested on ECC5)
If you want to allow this function, you can audit who changed data via SE16N by browsing the following tables;
SE16N_CD_KEY : Change Documents – Header
SE16N_CD_DATA : Change Documents – Data
You can also run report RKSE16N_CD via SE38 (or create a custom transaction for it for ease of use).

We recommend to apply SAP Note 1420281 – CO-OM tools: SE16N: Deactivating &SAP_EDIT. SAP will deliver this correction with Support Package 17 and Support Package 18 (Release 600). This note deactivates the SAP Support function &SAP_EDIT completely for SE16N – Please make sure no users have access to transaction UASE16N as they may use it as alternative. Apply SAP Note 1473881 to disable UASE16N.

Please leave a comment if you have tried this out:
SAP note 1446530 enables one to use again the SE16n edit function on a case to case basis. As an authorization check it uses S_ADMI_FCD with field DBA.

But wait, there is more….If your developers have access to SE38, SE80, SE37 and other development transactions, they may want to trick you by using SE37 and executing function module SE16N_INTERFACE with the options I_TAB, I_EDIT and I_SAPEDIT activated and still maintain tables. The good thing is, that these changes are recorded and can be viewed with report RKSE16N_CD, the bad thing is that it may be already too late if the users changes financial data or any other tables that are not supposed to be maintained via SE16 type of transactions.

For starters, you should not give any development transactions to anyone outside the development environments and only allow SE37 etc. to be used via emergency procedures as once development access is granted, the users have the keys to the kingdom.

Now, if you still want to give access to development transactions, you need to lock them down. For the Function Module SE16N_INTERFACE, you need to exclude activity 16 and Object name SE16N for object S_DEVELOP.