I'm looking for a solution with POS printing.
The scenario is:
A restaurant currently has a POS system up and running, they take orders from iPads in store and have a network setup that processes the orders and automatically prints them out on the thermal printer in the kitchen (pretty cool, huh?). Anyway, this restaurant also has a website for online ordering (written in PHP) which have to be checked via email manually. The restaurant wants their online system to send each order to the printer, automatically.
I must add that I haven't been involved with the development of their site or their in-house ordering system. I haven't worked with PHP to POS systems before - is it even possible? What are the alternative solutions for sending data from website forms to a POS printer automatically?
Webservice on the php website with a status flag for processed or not. Query the webservice from the internal application/an internal application every x minutes (1 is probably sufficient) lists all unprocessed orders and flags them as processed when its retrieved (hack but will suffice)
c#/java/c++ etc will be best to avoid the issue of web based not able to access local printer interface/queue app simply takes result set back from web service and formats/prints it.
Fairly simple about 20 lines of php perhaps and probably less than 100k of c# would do it nicely.
I would be thinking less about the printer, and more about how to interface with the POS software that they use. Find out the manufacturer, product name, and version number (if you can). Then check with that manufacturer to see if they have an SDK or API that you can hook into.
When it comes to actually hooking it into the web site, I wouldn't make the call directly from your PHP page into their POS system. Even if possible, this sort of tight coupling would mean that if the POS system was offline or inaccessible, that the web site would be broken.
Instead, use a database or queuing system to store the orders from the web site. Write a small bit of middleware (such as a daemon or service) that will read from the database or queue, and feed orders to the POS system using their SDK or API.
Keeping these systems decoupled will save you much time and money in the long run. Without it, you are certain to have scalability issues.
Think about this for a second - if you did write directly to the printer, what would happen if two orders came in simultaneously? Would the ticket get garbled with data from both orders? Would one order fail while the other went through? This is more likely than you think, since restaurants tend to be busy during peak times. Go ask anyone that's worked in a pizza delivery restaurant on Superbowl Sunday.
If the Tablet application is really connecting via WIFI to a configured network printer, and the printer is only Network connected, and there is no other PC, then it means you have a bit more work cut out for you. There are a couple of approaches you can take. Either way you are going to have to have a PC on site. If you can print to the network printer on the local network, from a web browser, you have a shot with an easy approach. If you set up a PC with Web Application access, you can configure the same network printer on the local network, and then just create an html page with a stylesheet media=print that formats the order appropriately, then a javascript print call on button click should do it. This requires a PC logged in to the web site, and a person managing the orders and clicking print in order to get the order data to the printer using standard methods. The second approach is to identify the printer manufacturer, download the POS drivers for the printer model and get a class written up to handle acquiring, queuing, and releasing invoices to the printer, and then create a scheduled job that writes orders to the printer similar to a service. This would require a PC on-site as well, but would not require a person monitoring the orders and printing the queue. The second approach is going to cost the client significantly more money to develop.