[ILUG] OpenERP demo server

Colin Rooney colin.rooney at gmail.com
Wed Sep 28 08:13:04 IST 2011


> Unless someone advises us otherwise, can we proceed on the basis that
> OpenERP is "as good as it gets" - compared to other "Cloud" systems...
> Eg, Xero, KashFlow, FrontAccounting, FreeAgent/Iris Openbooks, GNUCash,
> xTuple, LedgerSMB, TurboCash, SQL-Ledger, SageOne, PostBooks, OpenBravo,
> Adempiere, WebERP, GnuAccounting - to name but a few ;-)


Firstly let me say I was one of the founders of Adempiere so I am bound
to be biased!

But I like to think I am always open minded so I've always kept an eye
on what the other open ERP projects do.  Now, admittedly, it's been a
while since I looked in detail at openERP but the last time I did I
found its list of functionality broad but shallow in comparison to
Adempiere.

I also remember a discussion of Adempiere Vs. OpenERP, years ago, in the
Adempiere forums and one of the points that came out were there were
100s of plugins for OpenERP but on close inspection many "plugins" were
adding additional fields... something that takes a couple of minutes in
adempiere and is managed via an Administration UI.

But I admit that their UI is a lot slicker... now the Adempiere UI is
easily translated and this ability is one of the reason behind the
simplicty.  When I say translated, one installation could be used in
multiple languages at the same time... a German using a German UI and an
Irish with a English UI for example.  There is also a mechanism to have
the data translated, and documents can be translated and they are
printed in the language defined for the person who the document is sent
to.  So it's not just the UI that is translated.

Another reason is the Adempiere UI is dynamic, depending on your user,
role, the function you are doing or just other field value entered, the
UI can change to add and/or remove fields.

Now none of that is important to a small or micro businesses in Ireland
[unless you wanted to make like easy for foreign staff perhaps :)] I
know, but was just explaining the reasoning.

Of course the slick UI of openERP has come from a lot of investment from
the company behind openERP.  Adempiere is purely community driven so the
big, costly, advances are slower to be contributed. They do happen though.

Now, Adempiere was forked from Compiere, in 2006, another commercial
open source project which has now been sold and is gone!

One of the techniques Compiere used to raise revenue was it charged for
migration.  I'm sure we're all aware that in open source it's important
be able to keep up to date but frequent updating of your core ERP system
is not the norm.  It touches so many aspects of a business that once
installed & working people try to touch it as little of possible - less
risk!
But, as anybody who uses open source will know and in particular open
source with a public internet face - security issues means you must
continuously keep up to date.

Adempiere releases LTS versions and patches are retrofitted to those for
a number of years.  And if and when you do decide to migrate it is free!
What is the migration policy for openERP?  I think it was like the
Compiere model the last time I looked, i.e. you must buy a support
package to get access to migration scripts.

Now I know Adempiere is not perfect - but at least it belongs to
everyone and not to a "for now" benign company. I think we've seen a few
examples of the risks this poses in the FLOSS world in recent years.

Now to muddy the waters even more and say if I couldn't use Adempiere
(and sometimes even when I could) I would lean towards the Apache Open
for Business [OfBiz] project.  Again completely open with zero risk of
it becoming closed.  The Apache license might even suit some over the
GPL of Admepiere.  Adempiere has great a functional design - but OfBiz's
technical design is superb, if somewhat complicated at first glance.
When I consider this project is probably 10 years old the design has
stood the test of time and its SOA like architecture proved to be way
ahead of everyone else - if e-commerce was an important aspect of an ERP
implementation I would be leaning strongly in this direction.

So I say, look closely at the functionality of openERP & Adempiere...
and in particular at the depth of the actual functionality as opposed to a;
Sales Check,
Purchases Check,
Accounting Check,
type of comparison.
I would be surprised if the openERP could do all Adempiere can.  It's
all in the details!

Mind you if the target were very small companies then perhaps openERP
provides all that is required and anything more complicated is a
hindrance rather than an advantage!?

Finally, I've said here before I know Admepiere pretty much inside out
(though I've, sadly, not done much work with it in over a year at this
stage) and I know the technical aspects of OfBiz well too - so if anyone
is interested in knowing more I would gladly share what I know to do my
bit to help promote more these truly open projects here in Ireland.


Colin


