Which pricing scheme each applet and till sells at
Step 3 of setting up pricing schemes: decide which scheme each branch, applet and till sells at. The schemes and their prices already exist (Steps 1 and 2), and How a line gets its price explains the order this step sets. GadgetSphere sells at Retail in its 22 branches, Member to loyalty customers and Wholesale to the distribution company’s corporate clients, from one set of item prices.
- Step 3: say which scheme each applet sells at.
Step 3: Say which scheme each applet sells at
This is the step that decides what actually happens, and there is more than one place it is decided.
The branch comes first, not the applet. When a sales applet opens a line it takes the branch’s own Default Pricing Scheme — the field on the branch record, set in Organisation > Branches > edit — and only falls back to the applet’s Settings > Default Selection > Default Pricing Scheme when the branch has none. Both arms of that rule are live, so when one branch sells at a scheme the others do not, look at the branch record before you touch the applet setting.
Then the picker decides what to open with, and it does not always honour either of those. If the item is priced on exactly one scheme, that one is applied and no default is consulted at all. Otherwise it looks for the customer’s own Pricing Scheme field, and only then for the default above. The customer field is a real override, and it is blank unless somebody filled it in — which is what makes it easy to miss. One scheme saved on one customer record quietly outranks every default you set.
POS has two more layers that the back office does not:
- Branch Settings > Pricing Scheme, with a priority — a second, POS-only branch mechanism, separate from the branch record’s own Default Pricing Scheme above. It is read by the Add Item panel, where the highest-priority scheme the item has a price in wins. A scanned barcode ignores it and prices at the branch record’s Default Pricing Scheme (or the applet default), so a scanned item and a picked one can come in at different prices.
- Role ↔ Pricing Scheme Link — which decides which scheme a role sells at. This is the one that catches people: two cashiers at the same counter, on the same till, can be selling at different prices because they hold different roles.
The role link is a till control, not a company-wide one. POS sends the role’s permitted schemes to the price query and gets back only those. The shared price picker used by Sales Invoice, Sales Order, Sales Quotation and the purchase documents collects the same list and does not send it — the line that would is commented out — so in the back office the drop-down offers every scheme the item is priced on, whatever the user’s role. Nothing creates these role links for you either: they exist only where somebody sat down and built them.
If you are using the role link to stop staff selling at wholesale, it is doing that at the counter and not on a sales order. The POS setting Show All Pricing Schemes also switches the filter off at the till.
And the four tick boxes on that link are not doing anything. Each role-to-scheme row carries Sales Price Read, Sales Price Update, Purchase Price Read and Purchase Price Update. The screen writes all four and the till reads none of them: what it sends to the price query is the list of scheme identifiers, nothing else. No component in any applet repository and nothing in the backend consults the four flags, beyond a search filter on the maintenance listing itself. So a row with Sales Price Update unticked still lets that role’s cashiers change the price. Treat the row as a yes/no — this role may sell at this scheme — and do the rest with ordinary client-side permissions.
So when somebody asks why a price came out differently from what they expected, check in this order: whether the item is priced on only one scheme, then the customer’s own scheme, then the role link if they were at a till, then the branch record’s Default Pricing Scheme, then the applet default, then whether a price book discounted it afterwards.
What success looks like for this part
At GS-KV-01, a draft sales invoice for a customer whose own Pricing Scheme is blank opens the flagship smartphone at the price of the branch record’s Default Pricing Scheme (or, if that is blank, the applet’s default), and after you change the draft’s customer to a Member customer, delete the line and add it again, it opens at the Member price. Where you have built role links for your tills, a cashier in each of those roles is offered only the schemes the role is linked to, unless Show All Pricing Schemes is on. Then run the whole task’s success check.
Common mistakes in this part
| What goes wrong | What you see | The fix |
|---|---|---|
| No Default Pricing Scheme on the branch record or the applet | Lines come in with no price, or the wrong one | Set it on the branch record first; the applet’s Default Selection is only the fallback for branches with none. Reload after changing the applet setting |
| Two users getting different prices on the same till | Looks like a bug | The Role ↔ Pricing Scheme Link in POS decides per role |
| One branch pricing differently and nobody knows why | Looks like a bug | The branch record’s Default Pricing Scheme prices every back-office line and every scanned barcode there; POS Branch Settings › Pricing Scheme, with its priority, prices the till’s Add Item panel. Check both |
The rest of the task’s mistakes are on the front page and with Steps 4 and 5.
Next: Steps 4 and 5: Keep them in step, and find out why a price changed.
Related documentation
- Setting up pricing schemes — the whole task.
- POS General applet — branch and role pricing settings.
- Doc Item Maintenance applet — which scheme the picker proposes.