4 ms·

Show HN: Open-Source Rails Point of Sale

27 points by websitescenes 13y ago

Buetol 13y ago
Is there any screenshot or publicly accesible demo ? The linked page doesn't give much information
- websitescenes 13y ago
  When I actually finish, I will do all that stuff. I would say I am about 80% done. Trying to figure out how to make it easily extendible. I will probably use generators to facilitate custom module generation. Once those are done. I will write docs, etc. I may have jumped the gun by posting it here in its current form; Still I thought someone might find it interesting.
  - deleted 13y ago
    [deleted]
  - ondiekijunior 13y ago
    I have been involved in writing Unicenta POS an open source java point of sale, have you looked at it?
    - websitescenes 13y ago
      That's awesome! I am glad there are people addressing this issue out there. With that said, I have to say that I am not interested in java at all. I think that java is one of the limiting factors of current point of sale systems. I prefer the web based approach and think that this is the future of retail sales. With that said, there are obvious detractions to a web based approach, like having to have an internet connection but I think that is acceptable.
      - morganvachon 13y ago
        Not necessarily an Internet connection, but definitely a local network. Before we caved in and started using Quickbooks across the board for both invoicing and POS retail in our storefront, the bosses had me whip together a custom POS based on parts of OpenBravo and OpenPOS. I was running a virtualized, modified OpenBravo ERP server that was connected to the front register running a heavily modified OpenPOS front end. It was quirky, buggy, and ugly, but even if we lost Internet we could still operate as long as the LAN stayed up. Now we're using Quickbooks for everything, because our accounting office wanted easier reporting. It's a nightmare, but at least we have good outside support across the board, instead of me being on call 24/7. I'd love to give your project a shot in my spare time, and see if it might be useful for inventory management if nothing else. Quickbooks sucks in that area without their expensive add-ons.
        websitescenes 13y ago
        Inventory features are almost non-existent so far. That's going to be addressed very soon. Thanks for the feedback.
LukeWalsh 13y ago
This is something I'm 100% behind. As a developer who works integrating with point of sales systems this is an industry ripe for disruption. The pain of integrating is killing innovation in retail. Whether it will be open source or someone like square I look forward to an industry standard in the future.
- SheepSlapper 13y ago
  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 13y 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 13y 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 13y 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).
xpop2027 13y ago
This is awesome, looking forward to the progress and contributing!
- websitescenes 13y ago
  Contributing!? Really? That would be awesome. I have not worked with others via Github before and would be very interested in doing so.
al2o3cr 13y ago
Neat project. A couple code-reviewish notes: * why use protected_attributes in an new Rails 4 project? I'm curious what motivated this decision. * if you're destroying records, you'll want to look into using the :dependent option to has_many to make sure you clean things up. However, you may want to carefully consider where in the app "deletion" actually makes sense; anything that winds up in an accounting system probably shouldn't be deletable at all. * get the tests running. The version on Github has a controller test for "ZusersController" which doesn't appear to exist in the application... * a minor thing, but it'll drive future contributors crazy: hard tabs vs. soft tabs. Ruby code is usually two-space soft-tabs, but even if you don't agree with that at least be consistent. There are files on GH that are a riot of mixed tabs (configurations_controller.rb is a notable example) and nobody's got time for that. I'm not the best at catching replies on HN, but ping me on Github (same username) if you want to discuss further.
- mtrpcic 13y ago
  Thanks for someone pointing this out. There are a lot of places in the code that could use some cleaning up. The overall frontend code structure is a little lacking: * There's a "main.js", and a bunch of empty .coffee files that were presumably generated via a generator. Choose one frontend language and use it. * Vendor libs should go in vendor/assets/javascripts. This codebase has assets/javascripts/vendor, and then random vendor libs that aren't even in that folder, they're just in "javascripts". * The frontend code is going to quickly become jquery soup. There's no structure, all code executes on all pages. * Very minor, but OS specific files should be omitted from git (like .DS_Store) * Test coverage seems pretty low * The secret token is public in the git repo (Why not use secrets.yml and keep it out of SCM to be safe?) There are a myriad of other minor issues as well. It's a good idea for a project, and would help a lot of entrepreneurs out of done properly, but there are some glaring code quality issues here that worry me about the project as it grows.
  - websitescenes 13y ago
    Also really great feedback. I have been programming for only three years so I am still learning much of what you describe. I will be cleaning out the unused template files very soon. Good point on jQuery firing on each page, although I am not really sure why it matters if it has no effect. Processing time? There are no tests but I hope to add some soon. (I have never written any, so I will have to learn)
iagorodriguez 13y ago
I found this project really interesting. Forked it. It might be interesting to create platforms like this for the very commmon uses-cases: ecommecrce, blogging, CMS. Currently there are solutions for all this use cases in the rails community but imo they are pretty directed. I mean, they are "difficult" to modify. I would like something like rails composer where you can configure the basic elements of the platform without custom generators.

