I did not design this for big environments.
But maybe persons can use it for non profit organisations,
for instance little shops in elderly homes. I worked as a volunteer in such an environment and i saw the struggle with
other volunteers by payments.
So this could be a solution for those situations.
And by the way it's really fast for not too big environments.
Any specific reasons why you think it would compare poorly to other commercial applications. I have tried the ones at Walmart and they are sometimes very slow to respond .
To be fair, some commercial systems suck on UX too, but some of them are much better than this.
If you compare it to eposnow[0] for instance, and see the adoption of large clear buttons.
The real differences, as I see it, between this and commercial systems are
1) most commercial tills are clients that poll a server that allows central management of stock, prices, and extraction of sales data by api
2) commercial tills can integrate with card machines, so the price comes up on the machine automatically, and successful payments are registered on the till. In a busy store this stops under/over errors.
The world needs a decent, hackable, open source till, because there are many situations where you need small but important extra features. Without the above I would say appeal is going to be limited, but good luck to the author
Commercial tills also integrate with a huge bunch of other specialized periphery. Payment terminals are an important category (and an ugly one, because each country has its own, and there are many different protocols in use), but receipt printers, barcode scanners, RFID systems (to perform cashier authentication), cash drawers, checkout scales, cash management systems, RVMs (reverse vending machines; those things taking bottles back at the store) and whatever other, often custom hardware big retail chains come up with (think store signaling systems for example).
They also need to take fiscal requirements into account: in a growing number of countries, cash register systems have to satisfy fiscal requirements and must perform some sort of transaction signing and reporting to fiscal authorities, or integrate special hardware which gets all transactions and prints out the receipts instead of a "normal" printer on which you can print anything. This is an ugly topic that easily keeps several full-time employees busy, because fiscal requirements are mandated by law and thus are moving targets. The US doesn't have this at the moment, but compensates by having a rather special and complex tax system ;-)
And then there's the calculation of prices modified by promotions (think coupon codes, time-controlled rebates, such stuff) which is an entire topic on its own, especially when taking the interplay of promotions with sales tax calculation and rounding logic into account (not all countries round to .01 cents, some don't have anything smaller than 0.05, and some retailers voluntarily decide to round to multiples of 0.05 in order to eliminate handling effort with small coins).
In my past i have developed client server applications.
Long time agoo before relational databases appear.
In the time of dbii and clipper (compiler and linker)
But i'am retired now and i have not a network in my home to apply with ip numbers for testing. Thats the simple reason that i did not explain it in my documentation. But anyone will be my guest and fork it and work on it.