Fastcounting is a python module which helps you to understand your accounting data. Accounting Software is localized and comes with much functionality.
We take a step back and only implement the ground truth. And we make it easy for you to ask your own questions.
The basic use case right now is make queries against our views. Our backend store should allow us to easily introduce new functionality when needed.
Friendly reminder that you will have to do some preprocessing of your data.
install redis server 6
start redis server 6
Get python environment e.g with conda:
- conda create -n pauline
- conda install nb_conda
- git clone https://github.com/elcolumbio/fastcounting.git
- cd fastcounting
- pip install -r requirements.txt
- pip install .
- jupyter lab
- select kernel pauline
We can use conda install -f requirements.txt the moment redis 3.4.2 is released
Standard accounting software is often insufficient for data to analizing. E-Commerce companies typicaly have 100s or 1000s of transactions for each day.
So let's export and save the data in a csv or sql.
The data you export from your accounting software is very misplaced in a 2 dimensional table.
The rows aren't representing atomic transactions and in accounting you have 3 main dimensions.
Here we provide a simple and powerful logic besides tables.
I just made my first very simple dash app on top of our data core and our views.
It has 2-4 times faster query speed, highly customisable and is accessible. All which my accounting Software isn't able to provide.
github repo elcolumbio/cctable
| type | memory used | info |
|---|---|---|
| csv | 2.6 MB | the file we import |
| csv rows | 61 245 rows | ~ number of transactions(multi tax = 1 transaction) |
| number atomic | 181 224 entries | number of atomic transactions |
| accountsystem | 0.16 MB | we join for more meaningful output |
| without views | 108 MB | core db |
| atomic hashes | 181 224 | - |
| general hashes | ~ 65 000 | - |
| sorted sets | 4 with a length of 181 224 | - |
| with views | 186 MB | core db and views |
| same as without views | "" | "" |
| atomic view | 181224 entries | big stream with fields joined |
| account view | 90 with total of 181 224 entries | we distribute data over accounts |
Account is a collection of related accounting entries
Accounting transaction links two or more entries together, so the total of all entries is zero.
Our naming convention for 'entries' is: atomic. And our naming convention for 'accounting transaction' is: general.
We transfer every number to the balance side, where this very account is increasing. That means you don't need to look at the balance side, you will see just by the value. If the account is increasing or decreasing.
To do this we need to categorize all accounts with the help of our standard accounting frame.
E.g. in Germany we have SKR04, there we have 8 main classes 0-7. Only in the 8th and last class we have mixed accounts.
0-1 : active accounts (incr left)
2-3 : passive accounts (incr right)
4 : revenues (incr right)
5-6 : expenditures (incr left)
7 : revenues and expenditures
So we need more information for 7. There is a category column in our accounting frame.
We have only 3 groups for 7. Einnahmen = revenue and Abschreibungen, Betriebsausgaben = expenditures.
Like this we matched all accounts which are part of your final reporting.
underlying dimensions of accounting:
- date
- account
- relations
For now we focused on the first Two.
Backup queries:
- aggregation -> we leverage lua scripts and one dimensional arrays to combine filtering and lookup in lua.
- atomic -> we seperate and make filter easy to use and we have one lookup function: atomics in and details out alternative atomic Most data stays in redis.
View queries: Build on top of our Backend very easy to create and delete and to query against.
- atomic view -> all the data you can filter by date
- account views -> for every account -> a stream you can filter by date too
Batch processing: We have some capabilities in our backend, but we won't implement it for now. We want to have easy remove and rollback logic, useful if you want to do some trial and error analysis. Also to get meaningful Diff Views would be very nice.
From my understanding accounting terms are in the official language for each country. I still have to replace some german and maintain a dictionary.
- Event driven
- data rebuild-able
- simplicity
- fast read
- multi state diffs
- useful queries
- data validation
