Audit and telemetry

Bitta Retail POS keeps two separate records of what happens at your registers. Publisher telemetry goes to Bitta Apps so problems with the app can be found and fixed, and it never contains your business data. Audit evidence stays in your Business Central company, where managers and administrators review it in the app's own pages and reports. This page explains both, and shows where to look when you need to diagnose a problem.

Prerequisites

• The BAA POS - Admin permission set, or BAA POS - Full, for POS Audit Events, POS Repair Exceptions and the POS Operational Audit report. See POS user permissions.
• BAA POS - Supervisor or BAA POS - Admin for Commerce Audit.

What Bitta Apps receives

The app sends operational signals to Bitta Apps' own Application Insights resource. Every signal is emitted with the extension publisher telemetry scope, so it reaches the publisher's resource only, and it is classified as system metadata.

Each signal has an event ID in the BAAPOS-#### series and the app version. The other values are limited to fixed categories, enum names, yes/no flags, counts and durations. Examples of what is reported:

• the extension was installed, a sale was posted, an End of Day run finished;
• a card payment started, was captured, failed or was refunded;
• a receipt print job was sent or failed, with a fixed failure category;
• the license blocked an operation, with a reason such as trial ended.

The app never sends store codes, terminal IDs, setup or reason codes, POS user numbers, customer or item names, monetary amounts, payment provider responses or error text.

Review POS audit events

POS Audit Events is a read-only list of operational evidence written by the app: sale cancellations and reopens, supervisor approvals, discount reductions, cashier switches, register access and lease events, no sale and other cash movements, refunds, shift open and close, End of Day posting, configuration and credential changes, and posting or post-notification problems that need attention.

1. In Tell Me, search for POS Audit Events and open it. The newest events are at the top. Each row shows Event Type, Outcome, Reason, Store, Terminal, Actor, Approver, Document and Shift.

2. If you suspect audit evidence is missing, choose Repair Pending Audit. The app retries evidence that is still queued, without rerunning the original operation, and reports "Audit repair completed. Materialized events: ... Dead-lettered events: ... Pending events: ...".

To see failures only, filter Is Exception to Yes. Evidence Count and Evidence Fingerprint identify the exact set of records an event covers without exposing their contents. Credential changes record only that a key was set or cleared, never the key itself.

Print the Operational Audit report

The POS Operational Audit report prints the same audit events with filters, in an RDLC layout or an Excel layout.

1. In Tell Me, search for POS Operational Audit, or open POS Report Center and choose Operational Audit in the Audit group.

2. Set Event From and Event To (they default to the whole work date), choose Exceptions Only or clear Successful Events to narrow the output, and pick Sort by Type, User or Terminal. You can also filter on store, terminal, actor, approver, event type, outcome, document, reason and source fields. Then run the report.

For the other audit reports in the Report Center, see All POS reports.

Check repair exceptions

When an upgrade finds a historical record it cannot link automatically, for example a settlement or loyalty accounting entry from an older version, it writes a row to POS Repair Exceptions instead of guessing. Open it from Tell Me or from Troubleshooting on the Bitta Retail POS Admin Role Center. Each row shows the Status (Open or Resolved), the Exception Type, a Sanitized Reason and the source table and record. The page has no actions; contact Bitta Apps support with the exception type and detected time if open rows remain.

Inspect a sale line with Commerce Audit

To see why a line was priced the way it was, open the sale in POS Sales, select the line and choose Commerce Audit. The card shows the frozen pricing authority, the Business Central price and discount sources that were observed, the estimated and actual cost, and the source and posted Business Central documents, with Open Source Document and Open Posted Document actions.

Retention of audit and evidence data

When a company is set up, Bitta Retail POS registers its evidence tables with the Business Central retention policy feature. Each table is registered with a locked filter that limits which records a retention policy can delete and how old they must be:

Table	Records the locked filter allows	Age in the locked filter
POS Print Queue	Completed print jobs	30 days
POS Audit Event	Audit events past their Retention Date (event date plus seven years)	7 years
POS Posted Daily Sales	Posted rows	7 years
POS EFT Transaction	Captured, failed, cancelled or refunded transactions that do not need attention	7 years
POS Shift	Closed shifts	7 years
POS Posting Claim	Completed or cleared claims	7 years
POS Post Notification	Delivered or dead-lettered notifications	7 years

Bitta Retail POS only registers these tables; it does not create or enable any retention policy. Deleting old records is up to the retention policies your administrator sets up in Business Central.

What's next

Use what you found here to fix the problem: Troubleshooting. Developers who react to posted sales should also read Integration events.