Bitta Retail POS guide

Loyalty program administration

Administer the governed multi-program loyalty model: Programs, versioned Rules and Tier Benefits, Memberships, Points/Visit-Stamp/Cashback/Tier types, balance adjustments, opening liability, breakage, expiry runs, and reports.

status: verified applies-to: 1.0.0.121rev: 1

Bitta Retail POS loyalty is a governed, company-scoped, multi-program model: you define Programs, attach versioned Rules and Tier Benefits, and the server enrolls Memberships, evaluates every sale deterministically, and keeps append-only ledgers with full accounting evidence. This page is the administrator's guide. For what cashiers see and do, read Customers and loyalty at the register.

The building blocks

  • Programs - the top-level policy container. A company can run several programs at once (for example a points program and a tier program side by side), and one customer can be a member of each.
  • Rules - the versioned earning and redemption policy attached to a program: what earns, at what rate, thresholds, and how value or rewards are granted. Activated rule versions are frozen; changes always go into a new version.
  • Tier Benefits - versioned benefit definitions for tier programs: an approved Business Central pricing context, an approved POS discount layer, or linked earn multipliers.
  • Memberships - the link between a customer and a program, carrying the governed balance, debt, tier, and expiry state. Membership and balance changes go through server-owned services only - nothing writes a balance directly.

Configuration is protected by validation and table guards: activated or referenced facts cannot be silently rewritten.

Administration workspace

Open the POS Admin Role Center and use the Loyalty Administration group: Loyalty Programs, New Loyalty Program, Loyalty Memberships, Loyalty Entries, Loyalty Balance Adjustment, Loyalty Rules, Loyalty Tier Benefits, and POS Repair Exceptions.

The four benefit models

Program type How members earn How members benefit
Points Governed earning per eligible sale Root-based Value redemption at the Tender screen; balance, debt, and expiry shown at the register
Visit / Stamp Visit- or quantity-based stamps Conversion to a Value reward or an Item Reward (a protected reward line for a mapped BC item)
Cashback Money-normalized earning Store-credit style Value redemption, precision-preserving
Tier Spend-based tier evaluation Approved BC pricing or POS discount benefits and linked earn multipliers; tier shown at the register

Redemption itself takes two forms everywhere:

  • Value redemption - redeemable value applies at the register as an internal Voucher tender line, durably reserved against the exact earned roots before completion and finalized atomically with the sale.
  • Item redemption (Item Rewards) - the member's earned reward creates a protected, mapped Commerce Authority line with exact item, variant, unit of measure, stock, tax, posting, return, and actual-cost identity. Standard BC posting owns inventory, Item Ledger, Value Entry, actual cost, and COGS.

Creating and activating a program

  1. Create the program (or start from a demo template - see below) and define its Rules, and for tier programs its Tier Benefits.
  2. For Points and Cashback programs, confirm the Voucher tender is active, visible at the relevant terminals, has a BC Payment Method, and settles to the intended direct-posting G/L account. Put that same account in Redemption Expense Account No. when accrual accounting is off.
  3. Choose Validate and resolve every named field error.
  4. Choose Activate. Activation freezes the evaluator version and the active policy fingerprints.

WARNING

Do not edit an activated policy in place - the guards will not let you silently rewrite referenced facts. Suspend the program, choose Create Policy Version, edit the new draft, validate it, and activate it. Members and balances carry forward; the versioned rules keep an exact history of which policy governed which sale.

Demo templates

In an evaluation company, run the Demo Data Guide to create four Draft program templates: DEMO-POINTS, DEMO-VISITS, DEMO-TIERS, and DEMO-CASHBACK. The templates are deliberately created as drafts - they do not activate a financial policy for you. DEMO-VISITS rewards mapped item DEMO-I1; DEMO-TIERS ships BASE/SILVER thresholds with a 5% approved POS discount for SILVER. Inspect each template's Rules, then follow the activation steps above. Draft templates are the provisioning path for demos; there is no legacy-loyalty conversion path because no earlier loyalty data model shipped.

Balances, adjustments, and liability accounting

Every earning, redemption, restoration, reversal, adjustment, opening liability, and breakage event is durably accounted, with exact G/L, customer-ledger, settlement, payment-line, and voucher-root evidence:

  • Loyalty Entries shows the append-oriented ledger.
  • Loyalty Balance Adjustment is the controlled path for manual corrections - adjustments are governed operations with accounting evidence, not direct edits.
  • Opening liability lets you grant starting balances (for example, honoring balances promised outside the system) with the liability booked correctly.
  • Breakage is recognized when value expires, with its own accounting trail.

Debt is a first-class concept: if a member returns a sale whose earning they already spent, the signed debt stays on the governed balance, available redemption is floored at zero, and later earning repays the debt first. Value restored to an already-expired root is re-expired immediately and never becomes redeemable.

Expiry scheduling

Scheduled expiry runs through the governed Job Queue owner. The hourly coordinator freezes one run timestamp per run, isolates each membership's work, and preserves retry evidence. Review runs on the Expiry Runs page and audit outcomes with the Loyalty Expiry Audit report.

Returns and repair

Partial, repeated, and final returns are persisted exactly for every program type and reward item: each return computes the program's cumulative frozen target and applies only the new delta, so a retry is idempotent and never duplicates ledger, activity, or accounting records. Two supervised surfaces exist for exceptional cases:

  • Loyalty Refund Recovery - for a return whose external payment refund captured but whose local finalization needs attention. Inspect the aggregate and its legs; never resend a captured refund.
  • POS Repair Exceptions - fail-closed exceptions that require exact source-data correction before rerun; the system never guesses missing financial provenance.

Reports

  • Loyalty Activity Report - program/customer/date filters over finalized Activity, Detail, and Ledger facts.
  • Loyalty Reconciliation Report - Member Balance, Ledger, Accounting, and Reversal evidence; use Attention Only to surface exceptions.
  • Loyalty Expiry Audit - Expiry Run, Detail, Ledger, and Accounting evidence by date and program.

Manager attention surfaces also flag member debt, expiring lots, refund recovery, and reconciliation items.

TIP

After activating your first real program, run one end-to-end drill before launch day: enroll a test customer, earn past the threshold, redeem at the Tender screen, print the receipt, return part of the sale, and check the Reconciliation report. See the register-side flow in Customers and loyalty at the register.

// next step

Ready to try Bitta Retail POS?