Traditional Point of Sale · Retail
Final Orbit POS
A high-speed counter register crafted for fluid retail checkout.
- Price
- Free
- Version
- v1.0.2
- Published
- Updated
- Maker
Final
Screens
5 screensAbout this flow
Final Orbit is a retail counter register built around a responsive catalogue grid, dynamic cart drawer, and high-frequency action rail. Designed to recreate the ergonomics of classic retail till terminals, it keeps order management, parked sales, discounts, and customer tracking visible and actionable on a single screen without slowing down the cashier.
What it can do
- Dedicated Action Rail
- Gives cashiers single-tap access to hold sales, ring misc items, trigger no-sale drawer kicks, apply discounts, and reprint receipts.
- Dynamic Cart & Line Controls
- Easily adjust quantities, view nested line discounts, inspect notes, and access item-level actions in a dedicated transaction panel.
- Integrated Customer & Order Tabs
- Switch seamlessly between the current basket, attached customer accounts, and order recall without navigating away from the register.
- Fast Client-Side Product Search
- Instantly filter catalogue items across names, SKUs, and hardware barcode scans through an overlaid search drawer.
Changelog
- v1.0.2Live
The refund dialog's backdrop and shadows follow the theme. - The vendored refund dialog painted its backdrop rgb(0 0 0 / 0.5) and gave its two drop shadows their own black, so none of the three could move when a maker flips the brand knobs. All three now derive from --scrim, the one token the engine writes as a DIMMER rather than a surface: the engine re-weights it per appearance, so a shadow follows the theme down instead of staying black on a white ground. They derive from the engine token rather than one of this app's own --fp-* names on purpose, so the next upstream update to this vendored file has nothing extra to merge. Presentation only. No refund money path was changed and none was re-exercised, so the cash-rounding assertion this build's paid-back reader exists for is still unsettled — see Device QA in the manifest. Still warning after this release, all outside the refund dialog: src/index.css, src/lib/palette.ts and src/screens/Receipt.tsx paint with hardcoded colours, and the receipt pins a font family. The receipt's are the thermal-slip exception — a print head burns black on white — but the other two have not been examined.
- v1.4.0
Refunds move to the vetted blueprint dialog, and the ORDERS list stops losing partly-refunded sales. - ONE refund UI. ORDERS → an order → REFUND now opens the payment-refund blueprint dialog: item/fee/tip selection, per-line restock-or-damaged, a reason, and a per-tender split with cash rounding, committed headlessly against the engine's refund plan. The thinner refund screen this build carried first has been deleted — two refund UIs in one till is exactly the drift this flow has been bitten by before. - A partly-refunded order stays in ORDERS with its remainder refundable. This took three attempts, and the first two were the same mistake in different places: asking the host for `status: "completed"`, then for `completed` + `refunded`, then filtering locally on a guess list that included `open` and `pending`. All three guessed at a vocabulary the host owns, in the direction of hiding a sale. The list now reads orders with no status filter, hides only what it can positively name as belonging elsewhere (parked, in-cart, draft), re-reads the just-refunded order by id via setActiveOrder, and repairs itself from getRefunds() — which knows what has been refunded without going through an order status at all. - The order detail carries a Status row: the refund standing when there is one, and otherwise the host's own status word, so the till says what it is looking at rather than guessing. - Order detail also shows per-line notes, what has been refunded and what is still refundable. The REFUND button closes only on proof that nothing is left — a failed read leaves it live rather than claiming a sale cannot be refunded. - The receipt prints the customer, the discount line and per-line notes. Because the host drops notes as the cart becomes an order, the till keeps a snapshot of the basket at tender time and the receipt falls back to it — never overriding what the order carries, and never attached to a reprint of a historical order. - HOLD stays live on an empty till when there is a parked sale to recall.
- v1.0.1
Refunded figures now report the money that MOVED. Order detail and the printed receipt were showing the refund engine's computed refunded total. That figure is the refund BEFORE the company's cash rounding is applied on the way out, so on a rounding company it disagrees with what the customer was actually handed — and a refund line that disagrees with the drawer is worse than no refund line at all. - The refunded figure now prefers a refund's own PAYMENT LEGS, which are a record of what was paid back rather than a calculation of what should have been. Magnitudes are taken because a leg's sign is not consistent and the UI supplies the minus itself; that normalises presentation without computing an amount. A refund's computed total remains the fallback for a refund carrying no legs, and the plan's refunded total the fallback when the host returns no refund records. - Capacity and history are now read as two independent questions: the plan still owns what is left to refund, the refund records own what went back. A failed read stays unknown rather than becoming zero. Verified in preview by supplying a refund whose legs (15.20) disagreed with its computed total (15.19): order detail and the reprinted receipt both showed 15.20 while "still refundable" continued to track the plan. That proves the wiring and nothing about a host — refund movement, cash rounding and printing remain device checks. A refund record also carries the rounding the host applied; this build does not surface it yet.
- v1.0.0
Orbit POS 1.0.0 — the dark space-themed counter register, now with the vetted refund blueprint on order detail: item, fee and tip selection, per-line stock disposition, refund reasons, original-tender allocation and cash rounding. Reprinted receipts now show a Refunded line taken from the refund engine's own figure. Refund movement, stock actions, cash rounding and printed output still need a device pass.
