Batch Determination Fails at Goods Issue

The warehouse team reports that when they post a goods issue for a production order or a stock transfer, the batch field stays blank and no proposal list opens, even though they can see the material has plenty of batch stock in the bin. Sometimes it worked yesterday on the same material and plant and now it does not. Sometimes it works for one storage location but not another for the same material. Occasionally the complaint is the opposite of empty: the proposal opens but shows the wrong batches, or batches that are clearly expired or blocked, and the operator has to override it every time. Either way the request that reaches the functional consultant is phrased as 'batch determination stopped working' or 'the system is not picking a batch anymore,' with no further diagnosis attempted on the shop floor.

Pull the batch master for the specific material and plant in MSC3N and list the classification values against the exact characteristics named in the strategy's selection criteria in COB3. Where a value is blank, or where the batch status excludes it, or where the batch's expiry date fails the strategy's date filter, that is the documented reason the proposal returned nothing - independent of whether MMBE shows quantity on hand.

Missing or blank classification values on the batch are a master data fix - update the batch record directly in MSC2N, no transport required, though a mass update via a batch input session may be needed if many batches are affected. A missing condition record for the search strategy is also master-data-style maintenance in COB1, done directly in production, but if the strategy type, access sequence, or condition table itself is missing that is customizing and needs to move through the transport route with the usual testing. If the movement type is not flagged for batch determination, that flag is customizing in the movement type settings and requires a transport, coordinated with whoever owns movement type configuration since it affects every process using that movement type, not just the one reported. If the root cause is that the strategy's own selection logic (expiry cutoff, status filter) is correctly excluding genuinely unusable stock, the fix is not technical at all - it is a stock disposition decision, and no configuration change should be made to force a proposal of stock that should not move.

The standard workaround is to let the operator key in the batch number manually at MIGO and skip the proposal screen entirely. It gets the goods issue posted and closes the immediate complaint, but it removes the control the strategy exists to enforce - first-expiry-first-out, status exclusion, quantity splitting - and puts the choice back in the hands of whoever is standing at the terminal. It also means the same gap resurfaces on the next transaction, because nothing about the missing condition record, the blank characteristic, or the deactivated movement type flag was actually touched.

Batch classification values are owned by the production or quality team that releases the batch; missing values point there first. The search strategy condition record and movement type activation flag are owned by the MM/inventory management configuration team. The handover note should state the material, plant, movement type, the strategy type and condition record checked, and whether the gap is a blank characteristic on a specific batch or a missing configuration entry affecting the whole movement type.