6 ms·

I couldn't agree more. A few years back I wrote integrations for various Micros/Aloha POS systems, and it was painful. The industry as a whole seems to be stuck

I couldn't agree more. A few years back I wrote integrations for various Micros/Aloha POS systems, and it was painful. The industry as a whole seems to be stuck in the 90's.

sandGorgon 12y ago
could you talk some more on what is so painful about this ? I'm looking to join a startup that is looking to play in this space (in India) and I'm wondering, from a noob POS guys/experienced developer perspective, what the challenges are ? is it that vendor docs are poor or is it something else ? I would like to think that system software integration is always trickier than .. say web API integrations.
- websitescenes 12y ago
  Did you just call me a noob? You hurt my feelings haha. It is difficult if you are coming from a web development standpoint. I started programming with PHP and moved to Ruby recently and I am not familiar with Java or the like. For someone that is familiar with those technologies I am sure it is a snap but honestly I have zero interest in learning Java or anything similar. I want to use the things I am familiar with. And yes, documentation is almost always horrible because POS companies almost always want you to pay them to integrate or extend the system.
- mamcx 12y ago
  Of curse is it. I have a iOS app that integrate with several ERPs/POS (http://elmalabarista.com/bestseller http://elmalabarista.com/bestseller) that is used in my country. In first place, API???? What the hell is that? No kid, POS/ERPs don't know what a true API is. Is direct access to the DB, plan text files, and a lot of hyper-pain talking directly to the developers of that systems. And good look doing data archeology of all of that. Because this I'm also building a POS for the iOS (in late stage, but is hard to do this solo). One of the innovations it have? The customer table is called: drum-drum-drum "Customer". Seriously, after dozens of integrations mine is the only one that the tables have names that make sense. And the fields. And the data type of that fields (cough a database have a datetime field? cough).
- SheepSlapper 12y ago
  Probably the biggest problem is that documentation doesn't exist, is wrong, or is the crappy "GetItems returns Items" variety. POS companies will often charge you a large sum of money in order to work with their systems. I think we paid Micros $10k to be able to integrate with their junk, and we had to fly to Maryland and sit in their offices for 2 days while they ran around being useless. Workflows can be vastly different. If you're trying to write an IPOS interface that abstracts all that pain away for the client that's interacting w/ the system, it can lead to weird situations. Some POS systems will let you open a check w/ nothing on it (Aloha) but some won't (Micros). And on Aloha, if a server logs in and looks at that empty check before you put something on it, it'll automatically close. There are a ton of edge cases that you have to test, and the way two POS systems work in similar conditions are never the same. Getting menu data out of a POS is a nightmare, as there's usually a ton of unused junk that you don't need. Often there are many duplicates, so the Onion topping you add to a taco is different from the Onion topping you add to nachos, and both are different from the Onion topping you'd put on a burrito. Despite the fact that it's literally the same onion being used. Sometimes, menu items that are on sale for happy hour or something aren't different items, but they get modified with "happy hour". You don't want your users seeing that junk, so you have to do a bunch of magic behind the scenes to submit the normal item AND the happy hour mod when the user orders it. I could go on, there's a LOT of this weirdness when working with POS systems and most of the time you don't know what it'll be until you've sat there banging your head against your desk because when you order a Sandwich + fries it works, but a Sandwich + garlic fries will only add the fries to the cart. Feels good when you're finally done with the integration, but it's hell getting there. Oh, and a lot of the time there is no real API, you're changing database files or doing some sort of dark voodoo magic to get the thing to work. Sometimes you get lucky and there's a SOAP service or some COM calls you can make that'll play nice with the POS, but that's hardly ever the case.
wil421 12y ago
Part of the problem is customer not wanting to update systems already in place (update to a new version of Aloha). I work for the company that makes Aloha and I can see the newer products we are offering yet not many restaurants I frequent seem to be using the new versions. We also make one for small business called Silver but I dont know how much has caught on.
- SheepSlapper 12y ago
  Totally. There hasn't been an incentive for them to upgrade, so they haven't. As more people get into the space and do cool things on top of POS systems that play nice with developers, they might be more inclined to switch/upgrade so they can have the same cool features as everyone else. The industry is definitely moving in that direction, but POS companies are behemoths that haven't had to innovate in the past 20 years, so it'll be slow and painful.
  - wil421 12y ago
    Or in my company's case we dont innovate we "buy" it and then add our logo. It really sucks because I can see what new technologies can bring to the table. I really feel POS systems should run on any desktop hardware.
  - rhizome 12y ago
    What incentive to the incumbents have to give up their lockin?

I couldn't agree more. A few years back I wrote integrations for various Micros/Aloha POS systems, and it was painful. The industry as a whole seems to be stuck in the 90's.

sandGorgon 12y ago

could you talk some more on what is so painful about this ? I'm looking to join a startup that is looking to play in this space (in India) and I'm wondering, from a noob POS guys/experienced developer perspective, what the challenges are ? is it that vendor docs are poor or is it something else ? I would like to think that system software integration is always trickier than .. say web API integrations.

websitescenes 12y ago
Did you just call me a noob? You hurt my feelings haha. It is difficult if you are coming from a web development standpoint. I started programming with PHP and moved to Ruby recently and I am not familiar with Java or the like. For someone that is familiar with those technologies I am sure it is a snap but honestly I have zero interest in learning Java or anything similar. I want to use the things I am familiar with. And yes, documentation is almost always horrible because POS companies almost always want you to pay them to integrate or extend the system.
mamcx 12y ago
Of curse is it. I have a iOS app that integrate with several ERPs/POS (http://elmalabarista.com/bestseller http://elmalabarista.com/bestseller) that is used in my country. In first place, API???? What the hell is that? No kid, POS/ERPs don't know what a true API is. Is direct access to the DB, plan text files, and a lot of hyper-pain talking directly to the developers of that systems. And good look doing data archeology of all of that. Because this I'm also building a POS for the iOS (in late stage, but is hard to do this solo). One of the innovations it have? The customer table is called: drum-drum-drum "Customer". Seriously, after dozens of integrations mine is the only one that the tables have names that make sense. And the fields. And the data type of that fields (cough a database have a datetime field? cough).
SheepSlapper 12y ago
Probably the biggest problem is that documentation doesn't exist, is wrong, or is the crappy "GetItems returns Items" variety. POS companies will often charge you a large sum of money in order to work with their systems. I think we paid Micros $10k to be able to integrate with their junk, and we had to fly to Maryland and sit in their offices for 2 days while they ran around being useless. Workflows can be vastly different. If you're trying to write an IPOS interface that abstracts all that pain away for the client that's interacting w/ the system, it can lead to weird situations. Some POS systems will let you open a check w/ nothing on it (Aloha) but some won't (Micros). And on Aloha, if a server logs in and looks at that empty check before you put something on it, it'll automatically close. There are a ton of edge cases that you have to test, and the way two POS systems work in similar conditions are never the same. Getting menu data out of a POS is a nightmare, as there's usually a ton of unused junk that you don't need. Often there are many duplicates, so the Onion topping you add to a taco is different from the Onion topping you add to nachos, and both are different from the Onion topping you'd put on a burrito. Despite the fact that it's literally the same onion being used. Sometimes, menu items that are on sale for happy hour or something aren't different items, but they get modified with "happy hour". You don't want your users seeing that junk, so you have to do a bunch of magic behind the scenes to submit the normal item AND the happy hour mod when the user orders it. I could go on, there's a LOT of this weirdness when working with POS systems and most of the time you don't know what it'll be until you've sat there banging your head against your desk because when you order a Sandwich + fries it works, but a Sandwich + garlic fries will only add the fries to the cart. Feels good when you're finally done with the integration, but it's hell getting there. Oh, and a lot of the time there is no real API, you're changing database files or doing some sort of dark voodoo magic to get the thing to work. Sometimes you get lucky and there's a SOAP service or some COM calls you can make that'll play nice with the POS, but that's hardly ever the case.

wil421 12y ago

Part of the problem is customer not wanting to update systems already in place (update to a new version of Aloha). I work for the company that makes Aloha and I can see the newer products we are offering yet not many restaurants I frequent seem to be using the new versions. We also make one for small business called Silver but I dont know how much has caught on.

SheepSlapper 12y ago
Totally. There hasn't been an incentive for them to upgrade, so they haven't. As more people get into the space and do cool things on top of POS systems that play nice with developers, they might be more inclined to switch/upgrade so they can have the same cool features as everyone else. The industry is definitely moving in that direction, but POS companies are behemoths that haven't had to innovate in the past 20 years, so it'll be slow and painful.
- wil421 12y ago
  Or in my company's case we dont innovate we "buy" it and then add our logo. It really sucks because I can see what new technologies can bring to the table. I really feel POS systems should run on any desktop hardware.
- rhizome 12y ago
  What incentive to the incumbents have to give up their lockin?