RSMONICDP table — InfoCube Data Package Load Monitor Table
RSMONICDP holds one row per data package processed during a classic load into a BW InfoCube, recording the package number, the request it belongs to, and package-level status and record counts as shown historically in the load monitor. It belongs to the older InfoPackage-based monitor architecture and is largely legacy on current BW and BW/4HANA systems built around DTPs and process chains.
This page covers RSMONICDP, the data-package-level monitoring table behind the classic BW load monitor for InfoCube loads. It focuses on what a row actually represents, how to trace a reconciliation problem back through it, and why it frequently misleads consultants who expect it to reflect current DTP-based load status.
Published 15 Sept 2026· 970 words
What it stores
One row in RSMONICDP represents the monitoring record for a single data package within a request that loaded data into an InfoCube, under the classic BW monitor architecture (the one surfaced historically through the load monitor transaction). A load request is split into data packages during extraction and update; each package gets its own status and record-count entry so the monitor can show progress and errors at package granularity rather than only at request level. It is a diagnostic and audit table, not a data storage table for the cube itself, and its content only has meaning in the context of the request and target object it belongs to. Rows accumulate as loads run and are subject to periodic monitor cleanup, so absence of a row does not necessarily mean the load never happened.
Key fields
- MANDT - client, must always be part of any restriction on this table
- REQUNR - technical request identifier the data package belongs to, links back to the load request
- DATAPAKID - sequential number of the data package within that request, used to isolate a single package's status and counts
How it joins the data model
- RSMONICDP-REQUNR = RSREQDONE-RNR (or equivalent request key) to get the overall completion status and timestamps of the request the package belongs to
- RSMONICDP-REQUNR joins to process chain log entries in RSPCPROCESSLOG when the load was triggered from a chain step, to correlate package-level failures with the chain variant that failed
- the InfoCube itself (RSDCUBE) is reached only indirectly, through the target object name carried on the request, not through a direct field-to-field join on RSMONICDP
How to read it safely
Always restrict on client first. This table can grow large on systems with a long history of frequent InfoCube loads, so never select from it without at least a request ID or a date range narrowing the request first, typically obtained from the request table rather than guessed. Selectivity on REQUNR plus DATAPAKID gives an exact single-package lookup; selecting only on client and a wide time window is expensive and usually unnecessary once the request in question is known from the monitor screen or from a support message. Treat any figures found here as a snapshot at load time, not as a live reconciliation source.
How to prove it in the data
Symptom: a load into an InfoCube shows as completed successfully but the record count in reporting does not match the source extraction count. Take the request ID from the load monitor or from the request table, then select RSMONICDP for that client and REQUNR across all DATAPAKID values, and compare the record counts recorded per package against the extraction counts on the source side. A gap concentrated in one or two packages, rather than spread evenly, points to a package that errored and was skipped or repeated rather than a global extraction problem.
ECC vs S/4HANA
RSMONICDP belongs to the classic BW extraction and load monitor, built around InfoPackages loading directly into InfoCubes. On BW/4HANA and on current embedded BW scenarios in S/4HANA, loads are built around DTPs, transformations and process chains, and the classic monitor path this table supports is largely legacy; it is not exposed through a CDS compatibility view and has no official successor. Where it still physically exists it should be treated as historical data at best, not as a live monitoring source for current loads.
Common pitfalls
- Assuming a missing or empty result for a known request means the load never ran, when in fact monitor data has simply been deleted by a housekeeping job that purges old monitor entries independently of the request itself
- Treating RSMONICDP as the source of truth for current load status on a system running mainly DTP-based process chains, when it belongs to the classic InfoPackage monitor and may not be populated at all for DTP loads on newer architectures
- Reading package-level record counts as final delivered counts without checking whether the request was later deleted and reloaded, since old package rows for a superseded request can remain and confuse a count comparison
- Using this table alone to diagnose why a load failed, when it records status and counts, not error messages; the actual failure reason sits in the request's message log, not here
- Assuming behaviour and content are identical across BW releases; the monitor architecture was reworked more than once, and code or reports written against RSMONICDP for one generation of BW can silently return nothing on a later one without raising any error
Whose problem this is
Any question about what this table shows for a specific load belongs to whoever runs BW data load operations and process chain monitoring, not to the functional reporting team. If the question is about a discrepancy between loaded and expected volumes, it starts with the person who owns the process chain or InfoPackage for that data flow, escalating to BW basis if monitor data itself looks inconsistent or has been purged.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/rsmonicdpERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.