PLMZ table — Task List Material Component Assignments
PLMZ stores assignments of BOM or material components to operations in routings and other task lists. It links a task-list operation with the BOM item or component allocated to that operation and supports effective-dated or change-number-controlled assignment. It is not supplementary Master Inspection Characteristic data; QM characteristics in task lists use tables such as PLMK.
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 20 Sept 2026· 872 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
- Task-list type, group, and group counter — identify the routing or task list.
- Operation and sequence assignment — identifies the operation receiving the component.
- BOM or item reference — identifies the material component being allocated.
- Validity and change-number fields — control effective assignment state.
- PLKO, PLPO, PLAS and STPO, STAS — provide the task-list and BOM context around the assignment.
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 remains relevant in S/4HANA manufacturing. SAP's current released CDS content describes PLMZ as the source for manufacturing bill-of-operations operation-to-BOM-item assignment change states. Use it for component allocation to operations, not MIC master data.
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.