Who is allowed to give a discount?

Ask a shop owner who is allowed to give a discount and you usually get a name. Ask who is allowed to void a sale, refund a card payment, change a price after it was agreed, or see what a screen cost you, and the answer is normally the same name, followed by "well — everyone can, really, but they wouldn't."

That is not a permission model. It is a hope, and it holds right up until a Saturday when the person you trust is on lunch.

The problem is not theft

It is worth saying plainly, because the conversation usually starts in the wrong place. The reason to control who can discount is not that your staff are stealing from you. In most shops they are not.

The reason is that an unrecorded decision cannot be reviewed. If anyone can knock £15 off, then at the end of the month you have a margin that is lower than your pricing says it should be and no way to find out why. The individual decisions were probably all reasonable. Collectively they are invisible, and invisible is the part that costs you.

Four actions worth separating

Most of the damage comes from four actions that are usually bundled together because they all live near the till:

Discounting. Reducing the price of something before it is paid for.
Voiding. Removing a sale that has already been rung up.
Refunding. Sending money back out after it has come in.
Seeing cost. Knowing what you paid for the thing on the shelf.

They are different risks with different answers. A Saturday assistant probably should be able to take a payment and probably should not be able to refund one. A technician needs to order a part and does not need to know its margin. Your accountant needs every figure in the building and should never be able to issue a refund.

Once you write them out like that, the bundle stops looking sensible. Nobody actually wants one switch labelled "trusted" — they just never had four.

"Hidden" is not the same as "not allowed"

Here is the part that catches a lot of systems out, and it is worth checking on whatever you use today.

There is a difference between a button that is not shown and an action that is not permitted. If the rule lives only in the screen, then the rule is decoration: it holds for the person clicking, and it does not hold for anything that reaches the data another way.

The test is simple enough to ask a vendor. Where is the permission enforced — in the interface, or in the database? If the answer is only the first, then what you have is a tidier screen, not a control.

The same question applies to figures rather than actions. Hiding a cost column is not the same as a role that cannot read cost at all. One is a layout choice. The other is a boundary.

Roles are how you stop over-granting

The practical failure in small shops is not too few permissions. It is that handing someone a login feels risky, so the owner keeps their own account logged in at the counter, and everyone uses it.

That single habit destroys every audit trail you have. "Who authorised this refund" has one answer for the whole shop and it is you. Six months later, when you actually need to know, there is nothing to find.

Giving everyone their own login is only safe if a login can be limited. That is the whole argument for roles: not bureaucracy, but the thing that makes individual accounts affordable. Once a sales role genuinely cannot refund, you can hand out sales accounts freely — and the audit trail starts naming people instead of naming you.

What to look for

If you are assessing this on a system you already run, or one you are considering, four questions get you most of the way:

Can two people on the same till have different powers, without one of them sharing the other's password?
Is discounting separable from refunding, and refunding from voiding?
Can someone be allowed to use an item without being allowed to see what it cost?
When something is overridden anyway — because sometimes it has to be — does the system record who allowed it and why, or does the exception just happen?

The fourth is the one people forget. A control that cannot be overridden gets worked around, and a workaround leaves no record at all. The goal is not to make the exception impossible. It is to make it visible.

The honest version

Every shop overrides its own rules sometimes. A regular customer, a job that went badly, a goodwill discount at the counter — these are good decisions and they should stay possible.

What should not stay possible is making them anonymously. If you can answer "who discounted this, and why" three months later, the system is doing its job. If you cannot, then the £15 was never really the problem.

In SlickCell Pro this is five roles — owner, manager, technician, sales and accountant — enforced by database policy rather than by hiding buttons, with cost visibility handled as a separate decision from the actions themselves. Workforce and roles covers how they are assigned, and Security covers where they are enforced.