RSREQDONE table — RSREQDONE - BW Request Status Management Table

One row in RSREQDONE reflects the completion status of a processing step for one request loaded into one InfoProvider, within the BW status management framework that governs how a request moves through its lifecycle: extraction and load, DSO activation, cube rollup, aggregate fill, compression, and similar downstream steps. The table exists so that status management and process chains can check, without re-running any logic, whether a given step has already been marked done for a given request/target pair, and therefore whether the next step in the chain (or a reporting query) can safely proceed. It is a control table, not a data table: it says nothing about whether the records loaded are correct, only that a named step against that request has been flagged complete.

Only the fields below can be stated with confidence. RSREQDONE carries a set of additional per-step completion indicators beyond these, but their exact field names are not reproduced here because they are not certain enough to state as fact; check the table structure directly in the system rather than assume a spelling.

The two joins that actually get written in an investigation are from RNR back to the request monitor, and from TARGET to the InfoProvider definition tables. Everything else in a status-management investigation is reached through those two anchors.

Always restrict by TARGET first; this table accumulates one entry per request per InfoProvider per step across the full retention history of the system, and unrestricted selects on older BW systems with long-running loads can return millions of rows. RSREQDONE itself does not reliably carry a usable timestamp for filtering by date, so get the request creation time from the monitor table via RNR and use that to bound the window before pulling status rows. Client restriction is implicit in any transaction-based access but matters if querying the table directly through a generic tool.

Symptom: an ADSO load shows successful in the job log but activation never seems to finish and downstream aggregates look stale. Find the RNR for the load from the request monitor, then select RSREQDONE for that RNR and TARGET equal to the ADSO's technical name. If the activation-related indicator for that request is not set despite the load step showing green, status management is out of sync with the actual job outcome, and that mismatch, not the extractor or the data itself, is the object to escalate.

RSREQDONE is a native BW table and remains part of the classic status management framework in BW/4HANA and in the BW component embedded in S/4HANA analytics scenarios; there is no known CDS compatibility view replacing it. Its role has diminished in relative importance where S/4HANA reporting moves toward CDS-based virtual data models that bypass classic request-based BW loading altogether, but wherever a classic InfoProvider and process chain still exist, this table still governs the same lifecycle logic it always did.

This table is read far more often than it is understood, and most of the mistakes come from treating a status flag as proof of data quality.

This is a data warehouse or BW basis question, not a functional module question. The owner is whoever administers the process chains and DTPs feeding the affected InfoProvider. A functional consultant who sees stale figures in a report should escalate to that team with the RNR and target already identified rather than propose a fix against this table directly.

RSMONICDP is the request monitor table that supplies the timestamps and job outcome missing from RSREQDONE. RSPCPROCESSLOG carries the process chain run history that triggered the load and downstream steps. RSDCUBE and RSDODSO define the InfoProviders referenced by TARGET. The relevant transactions are the request monitor and the process chain monitor in the BW workbench, both of which write and read this status information behind the scenes.