The information that is showing on your screen is also held somewhere. Sometimes as a result from a calculation but mostly in very accessible transparent tables, which can be viewed or selected on from an ABAP report. These articles are about how to find the tables behind the fields.
The most popular way into the table search would usually be a screen field... Simply ask the end-user to point out which field is required on the screen, and take it from there: press F1 for help and get technical details via the "Tools" button.
You must have noticed that screen fields don't always lead to their physical tables directly. But there is a relation ! The developer at SAP does generally the same as you when creating an application.
The SQL trace is about tracing database activity, which can also be useful finding the origin of your data...
A runtime analysis may be easy, but an SQL trace should never be forgotten about. Tracing SQL steps is done for any transaction, report or even different transactions or reports. It records any actions in the database, in any (all) sessions (your sessions). It can also be used to "trace" only part of a transaction, by timing when to switch it on and off again. The great thing about the SQL trace is that is can be switched on when you expect a program to select data, and switched off again immediately afterwards, leaving you with a short trace on the tables you were searching for.
Use the performance tool to track down which transparent tables are selected on. A very straight forward way to find out which tables a SAP application is using is by running a runtime analysis. Part of the results of a runtime analysis is the tables hit-list. The transparent table (or pool table) you're looking for must be in this list ! Transaction SAT (or SE30) Runtime analysis is also highlighted on the articles on Performance.
Using runtime analysis aims at a full usage cycle, where the SQL trace can be switched on and off at any time. Since the listing of tables is a side product of Runtime analysis, you may need to look it up first. Just remember it is there, it is accurate and there is no way a program can select information without making the table part of the runtime analysis results.
Setting up some development tools that allow easy interrogation of system (data) resources...
The overviews from the "Tables and such"will prove to be useful but often incomplete. A report or application that has to be build and integrate with SAP often has to use the same tables and selections as done in SAP. Copying the SAP programming sources of selections might be a logical way of approach: but hard to do because of complexity. I have chosen a different approach: via the data dictionary to try and find out how data is stored. Thereby I avoid the often complicated SAP sources. A couple of guidelines:
Some data is not held on actual fields. E.g.:
Long texts are a bit tricky to find. Because a text field has no restriction in length, it is a bit of a challenge for database fields to hold a long text. They are held on a text-pool rather than a transparent table. There is a separate article on long texts on AbapcadabrA. Check (transparent) table STXH for text headers.
In many cases the system holds possible values for a certain field, which can be set on the domain of the field. Linked to a check table or linked to Domain values Have a look at domain EBSTYP as an example, this is the domain behind EKKO-BSTYP, a single character field which holds the type of purchasing document. SAP only supports a predefined set of values for this field, making the way to store short descriptions with the possible field values very suitable for domain values. Go to transaction SE11 and fill in EBSTYP for the field Domain. On the tab Value range the possible values are listed, or (potentially) a check table is displayed.