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

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

On 10/27/07, brush <..hidden..> wrote:
> dear chris,
>
> thanks for the response!  i've joined the -devel list, and am
> cross-posting because i'm not sure which is best; guidance appreciated
> re: netiquette here!
>
> On Thu, Oct 11, 2007 at 02:04:45PM -0700, Chris Travers wrote:


> > 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.
>
> i'd be happy to do so!  let me know what you'd like beyond this email...

I would subscribe to the devel list, search the archives for the CoA
proposal, and offer your thoughts on our direction.  Our current
approach is a flat CoA attached to hierarchical headers.  Mostly we
are looking at data representation at the moment.  The interface is
likely to be ostly PL/PGSQL, and a little Perl.

This means that accounts aren't really "nested" in the proper sense,
but rather subtotals can be.

I.e. if you have:
inventory
---->  cereal grains
        ----> oats
        ----> barley
        ----> wheat

you can attach a transaction to oats, wheat, or barley, but not to
inventory or cereal grains.  Hence the hierarchical structure is
purely a reporting convenience and the CoA is still flat for
transactional purposes.

>
> understood.  and, indeed, automation will be very helpful!  but the
> immediate concern i'm describing above is that, at least in the
> sql-ledger we're using, we can't even get multiple departments on a
> single transaction screen (with multiple line entries).  is that doable
> in lsmb currently?  if not, a very desirable interim solution (1.3?)
> would solve the following use case.

What abut projects?  Projects are per-line-item.

>
> telephone bill:
>
> want to credit cash account $120 for whole check amount, but make three
> separate telephone expense debits of $40 each applied to a separate
> department (edu program, farm program, admin).

Those sound a lot more like projects than departments.
>
> the easiest way i can imagine this is if each AP expense line (or GL
> entry line) included drop-downs for BOTH project (as now) and dep't.
>
> on the UI this isn't too hard, but i don't know the db structure well
> enough to know how big a change may be required.

You would need to add a department_id field to acc_trans I believe.

> > 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.
>
> SOAP is certainly a possibility, right?  i guess a core question is
> which app would be client and which the server?

We are working on a RESTful web service API.  Similar to SOAP but uses
basic HTTP as the RPC framework, and the XML document is entirely
self-contained as a data resource.  It can be accessed from any
language bu basically getting, putting, or posting XML documents.

>
> > 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.
>
> hmmm.  do you mean (for lsmb) 1.3 or 1.4?  it seems that a civicrm 2.0
> and lsmb 1.3 combo would be useful in the pretty near term.
>
> > > [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.
>
> thanks so much!  could massively amp up use of lsmb among npo's...
>
> > > 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?
> > >
> > 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).
>
> ok.  in thinking this over further, i think that for a wide range of
> applications (both civicrm and paypal, and any other source of
> accounting data legacy or otherwise) the most flexible interim approach
> would be an import infrastructure for lsmb.


> the first step, it seems to me, would be a well-commented import script.
> the following seem like useful aspects:
>
> 1) first, of course, a basic GL transaction import including dep't and
> project.
>
> 2) second, AP and AR-specific transaction import with relevant fields.
>
> 3) third, dupe-checking functionality, probably on date and amount,
> and/or transaction code (in notes?), with override option.
>
> then, scripts to convert specific output CSV's from various sources (ie.
> paypal/civicrm/etc.) to canonical import CSV format.
>
Although I am generally the first person to object to pushing XML into
everything (I personally think that XML as a format sucks for
everything except serializing objects so that they can be transformed
by another program into different objects), this seems to be a perfect
case where XML./XSLT would be a lot easier than CSV-based
manipulations.

Best Wishes,
Chris Travers