Title
Consistency Report for DI Backflush

Purpose
The report reads backflushes from the DI System and the APO System anddisplays the inconsistencies between the two systems with regard to thebackflushes selected.

Integration
This report is only useful if you are using the DI Backflush functionswith the APO.

Prerequisites
The only prerequisite is the existence of backflushes from the scenario"DI Backflush with APO".

Features

Selection
Alongside the creation date and the backflushing system (APO), there isthe "Check Only with HeadIDs from R/3" indicator on the selectionscreen.

• If the "Check Only with HeadIDs from R/3" indicator is inactive
(default), the system reads all backflushes in the APO and in the DISystem that lie within the creation period entered using the creationdate.

• If the "Check Only with HeadIDs from R/3" is active, the system first
reads the backflushes in the DI System matching the selection criteriaand then reads the backflush data belonging to these backflushes in theAPO. When the system selects like this, it does not take into accountbackflushes that exist only in the APO and not in the DI System.

Output
The report writes any inconsistent backflushes in a list. You can thenuse the reporting tools for DI Backflush to check each individualbackflush.
An inconsistent backflush is put into one of four categories:


• The indicator that shows the progress of the synchronous processing has
a different value in the APO System to the value in the DI System.
This situation is not necessarily an inconsistency. It can occur if theinformation message, that informs the APO that this indicator has set inthe DI System, is still in the CIF (core interface) and the APOtherefore does not know that this indicator has been set. In case ofdoubt, check the CIF queues.

• The indicator that shows the progress of asynchronous processes has a
different value in the APO to the value in the DI System.
This situation is not necessarily an inconsistency. It can occur if theinformation message, that informs the APO that the indicator has beenset in the DI System, is still in the CIF (core interface) and the APOtherefore does not know that the indicator has been set. In cases ofdoubt, check the CIF queues.

• The backflush exists in the DI System but not in the APO.

This situation is not necessarily an inconsistency. It can also occur ifthe backflush has been deleted in the APO already but has not beenarchived in the DI System yet. Either the backflush data has not beenarchived yet or the archiving program has not identified the backflushas being ready for archiving yet. Look in the documentation for thearchiving program to see which prerequisites must be met before abackflush can be archived.

• The backflush exists in the APO but not in the DI System.

This situation is not necessarily an inconsistency. It should not occur,however, if the "Check Only with HeadIDs from R/3" indicator is active.It can occur if a backflush has already been saved in the APO but theinformation message to the DI System is still in the CIF (coreinterface). The DI System, therefore, does not know this. In cases ofdoubt, check the CIF queues. This situation can also occur if abackflush has been archived in the DI System already but the deletionreport has not deleted it in the APO System yet.

Activities
The system cannot determine without any doubt whether a situation isinconsistent or not because backflushes that are in the CIF are nottaken into account. In addition, after a certain status for a backflush,it is possible to delete or archive the backflushes in the APO or DISystem independently from each other.
If there appears to be an "inconsistency" becauseconfirmations/transfers are currently in the CIF, then this temporaryinconsistency will probably not be listed when you next start thereport.
If the report displays inconsistent backflushes, then you check eachbackflush individually. To do this, you use the evaluation tools forbackflushing in the APO and in the DI System as well as the RFC monitor.