Delta Extraction Missing Records After an Init

Someone in finance or logistics reports that a handful of documents are simply not in the report, even though they can pull the document up in the source system without any problem. It is never all the data, which is what makes it confusing - reconciliation for most of the period matches perfectly, and the gap is often tied to a specific day, usually the day the extraction was reinitialized or a cutover happened. The business frames it as 'the report is missing some invoices from last Tuesday' rather than 'the delta is broken', because everything else loads fine on schedule afterward. Sometimes it only surfaces weeks later during month-end reconciliation, when someone finally sums document counts by creation date and finds a hole that lines up exactly with a known init or system copy date.

Pull document counts by creation date from the source table for the suspect day and compare against the equivalent count in the BW InfoProvider for the same date, filtered by the same key figures used for reconciliation. Identify the specific document numbers present in source but absent in BW, then check their creation timestamp against the recorded init cutover time in RSMO - a cluster of missing documents falling exactly on or just before that timestamp confirms a timing-gap cause rather than a random load failure.

If the cause is a timing gap or narrow setup scope, this is a data fix: run a repair full load scoped to the affected date range or key range into a correction request, then reconcile against the source. No transport needed, but the cutover window and selection used must be documented so the repair is not repeated or missed. If the cause is unprocessed queue entries deleted during reinit, there is no clean recovery path other than the same scoped repair full load - the queue content itself cannot be resurrected. If the cause is a safety interval set to zero, that is a configuration change in the source system DataSource settings and needs to move through transport before the next reinit; pair it with a repair load covering the exposure window under the old setting. If the cause is orphan unconfirmed init requests for another target, resolve or delete those entries in RSA7 first - this is a data/administrative action, not a transport. If the cause is an asynchronous delta pointer field, the DataSource delta configuration needs to change to a field set at commit time or the safety interval needs to be widened to absorb the async delay; this is a config change requiring transport and a fresh init afterward.

The reflex is to delete the delta queue and run another full init, expecting it to pick up everything the first one missed. It resets the delta pointer going forward but does nothing to recover records that already fell into the gap - those are gone from both the old and new delta stream unless explicitly repaired. Worse, if the root cause is a safety interval or setup-table scope problem, the second init reproduces the exact same gap under a new timestamp, and the team ends up chasing the same missing-records complaint again a few weeks later, now with two unexplained holes instead of one.

This sits jointly between Basis, who manages the delta queue and qRFC processing on the source side, and the BW consultant who defines the init selection and safety interval. The handover note should record the exact init cutover timestamp, the setup table selection criteria used, the safety interval values in effect, and the date range applied for any repair full load done to close the gap.