|
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.
|
