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

[Tim Schofield]

Talking about the maths side reminds me that if you are designing a
new accounting application from scratch (I don't understand why but
that's another discussion) don't make the mistake openerp did, make
sure you do the arithmetic as integers rather than floating point.
Using floating point is a common mistake, which can end up with an out
of balance TB.

Tim

On 14 November 2013 10:49, Chris Travers <chris.travers at gmail.com> wrote:
>
>
>
> 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
>
> _______________________________________________
> npo-accounting mailing list
> npo-accounting at sfconservancy.org
> http://lists.sfconservancy.org/mailman/listinfo/npo-accounting
>



-- 
Course View Towers,
Plot 21 Yusuf Lule Road,
Kampala
T   +256 (0) 312 314 418
M +256 (0) 752 963 325
www.weberpafrica.com
Twitter: @TimSchofield2
Blog: http://weberpafrica.blogspot.co.uk/