QS41 — Create Selected Set (QM Catalog)

QS41 creates a Selected Set, one of four layers in the QM catalog hierarchy (catalog type, code group, code, selected set). A selected set is a named, restricted list drawn from one or more code groups within a given catalog type; it exists so that a specific screen field (defect type on a notification, valuation code on a usage decision, a characteristic's valid values) can offer a short, purpose-built dropdown instead of every code ever defined for that catalog type. The structural fact that causes most confusion: QS41 does not originate codes. Codes and code groups are maintained separately (via QS21 and related transactions); QS41 only assembles references to codes that already exist. If a code is missing from a selected set, the fix is almost never in QS41 itself, it is in the code group the set draws from, or in the status of the code.

QS41 is a configuration-time transaction, used once catalog types and code groups are already in place, before those codes are exposed to end users. A consultant reaches for it when setting up or extending the notification catalog profile, the usage decision code groups for inspection lot completion, or the valid-values list for an inspection characteristic. It sits upstream of QA32 (lot completion), QM01/QM02 (notification creation), and QE51N (results recording) — those transactions are where the selected set actually gets consumed via an F4 help. There is no Fiori app for this; it remains backend catalog configuration, done once per business scenario rather than repeatedly. It is not something an end user or a shift-level operator would ever open.

Start in SE16 on the selected-set line table, filtered by catalog type and selected set number, to list every group/code pair actually assigned to the set. Cross-check each code against the code master table filtered on the same catalog type and group, comparing status flags — a code can be present in the selected set but still suppressed at runtime if its own status is blocked. Separately, check the configuration point where the set is assigned (catalog profile entry, characteristic master, or plan/task list) to confirm the selected set key referenced there matches the one just inspected, rather than an older or differently-named set.

QM catalog and selected-set maintenance is functionally unchanged on S/4HANA. There is no Fiori app replacing QS41; it remains a SAP GUI configuration transaction, consistent with the rest of the QM catalog family. Consultants moving from ECC should not expect a simplified UI here, and any S/4HANA-specific behavior differences would be limited to general catalog authorization or transport handling rather than the object model itself.

This is functional QM configuration territory, owned by the QM consultant responsible for the catalog structure, not by ABAP or Basis. A handover should state the catalog type, the selected set key, the code group(s) it draws from, and every place the set is assigned downstream (catalog profile, characteristic, task list) so the receiving consultant does not have to reverse-engineer the assignment chain.

Read QS21 first to understand how code groups and codes are created, since QS41 only aggregates what QS21 already defined; QS23 is useful for displaying an existing code group to confirm status before troubleshooting a selected set. Downstream, QM01/QM02 and QE51N are where selected sets actually surface as F4 helps to end users, and QA32 shows the usage-decision variant of the same mechanism. Understanding those consuming transactions makes it obvious why a selected set that looks correct in QS41 can still fail to appear where expected.