On Jan 29, 2008 8:25 PM, Jeff Kowalczyk <
..hidden..> 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.