iVendNextDevelopers Request a sandbox

S5 — the configuration pack: reasons, IMEI, a line detail, member pricing

What the cashier meets once the pack is applied: member price, reasons, a line detail, an IMEI, a void reason

What the cashier meets once the pack is applied: a member's price, a reason for a markdown, a checked line detail, a phone's IMEI and a reason for a void.

Nothing here is code. The pack switches on what iVendNext already has: the till asks for and keeps a coded reason, tracks a phone by its IMEI, captures one more detail per line, and prices members differently. It is for an iVendNext Partner or a shop's administrator who wants that set-up as one data file they can apply, test and repeat on the next shop.

Configuration only, applied by a script over the record API and written up as a recipe: recipes/configure_no_code.md.

When to use it: what the shop needs is already in iVendNext and only has to be switched on and filled in.

What it looks like

The customer, the item and the reasons are the sample's own (PP CFG …, in config.json). The sale was voided at the end, so nothing was sold.

Step Frame Screenshot
1. The gold member's 10% (a promotion for the member group): R 229.90 off the basket, in the totals the till, 1440 wide
2. A 10% markdown on the phone asks for a reason; price match also asks for a comment the till
3. The line detail Warranty card refuses a value that does not match its pattern (WC- and eight digits) the till
4. The phone's IMEI, captured before it can be charged the till
5. A void asks why, and keeps the voided sale on record the till

The files

File What
config.json the whole set-up as data: five reason codes and their switches · one IMEI-tracked item with three IMEIs · a line detail with a pattern · a member tier
apply_config.py applies it (idempotent) · --remove undoes it · standard library only

Run it

PP_BASE=https://shop.example PP_KEY=<api key> PP_SECRET=<api secret> python3 samples/s5_config_pack/apply_config.py

Run it twice and nothing doubles. Add --remove to undo it.

Before you build on it

Technical notes

The walk

The GIF: nothing here is code: after apply_config.py, the till itself gives the gold member their price, asks for a reason (and a comment) on a markdown, checks a line detail against its pattern, asks for the phone's IMEI, and asks why a sale is voided. Frame: the till (/pos?frame=terminal, 1440 wide). Walked on our test bench on 2026-10-07, iVendNext POS app at 8dc36aab8. Built from the same screens as the stills below; every frame is cut above the till's key row.

The cashier is the bench's Thabo Nkosi; the customer, the item and the reasons are the sample's own (PP CFG …, in config.json).

The tests

File What
our test bench's own run (not in the kit) the bench tests: read back, till sales through the till's own calls, apply twice, remove

Why this way (R6)

A script over the record API reading one JSON file (picked: ~170 lines; any shop's administrator reads it; the same file is the documentation) · clicking it through in Desk (rejected: nothing to test, nothing to repeat on the next shop) · a manifest (rejected: a manifest may not touch the shop's own settings or its stock).

Not used, because it would need an extension point that has not shipped

Hiding or requiring a till field (P-FIELDS), a rule that refuses a wrong detail on save (P-RULES), a wallet or a card check (P-WALLET, P-CARDSET). The member discount is the promotion engine's, not a pricing rule (selling pricing rules are refused at this pin).

This page in the kit