Which price list the document opened with — transcript

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This lesson is for whoever gets asked “why did this invoice come out at that price”. In about twelve minutes you will be able to answer it in order, rather than guessing, because the decision is made in three places and only the first of them is the setting most people go and check.

Step 1 — Start with the branch, not the applet

After this step you will check the right setting first. When a sales applet opens a line it reads the branch’s own Default Pricing Scheme — the field on the branch record, set in the Organisation applet — and only when the branch has none does it fall back to the applet’s own Default Selection setting. Most people go straight to the applet setting, and on a tenant where branches are configured that setting is never consulted. Both halves are in daily use: across all ninety tenant databases a branch default is set on about nine hundred and thirty branches in forty tenants, and left empty on about one thousand eight hundred branches in seventy-five.

Reference: Doc Item Maintenance — The price on a document line

Step 2 — Know when neither default is consulted at all

After this step you will recognise the case that skips both. If the item is priced on exactly one scheme, the picker applies that one and disables the drop-down, and no default is looked at. Only when the item has more than one price does the picker go looking: first for the customer’s own Pricing Scheme field, and only then for the default from step one. That customer field is a genuine override and rare — about four hundred and forty customer records in fourteen tenants carry one, against eight and a half million records in eighty-five tenants that do not. The tenants that do use it are usually the ones running a business-to-business storefront, because the entity-aware catalogue prices from exactly that field. So on most tenants the answer is the branch, and on a new item with one price it is neither.

Reference: Doc Item Maintenance — The price on a document line

Step 3 — See why the drop-down offered what it offered

After this step you will understand a list that sometimes looks arbitrary. The server returns every price row for that item whose status is active, with no ordering at all, and the picker keeps one row per scheme — the last one the unordered result happened to contain. That is invisible while each item has one row per scheme. It stops being invisible when an item carries a second unit of measure, because a second unit means a second row on the same scheme. Measured, twenty-seven thousand scheme-and-item pairs in forty-two tenants hold more than one active row, against eleven million pairs holding exactly one in sixty-six tenants.

Reference: Doc Item Maintenance — The price on a document line

Step 4 — Learn where the role permission really bites

After this step you will stop relying on a control in a place it does not apply. The Role to Pricing Scheme link decides which schemes a role may sell at, and the till honours it: POS sends the role’s permitted schemes to the price query and gets back only those. The shared picker used by Sales Invoice, Sales Order, Sales Quotation and the purchase documents collects exactly the same list and never sends it, so in the back office the drop-down offers every scheme the item is priced on, whatever role the user holds. Eleven tenants have this permission configured at all, on about two hundred and ten rows. If you are using it to keep staff off wholesale prices, it is doing that at the counter only.

Reference: Setting Up Pricing Schemes — Step 3: Say which scheme each applet sells at

Step 5 — Expect the till and the back office to disagree

After this step you will know why scanning and searching can give different prices. The counter has two routes into the price table. The barcode scan joins it with a condition that the price row is active. The label and text search, a few lines away in the same class, joins it with no status condition at all, so a price somebody deleted can still be offered in Add Item results while the same item scans at the price you expect. The symptom the counter reports is that the search shows an old price, and the give-away is that scanning gives a different answer from typing the name. Until the join is fixed, scan rather than search after a price list has been cleaned up.

Reference: POS General — Branch Settings — what each tab actually reaches

Step 6 — Read what selecting a price actually stamped

After this step you will know what to look at on a finished line. Choosing a price copies onto the line the unit price inclusive and exclusive of tax, the minimum price, the replacement and reference prices, a tax code, rate and type that may not be the scheme’s at all, and one more thing that is easy to miss: the identifier of the price record it came from. That identifier is the only thread from a posted invoice line back to a price list, and it is what makes the next two lessons possible. The tax triple is the subject of the next lesson, because where it comes from is not where anybody expects.

Reference: Doc Item Maintenance — The price on a document line

How the steps fit together

    flowchart TD
  A["Branch record<br/>Default Pricing Scheme"] -->|"empty?"| B["Applet setting<br/>Default Selection"]
  A --> C{"How many schemes<br/>is the item priced on?"}
  B --> C
  C -->|"exactly one"| D["That one is applied<br/>drop-down disabled"]
  C -->|"more than one"| E{"Customer has<br/>a scheme?"}
  E -->|yes| F["The customer's scheme"]
  E -->|no| G["The default from above"]
  D --> H["Line stamped: price, minimum,<br/>tax triple, price-row id"]
  F --> H
  G --> H
  

Check yourself

Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.

Next: The tax on the line is not the price’s tax · Back to the series · Play this as a presentation