!--a11y-->
Handling Data Records with Errors 
Using the Error handling function on the Update parameters tab strip in the Scheduler, you have the option of controlling the behavior of the BW system, should incorrect data records occur when you are loading data using the PSA.
The system checks for incorrect data records:
· in the transfer rules
· in the update rules
· when data is updated into the master data-, text- or hierarchy tables.
· when data is updated to the InfoCube.
·
when
checking for referential
integrity within an InfoObject
against the master data tables or ODS objects on a communication
structure level.
Incorrect records arising in transfer rules, update rules, when updating to a data target, or when checking for referential integrity, are highlighted and returned to the error handler. The error handler locates the original PSA records and writes the corresponding log. This function is as yet unavailable for updating to ODS objects.
You can control how the system responds to incorrect data records using the Error Handling function on the Update Parameter tab strip in the Scheduler.
...
1. Choose how the system should react to incorrect data records
a. No update, no reporting (default)
If errors do occur, the update of the entire data packet is canceled. The request is not released for reporting. However, the records check continues.
b. Updating valid records, no reporting (request red)
This option enables you to update valid data that is released for reporting only after the administrator has checked the incorrect, not updated records, and has manually released the request (by a QM action, meaning setting the Overall status on the tabstrip Status in the monitor).
c. Updating valid records, reporting possible
The valid records can be reported on immediately. Automatic follow-up actions are also carried out, such as adjusting the aggregates.

With option a) the incorrect records are marked in red in the PSA maintenance. You can display the relevant error messages amodally, edit the records, and update the request manually. If it was not possible to write into the PSA (hierarchy or transfer method IDoc), an application log is written instead.
With options b) and c) a new request that is only read into the PSA is formed from the incorrect records. Here you can edit the records of the new request in the PSA and start the update manually.
If errors arise when an InfoCube is updated, new requests are generated for incorrect records for each InfoCube combination. Among these requests, the incorrect records are booked in the PSA. These new requests entered the InfoCubes for which there were incorrect records as data targets. If, for example, a record was booked into two InfoCubes by mistake, a request is generated for this record that contains both InfoCubes as data targets. In the PSA tree, the requests appear as successfully booked in the PSA. In the PSA tree, the requests appear as successfully booked in the PSA.
2. Specify after how many incorrect data records the load process should be terminated. You can display the errors arising up to that point in the PSA. If you do not enter after how many incorrect records, termination should occur, handling incorrect data records is not active. In this case, the update will terminate after the first error.
3. Select how the BW system should react when the number of data records received by the BW is not the same as the number of data records updated in the BW.
There can be a difference between the number of received and booked records. This can occur
· in the transfer rules
· in the update rules
· when updating
records are sorted, aggregated, or added.
If you set the No Aggregation Permitted indicator, the request is taken as incorrect if the number of received records is not the same as the number of updated records.

Independently of this indicator, an error arises when the number of selected records is not the same as the number of records received in the BW.
The monitor directs the user to the relevant error case and enables a direct navigation into the PSA or the respective error request.
If you want to continue processing the incorrect data records in a program that you have written yourself, you can use the method GET_ERRORS of class CL_RSSM_ERROR_HANDLER. The use of this method is documented in the RS_ERRORLOG_EXAMPLE.
See also:
Checking and Changing Data Using
PSA-APIs