CashRegister in PyQt5 with barcode logon and 32 programmable buttons | Hacker News Reader

CashRegister in PyQt5 with barcode logon and 32 programmable buttons

github.com

27 pointsDirkJanJansen27 comments

Programmer who also works in retail, uh no, this layout highlights all the wrong things. The list of items is half the screen, my current system has it at about 1/4 and buttons are enormous, very easy to use and rarely ever miss a button or hit the wrong one, this looks like that will happen all the time. Also we have a lot of colour in buttons that relate to use (payment buttons red, department buttons green, account buttons yellow), this has grey and grey and grey. It might work but I pity anyone using this system. I think with some more UI considerations for the actual use cases (what do register users need the item barcode for? I might enter it but once the item name pops up I don't need it taking up my screen) this could get good. I also don't need whitespace between buttons, have them as big as you can.

You should not compare this with a commercial program, I'am a hobbyist and not a professional. I think it's a good effort for an open source product.

He is still giving you constructive feedback that you can use to improve your product. Even if it's just a hobby. I assume that is why you posted it here?

If I my add something as well. Use a local git program to commit and add files instead of using drag 'n drop from the website. Add commit massages with a short description of what you changed.

I would also remove all the logos in the program.

Keep at it :)

Thank you for your response. In the installation directory is a changelog.txt in which all the changes and additions in the program are documented.

I fully understand that, I also imagine it's really harsh to release something like this then get feedback like mine, so if you want you can send me any messages about things I like and dislike about the system I currently work with if you want any suggestions for your system.

Edit: honestly I think my first message is a bit mean, I wish I could retract it because working hard on a project this only to be met by that is really shitty. But I wanted to highlight that knowing the use cases for your project is really important. I really believe with a few UI changes this could be comparable to the software I currently use, having that as open source would be awesome.

Thank you. I did see it as positive, for your remarks were usefull. I looked already for bigger buttons without spaces and it becomes better. I thought already to make one button too switch between buttongroups in that way you can use 3 or even more groups with buttons for several departmens so you get 3x40 or even 5X40 buttons. And by the way colors is very easy to realize to make it more clearer. I certainly will use your remarks.

Reminds me of this DOS PoS freeware that's been around for a while:

http://keyhut.com/pos.htm

http://keyhut.com/posphoto.htm

If it's run on straight DOS then there's no need for OS updates, no worries about viruses, no telemetry yada yada :-)

The guy who made this also made a desktop gui ERP application to teach himself python (or programing general, I forget). He is an inspiration.

Keep doing what you are doing Dirk.

https://github.com/DirkJanJansen/Pandora

Thank you for your inspiring comment.

How this compares to commercial software solutions? Seems very interesting.

I have not compared with commercial applications I made this as open source for the community. I have no background in retail.

Poorly. I can't imagine using this in a fast-paced retail environment.

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

[0]:https://www.eposnow.com/uk

Edit:formatting

It's easy to put this on a server with clients pos. For a server database system postgreSQL is used.

It might be worth clearing that up in the docs then. I missed it

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.

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).

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.

Screenshot https://github.com/DirkJanJansen/Sales/blob/master/Cashregis... Documentation https://github.com/DirkJanJansen/Sales/blob/master/Installat...

2020-06-26 Added 5 changeable buttongroups with each 39 programmable buttons. Bigger coloured buttons and removed logos from front end.

Changed to 40 bigger buttons. Layout changed and applied some colors. With thanks to Phillipharryt for his constructive comments. Thanks buddy!

Asking out of curiosity: why did you choose Riverbank’s python binding instead of Qt’s?

I don't know the difference. I learned myself python, Pyqt5 and postgreSQL in a relative short period, mostly by examples and documentation online. Got a little knowledge from my past by learning and programming in Clipper and QBasic for my last company, long time agoo (1997-2002). Now i am retired and i like to program in python (My age is 75)

Gotcha. I'm a commercial Qt developer and starting to think about Python being a first-class language in my ecosystem. But I've learned that the more robust binding, PyQt, is a GPL/Commercial offering separate from the Qt licensing.

Qt for Python is the "offical Qt" binding but it's not as robust or even supported on some platforms like embedded. It's a bit frustrating.

Still, nice work!

I have looked at C++. But development in Python is fast and you get more ideas. So for development and testing i should prefere Python and then i should program it in C++ for commercial use. I saw earlier in my former business, that interpreters were used for big programs. That way you can test fast, for you can see your errors fast.

Totally agree. It's even more useful in a cross-compiled development environment.

Typically I'm developing in Qt/C++ on a host and then using a custom crosstool chain to recompile for the target. The entire cycle isn't that bad, but it's not instantaneous. Using Python has radically sped up some parts of what I'm doing on the target hardware.

Reply on news.ycombinator.com