Run your counter on the computer

## Every shop, not only restaurants The app used to check the shop type when it connected, and close itself if the shop was not a restaurant. It no longer does. A grocery, a pharmacy or a general store can install it and sell over the counter straight away. What a shop sees now follows what the web portal has switched on for it: - A restaurant keeps its tables, service types and delivery staff. - A counter shop gets none of those, and no empty controls where they were. - A superadmin can override this per shop on **Shops ▸ Modules & plan ▸ Desktop & app mode** — for a canteen registered as a grocery, or a bakery registered as a restaurant. ## The same look as the web POS The app has been rebuilt on the browser POS's own colours and typeface, so the two no longer look like different products. A shopkeeper who learns one is not relearning the other. - The left sidebar is gone. The pages now run across the top bar, which leaves the whole window width to the bill and the products. - Register, invoices, shop key and sync keep their place in that bar at every window size; when space runs short it is the page tabs that scroll. - The bill and the product wall are the same height and both fill the screen. ## A rebuilt POS page - The bill is on the left and the products on the right, as in the browser. - The bill is a proper table — product, quantity, subtotal. - Products are a wall of tiles showing the picture, the name, the barcode / SKU, the price, and the stock left (in red when it has run out). - **Scan a barcode** straight into the bill. A scanner types the code and presses Enter; if the code names one product it goes in and the box clears for the next one. An unknown code changes nothing. - Search also matches the SKU, not just the name. - Filter by **category** and by **brand**. - Pick a **saved customer** from the shop's own list, or press **+** to type in somebody who is not on it. - Choose a **service staff** member on the order. - Apply an **Order Tax** from the shop's tax rates, beside the discount. - **Recent Transactions** opens this register's sales from the POS page. - The counter and the date are shown above the till, with a clear warning when the register is closed. ## Card and Credit Sale Cash is no longer the only way to finish a sale. - **Card** records the sale as paid by card. - **Credit Sale** records the sale with nothing paid, so the balance stays on the customer's ledger. Nothing is added to the cash register for it — money that has not arrived must not make the till fail to balance at closing. How the sale was paid travels with it, so a credit sale rung up with no internet still uploads as a credit sale rather than turning into cash.

In This release, you can see all possible invoices of current register.

1. Pairing (no internet needed) Admin downloads Metadata.zip from the website (Users Management) and imports it on the desktop app. The zip carries the shop key, user, business info, and full product/menu dataset — verified by a checksum so it can't be tampered with. The app is now "offline-paired": no server session, but fully usable for selling. 2. Selling offline Every order (open/edit/complete/cancel) is saved locally and added to an upload queue (state.queue) — nothing touches the server yet. Opening a register offline creates a local register (register.local = true) tracked entirely on-device. 3. Closing a register Closing bakes that session's sales into a LocalRegisterRecord (opening/closing balance, items sold, and which queued tasks belong to it) and lists it on the Register Sell page, marked unpublished. 4. Publish (the part we just built) Pressing Publish on a closed register sends its register data + queued tasks directly to the server (register/publish), instead of exporting a zip file. The server verifies the shop key, rejects duplicates (by a unique export id), then replays each task through the normal order-create/confirm logic — creating a real cash_registers row (open → sales → close) and real sales, exactly as if they'd happened online. On success: register marked "Published" and its tasks drop out of the local queue. On failure: the exact reason is shown in a highlighted red message so it's obvious something needs attention. 5. Timezone correctness The desktop always exports true UTC timestamps. The importer converts the register's open/close time and each sale's actual time into the business's configured timezone (Asia/Karachi etc.) before saving — so the times shown on the website match what the desktop showed locally, both for the register and for each sold item's date, instead of showing the moment it happened to be published.

Service Types and Key issue resolve. Online Device Activity Log

Resolved Offline Bug, And Design Update