All needs

Every card in full, by area, for your browser's find. The catalogue · the A to Z list.

Prices and promotions

A coloured row for products on promotion in the Desk list

A coloured row in the Desk product list for the products on promotion — Not yet · Request · the card

What you build. Nothing yet: the Desk list colours a row only from the record's own status, and the item has none.

Limits.

• A field of your own cannot take the place of a status, and a manifest cannot add a workflow to a shop's own record types (chapter 7); a workflow set in Desk was not run.
• Today (not run) the filter and the saved view of the card products-on-promotion-filter list the same products.

Tell the customer. The Desk list cannot yet colour the products on promotion; it can filter and list them.

Filter the product list to products on promotion

Filter the product list to the products on promotion — Ready, with limits (3) · Outside app · the card

What you build. A check field of your own on the item, kept current by an outside app that reads the active promotions; the Desk list filters on it, and a saved view or a report shows it.

Limits.

• The flag lags a promotion's start and end by the app's schedule.
• On the till a field rule can show the flag, within the three more item fields it allows.
• A coloured row in the Desk list has no door today (the card products-on-promotion-colour).

Tell the customer. The product list filters to what is on promotion, updated each time our app runs.

A discount the promotions cannot express

A member rate that multiplies with a promotion, taken after it — Ready, with limits (5) · Sandboxed function · the card

What you build. Your sandboxed module takes money off a line after every promotion, on the server and on the till offline.

Limits.

• Installing the certified module on a shop, step by step: recipes/configure_no_code.md, A member rate after the promotions.
• It runs only once CitiXsys has certified your module, the shop's administrator has added it in Desk, and the shop has raised its limit above 0.
• It is never offered a line a pricing rule has already priced, a return or a gift-card line.
• The Desk POS does not run it: a sale rung there is priced without your module.
• A function that runs on a till is compiled from Rust; one that runs only on the server may be JavaScript.

Tell the customer. The extra rate is applied after the promotions, on the till too, once our certification and the shop's own limit allow it.

A member price for each customer tier

Members pay less, by tier — Ready, with limits (5) · Configure · the card

What you build. One Customer Group per tier and one promotion per tier; each tier's promotion excludes every other group, non-members included. Works offline for a member on the till's offline customer list.

Limits.

• A promotion cannot be aimed at a group, only exclude groups: a group added later gets every tier's discount until the set-up script (apply_config.py) runs again.
• A customer with no customer group gets the member discount: give every customer a group, and set Selling Settings → Default Customer Group to a non-member group (without it, a customer made at the till can land in a member tier).
• Use lowest-level groups only: a customer in a group that has groups under it is never excluded.
• The member discount is on the whole sale, not on each line, and only one sale-level promotion applies.
• Lines already discounted are left out; a cashier's sale discount replaces the member discount (from the code; not walked).

Tell the customer. Each tier gets its own price through a promotion; every customer needs a group, and the discount shows on the sale's total.

Prices, promotions and coupons

Our prices, promotions and coupons — Ready, with limits (3) · Configure · the card

What you build. Set up in iVendNext Desk: price lists, promotions and coupons. No code.

Limits.

• Combined discounts follow the promotion rules.
• Offline, pricing rules are not applied.
• A coupon or promotion row naming a parent item group matches only items placed directly in it. Sample S31's service writes a coupon's get rows and a promotion's exclusion rows out as the child groups; a promotion's buy and get rows are reported, never changed, as a child row there would change the offer.

Tell the customer. Prices, promotions and coupons are set up in iVendNext; how discounts combine follows its promotion rules.

A price checker on the shop floor

A price checker shoppers use on the shop floor — Ready, with limits (1) · Outside app · the card

What you build. A page your app serves on a screen in the store, reading items and prices over the API.

Limits.

• It reads only, and shows nothing a shopper could not see.

Tell the customer. Shoppers scan an item at the checker and see its price.

A price list with a photo for each item

A price list as a document with a photo for each item — Ready, with limits (4) · Outside app · the card

What you build. A small outside program makes a page that prints to PDF, and a spreadsheet file, for each distributor from the price list and the items' images (the sample's catalogue.py).

Limits.

• Photos must be kept in the shop: attach the file to the item and set its Image field (a PNG, JPEG, GIF or WebP up to 800 kB); any other item gets a grey box and is reported.
• General prices only: a price made for one customer, supplier or batch is skipped, so a list for one distributor is that distributor's general list; disabled items are left out.
• The page is a file made on demand, not a live view: run it again when prices or photos change.
• A print format on the price list is not offered: a kit template cannot read the price rows; ask for P-TEMPLATEHELPERS (readers under an iVendNext name).

Tell the customer. Each distributor gets a price list with a photo of each item, made by our app from the shop's own prices and images.

An extended warranty sold as an item

Sell an extended warranty with a product — Ready · Configure · the card

What you build. The extended warranty is an item with its own price, sold on the same sale.

Limits. None known.

Tell the customer. The extended warranty is sold as its own line on the sale.

A price list worked out from another

A selling price list worked out from another (a multiple of the buying list, wholesale as a share of retail) and kept in step — Ready, with limits (7) · Outside app · the card

What you build. An outside app follows price changes on the event feed and writes the derived list's item prices through the record API, by a rule the shop keeps: a factor, an offset, a rounding step and a floor.

Limits.

