Based on the gnucash accountant software this commandline tool extends the possibilities of tracking the use of money.
Find a file
2022-11-28 15:37:17 +01:00
.vscode Codium plugin for sphinx got a new name 2022-11-28 14:42:04 +01:00
docs remove delay stuff 2020-12-13 17:13:20 +00:00
src document constant and introduce key for source 2022-11-28 15:37:17 +01:00
tests add test for error: none in description 2020-12-20 18:26:56 +00:00
.gitignore remove idea ide files 2022-11-28 14:41:35 +01:00
.pylintrc pylint config: ignore formatting advice with % for logging 2020-08-23 17:25:09 +00:00
environment.yml introduce test coverage calculation 2020-12-09 13:36:29 +00:00
LICENSE Initial commit 2020-03-20 16:49:37 +01:00
pytest.ini ignore depraction warning coming from piecash 2020-07-23 19:22:45 +02:00
README.md remove delay stuff 2020-12-13 17:13:20 +00:00
setup.cfg create setup 2020-07-07 09:27:10 +02:00
setup.py pep8 2021-12-29 18:37:10 +01:00

moneyusage

Based on the gnucash accountant software this commandline tool extends the possibilities of tracking the use of money.

Existing solutions

For my personal tracking of money I spend I use a spreadsheet. It is kind of OK but I cannot do serious evaluation based on that. The easy possibilies are quite limited. For example an yearly evaluation I have never done. The monthly overviews are bad since expenses that are used in other months are in there. Categorisations cannot be detailed.

GnuCash is more professional and would probably enable better evaluations. I would still want a commandline interface to create templates which is work.

Both solutions have one shortcoming: the usage of money is always assumed at the day of paying the stuff. But that is a very bad model of actual consumption: rent is used every day but only paid once a month. A holiday is one week long, maybe months in the future but paid now. A house is insulated with several tens of thousands of euros, so it is a very costly year but actually the use is spread over the following maybe 50 years. Gas is paid the same every month but in the winter you use much more of it. How much you know by regularly looking at your gas meter.

New idea for this project

This wrapper around gnucash should cure this shortcoming, allowing both accounting of payments and accounting of usage to get proper statistics. Using gnucash as a base gives a GUI both for developing as well as for additional usage of the same data. It also should make useful shortcuts and a quick-to-use command-line interface possible, creatable with hopefully easy python interfaces.

Double accounting

My understanding of double accounting (doppelte Buchführung) as in gnucash: every transaction has a date and a list of accounts (mostly two, but can be more) for which the transaction adds or subtracts money. The sum for all accounts for one transaction must be zero.

The idea is that one of the accounts is your bank account. It gets lower when you buy a toaster by 20€. At the same time your account „household“ gets higher by 20€ since you spent 20€ on household stuff.

This double accounting is useful to model both amounts of money that you have (bank accounts, cash, credits to and from other people) and categorisation (mobility, food, household, income, presents, donations, ...). My problem is only that the date the transaction has usually reflects well the date when my cash gets decreased but poorly when I actually use the benefit of my spending („use“ of the money).

Implementation in terms of double accounting

The solution can be achieved within the system of double accounting: one transaction moves money from the account „bank account“ to an intermediate account „tmp-vacation“ at the date of paying and 10 more transactions move each a tenth of the money from „tmp-vacation“ to „vacation“ at the 10 days when I do my vacation months later. I started to implement this but it creates such a huge amount of transactions that the file grew far too quickly (in the magnitude of 10 MB for about 100 transactions) and reading from it also was slow.

Implementation with time spans

Instead I use a different data model: each split in a transaction can have a time span, implemented in the module time_span. This could be a list of days or a period with begin and end. This time span is saved as a slot in the gnucash file. I have not found a way to display it in the GnuCash gui and processing the entire file for an overview diagram still takes a lot of time but at least the file size does not increase so quickly.

Detail ideas

  • Aggregation of buying things: not only using money but also spending money is spread over several transactions
    • Example: for building a house you need to pay a lot of individual things. Their usage is not independant but one big block, then distributed over 50 years. So it would make sense to collect all these payments and be able to change their use all at once: e.g. let it start as soon as the house in use.

Code

Usage

Environment

To create a python environment with the necessary dependencies, install conda and run conda env create. It uses the configuration of the file environment.yml. Then run conda activate moneyusage to activate the new environment. Since the current piecash version does not always work with the current GnuCash version, I probably have to adjust piecash to the installed GnuCash version (4.0) if they don't fit. The issue can be temporarily "solved" by removing the version check.

To run the tests, you need to "install" this project into the current environment. This is done via pip install --editable . in the environment file. Otherwise the source is not in the pythonpath and the tests cannot import it. It uses the setup.py with the setup.cfg config.

Tests and Test coverage

The tests are run with pytest in the main directory. Test coverage can be calculated with the coverage module: coverage run --source=src -m pytest and shown with coverage report or coverage html afterwards.

Documentation

To create the documentation go to the docs directory: cd docs and run make html. Then under docs/_build/html/index.html you can view the created documentation.