I'm trying to find the data underlying a transaction. I put the cursor in the field I want, and press F1. Then I click on the button for technical data. This gives me a table and field name. But when I look at the table, it turns out to be a structure.
How can I find where the data is really coming from?
Frequently data is presented in a transaction's screen through a structure. The structure may be populated from a number of sources - and may even contain some calculated fields. In order to find out where the data comes from initially, there are a few techniques which can be used - in no particular order of preference.
The structure may be built up of a number of includes. If the include is in fact a table, then the chances are your data comes from that table.
See if there is a logical database in the business area you are looking at. Looking at the structure of the logical database often reveals the tables used to drive that business area. See if the field name you are looking for is in any of the tables. Logical databases can also be useful in determining how tables are linked together.
Debugging. Start the transaction in debug mode. Set a watchpoint for the structure-field you are interested in. When the debugger breaks, look at the lines just above the breakpoint. This will show where the field was populated. This may be a structure, in which case restart the process using that structure for a watchpoint.
Pretty soon you will get to the table containing the data. Switch SQL trace on, and run your transaction. Switch the trace off, and examine the log. This will detail the tables hit, and the order in which they were hit.. Not all tables hit will be displayed - for example, configuration tables tend not to show up, as they are buffered.
The runtime analyser, SE30, will show all tables accessed by the transaction. There are three courses I've found whose course notes contain diagrams of the tables used for particular sets of data. LO910 (Configuration and Organization in Logistics), LO250 (Configuration of the PP module)and LO630 (Sales Information Systems).
Often, SAP have not been too imaginative in their table naming conventions. For example, most of the information in structure CAUFVD can be found in the view CAUFV. Further, tables ending in KO tend to be header tables, with the underlying data being in a table with the same stem, but ending in PO. E.g. EKKO and EKPO., AFKO and AFPO.
A combination of these techniques should enable you to discover the underlying data.
Dig Deeper on SAP ABAP
Related Q&A from Matthew Billingham
An SAP user is trying to run a report in an SAP ALV Grid online and wants to know how to get the data in the report to appear along with the header. Continue Reading
An SAP user needs to transfer customer purchase order spreadsheet data to SAP VA01 to create a new sales order. Continue Reading
An SAP user needs information on how to change the password on several SAP user accounts from a central location. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.