Return to README CVS log

Up to [cvsweb.bsd.lv] / pta

fix typos; patch from <Randy at randy7 dot com>

# $Id: README,v 1.3 2020/10/04 13:50:48 schwarze Exp $
# 
# Copyright (c) 2020 Ingo Schwarze <schwarze@openbsd.org>
# 
# Permission to use, copy, modify, and distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
# 
# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

pta - the plain text accounting program
---------------------------------------
The Plain Text Accounting program reads bookkeeping journals and
writes account lists, balances, and cost center assessments to
standard output.  All input files are ascii(7) text files.

Design goals
------------
 * Get all input from ASCII text files with Unix line endings and
   using strings of one or more space characters as field separators.
   Such files are easy to read and edit for human beings
   and easy to diff(1).  For now, UTF-8 is out of scope.

 * Produce all output as ASCII text on standard output.
   Support for roff(7), LaTeX, or HTML output files may or may not
   be added later.

 * Optimize the format of the journal to require as little typing
   as possible, while still keeping it readable.

 * Always enforce the principle of double-entry accounting.

 * Always require the user to provide a system of accounts and to
   strictly stick to it, but avoid any limitations with respect
   to which accounts can be defined, how they are numbered, and
   how they are used.  Avoid any limitations based on specific
   accounting systems or on any national or international law.
   Most commercial accounting systems integrate lots of
   information about accounting, tax, and social security laws,
   design their user interface in ways making it likely that
   even accounting files created by mostly ignorant users will
   respect all applicable laws, and deliver software updates
   whenever laws change.  The pta program does none of this
   and will not receive updates when laws change.  Adapting
   account systems and accounting practices to applicable laws
   is purely the responsibility of the user.

 * Avoid any limitation on the type of legal subjects supported.
   In particular, pta is intended to be usable for private finances,
   for freelancers, for non-profit associations, and for small
   commercial companies.

 * Support both cost centers and subaccounts.

 * Support basic performance tracking of long-term financial
   investments.  There are no plans to provide features that would
   only be useful to support short-term, speculative, or high-risk
   investments.

 * Keep program code and documentation well separated.
   Mixing both in the same files is an abomination.

 * Minimize the use of external Perl modules.  This keeps the code
   simple and self-contained.

 * Strictly avoid the use of CPAN and of any kind of Perl build
   systems features.  All those features and frameworks suffer from
   unbearable overengineering.

 * For now, avoid use of Perl object orientation and modularization.
   The tasks to be solved are not complicated enough to warrant
   the complexity that object orientation or modularization
   would introduce.

 * Keep the code as small, as straightforward, and as simple as possible.
   Avoid abstraction as much as possible.  Software reusability as
   a goal is massively overrated in most contexts and rarely
   justifies additional abstraction or complexity.

 * Support journals and standard output using the English and German
   languages, and more languages that can be written in the ASCII
   character set as far as there is demand, but avoid developing
   any kind of internationalization framework.  In particular, avoid
   configuration options of low importance like for date and number
   formats or for character sets.

 * Do not require nor support any graphical user interface.

 * Never use any environment variables.  Those are notorious for
   causing unpleasant surprises.

 * Support as few command line options as possible, and keep them
   as simple as possible.

Installation
------------
The pta program can be used without installing it.  To use it, just
create a new directory, change into it, create a file ./accounts.txt
and a file ./journal.txt, then run pta.pl providing an absolute or
relative path to the program.  Putting your files accounts.txt and
journal.txt into the pta source directory is possible but discouraged;
keep your data separate from the program if possible.

Even if installation is desired, no "configure" script nor any "make"
step is needed.  Simply change to the pta source directory, read the
Makefile to see what it does, then run a command similar to

   # make DESTDIR=/usr/local install

Contact address
---------------
Please send patches, bug report, suggestions, and questions
directly to the author, Ingo Schwarze <schwarze@openbsd.org>.