SAP tableObjectPLMKModuleQM

PLMK table — Task List Inspection Characteristic Assignment

PLMK holds the inspection characteristics assigned to a specific operation of a task list (inspection plan, routing, or rate routing). Each row ties one characteristic to one operation node of one task list group and version, either as a locally defined characteristic or as a reference to a reusable master inspection characteristic. It is read when an inspection lot is created, not when results are recorded.

This page covers PLMK, the table that links inspection characteristics to task list operations in QM, and the diagnostics around missing, duplicated, or version-mismatched characteristics on inspection lots. It also covers how PLMK relates to the task list operation table, its companion control/value table, and the master characteristic catalog.

Published 16 Sept 2026· 1,080 words

What it stores

One row in PLMK represents a single inspection characteristic attached to one operation, or sub-operation, of one task list. The task list can be an inspection plan, a routing, or a rate routing used for quality inspection planning. The characteristic can be locally defined so it only exists in the context of that task list operation, or it can be a reference to a reusable master inspection characteristic maintained in the QM characteristic master. PLMK sits between the routing or inspection plan structure and actual inspection execution: when an inspection lot is created for a material that uses this task list, the characteristics found here become what the inspector is asked to evaluate for that operation, carrying whatever sampling, tolerance and control settings were configured on the task list.

Key fields

  • MANDT - client
  • PLNTY - task list type, for example an inspection plan versus a routing versus a rate routing
  • PLNNR - task list group, the key identifying the task list itself
  • PLNAL - group counter, i.e. the task list version
  • PLNKN - internal node number of the operation or sub-operation the characteristic is assigned to
  • ZAEHL - counter distinguishing multiple characteristics assigned under the same operation node
  • Additional attributes covering quantitative versus qualitative type, tolerance, sampling procedure and the reference to a master characteristic exist on this row but are deliberately not named here field by field; they should be confirmed against the actual dictionary structure before being quoted in a fix

How it joins the data model

  • PLMK-PLNTY/PLNNR/PLNAL/PLNKN = PLPO-PLNTY/PLNNR/PLNAL/PLNKN, joining the characteristic back to the operation it belongs to
  • PLMK-PLNTY/PLNNR/PLNAL/PLNKN/ZAEHL = PLMZ-PLNTY/PLNNR/PLNAL/PLNKN/ZAEHL, joining to the control and value data for that same characteristic row
  • PLMK-PLNTY/PLNNR/PLNAL = PLKO-PLNTY/PLNNR/PLNAL, joining to the task list header for group and version-level attributes
  • The task list group and version are reached from the material and plant through a separate task list to material allocation table, before ever touching PLMK
  • When an inspection lot is created against the task list, the resulting characteristic-level results are recorded against the same PLNTY/PLNNR/PLNAL/PLNKN/ZAEHL combination, or against the master characteristic number if the row references one

How to read it safely

Always restrict on MANDT plus the task list identity, PLNTY, PLNNR and PLNAL together, before looking at anything else. Never select on PLNKN or ZAEHL alone; both are only meaningful inside a specific task list group and version and will silently mix up characteristics from unrelated task lists if used as the sole filter. The table is not enormous compared to the results tables, but a plant with many inspection plans and many versions of each can still make an unfiltered scan slow and misleading. It is usually more productive to start from PLPO to get the operation description and confirm which operation is in question, then come back to PLMK for the characteristics under that operation.

How to prove it in the data

Symptom: a characteristic that should print on the inspection lot for material Y is missing. Find the task list assigned to that material and plant, note its PLNTY, PLNNR and PLNAL. Select PLMK for exactly that combination and check whether the expected characteristic row exists at all, and whether it carries a deletion or validity-period flag that would keep it out of newly created lots. Cross-check the same key against PLMZ to see whether the control data marks the characteristic inactive even though the PLMK row itself is present.

ECC vs S/4HANA

PLMK is a classic transparent table from the routing and task list data model shared by PP and QM, and it continues to exist on S/4HANA without being replaced by a CDS-based compatibility view, unlike some finance and MRP objects. The underlying task list structures were not restructured in the S/4 move, so maintenance still goes through the standard inspection plan and routing transactions rather than a Fiori app built directly on this table.

Common pitfalls

  • Confusing PLMK, the task list-level assignment, with the master characteristic catalog: deleting or changing a characteristic in one does not touch the other, so a characteristic removed from a task list can still exist untouched in the reusable master, and the reverse is also true
  • Reviewing the task list characteristic list on screen and assuming that is what printed on a given inspection lot, without checking that the lot was actually created against that same task list version, PLNAL; an older or newer version can carry a different set of characteristics
  • Reading PLMK and concluding a characteristic is missing without checking its deletion or validity flag; the row can still physically exist but be logically excluded, which never surfaces at lot creation
  • Treating ZAEHL as stable across versions; when a task list group is copied to a new PLNAL, the characteristic sequence can be renumbered, so matching two versions by ZAEHL alone silently pairs unrelated characteristics
  • Forgetting that PLMK is read at inspection lot creation time and not at result recording time; editing a characteristic in the task list after a lot already exists changes nothing on that lot, only on lots created afterward, which is a frequent source of confused change requests

Whose problem this is

This is core QM master data. Ownership sits with whoever maintains inspection plans and routings for the plant, typically the quality planning role in QM, working with production planning when the task list is a shared routing carrying inspection operations. A missing, wrong, or extra characteristic on an inspection lot is a question for that quality planner, not for basis or for the person recording the inspection result.

Related SAP objects

Reviewed pages this object connects to in the ERPClimb knowledge graph.

Source: ERPClimb — https://erpclimb.com/sap-tables/plmkERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.