<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 14, 2013 at 10:01 AM, Tim Schofield <span dir="ltr"><<a href="mailto:tim.schofield1960@gmail.com" target="_blank">tim.schofield1960@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Talking about the maths side reminds me that if you are designing a<br>
new accounting application from scratch (I don't understand why but<br>
that's another discussion) don't make the mistake openerp did, make<br>
sure you do the arithmetic as integers rather than floating point.<br>
Using floating point is a common mistake, which can end up with an out<br>
of balance TB.<br></blockquote><div><br></div><div>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. </div>
<div> <br></div><div>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.</div>
<div><br></div><div>Best Wishes,</div><div>Chris Travers</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Tim<br>
<div><div class="h5"><br>
On 14 November 2013 10:49, Chris Travers <<a href="mailto:chris.travers@gmail.com">chris.travers@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Wed, Nov 13, 2013 at 5:00 PM, Bradley M. Kuhn <<a href="mailto:bkuhn@sfconservancy.org">bkuhn@sfconservancy.org</a>><br>
> wrote:<br>
>><br>
>> Chris,<br>
>><br>
>> Chris Travers wrote on 27 October:<br>
>> > I have gone ahead and added technical details of LedgerSMB.<br>
>><br>
>> Thanks for doing that!<br>
>><br>
>> Meanwhile, based on a previous discussion that you and had a while back,<br>
>> I was thinking today about your idea of using SQL stored procedures as a<br>
>> double-entry accounting engine.<br>
>><br>
>> Having looked a lot recently at people re-implementing, over and over,<br>
>> double-entry accounting in their own way, that perhaps we should define<br>
>> an API to double-entry accounting that is separated from all other parts<br>
>> of an ERP and/or accounting software system.<br>
><br>
><br>
> That's a worthy goal.  This is difficult for a number of reasons (which I<br>
> will address below) but to the extent we can all work together on an API,<br>
> this means that the accounting logic becomes pluggable and folks can use<br>
> whatever systems they prefer.  If someone wanted to connect things to<br>
> $proprietary_accounting_system that might even be possible.  If nothing<br>
> else, a solid API would mean flexibility, interest, and an ability to<br>
> develop a lot of other things faster.  This being said, the closer we can<br>
> get, the better.  We'd have to make some decisions in some areas though.<br>
><br>
> So on to the problems.  As I see it there are three of them.<br>
><br>
> 1.  Complexity of input data.  Financial transactions are complex, and they<br>
> get more complex in certain kinds of environments.  In the for-profit world,<br>
> I would expect a grocery store receipt to add up to maybe a hundred of gl<br>
> line items.  There are almost certainly similarly complex transactions in<br>
> the NPO world.  So an API would need to be able to handle that and be<br>
> capable of handling some complexity of data structure (JSON would not be a<br>
> bad choice).<br>
><br>
> 2.  Pervasiveness of data.  Financial transactions touch everything and they<br>
> tend to be connected to everything.  Managing that connectedness is a<br>
> significant challenge of a sort of loosely coupled approach.  An API would<br>
> need to be able to handle that.<br>
><br>
> 3.  Integration of data.  Often times it is important to be able to do<br>
> complex reporting   Often times one needs to tie line items of a transaction<br>
> back to some other data.  For example, you might want to find out "how has<br>
> our spending on scalpals we ship to clinics in Africa compared to our<br>
> spending on insulin?"  While you can do this with just the chart of accounts<br>
> if you set up your accounts with this question in mind, doing it after the<br>
> fact requires being able to tie line items to scalpals or insulin as they<br>
> are being entered.  Additionally doing the reporting effectively often<br>
> requires that all the data is in the same database so the RDBMS can optimize<br>
> things like joins (in that environment).<br>
><br>
> Having said all of this, if you had an API that submitted a JSON document<br>
> and received one back with line identifiers, etc. populated, then it should<br>
> be manageable enough.  There are naturally limits to this kind of modularity<br>
> due to the complexity of the data being stored and retrieved on both sides.<br>
><br>
>><br>
>> In other words, double-entry accounting is just a form of math.  Most<br>
>> math systems have a clear API that has details of how to interact with<br>
>> that math system.<br>
>><br>
>> We should have this for double-entry accounting, too.<br>
>><br>
>> I put some very rough (and currently confusing) notes in:<br>
>>   <a href="http://npoacct.sfconservancy.org/UseCases/StorageAPI/" target="_blank">http://npoacct.sfconservancy.org/UseCases/StorageAPI/</a><br>
><br>
><br>
> As far as posting data, that's pretty good.<br>
>><br>
>><br>
>><br>
>><br>
>> I would love to define this API with input from other projects, as it<br>
>> might allow us to make storage mechanisms for double-entry data more<br>
>> interchangable.<br>
>><br>
>> What do you all think of this idea?<br>
><br>
><br>
> On the whole, quite supportive.<br>
>><br>
>> --<br>
>> Bradley M. Kuhn, Executive Director, Software Freedom Conservancy<br>
><br>
><br>
><br>
><br>
> --<br>
> Best Wishes,<br>
> Chris Travers<br>
><br>
> Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor<br>
> lock-in.<br>
> <a href="http://www.efficito.com/learn_more.shtml" target="_blank">http://www.efficito.com/learn_more.shtml</a><br>
><br>
</div></div><div class="im">> _______________________________________________<br>
> npo-accounting mailing list<br>
> <a href="mailto:npo-accounting@sfconservancy.org">npo-accounting@sfconservancy.org</a><br>
> <a href="http://lists.sfconservancy.org/mailman/listinfo/npo-accounting" target="_blank">http://lists.sfconservancy.org/mailman/listinfo/npo-accounting</a><br>
><br>
<br>
<br>
<br>
--<br>
</div>Course View Towers,<br>
Plot 21 Yusuf Lule Road,<br>
Kampala<br>
T   <a href="tel:%2B256%20%280%29%20312%20314%20418" value="+256312314418">+256 (0) 312 314 418</a><br>
M <a href="tel:%2B256%20%280%29%20752%20963%20325" value="+256752963325">+256 (0) 752 963 325</a><br>
<a href="http://www.weberpafrica.com" target="_blank">www.weberpafrica.com</a><br>
Twitter: @TimSchofield2<br>
Blog: <a href="http://weberpafrica.blogspot.co.uk/" target="_blank">http://weberpafrica.blogspot.co.uk/</a><br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
npo-accounting mailing list<br>
<a href="mailto:npo-accounting@sfconservancy.org">npo-accounting@sfconservancy.org</a><br>
<a href="http://lists.sfconservancy.org/mailman/listinfo/npo-accounting" target="_blank">http://lists.sfconservancy.org/mailman/listinfo/npo-accounting</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Best Wishes,<div>Chris Travers</div><div><br></div><div>Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor lock-in.</div>
<div><a href="http://www.efficito.com/learn_more.shtml" target="_blank">http://www.efficito.com/learn_more.shtml</a></div></div>
</div></div>