// Mini POS wiki
Pricing & Discounts
How Mini POS lets a cashier change a price without letting them give the store away: line and whole-ticket discounts, price overrides, the cap/floor rules, supervisor PIN authorization, and the reason-code audit trail. Enforcement lives in the pricing engine and the sale-line validation — never only in the screen.
Task Guides: Cashier Day | Supervisor Operations | Profile Tests
Pricing & Discounts
How Mini POS lets a cashier change a price without letting them give the store away: line and whole-ticket discounts, price overrides, the cap/floor rules, supervisor PIN authorization, and the reason-code audit trail. Enforcement lives in the pricing engine and the sale-line validation — never only in the screen.
The pricing governance engine See status matrix
What it is
All discount and override rules are decided by one codeunit (BAA POS Pricing Mgmt): pure Check procedures the UI consults, plus Apply helpers that stamp the change and validate through the table triggers. Both the register and the back-office Sales Card go through the same engine, so a rule can't be bypassed by using a different screen. The register additionally shows an always-visible badge on any discounted or re-priced cart line, so a changed line never looks identical to a normal one.
Where to find it
Cashier: the pencil (edit) glyph on a cart line (line price/discount) and the Discount button in the register action bar (whole-ticket). Admin: the discount/override toggles on POS Setup.
Setup
| Field (POS Setup) | Default | What it does |
|---|---|---|
| Allow Line Discount | on | Enables per-line discounts (% or amount). |
| Allow Invoice Discount | on | Enables whole-ticket discounts, distributed across lines. |
| Default Max Discount % | 0 | Company-wide cap a cashier can grant without a supervisor. A POS User can carry a personal cap that overrides this. |
| Require Discount Reason | off | A reason code is mandatory on any discount. |
| Supervisor For Over-Limit Discount | on | When on, a discount above the cashier's cap can be authorized by a supervisor PIN; when off, over-cap is simply refused (no approval path). (Field name Supervisor Over-Limit Disc.) |
| Allow Price Override | on | Enables changing a line's unit price. AND-gated with each POS item's own Allow Price Override flag. |
| Price Override Never Below Cost | on | Floors the override at the item's cost. (Field name Price Override Not Below Cost.) |
| Min Margin % | 0 | Floors the override at the minimum-margin price (cost ÷ (1 − margin)). |
| Require Price Override Reason | off | A reason code is mandatory on any override. |
| Supervisor For Price Override | on | A price override needs a supervisor PIN for users without Can Override Price. |
The Default column reflects the value on a newly created POS Setup record (the field InitValue). Existing provisioned companies are backfilled to the same values by BAA POS Upgrade. The six governance toggles therefore ship on — discounts and overrides are available after setup, with reason-required and cap/margin fields permissive until an administrator tightens them. These policy rules are company-wide; applicable user authority can vary by POS User, but there is no current per-store pricing-governance override.
Notes & limits
- An invoice-only configuration is legal: turn Allow Invoice Discount on and Allow Line Discount off, and the register grants whole-ticket discounts while refusing line ones.
- The screen only gates the display; every Apply re-enforces all the hard rules (toggles, floors, reason-required) server-side.
- Money precision. Derived line totals, discount amounts, tax, floors used for comparison, and distributed shares are normalized through the central
BAA POS Money Policyusing the currency's configured BC Amount Rounding Precision (company LCY when the sale currency is blank). Unit Price retains its supported 2–5 decimal precision instead of being flattened to the accounting amount precision. The invoice-discount distribution normalizes each monetary share and lets the final line absorb the remainder so the sum equals the granted discount. - Currency. Item prices are LCY in this version; a general multi-currency / exchange-rate item-price path is planned, not built — a real non-LCY sale price and FX conversion are out of scope today, so the money-precision machinery uses LCY precision for the floors.
Retail, wholesale & Business Central price lists
What it is
A mapped POS item is priced by the standard Business Central price calculation engine, not by a second Mini POS price table. Mini POS builds a temporary sales header and line from the frozen sale context: sell-to and bill-to customer, customer price group, store location, item, variant, unit of measure, quantity, document date, and currency. It then records the selected Business Central price/discount source on the POS line. An unmapped POS-only item uses its POS Item Unit Price as the fallback and cannot be posted until it is mapped.
Pricing Profiles choose which Business Central Customer Price Group is supplied to that calculation. The automatic context order is: an already approved manual switch, an approved loyalty-tier profile, the mapped BC customer's own Customer Price Group, a POS-customer scope, Customer Type, Store, Register Profile, then compatibility fallback. Within the same scope, the higher profile Priority wins; equal priorities use profile Code order.
Where to find it
Tell Me → Pricing Profiles. Maintain the actual prices, quantity breaks, dates, variants, and units of measure in standard Business Central Sales Price Lists / Customer Price Groups. On the register, the current pricing profile appears in the status bar; select it to request an allowed manual switch.
Setup
- Create and activate the Business Central Customer Price Groups and Sales Price Lists that own the commercial prices, for example
RETAILandWHOLESALE. - Create one active POS Pricing Profile per context. Set its Customer Price Group Code, effective dates, Priority, whether POS promotions may compete with the BC discount, and whether a manual switch requires supervisor approval.
- Add profile Scopes for a POS Customer, Customer Type (including Wholesale), Store, or Register Profile. A mapped BC customer with its own Customer Price Group is used before those automatic scopes.
How to use
- For normal retail, scope the retail profile to the store or register profile.
- For wholesale, map the customer to a BC customer carrying the wholesale Customer Price Group, or scope the wholesale profile to that POS Customer / Wholesale Customer Type.
- Attach or change the customer before tender. Mini POS requotes every open line. It also revalidates the frozen price context before tender or an external payment; if an authoritative price changed, the cashier must review the refreshed totals before money moves.
How to test
- Create different retail and wholesale BC prices for the same mapped item. Start a retail cash-customer sale, then attach the wholesale customer. Expected: the open line requotes to the wholesale price and the status shows the resolved profile/source.
- Create a variant- or quantity-specific BC price-list line, then use Price Check with that variant and change the quantity. Expected: each step is requoted server-side and shows the matching price and line total.
- Require supervisor approval on a profile and request it from the register. Expected: the profile does not switch until a supervisor authorizes it; the switch and reason are retained on the sale.
Notes & limits
- For mapped items, the POS Item's BC Unit Price field is a reference snapshot, not the sale-price authority.
- Automatic BC, POS item/customer, and loyalty-tier discounts compete as a best offer; they do not silently stack. Manual discounts remain a separately governed layer.
- Real foreign-currency selling and exchange-rate price conversion are not supported by the current register workflow.
Line discounts See status matrix
What it is
A discount on one cart line, entered as a percentage or a cash amount. The line shows a badge (e.g. −10%) so the change is visible on the ticket.
How to use
- Tap the pencil glyph on the cart line, choose Discount %, or Discount amount.
- Enter the value (and a reason code if required). If it exceeds your cap and supervisor over-limit is on, a supervisor PIN is requested.
- Confirm — the line recalculates and shows its discount badge.
How to test
- With Allow Line Discount on and cap 10%, discount a line 5%. Expected: applied, badge shows, no PIN.
- Discount 20% with Supervisor Over-Limit on. Expected: supervisor PIN requested; on valid PIN the discount applies and records the approver.
- Discount 20% with Supervisor Over-Limit off. Expected: refused with a "cannot be approved at this register" toast.
Invoice (whole-ticket) discounts See status matrix
What it is
A discount on the whole sale, distributed proportionally across its lines. Re-applying replaces the previous invoice discount (it is delta-based, never stacked).
How to use
- Register: press the Discount button in the action bar, choose % or amount, enter the value (and reason if required).
- Confirm — the discount spreads across the lines and the totals update.
How to test
- Sale with lines 10.00 and 30.00; apply a 4.00 invoice discount. Expected: 1.00 lands on the 10.00 line and 3.00 on the 30.00 line; sale total 36.00.
- Re-apply 8.00. Expected: total invoice discount is 8.00, not 12.00 — it replaces, never stacks.
- Apply a discount that needs a supervisor and enter a valid PIN. Expected: the discount applies with no "record was modified" error and the approver is recorded.
After an invoice discount is distributed, the page rereads the sale header before refreshing totals. If a "changes cannot be saved… not up-to-date" error appears, capture the current app version and AL call stack before retrying.
Price override See status matrix
What it is
Replacing a line's unit price outright. The original price is preserved and shown on the line as a was … badge, so the override is always visible and auditable.
How to use
- Tap the pencil glyph on the line, choose Price, enter the new unit price (and reason if required).
- If Supervisor For Price Override is on, a PIN is requested. The engine also refuses any price below the configured floor.
How to test
- Override a line to a price above the floor. Expected: applied; the line shows a "was …" badge.
- Override below cost with Price Override Not Below Cost on. Expected: refused with the floor price named.
Supervisor authorization See status matrix
What it is
When a change exceeds a cashier's authority, the POS Supervisor Auth dialog asks a supervisor to enter their PIN. The approving supervisor is recorded on the sale/line (Approved By), so every over-limit change names who authorized it. A cashier who is themselves a supervisor is never prompted.
Notes & limits
- PINs are salted SHA-256, not plaintext; the PIN is validated server-side.
- Supervisor gating is a soft escape hatch, not a hard gate — a hard floor (below-cost, min-margin) can never be authorized past.
Floors, margins & caps See status matrix
What it is
Two kinds of limit. A cap (Default Max Discount % or the cashier's personal cap) is the most a cashier can grant unaided; over-cap either refuses or asks a supervisor. A floor (never-below-cost and/or minimum-margin) is a hard limit no one can authorize past — the price is simply refused below it.
How to test
- Set Min Margin % to 50 and cost 1.00; try to override to 1.50. Expected: refused (floor is 2.00).
Reason codes & attribution See status matrix
What it is
When Require Discount/Override Reason is on, a standard BC Reason Code must be picked for the change. The reason and the approving supervisor are stamped on the sale/line and flow into telemetry, giving a complete "who changed what price and why" trail.
How to use
- Create reason codes in BC (Reason Codes page). Turn on Require Discount Reason / Require Price Override Reason.
- Cashiers now must pick a reason before any discount/override applies.