The shop's own fields on the till (field rules) — the recipe

Field rules give a shop its own say over the fields the till shows, per till theme, with no code: hide a field nobody uses, relabel it in the shop's own word, require a phone or an email on a new customer, or show up to three more Item fields and three more Customer fields. This recipe is for an iVendNext Partner, or the CitiXsys Consulting Team, shipping them in a manifest.

Reference implementation: samples/s21_field_rules/ — the sale's line reads Product, the customer's card says Stars, the new-customer sheet has no email, and a new customer needs a phone.

When to use it. It is step 1 of the screen ladder — configuration. Reach for it before any screen of your own. A shop's manager can do the same in POS Studio's Fields tab; a manifest is for an iVendNext Partner who ships the same rules to many shops.

The four rules, here. Nothing is called and nothing leaves the shop. No price, amount, tax or tender field is on any list: a rule changes what the till shows and asks for, never what it charges.

Steps

Declare the rules in your manifest, each naming the shop's till theme:
```
"field_rules": [
  {"theme": "PP Partner Till", "surface": "cart_line", "field": "item_name", "action": "relabel", "label": "Product"},
  {"theme": "PP Partner Till", "surface": "customer_card", "field": "points", "action": "relabel", "label": "Stars"},
  {"theme": "PP Partner Till", "surface": "customer_create", "field": "email", "action": "hide"},
  {"theme": "PP Partner Till", "surface": "customer_create", "field": "phone", "action": "require"}]
```
The screens and what each takes: customer_create (hide phone, email, more details; relabel name, phone, email; require phone, email), customer_card (hide or relabel member since, lifetime, visits, points; hide phone; show Customer fields), cart_line (relabel item name, quantity; show Item fields), item_result (hide or relabel the item code; show Item fields), sale_details (hide or relabel an optional sale detail). One action per screen and field; a label is at most 40 characters.
They are live at install. Field rules have no switch: a require rule is enforced by the server as soon as the manifest installs, and the others reach each till that wears the theme at its next start. Tell the shop before you install.
What the cashier sees. The till's start reads the rules with its theme; each screen asks them as it draws, online and offline. A new customer without a required phone is refused by the till and by the server: "Phone is required here." — an older till cannot get round it. A customer added offline without it is created when the sale syncs and flagged on the Sales to review report, never refused (the customer has paid). (A customer made in iVendNext Desk or by an import is not a till's, and is not checked.)
Uninstalling removes exactly your rows and leaves the theme as the shop had it, even if the shop renamed the theme meanwhile.
Test it. The manifest passes the kit's checker, which refuses in the product's own words what the product would (a field a screen does not take, a label over 40 characters, two rules for one field) — samples/s21_field_rules/tests/. Then start a till on a sandbox.

Technical notes

What was proven where

Proven on our test bench on 2026-10-08 (iVendNext POS app at 577a8d41), run pp-20261008T125051Z-84203, 6 of 6 checks:

Install: the four rows on the named theme.
The till's start (pos_fields.rules_for_boot over the till's own POS Profile) reads all four.
A new customer without a phone, through the till's own create as the cashier: refused at once by the server — "Phone is required here."; with a phone, created.
Uninstall: exactly these rows removed; the theme's rows as before and the till's profile wearing what it wore.

Not run here: how each screen draws the rules (a browser walk), a rule in a cashier's own language, show, a theme renamed before uninstall (row WAVEB proved that one on 2026-10-08). Field rules change no booked value, so there is no money-kit label.

This page in the kit