Barcode scanners, 1D and 2D
Most scanners emulate a keyboard, so most simply work. Buy a 2D imager even where 1D would do: packaging QR and payment QR are both 2D, and GS1 element strings carry batch and expiry.
The iron on your counter is already the right iron.
Scanners, printers, drawers, terminals, tax rails, suppliers and your books. Hardware here is declared in a definition rather than waiting for a driver, which is why an unlisted device is not a support ticket.
The hardware you already own, driven properly
Four models exist for driving retail hardware: an approved list, an approved host, a driver per device, or a declaration. We chose the declaration, and the rule that makes it work is that an unknown element is skipped rather than thrown.
Receipt printers, ESC/POS
The de facto command set, implemented in genuinely different subsets by different makes. Receipts come from a definition, so changing the footer is not a release.
Cash drawers
Not a device: the drawer opens on a command sent to the printer over its kick port. Worth knowing before you buy, because small portable printers usually have no port.
Card terminals
Your payment processor should be a choice you can change without changing your point of sale. Card settles onto the same ledger as cash and as UPI.
POS terminals
The till runs on Android-first hardware with the print layer built once against ESC/POS, so the same build drives a counter terminal and a handheld.
Phones and tablets
A phone is a valid till. Shelf counting, receiving, and a second checkout lane during a rush all run on hardware the shop already has in a pocket.
One ledger under every tender
Payment rails, tax rules, and the accounts are three faces of one transaction. Keeping them on one core is why the day-close explains itself instead of needing a reconciliation.
Card, UPI, and cash
Every tender settles onto the same ledger. UPI carries no merchant discount rate, which is exactly why we do not take a percentage of your sales.
Country fiscal packs
Tax and receipt rules differ by market and are configuration, not a rebuild. Each receipt is sealed into a hash-chained fiscal record for the locale it was raised in.
Double-entry, posted live
Sale and cost of goods post as journal entries at the moment they happen, which is why the margin number and the books cannot drift apart.
Invoices and credit notes
Trade customers, account sales, and credit notes are the same document family as the receipt, on the same ledger, so nothing settles in a spreadsheet.
Suppliers, stock, and everything that moves
Purchase orders and invoices
One order per supplier goes out and comes back matched to the invoice, with the discrepancy flagged rather than absorbed quietly into your margin.
Live stock and reorder
One count, decremented by the till and incremented by the delivery, with reorder driven by real movement rather than a reorder point somebody set in 2019.
Back room and transfers
Receiving, put-away, and transfers between locations are real movements on the same stock record, so the branch that is short can see who is long.
Delivery and dispatch
Delivery rounds and dispatch runs are planned against the orders that promised them, so what was committed online is what the van is loaded for.
The identification, tax and network standards this runs on
A standard outlives a connector. Where an obligation has a date, the date matters more than the feature, so these are named with what is shipped and what is still being built.
GS1 identification
EAN and UPC at the shelf edge, GS1 element strings for batch and expiry, and DataMatrix for the 2D transition retail scanners are being asked to complete by the end of 2027.
E-invoicing, per market
On the roadmap and on a clock. India requires invoices to reach the portal inside a fixed window above a turnover threshold, and the European model builds on EN 16931 with a UBL serialisation over an access point. One invoice model, two mappings.
Weighing scales
Today: a label-printing scale that emits a weight-embedded barcode, which the till reads and prices with no serial link at all. A live serial link and price-lookup upload are on the roadmap.
Marketplaces and networks
On the roadmap, and built as one rail rather than one integration each: order ingest, status callbacks, and a reconciled payout report, reusable across open commerce networks and aggregators.
Multi-currency and locale
Prices, formats, tax treatment, and language follow the market a store is in, on one codebase. Opening a new market is configuration, not a fork.
Offline and resync
The till keeps selling through an outage and reconciles itself when the network returns. The device layer has no domain imports, so printing does not depend on a server being reachable.
One catalog, three shopfronts, and your own way in
storeDule and webDule
Both storefronts read this catalog, pricing, and stock. Not synced to it: the same row the till decrements and the ledger posts against.
A versioned REST API
Catalog, stock, orders, and the ledger are reachable over a documented HTTP API, with published events so another system can react to a sale rather than poll for it.
Accounting export
Sales, cost of goods, and expenses export in a form your accountant can take straight into their own books, from the ledger that raised them.
Everything else, too
Catalog, suppliers, customers, sales, and books export at any time. There is no lock-in, no exit fee, and nothing here depends on you being unable to leave.
Early Access
Tell us what is on your counter
Send us your scanner, your printer, your terminal, and your accountant's format. We will tell you what works out of the box, what needs a definition writing, and what is honestly on the roadmap.
Your data stays yours. Catalog, suppliers, sales, and books are exportable at any time.
Explore
More from grossDule
The full picture, one page at a time.
Use cases
The store types and the jobs grossDule was built around, from one till to many.
Pricing
Simple and honest. One price per location, unlimited tills and staff, and nothing taken from your sales.