RSD1 — RSD1 InfoObject Maintenance

RSD1 maintains InfoObjects: characteristics, key figures, unit characteristics and time characteristics. An InfoObject is metadata shared across every InfoProvider that uses it, so a change made here is never local - it is a cross-object, cross-client structural change. The one fact that explains most confusion: an InfoObject exists in an active version (A) and can also carry a modified, not-yet-activated version (M) simultaneously. Screens elsewhere in BW may show the old active definition while RSD1 already holds an inconsistent modified one, which is why 'it looks fine in RSD1 but the query is wrong' is a common symptom - the InfoProviders and queries referencing it have not been reactivated against the new version. Master data, SID and hierarchy tables are generated from this definition, so type, length or compounding changes ripple into physical database objects, not just a metadata record.

RSD1 is reached for during data model design and rework: creating a new characteristic to hold a business dimension, adding attributes or navigation attributes to an existing one, switching an attribute to time-dependent, defining compounding for a key that is only unique within a parent, or setting currency and unit behaviour on a key figure. It is also the first stop when an activation error message names an InfoObject, or when a query is missing a navigation attribute that everyone insists exists. RSA1 is the entry point most consultants use day to day, since InfoObjects sit inside the InfoObject catalog in the modeling workbench and double-clicking one there opens RSD1 in the background; going to RSD1 directly is faster when the object name is already known, for example from an error log.

In SE16 on RSDIOBJ, filter by the InfoObject name and look at the object version field: an entry with version M and no corresponding A record, or an M and A record with different content, confirms an unactivated or partially activated change. Cross-check RSDCHA or RSDKYF for the same object name to see whether the type, length, compounding or currency settings match what the query or load error is complaining about. If the symptom is a missing navigation attribute, confirm it exists as active in RSDCHA-linked navigation attribute settings before assuming the InfoProvider simply has it switched off.

In embedded BW on S/4HANA, RSD1 works the same way as on classic BW; InfoObjects, activation behaviour and generated tables are unchanged. On BW/4HANA, InfoObjects still exist as a modeling concept, but the primary place to maintain them shifts to the Eclipse-based BW Modeling Tools rather than the SAP GUI transaction, and several classic InfoProvider types are no longer available alongside them. For pure S/4HANA analytics built on CDS views rather than classic BW, InfoObjects and RSD1 are not part of that model at all.

This is functional/BW modeler territory, not Basis, since the changes are data model decisions about grain, compounding and time-dependency. Basis gets involved only for authorization on the InfoObject catalog, transport route problems, or lock table cleanup. A good handover states the InfoObject name, the object version found in RSDIOBJ, which dependent InfoProviders or queries were checked, and whether master data needs deletion before the change can activate.

Start from RSA1, since that is where InfoObjects sit inside the modeling workbench alongside the InfoProviders and transformations that consume them, before working RSD1 in isolation. Check RSMO when an InfoObject change causes a master data or hierarchy load to fail, since the monitor shows whether the failure is a SID lookup or structure mismatch traceable back to a recent RSD1 activation. Use RSPC to see where a master data load sits in a process chain when reactivation forces a reload. Use RSRT to confirm whether a navigation attribute or compounding change is actually visible at query runtime once the InfoObject and InfoProvider are both reactivated.