Changeset - 716e1b6f54af
[Not reviewed]
0 1 1
Bradley Kuhn (bkuhn) - 7 years ago 2013-11-13 21:18:12
This may be a completely crazy idea, but I think it'd make the world better.
2 files changed with 63 insertions and 0 deletions:
0 comments (0 inline, 0 general)
Show inline comments
@@ -27,3 +27,4 @@ You should add your use case as a subpage of the [[UseCases]] page, to create a
### Technical-User-Center Use Cases

- [[Reading and Reporting API|UseCases/ReadAPI]]
- [[Storage API|UseCases/StorageAPI]]
Show inline comments
new file 100644
# Storage API

Most accounting systems continually reimplement double-entry accounting.  As
a developer, I find this frustrating because very commonly, user-interface
code for accounting systems is co-mingled with details of the double entry
accounting implementation.

What I propose is a clear API that simply does the basic functions of
double-entry accounting, treating double-entry accounting more like
mathematical operations and less like business logic.  Business logic varies,
but the rules of double entry accounting remain roughly the same.

Users of the API would be those who write accounting applications and want to
treat the double-entry portion purely as a black box.

The ideal scenario would be an known double-entry accounting API that
different accounting projects could support, separating the problem of
storage of double-entry accounting data from specific accounting systems.

A very rough idea of the API's core data structures follows.  This is not
fully baked.

# Postings

The primary record of a double-entry accounting is a posting, which has the
following fields:

- Date
- Payee
- Two or more entries, and the sum of the amounts on all entries must
  balance, otherwise the posting is not valid.
- State

## State

State has the following fields:

- User
- Value


The idea behind posting state is that it is somewhat user-configurable.
Typical posting states would be things like CLEARED for items that have
cleared a bank account.  However, one idea behind the state is use it to
allow for "user-specific" versions of the books.  The goal is to allow users
to "stage" postings that may or may not be accepted.  For example, a user
might submit an expense report, and the state might be "REQUESTED".
Generally, the rest of the system would ignore REQUESTED postings, as they
aren't officially approved for the books yet.

# Entry

Entries have the following fields:

- Account
- Amount
- Currency
- (optional) fixated price per unit price to another Currency
- (optional) entry-specific price to another Currency
- (optional) zero or more key value pairs for tagging


0 comments (0 inline, 0 general)