First time POS Installer...Need some Help

[SoxFan80]

Someone Help..PLZ!!!

Scenario:

A buddy of mine runs a Bar/Restaurant which has old Micros POS equipment installed throughout. We want to slowly transition away from the dinasour MICROS POS equipment because he complains that it is too slow and overkill as far as what he needs to know about the daily/monthly sales/transactions. So, I had a Software Engineer (co-worker/friend) design a custom solution for him using VB.NET He initially wants to go with one POS system before purchasing the other three systems. Although, I've seen alot of hardware bundles online, I'd appreciate any and all feedback on the questions below.

1. The best place to buy the POS hardware bundle (no pos software needed...just an OS and a CD ROM drive) that has fair pricing?

2. Should we go with an all-in-one system initially or a PC based system? He is worried about spills.

3. He wants a remote kitchen for the printer so food orders could be grilled back from the bar. Which Epson printer model should I go with for the local workstation and which model for the remote kitchen printer?

4. What type of connection to use from the local workstation printer to the remote kitchen printer? Also, when he expands to more than one POS system, how would the remote kitchen printer be modified to except print jobs from multiple POS machines?



Hellllllllllllllllllllllllllllllllp!!!!!!!!!!!!!!!!!!!

 

[AkamaiAloha]

No need to cry to for HeLLLLLLLLLLLLLLLLPPPPPPPP! All your questions are easy

1) As this is an open architecture design, any PC and touch screen monitor will do. Booksize PCs are available from Dell, and host of other places you can google. POSiflex, Touch Dynamic, Partner Tech, etc.. your options are unlimited.

2) All in ones look nice, and have been the direction the industry is headed for the last 5 years or so. Personally, I prefer the two piece design (separate touch monitor and small pc) because if something like the bulb burns out, you only need to replace the monitor instead of the whole unit. Because you guys won't be buying from dealers that warranty the equipment, I think is preferable to buying an all in one in your case.

3) Thermal printers are the way to go for local printers, impact printers for kitchen. Epson is the Cadillac of printers--that's all we use. But they are usually the most expensive.

4) Honestly, that's a question for your programmer. If he doesn't know how this is going to work, you, the programmer, and your buddy are in for a world of pain. Bottom line: POS software is FAR more complicated that end-users give it credit for--and please don't be offended by this--but it sounds like a horrible idea, to try to write custom software from the ground up. The worst MICROS system in the world was still designed by architects and engineers with many years of industry exeperience, along with folks in the hospitality industry that know what restaurants need.

I am speaking from experience here. For the last 3 years, one of the high-end restaurants in our area has been saying that a trusted software engineer is writing software, and will eventually replace the Aloha system they currently use (we support their Aloha system). I couldn't really care less if this ever comes to fruition or not, but I've repeatedly warned them what a nightmare they are in store for if it happens. To date, it has not happened, and is not close to happening--and I think the programmer and the restaurant owners are finally starting to realize what a bad idea this was.

Sorry for adding advice that wasn't asked for--the other 4 suggestions I mentioned, IMO, constitute good advice. But, I also believe those of us in the forum are here to help in other ways, when possible. I know I have appreciated it when others have added there two cents, whether I asked for it or not.

To conclude: If you're starting a venture to create POS software to sell to a specific food service market, go for it! May the rewards of being an entreprenuer be yours, and I wish you the best of luck! If you or the programmer are thinking this might be a way to make some quick cash, think again, and bail out while you still can! And save your friend (the business owner) the time, expense, and head ache of what other's have tried many times before.

Hope I wasn't offensive. You and your programmer friend could be the most brillant guys on the planet for all I know--not saying it isn't possible, just saying it's very complicated and won't be something that's done quick and easy.

Good luck, and post if you have more questions!

 

[Shift4SMS]

I have to fully agree with Akamai -- both his answers to 1-4 and his advise.

Writing a POS system sounds VERY easy on the surface: "How hard could it be to put a few buttons on the screen that represent a menu, spit something out in the kitchen, print a final receipt and take a payment?" The problem is frame of reference. Most decent POS applications hide the underlying complexity from the user. If POS user experience is what is being used to gauge how easy writing a program will be, then there will be a BIG learning curve to this process. Your programmers original premise shows one flaw: "We want to slowly transition away…", unless you are a one man operation, POS applications tend to be all or nothing – most servers will not key an order into two systems and many times will not even split an order into two systems.

