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

Thu Nov 14 22:50:52 EST 2013

On Thu, Nov 14, 2013 at 10:01 AM, Tim Schofield <tim.schofield1960 at gmail.com
> wrote:

> 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.
>

Basically you have two options here.  One way or another it must resolve to
some sort of integer math using a base-ten compatible system which
addresses the floating point component as well.  If you need to do costing,
you may need to track precision well beyond what you might think so
typically I recommend using decimal-compatible arbitrary precision math
libraries instead of either integers or floating points.

What we do in LedgerSMB is use Math::BigFloat on the application side and
Numeric on the database side.  This means that we are guaranteed not to
have the binary round-off problems that happen with standard floating point
types.

Best Wishes,
Chris Travers

> 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/
> _______________________________________________
> npo-accounting mailing list
> npo-accounting at sfconservancy.org
> http://lists.sfconservancy.org/mailman/listinfo/npo-accounting
>

-- 
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/78d6b4b0/attachment-0001.html>