<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 13, 2013 at 5:00 PM, Bradley M. Kuhn <span dir="ltr"><<a href="mailto:bkuhn@sfconservancy.org" target="_blank">bkuhn@sfconservancy.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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></blockquote><div><br></div><div>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.</div>
<div><br></div><div>So on to the problems.  As I see it there are three of them.</div><div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div><br></div><div>As far as posting data, that's pretty good.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></blockquote><div><br></div><div>On the whole, quite supportive. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888">--<br>
Bradley M. Kuhn, Executive Director, Software Freedom Conservancy<br>
</font></span></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>