shared API for double-entry accounting, treating it as a 'math' library. (was Re: Announcing Joar Wandborg joining the project as a Conservancy contractor.)

[Chris Travers]

On Wed, Nov 13, 2013 at 5:00 PM, Bradley M. Kuhn <bkuhn at sfconservancy.org>wrote:

> Chris,
>
> Chris Travers wrote on 27 October:
> > I have gone ahead and added technical details of LedgerSMB.
>
> Thanks for doing that!
>
> Meanwhile, based on a previous discussion that you and had a while back,
> I was thinking today about your idea of using SQL stored procedures as a
> double-entry accounting engine.
>
> Having looked a lot recently at people re-implementing, over and over,
> double-entry accounting in their own way, that perhaps we should define
> an API to double-entry accounting that is separated from all other parts
> of an ERP and/or accounting software system.
>

That's a worthy goal.  This is difficult for a number of reasons (which I
will address below) but to the extent we can all work together on an API,
this means that the accounting logic becomes pluggable and folks can use
whatever systems they prefer.  If someone wanted to connect things to
$proprietary_accounting_system that might even be possible.  If nothing
else, a solid API would mean flexibility, interest, and an ability to
develop a lot of other things faster.  This being said, the closer we can
get, the better.  We'd have to make some decisions in some areas though.

So on to the problems.  As I see it there are three of them.

1.  Complexity of input data.  Financial transactions are complex, and they
get more complex in certain kinds of environments.  In the for-profit
world, I would expect a grocery store receipt to add up to maybe a hundred
of gl line items.  There are almost certainly similarly complex
transactions in the NPO world.  So an API would need to be able to handle
that and be capable of handling some complexity of data structure (JSON
would not be a bad choice).

2.  Pervasiveness of data.  Financial transactions touch everything and
they tend to be connected to everything.  Managing that connectedness is a
significant challenge of a sort of loosely coupled approach.  An API would
need to be able to handle that.

3.  Integration of data.  Often times it is important to be able to do
complex reporting   Often times one needs to tie line items of a
transaction back to some other data.  For example, you might want to find
out "how has our spending on scalpals we ship to clinics in Africa compared
to our spending on insulin?"  While you can do this with just the chart of
accounts if you set up your accounts with this question in mind, doing it
after the fact requires being able to tie line items to scalpals or insulin
as they are being entered.  Additionally doing the reporting effectively
often requires that all the data is in the same database so the RDBMS can
optimize things like joins (in that environment).

Having said all of this, if you had an API that submitted a JSON document
and received one back with line identifiers, etc. populated, then it should
be manageable enough.  There are naturally limits to this kind of
modularity due to the complexity of the data being stored and retrieved on
both sides.


> In other words, double-entry accounting is just a form of math.  Most
> math systems have a clear API that has details of how to interact with
> that math system.
>
> We should have this for double-entry accounting, too.
>
> I put some very rough (and currently confusing) notes in:
>   http://npoacct.sfconservancy.org/UseCases/StorageAPI/


As far as posting data, that's pretty good.

>
>
>
> I would love to define this API with input from other projects, as it
> might allow us to make storage mechanisms for double-entry data more
> interchangable.
>
> What do you all think of this idea?
>

On the whole, quite supportive.

> --
> Bradley M. Kuhn, Executive Director, Software Freedom Conservancy
>



-- 
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor
lock-in.
http://www.efficito.com/learn_more.shtml
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/npo-accounting/attachments/20131114/f5cf97d0/attachment.html>