• The new price arrives seconds after the source is saved (14 seconds on a sandbox; about a minute at worst when the shop's background worker is busy, chapter 5); a sale in those seconds is priced at the old one, and a till takes the new price at its next sync.
• A price a person set on the derived list, or changed there after the app wrote it, is kept and listed, never overwritten; a list that already has prices keeps them, so derive into a new list or end those prices first.
• Only prices for everyone are derived: a price for one customer, one supplier or one batch is left alone.
• Both lists are in one currency, and one list is written by one rule; a loop of lists is refused.
• A promotion or a member discount still applies on top, as always.
• Run one copy of the app per shop.
• The price list record has no formula field (read on a sandbox), and a selling pricing rule is refused (chapter 4), so this is an app, not a setting.

Tell the customer. The derived list follows its source within seconds of each change (about a minute at worst on a busy shop), by the formula, rounding and floor you choose; a price someone sets by hand on it is kept, and the nightly check lists it.

A fee or surcharge added to a sale

A surcharge added to the sale because of the payment method or a condition — Not possible · None · the card

What you build. Nothing: money may never change after the cashier has seen the sale (rule 1, chapter 3).

Limits.

• Instead: put the fee on the sale as an item the cashier adds before payment; a check before payment can refuse the sale, with your sentence, until that line is there (not run; not yet in the guide).

Tell the customer. A fee cannot be added by the system after the sale is shown; it can be a line the cashier adds before payment.

Stock and buying

Your own behaviour inside Handheld

Add our own step or screen to Handheld — Not yet · Request · the card

What you build. Nothing inside Handheld: it has no extension point today.

Limits.

• Today: react to what Handheld books, through the API and the event feed.
• Ask us: the step you need in Handheld.

Tell the customer. Handheld cannot be extended yet; we can react to what it books.

Alerts before expiry and below the minimum, and a draft transfer request

Alerts before expiry and below the minimum stock, and a draft stock transfer request made from them — Ready, with limits (7) · Outside app · the card

What you build. An outside app on a schedule reads stock, reorder rows and batches over the record API, writes each alert on a record type of your own (a manifest notification announces it), and makes one draft transfer request per store and day.

Limits.

• The standard automatic reorder submits the request, never a draft (run, card low-stock-reminder): a draft needs this app.
• A manifest's notification cannot run on a shop's own record, such as a batch (chapter 7), so the alert is a record of your own and the notification is on that; the shop's administrator can set a notification on a batch in Desk (the card expiry-alert-before-date).
• A transfer request has no batch column and holds an item once (run: a second row of one item was refused): batches of one item share a line whose description names them; an item low and near expiry in one store the same day gets one line (not run).
• A batch's quantity per store is read from its stock movements' batch records; with no right to read them the alert says the batch's total and makes no line.
• The shop's built-in Administrator is never told by role: give the alerts role to named people (run).
• A draft reserves nothing; once a person submits it, the projected stock counts it and the item stops being low (run).
• The reports Stock Projected Qty (switched off on both sandboxes) and Batch Item Expiry Status are not used: the sample reads records only.

Tell the customer. You get an alert before stock runs low or a batch expires, and a draft transfer request that a person approves before it becomes a real one.

A branch sees its own store's stock and the head office's

A branch sees the stock of its own store and the head office's, no other — Ready, with limits (4) · Configure · the card

What you build. A User Permission on Warehouse for each store a user may see, their own and the head office's, set in iVendNext Desk.

Limits.

• With one permission, the Bin, Stock Ledger Entry and Warehouse lists, and the reports Stock Balance (also with another store chosen), Stock Ageing by store, Stock Ledger, Total Stock Summary and Warehouse Wise Stock Balance, showed that store only (run).
• Three reports showed other stores to the same user (run): Item Balance (Simple) and Warehouse wise Item Balance Age and Value showed every store, and Stock Ageing in its default layout showed the stock of every store, and of any store chosen in its filter. Test each stock report a branch may open, in each layout, and take away the ones that leak.
• A user with two permissions (own store and head office) was not run; nor were the other stock reports.
• At the till the Other stores stock panel shows every store or none, never own and head office (from the product's code, not run): ask for P-STORESCOPE.

Tell the customer. A branch sees its own store's stock in the lists and in the reports we tested; some stock reports must be taken away from it, each one tested first, and the till's stock panel shows every store or none.

Every pack's own code checked on every stock document

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 — Ready, with limits (8) · Configure · the card

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.

The list of stock counts with quantity, difference and stock value

The list of stock counts showing the quantity, the difference and the stock value — Ready, with limits (4) · Outside app · the card

What you build. The difference is a column of the list, by configuration. Totals of the item rows are a prefixed field on the document, filled by an outside app after each save, or a report the user builds in Desk.

Limits.

• The header holds the difference amount only; quantity and stock value are on the item rows (read on a sandbox).
• A save rule cannot sum the rows (a rule never writes quantity or money): ask for P-RULES3.
• A manifest cannot declare a report with columns from the item rows (its checker takes plain field names); Desk's report view accepted them, but a sum grouped by document was refused and no rows were seen: test it on the customer's data, and ask for P-REPORTCOLS.
• Totals appear after the save, not while the user types.

Tell the customer. The count list shows the difference as it stands; totals of quantity and value appear a moment after each save, or, once tested on your data, in a report in Desk.

Merge several count documents into one

Merge several stock counts into one — Ready, with limits (5) · Desk action · the card

What you build. A desk action on the count list: the ticked rows go to your service, which re-reads them and writes one merged draft through the record API.

Limits.

• Drafts only: the shop refuses a submitted or cancelled count before your service is called (run). The list allows 100 per press, but each is read and commented inside Desk's 10 seconds: keep it to a handful.
• The rule for the same item in the same warehouse (add them, or the latest count's) is the customer's, kept in a settings record; the valuation rate, posting date and posting time are the latest count's (run).
• The source counts stay drafts with a comment merged into ⟨name⟩: cancel or delete them, or the stock is counted twice (run).
• A row with serial numbers, or with its batch or serials in a bundle, refuses the merge (laptop only).
• Desk waits at most 10 seconds: a merge of two counts took 5.3 to 5.7 seconds with the service far from the shop; run it near the shop. A retry from the same dialog finds the draft already made (run), unless the shop saved it after the service stopped waiting: then look for a second draft.

Tell the customer. Several counts become one draft that a person checks before it is submitted; a submitted count is left alone.

A notification a number of days before a date on a shop's record

A notification a number of days before a date on a shop's own record, such as a batch's expiry — Ready, with limits (2) · Configure · the card

What you build. A notification in iVendNext Desk, of the kind Days Before, on the batch's expiry date, set by the shop's own administrator; the system notification or e-mail goes to a role.

Limits.

• It is set in Desk, one shop at a time: a manifest cannot ship a notification on a shop's own record (chapter 7), so a partner who wants it installed for many shops asks for P-NOTIFYDATE, or sets it with the shop's administrator.
• It was saved on a sandbox but never fired (the site has no batch with an expiry date), and a batch with no expiry date raises nothing.

Tell the customer. The shop's administrator can set a notification a number of days before a batch expires; we have not yet watched one fire.

A pharmacy pack's 2D code read at the scan

Read a pharmacy pack's 2D code at the scan, and refuse an expired pack — Ready, with limits (2) · Scan source · the card

What you build. The till reads the pack's GS1 code (item, batch, expiry, serial) at the scan. It is data: no code runs.

Limits.

• GS1 codes: not run in the kit (the product's own tests cover them).
• A pack's own serial checked on Desk documents too (receipt, transfer, count): the card units-as-serial-numbers, sample S30; at the till only from the lot iVendNext picks first until POS LANE X row X57, P-SERIALUNITS (one row per serial with its own batch at the till), merges.

Tell the customer. The till reads the pack's code, finds the batch, and refuses an expired pack.

Receiving and stock counts on Handheld

Receive goods and count stock with a handheld scanner — Ready, with limits (3) · Configure · the card

What you build. Handheld, our app, set up for the stores.

Limits.

• Handheld books online only: receiving and counts need a connection.
• A count has no in-app approval step.
• Handheld offers no extension point.

Tell the customer. Stores receive and count on Handheld while it is online.

The IMEI of every phone sold, once

Record the IMEI of every phone sold, and never sell one twice — Ready, with limits (2) · Configure · the card

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.

A reminder for each store when stock is below its level

A reminder per store when its stock falls below a set level — Ready, with limits (4) · Configure · the card

What you build. Item Reorder rows on the item (the store, the level, the quantity, the type Transfer or Purchase) and the setting for automatic requests in Stock Settings; the standard job makes the request.

Limits.

• The request is submitted, never a draft (run: type Transfer made a submitted Material Transfer request, status Pending); for a draft see the card stock-and-expiry-alerts.
• Leave the row's warehouse group empty: with a group named, the level is compared with the whole group's stock and a store below its level was not reordered (run).
• The job runs once a day over the whole site, only while the automatic-request setting is on (it is off until someone switches it on: read on the sandbox); it covers every item with a reorder row.
• The quantity requested is the reorder quantity, or the shortfall when that is larger, and it compares projected stock, so an open request or an incoming order delays the next one (read from the code).

Tell the customer. Each store's low stock comes as a transfer request, raised once a day; it is a real request, not a draft.

A unit's own code recognised at the scan

Scan a unit's own barcode or a handset's tag, and refuse a unit already sold — Ready, with limits (3) · Scan source · the card

What you build. The shop declares a table of its units' own codes; the till's scan finds the unit, its batch and serial, and refuses one already sold. It is data: no code runs.

Limits.

• A unit sold on another till a moment before: not run in the kit (the product's own tests cover it).
• When the code must be checked on Desk documents too (receipts, transfers, counts), make it a serial number instead: the card units-as-serial-numbers, sample S30. This card's scan source stays for codes a shop keeps in its own table.
• POS LANE X row X57, P-SERIALUNITS (one row per serial with its own batch at the till) makes a batch-and-serial unit reliable at the till; until it merges, a unit sells reliably only from the lot iVendNext picks first.

Tell the customer. Scanning a unit's own code finds that exact unit, and a unit already sold is refused.

First-expiry-first-out at the till

The till sells the batch that expires first — Ready, with limits (5) · Configure · the card

What you build. Nothing of yours: switch batch tracking on for the item (card batches-and-expiry). At the batch pick the till lists the item's lots with the earliest expiry first, lots with no expiry last and empty lots at the bottom, and proposes the earliest-expiry lot or lots for the quantity, splitting across lots when one is short for a line in the stock unit (list_lots, business_logic/serial_batch.py).

Limits.

• The cashier confirms the pick: a proposal, not an assignment. The server checks the pick again at checkout and refuses one that does not add up to the quantity.
• A line sold in a pack unit takes one lot for the whole line: the earliest lot that holds it, or none.
• The order is by expiry date alone. It does not follow the shop's Stock Settings choice of first-in or first-expiry; a till that assigns lots by itself in that order is a product decision, not a door (ask us if the customer needs it).
• For an item that has both batches and serial numbers, the core's automatic pick of the first-in lot can override the proposal until POS LANE X row X57 merges; test that shape first.
• Offline, a batch line is added without a pick (read in the till's code, not walked).

Tell the customer. At the batch pick the till suggests the lot that expires first, and the cashier confirms it.

Batches and expiry dates

Track batches and their expiry dates — Ready · Configure · the card

What you build. Batch tracking on the item, set up in iVendNext Desk.

Limits. None known.

Tell the customer. Each batch and its expiry date is tracked from receipt to sale.

Customers and loyalty

A customer's recent visits on the till

A customer's shopping history or trend on the till: recent visits, the store, who served and the discount on each — Ready, with limits (5) · Partner page · the card

What you build. A partner page, opened by a till key with the customer on the sale (or in Desk for a customer); your server reads the sales over the record API and shows who served and the discount on each.

Limits.

• The till's own customer card already shows, read from the code at the pinned build and not run on a site: name, phone, e-mail, member since, credit limit and balance, lifetime spend, visits, what they buy, loyalty and the last 10 sales, each with its number, date, first item, store, amount, whether a return and its mode.
• It does not show who served or the discount on each sale: your page adds them, read from the sale records (run on a sandbox).
• The sales come from till sales and non-consolidated Desk sales; the day's roll-up invoice is skipped, or each sale shows twice (Desk sales and a hand-made roll-up run on a sandbox; till sales and a roll-up made by a till's closing: laptop only).
• Online only; the cashier presses the key; a customer and an item must be on the sale. A default walk-in customer on every sale opens the page for the walk-in.
• The app's key reads every sale and every user's full name; the built-in Administrator's name is not readable (run).

Tell the customer. The cashier sees a customer's recent visits, with who served and each discount, on a page opened by a key on the till; it needs a connection.

Loyalty with iVendNext's own programme

Customers earn and spend loyalty with iVendNext's own programme — Ready, with limits (1) · Configure · the card

What you build. Our loyalty, set up in iVendNext. The kit has no recipe for it.

Limits.

• Offline, loyalty waits for a connection.

Tell the customer. Loyalty works on every till that is online.

A store wallet or a loyalty points balance spent at the till

Customers spend their cash back, store credit or loyalty points balance at the till — Ready, with limits (2) · Wallet · the card

What you build. Your service keeps the balance; the till asks it what this sale may use, takes it as a payment method, and gives it back to the same wallet on a return.

Limits.

• Online only: the wallet is never offered on an offline till.
• When your service is down, the till says it did not answer and the cashier takes another payment.

Tell the customer. Customers pay with their balance at the till while it is online; a return gives the money back to the same wallet.

Loyalty earned in the customer's own programme

Every booked sale earns loyalty points in our own programme — Ready, with limits (2) · Outside app · the card

What you build. The customer's service reads each booked sale from the feed and credits its own ledger; the ledger may live in iVendNext as your manifest's records.

Limits.

• The kit's samples read the shared feed, whose key is not limited to one app (a feed scoped to your app is an extension point, chapter 9).
• Loyalty points are credited when the service is back: a sale waits in the feed while it is down.

Tell the customer. Each booked sale earns in your own programme, shortly after it is booked.

A new customer's phone or e-mail made required

Every new customer must give a phone number or an e-mail — Ready, with limits (2) · Field rules · the card

What you build. A field rule, set in POS Studio's Fields tab or declared in a manifest, requires the field when the till makes a customer; the server holds it where it writes.

Limits.

• Required only when the till itself makes the customer: one made in Desk, by an import, through the record API or by another app is not checked.
• Offline, a customer added without the field is still made when the sale drains, and the Sales to review report lists it.

Tell the customer. The till asks every new customer it makes for the phone or e-mail; customers made elsewhere are not checked.

A customer's past sales, found by their phone number

Find what a customer bought before by typing their phone number — Ready, with limits (3) · Partner page · the card

What you build. Two routes that exist today. At the till, the no-receipt return search takes a phone number in any written form and lists that customer's recent sales in the stores it reaches. For more than the till shows (who served, each discount), the customer-history page of sample S28, opened by a till key or from the customer in Desk.

Limits.

• The till's search is the elevated no-receipt lookup: it needs the elevated right or a manager's approval, so it is not every cashier's screen.
• The till's search looks back 30 days and lists up to 200 customers' matches (LOOKUP_WINDOW_DAYS, LOOKUP_MATCH_CAP in the product's returns.py); it is for a return, not a general search screen. Read in the code, not run.
• S28's page needs a connection and a customer on the sale (or open in Desk); see the card customer-history-on-till for its limits.

Tell the customer. A manager or a cashier with the right finds a customer's recent sales by phone at the till, and a key opens a page with the longer history.

A gift card for a big spend

A gift card for a spend over a threshold, spendable after a hold — Ready, with limits (5) · Outside app · the card

What you build. An outside app reads booked sales from the feed and issues the shop's own gift card, released after the hold.

Limits.

• The card is made after the sale, not on its receipt.
• A return without the receipt names no sale, so it voids nothing.
• The hold runs from the card's issue.
• The kit's samples read the shared feed, whose key is not limited to one app (a feed scoped to your app is an extension point, chapter 9).
• Offline, gift cards wait for a connection: the card cannot be spent on an offline till.

Tell the customer. A qualifying sale earns a gift card shortly after it is booked; it can be spent once the hold is over.

A one-time code before a new customer is made

A one-time code sent to the customer before a new customer is made at the till — Ready, with limits (2) · Capture on an event · the card

What you build. Your service is asked when a new customer is added; it sends a one-time code, and the server checks the code before the customer is made.

Limits.

• New customers only: there is no door yet when an existing customer is chosen (the card question-on-existing-customer).
• Three wrong codes end the check, and a code lives ten minutes.

Tell the customer. A new customer is made only after they read back the code sent to their phone.

The customer's own CRM kept up to date

Our CRM sees our customers and their sales — Ready, with limits (2) · Outside app · the card

What you build. Your outside app reads customers and sales over the API and the feed and writes them to the CRM.

Limits.

• The kit's samples read the shared feed, whose key is not limited to one app (a feed scoped to your app is an extension point, chapter 9).
• The feed reports a change after it is saved, so your app corrects after the fact.

Tell the customer. The CRM receives customers and sales shortly after they are saved.

A question when an existing customer is chosen

A question or a check when the cashier picks an existing customer for the sale — Not yet · Request · the card

What you build. Nothing yet: capture on an event asks when a new customer is added, not when an existing one is chosen.

Limits.

• Today the check before payment can refuse the sale at Pay.

Tell the customer. The till cannot yet ask when an existing customer is chosen; it can stop the sale at Pay.

A member's status at the till

Show the member's tier and status when the cashier asks — Ready, with limits (2) · Till key · the card

What you build. A till key answered by the customer's own service, with a message the cashier reads.

Limits.

• Till keys answer online only: the key is dimmed on an offline till.
• The key's request carries no money and no serial numbers: read them from the booked sale, after it is booked.

Tell the customer. The cashier presses a key to see the member's status, while the till is online.

Till controls and approvals

A value asked for at the till

An answer for the cashier during the sale: a message, or a seal number, a reference or a warranty card number added to the sale — Ready, with limits (3) · Till key · the card

What you build. A key on the till calls your service; your answer is a message, details added to the sale, values for its lines, or any of them together.

Limits.

• The cashier presses the key: nothing makes the cashier press it.
• Till keys answer online only: the key is dimmed on an offline till.
• The key's request carries no money and no serial numbers: read them from the booked sale, after it is booked.

Tell the customer. The cashier presses a key to record the value on the sale. It is not forced, and it needs a connection.

A beep and a question when a flagged item is scanned

A beep and a yes-or-no question when the cashier scans an item we flagged — Ready, with limits (2) · Capture on an event · the card

What you build. Your service is asked when an item your filter names is scanned; it answers with a beep and a question, a refusal, or values for the line.

Limits.

• Online, your service answers. Offline, the answer you declared applies to the items ticked at the start of the day.
• POS LANE X row X60, P-CAPTURE4 (a notice at the scan) adds an answer that shows your sentence and adds the item with no question; today the cashier answers once.

Tell the customer. Scanning a flagged item makes the till beep and ask the cashier your question before the line is added.

Blind till counts for cashiers

Cashiers count the drawer without seeing what the till expects — Ready · Configure · the card

What you build. A setting in iVendNext Desk (chapter 4). The kit has no recipe for it yet.

Limits. None known.

Tell the customer. Cashiers count the drawer at the close without seeing the expected figure.

A change to the order of the till's steps

Change the order of the till's steps, or what every cashier sees — Not yet · Request · the card

What you build. Nothing a builder can do: the till's steps are the product's.

Limits.

• Ask us: the change to the till's steps, with the reason; it is product work, not an extension point.

Tell the customer. The order of the till's steps is the product's; we can take the request.

A warranty check at the till

Check a product's warranty at the till — Ready, with limits (3) · Till key · the card

What you build. A till key calls your service with the sale's lines; your service answers with the warranty, as a message the cashier reads.

Limits.

• Till keys answer online only: the key is dimmed on an offline till.
• When your service is down, a press tells the cashier it could not finish, nothing is added, and the sale goes on.
• The key's request carries no money and no serial numbers: read them from the booked sale, after it is booked.

Tell the customer. The cashier presses a key to see the warranty for the items in the sale, while the till is online.

A coded reason for a void, a return or a discount

A coded reason when a cashier voids, returns or discounts — Ready, with limits (3) · Configure · the card

What you build. Reason Code Master rows and the switch for each type in Retail Setting (a void reason also needs save_voided_transaction).

Limits.

• The till asks for the reason, but the server does not insist: a sale discount with no reason code still books.
• Item-return and sale-return reasons: not run.
• Offline: not run.

Tell the customer. The cashier picks a coded reason for each void, return and discount, and the reason is kept on the sale.

A coupon for a first purchase only, or for one customer group

A coupon only a new customer may use, or only customers of one group — Ready, with limits (6) · Check before payment · the card

What you build. Your service answers the check before payment. The shop keeps one rule per coupon; the service refuses the coupon when the sale's customer has bought before (a first-purchase coupon) or is not in the coupon's customer group.

Limits.

• Answered when the cashier presses Pay, not when the coupon is entered.
• Offline, the till does not ask the service: the coupon applies and the sale is flagged when it syncs.
• The check does not run on a park to a till, a layaway deposit, an account collection or the Desk's own POS screen: a restricted coupon there is neither refused nor flagged.
• The count is taken at the check: a sale for the same customer booked after the check and before the money is not seen.
• A customer group matches exactly: a group under it is not the same group.
• The app's user needs a plain read on the shop's sales and no User Permissions, or a returning customer can pass as new.

Tell the customer. A restricted coupon is refused at Pay with the reason; the cashier removes it and the sale goes on.

A cap on what a coupon or a loyalty points balance may pay

A coupon or a loyalty points balance pays no more than part of the sale — Ready, with limits (1) · Check before payment · the card

What you build. Your service answers the check before payment and refuses, or leaves out the payment method, when the coupon or balance would pay over the cap. For a wallet you run yourself, the wallet's own answer carries the cap (the card store-wallet-at-till).

Limits.

• Answered when the cashier presses Pay, not when the line is entered.

Tell the customer. The till stops a coupon or a loyalty balance from paying more than the agreed share, at Pay.

Your own screen on the till or in Desk

A delivery partner's screen, or any screen of ours, opened from a key on the till — Ready, with limits (1) · Partner page · the card

What you build. Your own page, framed on the till or in Desk, told who is looking at what by a signed context.

Limits.

• On the till it answers the till once.

Tell the customer. Your screen opens inside the till or Desk; on the till it can send back one answer.

A discount above a limit needs a manager

A discount above a set limit needs a manager's approval — Ready, with limits (2) · Check before payment · the card

What you build. Your service reads the sale's discounts in the check before payment and answers approve when one is above the limit.

Limits.

• Answered when the cashier presses Pay, not when the line is entered.
• A manager who is not the cashier signs in on the till to approve. Approval by e-mail has no door.

Tell the customer. A discount above the limit waits at Pay until a manager approves it on the till.

An insurance co-payment at the till

Insurance co-payment: the insurer pays part of a prescription and the customer the rest — Not yet · Request · the card

What you build. Nothing a builder can do: it is part of our pharmacy pack.

Limits.

• Ask us: our pharmacy pack's co-payment.

Tell the customer. Co-payment comes with our pharmacy pack.

A manager's approval for a large sale

A manager must approve a sale over a set amount — Ready, with limits (2) · Check before payment · the card

What you build. Your service answers the check before payment with approve when the sale is over the amount; the till asks a manager before it takes payment.

Limits.

• Answered when the cashier presses Pay, not when the line is entered.
• A manager who is not the cashier signs in on the till to approve. Approval by e-mail has no door.

Tell the customer. A sale over the amount waits at Pay until a manager signs in on the till and approves it.

The next sale keeps the previous sale's sales person

The next sale starts with the sales person of the last completed sale, splits included — Not yet · Request · the card

What you build. Nothing a builder can add: the shop has no setting that keeps the last sale's sales person. A product decision for the iVendNext team.

Limits.

• Ask us: a Retail Setting that carries the last completed sale's sales person (and splits) into the next sale.
• Today the sale starts with the cashier, then the profile's default seller, and the cashier changes it. Try on a sandbox (not run): add the cashier as the sales person by default, or have the seller scan a badge at tender.

Tell the customer. The till does not remember the last sale's sales person yet; the cashier changes the default at tender, and the setting is a product decision.

No line sold at a placeholder price

No line at a placeholder price such as 0.01 — Ready, with limits (1) · Check before payment · the card

What you build. Your service answers the check before payment and refuses a sale while any line carries the placeholder price, with your own sentence.

Limits.

• Answered when the cashier presses Pay, not when the line is entered.

Tell the customer. A sale with a line at the placeholder price cannot be paid; the cashier is told to correct the price first.

A limit on the quantity of one item on a line

No more than 50 of one item on a line — Ready, with limits (1) · Check before payment · the card

What you build. Your service answers the check before payment and refuses a sale with a line over the limit, in your own sentence. The limit lives in one settings record the shop edits.

Limits.

• Answered when the cashier presses Pay, not when the quantity is typed.

Tell the customer. The till stops the sale at Pay when a line is over the limit and tells the cashier why. It does not stop the quantity being typed.

A limit on the number of lines in one sale

No more than a set number of lines on one sale — Ready, with limits (1) · Check before payment · the card

What you build. Your service counts the sale's lines in the check before payment and refuses a sale over the limit, with your own sentence.

Limits.

• Answered when the cashier presses Pay, not when the line is entered.

Tell the customer. A sale with too many lines is stopped at Pay, with the reason; the cashier splits it.

No more than so many manager approvals for a discount per store per day

No more than so many manager discount approvals per store per day — Ready, with limits (3) · Check before payment · the card

What you build. Your service counts approvals for each store and day in the check before payment: it answers approve until the limit is reached, then refuse. Count a sale once, not each time it is asked.

Limits.

• Answered when the cashier presses Pay, not when the discount is typed. The check is asked again for the same sale when the basket changed or Pay is pressed again, so count approvals per sale, and a sale abandoned after an approval still used one.
• It counts the approvals your own check asked for. The till's own approval inbox is a separate path that this check does not count (not run): ask which path the shop's managers use (P-OVERRIDECAP would count the inbox).
• Offline the till uses your declared down answer.

Tell the customer. After the day's limit of manager approvals for a store, a further discount is refused at Pay; we count only the approvals our check is asked about.

Only some payment methods for a sale or a customer

No store credit for a walk-in customer, no on-account for a cash customer, and methods that may not be combined — Ready, with limits (2) · Check before payment · the card

What you build. Your service answers the check before payment with allow and exclude_tenders: the payment methods this sale may not use.

Limits.

• Answered when the cashier presses Pay, not when the line is entered.
• The excluded methods show dimmed, with your reason.

Tell the customer. At Pay the till offers only the payment methods this sale and this customer may use; the others are dimmed with the reason.

One more detail on a line

One more detail on a line, for goods with no serial number — Ready, with limits (2) · Configure · the card

What you build. A Transaction Item Attribute: a name, a pattern and an order. The till offers it on each line.

Limits.

• The pattern is checked on the till screen only: the server accepts a value that breaks it.
• Offline: not run.

Tell the customer. The till asks for the extra detail on each line and keeps it with the sale.

A partner's voucher or PIN made at payment and printed on the receipt

A partner's voucher or PIN made when the sale is paid and printed on the receipt — Not yet · Request · the card

What you build. Nothing yet: the receipt's own lines are the shop's settings and the check before payment only approves or refuses, so neither can carry a value your service makes at payment.

Limits.

• Today (not run) your service can read the booked sale from the event feed and send the voucher by message or e-mail after the sale; it is not on the paper receipt.

Tell the customer. The till cannot yet print a partner's voucher on the receipt at payment; we can send it to the customer right after the sale.

A prescription number before payment

A prescription number is required before a prescription item is paid for — Ready, with limits (1) · Check before payment · the card

What you build. Your service answers the check before payment and refuses the sale, with your sentence, while a prescription line has no prescription number.

Limits.

• Answered when the cashier presses Pay, not when the line is entered.

Tell the customer. A sale with a prescription item cannot be paid until its prescription number is recorded.

A question when the quantity of a line changes

A question when the quantity of a line changes, before Pay — Not yet · Request · the card

What you build. Nothing yet: capture on an event asks on a scan, not on a quantity change.

Limits.

• Today the check before payment can refuse the sale at Pay (the card line-quantity-cap).

Tell the customer. The till cannot yet ask when a quantity changes; it can stop the sale at Pay.

A rule that depends on which terminal the sale is on

A rule that depends on which terminal the sale is on, beyond its POS profile — Not yet · Request · the card

What you build. Nothing yet: the check before payment does not name the terminal today. The extension point asked for adds it.

Limits.

• Today a rule can depend on the sale's POS profile, not on the terminal.

Tell the customer. A rule per terminal is not possible yet; per POS profile it is. We have asked for it.

Selling below the minimum price needs a manager

Selling below the minimum price needs a manager's approval — Ready, with limits (2) · Check before payment · the card

What you build. Your service compares each line's price with the minimum in the check before payment and answers approve when one is below it.

Limits.

• Answered when the cashier presses Pay, not when the line is entered.
• A manager who is not the cashier signs in on the till to approve. Approval by e-mail has no door.

Tell the customer. A sale with a line below the minimum price waits at Pay until a manager approves it on the till.

Show or relabel the discount price or the total including tax on the till

Show or relabel the discount price or the total including tax on the till — Not yet · Request · the card

What you build. Nothing yet: no price, amount, tax or tender field is on the field rules' lists, so a rule cannot show or relabel one.

Limits.

• Field rules change what the till shows and asks for, never what it charges.

Tell the customer. The till cannot yet show or rename a money column; the figures it works out stay as they are.

The shop's own fields on the till, renamed or hidden

Show our own fields on the till, call them by our words, hide the ones we never use — Ready, with limits (1) · Field rules · the card

What you build. Field rules per till theme: hide a field, call it by the shop's word, or show up to three more item and three more customer fields, offline too. It is data: no code runs.

Limits.

• Up to three more item fields and three more customer fields; the field rules page lists which fields.

Tell the customer. The till shows your fields in your words and hides what you never use, within the listed fields.

A warning at the scan that the cashier taps past

A warning when an item is scanned (another batch has less shelf life), with the cashier tapping to carry on — Ready, with limits (5) · Capture on an event · the card

What you build. A capture on scan. Your service looks up the item's other batches in the store over the record API, then answers confirm with your sentence ("This item has a batch with less shelf life in the store. Add it anyway?"). The cashier taps Yes once and the item is added.

Limits.

• It is a question, not a notice: one tap, and No leaves the item off. POS LANE X row X60, P-CAPTURE4 (a notice answer at the scan: the sentence shows and the item is added with no tap) removes the tap when it merges.
• The call is made before the line is added, and an ordinary item scan carries no batch: you can say the item has shorter-dated batches, not that this lot is the longer one, unless the scanned code names the batch. The lot is chosen later, at the batch pick (card first-expiry-first-out).
• Online, your service answers. When it is down or offline, the answer you declared applies (allow_and_flag lets the line on and flags it for review), so the warning is missed then.
• Your service reads other batches over the record API: allow for the seconds it takes (the scan waits up to the time you declared).
• Not run: a confirm answer on a till.

Tell the customer. Scanning an item with a shorter-dated batch in the store makes the till ask the cashier once, and one tap adds the item.

Documents and print

A reason asked when a document is rejected

The approver must give a reason when rejecting a purchase order, and it is kept on the document — Ready, with limits (4) · Desk action · the card

What you build. A Desk action Reject with reason on the document with one required input, Reason (Small Text). Your service writes the reason and who pressed into fields your manifest added, then moves the document with the shop's workflow call (apply_workflow); a save rule, added with the button, refuses a rejected document with no reason. Recipe section A reason asked before a document is rejected; sample S11's reject.

Limits.

• The user presses the action instead of the workflow's own reject button. Take the reject transition away from those roles (configuration), or that button still rejects without a reason.
• A user presses it: nothing asks for a reason when a document is rejected another way (an import, the API).
• Your service rejects with its own key, as its integration user: that user's role needs the reject transition, and the workflow records that user. Write the pressing user (the context carries it) into a field if the audit trail must show who rejected.
• Your service must be up: when it is down the button says so and nothing is rejected.

Tell the customer. The approver is asked for a reason in a dialog when rejecting, and the reason is kept on the document.

A button on a record that asks your system

A button on a record that rechecks stock in our ERP or assigns a pick route — Ready, with limits (1) · Desk action · the card

What you build. A Desk action: a button on the form, or for the ticked rows of a list, answered by your service.

Limits.

• A user presses it: nothing runs on its own when the record is saved.

Tell the customer. Users press a button on the record and your system answers in Desk.

A limit judged only when the value is new or changed

Check a limit (an item's maximum discount, say) against the ceiling only when someone sets or changes it, not on every edit of the record — Ready, with limits (3) · Event feed · the card

What you build. Your service reads the record's events and judges the value only when it is new or differs from the last one it saw (changed in the kit's feed client), then flags it. Recipe section A value judged only when it changes.

Limits.

• The save is not refused: the value is judged seconds later and flagged.
• POS LANE X row X59, P-RULES4, gives the save rule's limit an on change switch, so the save itself is refused, when it merges.
• A value edited twice between two reads of the feed is judged once.

Tell the customer. A new or changed value over the limit is flagged within seconds; existing records are not held up by unrelated edits.

A code in a set shape

A code must follow our pattern — Ready, with limits (1) · Save rules · the card

What you build. A save rule of kind pattern, held on every save.

Limits.

• On a till sale and the till close a save rule only flags, never refuses.

Tell the customer. A code in the wrong shape is refused when the record is saved.

Our own document numbering

Documents numbered our way — Ready · Configure · the card

What you build. Naming series set up in iVendNext Desk.

Limits. None known.

Tell the customer. Documents carry the shop's own numbering.

The approval e-mail carries the document's print

An e-mail at each approval step with the purchase order's PDF attached, and the uploaded CSV — Ready, with limits (4) · Configure · the card

What you build. A notification set up in Desk by the shop's administrator on the approval step, with Attach print ticked and the print format chosen. In Print Settings, Allow Print for Draft must be on: with it off the notification raises an error on a draft or pending document, and as the notification runs inside the document's own save, that can stop the approval step. Nothing is shipped in a manifest: a notification on a shop's own record type is refused there (chapter 7).

Limits.

• An uploaded CSV goes as a link in the message: the installed framework has no attach-from-field, and a manifest cannot carry it (it could mail any private file). The link opens with the reader's own rights.
• Allow Print for Draft is a site-wide setting, and a notification that fails (no print, no recipient mail) can hold the document's save: send the first one to a test document.
• A package's own record types will carry a notification with the package's own print format when POS LANE X row X58, P-MANIFEST4 (multi-select, a settings record, notification attachments) merges. The shop's own documents stay configuration.
• Not run: a mail sent with the print attached.

Tell the customer. Each approval step mails the approver the document as a PDF; an uploaded CSV is a link in the same mail.

Approvals by store

Each store's purchase orders or transfers are approved by that store's manager — Ready, with limits (1) · Configure · the card

What you build. A workflow whose approver is chosen by the document's store. Configuration only.

Limits.

• Who may edit a record in a workflow state is checked in the browser only: follow the four safeguards in chapter 13a.

Tell the customer. Each store's documents go to that store's approver.

Extra fields on the shop's own documents

Extra fields on a purchase order and its lines, a goods receipt, a stock transfer, an expense or the till close — Ready, with limits (1) · Manifest · the card

What you build. A manifest adds fields, named with your prefix, to the shop's own record types and their child tables.

Limits.

• A manifest cannot make such a field required, unique or defaulted: use a save rule (the card required-when-another-filled).

Tell the customer. The documents carry the extra fields; a rule that a field must be filled is a separate save rule.

A value worked out from others

A field filled in from other fields when the record is saved — Ready, with limits (2) · Save rules · the card

What you build. A save rule of kind derived, held on every save.

Limits.

• On a till sale and the till close a save rule only flags, never refuses.
• POS LANE X row X59, P-RULES4, adds days between two dates to the derived rule, and to the limit rule a value judged when it changes, a row rule that reads its header and a limit read from a settings record, when it merges.

Tell the customer. The field is worked out from the others each time the record is saved.

A field required when another holds a value

A field must be filled when another field holds a value — Ready, with limits (1) · Save rules · the card

What you build. A save rule of kind required when, held on every save: Desk, imports and API writes. (The shop's own mandatory depends on is checked in the Desk form only.)

Limits.

• On a till sale and the till close a save rule only flags, never refuses.

Tell the customer. The record cannot be saved without the field when the other holds a value.

Fields locked once approved

Fields cannot be changed once the document is approved — Ready, with limits (1) · Save rules · the card

What you build. A save rule of kind locked in state, held on every save.

Limits.

• On a till sale and the till close a save rule only flags, never refuses.

Tell the customer. Once approved, the locked fields cannot be changed.

A final receipt while the till is offline

The final receipt printed while the till is offline — Not yet · Request · the card

What you build. Nothing a builder can do.

Limits.

• Today: a provisional slip offline; the final receipt once the till reconnects.
• Ask us: a final receipt offline.

Tell the customer. Offline the customer gets a provisional slip; the final receipt follows when the till reconnects.

A gift receipt

A gift receipt with no prices — Ready · Configure · the card

What you build. A print layout set up in iVendNext Desk. The kit has no recipe for gift receipts yet.

Limits. None known.

Tell the customer. The cashier can print a gift receipt.

Prescriptions kept as records

Keep each customer's prescriptions in iVendNext — Ready · Manifest · the card

What you build. Prescriptions as your manifest's own record type.

Limits. None known.

Tell the customer. Prescriptions are kept in iVendNext, with their own screen.

Your own records in iVendNext Desk

Keep our own records, such as a warranty register, in iVendNext with their own screens and print formats — Ready, with limits (1) · Manifest · the card

What you build. A manifest declares your record types, fields, print formats, notifications and workspaces, with native screens; they can be listed under ours.

Limits.

• A multi-value field (a table of choices) and a settings record of your own type wait for POS LANE X row X58, P-MANIFEST4; today a settings record is an ordinary record type read by name (the record named Default, sample S22).

Tell the customer. Your records live in iVendNext Desk, with their own screens, lists and reports.

The controlled-drug register

Keep the controlled-drug register the law asks for — Not yet · Request · the card

What you build. Nothing a builder can do: it is part of our pharmacy pack.

Limits.

• Ask us: our pharmacy pack's controlled-drug register.

Tell the customer. The controlled-drug register comes with our pharmacy pack.

A layout of its own for each customer's invoice

A layout of its own for each of a few distributors' invoices — Ready, with limits (5) · Manifest · the card

What you build. Print formats in a manifest, on the sales invoice: one template that branches on the customer picks the layout by itself, or one format for each customer that the user chooses.

Limits.

• The back-office invoice only: the till's receipt is separate.
• Nothing chooses a format by customer on its own (the customer record has no print-format field, read on a sandbox), so the branch lives in the template, and the shop's administrator makes that template the invoice's default (a manifest cannot set the default): ask for P-PRINTBYPARTY. With one format for each customer, a person picks it every time.
• A layout reads only the invoice's own fields; a figure the invoice does not carry cannot be printed.
• Once the branch format is the invoice's default, it is every customer's invoice: any customer not named gets the plain layout, so that layout must carry what the shop's current invoice does (tax lines, tax numbers).
• A copied layout gets none of our later fixes.

Tell the customer. Each distributor's invoice prints in its own layout from the back office; the till's receipt is not part of it.

Only some roles may submit or cancel when a field holds a value

Only the receiving store receives a transfer; only a supervisor cancels it — Not yet · Request · the card

What you build. Nothing yet: save rules today govern a field's value, not who may submit or cancel.

Limits.

• Today, permissions by role decide who may submit at all, whatever the field holds.

Tell the customer. Submit and cancel by role and value is not possible yet; we have asked for it.

Lab orders kept as records, with a workflow

Optical lab orders tracked in iVendNext and sent to the lab — Ready, with limits (1) · Manifest · the card

What you build. Lab orders as your manifest's own record type with a workflow; your outside app sends them to the lab.

Limits.

• Who may edit a record in a workflow state is checked in the browser only: follow the four safeguards in chapter 13a.

Tell the customer. Each lab order is tracked through its steps and sent to the lab.

The shop's own lines on its receipt

Our address, tax number and returns policy on the receipt — Ready · Receipt settings · the card

What you build. The register's Receipt Header and Receipt Footer print on the shipped receipt without copying it: store settings, not a declaration.

Limits. None known.

Tell the customer. The shop's own lines print on every receipt, and the receipt keeps our later fixes.

Shelf and item labels printed from the till

Print shelf labels from the till — Ready, with limits (1) · Label layout · the card

What you build. A label layout the shop declares or your manifest installs (HTML, or Zebra printer commands); the till prints it from an item's card or a basket line, on any printer the device reaches.

Limits.

• Labels from the back office and from Handheld print through a desktop utility.

Tell the customer. Stores print labels from the till; the back office uses the desktop utility.

Your system's answer before a back-office document is submitted

A purchase order blocked by data our ERP holds; a goods receipt checked against the supplier's terms — Not yet · Request · the card

What you build. Not yet as its own extension point. Today: a workflow step only your service can take, after its check passes (the recipe), or a Desk action a user presses.

Limits.

• Today, with a workflow: the user waits a few seconds, and your service must be up for back-office submits.
• Today, an outside app finds a problem only after the save.

Tell the customer. A back-office document can be held for your system's check today through a workflow step; a direct check is coming.

Approvals by amount

Purchase orders or transfers over an amount need approval — Ready, with limits (1) · Configure · the card

What you build. A workflow on the document, with an approval step by amount. Configuration only.

Limits.

• Who may edit a record in a workflow state is checked in the browser only: follow the four safeguards in chapter 13a.

Tell the customer. Documents over the amount wait for the approver before they can be submitted.

A receipt laid out for your market

A receipt with our logo, tax number and address, a line per VAT rate, in a second language — Ready, with limits (5) · Manifest · the card

What you build. A print format installed by a manifest (or set up by hand), then chosen on the till's POS Profile, which is configuration. The save is refused if it cannot print the register's latest sale. The format reads only the sale; the sample's package adds one field to the sale that copies the Company's tax ID.

Limits.

• The format is for the till sale only; a back-office invoice has its own.
• A sale saved before the package was installed has no tax number on it; the address is the one the sale holds, from the POS Profile or the Company.
• Two different non-zero rates under one tax account print a single VAT total.
• Arabic on paper or PDF, a returned sale and a sale with two or more tax rows: not run.
• A customised receipt gets none of our later fixes, and the shop's seeded receipt carries more than the sample (per-item charge rows, serial and batch lines, deposit and balance lines, offline-sale lines): copy back what your market needs.

Tell the customer. The receipt carries the shop's logo, tax number, address and a line per VAT rate; we test returns and your language before go-live.

A receipt reprinted

Reprint a receipt for a past sale — Ready, with limits (1) · Configure · the card

What you build. Reprint is part of the till; no set-up beyond the receipt format.

Limits.

• A reprint keeping the sale's old VAT rate: not run.

Tell the customer. The cashier can reprint the receipt of a past sale.

No value twice in a document's lines

The same item or code may not appear twice in one document — Ready, with limits (1) · Save rules · the card

What you build. A save rule of kind unique in rows, held on every save.

Limits.

• On a till sale and the till close a save rule only flags, never refuses.

Tell the customer. A document with the same value on two lines is refused when it is saved.

The receipt sent by WhatsApp

Send the customer the receipt on WhatsApp — Ready, with limits (2) · Receipt settings · the card

What you build. WhatsApp on the till's Print sheet: a store setting.

Limits.

• Only where the store has the WhatsApp app set up.
• Not offered offline: the receipt offers e-mail and SMS.

Tell the customer. The cashier can send the receipt on WhatsApp while the till is online.

Item fields on the receipt

Show more of the item's own details on the receipt — Ready, with limits (1) · Field rules · the card

What you build. A field rule puts item fields on the receipt: on screen, on paper and on the offline slip.

Limits.

• Up to three more item fields per till theme, from the field rules page's list.

Tell the customer. The item details you choose print on the receipt.

Initials that confirm a new record is set up, in place of a confirm pop-up

When a new item is first saved, the user confirms that batch and expiry are on and the item is linked to its parent — Ready, with limits (5) · Save rules · the card

What you build. A short text field, Setup confirmed by, that your manifest adds to the record (a field you add may be read-only or hidden, never mandatory), and a save rule of kind required when on that field, with the conditions that make the confirmation matter (for example, batch tracking is on). The save is refused with your message until the user types their initials, in Desk, an import and the API alike.

Limits.

• Initials, not a tick: the rule counts an empty text field as missing, but it does not count an unticked tick as missing (the tick is 0, which is a value). Do not build it on a tick.
• A field on the form, not a pop-up: your code cannot show a question inside Desk (rule 4). Typed once, it stays, so nothing asks again.
• It holds on every save until filled, not only the first: records saved before the rule existed need the initials at their next save.
• On a till sale and the till close a save rule only flags, never refuses (card required-when-another-filled).
• Not run: the condition on a tick field (batch tracking) was not run on a shop.

Tell the customer. A new record cannot be saved until someone types their initials to confirm it is set up; there is no pop-up, and it is asked once.

Reports and data

Head-office reports and BI

Head-office reports and our BI tool fed with sales and stock — Ready, with limits (3) · Outside app · the card

What you build. An outside app on the feed and bulk reads fills the BI tool.

Limits.

• Rows are as of extraction: a later change to a booked sale, other than a return or a cancellation, is not followed.
• The kit's samples read the shared feed, whose key is not limited to one app (a feed scoped to your app is an extension point, chapter 9).
• Offline sales arrive late, when the till syncs.

Tell the customer. Head office sees sales and stock in its own BI tool, shortly after they are booked.

Something done every night

Open quotations cancelled every night; a report sent every morning — Ready, with limits (1) · Outside app · the card

What you build. An outside app on a schedule, over the record API.

Limits.

• It runs at the time you choose, not at the moment the till closes.

Tell the customer. The job runs every night at the agreed time.

A balance report with opening and closing figures

A report of each member's cash balance for any dates, with the opening and the closing figure — Ready, with limits (3) · Outside app · the card

What you build. Your service's daily job writes one balance row per member per day (opening, change, closing) into a record type of your own; a Report Builder report over the rows, filtered by date, reads the opening of the first day and the closing of the last. Recipe step 7 of the loyalty recipe; S22's daily_balances.

Limits.

• The closing is taken when the job runs, so a move made between midnight and the run counts in the day that ended.
• A day the job did not run has no row; the next row's opening still follows from the last closing.
• Not run on a shop.

Tell the customer. Each member's balance is kept day by day, so a report for any dates shows what they started and ended with.

A statement of what each customer owes

A statement of what each customer owes, printed and sent on a schedule — Ready, with limits (3) · Configure · the card

What you build. The standard Process Statement Of Accounts: pick the customers, the layout, the dates, the frequency and the sender; the site makes the PDF and can e-mail it.

Limits.

• The plain statement rendered (opening, each sale, closing). With ageing switched on, the same statement stopped with a server error on this sandbox, though the receivables report ran: run it on the customer's site before you promise the ageing.
• The schedule sends through the site's e-mail queue, from the sender account chosen on the statement or else the user, so the site needs an outgoing e-mail account that is switched on (read from the code, not run: both sandbox accounts are off and no mail was tried).
• A customer with no e-mail address is skipped by the send (read from the code).

Tell the customer. Each customer's statement is a PDF made on demand, and can be e-mailed on a schedule once the shop's outgoing e-mail is set up; we have not run a send.

Integrations, payments and hardware

Your own connector on our integration framework

Build our connector inside iVendNext's integration framework — Not yet · Request · the card

What you build. Nothing inside the shop: the connectors on our framework are ours.

Limits.

• Today: build an outside app instead.
• Ask us: to build the connector.

Tell the customer. A connector on our framework is ours to build; an outside app does the same job today.

A store's list of web orders to pick and hand over

Click and collect — the store sees which web orders to pick and which customers are coming to collect — Ready, with limits (7) · Manifest · the card

What you build. A manifest: a Report Builder report of the web orders still to pick, two fields on the delivery note that can be set after it is submitted, Handed over (a list column and filter: the Delivery Note list filtered on Status To Bill or Completed, Is Return No, % Returned less than 100, Handed over No, Customer's Purchase Order No set, the store's warehouse and a date on or after the install is the waiting list) and Collected by, and a workspace that opens both. A web order is an order with the web shop's order number. Nothing leaves the shop.

Limits.

• The lists are in Desk. The till's own pickup board lists till sales only, and a page on the till opens only over a sale.
• Who handed an order over, and when, is the delivery note's own history, not a field.
• The waiting list is a filtered list, not a report: a report cannot use a field its own manifest adds.
• An order returned before collection stays on the list (a return does not yet update its original): cancel its note instead.
• Notes from before the install would wait too: add a date to the saved filter. A return or an amended note copies the two fields.
• A Desk order typed with a customer's order number, or a web order shipped from the store, shows too.
• A web order booked as a sales invoice shows only once its delivery note exists.

Tell the customer. Each store gets a Desk board of the web orders to pick and the customers coming to collect, and records each hand-over on the delivery note.

Buy now, pay later at the till

Customers pay with a buy-now-pay-later provider — Not yet · Request · the card

What you build. Nothing a builder can do: it is our payment connectors' work.

Limits.

• Ask us: a buy-now-pay-later tender in our payment connectors.

Tell the customer. Buy now, pay later comes through our payment connectors; we take the request.

The customer's own online shop

Orders from our own online shop come in; stock and prices go out — Ready, with limits (2) · Outside app · the card

What you build. Your outside app: orders in, stock and prices out.

Limits.

• An online order cannot be edited at the till.
• The kit's samples read the shared feed, whose key is not limited to one app (a feed scoped to your app is an extension point, chapter 9).

Tell the customer. Online orders arrive in iVendNext and the shop shows the stores' stock and prices.

An ERP on Acumatica

Our Acumatica ERP receives sales, stock moves and purchasing — Ready, with limits (3) · Our connector · the card

What you build. Our Acumatica connector. Ask us which release carries it for the customer.

Limits.

• About 2.75 complete sales a minute per connection (about 165 an hour): size the busiest hour against it.
• One ERP per company.
• Our Sage X3 connector is not built yet.

Tell the customer. Our connector books the stores' sales into Acumatica; we size it against your busiest hour first.

A feed of your own app's events

Our app gets its own queue of what changed, with business labels — Ready, with limits (1) · Event feed · the card

What you build. The event feed extension point: your app pulls its own queue (sales, customers, stock) and marks each item done.

Limits.

• The kit's feed client and its samples have not been run against this extension point: not run.

Tell the customer. Your app reads its own queue of changes and nothing is lost while it is down.

The customer's own ERP kept in step both ways

Our ERP and iVendNext kept in step: items, prices, stock and purchase orders — Ready, with limits (4) · Outside app · the card

What you build. Your outside app on the API and the event feed, keeping its own map of record ids, its own place in the feed, and a nightly reconciliation.

Limits.

• The feed reports a change after it is saved, so your app corrects after the fact.
• The kit's samples read the shared feed, whose key is not limited to one app (a feed scoped to your app is an extension point, chapter 9).
• Webhooks try three times, then stop: use the feed for anything you must not miss.
• One ERP per company.

Tell the customer. The ERP and iVendNext stay in step within minutes, and a nightly pass reconciles them.

The customer's own order or warehouse system

Our order-management or warehouse system linked to the stores — Ready, with limits (2) · Outside app · the card

What you build. Your outside app over the API and the event feed; the customer's systems stay its own, and you connect to them.

Limits.

• The feed reports a change after it is saved, so your app corrects after the fact.
• The kit's samples read the shared feed, whose key is not limited to one app (a feed scoped to your app is an extension point, chapter 9).

Tell the customer. The order and warehouse systems exchange records with iVendNext through our app.

Your system told of sales, returns and stock moves

Our system hears about every sale, return and stock move — Ready, with limits (3) · Outside app · the card

What you build. An outside app reads the event feed and reacts to each sale, return and stock move.

Limits.

• The kit's samples read the shared feed, whose key is not limited to one app (a feed scoped to your app is an extension point, chapter 9).
• Webhooks try three times, then stop: use the feed for anything you must not miss.
• An offline sale's events appear when the till syncs, possibly hours later.

Tell the customer. Your system hears of each sale, return and stock move shortly after it is saved.

An online shop on WooCommerce

Our WooCommerce shop linked to the stores — Ready, with limits (2) · Our connector · the card

What you build. Our WooCommerce connector: online orders in, stock and prices out. Ask us which release carries it for the customer.

Limits.

• It does not reserve stock.
• It takes percentage vouchers only.

Tell the customer. Our connector links the WooCommerce shop; it does not hold stock for an order, and vouchers are percentages.

A card or mobile-money provider we do not connect

Take card or mobile-money payments through our own provider — Ready, with limits (1) · Payment connector · the card

What you build. Your payment connector on the gateway contract paygw/1.

Limits.

• Certified by our conformance kit before it takes a payment.

Tell the customer. The provider is connected once its connector passes our certification.

An outside fiscal service's result on the sale

The tax authority's result, QR code and seal on each sale and receipt — Ready, with limits (1) · Fiscal reader · the card

What you build. A fiscal reader: the outside fiscal service writes its result on the sale, and the receipt prints only when it is back.

Limits.

• When the fiscal service is down, the sale waits and its receipt is held until a result arrives; the till does not retry for you.

Tell the customer. Each receipt carries the tax authority's result, from your fiscal service.

Setup and administration

One settings page that drives the shop's rules

Change the limits and who is told in one settings page, not in each rule — Ready, with limits (3) · Event feed · the card

What you build. A settings record of your own (named Default); when it is saved, your service copies its values into the save rules' limits and the notifications' recipients it names. Recipe section A settings record that drives rules; S22's settings_sync (a standalone, tested function S22 itself does not call).

Limits.

• For the seconds between the settings save and the copy, the rules hold the old values.
• POS LANE X row X59, P-RULES4, lets a save rule read its limit from a settings record itself, when it merges.
• Not run on a shop.

Tell the customer. The limits and the people told are changed in one settings page, and the rules follow within seconds.

A list column the retailer wants on a record's list

A column the retailer wants on a record's list — Ready, with limits (2) · Configure · the card

What you build. The user picks the columns in the list's own settings in iVendNext Desk, or an administrator sets the record type's list settings.

Limits.

• Only the record's own fields can be a column; a total of its item rows cannot (the card count-list-totals).
• Picking the column by hand in the list's own settings was not run, so whether a column can be set for every user is not promised.

Tell the customer. Users pick the columns they want on a list; a total of a document's rows is a separate piece of work.

Permissions by role

Each role sees and does only what it should — Ready, with limits (2) · Configure · the card

What you build. Roles and permissions set up in iVendNext Desk.

Limits.

• Permissions hide an action, never a field: hide some till fields with field rules (the card till-fields-shown-renamed-hidden).
• The kit has no recipe for permissions per till action.

Tell the customer. Each role is given only the actions it needs.

A country's tax or e-invoicing rules

Our country's tax and e-invoicing rules — Not yet · Request · the card

What you build. Nothing a builder calculates: we add countries.

Limits.

• Today an outside fiscal service can record its result through a fiscal reader (the card outside-fiscal-result).
• Ask us: the country, through a fiscal app of ours.

Tell the customer. Countries are added by us; meanwhile an outside fiscal service can record its result on each sale.

A server in the store

A server in each store — Not yet · Request · the card

What you build. Nothing: there is no store server; the tills work offline on their own.

Limits.

• Ask us: a store server.

Tell the customer. There is no store server; each till keeps working offline on its own.

Several companies in one site

Several companies, countries or currencies in one site, with connectors — Not yet · Request · the card

What you build. Nothing a builder can do.

Limits.

• One company is one country and one currency.
• Today: one site per company, so several countries mean several sites.
• Ask us: several companies in one site.

Tell the customer. Each company, country and currency runs on its own site today.

A value unique across all records

A tax number on one customer only — Ready, with limits (7) · Save rules · the card

What you build. A save rule of kind unique across: the value of one field is on no other active record of the type. The product also takes up to three scope fields (for example the company). It holds on every save: Desk, import and the API. The kit's copy of the save-rules page, written before this kind merged, lists seven kinds and does not describe it; the product's page does, and the shop's install screen is the check.

Limits.

• The kit's copy of the checker does not take scope fields yet (probed: it refuses them); the plain form passes. Scope arrives with the next re-copy of the product's checker.
• On a table above 10,000 records, the field must be indexed.
• It is a rule, not a database constraint: two saves at the same moment can both pass.
• A cancelled record holds no value; an empty value passes; the comparison follows the database's case rules.
• It checks the record itself, never a table's rows (card no-value-twice-in-lines does that).
• On a till sale and the till close a save rule only flags, never refuses.
• Not run: the kit's sandbox has not exercised this kind.

Tell the customer. A customer's tax number can be held on one active customer only; a second one is refused when it is saved.