What actually stops a sale below cost — 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 has been asked to stop discounting below cost. In about twelve minutes you will know which switches to set, who to exempt, and — the part that matters most — what this whole family of controls does not reach.

Step 1 — Read the two halves as one rule

After this step you will stop looking for a single switch. Below-price control is always a pair. A setting named Disallow sell below… turns the rule on for the whole tenant, and a client-side permission named Allow sell below… exempts the people you grant it to. The rule only applies when the setting is on and the person does not hold the permission. That shape is deliberate and it is the right one for this job: the policy is a business decision made once, and the exemption is a personal trust decision made per person. This is the clearest example on the platform of a setting and a permission doing two different jobs on one behaviour.

Reference: Sales Invoice (Internal) — Applet settings

Step 2 — Know where the line-level block actually lands

After this step you will recognise the symptom. There are three line-level checks — below the item’s minimum price, below its replacement price, below its moving-average cost — and when one trips, the line is marked invalid and the Add button is disabled. Nothing is refused and nothing is logged; the button simply will not press, with an explanatory line under the price. One of the three has an escape the other two do not: a line that has been through the approval dialog is exempt from the minimum-price check, and only that one. So if approval clears a line and it is still blocked, you are looking at replacement price or cost, not minimum.

Reference: Sales Invoice (Internal) — Applet settings

Step 3 — Meet the document-level rule, which is the one people notice

After this step you will know why a finished invoice refuses to issue. A fifth switch works a level up: it adds the whole document’s lines and compares them with the summed moving-average cost, prints a selling below cost banner over the lines, and disables Final rather than Add. That is a different experience for the person doing it — the document builds normally, every line goes in, and then nothing happens when they try to issue it. It exists because discounting is usually done across a basket rather than on one line. The counter has its own copy of the same rule, and there it disables the payment button instead.

Reference: Sales Invoice (Internal) — Applet settings

Step 4 — Understand that none of this is the server

After this step you will describe the control accurately. Every check above is form validity in the browser. The server does have an equivalent rule — it sums the document against the summed cost and refuses to finalise — but it runs only when the finalise request specifically asks for it, and no applet on the platform asks. So the rule exists, has never been switched on by anything a person clicks, and is not protecting you today. The practical consequence is the one to remember: an import, an integration or anything driven through the interface is not stopped by these settings at all. They shape what your staff can do at a screen.

Reference: Sales Invoice (Internal) — Applet settings

Step 5 — Do not build on two switches that cannot work

After this step you will not waste an afternoon. Two entries in this family look like controls and are not. There is a key for disallowing a price below the standard price which has no toggle on the settings screen and no reader anywhere — a slip for the above standard price check, which is the one that really exists. And there are three keys that look as though they hide the minimum, replacement and cost figures from the message under the field; they have no control on the screen, so they are never written, so the guard behind them always passes. What really decides whether those figures are printed is a separate permission, granted per person.

Reference: Sales Invoice (Internal) — On the screen and doing nothing

Step 6 — Set up the way out before you need it

After this step your counter will not be stuck. Decide in advance who may override. There are two routes and they are not the same: a standing exemption, granted to a person, which lets them sell below the line forever; and an approval, where somebody else clears one particular line from a dialog without gaining a standing exemption. Grant the approval right to the people who would be called over anyway — a duty manager, a supervisor on shift — because that grant also decides who appears in the approver list the cashier is shown. Then write down which of your roles holds which, because nothing in the product will remind you.

Reference: Sales Invoice (Internal) — Who can change what

How the steps fit together

    flowchart TD
  s1["Step 1 — Read the two halves as one rule"]
  s2["Step 2 — Know where the line-level block actually lands"]
  s3["Step 3 — Meet the document-level rule, which is the one people notice"]
  s4["Step 4 — Understand that none of this is the server"]
  s5["Step 5 — Do not build on two switches that cannot work"]
  s6["Step 6 — Set up the way out before you need it"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5
  s5 --> s6
  

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