Printable View
the receipt goes in the drawer. You don't want to hardcode ccsales because you might switch cc companies. The ccsales are totalled separately with a ccsales button and compared to the receipts at the end of the day and there are any discrepencies you also have a weekly statement from the cc company to compare it to.
I've worked with 2 credit card machines.Quote:
Originally Posted by szlamany
One, for a large retailer with a few hundred stores, used a full featured touchscreen PIN pad unit that pretty much did everything, even taking the customer signature. Our program sent the transaction dollar amount and only got back a status code from the unit. We never saw the card number or any other customer info. Our interface to it was a COM object and drivers supplied by the manufacturer. It was more like interfacing with a separate networked computer than an attached device. All the accounting and reporting was handled within our program so no receipt copy was needed unless system problems caused the backup plan to go into action.
Another project, this one for a small group of medical offices, used a simple card reader. It piggybacked on the keyboard and when the card was swiped the program got the number and some other info as keyboard input. The transaction info was sent either over the Internet or phone line to the processing center's computer which would return an approve/decline response. The receipt copy was kept for accounting purposes since our program only provided rudimentary reporting.
what about how the program is made... should it be designed to load before windows so that the only thing running on the computer is the POS system...
As I mentioned in the article I linked earlier, it is usually best to do this by managing the user rights and privileges. This makes it easy for administrators to maintain the system while keeping things like Task Manager and even the Taskbar out of reach to ordinary users. The POS program would load on startup by placing the appropriate command(s) in the Run section of the registry for POS users.Quote:
Originally Posted by TheUsed
The alternative is to use a command shell replacement. While this has the advantage of making the system totally dedicated it has the disadvantage of being harder to code, harder to maintain, and more difficult to customize and extend. For the clients I did POS systems for flexibility was the most important consideration. Other companies I know about wanted tight standardization and went with a dedicated POS program.
Our POS system will not be a dedicated app - the user will want to run other apps on that same machine.
replacing the command shell doesn't really screw anything up. You can create a password-protected link in the program to launch the taskbar.
ok what if it did load before windows but had an option to boot windows? that way system admins can do whatever.. I mean I just dont know which is best. Like what do you mean run the shell command that's used to open other programs through another program right?
yeah. Or you could just put common buttons on the menu such as calculator (useful always in a program like that)
You're really talking about 2 different things.Quote:
Originally Posted by TheUsed
Not booting Windows would imply a separate OS configuration, such as running Linux and Windows from the same HD. I think this would make things too complicated to code and maintain. Only run one OS.
Overriding the Windows command shell and booting to alternate configurations is another. I don't recommend coding this because you can buy alternative security shells for considerably less than what it will cost you in time and money to code a secure and stable one. Plus, Windows XP (and I suppose Vista as well) itself provides all that you should need for most POS environments as long as you take the time to configure it right.
all you have to do is replace the explorer.exe with your own filename in the win.ini file. If you don't use the standard explorer.exe, you don't have the task manager running, and the user won't be able to tab off of it. If you ctrl-alt-del you can still start other programs, but you can lock that command with a password.
The sysadmins I worked with on one POS project gave an emphatic "NO!" to that idea. Most notably they called it a major security risk and said that it would be very difficult to maintain reliably and to support.Quote:
Originally Posted by Lord Orwell
On the other project the program had to work and play well with other programs since the system wasn't a fully dedicated POS system but an add-on to a medical office management system.
well there's always the full-screen and on-top of other windows option. Wendy's system does that.
I recently coded something like that for our medical apps. It put a bit of critical info up front first where the user, a medical tech, had to act on it before doing anything else. If the user had access to Task Manager they could bypass it easily, but they don't have access to it. I think it's a rather clunky and obtrusive way to do it but it works.Quote:
Originally Posted by Lord Orwell
Also, going back to general POS, with a touch screen and specialized limited keyboard you can get away with a lot more. Sometimes it pays to look at a hardware solution in addition to a software and system administrative solution.
The hardware I ordered for my customer left Louisville, KY at 4:07 am today - and arrived in Windsor Locks tonight at 8:47 - must be at the airport (UPS - 2nd Day Air).
I'll check Track Shipments in the AM and it should be on a truck to my office.
Now I get to figure out how to get my VB client program to interface with the cash drawer and the receipt printer. It's got a POS keyboard - whatever that is - I guess I'll find out in the morning.
a POS keyboard is one that you can customize every button on it. Print your own keytops and they go under a plastic cover. That way you can have a button for "milk" or one for "dairy" or whatever. Or more useful is a $1 button, a $5 button, and "Exact Change" button, etc.
And interfacing the printer is easy. It is recognized by windows as a printer. Interfacing the cash drawer can be easy but it depends on the interface. I believe most of them are serial and i would expect it would have a driver disk, but not necessarily. it basically is just a relay in there that opens it. I've actually seen them hooked into the pc speaker and you open the drawer by calling the beep command.
Here's the POS machine - cash drawer - POS keyboard - nice thermal receipt printer - nice barcoder reader - and a magstripe reader
i didn't know hp made cash drawers. But you see what i mean by pos keyboard? Nothing printed on the buttons.
Yes - some of them have the old F1...F5 type buttons under the clear covers.Quote:
Originally Posted by Lord Orwell
Do you just print on some colored paper and cut-out "new key meanings"?
We found the OPOSCashDrawer functions on a CD that came with all this - and already can open the cash drawer - rather simple. Very little programmer documentation though...
What is the expected use - OPEN/CLAIM/OPENDRAWER - then what?? Do we detect that the drawer was closed manually to close the transaction?
Any general assistance you can offer on the use of these OPOS functions in regard to cash drawer and receipt printer (I was kind of surprised the cash drawer plugged into the receipt printer) would be appreciated.
Thanks!
Many credit card software comapnies have (Activex contraols) that you can use in your software to make it a seamless transaction. (Search for Credit Card Active x Controls)
the way it is usually done is you check to make sure the drawer is closed before you store the order. If not, you pop up a dialog telling operator drawer is still open.
I was more or less asking about the use of all these undocumented methods.
If you have written app's that interface with receipt printers and cash drawers what is best practice on the use of the methods to OPEN/CLAIM/OPENDRAWER/etc...
My "SQL TRANSACTION-like" mind tell me I want to start loading "purchase" items into a table for an order in an "open-status". Then total up the price - get some $$'s from the client - note the change amount. That's when the drawer opens. I would love to have the receipt already starting to print - then after the app detects that cash drawer is closed then flag the order as a "closed-status".
Now how to translate all that into proper method calls to the OPOS object is my challenge.