Example: Set Up Logging of Input Fields 
The procedure shows how you must proceed if you want to set up logging for a field and do not yet know whether it is linked to the change document creation facility.
Procedure
Test change document creation facility
Change the data for the desired field.
Use the application-specific evaluation transaction or the transaction S_AUT10 to check whether a change document was generated.
CautionIn many transactons, change documents are generated only for Changing and Deletion, but not for the Creation of an object.
End of the caution.
If the system has not generated a change document, proceed with point 2 (check Customizing). If a change document has been generated but the latter does not contain the desired field, proceed with point 3 (make logging setting for data element).
Check Customizing
For some applications, the change document creation facility has to be activated in Customizing. Examples are work center, functional location, and equipment. For process and production orders, change document creation can be implemented in a user exit (see SAP Note 390635).
Check whether change document creation can be activated in Customizing for the application.
If possible, activate change document creation and proceed with point 1.
Make logging setting for data element
Determine the data element of the dynpro field via the
Input Help 
Technical Information 
.If one of the tables of the change document obnject that you determined in point 1 contains this data element, activate logging for this data element in transaction S_AUT01.
You can use transaction S_AUT01 or S_AUT03 to determine which tables a change document object contains.
If changes are not logged even though you have set the logging indicator for the data element in transaction S_AUT01, the contents of the dynpro field are obviously not passed on to the change document creation facility. You can check this through debugging.
You cannot use the change documents if the field contents are not passed on to change document creation. Check whether you can use table logging at this point. Continue with point 4 (test table logging).
If no table of the change document object contains the data element, you cannot use this change document object. In this case, check whether you can use table logging at this point. Continue with point 4.
Test table logging
Make a change to the desired field.
Use transaction S_AUT10 to check whether the system has generated a table log for the change.
NoteFor the system to generate table logs, the system profile parameter rec/client must be active in each client in which you want to use table logging.
End of the note.
Activate table logging
To activate table logging, you must determine the database table in which the input of a dynpro field is stored. To do so, proceed as follows:
Determine the data element of the dynpro field via F1 -> Technical Information.
This shows you whether this data element is included in a Transparent Table, a Structure, or a Generated View .
If the name of the Transparent Table is displayed, you must activate the logging settings for the table in transaction S_AUT01 and then test the table logging facility (see point 4).
If the name of the Generated View is displayed, in this case the data changes are not wirtten direct to the database table but stored via a view. You then proceed as follows:
Switch to the Data Dictionary. There determine the table that contains the desired data element from the tables of the view.
Activate table logging for this table in transaction S_AUT01.
Test the table logging (see point 4).
If the name of the Structure is displayed, the dynpro structure and the database table do not have the same name.
The name of the structure may enable you to deduce the name of the database table. If not, you must proceed with the next point.
CautionTable logging should not be activated for transactional data because this generates a high data load and impairs performance.
End of the caution.
Analyze lock entries
If a transaction is started by a user in change mode, the system sets table locks to protect the data from being changed by several users simultaneously. The lock entries of the user effecting changes displayed in transaction SM12 can give you an initial indication of the tables in which the relevant transaction saves data.
NoteHowever, under no circumstances do the lock entries represent a conclusive listing of the tables that were changed by a transaction.
End of the note.Perform runtime analysis
To perform runtime analysis, you need basic knowledge of ABAP. You proceed as follows:
Carry out an SQL trace (transaction ST05) of the save operation.
The system displays a trace list (ALV grid).
NoteChanges are frequently saved asynchronously via update modules. The SQL trace must therefore run for such time as it takes for all the update modules of this operation to finish.
End of the note.Search the list for SQL statements that make changes to the database, such as INSERT, UPDATE, DELETE.
Check the Data Dictionary using the table name to see whether the changed values may tend to be stored in this table.
For all SQL statements in question, double-click in the Statement column to check whether the SQL statement contains the changed field and whether this field contains the changed value.
NoteConvert routines that convert the value entered may be stored in the Data Dictionary.
End of the note.As an alternative to runtime analysis, you can also carry out a debugging.
CautionChanges are frequently saved asynchronously via update programs. To be able to debug the update modules, you must activate Update Debugging in the Debugger.
End of the caution.User transaction S_AUT01 to activate the logging settings for the table determined and then test the table logging (see point 4).