Skip to Content
Technical Articles

ABAP Tricks for Functionals | Trick #1 – Edit Table Values in S/4 HANA using SE16 Debug Edit

Introduction –

We come across situations where we need to edit values in standard/custom tables. There could be many reasons why you want to edit values in standard/custom tables, some reasons are listed below.

  1. You are performing testing, and want to simulate a test scenario without changing a lot of test data
  2. You do not have a table maintenance transaction available to edit table value
  3. You have found a data inconsistency and want to change table value to fix it

This blog post explains how to step by step edit a non primary field value in SAP standard or custom table.

Note this process should be used with extreme caution in your productive and non-productive environments. Changing table values directly can cause unwanted consequences. You should only use this approach, when you are fully aware of what you change, will not cause any harm to the standard SAP system.

 

Prerequisites-

  • For debug edit to work you need to have access to transaction SE16
  • You need to have access to debug edit – Authorization Object – S_DEVELOP with object type DEBUG and activity 02

Solution –

Step 1- Identify the table and field you want to edit (For this example, I will edit the material text in table MAKT) and open the table using transaction SE16

Step 2 – Select the row you want to edit, and double click on it

Step 3 – Enter /h in the SAP command field, and turn on the debugger, if everything is fine, you will see a message saying “Debugging switched on”

Step 4 – Press F7 till you reach program include LSETBF01 and routine – set_status_val, click on line 34 variable code, and change it from SHOW to EDIT

Step 5 – Edit the data and save it (Note you can only edit non primary fields using this approach)

Step 6 – The data edit is complete, now you can view the edited data, to confirm it actually was saved in the system

Conclusion –

  • This process will work for both ECC and SAP S/4 HANA systems
  • The process will work for editing values in standard and custom tables in the system
  • The process should be used with extreme caution, changing standard tables directly in productive system is not advised
  • In a future blog post, I will share how to use other functions, and edit primary key fields (Note this is my first blog post 🙂

Please feel free to share your feedback and questions. Based on your feedback, I will write the upcoming blog posts in this series. Thank you for reading.

 

8 Comments
You must be Logged on to comment or reply to a post.
  • Hi Ameya,

    Appreciate your effort !

     

    This approach has been getting used since SAP 4.6 release.

    Use SE16N instead of SE16 for data browser.

    You can use &SAP_EDIT command  for debuuging in SE16N, start the debugger and set global variable GD-SAPEDIT & GD-EDIT as 'X' and execute. It will allow to edit Table in full mode ( Insert, Update, Delete etc together ) in same screen. While in SE16, you can use only one action ( INSR/DELE/EDIT/SHOW etc) at a time.

    However this is not recommended for production system and should be used in non-Productive system with restrcited access.

     

     

    Regards
    Samir

  • I suggest anyone to refrain editing some tables in HANA systems for all cost. Type of some standard tables are different than ECC and this may lead you to guillotine by project management if you mess up 🙂

  • Very big headache....

    Everyone does understand all the different tables that are linked and what will happen when you destroy the link.   Or two different information... or...  Using this on a Z table is not as bad.  But any SAP table?

    Yes, this is not the first time this has been out here - probably won't be the last.

  • I hope that security teams at SAP clients have enough sensibility not to give such access to non-developers. Needless to say, it should not be given to anyone outside of DEV environment. This must never be used in PRD, no matter how great caution is exercised. And standard SAP tables should never be manipulated either.

    Changing values in debugger is a powerful tool for the developers but, in my opinion, it should never be abused like this, not even in DEV system. If “funkies” have no way but to resort to this tactic, that’s an indication that something is wrong.

    Let’s look at the suggested use cases.

    1. You are performing testing, and want to simulate a test scenario without changing a lot of test data.

      This should be discussed with the developer. If this is a test of a small part in a long scenario, there could be a simpler yet legitimate way to create test data. E.g. I’m always able to advise on whether an existing document could be copied or if it’s sufficient to re-trigger output instead of creating a new document. Also, there could be other dependencies that you might not be aware of, hence you’d be doing more harm than good for this test. And when “volume testing” is required, some tools should definitely be made available.

    2. You do not have a table maintenance transaction available to edit table value

      There is a reason maintenance is not available for the table: because it’s not meant to be manipulated manually. Otherwise you don’t need to resort to sneaky tactics and could simply edit data (in Z tables) in SE16N.

    3. You have found a data inconsistency and want to change table value to fix it

    Manipulating data through debugger is exactly what can cause data inconsistency. There are no validations when data is manipulated in debugger. For example, you might think that entering 10 as item number is sufficient. But it’s supposed to be ‘000010’. Or it’s not even the value you assume: a good example would be partner functions (SH on screen but WE in database). There are many things like that in SAP.

    In a DEV system, it’s not unusual to see bad data in Z table(s) as a result of experiments or development in progress. If such inconsistent data is interfering with testing, then a developer should clean it up. It takes only a few minutes to create a program for that. And I’ve written programs before just to load some testing data. It’s not a big deal.

    So instead of using such “tricks” I’d suggest to discuss the testing needs with your team and management. Most likely there are better solutions.