Batch-level traceability: know exactly which intake every outgoing kg came from

Until now, a recycling operator's waste stock was a single number per waste type: how many kg of scrap iron you have, how many kg of plastic, how many units of appliances. Fine for aggregate accounting, but not enough for a question an audit or a partner can ask at any time: "this batch of processed material — which specific intakes did it actually come from?"

VanaGreen now answers that question at the individual batch level, not just the total.

Batches, not just a total

Alongside the existing aggregate stock (unchanged, still there), every quantity that enters inventory — from a collection, a treatment, or a manual adjustment — now creates its own batch, with its own initial and remaining quantity. When a quantity leaves stock — through a treatment or an outgoing shipment to a partner — consumption follows FIFO: it always draws from the oldest available batch, never the most recent. It's the same logic any well-run physical warehouse would apply manually, except now it's guaranteed by the system, not by an operator's memory.

When a treatment produces new material (shredding or sorting, for example), the result is recorded as a derived batch, explicitly linked to the batch (or batches) it came from. In practice, you can trace the whole chain: which intake a batch came from, which treatment it went through, what came out of it, and who it went to.

Confirmed units vs. estimated units

For waste counted by unit (not just weighed), the outgoing form now shows two distinct figures: how many units are confirmed available (coming from batches where the exact count is known) and how many are estimated — calculated from the remaining weight divided by an average kg-per-unit for that waste type. If the operator enters a weight that deviates too far from what the estimated unit count would suggest, the app shows a warning — not blocking, just a signal that the value is worth double-checking before confirming.

Cancellation that actually cancels, not just blocks

This was the toughest product decision in the whole feature: what happens to batches when a finalized collection, outgoing shipment, or treatment session gets canceled or reopened? The easy option would have been to simply block cancellation any time a batch had already been touched. Stefan chose the harder, correct option instead: real reversal.

Cancellation actually undoes the batch creation or consumption tied to the canceled operation — but only when it's demonstrably safe, meaning nothing later has touched that batch since. If a later treatment or shipment has already consumed (partially or fully) a batch that the canceled operation wants to undo, the system clearly refuses the cancellation, with an explicit message, and the whole transaction rolls back cleanly — no partial state, no batches left inconsistent. There's never an automatic cascade that cancels downstream operations too — that decision stays with the operator.

As a direct consequence of this work, finalized treatment sessions got a cancel/reopen function for the first time — until now, a finalized treatment was permanent, with no way back.

Why it matters for an operator

For someone responding to an ANPM (Romanian National Environmental Protection Agency) inspection or a partner's traceability request, the difference is direct: you can show exactly which intake a batch leaving the warehouse came from, not just a monthly total. And when someone enters a wrong quantity at intake or during a treatment, fixing it no longer means leaving stock in a confusing state — cancellation undoes exactly what needs undoing, or stops you clearly if the operation can no longer be canceled safely.