Files @ 0737c90fd50f
Branch filter:

Location: NPO-Accounting/npo-accounting-ikiwiki/Words/accounting.html

bkuhn
See how separating the items with <hr/> looks.
  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
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>