I could be assuming too much but I get the impression that this POS project is being looked at like a hobby. If your programmer is anything like me, it would be a great hobby and very fun (ok, I'm a technogeek, I admit it). But unlike a hobby, once the project is done it will require support and this is where the fun will stop.

Now that I have dashed your hopes, I will say that the problems are not insurmountable. But you will need to do a lot of research prior to choosing this route. Plan everything. There are several good application development books out there that you and your programmer should read. Most state that a successful project, depending on the author, is 60-80% planning and design and 20-40% coding (actually, there are other percentages, I'm simplifying these numbers). Research, plan, design, research more, plan more, design more then code.

Good luck. Sorry for the additional bad new but I hope it helps…


Steve Sommers
Shift4 Corporation --

http://www.shift4.com

Creators of $$$ ON THE NET(tm) payment processing services

 

[Golom]

As someone who has written a POS "from the ground up", I have to agree with AkamaiAloha. The apparent simplicity of a POS from the user perspective is the result of artfully concealing some pretty industrial strength stuff (e.g. relational databases, Credit Card Authorization, Accounting Information, Network Interfaces, Multiple Device Support, Business Rules, etc.)

As an example of the complexity, my systems (there are three primary modules) contain over 93,000 lines of code and that's before some post-processing that adds another 10,000 or so lines. Your buddy may be a great programmer but the design, coding and testing of anything even approximating that size is a multi-year project.

[small]No! No! You're not thinking ... you're only being logical.
- Neils Bohr[/small]

 

[SoxFan80]

Thanks Akamai,Shift, and Golom for your two cents on my post. Your input did make alot of sense. We will def outsource the hardware for warranty and maintenance contracts. The programmer is very good though and has programmed for a statewide POS application that ties into a local and remote SQL DBS. So we're pretty sure that it will work. We're on Beta 2. He just hasn't programmed for a bar/restaurant environment which mainly leaves us with the printer questions.

4. How will the local workstation printer communicate to with the remote kitchen printer? Also, when we expand to more than one POS system, how would the remote kitchen printer be modified to except print jobs from multiple POS machines?

 

[awbbar]

I think you should be concentrating on the reporting aspect of a pos system. Developimg something new is costly
for the end user unless the the developer is doing this free. There are quite a few stable/simple pos systems that could suit your friends needs.He could then spend a few bucks on custom reports to meets his needs if the pos systems did not have it.

you are going to spend close to the same price for hardware for most pos systems so that leaves only the software.
At approx $300-$1000 per term for software full of features you think about later why try and reinvent the wheel.
You would be better off taking your friend to a restaurant show or arranging for a demo from some dealers with emphasis on reporting.
Save time and money.

 

[AkamaiAloha]

Some really good comments and perspectives here.

Since you're not giving up , I am going to add one or two more things before I try to answer your last question.

I don't care how good of relationship you think you have with the bar owner, make sure you get in writing that he understands that this is BETA software, that it's being priced accordingly, and have him waive some of his rights in terms of his ability to sue you. I can't tell you how many times (in this industry specifically) I've seen the "nicest" people turn into to the biggest a-holes when they felt aggravated or that their business was losing money as a result of the problems. Sometimes their reaction is justified, but often times it's not. To borrow Steve's phrase, it's all about frame of reference. When few restaurants had advanced POS systems (10 or so years ago), making customers happy was easy. Just about anything was better than a pen and paper for taking orders. Now, most businesses have some type of "modern" system, and business owners take for granted all that their current POS systems do, and don't really realize that over time, they've designed their operations (to some extent) based on the systems capabilities and information it provides. Like Golom and Steve pointed out, a lot of this stuff is done behind the scenes, and the owners don't even notice half the stuff it does--until it's gone, that is. That's when the crap hits the fan. "But our old system did it this way!" or "Why can't we make it do this?" And you would be amazed something the silly little things customers act like they can't live without. I read in some newsletter (about a 1 yr ago) that the POS industry represents the fastest growing area in terms of law suits, in recent years. This advice is not meant to discourage you from moving forward--but hopefully it will discourage you from making some of the same mistakes we did. Cover your butt!

Ok, done preaching.

I am not sure if you're asking how order about printers in terms of physical connections, or software-wise. I am not a software engineer, so I can't help much there, but I will do my best.

Physically connecting printers: Most POS systems rely on RS-232 communication, commonly refered to as a Communications port. Local printers often use a NULL MODEM cables to connect to these ports to the back of the printer. For kitchen printers (which are further away physically), you can utilize the same style of communication port, but you use a standard CAT5 network cable. The only real difference is that you'll have a small plastic interface at the computer end and one at the printer in the kitchen (RS-232 9 pin Female to RJ-45, and RS-232 25 pin Male to RJ-45), that are pinned out to transmit the serial communication that the printer is using, over the network cable.

Ok, that was the easy part. The software is even more complicated, because you're involving various architectures as Golom mentioned. You've got to decide if you're going to use the windows spooler or write your own, you need to consider the the operating system platform it will be running on, you've got to consider network communication, different hardware platforms, etc. As most of the programmers on the forum have now witnessed, I am not a programmer and I can't even begin to cover all the aspects of this. And I don't think anyone on here will be able to either, mainly because it's going to be too tied in with how your specific POS software handles the information. If your programmer has experience in writing POS software, I would assume has at least a general idea of how this is going to work.

My advice to you is too break down the elements of what sending an order to a printer will look like in a flow chart, then tackling those aspects one at time by locating experts who have specific knowledge about various stages in the process. Unfortunately, you're not going to get a "one stop" answer in terms of how to make this happen by posting in any single forum.

I am enjoying this discussion though (especially complaining about the customers--I can't believe Adam and Bo are missing out on this! ). Keep us posted as to how it goes.