5 ms·

We're actually looking into OpenERP for potential implementation at my company (around 2500 employees). I've been doing a good bit of research. My findings so f

by rufugee 14y ago

We're actually looking into OpenERP for potential implementation at my company (around 2500 employees). I've been doing a good bit of research. My findings so far: The good: * Done in python. Easy to read. * Easy to extend or modify (done via python modules) * Supposedly can be extended/configured to a certain extent without code (field additions, etc) * Has a long list of modules available, and core modules which support my needed (accounting, finance, warehouse/supply chain, HR/Payroll) * Requires PostgreSQL...my database of choice. * Seems pretty stable...I haven't hit many bugs yet. * Fully open source under the AGPL...you get the entire product, unlike others such as OpenBravo and XTuple where you have to pay to get certain features. The flip side of this is that because it's AGPL, you have to release the source any modifications or modules you make unless you pay OpenERP for a subscription (and consequently, a different license) The bad: * The documentation is badly out of date. There are two versions...web-based and PDF. The web-based ones are more updated, but still out of date. Trying to learn as complex a system as an ERP with broken documentation is a very frustrating exercise. This is probably to biggest headache for me and it has significantly slowed our evaluation. It'd be at least a little better if I could pay for improved docs, but this is all they have...even paying customers are provided out-dated documentation. * Not many success stories in the US. I get the impression that it's more popular in Europe (OpenERP is out of Belgium). * Company is a bit unresponsive. I've contacted them and had very little successful communication with them, even though they have a US rep. If you read online, others seem to have had similar problems. We're still going to make a go of it, because our current system is legacy and leaves a lot to be desired. However, I think they could have a lot more success by hiring tech writers and making sure the documentation stays up to date.

