Evaluating Logs (SAP Library - Profitability Analysis (COPA))

Evaluating Logs

Use

After a data transfer has taken place or been terminated, you can use this function to find and rectify errors.

Features

The system creates a list of all transfer runs in which you can sees the statuses of the transfers. The status indicates whether a transfer was completed, or if there were errors. The following statuses are possible:

Status	Meaning
Conversion error	The transfer was terminated in the conversion stage. No records were written to the database.
Canceled	The conversion was successfully completed, but errors occurred in the subsequent processing. The transfer was therefore not completed. It is possible that no records were written to the database. You can find further information concerning confirmed data records in the detail log.
Error	The transfer was completed, but there were business content errors. All of the data records except the ones containing errors were written to the database.
Warning	The transfer was completed, but warnings were output to the log. All of the records were written to the database.
OK	The transfer was completed without errors or warnings. All of the records were written to the database.

Two logs are written for each transfer which represent the two logical parts of the transfer:

Conversion Stage:

The conversion log is created for every data transfer. The technical aspects of the transfer run are described step-by-step. Errors which prevented the program from running to completion are logged. In the conversion log, you can display all of the sender and receiver records, or just the ones containing errors.

Function Stage:

The detail log is only created if the conversion is completed successfully. It contains information about the checks and the saving of the data for each record which contains errors. If, during a transfer involving header and item structures, only one item from many is incorrect, the whole block will be listed. This includes the header and all items.

You must always use this log in evaluating whether the transfer occurred successfully, as the messages on the screen and those in the spool directly after the transfer run do not always match those in the log.

When evaluating log entries, note that the messages in an EDT log can change over the course of several releases. Both the content and the name of a message can change. If messages are used in programs you developed, you should check them after changing releases.

Error Correction

Sometimes the scope of the imported data does not match the system’s requirements. In this case, you may have to make certain "conceptual adjustments" before you actually correct any errors. You may have to either:

modify the system’s data requirements in Customizing (that is, modify the data requirements to more closely match the data in the operative system).
modify the imported data by changing or enhancing your data selection programs (that is, modify the data to be imported to more closely match target system’s requirements).

Postprocessing

For transfers which end with status errors, it is possible for you to directly correct the data in each record with contains errors. Afterwards, you can transfer the corrected data records to the R/3 datapool.

Output File

You can use the file to make corrections enmasse using a small self-authored program. This would be the best option, for example, if a particular field contains an incorrect value in all of the data records. After running such a program, you can restart the data transfer using the output file with the corrected records as the new input file. The name extensions added by R/3 are listed in the detail log. The extensions are such things as the external number, the client, the date, and an indicator whether the data records were saved in sender or receiver format.

Restart

Under certain circumstances, the transfer can terminate in the conversion or function stage. This could occur, for example, if there were an overflow of table spaces in the database, a runtime error, or a power outage.

If this happens, and no data records actually reached the database (which means that there would be nothing listed in the detail log about confirmed data records), then you can simply repeat the transfer after correcting the error(s).
If all of the data records have already been transferred, then the database condition is "consistent".
What can cause problems, however, is when the transfer terminates during the function stage. If this happens, there is no way of immediately knowing how many records actually made it to the database. The program will thus note how many data records are confirmed (successfully committed to the database).

A restart makes it possible to repeat the transfer in such a way that the function stage will only be carried out for those data records which were not confirmed the first (previous) time(s). Subsequently, the database will be contain consistent records. Afterwards, if necessary, you can edit the data records which contain errors again, just as with every other data transfer.