Reports & Transaction History
Every API call and every data conversion is logged to the database with full payloads, timing and success flags. The Reports screen (/pckzra/reports) is the window into that audit trail.
What is logged
| Record | Contents |
|---|---|
API transactions (api_transactions) | Full request/response headers and bodies, HTTP status, success flag, response time in ms, store ID, transaction ID |
Conversion logs (conversion_logs) | Source and target data, mapping rules applied, validation errors, processing time, conversion success flag |
Fiscal invoices (fiscal_invoices) | Every issued receipt: audit number, receipt number, SDC ID, store, TPIN, refund linkage — used for credit note lookups |
CleanupOldTransactions stored procedure exists for manual, deliberate cleanup only.
Available reports
Transaction statistics
Total, successful and failed transaction counts with a computed success rate. Filter by store and date range. This is the first place to look when assessing system health.
Transaction history (paginated)
The full transaction list with pagination. Each row links to a transaction detail view showing the complete request and response pair — the exact JSON the POS sent and what the middleware (or Chrilan) answered.
Failed transactions
Pre-filtered view of failures, defaulting to the last 7 days. Each failure keeps the error body, so most diagnosis happens here without touching the server.
Conversion reports
Paginated conversion history, plus a failed conversions view. Use this when a payload was received but could not be translated — e.g. a missing TrxInfo link or a blank required field.
Volume by store
Transaction counts grouped per store. A store with zero volume during trading hours usually indicates a local (POS/network) issue rather than a middleware issue.
Following a single transaction
Every request is assigned a transaction ID (UUID) at the door, before authentication. The same ID is attached to:
- The inbound POS request log
- The store lookup (the record is tagged with the store ID once resolved)
- The conversion log (Taxint → Chrilan)
- The outbound Chrilan request/response log
- The final response log back to the POS
To investigate a reported problem: get the store name and approximate time from the reporter, find the transaction in Reports, and open the detail view. The full chain of evidence is on one screen.
Reports REST API
Everything on the Reports screen is also available programmatically — see the Reports API reference for endpoints such as GET /api/reports/statistics, /transactions/failed and /volume-by-store. The Swagger UI at /pckzra/swagger-ui.html lets you try them interactively.
Typical investigations
| Question | Where to look |
|---|---|
| “Did store X's sale at 14:32 reach ZRA?” | Transaction history filtered by store and time; check the Chrilan response body for rcptNo |
| “Why did the receipt not print?” | Failed transactions; check HTTP status and error body (403 = store issue, 400 = payload issue, 500 = Chrilan/upstream) |
| “Is the system slower today?” | Response time (ms) column in transaction history; compare against the baseline |
| “Which store has the most failures?” | Volume by store + failed transactions filtered per store |