A Satisfied-From-Stock Job Did Not Draw Down Inventory: Causes and Fixes

When a job carries a satisfied-from-stock status but the ledger has no consumption entry pegged to it, the stock was never actually drawn down and on-hand is overstated by the quantity the job claimed. EDGEBIC by User Solutions flags this on its plant-wide anomaly scan, because a schedule that says stock was used and a ledger that says otherwise cannot both be right.

This post covers why the entry goes missing, why a simulation run is a legitimate exception, and how to correct the balance without inventing history. It sits with the other inventory symptoms in the EDGEBIC troubleshooting guide. For the mechanism itself see what is consume-from-stock netting, and for the full-coverage case see when an order is fully satisfied from stock.

What You Are Seeing

A job shows the satisfied-from-stock status. It scheduled no operations, which is correct: its whole demand was met from inventory. But the transaction history for the product has no issue entry pegged to that job, so the on-hand balance never went down. Downstream, later jobs net against a quantity that is not really available.

Why It Happens

Cause 1: The Persist Step That Posts the Issue Did Not Run

The status flip and the ledger post belong to the same round trip at the end of a scheduling run. When that round trip does not complete for a job, the status can land without its consumption entry. That leaves the schedule and the ledger telling different stories about the same quantity.

How to tell: the job's status is satisfied from stock, the transaction history for the product shows no entry pegged to the job number, and the on-hand balance is higher than the shop floor believes.

Cause 2: The Run Was a Simulation

A what-if or quote simulation deliberately does not post to the ledger. It shows the netting result so you can judge a promise date or a coverage question without moving inventory. A job that shows as satisfied from stock inside a simulation is correct to have no consumption entry.

How to tell: the result came from a what-if or a quote rather than a live scheduling run.

Cause 3: The Entry Was Posted and Then Reversed

The ledger never deletes. A consumption that was backed out appears as a reversal rather than as an absence, and the balance goes back up by the reversed quantity. That is a different situation from a missing entry and needs a different response.

How to tell: the history shows an entry for the job and a matching reversal.

How to Fix It

• Re-run scheduling for the job. The full round trip runs again and posts the consumption. The posting path is repeatable, so a second run does not stack a second draw-down.
• Confirm in transaction history. Filter to the job number and look for one live issue entry and no build receipt. A satisfied-from-stock job schedules no work, so there is nothing to receive, and if one does carry a machine row anyway, a satisfied-from-stock job that still shows a work center row covers what that breaks downstream.
• If the run was a simulation, do nothing to the ledger. Schedule the job through a live run when you are ready to commit the coverage.
• If you find a reversal, decide deliberately. Either re-post the consumption or accept the stock back into the balance, but do not delete the reversal.

How to Diagnose It, in Order

1. Run a plant-wide anomaly scan. This check is plant-wide, so a job-filtered run will not produce its rows.
2. List the flagged jobs and note the products and quantities involved.
3. Open transaction history per product, filtered to each job number, and confirm the entry is absent rather than reversed. How to audit the inventory ledger for a part covers the reading.
4. Re-run scheduling for each affected job.
5. Re-scan and re-check the history to confirm the entries landed and the balance moved.

Why the Overstated Balance Matters More Than the Row

The anomaly row is a warning, but its downstream effect is not small. Netting is only as good as the balance it reads. A product whose on-hand is overstated by one job's worth of coverage will satisfy the next job from stock that does not exist, and the shortage surfaces on the floor rather than in the plan. That is why this check is worth clearing quickly even though it never blocks a run.

Keep it distinct from cache drift, where the stored on-hand number and the ledger total disagree with each other. Here the ledger and the balance agree, and both are wrong together because a movement that should have been recorded was not. The reading for the other case is my on-hand quantity does not match the inventory ledger.

How to Prevent It

• Scan plant-wide after every bulk scheduling run, not just after single-job runs. A bulk run covers more jobs and therefore more chances for a gap to go unnoticed.
• Check the history whenever a job flips to satisfied from stock on a product you care about. One filtered look confirms the movement.
• Keep simulations clearly separated from live runs in how you talk about them, since the same status appears in both and only one of them moves stock.
• Never patch the balance by typing over the on-hand number. Post an adjustment with a reason instead, which keeps the ledger as the single trail everything else is measured against.