Pricing and discounts setup

How Bitta Retail POS decides what an item costs and how far a cashier can move that price: Business Central price lists as the pricing authority, Pricing Profiles for retail vs wholesale contexts, and the governance rules for discounts and overrides - caps, floors, supervisor PINs, and reason codes. For the cashier-side steps at the register, see Discounts and price overrides.

Business Central is the price authority

A mapped POS item is priced by the standard Business Central price calculation engine, not by a second POS price table. Bitta Retail 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 - and records the selected Business Central price and 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.

Maintain the actual prices, quantity breaks, effective dates, variants, and units of measure in standard Business Central Sales Price Lists and Customer Price Groups. When a scanned barcode carries an alternate unit of measure, the price uses the item's Qty. per Unit of Measure - see Barcode setup.

Attaching or changing the customer requotes every open line, and the frozen price context is revalidated before tender or an external payment; if an authoritative price changed, the cashier must review the refreshed totals before money moves.

Pricing Profiles (retail vs wholesale)

Pricing Profiles choose which Business Central Customer Price Group is supplied to the 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.

Set them up from Tell Me -> Pricing Profiles:

1. Create and activate the Customer Price Groups and Sales Price Lists that own the commercial prices, for example RETAIL and WHOLESALE.
2. Create one active POS Pricing Profile per context: 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.
3. 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.

On the register, the current profile appears in the status bar; selecting it requests an allowed manual switch. 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.

Discount and override policy

All discount and override rules are decided by one engine: pure Check procedures the UI consults, plus Apply helpers that stamp the change and validate through the table triggers. The register and the back-office Sales Card go through the same engine, so a rule cannot be bypassed by using a different screen, and every discounted or re-priced cart line carries an always-visible badge.

Configure the policy on POS 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.
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.
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.

These toggles ship on for a new company, with the reason-required and cap/margin fields permissive until an administrator tightens them. The policy is company-wide - user authority varies per POS User, but there is no per-store pricing-governance override.

Per-user authority

Each POS User carries a personal Max Discount % (overrides the company default when above 0), a Can Override Price flag, and a Supervisor flag. See Stores, terminals, and users for the full user setup and Security, PINs, and lock screen for how supervisor PINs work.

Caps vs floors

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 for a supervisor PIN, depending on the setup toggles.
• 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, supervisor or not.

Reason codes and attribution

When Require Discount Reason or Require Price Override Reason is on, a standard BC Reason Code must be picked before the change applies (create them on the BC Reason Codes page). The reason and the approving supervisor (Approved By) are stamped on the sale line and flow into telemetry, giving a complete "who changed what price and why" trail. Price overrides also preserve the original price and show it as a "was ..." badge on the line.

Notes and limits

• The screen only gates the display; every Apply re-enforces the toggles, floors, and reason requirements server-side.
• Monetary amounts are normalized centrally at the currency's configured BC Amount Rounding Precision; unit prices keep their supported 2-5 decimal precision. An invoice discount is distributed proportionally and the final line absorbs the rounding remainder, so the sum always equals the granted discount.
• Item prices are LCY in this version. Real foreign-currency selling and exchange-rate price conversion are not supported by the current register workflow.