Questions on the implementation

First of all, thank you for the project, I’m learning a lot from it. I was interested on implementing the same idea on a SQL database, however I had some doubts.

What makes me wonder is if it makes sense to create a collection (table if SQL) for each account. e.g. a collection for Assets:Cash:USD, one for Assets:Cash:EUR and so on. Was this ever considered on this project? what would be the drawbacks? Because as I see having all on medici_transactions tends to make the collection to get large in size too quickly, and that brings the question of whether this would be an issue -mostly performance-wise- when we query this collection or inspect the data.

[koresar]

Now I want to implement Rechnungsabgrenzungsposten.

Thanks. So useful! I’d love to see that info in the md file or something.

[Uzlopak]

Well. I think to realize a good accounting software you actually need to implement some aspects more technically and some aspects closer to the reality and more according to the thing we call in Germany GoB = Grundsätze der ordentlichen Buchhaltung. According to wiki its called accounting standards in English.

E.g. technical aspects is e.g. enforcing to not use floats, always integers. See https://www.youtube.com/watch?v=TQDHGswF67Q for the funny aspects of using floats. Currently generating the balance of an Account is the big complex solution in medici.

The accounting standards makes you think more like an real world accountant. It starts with the what we call in german Kontenplan, which is according to wiki called Chart of accounts in english. What does this mean? You usually dont create your own account chart but you look what the de facto standard of your country is regarding the accounting charts. E.g. in Germany we have a company called Datev, which has a handful pre defined accouting charts, which are basically used by every german company see https://www.datev.de/web/de/m/ueber-datev/datev-im-web/datev-von-a-z/skr-standard-kontenrahmen/ . The reason is simple: If the tax office comes to investigate your accounts, you want them to be out very fast out of your company. If every company uses a similar accounting chart,then they dont have to stay longer because they have to understand your custom accounting plan. With the used account chart, you can actually define beforehand how many T-Tables you actually need. It does not mean that you need a sql table per account, but e.g. in medici you have a depth of up to 3, “Income”, “Income:Rent”, “Income:Rent:Bla”. But if you know that you always have a depth of three and you can not credit or debit into the first or second layer you can reduce some complexity regarding determining the balance of the accounts. So if you currently want to determine the balance of “Income” it will go through all the entries with “Income” as first account_path. But if you know that you can not credit or debit on first and second part of the account, you can persist the balance of each 3-part-account and sum it up. In “normal” accounting you would for determine the balance of a 1-part-account also not start to accumulate over all journal-entries, but accumulate over the 3-part-accounts.

Also the reality gives us a good hint, how to solve the balancing issue. In Accounting you would also actually close the books every year, make Rechnungsabgrenzungsposten (english: accruel) and then open fresh books. So you dont carry old data for ever. So you can actually reduce the data overhead. So a functionality to close books and open fresh books should be imho also implemented. If you login into your banking account, than you also dont want to see the super old transactions. You see the e.g. latest 30 days. If you want to see older data, you can load it from closed books. Maybe the closed books are also on slower memory, as you usually dont need the old stuff that regularly. So what we would maybe call database backup the corresponding process is in accounting the closing of books. And we are not forced to do it every year, but every month or every x days.

I know this answer blowed out of proportion, but I really think, that reading some accounting books and asking an accountant how they actually work, can give good hints how to do it.