Annotation of pta/README, Revision 1.3
1.3 ! schwarze 1: # $Id: README,v 1.2 2020/09/27 15:38:25 schwarze Exp $
1.1 schwarze 2: #
3: # Copyright (c) 2020 Ingo Schwarze <schwarze@openbsd.org>
4: #
5: # Permission to use, copy, modify, and distribute this software for any
6: # purpose with or without fee is hereby granted, provided that the above
7: # copyright notice and this permission notice appear in all copies.
8: #
9: # THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
10: # WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
11: # MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
12: # ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
13: # WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
14: # ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
15: # OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
16:
17: pta - the plain text accounting program
18: ---------------------------------------
19: The Plain Text Accounting program reads bookkeeping journals and
20: writes account lists, balances, and cost center assessments to
21: standard output. All input files are ascii(7) text files.
22:
23: Design goals
24: ------------
25: * Get all input from ASCII text files with Unix line endings and
26: using strings of one or more space characters as field separators.
27: Such files are easy to read and edit for human beings
28: and easy to diff(1). For now, UTF-8 is out of scope.
29:
30: * Produce all output as ASCII text on standard output.
31: Support for roff(7), LaTeX, or HTML output files may or may not
32: be added later.
33:
34: * Optimize the format of the journal to require as little typing
35: as possible, while still keeping it readable.
36:
37: * Always enforce the principle of double-entry accounting.
38:
39: * Always require the user to provide a system of accounts and to
40: strictly stick to it, but avoid any limitations with respect
41: to which accounts can be defined, how they are numbered, and
42: how they are used. Avoid any limitations based on specific
43: accounting systems or on any national or international law.
44: Most commercial accounting systems integrate lots of
1.2 schwarze 45: information about accounting, tax, and social security laws,
1.1 schwarze 46: design their user interface in ways making it likely that
47: even accounting files created by mostly ignorant users will
48: respect all applicable laws, and deliver software updates
49: whenever laws change. The pta program does none of this
50: and will not receive updates when laws change. Adapting
51: account systems and accounting practices to applicable laws
52: is purely the responsibility of the user.
53:
54: * Avoid any limitation on the type of legal subjects supported.
55: In particular, pta is intended to be usable for private finances,
56: for freelancers, for non-profit associations, and for small
57: commercial companies.
58:
59: * Support both cost centers and subaccounts.
60:
61: * Support basic performance tracking of long-term financial
62: investments. There are no plans to provide features that would
63: only be useful to support short-term, speculative, or high-risk
64: investments.
65:
66: * Keep program code and documentation well separated.
67: Mixing both in the same files is an abomination.
68:
69: * Minimize the use of external Perl modules. This keeps the code
70: simple and self-contained.
71:
72: * Strictly avoid the use of CPAN and of any kind of Perl build
73: systems features. All those features and frameworks suffer from
74: unbearable overengineering.
75:
76: * For now, avoid use of Perl object orientation and modularization.
77: The tasks to be solved are not complicated enough to warrant
78: the complexity that object orientation or modularization
79: would introduce.
80:
81: * Keep the code as small, as straightforward, and as simple as possible.
82: Avoid abstraction as much as possible. Software reusability as
83: a goal is massively overrated in most contexts and rarely
1.3 ! schwarze 84: justifies additional abstraction or complexity.
1.1 schwarze 85:
86: * Support journals and standard output using the English and German
87: languages, and more languages that can be written in the ASCII
88: character set as far as there is demand, but avoid developing
89: any kind of internationalization framework. In particular, avoid
90: configuration options of low importance like for date and number
91: formats or for character sets.
92:
93: * Do not require nor support any graphical user interface.
94:
95: * Never use any environment variables. Those are notorious for
96: causing unpleasant surprises.
97:
98: * Support as few command line options as possible, and keep them
99: as simple as possible.
100:
101: Installation
102: ------------
103: The pta program can be used without installing it. To use it, just
104: create a new directory, change into it, create a file ./accounts.txt
105: and a file ./journal.txt, then run pta.pl providing an absolute or
106: relative path to the program. Putting your files accounts.txt and
107: journal.txt into the pta source directory is possible but discouraged;
108: keep your data separate from the program if possible.
109:
110: Even if installation is desired, no "configure" script nor any "make"
111: step is needed. Simply change to the pta source directory, read the
112: Makefile to see what it does, then run a command similar to
113:
114: # make DESTDIR=/usr/local install
115:
116: Contact address
117: ---------------
118: Please send patches, bug report, suggestions, and questions
119: directly to the author, Ingo Schwarze <schwarze@openbsd.org>.
CVSweb