Every pack's own code checked on every stock document
The customer asks: Each pack carries its own printed code; check it when stock is received, moved, counted and sold, and tell a lost pack from a sold one
- Verdict: Ready, with limits (8)
- Door: Configure · area: Stock and buying › Batches and expiry
- Recipe: S30 — Units as serial numbers: each pack's printed code, tracked by iVendNext itself
- Sample: S30 — Units as serial numbers: each pack's printed code, tracked by iVendNext itself
- Checked: run on a sandbox 2026-10-16 · POS 2.0.0.650 · received by paste and CSV, transferred, sold, refused sold again, returned, counted with one missing, refused in Defective, the report, the migration's dry run; not run: the migration's apply, the current undo, an issue, a resale after a return, offline, a Purchase Receipt
What you build
Configuration: each code is a serial number of an item with both batches and serial numbers, and no Serial No Series. Sample S30 adds the set-up script, a migration from a unit table of your own, and a report that tells a counted-out unit from a sold one.
Limits
- At the till, a unit sells reliably only from the lot iVendNext picks first (expiry or first in); a unit from another lot is refused at payment, until POS LANE X row X57, P-SERIALUNITS (one row per serial with its own batch at the till), merges.
- A count marks the units it did not find Delivered, as a sale does: the sample's report tells them apart.
- Defective is a store, not a status; the till refuses a unit there as another store's.
- An item that already has stock cannot be switched to serial numbers: the units move to a new item.
- Issued and counted-out codes can be received again; a code sold at the till and received again by a receipt, not a return, stays refused at the till.
- Till sales read Active until the day's sales are posted; a site needs a default Company.
- A later version of iVendNext names a serial number by a generated name: the sample's lookups by name then read the code field instead.
- Offline: not run (the cashier scans the item, then the code as its serial).
Tell the customer
Every pack's code is checked by iVendNext on receipts, transfers, counts, sales and returns; at the till, until an update we have planned, a pack from a lot other than the one iVendNext picks first is refused at payment.
What next
- Tell the customer the 8 limits above, and write them into the proposal.
- Start from: S30 — Units as serial numbers: each pack's printed code, tracked by iVendNext itself.
- Copy the sample: S30 — Units as serial numbers: each pack's printed code, tracked by iVendNext itself, and change it.
- Build and test it on your sandbox (request one if you have none; what is on it).
- Check it on your sandbox as the people who will use it; where it touches a price or a total, the money kit's release gate proves it (testing and release).
- Make the same settings on the customer's site, from the list you wrote down, through the customer's own change process.
Nothing to code: write down each setting you make on your sandbox, so it is made the same way on the customer's site.
Related needs
- Scan a unit's own barcode or a handset's tag, and refuse a unit already sold — Ready, with limits (3)
- Record the IMEI of every phone sold, and never sell one twice — Ready, with limits (2)
- Read a pharmacy pack's 2D code at the scan, and refuse an expired pack — Ready, with limits (2)
- The till sells the batch that expires first — Ready, with limits (5)
Start a project shortlist with this need · Put it in your blueprint · Every need