Re: ledger-npo, configurable categories, and integration with civicrm & paypal

["Chris Travers" <..hidden..>]

Hi Brush;

Before I begin, I would like to invite you to join the -devel list as
well, as some of the more implementation-centric portions of this
discussion would be better handled there.

On 10/11/07, brush <..hidden..> wrote:
> allies!
>
> it's wonderful to discover ledger-smb and this thriving community.  i'm
> tech and financial coordinator for TLC Farm, a "small to medium"
> non-profit (NPO) with $100-200k annual budget.  since our founding,
> we've been committed to using open source technologies and approaches
> regarding both software and information, content creation, etc.

Welcome aboard!  It also looks like open source is a good fit for the
sort of community you are trying to develop with TLC Farm (judging by
your web site).

> sql-ledger was the only OSS accounting package available to us at the
> time; we've been running a mildly (and badly) hacked version 2.4.11 since
> then.  CRM and donor relationship management has also been important to
> us, and we've been growing with the CiviCRM project on top of drupal.
>
Understood.  There has been some talk about CiviCRM integration.  Most
of this will probably need to wait for LedgerSMB 1.3 however.

> i'd love to upgrade to ledger-smb, and am curious about various aspects
> that would make our lives a lot easier.
>
> A:
> first, and perhaps most importantly: the transaction categorization
> capacity of SL 2.4.11 is not adequate to the needs of a nonprofit; this
> has been mentioned in the thread on ledger-npo from last year.

One of the most important thing to do is to understand exactly what is
needed.  This list (-users) is the best place to discuss functional
(non-technical) requirements.  Perhaps you can provide more
information as to what you need exactly.

> most organizations use a nested hierarchy within the chart of accounts
> to achieve adequate reporting and distinction between different kinds of
> transactions.  so, for example:
>
> account 8110-022-123-ED07 might refer:
>
>   1) to the type of entry (8110 - supplies)
>   2) to the program or department from whose budget it came (02x =
> education; 022 = sustainability workshop series)
>   3) to the grant or restricted asset to bill (123 - the 2007 whole
> earth foundation "climate conditions" grant)
>   4) to a budgeted project which may span multiple programs/grants (ED07
> - the Earth Day 2007 set of outreach, fundraising, educational, and
> demonstration activities)

Hierarchical accounts are somewhat of a problem on the current
codebase.  The best time and place to address this is as we start to
move towards 1.4.  If you are reasonably technical, please join us on
the -devel list and help us work out how to make this happen.

> one wants to be able to report dynamically over the various categories
> of transaction.  in the above example, one would want to be able to
> search for "all education [ie. 02x] transactions" OR "-023- transactions
> only" as well.  in fact, one would like to produce reports in which
> summaries by level of details can be chosen.
>
> ideally, one could accommodate the nested COA model since that is what
> many org's already use.  however, one could also use other fields; we've
> tried to do this by using "department" for program and "project" for
> project; the restricted funds bit is left out, and a major headache.

I am guessing that a nested COA hierarchy system would make life
easier for a lot of people.  I have a few ideas.
>
> moreover, there is a major difficulty in using the "department"
> field: each transactions, involving multiple entries, can only be
> attached to a single department.  however, frequently we have expenses
> which are split over multiple departments (ie. telephone, split evenly
> between fundraising, programs, and management).  it is bulky and
> confusing to create multiple transactions for a single bill.  ideally,
> the "department" (and other, hierarchically reportable fields) would be
> able to be set per entry, like the project is.

One of our major areas of effort is in separating workflow from
accounting logic.  When you enter a telephone bill, if you need to
track by department, this is going to mean a separate line item for
each.  However, as we move forward, we want to make this a lot easier
to automate.
>
> it seems this may be possible in ledgersmb 1.2.x; is that true?  what
> difficulties may remain?

Basically, in these areas, we are not yet substantially different from
SQL-Ledger 2.6.  These areas are going to be re-engineered in 1.4, but
the time to discuss how to make it work is now.

>
> B: for a variety of reasons, i think it makes sense for CRM modules to
> be independent of accounting.  however, they will ideally coordinate
> information with a minimum of re-entered data or data mismatch.  CiviCRM
> is probably always going to reside on a different server than ledgersmb,
> but we'd like transactions (probably entered first in CiviCRM) to be
> smoothly uploaded into ledgerSMB.  any work on this?  thoughts?  links
> to other examples of automated batch processing?

CiviCRM is also written in PHP which means we can't call eachother's
functions directly.  There are other ways of doing this, and there has
been some discussion on the CiviCRM lists on such integration.

Unfortunately the greatest obstacle at the momnt is that the relevant
portions of both programs changing drastically between the current
released branch and the next one.
>
> [UPDATE] i just noticed that some folk at least on the CiviCRM side are
> investigating the possibilities: see http://civicrm.org/node/239 .  any
> thoughts on how we can support this happening?

Bradley Kuhn of the SFLC seems to be pushing this.  I am on the
CiviCRM list in order to help provide some high-level guidance on
making this happen easily.
>
> C: similarly, we'd like to be able to sync our PayPal transactions with
> LedgerSMB (for now, just on a monthly basis).  we'd need some
> dupe-checking probably on transaction code, since CiviCRM entries may
> already include paypal payments.  any work on this?
>
Not at the moment.  We would accept contributions if you want to work
on it.  This would seem to be a low priority at least for me and maybe
for other community developers.  However, you are welcome to take any
of the paths available:

1)  File a eature request.  I can't imagine that this will be a huge
priority for me, but you never  know-- someone may see your feature
request and decide they need ot too, and make a contribution.
Regardless of other steps, this is a good place to start (sourceforge
feature request tracker).

2)  You can write the code yourself and contribute it. If you do this,
it is a good idea to communicate a fair bit on the -devel list both
before you write the code and while we are evaluating it.  We will
work with you to get your features added, but you can plan on having
your first few submissions sent back for modifications.

3) You can hire someone (inside or outside the community) to do the
development and  have them coordinate with us via the -devel list.

4)  For areas which are pending re-design, you can and should get
involved in all discussions you feel comfortable with on both the
-users (for usability/functionality/workflow issues) and -devel (for
technical and implementation discussions).

Hope this helps,
Chris Travers