smiler 14y ago
Are you looking to hire anyone to assist with the implementation? I work in the manufacturing / logistics / WH arena and am very keen on ERP work
icebraining 14y ago
Consider contacting one of the partners; many of us provide support and training as well as custom development of modules.
nwmcsween 14y ago
IMO the whole openerp architecture seems very ugly, the code even more so.
- rufugee 14y ago
  specifically?
  - lcampbell 14y ago
    I looked over the code because there was talk of switching over to OpenERP. My thoughts on the server component so far (keeping in mind that I'm exceptionally pedantic) -- - Internal inconsistencies w.r.t formatting -- sometimes there's newlines between functions, sometimes not. - Docstrings are fairly haphazard. I remember seeing some somewhere, but can't find them anymore. I have no idea what the `ir` module does or what it's for. - The custom ORM (`bin/osv/`) scares the daylights out of me. It only has 4 test cases that I can see (in `test/test_osv.py`). I don't see any test cases for the DSL that the `osv` module provides. - It appears that the ORM uses raw SQL as an intermediate for composing queries, then uses regular expressions to extract data from these intermediates. I've only spent 10 minutes thumbing through the code, haven't read the docs or anything, so the above is a very shallow analysis.
    - pestaa 14y ago
      It's obvious you're pedantic. How much I wish `inconsistent newlines between functions` would be my first shallow observation when reading through my code.
      - rufugee 14y ago
        Agreed. You should see the code of our current ERP ;-) Generally, I find the code to be well-organized and easy to find (it's just a set of python modules for the most part). I can't speak to the syntax formatting or functionality of the ORM yet...
      - deleted 14y ago
        [deleted]
herge 14y ago
There was a talk about OpenERP at Montreal-Python about a month ago. The video of it is not up yet but will be some time soon here: http://www.youtube.com/user/MontrealPython http://www.youtube.com/user/MontrealPython Also, there is a Montreal (EST time zone!) based consultancy company called Savoir-Faire Linux that are involved in the development of OpenERP, and can help you with any implementations.
drd 14y ago
"The bad: * The documentation is badly out of date....." Completely normal, this is one of the common risks with software projects: ".... This is a fact that companies do their best to have revenue since the first days of their creation. This implies another fact that always a proper documentation is the last thing they provide to the users....." (http://www.drdacademy.com/?id=17 http://www.drdacademy.com/?id=17)
- mgkimsal 14y ago
  It also seems that bad documentation is something that keeps people from adopting (read, providing those sought-after revenues) some software packages.
  - drd 14y ago
    That is true. The best example is here in this post, i.e. the results of evaluation by <rufugee> which is posted above. SAP suffers from the same problem too. Of course, this could be a business objective for the software producer, since, training brings in income.
fheopenerp 14y ago
Hello, I'm the director of OpenERP US. I would like to make it up to you and schedule a phone call with the right person here. At least we are responsive on HN ;) Concerning references in the US, I will be glad to share that with you. Just email me (fhe@o...... .com) or PM me (@fheopenerp).
sharoonthomas 14y ago
* OpenERP is written in python (great) but the code is not readable. They do not follow any coding standards (like pep008) and don't even have a code review process. Give it a try [1]. At my company we say "Unlearn python before you start working on openerp". * Yes OpenERP is easy to extend and modify and has a good modular architecture. However, the API is badly broken, have a look at an on_change event handler on the server side [2]. Think of modifying this in your extended module! * Extending/Configuring without code is marketing speak. It sounds and looks great for a demo, but is impractical to be used in any business. For example, you modify how a product view looks like by changing it without code and it works, then next time you upgrade the product module, you will lose all the changes. It is also a quick recipe to making your ERP a 800lbs gorilla which cannot be maintained. * They have a long list of modules. Most of the modules are crap uploaded by OpenERP partners who implemented some specific business case for a customer of theirs and is not generic. In most failed OpenERP implementations, the primary reason is almost always these extra modules which introduce dangerous bugs. I would not blame the developers alone, because OpenERP itself lacks a culture of testing and lacks sufficient tools to test the software. Be sure to evaluate every module with real world business cases. For example, purchasing in a different currency could be a feature on the "wishlist" [3]. And BTW.. they have a module which can order " sandwiches, pizzas, prepared meals, etc." for the 2500 employees :P (i am not joking [4]) * Postgresql - it's a great database, but badly misused in Open ERP [5] (it is from the core stock module which keeps track of your inventory). I will personally not trust any software which uses "distinct" [6] in a query as important as that. It also shows how OpenERP will not scale and how Open ERP developers lack the basic knowledge of SQL (not that they know better python). * Open ERP is far from stable. Memory leaks are pretty common and add to that poorly written python. We have been maintaining production instances for a really long time and I would not find it a stable software. * As for AGPL - it may not be the right license for an ERP. AGPL requires you to make the source of the software available as a downloadable link to all users of the software. Would you be willing to do that for all your employees ? And moving a bit more back - they switched overnight from GPL to AGPL claiming OpenERP SA owns all the copyright. Even if we assume they really do, you have an "open source" software which has no community contributions or you have a software which has a license which stands to be sued by any previous contributor some day. * Success Stories: There may not be many actually. I personally know several of the companies in the openerp success cases page who do not use OpenERP anymore. * Partners/Implementors of Open ERP: Here you will find the good, bad and the ugly. There are some great implementors who understand OpenERP well but may not necessarily be the partners in the spotlight. The gold, silver and ready partnership levels are just a matter of how much money you paid Open ERP SA (the company behind openerp). Chose your implementor very carefully. If they say, it has everything you want and works just like that - they are lying to you. I recommend reading a recent article a community member has written, it's pretty detailed and in french (but google translate seems to translate it well) [7]. And finally, the recent fuss about "sorry sap". It looks more like an ambitious plan to have a negative social campaign about SAP and hope that SAP would fork out a few million dollars to acquire them. Venture capitalists who invested in OpenERP surely have an exit plan ? [1] http://bazaar.launchpad.net/~openerp/openobject-server/trunk/view/head:/openerp/osv/orm.py http://bazaar.launchpad.net/~openerp/openobject-server/trunk... [2] http://bazaar.launchpad.net/~openerp/openobject-addons/6.1/view/head:/sale/sale.py#L1190 http://bazaar.launchpad.net/~openerp/openobject-addons/6.1/v... [3] https://groups.google.com/d/msg/tryton/1kOND1_kGZ8/7MCU2V699OoJ https://groups.google.com/d/msg/tryton/1kOND1_kGZ8/7MCU2V699... [4] http://v6.openerp.com/node/1278 http://v6.openerp.com/node/1278 [5] http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/view/head:/stock/stock.py#L114 http://bazaar.launchpad.net/~openerp/openobject-addons/trunk... [6] http://www.thedwick.com/2005/11/how-distinct-hides-bad-sql/ http://www.thedwick.com/2005/11/how-distinct-hides-bad-sql/ [7] http://translate.google.com/translate?hl=en&sl=fr&u=http://people.via.ecp.fr/~alexis/openerp/&prev=/search%3Fq%3Dalexis%2Bde%2Blattre%2Bopenerp%26hl%3Den%26tbo%3Dd&sa=X&ei=ZxPIUNrSF8ryrQeky4HYDQ&ved=0CGwQ7gEwBw http://translate.google.com/translate?hl=en&sl=fr&u=...

by rufugee 14y ago

smiler 14y ago

Are you looking to hire anyone to assist with the implementation? I work in the manufacturing / logistics / WH arena and am very keen on ERP work

icebraining 14y ago

Consider contacting one of the partners; many of us provide support and training as well as custom development of modules.

nwmcsween 14y ago

IMO the whole openerp architecture seems very ugly, the code even more so.

rufugee 14y ago
specifically?
- lcampbell 14y ago
  I looked over the code because there was talk of switching over to OpenERP. My thoughts on the server component so far (keeping in mind that I'm exceptionally pedantic) -- - Internal inconsistencies w.r.t formatting -- sometimes there's newlines between functions, sometimes not. - Docstrings are fairly haphazard. I remember seeing some somewhere, but can't find them anymore. I have no idea what the `ir` module does or what it's for. - The custom ORM (`bin/osv/`) scares the daylights out of me. It only has 4 test cases that I can see (in `test/test_osv.py`). I don't see any test cases for the DSL that the `osv` module provides. - It appears that the ORM uses raw SQL as an intermediate for composing queries, then uses regular expressions to extract data from these intermediates. I've only spent 10 minutes thumbing through the code, haven't read the docs or anything, so the above is a very shallow analysis.
  - pestaa 14y ago
    It's obvious you're pedantic. How much I wish `inconsistent newlines between functions` would be my first shallow observation when reading through my code.
    - rufugee 14y ago
      Agreed. You should see the code of our current ERP ;-) Generally, I find the code to be well-organized and easy to find (it's just a set of python modules for the most part). I can't speak to the syntax formatting or functionality of the ORM yet...
    - deleted 14y ago
      [deleted]

herge 14y ago

There was a talk about OpenERP at Montreal-Python about a month ago. The video of it is not up yet but will be some time soon here: http://www.youtube.com/user/MontrealPython http://www.youtube.com/user/MontrealPython Also, there is a Montreal (EST time zone!) based consultancy company called Savoir-Faire Linux that are involved in the development of OpenERP, and can help you with any implementations.

drd 14y ago

"The bad: * The documentation is badly out of date....." Completely normal, this is one of the common risks with software projects: ".... This is a fact that companies do their best to have revenue since the first days of their creation. This implies another fact that always a proper documentation is the last thing they provide to the users....." (http://www.drdacademy.com/?id=17 http://www.drdacademy.com/?id=17)

mgkimsal 14y ago
It also seems that bad documentation is something that keeps people from adopting (read, providing those sought-after revenues) some software packages.
- drd 14y ago
  That is true. The best example is here in this post, i.e. the results of evaluation by <rufugee> which is posted above. SAP suffers from the same problem too. Of course, this could be a business objective for the software producer, since, training brings in income.

fheopenerp 14y ago

Hello, I'm the director of OpenERP US. I would like to make it up to you and schedule a phone call with the right person here. At least we are responsive on HN ;) Concerning references in the US, I will be glad to share that with you. Just email me (fhe@o...... .com) or PM me (@fheopenerp).

sharoonthomas 14y ago

* OpenERP is written in python (great) but the code is not readable. They do not follow any coding standards (like pep008) and don't even have a code review process. Give it a try [1]. At my company we say "Unlearn python before you start working on openerp". * Yes OpenERP is easy to extend and modify and has a good modular architecture. However, the API is badly broken, have a look at an on_change event handler on the server side [2]. Think of modifying this in your extended module! * Extending/Configuring without code is marketing speak. It sounds and looks great for a demo, but is impractical to be used in any business. For example, you modify how a product view looks like by changing it without code and it works, then next time you upgrade the product module, you will lose all the changes. It is also a quick recipe to making your ERP a 800lbs gorilla which cannot be maintained. * They have a long list of modules. Most of the modules are crap uploaded by OpenERP partners who implemented some specific business case for a customer of theirs and is not generic. In most failed OpenERP implementations, the primary reason is almost always these extra modules which introduce dangerous bugs. I would not blame the developers alone, because OpenERP itself lacks a culture of testing and lacks sufficient tools to test the software. Be sure to evaluate every module with real world business cases. For example, purchasing in a different currency could be a feature on the "wishlist" [3]. And BTW.. they have a module which can order " sandwiches, pizzas, prepared meals, etc." for the 2500 employees :P (i am not joking [4]) * Postgresql - it's a great database, but badly misused in Open ERP [5] (it is from the core stock module which keeps track of your inventory). I will personally not trust any software which uses "distinct" [6] in a query as important as that. It also shows how OpenERP will not scale and how Open ERP developers lack the basic knowledge of SQL (not that they know better python). * Open ERP is far from stable. Memory leaks are pretty common and add to that poorly written python. We have been maintaining production instances for a really long time and I would not find it a stable software. * As for AGPL - it may not be the right license for an ERP. AGPL requires you to make the source of the software available as a downloadable link to all users of the software. Would you be willing to do that for all your employees ? And moving a bit more back - they switched overnight from GPL to AGPL claiming OpenERP SA owns all the copyright. Even if we assume they really do, you have an "open source" software which has no community contributions or you have a software which has a license which stands to be sued by any previous contributor some day. * Success Stories: There may not be many actually. I personally know several of the companies in the openerp success cases page who do not use OpenERP anymore. * Partners/Implementors of Open ERP: Here you will find the good, bad and the ugly. There are some great implementors who understand OpenERP well but may not necessarily be the partners in the spotlight. The gold, silver and ready partnership levels are just a matter of how much money you paid Open ERP SA (the company behind openerp). Chose your implementor very carefully. If they say, it has everything you want and works just like that - they are lying to you. I recommend reading a recent article a community member has written, it's pretty detailed and in french (but google translate seems to translate it well) [7]. And finally, the recent fuss about "sorry sap". It looks more like an ambitious plan to have a negative social campaign about SAP and hope that SAP would fork out a few million dollars to acquire them. Venture capitalists who invested in OpenERP surely have an exit plan ? [1] http://bazaar.launchpad.net/~openerp/openobject-server/trunk/view/head:/openerp/osv/orm.py http://bazaar.launchpad.net/~openerp/openobject-server/trunk... [2] http://bazaar.launchpad.net/~openerp/openobject-addons/6.1/view/head:/sale/sale.py#L1190 http://bazaar.launchpad.net/~openerp/openobject-addons/6.1/v... [3] https://groups.google.com/d/msg/tryton/1kOND1_kGZ8/7MCU2V699OoJ https://groups.google.com/d/msg/tryton/1kOND1_kGZ8/7MCU2V699... [4] http://v6.openerp.com/node/1278 http://v6.openerp.com/node/1278 [5] http://bazaar.launchpad.net/~openerp/openobject-addons/trunk/view/head:/stock/stock.py#L114 http://bazaar.launchpad.net/~openerp/openobject-addons/trunk... [6] http://www.thedwick.com/2005/11/how-distinct-hides-bad-sql/ http://www.thedwick.com/2005/11/how-distinct-hides-bad-sql/ [7] http://translate.google.com/translate?hl=en&sl=fr&u=http://people.via.ecp.fr/~alexis/openerp/&prev=/search%3Fq%3Dalexis%2Bde%2Blattre%2Bopenerp%26hl%3Den%26tbo%3Dd&sa=X&ei=ZxPIUNrSF8ryrQeky4HYDQ&ved=0CGwQ7gEwBw http://translate.google.com/translate?hl=en&sl=fr&u=...