- Reason 1: If you are ISO certified, then you will be going against their instructions
- Reason 2: If you are bound by SOX compliance then you will not be adhering to it
- Reason 3: You can cause data inconsistencies between tables that have relationships with each other. It will not maintain referential integrity between the tables.
- Reason 4: SAP will not support any inconsistencies brought about by this method
Regarding security around this feature here are some points to note:
- It can be protected by the developer authorization S_DEVELOP (object type DEBUG activity 03 and 02 and 01). The user needs access to both SE16N and DEBUG before it’s available.
- All changes to table contents are updated in seperate change document tables. These tables are:
– SE16N_CD_KEY : Change Documents Header – Stores the user, the modification date and time
– SE16N_CD_DATA : Change Documents Data
- In addition you can apply notes 503274 and 597117 to specify a display transaction only, which does not allow table changes.
- If you are paranoid then block the transaction via SM01
- If you are crazy paranoid then remove the transaction from table TSTC 😉
Lastly a comment from Julius:
“For other readers, please also see SAP note 587410. With this authorization, you can use SE16N’s function modules to go *accross client boundaries* and turn the change authorization checks on S_DEVELOP and S_TABU_DIS OFF (!) when calling the FM.”
Suggestions for use:
I only use this on Z tables in a development environment where I do not wish to have table maintenance generated and I understand the referential integrity associated with the table.
Any thoughts and comments go to TIP: Changing entries directly in any SAP table