PLMZ table — Master Inspection Characteristic Additional Data
PLMZ is a QM master-data table that carries supplementary control data for a master inspection characteristic (MIC) maintained under transactions like QS21 to QS29. Each record extends the base characteristic held in PLMK with additional attributes such as valid-from/valid-to dates and control indicators, keyed by plant and characteristic number, and is read whenever a MIC is copied into an inspection plan or task list operation.
This page covers PLMZ, the plant-dependent additional-data table behind master inspection characteristics in Quality Management. It focuses on how PLMZ relates to the base characteristic table PLMK, how to select against it safely, and the pitfalls consultants hit when they try to diagnose inspection plan or results-recording problems from this table alone.
Published 16 Sept 2026· 902 words
What it stores
One row in PLMZ represents the additional, time-dependent control data attached to a single master inspection characteristic (MIC) for a given plant. The base identity and short description of a MIC live in PLMK; PLMZ carries the supplementary indicators and validity information that SAP split off for technical reasons rather than storing everything in one wide table. A MIC created and released through the master characteristic transactions generates a base record in PLMK and, where the characteristic has additional control settings, a corresponding record in PLMZ. Consultants normally only look here when troubleshooting why a characteristic behaves differently in an inspection plan than expected, or when a characteristic appears usable in one plant and not another.
Key fields
- MANDT - client
- MKMNR - master inspection characteristic number, the key linking back to PLMK
- WERK - plant for which the additional control data applies
- DATUV - valid-from date for the additional data record
- DATUB - valid-to date for the additional data record
How it joins the data model
- PLMZ-MKMNR = PLMK-MKMNR
- PLMZ-WERK = PLMK-WERK
- PLMK-MKMNR referenced from inspection plan characteristic assignment when a MIC is pulled into a task list operation
- PLMK-MKMNR referenced from inspection lot characteristic tables such as QASE when results recording is based on a master characteristic rather than a plan-specific one
How to read it safely
MANDT is the first field on every selection; never query across clients. WERK and MKMNR together are the practical selectivity for PLMZ, so a lookup should always restrict on plant first if the characteristic number range is not already known, since a full table scan on a QM master data table this narrow in row count is usually harmless but a habit worth avoiding on any productive system. The validity fields DATUV and DATUB matter more than they look: a characteristic can have multiple additional-data periods, and picking the wrong one gives a control setting that was correct last year but not today. Always check the current system date against the validity window before trusting a returned row.
How to prove it in the data
Symptom: a master inspection characteristic behaves correctly in plant 1000 but a colleague reports it missing or inactive in plant 2000. Select PLMZ with WERK equal to 2000 and MKMNR equal to the characteristic number in question. No row returned, while PLMK does return a row for that plant, means the additional control data was never maintained for that plant, which is the actual cause rather than a master data replication issue.
ECC vs S/4HANA
PLMZ has not been publicly documented as replaced by a compatibility view, and quality master data structures around master inspection characteristics have not changed shape in any release-specific way that can be confirmed here. Treat it as continuing to exist in S/4HANA in the same role it had in ECC unless a specific system check says otherwise, and verify field-level behaviour against the current system rather than assuming parity across releases.
Common pitfalls
- Treating a missing PLMZ row as proof the characteristic does not exist. The characteristic itself is defined in PLMK; PLMZ absence only means the additional attributes were never set for that plant, and the characteristic can still be usable with default behaviour.
- Ignoring the validity window and reading a PLMZ row that expired months ago, then concluding a control setting is active when a newer period record already superseded it.
- Assuming a characteristic's behaviour inside a specific inspection plan comes from PLMZ. Once a MIC is copied into an inspection plan operation, the plan-level characteristic record takes over and can be overridden locally; PLMZ only reflects the master data default, not what the plan actually carries.
- Editing PLMZ style attributes directly through table maintenance instead of through the characteristic master transactions. Direct table changes bypass consistency checks between PLMK and PLMZ and between master data and plan data, leaving the two out of sync.
- Cross-plant confusion: comparing a PLMZ row from one plant against expected behaviour in another plant without checking the WERK value, especially in systems where the same characteristic number was extended to several plants at different times.
Whose problem this is
Master inspection characteristic content, including what should be in PLMZ, belongs to the quality engineering or QM master data team that maintains the characteristic catalog, not to the person running the inspection lot. Basis or the technical team gets involved only if a direct table maintenance change is being investigated as the cause of an inconsistency.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/plmzERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.