The extension points
Part 1 of 5 · 9. The extension points, and how to ask for a new one
What your manifest declares is on from the moment of install, under the one consent, for every store. The exceptions: a save rule limited to a role stays off until the customer names the role, a manifest's "enabled": 0 keeps a save rule off, a payer stays off until the customer names its clearing mode, and a fiscal reader stays off until the customer has set it up. Field rules have no switch.
Back: the overviewNext: More extension points
| Extension point | What it lets you do | Where in the kit |
|---|---|---|
| Remote till key | Your HTTPS service answers a key the cashier presses: a message, details added to the sale, values for its lines, or any of them together. | Till keys · A till key · samples S1, S2, S6 |
| Event feed | Your app pulls its own queue of what changed in the retailer's iVendNext (sales, customers, stock) and marks each item done. | Reading iVendNext's events reliably · ../tools/feed_client/ |
| Save rules | The retailer declares a rule on a field, held at every save: a code's shape, a value worked out from others, no value twice in a document's rows or across records (one tax id per customer group), a field required when others are filled. A rule can also keep a document's submit or cancel for named roles when its header holds a value (only the receiving store receives a transfer). Also: no more than so many records a day per store (ten discount approvals a store a day), a total or a count of a document's rows on its header, the days between two dates, a limit judged only when its value changes or read from a settings record the retailer's own people tune, and a row rule that reads its header. | Chapter 7 (the save_rules kind) · the library page Save rules |
| Desk action | Your service answers a button on a record in iVendNext Desk, on the form or for the ticked rows of a list. | A button on a Desk record · S16 |
Document check (doccheck/1) |
Your service has the last word before a back-office document the retailer names is submitted (a purchase order, a goods receipt, a stock transfer), from every door: Desk, an import, the API. It allows the submit, refuses it with your sentence, asks the user a question, asks for approval by a role, or fills fields. Back office only: never a till sale, and never a record the till's own booking writes (a layaway's order, a delivery's invoice, an offline sale reaching the server), so the till's quote edit and quote cancel are not checked either; the till's door is the check before payment. fill writes only a field the retailer added (a field your package adds counts), never a standard field or money: a subscription naming one is refused when it is saved. |
Chapter 7 (an extension_subscriptions row of point doccheck) · Purchase orders checked by your ERP (S34) · A rule checked before a document is submitted · the library page Document check |
| Partner page | Your own page, framed on the till or in Desk, told who is looking at what by a signed context; on the till it may answer once. | Your own screen inside the retailer's frame · S17 |
| Fiscal reader | An outside fiscal service's result for a sale, read from the fields it writes, so the receipt prints only when the tax result is back, with the tax authority's QR code and seal where the service writes them. | The library page Fiscal reader · chapter 7 (the fiscal_readers kind) |
| Check before payment | Your service has the last word on a sale before money is taken: it allows the sale, allows it without some payment methods, refuses it with your own sentence, asks the cashier a question, or calls a manager. Every door that moves money, except those the library page lists, holds your answer to the basket. It is sent the POS day and its terminal (pos_opening, pos_terminal), so one rule can hold per terminal; both are among the fields the retailer consents to send. Four things your service meets: (1) no other door books a till sale around your check. At a POS Profile with your check in scope, a till sale (a POS Invoice) or its return submitted by any door but the till's own (the iVendNext Desk POS screen, the API, ivendnext_mpos.api.v1.submit included, the Desk form, a held sale submitted from either, an import) is refused for every user, Administrator included: "This sale needs a partner's check before it is paid. Ring it up on a till." Outside the till, a line taken from another store's stock also takes that store's checks. A check is per POS Profile, so a profile of the same store left out of your scope sells unchecked: scope your check to every profile on that store, or leave it unlimited. The refusal sits on the POS Invoice only: a Sales Invoice made in iVendNext Desk is not held by it. (2) Your answer pays only for the cashier it was asked for: another cashier taking over the sale (a held sale resumed, a teammate on the same POS day) is asked again. (3) A payer's sale is checked again on the plan's prices whenever its payer changes, so expect more than one round a sale; price_list stays the sale's header list on that round, and a refusal, the cashier's No or no manager takes the payer off. (4) Lots and serials: a check whose subscription ticks Send each line's lot and serial number (check_send_lots, the retailer's tick, never a manifest key) receives batch_no and serial_no on every line, on a sale and a return, under its own consent text; every check's answer now binds each line's lot, sent or not, so a lot that moves between your answer and the money asks you again. ⚠ totals.tax_minor is the sale's taxes and charges, a service mode's charge on the whole sale included: do not read it as tax alone. A price typed above or below the list reads discount_minor 0 (the typed price is the line's list, as in iVendNext Desk). An answer may fill sale details your subscription lists in its settings (fill_attributes, 1 to 10; the sale is priced and checked once more on the filled details), and an order or a layaway plan is checked once, at placement (stage: "sale"), and again when an order's change is saved; its delivery, instalments and pickup go on that answer. A refund's return_of.paid_by names only the payment methods that paid (a zero-amount row is left out). |
Chapter 7 (an extension_subscriptions row of point check) · A rule checked before payment · S18 · Several till rules in one app · S23 · Coupon rules · S32 · the library page Partner check |
| Pricing | Your sandboxed module takes money off a line after every promotion: a member rate that multiplies with a promotion, a cap per line from your own tier table. It runs on the server and on the till offline, never takes more than the retailer's own limit (which starts at 0), is never offered a line a Pricing Rule has already priced, a return or a gift-card line, and only a module we have certified runs. The Desk POS does not run it: a sale rung there is priced without your module. | The Wasm kit · its template (a member discount) · the library page Pricing |
| Wallet | Your service keeps a balance (cash back, store credit) that a customer spends at the till as its own payment method: the till asks your service what this sale may use, takes it, and gives it back on a return. | A partner wallet at the till · S22 |
| Scan source | The retailer declares a table of its units' own codes (a barcode per pack, a tag per handset). The till's scan finds the unit, its batch and serial, and refuses one already sold. It also reads a pharmacy pack's GS1 code. It is data: no code runs and nothing leaves the retailer's iVendNext. | Chapter 7 (the scan_sources kind) · Unit codes at the scan · S19 · the library page Scan source |