Inspection Lot Origins, Control Keys, and Automatic Creation Logic (Part 2)

Moving beyond the basic concept, the practical configuration challenge in SAP QM is controlling exactly when an inspection lot gets created, what data it inherits, and how it behaves once created. This is governed by the combination of inspection lot origin and inspection type, both of which are configured in the IMG under quality management inspection settings, and by the QM view of the material master where inspection types are assigned per material-plant combination.

The inspection lot origin is a fixed, largely SAP-delivered classification indicating the general business process area, such as goods receipt inspection, in-process inspection tied to production or process orders, and inspection tied to deliveries or stock transfers. Within an origin, the inspection type is the more granular, often customer-extensible object that a consultant assigns to a material master QM view record. The inspection type configuration determines control indicators including whether the lot is created automatically, whether quality inspection stock posting is mandatory, whether skip lot logic (inspection skipping based on history) is permitted, and whether the inspection is relevant for a specific document category like a particular purchase order type or account assignment category.

When a goods receipt is posted against a purchase order, the system checks whether an active inspection type exists in the material's QM view for that plant and whether the inspection setup indicates automatic lot creation is active for that combination of movement type and inspection type. If all conditions are met, the system creates the lot, assigns a sampling procedure and inspection plan or default characteristics based on the inspection plan usage and material specification search, and posts the received quantity into quality inspection stock rather than unrestricted stock. If no valid inspection setup exists, the goods movement proceeds normally with no lot created, which is often the root cause when consultants are asked to troubleshoot why a receipt was not inspected.

For production processes, in-process inspection lots are typically tied to a routing or master recipe operation flagged as inspection-relevant, and the lot is created either at order release or at the first confirmation, depending on configuration. This matters because in-process lots often need to reflect partial confirmed quantities rather than a full order quantity, and the timing of lot creation affects when quality can begin recording results relative to production progress.

Control keys attached to the inspection type also determine downstream behavior: whether usage decision is mandatory before further stock movement, whether certificate creation is triggered, whether the lot participates in dynamic modification (skip-lot) rules based on prior quality history, and whether follow-up actions like automatic notification creation occur on rejection. Consultants must carefully test these control indicators in a sandbox using representative movement types, because incorrect settings can silently prevent lot creation (leaving material uninspected and available) or aggressively create lots for movements that should not require inspection, creating unnecessary workload and stock blocking.

Across deployments, the fundamental origin/inspection-type model is consistent, but S/4HANA on-premise and private cloud retain full IMG-level configuration access for defining and extending inspection types and control indicators, while S/4HANA public cloud generally restricts consultants to activating and parameterizing predelivered scope-item configuration rather than freely creating new inspection types; teams should validate current extensibility options in their specific tenant rather than assuming on-premise-level flexibility is available.

During a rollout for a discrete manufacturer, goods receipts for a specific vendor were not generating inspection lots even though the material had an active QM view. Investigation showed the inspection type was correctly assigned, but the automatic lot creation indicator in the inspection setup for that particular movement type combination had been deactivated during an earlier data cleanup, so receipts posted straight to unrestricted stock. The fix required reactivating the correct inspection setup entry and then manually creating retroactive lots for the affected receipts to bring already-received stock back under quality control.

• Assuming assigning an inspection type in the material master alone guarantees lot creation without checking inspection setup activation.
• Not distinguishing between inspection lot origin (broad process category) and inspection type (specific configurable control object).
• Overlooking that different movement types can have different inspection setup entries, causing inconsistent lot creation behavior for the same material.
• Failing to test in-process inspection lot timing (order release vs confirmation) before go-live, causing confusion about when quality can begin recording results.
• Assuming public cloud tenants allow the same level of inspection type customization as on-premise systems.

• Maintain a documented matrix of inspection type to movement type mappings for each material category to speed up troubleshooting.
• Test automatic lot creation for every relevant movement type combination during configuration, not just the primary receipt scenario.
• Clearly separate origin-level assumptions from inspection-type-level configuration when writing functional specs.
• Validate in-process lot creation timing against actual production confirmation patterns before finalizing routing inspection flags.
• Confirm extensibility limits for inspection types early in cloud projects to avoid designing configurations that cannot be implemented.

A common interview probe is asking how a candidate would troubleshoot a missing inspection lot after goods receipt. Strong candidates walk through checking the material's QM view and active inspection type, then the inspection setup for the specific movement type, rather than jumping to guesses about user error or generic system bugs, demonstrating structured root-cause analysis.