DIY P.O.S. System

May 2, 2005 7:23 AM

How can I build a custom P.O.S. system with an old computer and my internet-programming-biased skills?

The system will be used in a small, single screen movie theater, so I'll need to roll one for the ticketing window, and one for the concession stand. It doesn't have to necessarily be a full-fledged P.O.S. system (cash drawer, customer display, etc.), but at the very least it needs to track transactions and store them for daily reports.

My skills fall on the side of internet programming. I know HTML, CSS, JavaScript, DHTML, PHP, and mySQL... I can make a mean web app, but a P.O.S. system? Is it possible with these skills?

I guess I could install a server on each computer and have them run off a localhost app... I don't know. Any suggestions?

posted by bjork24 to Computers & Internet (9 answers total)

Sure, you could make up a nice POS system in PHP/MySQL, what I'm not too sure about is the hardware - can stuff like cash drawers, pole displays, etc be controlled from a web app?? From what I remember, most of the POS hardware interfaces with a serial or parallel port.

Also, there's the "re-inventing the wheel" aspect. As you might already know, there's a ton of POS systems out there. One that I'm familiar with, MicroBiz offers the software with source code so you can customize it yourself. I worked for a company a few years back that did that, and sold customized versions under their own brand.

That might be an option for you, I dont know your full situation, but hope this helps.
posted by isotope at 7:47 AM on May 2, 2005

Doh! I guess I should've read your profile first, I see that you're the owner of the theater :)
posted by isotope at 8:30 AM on May 2, 2005

Response by poster: Yep. That would be me. I'm terrible about "re-inventing the wheel." I do it all the time... in my mind, building it yourself is the only REAL way to get 24/7 tech support.
posted by bjork24 at 8:53 AM on May 2, 2005

You have three choices, as I see it:

a) Try to fit PHP's square peg into a talk-to-the-hardware round hole. Lots of pain there.

b) Learn a language that allows you to talk to the hardware. Lots of pain and wasted time there.

c) Choose hardware that comes with COM objects that encapsulate it's functionality (pretty much everything out there). Code up an interface in VB.

Learning VB is going to be quicker and easier than (a) or (b). If you go this route your application is going to be little more than glue and interface - all the real work is being done by the vendor-supplied code, which will still need to be supported. So, what's the point of reinventing the wheel again? Seriously, you wouldn't try to build a home-brew watch or DVD player - just buy a POS system off the shelf and get on with something more productive.
posted by Leon at 9:50 AM on May 2, 2005

Do it in perl. A nice combo between ease of use and being able to control the hardware.
posted by cmonkey at 10:08 AM on May 2, 2005

I can't believe there's not a bazillion apps on sourceforge for this. While you're right that being your own support is the best was to have it 24/7 there's no reason why you can't learn how someone else's stuff is put together and be your own support. And it's almost always quicker than implementation from design to delivery.
posted by phearlez at 11:06 AM on May 2, 2005

And having worked for a company that wrote POS software a long time ago, isotope is right.

Scanners, scales, and cash drawers usually all have a serial port (RS232) that must be controlled from usually a program that can access those, which a web app most likely will not, unless you can somehow kludge together some sort of ActiveX control to do that. The cash drawer, for instance, will require you to send an ascii sequence across the serial port that will trigger it to open.

The printer will likely be USB or parallel. I haven't looked into this recently, but that will also be tricky.

Go with a sourceforge product, and hack that into what you want. It will be much easier.
posted by stovenator at 11:34 AM on May 2, 2005

Having been involved in numerous POS systems, agree with Leon, most POS hardware that I've worked with provides a COM interface, which will be hard to work with in a web application. VB, Delphi, C++, or even Access, but a language that interfaces easily with COM/ActiveX, most vendors ship an Active OCX/DLL to control their hardware. You can do this client-side through embedding ActiveX controls on a web-page or Java, but it will be painful and the UI will suffer.
posted by patrickje at 3:56 PM on May 2, 2005

bjork, you know you can mix PHP and GTK and get a desktop application, right? Google it, there's all kinds of

I still don't know how you'd control the cash drawer, though. I know Perl can do it, but I don't know about PHP.
posted by SpecialK at 11:39 AM on May 3, 2005