NPO-Accounting/npo-accounting-ikiwiki
6
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Added stub on the models of accounting

Browse source
This commit is contained in:
Joar Wandborg 2013-11-25 22:57:26 +01:00
parent 440d3fef79
commit 36fc93837d
2 changed files with 632 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

494
Words/accounting.html Normal file
View file

@ -0,0 +1,494 @@
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>The Models of Accounting</title>
<!-- 2013-11-25 Mon 22:56 -->
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
<meta name="generator" content="Org-mode"/>
<meta name="author" content="Joar Wandborg"/>
<style type="text/css">
<!--/*--><![CDATA[/*><!--*/
.title { text-align: center; }
.todo { font-family: monospace; color: red; }
.done { color: green; }
.tag { background-color: #eee; font-family: monospace;
padding: 2px; font-size: 80%; font-weight: normal; }
.timestamp { color: #bebebe; }
.timestamp-kwd { color: #5f9ea0; }
.right { margin-left: auto; margin-right: 0px; text-align: right; }
.left { margin-left: 0px; margin-right: auto; text-align: left; }
.center { margin-left: auto; margin-right: auto; text-align: center; }
.underline { text-decoration: underline; }
#postamble p, #preamble p { font-size: 90%; margin: .2em; }
p.verse { margin-left: 3%; }
pre {
border: 1px solid #ccc;
box-shadow: 3px 3px 3px #eee;
padding: 8pt;
font-family: monospace;
overflow: auto;
margin: 1.2em;
}
pre.src {
position: relative;
overflow: visible;
padding-top: 1.2em;
}
pre.src:before {
display: none;
position: absolute;
background-color: white;
top: -10px;
right: 10px;
padding: 3px;
border: 1px solid black;
}
pre.src:hover:before { display: inline;}
pre.src-sh:before { content: 'sh'; }
pre.src-bash:before { content: 'sh'; }
pre.src-emacs-lisp:before { content: 'Emacs Lisp'; }
pre.src-R:before { content: 'R'; }
pre.src-perl:before { content: 'Perl'; }
pre.src-java:before { content: 'Java'; }
pre.src-sql:before { content: 'SQL'; }
table { border-collapse:collapse; }
td, th { vertical-align:top; }
th.right { text-align: center; }
th.left { text-align: center; }
th.center { text-align: center; }
td.right { text-align: right; }
td.left { text-align: left; }
td.center { text-align: center; }
dt { font-weight: bold; }
.footpara:nth-child(2) { display: inline; }
.footpara { display: block; }
.footdef { margin-bottom: 1em; }
.figure { padding: 1em; }
.figure p { text-align: center; }
.inlinetask {
padding: 10px;
border: 2px solid gray;
margin: 10px;
background: #ffffcc;
}
#org-div-home-and-up
{ text-align: right; font-size: 70%; white-space: nowrap; }
textarea { overflow-x: auto; }
.linenr { font-size: smaller }
.code-highlighted { background-color: #ffff00; }
.org-info-js_info-navigation { border-style: none; }
#org-info-js_console-label
{ font-size: 10px; font-weight: bold; white-space: nowrap; }
.org-info-js_search-highlight
{ background-color: #ffff00; color: #000000; font-weight: bold; }
/*]]>*/-->
</style>
<script type="text/javascript">
/*
@licstart The following is the entire license notice for the
JavaScript code in this tag.
Copyright (C) 2012 Free Software Foundation, Inc.
The JavaScript code in this tag is free software: you can
redistribute it and/or modify it under the terms of the GNU
General Public License (GNU GPL) as published by the Free Software
Foundation, either version 3 of the License, or (at your option)
any later version. The code is distributed WITHOUT ANY WARRANTY;
without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE. See the GNU GPL for more details.
As additional permission under GNU GPL version 3 section 7, you
may distribute non-source (e.g., minimized or compacted) forms of
that code without the copy of the GNU GPL normally required by
section 4, provided you include this license notice and a URL
through which recipients can access the Corresponding Source.
@licend The above is the entire license notice
for the JavaScript code in this tag.
*/
<!--/*--><![CDATA[/*><!--*/
function CodeHighlightOn(elem, id)
{
var target = document.getElementById(id);
if(null != target) {
elem.cacheClassElem = elem.className;
elem.cacheClassTarget = target.className;
target.className = "code-highlighted";
elem.className = "code-highlighted";
}
}
function CodeHighlightOff(elem, id)
{
var target = document.getElementById(id);
if(elem.cacheClassElem)
elem.className = elem.cacheClassElem;
if(elem.cacheClassTarget)
target.className = elem.cacheClassTarget;
}
/*]]>*///-->
</script>
</head>
<body>
<div id="content">
<h1 class="title">The Models of Accounting</h1>
<div id="table-of-contents">
<h2>Table of Contents</h2>
<div id="text-table-of-contents">
<ul>
<li><a href="#sec-1">1. Models</a>
<ul>
<li><a href="#sec-1-1">1.1. Account</a></li>
<li><a href="#sec-1-2">1.2. Entry</a></li>
<li><a href="#sec-1-3">1.3. Change</a></li>
<li><a href="#sec-1-4">1.4. Reports</a></li>
</ul>
</li>
<li><a href="#sec-2">2. The Unix philosophy</a>
<ul>
<li><a href="#sec-2-1">2.1. Rule of Modularity</a></li>
<li><a href="#sec-2-2">2.2. Rule of Clarity</a></li>
<li><a href="#sec-2-3">2.3. Rule of Composition</a></li>
<li><a href="#sec-2-4">2.4. Rule of Separation</a></li>
<li><a href="#sec-2-5">2.5. Rule of Simplicity</a></li>
<li><a href="#sec-2-6">2.6. Rule of Parsimony</a></li>
<li><a href="#sec-2-7">2.7. Rule of Transparency</a></li>
<li><a href="#sec-2-8">2.8. Rule of Robustness</a></li>
<li><a href="#sec-2-9">2.9. Rule of Representation</a></li>
<li><a href="#sec-2-10">2.10. Rule of Least Surprise</a></li>
<li><a href="#sec-2-11">2.11. Rule of Silence</a></li>
<li><a href="#sec-2-12">2.12. Rule of Repair</a></li>
<li><a href="#sec-2-13">2.13. Rule of Economy</a></li>
<li><a href="#sec-2-14">2.14. Rule of Generation</a></li>
<li><a href="#sec-2-15">2.15. Rule of Optimization</a></li>
<li><a href="#sec-2-16">2.16. Rule of Diversity</a></li>
<li><a href="#sec-2-17">2.17. Rule of Extensibility</a></li>
</ul>
</li>
</ul>
</div>
</div>
<div id="outline-container-sec-1" class="outline-2">
<h2 id="sec-1"><span class="section-number-2">1</span> Models</h2>
<div class="outline-text-2" id="text-1">
<p>
My idea is to write this system in Python, using SQLAlchemy for
persistent storage.
</p>
<p>
The following subsections are the models that I think apply to a
bare-bone accounting API. The word "Model" is borrowed from
SQLAlchemy where a Model is an abstraction of an SQL database table.
</p>
<p>
Each of the subsections present the attributes of the model, in SQL
these would be "fields".
</p>
<p>
My choice of SQLAlchemy and SQL is because of familiarity [from
mediagoblin, talkatv, [proprietary] projects] and that transactions,
accounts both have strong relations inbetween.
</p>
</div>
<div id="outline-container-sec-1-1" class="outline-3">
<h3 id="sec-1-1"><span class="section-number-3">1.1</span> Account</h3>
<div class="outline-text-3" id="text-1-1">
<ul class="org-ul">
<li>Unique ID
</li>
<li>Name
</li>
<li>Parent ID, for hierarchical account structures
</li>
</ul>
</div>
</div>
<div id="outline-container-sec-1-2" class="outline-3">
<h3 id="sec-1-2"><span class="section-number-3">1.2</span> Entry</h3>
<div class="outline-text-3" id="text-1-2">
<ul class="org-ul">
<li>Unique ID
</li>
<li>Summary, descriptive summary of the Changes herein
</li>
<li>Timestamp
</li>
</ul>
<p>
Represents a series of transactions(Changes) between different
accounts. The sum of the transactions must be 0.
</p>
</div>
</div>
<div id="outline-container-sec-1-3" class="outline-3">
<h3 id="sec-1-3"><span class="section-number-3">1.3</span> Change</h3>
<div class="outline-text-3" id="text-1-3">
<ul class="org-ul">
<li>Unique ID
</li>
<li>Entry ID
</li>
<li>Account ID
</li>
<li>Value, fixed-precision value between -Infinity..+Infinity
</li>
</ul>
<p>
This model represents a change in an Account's value.
</p>
<p>
TODO: multi-currency
</p>
</div>
</div>
<div id="outline-container-sec-1-4" class="outline-3">
<h3 id="sec-1-4"><span class="section-number-3">1.4</span> Reports</h3>
</div>
</div>
<div id="outline-container-sec-2" class="outline-2">
<h2 id="sec-2"><span class="section-number-2">2</span> The Unix philosophy</h2>
<div class="outline-text-2" id="text-2">
<p>
Included for reference from
<a href="http://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond.E2.80.99s_17_Unix_Rules">http://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond.E2.80.99s_17_Unix_Rules</a>
</p>
</div>
<div id="outline-container-sec-2-1" class="outline-3">
<h3 id="sec-2-1"><span class="section-number-3">2.1</span> Rule of Modularity</h3>
<div class="outline-text-3" id="text-2-1">
<p>
Developers should build a program out of simple parts connected by
well defined interfaces, so problems are local, and parts of the
program can be replaced in future versions to support new
features. This rule aims to save time on debugging code that is
complex, long, and unreadable.
</p>
</div>
</div>
<div id="outline-container-sec-2-2" class="outline-3">
<h3 id="sec-2-2"><span class="section-number-3">2.2</span> Rule of Clarity</h3>
<div class="outline-text-3" id="text-2-2">
<p>
Developers should write programs as if the most important
communication is to the developer, including him- or herself, who
will read and maintain the program rather than the computer. This
rule aims to make code readable and comprehensible for whomever
works on the code in future.
</p>
</div>
</div>
<div id="outline-container-sec-2-3" class="outline-3">
<h3 id="sec-2-3"><span class="section-number-3">2.3</span> Rule of Composition</h3>
<div class="outline-text-3" id="text-2-3">
<p>
Developers should write programs that can communicate easily with
other programs. This rule aims to allow developers to break down
projects into small, simple programs rather than overly complex
monolithic programs.
</p>
</div>
</div>
<div id="outline-container-sec-2-4" class="outline-3">
<h3 id="sec-2-4"><span class="section-number-3">2.4</span> Rule of Separation</h3>
<div class="outline-text-3" id="text-2-4">
<p>
Developers should separate the mechanisms of the programs from the
policies of the programs; one method is to divide a program into a
front-end interface and back-end engine that interface communicates
with. This rule aims to let policies be changed without
destabilizing mechanisms and consequently reducing the number of
bugs.
</p>
</div>
</div>
<div id="outline-container-sec-2-5" class="outline-3">
<h3 id="sec-2-5"><span class="section-number-3">2.5</span> Rule of Simplicity</h3>
<div class="outline-text-3" id="text-2-5">
<p>
Developers should design for simplicity by looking for ways to
break up program systems into small, straightforward cooperating
pieces. This rule aims to discourage developers’ affection for
writing “intricate and beautiful complexities” that are in reality
bug prone programs.
</p>
</div>
</div>
<div id="outline-container-sec-2-6" class="outline-3">
<h3 id="sec-2-6"><span class="section-number-3">2.6</span> Rule of Parsimony</h3>
<div class="outline-text-3" id="text-2-6">
<p>
Developers should avoid writing big programs. This rule aims to
prevent overinvestment of development time in failed or suboptimal
approaches caused by the owners of the program’s reluctance to
throw away visibly large pieces of work. Smaller programs are not
only easier to optimize and maintain; they are easier to delete
when deprecated.
</p>
</div>
</div>
<div id="outline-container-sec-2-7" class="outline-3">
<h3 id="sec-2-7"><span class="section-number-3">2.7</span> Rule of Transparency</h3>
<div class="outline-text-3" id="text-2-7">
<p>
Developers should design for visibility and discoverability by
writing in a way that their thought process can lucidly be seen by
future developers working on the project and using input and output
formats that make it easy to identify valid input and correct
output. This rule aims to reduce debugging time and extend the
lifespan of programs.
</p>
</div>
</div>
<div id="outline-container-sec-2-8" class="outline-3">
<h3 id="sec-2-8"><span class="section-number-3">2.8</span> Rule of Robustness</h3>
<div class="outline-text-3" id="text-2-8">
<p>
Developers should design robust programs by designing for
transparency and discoverability, because code that is easy to
understand is easier to stress test for unexpected conditions that
may not be foreseeable in complex programs. This rule aims to help
developers build robust, reliable products.
</p>
</div>
</div>
<div id="outline-container-sec-2-9" class="outline-3">
<h3 id="sec-2-9"><span class="section-number-3">2.9</span> Rule of Representation</h3>
<div class="outline-text-3" id="text-2-9">
<p>
Developers should choose to make data more complicated rather than
the procedural logic of the program when faced with the choice,
because it is easier for humans to understand complex data compared
with complex logic. This rule aims to make programs more readable
for any developer working on the project, which allows the program
to be maintained.
</p>
</div>
</div>
<div id="outline-container-sec-2-10" class="outline-3">
<h3 id="sec-2-10"><span class="section-number-3">2.10</span> Rule of Least Surprise</h3>
<div class="outline-text-3" id="text-2-10">
<p>
Developers should design programs that build on top of the
potential users' expected knowledge; for example, ‘+’ should always
mean addition in a calculator program. This rule aims to encourage
developers to build intuitive products that are easy to use.
</p>
</div>
</div>
<div id="outline-container-sec-2-11" class="outline-3">
<h3 id="sec-2-11"><span class="section-number-3">2.11</span> Rule of Silence</h3>
<div class="outline-text-3" id="text-2-11">
<p>
Developers should design programs so that they do not print
unnecessary output. This rule aims to allows other programs and
developers to pick out the information they need from a program's
output without having to parse verbosity.
</p>
</div>
</div>
<div id="outline-container-sec-2-12" class="outline-3">
<h3 id="sec-2-12"><span class="section-number-3">2.12</span> Rule of Repair</h3>
<div class="outline-text-3" id="text-2-12">
<p>
Developers should design programs that fail in a manner that is
easy to localize and diagnose or in other words “fail
noisily”. This rule aims to prevent incorrect output from a program
from becoming an input and corrupting the output of other code
undetected.
</p>
</div>
</div>
<div id="outline-container-sec-2-13" class="outline-3">
<h3 id="sec-2-13"><span class="section-number-3">2.13</span> Rule of Economy</h3>
<div class="outline-text-3" id="text-2-13">
<p>
Developers should value developer time over machine time, because
machine cycles as of the year 2013 are relatively inexpensive
compared to prices in the 1970s. This rule aims to reduce
development costs of projects.
</p>
</div>
</div>
<div id="outline-container-sec-2-14" class="outline-3">
<h3 id="sec-2-14"><span class="section-number-3">2.14</span> Rule of Generation</h3>
<div class="outline-text-3" id="text-2-14">
<p>
Developers should avoid writing code by hand and instead write
abstract high-level programs that generate code. This rule aims to
reduce humans errors and save time.
</p>
</div>
</div>
<div id="outline-container-sec-2-15" class="outline-3">
<h3 id="sec-2-15"><span class="section-number-3">2.15</span> Rule of Optimization</h3>
<div class="outline-text-3" id="text-2-15">
<p>
Developers should prototype software before polishing it. This rule
aims to prevent developers from spending too much time for marginal
gains.
</p>
</div>
</div>
<div id="outline-container-sec-2-16" class="outline-3">
<h3 id="sec-2-16"><span class="section-number-3">2.16</span> Rule of Diversity</h3>
<div class="outline-text-3" id="text-2-16">
<p>
Developers should design their programs to be flexible and
open. This rule aims to make programs flexible, allowing them to be
used in other ways than their developers intended.
</p>
</div>
</div>
<div id="outline-container-sec-2-17" class="outline-3">
<h3 id="sec-2-17"><span class="section-number-3">2.17</span> Rule of Extensibility</h3>
<div class="outline-text-3" id="text-2-17">
<p>
Developers should design for the future by making their protocols
extensible, allowing for easy plugins without modification to the
program's architecture by other developers, noting the version of
the program, and more. This rule aims to extend the lifespan and
enhance the utility of the code the developer writes.
</p>
</div>
</div>
</div>
</div>
<div id="postamble" class="status">
<p class="author">Author: Joar Wandborg</p>
<p class="date">Created: 2013-11-25 Mon 22:56</p>
<p class="creator"><a href="http://www.gnu.org/software/emacs/">Emacs</a> 24.3.1 (<a href="http://orgmode.org">Org</a> mode 8.0.6)</p>
<p class="xhtml-validation"><a href="http://validator.w3.org/check?uri=referer">Validate XHTML 1.0</a></p>
</div>
</body>
</html>

138
Words/accounting.org Normal file
View file

@ -0,0 +1,138 @@
#+TITLE: The Models of Accounting
#+AUTHOR: Joar Wandborg
* Models
My idea is to write this system in Python, using SQLAlchemy for
persistent storage.
The following subsections are the models that I think apply to a
bare-bone accounting API. The word "Model" is borrowed from
SQLAlchemy where a Model is an abstraction of an SQL database table.
Each of the subsections present the attributes of the model, in SQL
these would be "fields".
My choice of SQLAlchemy and SQL is because of familiarity [from
mediagoblin, talkatv, [proprietary] projects] and that transactions,
accounts both have strong relations inbetween.
** Account
- Unique ID
- Name
- Parent ID, for hierarchical account structures
** Entry
- Unique ID
- Summary, descriptive summary of the Changes herein
- Timestamp
Represents a series of transactions(Changes) between different
accounts. The sum of the transactions must be 0.
** Change
- Unique ID
- Entry ID
- Account ID
- Value, fixed-precision value between -Infinity..+Infinity
This model represents a change in an Account's value.
TODO: multi-currency
** Reports
* The Unix philosophy
Included for reference from
http://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond.E2.80.99s_17_Unix_Rules
** Rule of Modularity
Developers should build a program out of simple parts connected by
well defined interfaces, so problems are local, and parts of the
program can be replaced in future versions to support new
features. This rule aims to save time on debugging code that is
complex, long, and unreadable.
** Rule of Clarity
Developers should write programs as if the most important
communication is to the developer, including him- or herself, who
will read and maintain the program rather than the computer. This
rule aims to make code readable and comprehensible for whomever
works on the code in future.
** Rule of Composition
Developers should write programs that can communicate easily with
other programs. This rule aims to allow developers to break down
projects into small, simple programs rather than overly complex
monolithic programs.
** Rule of Separation
Developers should separate the mechanisms of the programs from the
policies of the programs; one method is to divide a program into a
front-end interface and back-end engine that interface communicates
with. This rule aims to let policies be changed without
destabilizing mechanisms and consequently reducing the number of
bugs.
** Rule of Simplicity
Developers should design for simplicity by looking for ways to
break up program systems into small, straightforward cooperating
pieces. This rule aims to discourage developers’ affection for
writing “intricate and beautiful complexities” that are in reality
bug prone programs.
** Rule of Parsimony
Developers should avoid writing big programs. This rule aims to
prevent overinvestment of development time in failed or suboptimal
approaches caused by the owners of the program’s reluctance to
throw away visibly large pieces of work. Smaller programs are not
only easier to optimize and maintain; they are easier to delete
when deprecated.
** Rule of Transparency
Developers should design for visibility and discoverability by
writing in a way that their thought process can lucidly be seen by
future developers working on the project and using input and output
formats that make it easy to identify valid input and correct
output. This rule aims to reduce debugging time and extend the
lifespan of programs.
** Rule of Robustness
Developers should design robust programs by designing for
transparency and discoverability, because code that is easy to
understand is easier to stress test for unexpected conditions that
may not be foreseeable in complex programs. This rule aims to help
developers build robust, reliable products.
** Rule of Representation
Developers should choose to make data more complicated rather than
the procedural logic of the program when faced with the choice,
because it is easier for humans to understand complex data compared
with complex logic. This rule aims to make programs more readable
for any developer working on the project, which allows the program
to be maintained.
** Rule of Least Surprise
Developers should design programs that build on top of the
potential users' expected knowledge; for example, ‘+’ should always
mean addition in a calculator program. This rule aims to encourage
developers to build intuitive products that are easy to use.
** Rule of Silence
Developers should design programs so that they do not print
unnecessary output. This rule aims to allows other programs and
developers to pick out the information they need from a program's
output without having to parse verbosity.
** Rule of Repair
Developers should design programs that fail in a manner that is
easy to localize and diagnose or in other words “fail
noisily”. This rule aims to prevent incorrect output from a program
from becoming an input and corrupting the output of other code
undetected.
** Rule of Economy
Developers should value developer time over machine time, because
machine cycles as of the year 2013 are relatively inexpensive
compared to prices in the 1970s. This rule aims to reduce
development costs of projects.
** Rule of Generation
Developers should avoid writing code by hand and instead write
abstract high-level programs that generate code. This rule aims to
reduce humans errors and save time.
** Rule of Optimization
Developers should prototype software before polishing it. This rule
aims to prevent developers from spending too much time for marginal
gains.
** Rule of Diversity
Developers should design their programs to be flexible and
open. This rule aims to make programs flexible, allowing them to be
used in other ways than their developers intended.
** Rule of Extensibility
Developers should design for the future by making their protocols
extensible, allowing for easy plugins without modification to the
program's architecture by other developers, noting the version of
the program, and more. This rule aims to extend the lifespan and
enhance the utility of the code the developer writes.