What Is an Inventory Issue Transaction?

An inventory issue is a ledger entry that records stock leaving inventory, posted as a negative quantity when material is consumed or a demand is satisfied from on-hand. It is one half of a two-direction ledger: receipts add stock, issues remove it. Every issue is a signed, permanent line in the record, never an edit to a stored number.

This entry defines the inventory issue and shows how it reads inside EDGEBIC by User Solutions. For the wider index of terms, see the manufacturing glossary; for the record it lives in, see what is an inventory ledger; and for the movement that cancels one, see ledger reversal.

How it works

Think of a bank statement. Money in is a positive line, money out is a negative line, and each line shows the balance after it posts. The inventory ledger works the same way. A receipt is a positive entry, an issue is a negative entry, and every entry records the running balance that follows it.

An issue posts whenever stock is drawn down. The most common trigger is consume-from-stock: when a demand exists for a product that already has on-hand, the engine satisfies it from stock rather than building, and posts a single negative issue at the persist step with the comment Schedule Transaction. A routing's material step that consumes raw material posts an issue too. In each case the movement is signed, dated, and linked to the order it served.

Because the ledger is append-only, an issue is never edited or deleted. If it was wrong, an inverse reversal cancels it while both entries stay in the record. This is what makes the ledger the authoritative on-hand: the sum of every signed entry is the true balance, and nothing can quietly change history.

A concrete example

A product opens with 200 units on hand. An order needs 80, and the engine finds enough on the shelf, so it satisfies the demand from stock. At the persist step it posts issue number 2: minus 80, comment Schedule Transaction, running balance after 120.

The on-hand is now 120, not because a stored field was overwritten, but because the ledger sums to 120. No work center ran, no build receipt posted, and the job's status records that it was satisfied from stock. The single issue line is the whole story of those 80 units leaving.

Now suppose you reschedule that job. The engine first reverses issue number 2, restoring the balance to 200, then reads on-hand fresh, and posts a new issue for the current build quantity. The reversal and the fresh issue both appear, but only one consumption ever stands, so rescheduling the same job never drains the shelf twice.

How EDGEBIC uses it

In EDGEBIC, an inventory issue is one of the recognized ledger transaction types, posted through the inventory service so the on-hand cache is recomputed atomically in the same transaction as the entry. When the scheduler satisfies a demand from stock, it emits a satisfied-from-stock schedule row and pairs it with an issue in the ledger, keeping the plan and the stock record in agreement.

The reversal-first discipline is what makes reschedules safe. Before the engine reads on-hand for a job, it reverses any existing consume issue for that job, so no matter how many times you reschedule, there is at most one live issue draining stock for it. The ledger may accumulate an issue, a reversal, and a fresh issue across runs, but the arithmetic always nets to a single true consumption.

To see the receipts that mirror issues and the full ledger lifecycle, read EDGEBIC inventory ledger explained and what is consume from stock netting. To follow the entry that undoes an issue, continue with ledger reversal.