!--a11y-->
Handling Data Records with Errors 
Using the Error Handling function on the Update tab page, when data is transferred from the source object, you can determine how the system behaves if errors occur in the data records.
The system checks for incorrect data records:
· In the transformation rules
· When data is updated into the master data-, text- or hierarchy tables
· When data is updated to the InfoProvider
· When checking for referential integrity of an InfoObject against master data tables or DataStore objects
For a data transfer process (DTP), you can specify how the system reacts to incorrect data records. If you activate error handling, the records with errors are written to a request-based database table, the error stack. You can use a special data transfer process, the error DTP, to post the records to the target. You can create an error DTP for an activated data transfer process on the Update tab page, and run it directly in the background or include it in a process chain so that you can schedule it regularly in the context of your process chain. The error DTP uses the full update mode to extract the data from the error stack (in this case, the source of the DTP) and transfer it to the target that you have already defined in the data transfer process.
The temporary storage at the processing step level of the DTP request allows you to determine the step in which the error occurred.
...
1. Define on the Update tab page how the system reacts to data records with errors:
a. No update, no reporting (default)
If errors do occur, the update of the entire data package is canceled. The request is not released for reporting. However, the system continues to check the records.
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.
d. Specify the maximum number of incorrect data records allowed before the transfer process is terminated. If you do not make an entry here, the treatment of the incorrect data records is not activated, and the update is terminated with the first error.
e. Select how the system should react when the number of data records received is not the same as the number of data records updated.
A difference between the number of records received and the number of updated records can occur if the records are sorted, aggregated, or added in the transformation rules or during the update.
If you set the No Aggregation 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.
2. On the Update tab page, define the key fields for the error stack. The key should be as detailed as possible (maximum of 16 key fields). The fewer the number of key fields defined, the more records are updated to the error stack. In the standard setting the key for the DataStore object is defined as the key for the error stack.
3. Make the settings for the temporary storage by choosing Goto ® Settings for DTP Temporary Storage. Here you can define the DTP request processing steps required for temporary storage (for example, extraction, filtering, removing new records with the same key, and transformation), as well as the level of detail the data is temporarily stored with, and when the temporary storage is to be deleted again.
4. Once the data transfer process has been activated, create an error DTP on the Update tab page, which you then include in a process chain or (in the case of an error) start manually to post the data with errors to the target.