Re: Request for comments: towards CRM functionality

[Chris Travers <..hidden..>]

On Sat, Jul 23, 2011 at 11:43 AM, Pete Houston <..hidden..> wrote:
> I would tend to agree with Bob on this one. If the development of LSMB
> concentrates on making it the best at what it does (which is accountancy
> first and foremost with hooks into inventory, PoS, etc.) and then builds
> a solid, consistent API on top of that then I would consider that as job
> done.
>
> Those who want to add in various CRM, ERP, RT and who-knows-what-else
> functionality can then choose their preferred CRM, ERP, etc. tool and
> just write the glue to go between them. This is the open source way.

Pete:  Can you define ERP?  Does that include our order/quotations
management side?

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.

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?

There are two reasons to look at extending LedgerSMB with modules to
support additional areas:

1)  It provides additional functionality out of the box that is
tightly integrated to the accounting side.  So for example one can do
management accounting based on CRM data (labor cost tracking per sales
rep per sale, etc and apply this both forward looking as well as
backward looking) which is hard to do in loosely tied systems without
adding a lot of really thick glue.

2)  It provides a model for integration with other applications.  So
if you don't like the CRM approach, it becomes easier to push data in
from a third party FOSS app, such that the benefits of #1 are
preserved.
>
> Please don't add in features like this which don't really belong in an
> accountancy package and which are implemented well elsewhere - just give
> us the tools (ie. an API) so that our choices of applications can be
> made to talk to one another.

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.

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.....

The thing is, I don't think we can get to some of the more advance
possibilties in accounting (management accounting in particular)
unless there is a model for tracking CRM data in a more
management-accounting-friendly way.  So what I am looking at first and
foremost is a way of extending the job costing side to make it more
CRM-friendly.

I do agree that if someone doesn't need something they shouldn't have
to install it.  A point of sale aimed at small retail shops doesn't
make ANY sense when installed at a financial services business, for
example.  Ideally each of these would be separate projects integrating
at the database level.  But we aren't there yet though I'd like us to
be there by 2.0.

Also as a call to the community, if there are other things you want to
see available as addons and are willing to put code into, we do have a
separate area of SVN (for 1.x) set aside for this.

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.

Best Wishes,
Chris Travers