Contributed by Paul 'WEiRD' de Weerd on from the parents and teachers dept.
Ingo (schwarze@) writes in about a side project he's been working on to do his own accounting:
Sometimes, it happens to me that i make little progress with the work i planned to do (so let's not talk about the badly needed mandoc release today) and instead end up doing work that wasn't planned at all.
Recently, i got annoyed because i still didn't have a free accounting program that was to my liking. So i looked through the OpenBSD ports tree and briefly evaluated the programs i found there. None of them convinced me. Many seemed to have awkward user interfaces, some even require a GUI, and i definitely don't want a GUI. While i found every feature i wanted in at least one program, i failed to find any program having all the desired features. Some lack cost centers, some lack subaccounts, some lack support for handling unrealized profits and so on... I'm not absolutely convinced that i did not miss a good one, but at some point, it felt like i was wasting more time evaluting inadequate programs than might be needed to write an adequate one from scratch.
Consequently, i released the plain text accounting program today. Version 0.1 should still be considered experimental, but i'm already using it in production for my own bookkeeping, and a friend of mine is likely to also start using it for their business in 2021, so it is very likely that it will be actively maintained.
For the design goals, see the README file.
At this point, pta supports double entry accounting, configurable account systems, editing of account and journal files with any text editor, syntax checking of journal files, generation of account listings and balance sheets, statistical accounts, cost centers, subaccounts, splitting of journal entries, tracking the performance of financial investments including unrealized profits, and journals and account names in English and German language.
Support for multiple currencies, grouping of accounts and cost centers, nesting of subaccounts, and automated processing of value added tax are still missing in version 0.1.
At this point, it has less than 600 lines of code and more than 800 lines of documentation and 250 lines of examples.
You are welcome to start playing around with it and provide feedback, to improve the chances that i might muster the motivation to finish the most important missing features in time for the financial year 2021.
Thanks to Ingo for the update. If you're interested in a no-frills accounting program, you may want to look at pta!
(Comments are closed)
By Will Backman (bitgeist) bitgeist@yahoo.com on http://bsdtalk.blogspot.com
Works on OSX too thanks to simple dependencies. Ran it against the sample journal and accounts file. Neat!
Comments
By Ingo Schwarze (schwarze) schwarze@openbsd.org on mandoc.bsd.lv
Heh, sure, it's just pure Perl and doesn't even require the latest Perl features. Just for giggles, i tested at opencsw.org on Oracle Solaris 9 (officially SunOS 5.9 sun4u sparc SUNW,SPARC-Enterprise-T5220), which is the most prehistoric system i have access to, and it works just fine. I see no reason why it's shouldn't even work on MS Windows... Though i wouldn't wager my boots that Windows users will be those most impressed by the design goals. :)
schwarze@solaris9 :~/pta-0.1 > perl -v
This is perl, v5.6.1 built for sun4-solaris-64int
(with 54 registered patches, see perl -V for more detail)
Copyright 1987-2001, Larry Wall
[...]
schwarze@solaris9 :~/pta-0.1 > ./pta.pl -n ; echo $?
0
schwarze@solaris9 :~/pta-0.1 > ./pta.pl | wc
158 1063 10076
You can call that portable, i guess.
Comments
By sneaker (sneaker) sneaker@noahpugsley.net on
Ha! Now the race is on to see how many platforms it runs unmodified on! Next stop A/UX! :-)
Thanks Ingo, I will definitely use this. This is the way. This is the OpenBSD way.
Comments
By Ingo Schwarze (schwarze) schwarze@openbsd.org on mdocml.bsd.lv
Uh oh... I never heard about A/UX until today, i think...
Not very surprising though because Apple discontinued it about three years before i first got my hands on a Macintosh computer.
Whether or not pta(1) runs probably depends less on the age of the operating system but more on the age of the Perl interpreter.
By the way, i'm *not* promising that pta(1) will never use modern Perl idioms. Quite to the contrary, when there is a clear benefit - even in soft respects like readability - using modern idioms when writing a new program totally makes sense. It's probably pure luck and certainly not by design that right now, it still runs on Perl 5.6.1. The design goal is simplicity, not compatibility with archaic systems. :-)
By Robert Cameron (rpcameron) rob@rpcameron.net on
Comments
By Ingo Schwarze (schwarze) schwarze@openbsd.org on mdocml.bsd.lv
Ledger is one of the programs i looked at. The aspects of ledger that is disliked include:
1. While this may seem minor to some, a downside that seemed important to me is that it requires at least three lines of text in the journal file for every journal entry, while pta allows a significantly more compact format, with one single line for most journal entries (unless entries are split, which typically only affects a minority of entries, and unless an entry includes different subaccounts on both sides, which is even rarer). I consider it quite important to type less, and to see many journal entries on the screen at the same time.
2. Account naming seems too verbose (requiring a lot of typing) and too inflexible (incorporating the account hierarchy into account names). Account numbers are shorter (less typing), accountants are already used to them (familiarity effect), provide a useful default ordering for free, but without excluding the possibility that accounts can be grouped differently for different configurable reports (the latter admittedly not yet implemented in pta, but certainly planned).
3. All of the following concepts seem to be missing: cost centers, subaccounts, statistical accounts
4. The commodity pricing system feels excessively complicated with too many options, but at the same time, i'm not convinced either of the most important viewpoints can be modelled easily: in the balance sheet, commodities usually need to be listed at the cost price, but that seems to be made harder by ledger's focus on market prices. On the other hand, for tracking performance, not only market price changes matter, but it is crucial to keep interest, dividends, fees, surcharges, and other costs (for example for storage and transport) associated with the security or commodity in question, and i don't see how to easily achieve that.
5. A very minor point: i consider the feature that values can be left out in split journal entries dangerous. Split journal entries are error-prone in the first place, and having the program silently infer one of the amouts makes oversights even easier to miss. Forcing users to explicitly state their intent is more robust and more readable.
Of course, ledger also has several strengths, for example the system of arbitrary commodities seems quite ingenious and simple, except for the overcomplicated pricing system.
Given the very large number of features, the overwhelming variety of syntaxes, and the huge number of rules for logic and calculation, it is quite likely that i missed some possibilities and that some of the issues suspected above can actually be solved. Conversely, i did not inspect all features closely, so i almost certainly missed additional issues. Given how many potential issues there are, and how hard it is to evaluate the program due to the abundance of syntax and features, i judged it unlikely that *all* issues can be solved, and i judged it as probably inefficient to do an exhaustive evaluation.
Comments
By Wolfram (Wolfram) on
Thank you very much for giving your reasoning!
By d.c. (d.c.) on
Seems like a very different approach! It's great to see that one can make a system that simple!
Some possibilities to work with date ranges/periods would be great. Apart of things mentioned (currency conversions - which is a bit tricky, brutto/netto/VAT sanity checks, etc.) I miss "document id" in journal, which is mandatory here and would help to distinguish documents from the mental processes you do as an accountant when entering document into accounts.
Anyway great thanks for coding & sharing!
Comments
By Ingo Schwarze (schwarze) schwarze@openbsd.org on mdocml.bsd.lv
Indeed, support for working with date ranges (i.e. "prepare a P&L report for 2020-07-01 to 2020-09-30" or "show the balance sheet for 2019-12-31") is a great idea, thanks. I shall almost certainly do that. Strange that i did not think about it before...
I'm not sure what a "document ID" is. Is that something like an invoice number or a bank statement number? In that case, the "booking ID" is the column that should be used. I am planning to relax the format restrictions for that column, essentially making it "any string not containing whitespace". Can you explain in more detail what a document ID is and how it would look like? Can i read up on what "here" means and what regulations you are refering to?
Comments
By d.c. (d.c.) on
Hi!
It's not easy to be reasonably swift. :-) Here refers to Czech Republic, EU. Unfortunately we live in a mixture of bureaucracy inherited from Austria-Hungary with a slight scent of tsaris Russia and some new inventions (inspectional VAT reports?).
I had flirted with the idea of writing an accounting tool some years ago, even went through a retraining course for accountants later and found out that accounting was pretty and great, but the tax system and rules were brain-damaged and ugly.
Yes, I meant something like an invoice number or a bank statement number. I didn't see the "booking ID" was for this purpose. If so, I miss another identifier old accountants call "almanac". You have "almanac" of received invoices, or sent invoices or bank accounts.
You sometimes need to make a selection based on almanac (e. g. you are required to have a selection of your debtors at the end of fiscal period, but there should only be debtors of your main business activity, if you lend money to somebody it's other matter).
You sometimes need to find the original document. So you need almanac (where to find it) *and* the inovice no (what to look for). For me usually booking ID is another code (it's the sequence number inside the almanac. But it can be used to see the sequence and the almanac using codes - e. g. II001 would be Incoming Invoice 001).
Tax rules are sometimes really awful. I need not only to enumerate sum on all VAT received minus all VAT paid in a month, but to put aside all invoices over 10000 CZK subject to VAT of a certain level and including Inovice ID and VAT id of the other party. All other inovices in almanac are summed to groups according to VAT level (3 VAT rates here :o)).
I am sorry, I really tried to be swift.