QS23 — Display Selected Set in QM Catalogs

QS23 shows the contents of a Selected Set: the catalog type it belongs to, the code group or groups it draws from, and the specific codes included, each with its short text and status. A Selected Set is not itself a source of codes; it is a filter layer sitting between the raw code group and whatever master data object consumes it, so that a characteristic used at ten work centers can be given ten different narrow views of the same underlying catalog without duplicating codes. The structural fact that causes most confusion is exactly this: a Selected Set does not own the codes it displays, it references them, so a code deleted or blocked in the source code group disappears from every Selected Set built on it, silently, with no warning at the set level.

QS23 gets used during audit or troubleshooting of inspection master data, when a consultant needs to confirm exactly which codes a characteristic or usage decision profile is actually offering, without risking an accidental change. It sits downstream of code group and code maintenance and upstream of master inspection characteristics, inspection plan characteristics, and notification catalog profiles. Reached for instead of QS22 when the task is verification rather than maintenance, and instead of the results recording transaction when the question is why a code is missing from a dropdown rather than why a result failed. Also used when handing off a master data investigation to someone else, to capture the exact set contents at a point in time before a change is made in QS22.

Pull the Selected Set header record by set ID and catalog type and note the validity dates and catalog type stored there. Then pull the codes table filtered by catalog type and code group for the group(s) the set references, and compare the code list against what QS23 actually displays. A code present in the codes table but absent from the QS23 display confirms it was never assigned to this set or was removed from the assignment layer; a code present in both but greyed out or unselectable confirms it is blocked at the code level, not at the set level.

Catalog and Selected Set maintenance behaves the same on S/4HANA as on ECC; QS21, QS22, and QS23 remain the transactions of record and no Fiori app has replaced catalog code or Selected Set maintenance. Consultants working from Fiori-first S/4HANA rollouts still drop into these classic GUI transactions for catalog work, since the surrounding inspection and notification apps read the catalog data these transactions maintain rather than exposing catalog administration themselves.

Functional QM master data ownership. A clean handover states the catalog type, the Selected Set ID, the specific code(s) in question, and whether the discrepancy was traced to the code group, the code status, or the set's own validity period. ABAP involvement is rare and limited to custom validations firing off catalog data; Basis has no role unless the transaction itself is inaccessible.

QS21 is the create counterpart and the place to look when a Selected Set needs to exist that does not yet. QS41 maintains the underlying code groups and codes that every Selected Set draws from, and is the first stop when a code appears missing. QP01 and QP02 show how inspection plan characteristics reference a Selected Set in practice, and QM01 shows the notification-side consumer through catalog profiles. QA11 or QE51n are useful for confirming, from the results recording side, exactly which codes a given characteristic is actually offering at runtime.