Graphical interface for POS

Make comments, ask questions, or just complain about the software on this site. Or comment on any educational software.
Please note that by clicking on links that may appear in these posts that you may be leaving the Dale Harris Educational Software website and that the content of those sites is the sole resposibility of the authors of those sites.

Moderators:daleadmin, Dale Harris, Alan, Andrew

roxy99
Forum Regular
Posts:24
Joined:Mon Dec 22, 2008 1:44 pm
Graphical interface for POS

Post by roxy99 » Thu Mar 12, 2009 10:09 am

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:

Image

Image

Image

Image

roxy99
Forum Regular
Posts:24
Joined:Mon Dec 22, 2008 1:44 pm

Re: Graphical interface for POS

Post by roxy99 » Wed Mar 18, 2009 10:24 am

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.

Image

roxy99
Forum Regular
Posts:24
Joined:Mon Dec 22, 2008 1:44 pm

Re: Graphical interface for POS

Post by roxy99 » Tue Mar 31, 2009 10:45 am

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

User avatar
bob5731
Forum Regular
Posts:83
Joined:Sun May 30, 2004 1:34 am
Contact:

Re: Graphical interface for POS

Post by bob5731 » Tue Mar 31, 2009 8:11 pm

Hi
I want you to do it.
P.S. God Loves You And Have A Good Day!!!
http://god5731.myftp.org/

RollerBall
Forum Regular
Posts:178
Joined:Thu Jan 05, 2006 3:41 pm
Location:South-East England

Re: Graphical interface for POS

Post by RollerBall » Wed Apr 01, 2009 12:44 pm

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.

roxy99
Forum Regular
Posts:24
Joined:Mon Dec 22, 2008 1:44 pm

Re: Graphical interface for POS

Post by roxy99 » Wed Apr 01, 2009 1:54 pm

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.

User avatar
daleadmin
Forum Owner
Posts:1279
Joined:Tue Dec 30, 2003 9:47 pm

Re: Graphical interface for POS

Post by daleadmin » Wed Apr 01, 2009 6:03 pm

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

User avatar
Wes
Forum Regular
Posts:24
Joined:Mon Feb 09, 2004 11:58 am
Location:Nashville, TN
Contact:

Re: Graphical interface for POS

Post by Wes » Wed Apr 01, 2009 11:06 pm

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)

roxy99
Forum Regular
Posts:24
Joined:Mon Dec 22, 2008 1:44 pm

Re: Graphical interface for POS

Post by roxy99 » Thu Apr 02, 2009 10:00 am

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.

Robert_Nel
Forum Regular
Posts:90
Joined:Thu Jan 01, 2004 11:43 pm

Re: Graphical interface for POS

Post by Robert_Nel » Thu Apr 02, 2009 11:40 am

Rollerball wants to be able to change the price of an item from the RECEIVE.EXE program when merchandise is received into the store.
Great Idea
Robert
Robert R Nel

User avatar
daleadmin
Forum Owner
Posts:1279
Joined:Tue Dec 30, 2003 9:47 pm

Re: Graphical interface for POS

Post by daleadmin » Thu Apr 02, 2009 5:26 pm

No, its not.

roxy99
Forum Regular
Posts:24
Joined:Mon Dec 22, 2008 1:44 pm

Re: Graphical interface for POS

Post by roxy99 » Fri Apr 03, 2009 9:21 am

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.

User avatar
daleadmin
Forum Owner
Posts:1279
Joined:Tue Dec 30, 2003 9:47 pm

Re: Graphical interface for POS

Post by daleadmin » Fri Apr 03, 2009 3:38 pm

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

RollerBall
Forum Regular
Posts:178
Joined:Thu Jan 05, 2006 3:41 pm
Location:South-East England

Re: Graphical interface for POS

Post by RollerBall » Sun Apr 05, 2009 4:34 am

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.

User avatar
daleadmin
Forum Owner
Posts:1279
Joined:Tue Dec 30, 2003 9:47 pm

Re: Graphical interface for POS

Post by daleadmin » Sun Apr 05, 2009 3:48 pm

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

Post Reply

Who is online

Users browsing this forum: No registered users and 250 guests