QM Stock Not Released After Usage Decision

Quality reports the lot as closed: the inspector signed off, the usage decision code is 'accepted', the file is done from their point of view. Three days later production or the warehouse comes back saying the material is still sitting in quality stock, MRP will not count it as available, and a reservation or delivery cannot be picked against it. The complaint usually arrives as 'why is this batch still blocked, QC already released it' rather than as a system defect, because from the inspector's screen the transaction completed without any error message. Sometimes it surfaces as a month-end reconciliation issue instead, when someone runs a stock aging report and finds material with a UD from weeks ago still coded to the quality stock type.

Pull the inspection lot table joined against the plant stock tables for the material and plant in question: list every lot with a usage decision date populated and a decision code marked as accepted or rejected, then compare the lot quantity against the quantity still recorded under the quality inspection stock type in MARD/MCHB. Any lot where the UD date is populated but the quality stock quantity is still greater than zero is the evidence set. Cross-check the job log timestamps against the UD save time to isolate failed automatic postings.

If the decision code simply has no stock posting configured, this is a change to the QM decision code customizing (movement type assignment against the code and inspection type) and needs a transport through the normal change path; it is not something a single lot fix resolves, because every future lot using that code will repeat the symptom. If the cause is a failed background job, the fix is data-level: clear the blocking condition (unlock the material, fix the storage location) and reprocess the stock posting for that specific lot, usually via the usage decision screen's posting function rather than redoing the whole UD. If a partial lot was missed, the remaining lot needs its own usage decision; no configuration change is involved. If the quantity mismatch is the cause, reconcile the actual stock quantity against the lot before reposting, and only then repost the movement, otherwise the second posting fails the same way. If manual posting is the intended design, the resolution is procedural: update the work instruction so inspectors execute the stock posting step, not a system change. Batch status and WM transfer order issues are cleared as one-off data corrections against the affected batch or transfer order, with no config impact.

The common reflex is to reopen the usage decision in QA12, change nothing, and save it again hoping the posting fires the second time, or to bypass QM entirely and post a manual MIGO/MB1B movement to shove the stock out of quality status. Re-saving the UD often does nothing if the root cause is a missing movement type assignment, since the same configuration gap is hit again. The manual MIGO workaround gets the stock moved but leaves the inspection lot's own stock posting field inconsistent with what actually happened in inventory management, which shows up later as an unexplained quantity difference during lot closure review or in a batch traceability audit.

First ownership sits with the QM configuration or support consultant, since the decision code and inspection type setup determine whether a posting should even occur automatically. MM involvement is needed when the block is a stock or batch inconsistency, and WM/EWM support is needed when a transfer order is the blocker. The handover note should state the lot number, the decision code and date, the exact stock quantity discrepancy observed, and whether the fix applied was configuration (needs transport) or a one-off data correction.