QA02 — Change Inspection Lot

QA02 opens an existing inspection lot for change: sample size and sampling procedure, inspection specifications and characteristics assignment before results exist, planned and actual delivery dates, stock posting indicators, lot quantity adjustments, and status-relevant flags like skip or acceptance without inspection. The structural fact that explains most confusion is that QA02 edits the lot header and its planning data, not the results themselves and not the usage decision. Those live in separate transactions with their own status logic. A lot's editability in QA02 is gated by its status: once results recording has started for a characteristic, or a usage decision (even partial) has been posted, the corresponding fields are protected from change to preserve consistency between what was inspected, what was decided, and what the lot record says.

QA02 is reached whenever an inspection lot's planning data needs correction after creation: a wrong sample size was proposed by the inspection plan and needs manual override, a deadline needs extending because the lab is behind, a stock posting rule needs adjusting before the usage decision, or a lot quantity needs correcting because a goods receipt was split or reversed. It sits between lot creation (automatic from goods receipt, production order, or QA01 for manual lots) and results recording. Consultants reach for QA02 specifically for header and sampling changes; they reach for QE01 or QE51N to enter or change measured values, and QA11 or QA12 to post or change a usage decision. In a Fiori-first S/4HANA landscape, quick single-field corrections may also be handled through a quality lot monitoring app, but the underlying change logic and locks are identical.

Pull the lot from QALS by lot number and check the status field for usage-decision and results-existence indicators. Cross-check against QAVE for the same lot number: a row there with a decision code and date means the usage decision is posted and header changes will be blocked. If a change was attempted and appears to have had no effect, compare the lot's last-changed timestamp on QALS against the time of the attempted save; a mismatch confirms the change was rejected rather than lost.

The transaction and its underlying lock logic are unchanged on S/4HANA; QA02 still opens the same header and sampling data with the same status-driven field protection. What changes is the front end: quality lot monitoring and processing can be done through Fiori apps built for inspection lot management, which expose the same fields in a worklist-driven layout, but the classic transaction remains fully supported and is often faster for a single known lot number.

Functional QM territory. A handover to QM should include the lot number, its current status line from QALS, whether a usage decision exists, and whether results have been recorded, so the receiving consultant does not waste time trying to change a field that is locked by design rather than broken.

Start from QA01 to see how a lot's header data is first populated, since QA02's editable fields are the same set minus whatever creation logic already fixed. Follow to QE01 and QE51N to understand when results recording begins locking sample and characteristic fields. QA11 and QA12 explain the usage decision that finally locks the lot header outright. QA32 is worth knowing alongside QA02 for mass processing of lots rather than one at a time.