On Sat, Jul 23, 2011 at 01:52:25PM -0700, Chris Travers wrote:
> Pete: Can you define ERP? Does that include our order/quotations
> management side?
I can't define it, and it will mean different things to different
people of course. A quick glance at openerp.com gives this list:
* CRM
* Accounting
* Point of Sale
* Project Management
* Warehouse Management
* Human Resources
* Purchase
* Manufacturing
* Marketing
* Invoicing
* Application Builder
... so there's a starting point anyway.
> Part of the issue is that accounting as a software discipline is
> becoming as subset of ERP as a general discipline (as is CRM btw).
> Even Quickbooks offers features which are more traditionally ERP
> functions than accounting functions.
Is Quickbooks an accountancy package or an ERP package? Perhaps they are
trying to move into that space and for a proprietary application that is
probably a wise strategy. "Look, more features!", they can shout. LSMB
doesn't have the same pressures, however, and I think it's fine (ideal,
even) that it shouldn't keep adding features into the core codebase
which aren't there to solve the core problem, which I see as making
bookkeeping and accountancy manageable for SMEs.
> One of the current issues with the codebase (which is relevant to your
> concern) is that it is currently a bit of an
> everything-and-kitchen-sink approach already. I mean, how many of the
> users are using the POS functionality?
Quite. I suspect it's low, but those who do use it probably like it. It
might be a good case for splitting out into an optional module.
> TBH we are already to that point. A POS interface, quotation and
> order management, etc. are all things which probably belong more in a
> larger ERP framework than in a accounting program narrowly defined.
Agreed, albeit that order management is more tightly bound to the core
than the other examples.
> So what I would like to see is something for 2.0 that gives us all a
> benefit from both worlds.
>
> 1) A core module (basic contact/credit account tracking, chart of
> accounts, AR/AP transactions, GL transactions, financial reports. No
> inventory tracking, no quotations and order entry tracking. Just a
> solid, very basic accounting module.
>
> 2) Other modules around this which provide additional functionality.
> Areas which would be moved into optional modules would be:
> a) Job costing and project accounting.
> b) POS and retail management
> c) Inventory, Warehousing, Invoicing, and Order Management
> d) Pricegroups
> e) Departments and budgets
> f) Assemblies and manufacturing
> etc.....
Again, all good stuff.
> So I don't entirely disagree with you. I just don't want to see us in
> a corner because we focus on financial accounting to the exclusion of
> other (higher end) forms of accounting which pretty much require wider
> functionality to work.
My concern is that the development time which is spent on these other
areas is time not spent on the core. Not being on the devel list it
isn't clear to me how much still needs to be done on the core to make it
rock solid (which it really has to be before anyone starts building
modules to go on top of it). Of course the team should plan ahead, but
if you are considering this wider functionality now, the question is: is
the core and the API ready for it?
Looking at 2 very successful projects with which I am familiar - apache
and perl - both have a highly modular approach with modules being
contributed from both the core dev teams and the wider communities. My
belief is that they have been successful in using this approach because
of the time and effort spent on the core and the API to begin with. If
LSMB is going along the same path then I will be very happy with it.
Hope this explains where I'm coming from,
Pete
--
Openstrike - improving business through open source
http://www.openstrike.co.uk/ or call 01722 770036 / 07092 020107
Attachment:
pgp6x4K0fVgi1.pgp
Description: PGP signature