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

[Bradley M. Kuhn]

Chris,

So, I readily admit my thinking here is completely biased by my work with
Ledger-CLI.


Chris Travers wrote:
>    This is true, but you still have the issue of reporting, and the ability
>    to run reports in the future based on criteria that may not have
>    occurred to you yet.

However, I've found that the highly flexible key,value tagging of any split
portion of any posting has given me the ability to run reports of any kind I
like by just mixing and matching the values.  I've had some rather complex
reporting requirements, such as handling the public support test, and been
able to get it done.

Of course, I don't interface to an inventory system, and I can whip up a Perl
program that calls Ledger's command line if I need something more complex
than I can do in one Ledger command line.  This doesn't scale to a larger
accounting system.

OTOH, that's sort of the point: as I look at these existing systems, I don't
see any of them with the simplicity of being able to hack up my own report as
needed.  My thinking is that: no matter how good your "automated" report
builder is, you're going to often need a programmer to make a report for you
when it's complicated, and as such, I'd rather have a very accessible and
simple API that's maybe inefficient rather than a complex, efficiently
implemented system.  I'm thinking in terms of the "never try to write
optimized code on the first pass" but treat it as a refactoring task.

>    So I think what's missing is that the return values from the API would
>    need to include what was submitted plus id's for indexing on the other
>    side.

This is a very good point, but if each posting and entry has a unique
identifier, isn't that enough (after all, if it's stored in a database table,
that's what you'd have anyway).

>    The big problem that you have with API's and set-based data is that a
>    row-by-row analysis is slow and it is, quite frankly, a pain to process.

Yeah, OTOH, if we got to the problem where the system was too slow, we can
refactor.

> At any rate, from my experience I would expect the bottlenecks to be in
> trying to manage state over a stateless exchange if that is supported,

Well, that's coming back to problems that all APIs of this nature have.  If
we just have the "usual problems" it means we've moved from domain-specific
problems to general software design problems, and that makes me feel somewhat
confident that the idea could work.  (Every solution will have common,
identifiable problems faced in all software design.)

>    separation of duties/four eyes principle. How would you expect that
>    would be handled?

My thought was to use State with a value of REQUESTED, and the API user would
not consider REQUESTED transactions to officially be part of the books yet.
You could add additional states like PENDING_APPROVAL, ADDITIONAL_REVIEW,
that sort of thing.

   -- bkuhn