The guard rails on a price, and which of them are real — 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 is about to design a pricing policy around the boxes on a price record. In about thirteen minutes you will know which of those boxes the platform actually enforces, which merely warn somebody in a browser, and which are schema placeholders that have never been wired to anything — so your policy rests on the ones that hold.

Step 1 — Treat the minimum price as a warning, not a rule

After this step you will know exactly how strong the minimum price is. It is compared against the typed price by the line editor, and only when the applet setting that disallows selling below the minimum is switched on. A user holding the matching permission walks past it. A line that has been through the approval dialog walks past it. And no validator, no job processor and no part of the finalise path on the server checks it at all, so an import or an API call is never stopped by it. It is a real and useful control over people typing at a screen. It is not a control over your data.

Reference: Doc Item Maintenance — Pricing Scheme tab

Step 2 — Stop relying on the maximum price entirely

After this step you will know something the screen gives no hint of. The maximum price is stored, exported, copied between schemes when you use the Copy tab, and sent to the storefront in its product payload. It is compared with nothing, anywhere, in any layer. There is no ceiling check in the browser and none on the server. Twenty tenants have filled it in on about eighty-eight thousand price rows, which is a fair amount of careful work resting on a column that does not act. If you need a ceiling, the control that exists is the separate setting that refuses a price above the standard price, and that one is also browser-only.

Reference: Doc Item Maintenance — Pricing Scheme tab

Step 3 — Do not expect a price to expire on its date

After this step you will stop planning around a validity window. A price row has a start and an end date. The queries that hand prices to a sales line never filter on them, so an expired row is returned exactly as a live one and can be selected exactly as a live one. Only two screens read those dates at all — the till’s item search and the Sales Order version two item search — and they read them for one purpose, to decide whether to show the promotion price or the ordinary one. Across the platform both dates are set on about three hundred and ninety rows in six tenants, which is roughly the number of people who have tried this and moved on.

Reference: Doc Item Maintenance — Pricing Scheme tab

Step 4 — Learn the two columns that are pure decoration

After this step you will recognise the strongest form of this problem. Beside those dates sits a tick called Valid Date Check, which looks like the switch that turns the window on. It is written by nobody and read by nobody: it is serialised into the price interface and dropped. It is null on all twelve million price rows in all sixty-six tenants that hold any. Beside the promotion price sit its own two promotion dates, which no front end reads either — the window the till honours is the row’s general one. A control that is never written, never read and never wrong is the hardest kind to notice.

Reference: Doc Item Maintenance — Pricing Scheme tab

Step 5 — Know which boxes are placeholders

After this step you will stop proposing features that are only columns. Three things on this record were added to the database and never connected to anything: the price-range pair, and two pairs that would set a minimum price as a percentage of the unit price or of the purchase price. There is no form control, no interface field, no storefront payload and no consumer in any of the four hundred and forty-nine applet repositories. They survive in the front end as a translated drop-down label and nothing more. The quantity bands are a gentler version of the same thing: this screen writes them, the storefront receives them, and no consumer anywhere enforces an order quantity against them.

Reference: Doc Item Maintenance — Pricing Scheme tab

Step 6 — Build on the two that hold

After this step you will know where the load-bearing controls are. Two boxes on this record genuinely drive behaviour. Validity Period in days decides how long the membership points earned on that line last, defaulting to three hundred and sixty-five when it is zero. Follow Child Pricing decides whether a bundle parent’s price is recomputed when one of its children changes, and it is the one column on this record used as a real condition in a query. Everything else here is either advisory, like the minimum price, or inert. Put your enforcement where enforcement lives — permissions, approvals and the price list itself — and use these boxes to record intent, not to impose it.

Reference: Doc Item Maintenance — Pricing Scheme tab

How the steps fit together

    flowchart TD
  subgraph R["Real"]
    V["Validity Period (days)<br/>membership point expiry"]
    C["Follow Child Pricing<br/>bundle parent reprice"]
  end
  subgraph A["Advisory — browser only, bypassable"]
    M["Minimum price"]
  end
  subgraph N["Inert"]
    X["Maximum price"]
    D["Valid Date Start / End"]
    K["Valid Date Check"]
    Q["Min / Max Qty per Order"]
    P["Price range, % of unit price"]
  end
  

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.

Back to the series · Play this as a presentation