Skip to Content

TIP: Editing any table in SAP!!!

Use transaction SE16N -> Enter the table name and press enter to read the fields in.

Then type &SAP_EDIT in the transaction area (as a function code) and hit enter. A success message displays saying “SAP Editing function is activated”.

You can now execute the report and you can edit any field except the key fields.

Use with caution!!!
See blog Editing tables using SE16N and the security implications for the security implications of using this transaction

The comments have been great on this blog and it shows there’s a need for an explanation on how the security works which I will update here shortly.

In the meantime I’ve been asked to urge you to rather move the conversation / comments from the blog on to the forums where I have created a similar topic for discussion at TIP: Changing entries directly in any SAP table . Thanks

You must be Logged on to comment or reply to a post.
  • It’s a handy tip to be sure, but an adequately secured production environment would allow such a high risk activity to be granted by only tightly controlled firefighting roles. On behalf of all of us who will now be called up to explain this to audit and controls people who may read SDN blogs, thanks, Kevin 🙂


    • The response to this “shortest blog ever” is wild. Of course it goes without saying that it should not be used in a productive environment. I use it only in dev while testing. Happy ABAPing!!!
      • I do find it quite entertaining as to the responses….. What do the words “Use with Caution!!!” mean?
        Run out and do this in production… Of course not, use this in Dev where you need to add, change and delete entries in z tables where you don’t wish to create table maintenance on.
        Thanks to all for the security comments so go ahead and make production secure….
  • Hey Kevin..this is better than going to debug and change to edit mode of tables in some situations.I am sure security guys are going to block this as soon they read this blog 🙂 Anyways Thanks for sharing this…cheers!!!
  • Once some consultants find out about this tool they think this is the fix for everything. It has to be used as a last resort.

    With great power comes great responsibility. 😀

  • This should be disabled in any productive system. As was noted above I have seen people become dependant on this to fix problems, and sooner or later something fundamental will get broken.
    There is a very good reason why most companies say you should never do a direct table update on a standard SAP table in one of your custom programs. Many tables in SAP have dependencies on one another and changing an entry in one table and not the related ones can cause all sorts of odd side effects.
    Having said this, this trick (SE16N edit) actually gets taught in ABAP programming courses in Australia, which is where I first heard of it.
    Do I use this in the development system? Of course I do!
  • I was there when a colleague implemented this as an efficient way to edit table content. Normally consultants shouldn’t have the S_DEVELOP/DEBUG authorization in prod system so it should be no problem to know this. It checks the same authorizations that allow you to edit any table content in a productive SAP system via SE16 anyway.

    And when you’re in SAP development and you’re working on customer messages in their productive systems this simply rocks 🙂

    • One thing which I find funny about this, is that parts of the ABAP Editor and the Debugger are written in ABAP themselves. A carefully placed breakpoint can stop a change record from being written in a customer system!

      What’s cool (in a small way..) about SE16N is that to delete the records, you dont only need debug authority… you actually need to know how to use it!

      Before going “techie” I was a controller and later a public auditor. I feel the pain of these guys because of legislative and company “features” which cannot eaily be represented in a static ABAP program with config extensions in tables.

      But, having said that… changing data in a transaction source system is *not* the way to go…


  • At least, SE16N writes the result of the change to the database separately. Report RKSE16N_CD will show you the changes including table name, change time and user and table contents.

    If you use SE16 and switch on change mode in debugger, the syslog will tell you THAT but not what you changed, not even the table.

    So it must be stated that SE16N is the far better alternative.

    Regards, Clemens

  • SE16N is available since R/3 4.6C (and its future versions R/3 Enterprise and ECC) and was supplied as part of CO-OM tools. So, it does not exist in Basis system, and consequently not in CRM, SRM, etc.
  • Awesome.  I’m sure SAP loves the fact that you published this and can only guess that they’ll remove it.  Now I’ll have to go back to Se16 and edit tables with debug.  Thanks…  really appreciate it.
    • Come on Nathan, this is a great tip that needed sharing so that others can use what you already know. Now that it’s out there the security guys can lock down Production and if that bothers you then, as the other comments noted, things are wrong because you shouldn’t be doing this in production!
      • Not all customers have proper security staff, competency, time or awareness to do that.  So they’ll do what most people do and not allow it at all.  I’m sure you’ve run into many customers that don’t even allow SE16 in PRD for “security purposes”.  This just makes it worse. 
        • Security holes need to be publicised widely – once those responsible have had the opportunity to fix them.  If you rely on secrecy for security, how will you know whether the bad guys have discovered your secret? 

          For instance, up until about 2004, kryptonite bicycle locks could be opened using a humble bic biro.  “Shh, don’t tell anyone, or the thieves might find out and nick all our bikes”.  Well, the thieves already knew.  They were the only people who were protected by keeping security holes secret. 

          If you need to change the contents of a table, and you can’t do it through SE16 and debug “legally”, then you’ll have to find an authorised route – which you will find, if the business requirement is strong enough.

          • I’ll agree with you on that Matthew though to be honest it’s not a topic of interest for me.  I’m not being flippant…  just saying that my focus is on financial issues and not security ones.

            What *is* of interest to me is how this is communicated.  Reading through these comments it seems that there is agreement that &SAP_EDIT is a security hole and potentially a dangerous one.  To publicize it and end with a “Use with caution!!!” tag isn’t responsible.  That’s like giving a 16 year old boy the keys to a Porsche and saying “don’t speed”.  What would a reasonable person expect in that situation?  Maybe no harm comes out of it..  and maybe there are a lot of flashing lights (i.e., Very Urgent OSS messages that aren’t truly warranted).

            This blog isn’t about security or trying to alert the community to a variety of holes that should be plugged.  It’s about a new exciting tip that can be used (presumably) as a shortcut…  followed by three slammers no less!  Maybe turning this into a security issue is something that someone can do and reference this blog as a starting point.  Martin English blogged about this as well (Transaction SE16N vulnerability) but doesn’t explain how to stop it.  It just reads as another demo in my opinion.  The comments by Julius and Gretchen in both blogs clarify the situation but do these comments get the same amount of visibility as the blogs themselves?  Probably not.  I don’t subscribe to security blogs so maybe this has been discussed ages ago and I just can’t find it (entirely likely).

            All that said, we all know that “stuff” happens and the only way to fix it is directly on a table.  Sometimes the changes are a single value on a single record…  very simple.  Having had to do this ~100 times in my career, I feel much safer doing it on the table then via a program.  The best way for me to explain it is (and I’m struggling to find the right words)…  it’s just a more intimate experience.  My hands are right there on the table and I’m updating it the way that the system normally would.  I’ve done it via correction programs (SAP delivers many of them in the standard system) but sometimes I’ve seen senior resources execute these with a laissez-faire attitude because “the program wil take care of it for me”.  Yet some of these correction programs have little or no logic at all and place the burden of how, when or if the program should be executed on the person running it…  in spite of any warning messages.  I think the stress, fear, risk of doing it via SE16 or SM30 makes me more attentive to the situation and what I’m doing.  That’s just me.

          • “My hands are right there on the table and I’m updating it the way that the system normally would.”

            Yeah, famous last words… 🙂

            I can confirm that some of the utility programs in the Asset Accounting area reflect exactly this same belittlement of referential integrity.

            At least SE16N makes correct authority-checks (now) so you not only can choose whom to give authorizations to start it, but you can also take a granular approach to give certain folks only certain access while using it (regardless of the transaction).

            SE16N is a fantastic transaction, it’s features are nothing new and you can restrict them consistently. The problem in my opinion are the folks who panic without understanding it, ruine it’s reputation and then settle for locking the tcode as their best solution because they don’t want to change their authorizations.


  • You should also consider that the ability to debug is the equivalent to being able to create your own program and submit it, or even change your user context to execute functions with other user’s authority in service calls or RFC connections.

    This is nothing new. This is also well documented.

    A developer wanting to debug in production is a not a good developer. They didn’t test their programs properly, nor did the person who requested the program understand what they wanted. Cowboys… 🙂

    That both of them want to change table data in production later on is a natural consequence.

    That the transaction is located in Controlling is the real joke about this! The other option is editing an Excel spreadsheet before uploading the data. Tip: take a look at object S_DATASET for the other variant…

    The rest you can contain via authorizations and good program design. Developer guidelines help as well…


  • Hi Kevin and readers

    If SAP did not documented this, is because there exist a risk on the usage of this transaction, so we really appreciate, that when share this kind of information you show the entire picture and not only the nice part of the tip.

    On behalf of SAP Active Global Support, please let me complete the part which is not mentioned (risk part) of this transaction in order to keep clear why is not documented and what are the risk of a use it:

    – To change a table on the database directly (by using this tool) is not allowed according to any ISO process and is also not SOX compliant.

    – Severe data inconsistencies caa be created by doing this, as in SAP system many relational tables contain a set of information which belongs to one accounting object.

    – Changing tables might cause several problems during period end closing and all reconciliation actions which need to be performed.

    – SAP is not responsible to correct any errors which result from those actions.

    So, you can use it, but if you cause a inconsistence that perhaps do not appear until you have to close the FI-CO Accounting year, you will be on you own.

    I hope now the readers be aware about the risk of use this and have both sides of the coin to take their own choise.

    All the best,

    Luis F. Lanz
    In behalf of SAP Global Support

    • Thanks for the disclaimer Luiz.. 🙂

      Actually, this feature is well documented in some OSS notes which explain exactly how to use it.

      What I am most curious to know is how this feature and a plethora of customer implementations of the same ilk are going to react to the extended syntax checks, which currently issue a warning only?

      Will it be possible to create a “friend” list for SE16N, via which it is clear which tables are subject to this “protected exposure”?

      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.

      Cheers and enjoy securing your systems,

    • Quite right.  And the same goes for any program that updates the standard tables directly. 

      In over 12 years of working in SAP, I’ve only ever seen a direct modification via SE16, on a production system, once.  And that was only done for a very specific issue, after a full system backup was taken, and with extensive testing afterwards… and in careful consultation with our SAP support partners!


  • Kevin,

    it’s a nice trick and i must admit i wasn’t aware of it. i had once an sap support person have me debug directly a config table, but not using this transaction and i have seen system people do it in production for some z tables. however, this is just a trick and nothing else. it may help some tired developer get over this or that data issue in their development box, but there is no room for this transaction in the production system. it needs to become a required check for any auditor, along with SM30 edits. there should be no room for any adhoc adjustments from the system point of view for any reportable data with financial implications, which i think takes care of 99% of what is entered in a production client. all in all, we can put it under the banner of ethical hacking and applaud you for sharing it with the rest of sdn community.