Goods Movement Error During Order Confirmation

Shop floor supervisors say the confirmation went through but the system is showing an error, or that stock on the floor does not match what SAP shows for the order. Production reports the order as confirmed, labour hours are booked, but finance later flags that inventory for the components was never relieved and the finished goods stock was never received. Someone on the team mentions a growing list of stuck confirmations that a key user has to clear every morning. Occasionally it surfaces as a shortage message during the next MRP run, where the system still shows components as available that were physically consumed on the shop floor days earlier because the movement behind the confirmation never actually posted.

Start in the confirmation error transaction (commonly known by its error queue, COGI) to see the exact message and material for each failed line, this is faster than guessing from the order. Check the message number and long text, it names the missing storage location, the stock shortage, or the batch problem directly. Cross-check the material master in MM03 for the plant and storage location views to confirm the material is extended where the movement is trying to post. Use MMBE or a stock overview to compare book stock against what the error message expects. Pull up the order component list in CO03 to see if the backflush indicator, storage location, or batch fields differ from what is in the material master or was changed mid-order. If the error mentions status, check the order status in CO02 or CO03 for TECO or locking flags applied out of sequence.

Pull the confirmation error queue filtered by plant and date range and count entries older than one shift, aging beyond a shift is the signal this is a process problem, not a one-off. Group the stuck entries by message number, if one message dominates (for example a single missing storage location) it points to a config gap affecting many orders rather than isolated data errors scattered across materials.

If the cause is a missing storage location or unextended material, this is a data fix, extend the material or correct the storage location field on the component and reprocess the queue entry, no transport needed. If the cause is genuine stock shortage, the underlying inventory discrepancy has to be resolved first, either by posting the physical stock that exists but is not yet in the system or by correcting the sequence of movements, reprocessing without fixing the shortage just defers the error. Batch determination failures are usually data (assign or create the batch) unless the batch search strategy itself is missing, which is config and needs the strategy set up and transported. Negative stock permission, movement type restrictions, and status profile behaviour are configuration changes owned by MM or PP configuration teams and require a transport through the landscape, they are not something to toggle directly in production. Price control issues on the receiving material need a finance-agreed valuation correction, not a quick standard price overwrite.

The reflex is to open the error queue and mass-reprocess every entry, or to switch on negative stock for the plant to make the errors disappear. Mass reprocessing without reading the individual messages just re-triggers the same failure for genuine stock or batch problems, and turning on negative stock hides a real inventory sequencing issue by letting the system post consumption against stock that is not physically there, which then corrupts valuation and shows up later as a large unexplained inventory difference at period close.

PP support owns triage of the error queue and confirmation logic. MM or WM owns storage location extension and negative stock policy. The handover note should list the message number, the material and plant affected, whether stock genuinely existed at the time of confirmation, and whether the fix applied was a data correction or requires a configuration change with a transport reference.