Explore SAP tables with SE16, SE16N
SAP stores all information in database tables. If you want to create queries, you need to get familiar with the most common tables. SAP Data Browser is a tool for exploring the table contents. The original Data Browser transactions is SE16. SE16N (general table display) is an improved version of the SE16. HANA brings SE16H with new features. I use the original SE16, but perhaps you should try the new ones.
In order to use the Data Browser you need to know the name of the table. How can you find that? Just place the cursor on the field (e.g. Invoice Number) and press F1.
Click on the “Technical Information” icon in the Performance Assistant Screen. Next screen shows both the table and field names. In this case VBRK-VBELN.
SAP Data Browser (SE16, SE16N)
Only one table at a time can be queried with Data Browser.
Select the table and enter the selections. In the user parameters you can define, whether you want to see the technical field name or field label.
When you use SE16 for the first time, start with the Settings. In User Parameters you decide whether you want to display the technical field names or field labels. In the example below I have chosen the labels. Also the selection screens of SE16 are pretty empty. Unser Settings/ Selection fields you can define wich field you want to show up in the selection sceen.
In the Format list you define, which fields are included in the output. This is useful, when you want extract data only from certain columns.
SE16N thas no User Parameters. Both the technical name and the label are displayed side by side. All selection options are visible. The fields you want to output can checked ,
Header and item tables
Often the data is stored in higher level (header) and lower level (item) tables. For example the billing header table (VBRK) contains information on customer level. Product information is item level data stored in table VBRP. Customer number is not stored in this table. If you need a list of invoiced products by customer, you need a table join. This is where QuickViewer comes into picture. This easy tool enables table joins. QuickViewer is also an excellent tool for sketching SAP queries.
Search with key field
Both SE16 and SE16N allow downloading data to Excel or file. This feature can be sometimes utilized, when you want to see only a few records from the other table and dont want to create a QuickView of Query for that.
For example, you might want to know which materials a customer has bought. First you make a search in table VBRK By customer and invoice date. In Format list select only Billing Document numbers. Transfer the result to Excel and save as a text file. Next make a search in the row table VBRP using the Billing Document numbers from the text file. There is an example of this in the attached presentation.
I often use the text files to sort out the archiving error logs. I copy paste the document numbers to a text file and upload them to SE16 search for a closer examination.
Tables SAP ERP – S/4 HANA
Many of the SAP ERP tables exist only for technical reasons to keep summarized or grouped data. For example the accounting documents are stored in tables BKPF (header) and BSEG (items). The items (G/L accounts, Accounts Payable and Receivable) are duplicated in index tables. Examples of these are BSIS/BSAS, BSID/BSAD, BSIK/BSAK, which contain the open and cleared items of G/L accounts, vendors and customers.
The amount the tables is reduced considerably in S/4 HANA. The picture below shows common SAP ERP tables and their counterparts in S/4 HANA.
Bad news is that IT has most likely blocked the use of these tools at least in the production system. There are couple of reasons for that.
SAP tables can be enormous, and the queries can be huge performance eaters. If this is the case, ask for authorization in sandbox or test system. Practice these tools there until you understand, what you can do with them. Only people who create the InfoSets and write the queries should have access to SE16 / SE16N; people who run the queries should not.
The main reason is security. SE16 and SE16N are classified as dangerous tools, because you can bypass other constraints and access data directly in table level. Also tables with sensible data.
Probably the GDPR will reduce even more the rights to use these transactions. Instead of totally banning these transaction maybe they could be added only to special user roles. Like Query Designer or Super User for archiving.