<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">I am probably being dumb here, but in the context of an accounting system what do you mean by a standard file format? Are we talking about reports? In something like an office application an open standard document format is obvious and critical. For an accounting system?<br>
<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">I read this <a href="http://npoacct.sfconservancy.org/UseCases/StorageAPI/">http://npoacct.sfconservancy.org/UseCases/StorageAPI/</a> and it seems somewhat naive from an accounting POV. It has a simplistic view of what constitutes an accounting transaction (the bulk of transactions on accounting systems will be neither payments or receipts) and also from the need for a standard API for double entry bookkeeping. I am not sure who would use such a thing. I can't imagine a use case where you would want the front end of one system to talk to the back end of another, or am I missing something?<br>
<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Thanks<br>Tim<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 18 January 2014 10:07, Marc Paré <span dir="ltr"><<a href="mailto:marc@marcpare.com" target="_blank">marc@marcpare.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Daniel et al,<br>
<br>
I am just catching up on the discussion. While I can't really comment on the technical aspects of the API, I would like to chime in on some of the points you raise.<br>
<br>
I also agree that we need to be sensitive from where accountants are coming; they are being taught in schools (whether high school/college/university levels) using tools that are thought of as being the most appropriate for their regions.<br>
<br>
Where I am hoping this project will go, is that somewhere along our concerted efforts to build our NPO accounting tool, that we will ultimately look at establishing a standard format with an eye on having it adopted as a universal file format for all others to adopt and help maintain. Of course it would have to be an opensourced format, for which, if we are to consider it, already limits us -- XML, etc. ...<br>
<br>
At this point, now that the project has legs I also agree with Daniel that we should try to interest some international association that could be interested in maintaining the standard as an open standard as well as assure longevity to the format; or at least, that is what Daniel is suggesting. I for one put a lot of stock in the OASIS and its series of opendocument formats. As OASIS has support from many large opensource and NPO's, to me, would prove to our advantage to try to interest them in this particular project to see if they would be interested in helping document and adopt whichever format we decide on standardizing. If this were possible, we would a solid file format base to work from, and, protection from the OASIS group of the longevity of the file format.<br>
<br>
In short, I believe that at this point, we should be considering the assurance of the protection, longevity, standardization of whichever file format this project will adopt. Also consider if, whoever will champion this file format will have enough resources and industry partners to defend the format from any type of patent action assault. IMO, if we were to partner up with a group that specializes in opensource file formats such as the OASIS group, then, the file format will gain help from a group that is supported by many opensource and industry leaders, and also a group renowned for meticulous documentation of formats with the input of its stakeholder partners. Partnering with such groups will make for a more stable and dependable file format that could evolve in a more concerted effort by all of its stakeholders.<br>
<br>
Cheers,<br>
<br>
Marc<br>
<br>
[Disclaimer: I am part of the LibreOffice project -- marketing]<br>
<br>
Le 2013-11-15 13:56, Daniel Pocock a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It is also worth considering some other angles:<br>
<br>
- Somebody goes to school to learn book-keeping or accounting, usually<br>
before they really know whether they will work for a small business, a<br>
fund or NPO or whatever. What system does the school teach with? What<br>
can they install at home to practice and improve their skills? Which<br>
free software projects could try to fill this gap? Getting in at the<br>
education stage is a very powerful way to raise the profile of free<br>
software for financial purposes across the board.<br>
<br>
- as mentioned in my other email, how can products interact, e.g. using<br>
cXML or something else to exchange invoices?<br>
<br>
- internationalization: many products have a focus on their local<br>
market, e.g. Postbooks is strong for the US and European users have to<br>
set up VAT codes manually. Commercial vendors (e.g. Quickbooks) are<br>
putting out products that work out of the box for local conditions (e.g.<br>
automatically loading VAT codes in the UK, Australia, Canada and various<br>
other places). It is not really a question of language and date<br>
formats, rather, it is about building up a collection of static data<br>
such as tax rates and currency symbols. Can this type of data be<br>
gathered into a shared database that can be leveraged by all of the free<br>
software solutions who want to provide plug-and-play support for<br>
locales? It would be silly for every free project to try and duplicate<br>
this themselves.<br>
<br>
- industry associations: the financial profession and the NPO sector<br>
have various industry associations, could they be encouraged to<br>
participate in this effort, maybe forming an advisory board? Could this<br>
even help to find funding opportunities?<br>
<br>
- what we use ourselves: many free software developers and enthusiasts<br>
are self-employed. Many of us tend to patch and improve the software<br>
that we use ourselves every day and so we get to know if very well. The<br>
same is true for financial software: if we can rally a lot of people<br>
around a single product or a small group of products that they can use<br>
for themselves, they will end up promoting those to other professionals<br>
and businesses as well and it will gain further momentum. If the<br>
products in this pool are flexible and scalable enough then it meets a<br>
diverse range of business requirements and that means more free software<br>
enthusiasts are employed more of the time and there is a nice snowball<br>
effect.<span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<br>
-- <br>
Marc Paré<br>
Marc@MarcPare.com<br>
<a href="http://www.parEntreprise.com" target="_blank">http://www.parEntreprise.com</a><br>
parEntreprise.com Supports OpenDocument Formats (ODF)<br>
parEntreprise.com Supports <a href="http://www.LibreOffice.org" target="_blank">http://www.LibreOffice.org</a><br>
<br>
______________________________<u></u>_________________<br>
npo-accounting mailing list<br>
<a href="mailto:npo-accounting@sfconservancy.org" target="_blank">npo-accounting@sfconservancy.<u></u>org</a><br>
<a href="http://lists.sfconservancy.org/mailman/listinfo/npo-accounting" target="_blank">http://lists.sfconservancy.<u></u>org/mailman/listinfo/npo-<u></u>accounting</a><br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br>Course View Towers,<br>Plot 21 Yusuf Lule Road,<br>Kampala<br>T +256 (0) 312 314 418<br>M +256 (0) 752 963 325<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>
</div>