Graphical interface for POS
Moderators:daleadmin, Dale Harris, Alan, Andrew
If anyone wants a graphical (gui) interface, its in the works...
Here are some screenshots to see how a gui can make managing customers more user friendly. Also, my system features an import facility to be able to browse any historical sales transaction all saved in a database accessible by customer.
These are not static bogus screen shots. This is the gui in action. This is a great coupling of a gui usability layer paired with the unbeatable stability and robustness of Dale's application.
My next task is to do the same for the inventory and category management aspects. This is just the tip of the ice burg.
Take a look:
Here are some screenshots to see how a gui can make managing customers more user friendly. Also, my system features an import facility to be able to browse any historical sales transaction all saved in a database accessible by customer.
These are not static bogus screen shots. This is the gui in action. This is a great coupling of a gui usability layer paired with the unbeatable stability and robustness of Dale's application.
My next task is to do the same for the inventory and category management aspects. This is just the tip of the ice burg.
Take a look:
Re: Graphical interface for POS
Here's another sneak preview of the inventory module that permits browsing, resorting and editing operations.
Note: that in the release version Category and Vendor will appear be drop down selectors instead of integers.
Note: that in the release version Category and Vendor will appear be drop down selectors instead of integers.
Re: Graphical interface for POS
By the lack of responses in this thread I take it there isn't much interest in this. It takes A LOT of work to bring an application to a level suitable for public release versus just a level suitable for my own personal use. For instance, I would'nt need to write a help utility module if I'm only writing the application for myself.
Therefor I put it out to you if the forum members are interested, I need to see at least 10 responses of interest to motivate me to continue further development for public release.
Thanks
Therefor I put it out to you if the forum members are interested, I need to see at least 10 responses of interest to motivate me to continue further development for public release.
Thanks
Re: Graphical interface for POS
Hi
I want you to do it.
I want you to do it.
P.S. God Loves You And Have A Good Day!!!
http://god5731.myftp.org/
http://god5731.myftp.org/
-
- Forum Regular
- Posts:178
- Joined:Thu Jan 05, 2006 3:41 pm
- Location:South-East England
Re: Graphical interface for POS
Most retail outlets don't keep customer records so that is probably why there was a 'lack of interest'. However, if it allows easy editing and updating of stock records, including cost, that would be very useful as Dale has refused to countenance real time updating of stock cost when new stock is added even though it would be the single most valuable feature ever.
Re: Graphical interface for POS
Can you elaborate what you mean by easy update? What I intended was that the user can update ad hoc the cost and price of the stock items, exactly as it is done in Dale's POS only with GUI frontend.
By realtime do you mean a FIFO, LIFO or weighted average costing of inventory to be adjusted everytime a new purchase is received? That requires every time there is a purchase, that the purchases be tracked in a seperate table for calculations. Since Dale's program uses a flat datatbase inventory file, there is no historical tracking of purchases. Therefor its impossible for this program to do it since its not meant to be a full fledged accounting system.
However, my program is using a paralell relational database (an MS Access database) that is in conjunction with Dales' flat inventory file. Therefor it would be possible for me to add this feature. Its not a slam dunk though, its quite a job. I would need to put a purchasing module into it.
Maybe that can be added later or maybe when I do my own Python based POS from the ground up.
By realtime do you mean a FIFO, LIFO or weighted average costing of inventory to be adjusted everytime a new purchase is received? That requires every time there is a purchase, that the purchases be tracked in a seperate table for calculations. Since Dale's program uses a flat datatbase inventory file, there is no historical tracking of purchases. Therefor its impossible for this program to do it since its not meant to be a full fledged accounting system.
However, my program is using a paralell relational database (an MS Access database) that is in conjunction with Dales' flat inventory file. Therefor it would be possible for me to add this feature. Its not a slam dunk though, its quite a job. I would need to put a purchasing module into it.
Maybe that can be added later or maybe when I do my own Python based POS from the ground up.
Re: Graphical interface for POS
Roxy,
Rollerball wants to be able to change the price of an item from the RECEIVE.EXE program when merchandise is received into the store.
Dale
Rollerball wants to be able to change the price of an item from the RECEIVE.EXE program when merchandise is received into the store.
Dale
Re: Graphical interface for POS
Think the gui is nice. just used to the simplicity of dales. any advantage over doing it the current way? or just testing things out for your python version? looks like it would be a fun project though. i really need to teach myself programing.
-Wes :O)
Re: Graphical interface for POS
Thanks Dale,
Update of price and cost info can be done easily then if I put a receive module into my program.
The gui is not intended to add that much in the way of functionality- its merely adds a different way to work since not everyone is comfortable giving up their mouse.
Update of price and cost info can be done easily then if I put a receive module into my program.
The gui is not intended to add that much in the way of functionality- its merely adds a different way to work since not everyone is comfortable giving up their mouse.
-
- Forum Regular
- Posts:90
- Joined:Thu Jan 01, 2004 11:43 pm
Re: Graphical interface for POS
Great IdeaRollerball wants to be able to change the price of an item from the RECEIVE.EXE program when merchandise is received into the store.
Robert
Robert R Nel
Re: Graphical interface for POS
No, its not.
Re: Graphical interface for POS
Dale,
Can you please share your insight so I can understand where you're coming from. Allow me to benefit from your experience and please elaborate on why you feel it's a bad idea to make the cost of inventory change when a new receipt is received.
My opinion is that the the inventory cost is our standard cost. Sometimes suppliers make a mistake and the user should be flagged that the receive cost varies from the last cost. Note that I say flagged. I think the user should have the option to either change the cost or leave the cost.
Can you please share your insight so I can understand where you're coming from. Allow me to benefit from your experience and please elaborate on why you feel it's a bad idea to make the cost of inventory change when a new receipt is received.
My opinion is that the the inventory cost is our standard cost. Sometimes suppliers make a mistake and the user should be flagged that the receive cost varies from the last cost. Note that I say flagged. I think the user should have the option to either change the cost or leave the cost.
Re: Graphical interface for POS
Roxy,
Because in any store larger than a one person operation it is not the manager who is doing the receiving but usually some low level clerk who could not finagle his way out of the task. If he could, he would dump the job on someone even lower than he is.
Currently the program requires that the manager goes into the stock table (where a password may be required) to change the price there. He then has time to do some thinking. "My cost went up 27¢, should I raise the price 55¢ or 60¢ ?"
However if pimple-faced Bobby who has been working for all of two weeks is doing the receiving that day do we let him reset the price for any item to whatever he feels like at the moment? The boss just yelled at him so is he going to reset the price on a $20.00 item to $12.00 for revenge?
Plus if you look at the screen where you enter the invoice information where would you put the fields for changing the prices?
Dale
Because in any store larger than a one person operation it is not the manager who is doing the receiving but usually some low level clerk who could not finagle his way out of the task. If he could, he would dump the job on someone even lower than he is.
Currently the program requires that the manager goes into the stock table (where a password may be required) to change the price there. He then has time to do some thinking. "My cost went up 27¢, should I raise the price 55¢ or 60¢ ?"
However if pimple-faced Bobby who has been working for all of two weeks is doing the receiving that day do we let him reset the price for any item to whatever he feels like at the moment? The boss just yelled at him so is he going to reset the price on a $20.00 item to $12.00 for revenge?
Plus if you look at the screen where you enter the invoice information where would you put the fields for changing the prices?
Dale
-
- Forum Regular
- Posts:178
- Joined:Thu Jan 05, 2006 3:41 pm
- Location:South-East England
Re: Graphical interface for POS
Sighhh....
Because it's how every single stock control program in the world does it.
And I don't want it to change the price, just the cost. What I do need to know is what the real total value of my stock is at any moment, not what its notional value would have been 9 months ago when I set the file up. That's of no value to me whatsoever. And the pimply faced youth can make a lot of other mistakes besides this one - how come you're not bothered about that?
Anyone who you have laying any kind of finger on the system where sensitive data is concerned - and just receiving stock would fall into that category - should be a trusted employee - not some oik you've just dragged in off the streets. Firms do have them you know. They work in places like accounts. Employers also often train them too, to do things properly strangely enough. You have to do that when you expand beyond just being a one man band and doing every ruddy thing yourself.
But never mind. It just means that DHPOS will always only really cater for the single owner Mom and Pop store who just want to bang out nice looking receipts and wouldn't know what stock control was if it came up and bit em on the backside. And so long as you're happy Dale banging out monster features like ticket sales, that only one person in the world apparently wanted, that's OK
PS - the amount of code needed would not be great. And to satisfy reluctant revisionists like yourself, Dale, you could even add a switch in POSConfg so you could decide whether to update stock cost or not on receiving stock. But everyone would leave it in 'Yes' anyway.
Because it's how every single stock control program in the world does it.
And I don't want it to change the price, just the cost. What I do need to know is what the real total value of my stock is at any moment, not what its notional value would have been 9 months ago when I set the file up. That's of no value to me whatsoever. And the pimply faced youth can make a lot of other mistakes besides this one - how come you're not bothered about that?
Anyone who you have laying any kind of finger on the system where sensitive data is concerned - and just receiving stock would fall into that category - should be a trusted employee - not some oik you've just dragged in off the streets. Firms do have them you know. They work in places like accounts. Employers also often train them too, to do things properly strangely enough. You have to do that when you expand beyond just being a one man band and doing every ruddy thing yourself.
But never mind. It just means that DHPOS will always only really cater for the single owner Mom and Pop store who just want to bang out nice looking receipts and wouldn't know what stock control was if it came up and bit em on the backside. And so long as you're happy Dale banging out monster features like ticket sales, that only one person in the world apparently wanted, that's OK
PS - the amount of code needed would not be great. And to satisfy reluctant revisionists like yourself, Dale, you could even add a switch in POSConfg so you could decide whether to update stock cost or not on receiving stock. But everyone would leave it in 'Yes' anyway.
Re: Graphical interface for POS
Rollerball,
Most of the folks who harangue me about this want to change the prices and now you want to change the cost. So that is TWO extra fields that I would have to somehow shoe horn onto the screen to get people to shut up about it.
The amount of code that it would take to do this would be irrelevant because it would added to the RECEIVE.EXE program where there is lots of room and not the POS.EXE program. But it would be quite a lot of work because it would not only change the screen but also the file format of the .RCV file. It would also make the entry screen for receiving different from the entry screen for inventory so they could not share the code like they do now.
BTW, what's wrong with mom & pop stores? They're the folks that this program was originally written for in the first place. And I receive far more donations from them than the medium sized businesses that use it. (The difference being between "almost nothing" and "virtually nothing.")
As far as the ticket feature is concerned remember that the main purpose of my doing this is fun, because it sure ain't the money. The ticket feature was way different from the rest of the POS program and was buckets of fun. It has several users that I know about. The "receive" thing would just be drudgery.
However the time clock thing I swore never to do got done out of sheer bordom. And in keeping with my current policy of no longer saving users from themselves there is always the possibility that I could get that bored again and do this.
Don't wait up, don't leave a light on.
Dale
Most of the folks who harangue me about this want to change the prices and now you want to change the cost. So that is TWO extra fields that I would have to somehow shoe horn onto the screen to get people to shut up about it.
The amount of code that it would take to do this would be irrelevant because it would added to the RECEIVE.EXE program where there is lots of room and not the POS.EXE program. But it would be quite a lot of work because it would not only change the screen but also the file format of the .RCV file. It would also make the entry screen for receiving different from the entry screen for inventory so they could not share the code like they do now.
BTW, what's wrong with mom & pop stores? They're the folks that this program was originally written for in the first place. And I receive far more donations from them than the medium sized businesses that use it. (The difference being between "almost nothing" and "virtually nothing.")
As far as the ticket feature is concerned remember that the main purpose of my doing this is fun, because it sure ain't the money. The ticket feature was way different from the rest of the POS program and was buckets of fun. It has several users that I know about. The "receive" thing would just be drudgery.
However the time clock thing I swore never to do got done out of sheer bordom. And in keeping with my current policy of no longer saving users from themselves there is always the possibility that I could get that bored again and do this.
Don't wait up, don't leave a light on.
Dale
Who is online
Users browsing this forum: No registered users and 121 guests