QPGR table — QM Catalog Code Group Master Table

A row in QPGR represents one code group belonging to one catalog type in the QM catalog master data structure. SAP QM catalogs are organized in three levels: the catalog type itself (defined in the catalog type table), the code group within that catalog type, and the individual codes within the group. QPGR is the second level. It does not hold the descriptive text for the group (that sits in a separate text table) and it does not hold the individual codes (those sit in QPCD). What QPGR does hold is the group key, its administrative trail, and whether the group is currently usable. Catalogs built on this structure are used everywhere in QM that needs a controlled coding scheme: defect type codes on notification items, cause codes, usage decision codes on inspection lots, and valuation codes for inspection characteristics.

The table is client-dependent and small relative to transactional QM tables, so it is rarely a performance concern on its own. Always restrict by KATALOGART first; a code group key is only unique within its catalog type, so scanning across catalog types without that restriction returns unrelated groups that happen to share a group number. When chasing a specific defect or cause code from a notification, work backwards from the notification item's catalog type and group value rather than searching QPGR blind. Do not join to QPCD or the text tables without also matching on catalog type, or codes from a different catalog with a coincidentally matching group and code number will slip into the result set.

Symptom: a user reports that a defect code they expect to see in a notification is not offered in the input help. Selection: read QPGR for the notification's catalog type and the specific code group used by that field, and check the lock or deletion status. If the group is locked, the codes underneath it in QPCD will not appear in F4 help even though they still exist as records, which is the usual explanation rather than a missing code.

QPGR carries over from ECC into S/4HANA as a transparent table with no structural change observed. QM catalog master data was not part of the wave of table replacements that affected core inspection and notification objects, and the catalog maintenance transactions continue to write to the same three-tier structure. No compatibility CDS view is required to read it, and reporting on catalog master data is typically done with straightforward table access rather than a released core data service.

Catalog structure and code group definitions are owned by whoever configures QM master data, usually the QM configuration lead rather than the functional consultant running day to day inspection or notification processing. Disputes about a missing or locked code should go to that owner before being treated as a transactional data defect.

QPCD holds the actual codes under each group and QPCT holds code-level text; both are maintained through the same catalog maintenance transaction as QPGR. QMFE and QMUR are the notification item tables that consume defect and cause codes from a QPGR group. QASE consumes catalog codes during characteristic result recording. Catalog and code group maintenance is typically done through the QM catalog configuration transaction rather than by direct table edit.