The IMEI of every phone sold, once

The customer asks: Record the IMEI of every phone sold, and never sell one twice

• Verdict: Ready, with limits (2)
• Door: Configure · area: Stock and buying › Handheld and scanning
• Recipe: Set a shop up with no code
• Sample: S5 — the configuration pack: reasons, IMEI, a line detail, member pricing
• Checked: carried 2026-10-15 · not re-run

What you build

The item's Has Serial No: the IMEI is the serial number, received with the stock. The shop needs a default Company.

Limits

• A phone that also has a batch (a lot): until POS LANE X row X57, P-SERIALUNITS (one row per serial with its own batch at the till), merges, the till sells reliably only from the lot iVendNext picks first (sample S30).
• Offline: not run.

Tell the customer

The till asks for the IMEI of each phone sold and refuses one already sold.

What next

1. Tell the customer the 2 limits above, and write them into the proposal.
2. Follow the recipe: Set a shop up with no code.
3. Copy the sample: S5 — the configuration pack: reasons, IMEI, a line detail, member pricing, and change it.
4. Build and test it on your sandbox (request one if you have none; what is on it).
5. 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).
6. 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

• A coded reason when a cashier voids, returns or discounts — Ready, with limits (3)
• Members pay less, by tier — Ready, with limits (5)
• One more detail on a line, for goods with no serial number — Ready, with limits (2)
• Check a product's warranty at the till — Ready, with limits (3)

Start a project shortlist with this need · Put it in your blueprint · Every need

This card in the kit