On 19/09/11 16:34, Michael Kennedy wrote:
> On 19/09/2011 13:23, Bernhard Rohrer wrote:
>>   actually I would do all my accounting in OpenERP, since it allows
>> for cost accounting and project based accounting and cash flow
>> forecasts and a lot of other things that I really really want.
> 
> Super...
> 
> Unless someone advises us otherwise, can we proceed on the basis that
> OpenERP is "as good as it gets" - compared to other "Cloud" systems...
> Eg, Xero, KashFlow, FrontAccounting, FreeAgent/Iris Openbooks, GNUCash,
> xTuple, LedgerSMB, TurboCash, SQL-Ledger, SageOne, PostBooks, OpenBravo,
> Adempiere, WebERP, GnuAccounting - to name but a few ;-)
> 
> Eg, does OpenERP handle all our basic VAT needs - perhaps with add-ins...
> 
>> _but_ we also need a way to dump all that info so the accountant can
>> properly massage it and present it to revenue
> 
> Technically, that should be simple...
> 
>   1. We need a mechanism to get at the data in OpenERP. It's very likely
> that OpenERP has "export" facilities - which allow the user to dump all
> the requested data from the OpenERP DB into some standard format, such
> as CSV, Excel, etc. If not, I expect the DB structures inside OpenERP
> are "standard" (I've not checked - perhaps MySQL, PostGreSQL, etc) - in
> which case it should still be easy to extract whatever we need... If
> neither option is available, then, in an emergency, we could
> "reverse-engineer" the internal filing systems, but that's getting
> serious!, and surely not necessary.
> 
>   2. Then, we need to identify which "Accounting/Auditing" systems are
> used by the Accountants, and what "Import" facilities are available -
> perhaps CSV files; perhaps databases from "sister" bookkeeping systems.
> 
>   3. Finally, we'd need to re-jig the OpenERP data into the latter. That
> should be a simple task, if both of the data-formats are well defined.
> (I can certainly handle that aspect - if needed).
> 
> M.
> 
>> ----------------original message-----------------
>> From: "Michael Kennedy" Info at kennedysoftware.ie
>> To: "Harry Duncan" usr.src.linux at gmail.com
>> CC: ilug at linux.ie
>> Date: Mon, 19 Sep 2011 11:58:38 +0100
>> -------------------------------------------------
>>
>>
>>>> I worked on a project where we implemented the ROS XML schema's
>>>> previously, for something like VAT it is simple and quick but for the
>>>> larger forms it is quite tedious eg corporation tax and income tax.
>>>
>>> Yes, your experience ties in exactly with what I would expect.
>>>
>>> And, just on the VAT support, an important aspect would be the internal
>>> VAT features in the app (rather than the extracts for Revenue). Eg, how
>>> to handle changes in VAT-rates, support for the Cash-Accounting schemes,
>>> support for exempt customers or suppliers, exported goods/services, etc.
>>>
>>>> I would question though the value in having a completely integrated
>>>> solution, I've been doing a demo test of openerp for a business and
>>>> the goal is not to provide a full integrated accounts system but
>>>> rather to use OpenERP for supply chain through to sales and as a sales
>>>> support tool, dump invoice lists out of openerp for the accountant to
>>>> import into their book keeping to handle all the tax compliance stuff.
>>>>
>>>> There are distinct advantages from a revenue audit perspective to not
>>>> having a totally integrated solution/ Seems that it is an expectation
>>>> of revenue that they can now take a complete dump of your accounts
>>>> system to electronically analyse and they have put quite a bit of
>>>> money into software for this purpose. If you run a fully integrated
>>>> system you're a lamb to the slaughter and will be the largest repayer
>>>> of bank bailouts for years to come, keep your accounting practices
>>>> business unit focused and you're back to the playing court where you
>>>> provide complete accounts and they do the footwork with a calculator
>>>> in an audit.
>>>
>>> Very good points, Harry. Thank you.
>>>
>>> Also, the Accountant probably already has Accounting systems with
>>> whatever features (s)he requires - auditing/accounting features, links
>>> to ROS/CRO, etc, etc, (eg, Apex). In that case, the requirement would be
>>> to automate the transfer of the data/transactions from OpenERP to the
>>> A/c system, rather than to have to manually re-key the data. That should
>>> be quite easy, technically:
>>> - get the data out of OpenERP, perhaps in a CSV or "Excel" format
>>> - re-hash that into the structures needed for the Import options of
>>> the accounting systems.
>>>
>>>> Another colleague of mine who downloaded the OpenERP package later
>>>> than me was contacted by a partner in Kerry. They clearly got the lead
>>>> from the OpenERP guys, but aren't listed on the site yet.
>>>
>>> I also did not notice any mentions of Irish agents, etc, in my OpenERP
>>> searches.
>>>
>>>>> But, in case it's a whole waste of time, first we'd need to ensure
>>>>> that
>>>>> there's no other similar FOSS "Cloud" system out there with these
>>>>> features
>>>>> already implemented!
>>>>
>>>> Not an issue. Everybody knows somebody who's had a hotmail / yahoo /
>>>> gmail account hacked / hijacked. Translate that scenario to a cloud
>>>> accounting solution. Until cloud solutions are based on strong token
>>>> based authentication businesses would be mad to expose themselves to
>>>> that degree.
>>>
>>> Oooppss... I misled you - I was referring to the VAT features, etc, in
>>> OpenERP. I meant that we should try to check if someone had already
>>> implemented the VAT stuff, ROS interfaces, etc, in OpenERP (but is not
>>> here on ILUG), or if these features are already in some other FOSS/Cloud
>>> systems similar to OpenERP.
>>>
>>> - Mike
>>> -- 
>>> Irish Linux Users' Group mailing list
>>> About this list : http://mail.linux.ie/mailman/listinfo/ilug
>>> Who we are : http://www.linux.ie/
>>> Where we are : http://www.linux.ie/map/
>>>
>>


More information about the ILUG mailing list