shared API for double-entry accounting, treating it as a 'math' library.

[Tim Schofield]

I am fairly new to this group having been recommended to it by someone
else. I come to this as a professional accountant, and self taught
programmer.

I am sure this will be something discussed before but......

I am interested to know why there is a perceived need for specialist
accounting system for non-profits. From my point of view a good
accounting system will work for any type of organisation, it is really
the chart of accounts that varies from one type of organisation to
another. Double entry book keeping is the same, they all have cash
books, assets, stock etc.

Tim

On 15 November 2013 16:48, Bradley M. Kuhn <bkuhn at ebb.org> wrote:
> Chris,
>
> Your 20,000 invoice/week example reads to me like a classic scaling
> issue that could be addressed in various ways, but certainly is going to
> require specialized software development to handle in any event.
>
> Meanwhile, when I think about the full space of users for a possible NPO
> accounting software project, the bulk of them are going to be at small
> non-profits with 1-5 bookkeepers and no more than a 100-200 invoices a
> week.  As you say, these sort of high-volume situations come in up heavy
> inventory based accounting for large-scale retail or manufacturing is
> surely a niche.  I can imagine very large non-profits (say, the Red
> Cross) having to deal with this kind of volume, but I don't think we
> have the expertise nor the resources assembled here to figure out how
> handle that sort of situation.
>
> As we've been doing these codebase evals, I continually come back to the
> conclusion that everyone who has approached this problem in the Free
> Software community (including us!)  had a small-scale, niche market in
> mind.  Ours at the moment is non-profits -- and in particular fund-based
> fiscal sponsorship accounting with 30 or more (up to a thousand, I
> suspect, when we consider an org like Fractured Atlas) pools of
> temporarily restricted assets.
>
> We basically have two choices of approach to this situation (and I don't
> think this is a false dichotomy but if it is, let me know):
>
>   (a) We can do the same that everyone else did: start a project, and/or
>       bend an existing codebase, to address our niche, and have yet
>       another specialized version of one of the existing accounting
>       systems, or
>
>   (b) try to build a toolkit useful in the creation of small business
>       accounting applications (and reusing code from whereever seems
>       prudent, when that code is flexible enough to be adapted into a
>       toolkit).
>
> I'll try to anticipate that you might be about say that your 20k
> invoices/week *is* a small business, and thus this project won't even be
> able to please small businesses in your niche if we design the
> infrastructure "too flexibly" such that it can't do what you might
> consider a basic operation.
>
> But, here's the thing: people keep solving this problem over and over
> again in slightly different ways to address specific niches.  For
> example, I'd bet LedgerSMB is the only Free Software accounting project
> who has even tried to solve the batch 20k invoices/week problem.
>
> In other words, I think we have settle for the idea that we're not going
> to *revolutionize* accounting software systems -- not even non-profit
> accounting ones.  We're going to help by making things for non-profits a
> bit better, and hopefully the code this project does will be at least
> marginally more reusable than the code already out there for other
> accounting needs.  I'm somewhat inspired by CiviCRM here -- they started
> focusing on a niche (contact database for community organizing) but
> build a flexible enough codebase that they've been able to add many
> modules.
>
> Meanwhile, if the re-usability angle means we made it impossible for the
> users who want to get into the
> tens-of-thousands-of-transactions-per-week to reuse our code, I think
> that's a trade-off I'm likely willing to make for now.
>
> Chris, however, if you have a specific idea for a design of an API that
> would handle both, I'm open-minded to it.  I'm not trying to cover my
> eyes and pretend the problem doesn't exist; I'm trying to find a project
> that we can make real progress on with the meager resources we have.
>
>
>
> BTW, if they pay 20k invoices per week in a batch, and *are* a small
> business, how in the world do they review all of them, and do internal
> approvals, etc.?
> --
>    -- bkuhn
> _______________________________________________
> 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/