On Jan 29, 2008 8:25 PM, Jeff Kowalczyk <[EMAIL PROTECTED]> wrote:
> On Tue, 29 Jan 2008 19:14:46 -0800, Richard Hernandez wrote:
> > Actually (Vtiger) is selling it as a complete package. Vtiger has the
> > quote, price list, orders, etc. sections already there. Maybe this may
> > be an easier path.
>
> I was thinking of Vtiger when this thread started. When last I looked in
> on them, there was a major effort to add these features (which appears to
> have been followed through on), but at the time there was no clear sense
> of where to draw the line as a stop against becoming an accounting system.
>
> I viewed it as a cautionary tale, that once a toe is dipped into either
> CRM or Accounting duties, the expectations rapidly snowball to go all the
> way down the feature path.
In general, agreed.
Unfortunately, I havent found any (yet) open source CRM apps which seem
interested in making their db schemas sane (vtiger included). This means:
1) No ability to do cross-application reporting in a sane way
2) No ability to do db-level sync in a sane way (integration has to be built
into both applications rather than using any sort of db-level updates).
The last time I wrote a CRM app, it was about 1/3 the SLOC that LSMB is
currently (about 20k). I know how much work it is which is one reason why I
don't particularly want to be saddled with it long-term. However, it solves
a number of really important problems such as having a single point of
tracking invoices, and the like.
I would also add that CRM is very much like ERP in the sense that different
businesses may have vastly different needs. I am not yet convinced that
there is a one-size-fits-all CRM structure that will work, and this is
likely to be an area where a *lot* of vertical solutions end up being
necessary.
>
> I'd be content if LedgerSMB's customer -> contact entities avoided adding
> a single field that wasn't used for calculations or intended for printing
> to transaction documents, and instead there was a clear consensus and
> documentation for integrators to add their own schema, and a hook for
> their add-on form to render those fields.
What about bank accounts, telephone numbers, email addresses, and the like?
Even if one doesn't intend to print those on the transactions, they are
extremely important to ensure that one gets paid and paid properly.
I would draw the line at:
The core database schema should not include any information which is not
required for billing or accounting purposes. Any other information should
be added to custom div's on the contact forms and have custom workflow
scripts attached. There are proper hooks in place for this sort of thing
currently in /trunk though they do not use the old custom_queries
infrastructure.
BTW, I *am* planning on introducing a proof of concept CRM module as an
add-on sometime after 1.3 as a way to help get some of my customers off
software which is harder to support (and hence tends to be barely maintained
because it is too expensive to add new features). I would hope that others
would help take this and make it a more viable solution. However, it is
certainly not going to be initially a substitute for integration with the
likes of vTiger (in fact, it will likely be almost but not entirely unlike
vTiger....).
Best Wishes,
Chris Travers
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ledger-smb-users mailing list
Ledger-smb-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
