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

[Bradley M. Kuhn]

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