System overview
Restaurants, licenses and server health.
Restaurants (active / all)
—
Ending within 7 days
—
Users
—
Database size
—
Subscription revenue this month
—
All restaurants
| Restaurant | Plan | Users | Menu items | Transactions | Data size | Subscription | Status | Registered | Actions |
|---|
Server resources
Database
Restaurants
Every restaurant on the platform, with its license and fiscal state.
| ID | Restaurant | Status | Certificates | Packages for PURS | Actions |
|---|
Usage and database
Postgres connections, database size and usage per restaurant.
Connections in use
—
Database size
—
Queries over 30 s
—
Connections by state
Connections by application
Long-running queries
Query text is not shown: it can contain restaurant data.| Process | State | Application | Waiting for | Running for |
|---|
| ID | Restaurant | Database schema | Database tables | Menu items | Users | Transactions | Data size |
|---|
System health
Automatic checks of the database, payments, POS terminals and server, plus live process figures.
Last 20 payments
Paid, then subscription extended, then POS terminal certificate issued.| Time | Restaurant | Plan | Amount | Order | Gateway | Paid | Extended | Certificate | Result |
|---|
System details
Audit log
Every payment, subscription change and operator action, with filters and CSV export.
Events
—
Restaurants involved
—
Paid orders
—
Revenue
—
Refreshes every 60 seconds while this page is open.
Sign-ups
Restaurants that signed up, and sign-ups that stopped before the e-mailed code.
Signed up
—
Active trials
—
Have paid
—
Not finished
—
Backups
Every restaurant, the platform data and the menu photos, encrypted and stored in Cloudflare R2 every 6 hours. Kept 30 days plus one backup per month for 12 months.
Recent restores (30 days)
POS terminals (database backups)
Each POS terminal's own database, encrypted in R2.
Backups
Support
Reports, questions and feature requests from restaurants, one conversation per ticket. Replies also go to the restaurant's e-mail.
Open
—
Answered
—
Solved
—
Support
Reply
Email log
Every e-mail the platform sent or tried to send, kept one year. The text of the e-mail is not kept.
Sent, 24 hours
—
Sent, 7 days
—
Failed, 7 days
—
Through the backup server, 7 days
—
Invoices
Every subscription invoice ELV issued: SEF e-invoices and invoices outside SEF with the individual VAT record.
Transactions
Every subscription payment from every restaurant. Read-only: confirm or refund in Payment check.
Paid
—
Pending
—
Failed or cancelled
—
Refunded
—
Payment check
Compare a subscription payment in Monri with what the platform recorded.
Help
What each menu is for, and answers to common questions.
Website SEO
Title and meta tags of the marketing site. Changes are live on the website at once.
Search result
Google preview
Social sharing (Open Graph)
Blog
Articles on the website. Save a draft or publish without a deploy.
New article
PreviewPlain paragraphs. Use ## heading, ### subheading, - list items, **bold**.
Frequently asked questions
Optional. Used for the FAQ schema on the article page.
Plans and pricing
Prices on the website and in the Admin panel, RSD with PDV.
Organizations and branches
Group the restaurants of one customer as branches, for a consolidated report.
POS terminal releases
Upload the installer and its release.json from build-installer.ps1. POS terminals check the signature themselves.
Upload a release
ELV LPFR packages for buyers, two channels. Sandbox package (the one PURS reviewed): node scripts/sign-release.js ELV-LPFR-verzija-2.zip lpfr-test --version 0.8.2 --expect-sha256 214bb3dffb86ec0a662b3def4cfca48bfdd76b3e3d7a7e51f38dc7acecd3ba8f. Production package (live SUF): node scripts/sign-release.js ELV-LPFR-verzija-2-produkcija.zip lpfr --version 0.8.2 --expect-sha256 <SHA-256 of the production package>. Sign on your PC (the script refuses a file whose hash differs from --expect-sha256), then upload the .zip and its release.json here. Buyers download both from "My licences" on the website; POS terminals never receive them.
Android app for waiters (PDA): build it with build.ps1 in the AllurePOS-PDA repository, then sign it in the AllurePOS repository on your PC: node scripts/sign-release.js AllurePOS-PDA-1.0.0.apk pda-android --version 1.0.0 --changelog CHANGELOG.md (full paths to the APK in AllurePOS-PDA/dist and to that repository's CHANGELOG.md). Upload the .apk and its release.json here. Restaurants download it from Admin → Uređaji; POS terminals never receive it.
| Version | Channel | Size | Status | Release notes | Actions |
|---|
L-PFR licences (per fiscal card)
One licence per fiscal card (JID + PIB). POS terminals renew it every day; an expired or revoked licence refuses new sales only.
| Card / PIB | Taxpayer | Holder | Type | State | Valid until | Last check-in | Actions |
|---|
Cards that checked in and did not get a paid licence automatically. Also a list of potential customers.
| Card / PIB | Taxpayer | Why | Seen | Actions |
|---|
A new card reported the PIB of a paid licence. It got a 14-day provisional licence. Transfer moves the remaining paid period to the new card for free.
| Old → new card | Taxpayer | Reported | State | Actions |
|---|
A code from the seller activates a paid licence for one fiscal card: the customer types it on the L-PFR operator page. A vendor's unused codes hold its quota; a redeemed code uses it; revoking an unused code or letting it expire gives it back.
| Code | Batch | Created | Licence | Seller | Buyer | Only for PIB | Code valid until | State | Redeemed by | Actions |
|---|
ESIR vendors buy licence-years in advance and hand them to their customers' cards. Issuing or extending uses their quota; daily renewals and transfers are free.
| Vendor | ESIR | Contact | Quota left | Active | State | Actions |
|---|
Settings
Prices and periods are settings, not code. Limits the L-PFR accepts: trial and provisional at most 14 days, grace at most 30, renewal window at most 45.
Periods
Cards and activation codes
Prices, e-mail and support
Issuer certificates
Platform settings
Defaults stored in the platform database.