Changeset - 716e1b6f54af
[Not reviewed]
0 1 1
Bradley Kuhn (bkuhn) - 10 years ago 2013-11-13 21:18:12
bkuhn@ebb.org
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)
UseCases.mdwn
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]]
UseCases/StoargeAPI.mdwn
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)