27 points by websitescenes 13y ago

Buetol 13y ago

Is there any screenshot or publicly accesible demo ? The linked page doesn't give much information

websitescenes 13y ago
When I actually finish, I will do all that stuff. I would say I am about 80% done. Trying to figure out how to make it easily extendible. I will probably use generators to facilitate custom module generation. Once those are done. I will write docs, etc. I may have jumped the gun by posting it here in its current form; Still I thought someone might find it interesting.
- deleted 13y ago
  [deleted]
- ondiekijunior 13y ago
  I have been involved in writing Unicenta POS an open source java point of sale, have you looked at it?
  - websitescenes 13y ago
    That's awesome! I am glad there are people addressing this issue out there. With that said, I have to say that I am not interested in java at all. I think that java is one of the limiting factors of current point of sale systems. I prefer the web based approach and think that this is the future of retail sales. With that said, there are obvious detractions to a web based approach, like having to have an internet connection but I think that is acceptable.
    - morganvachon 13y ago
      Not necessarily an Internet connection, but definitely a local network. Before we caved in and started using Quickbooks across the board for both invoicing and POS retail in our storefront, the bosses had me whip together a custom POS based on parts of OpenBravo and OpenPOS. I was running a virtualized, modified OpenBravo ERP server that was connected to the front register running a heavily modified OpenPOS front end. It was quirky, buggy, and ugly, but even if we lost Internet we could still operate as long as the LAN stayed up. Now we're using Quickbooks for everything, because our accounting office wanted easier reporting. It's a nightmare, but at least we have good outside support across the board, instead of me being on call 24/7. I'd love to give your project a shot in my spare time, and see if it might be useful for inventory management if nothing else. Quickbooks sucks in that area without their expensive add-ons.
      - websitescenes 13y ago
        Inventory features are almost non-existent so far. That's going to be addressed very soon. Thanks for the feedback.

LukeWalsh 13y ago

This is something I'm 100% behind. As a developer who works integrating with point of sales systems this is an industry ripe for disruption. The pain of integrating is killing innovation in retail. Whether it will be open source or someone like square I look forward to an industry standard in the future.

SheepSlapper 13y ago
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 13y 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 13y 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 13y 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).

xpop2027 13y ago

This is awesome, looking forward to the progress and contributing!

websitescenes 13y ago
Contributing!? Really? That would be awesome. I have not worked with others via Github before and would be very interested in doing so.

al2o3cr 13y ago

Neat project. A couple code-reviewish notes: * why use protected_attributes in an new Rails 4 project? I'm curious what motivated this decision. * if you're destroying records, you'll want to look into using the :dependent option to has_many to make sure you clean things up. However, you may want to carefully consider where in the app "deletion" actually makes sense; anything that winds up in an accounting system probably shouldn't be deletable at all. * get the tests running. The version on Github has a controller test for "ZusersController" which doesn't appear to exist in the application... * a minor thing, but it'll drive future contributors crazy: hard tabs vs. soft tabs. Ruby code is usually two-space soft-tabs, but even if you don't agree with that at least be consistent. There are files on GH that are a riot of mixed tabs (configurations_controller.rb is a notable example) and nobody's got time for that. I'm not the best at catching replies on HN, but ping me on Github (same username) if you want to discuss further.

mtrpcic 13y ago
Thanks for someone pointing this out. There are a lot of places in the code that could use some cleaning up. The overall frontend code structure is a little lacking: * There's a "main.js", and a bunch of empty .coffee files that were presumably generated via a generator. Choose one frontend language and use it. * Vendor libs should go in vendor/assets/javascripts. This codebase has assets/javascripts/vendor, and then random vendor libs that aren't even in that folder, they're just in "javascripts". * The frontend code is going to quickly become jquery soup. There's no structure, all code executes on all pages. * Very minor, but OS specific files should be omitted from git (like .DS_Store) * Test coverage seems pretty low * The secret token is public in the git repo (Why not use secrets.yml and keep it out of SCM to be safe?) There are a myriad of other minor issues as well. It's a good idea for a project, and would help a lot of entrepreneurs out of done properly, but there are some glaring code quality issues here that worry me about the project as it grows.
- websitescenes 13y ago
  Also really great feedback. I have been programming for only three years so I am still learning much of what you describe. I will be cleaning out the unused template files very soon. Good point on jQuery firing on each page, although I am not really sure why it matters if it has no effect. Processing time? There are no tests but I hope to add some soon. (I have never written any, so I will have to learn)

iagorodriguez 13y ago

I found this project really interesting. Forked it. It might be interesting to create platforms like this for the very commmon uses-cases: ecommecrce, blogging, CMS. Currently there are solutions for all this use cases in the rails community but imo they are pretty directed. I mean, they are "difficult" to modify. I would like something like rails composer where you can configure the basic elements of the platform without custom generators.