Inventory
Included in every tierInventory availability is computed, not tallied at month-end
One formula decides what is actually available to allocate — on-hand minus what is allocated minus what is blocked by disposition — computed server-side from live lot and serial status, not a spreadsheet reconciliation someone runs before the planning meeting.
Lot and serial status → availability
| Status | Counts as on-hand | Counts as available |
|---|---|---|
| Quarantined | Yes | No |
| Released | Yes | Yes |
| Conditional Release | Yes | Yes |
| Rejected | Yes | No |
| Scrapped | No | No |
| Consumed | No | No |
Six statuses, shared by lots and serials. A released lot can contain a quarantined serial — serial disposition is independent of the parent lot's, on purpose.
Lot, serial, and sub-lot genealogy
Lots track quantity, unit of measure, received date for FIFO issue, and expiry for FEFO issue. Serials nest under a lot optionally and carry their own independent status — a released lot can still contain a quarantined serial, which is the correct behavior when a disposition decision is made at the unit level rather than the batch. Sub-lots are deliberately thin, per ISA-95 Part 2 §4.2: a code, a quantity, and a unit of measure that must match the parent lot's — no separate status, expiration, or storage location, because those inherit from the parent lot rather than drifting from it.
Availability, computed the same way everywhere
Available = On-hand − Allocated − Blocked. On-hand includes everything physically present — quarantined, released, conditionally released, and rejected stock — but blocked subtracts out quarantined and rejected quantities, so a lot sitting in quarantine shows up as present but not available to pick. Scrapped and consumed material is excluded from on-hand entirely, deliberately, so a missed drawdown can never leak into a release decision. The sum runs as a database aggregate, not a client-side loop, and it is the single calculation behind both production planning and the work-order release gate — there is no second, looser number quoted somewhere else in the product.
Allocation, and a drift detector that refuses to guess
Work-order material allocation is a real record per work order and BOM component — required, allocated, and consumed quantities, a shortage figure, and a status that moves from Allocated through Partially Consumed to Consumed or Released. A nightly worker independently recomputes allocated quantity from those records and compares it against the materialized balance the rest of the system reads for speed. If they disagree, it writes a drift record and marks itOpen for someone to look at — it never silently rewrites the number for you. That is a deliberate choice: an inventory system that quietly self-corrects a number you might be relying on for a compliance record is worse than one that flags the disagreement and waits for a person.
Lot and serial number reservation — not a stock reservation
Worth being precise about, because the word is overloaded: a "reservation" here means reserving a contiguous block of lot or serial numbers for an edge gateway, so an offline station can mint numbers without colliding with another station — not reserving stock. Reserved blocks expire automatically after a configurable window if unused. Stock commitment is the allocation model above, a separate mechanism entirely.
Material consumption and production, with edge-safe idempotency
Every consumption and production record can carry genealogy at lot, sub-lot, or serial granularity against a work order and the equipment that ran it, and carries an idempotency key so a retried submission from an offline edge station cannot double-post. Records distinguish the timestamp they were saved from the timestamp the event actually occurred — the latter is what feeds device-history and traceability reporting, so a delayed sync does not distort the record of when the work actually happened.
WIP is a live calculation, not a tracked balance
There is no separate work-in-process ledger to keep in sync. WIP for a work order, item, and piece of equipment is consumed quantity minus produced quantity, computed on request from the same consumption and production records above, and rendered at /mes/wip.
Regulatory mapping
| Standard | Clause | Qontiv feature |
|---|---|---|
| ISO 13485 | §7.5.9 | Traceability — lot/serial genealogy and independent serial disposition |
| IATF 16949 | §8.5.4 | Preservation — status-gated availability keeps blocked stock out of allocation |
| 21 CFR Part 11 | §11.10(e) | Immutable transaction ledger with a time-stamped audit trail |
Qontiv is designed for compatibility with these standards and supplies the traceability records an auditor asks for. Qontiv itself is not certified to any of them.
Scope — what this does and does not do
- No cycle-count workflow. There is no count sheet, count session, or blind-count feature. A physical count is posted as an ordinary inventory adjustment tagged with the seeded "Cycle-Count" reason code.
- Storage locations are a free-text hierarchy, not an enforced warehouse/zone/bin structure. You can model that pattern; Qontiv does not require it.
Availability
Inventory and WIP tracking, with full lot and serial genealogy, is included starting atCore. See pricing for the full tier ladder, orrequest a demo to walk your own lot and serial model through it.
Know what is actually available. Not what you think is.
One availability formula, allocation drift detection that never guesses, and computed WIP.