Transfer Order Will Not Confirm

The warehouse team reports that a putaway or pick task will not close out. The RF gun beeps and shows an error, or the office user running the confirmation transaction gets a message and the TO item stays open in the queue. Common phrasing: 'this order won't confirm, it just throws an error every time', 'I scanned the bin and it kicked it back', 'the picker finished the pallet but the system says quantity too large', or 'this TO has been sitting open for two days and nobody can close it'. Sometimes the complaint is really that the same TO number seems to need confirming twice, or that a bin the worker was told to use is refused by the screen. The business framing is always the same: physical work is done, but the system will not accept that it is done.

Pull the TO in LT21 and record planned quantity, confirmed quantity, item status, and the destination storage type and bin. Run LX03 for that bin at the time of the attempted confirmation to capture its block status and current quant content. Cross-check the material's stock category against the storage type's allowed indicators in the warehouse customizing view. Attach the exact RF or dialog error message text, since the message number narrows the cause to quantity, authorization, or bin status far faster than reproducing the scenario from scratch.

If the cause is a quantity difference within a reasonable margin, the immediate fix is data-level: correct the confirmed quantity to match the tolerance or process the difference through the standard difference posting so the TO closes with a recorded variance. If the tolerance itself is set too tight for the actual operational pattern, that is a movement-type configuration change requiring a transport and sign-off from the WM configuration owner, since it affects every future TO of that type. If the destination storage type rejects the stock category, the immediate fix is moving the stock to a bin in a storage type that accepts that category (data action); permanently adding the category to the storage type's allowed indicator is a config change needing transport and review of downstream reporting impact. If the item is already confirmed or the TO was cancelled, no fix is needed beyond explaining the TO history to the picker and reissuing a fresh task if stock still needs moving. If the movement type is set to immediate automatic confirmation, no defect exists; only change this configuration if the business genuinely wants a manual second step, and treat that as a transported change with wide impact. Authorization gaps route to the security team for role adjustment, not to WM configuration.

The common reflex is to cancel the stuck transfer order and create a fresh one to replace it, or to force the confirmation by overriding the quantity field without understanding why it differs. Cancelling and recreating loses the audit trail back to the original transfer requirement or reservation and can leave the source bin quant in an inconsistent state if the original TO had already posted a partial movement. Overriding the quantity to push a confirmation through can post stock into the wrong bin category or create a negative stock situation at the destination that surfaces later as an unrelated inventory discrepancy.

Warehouse operations owns the day-to-day confirmation process and the first triage of the error message. WM configuration ownership sits with the logistics execution config team for movement type tolerances and storage type allowed-indicator settings, both of which require transport. Authorization failures go to the security or basis team. The handover note should carry the TO number and item, exact error text, planned versus confirmed quantity, destination bin and storage type, and the movement type involved.