21–30 of 40 posts
I didn't get the date as text and the amount as real in table transactions.
This confirms what I’ve heard repeated before: it’s easier to teach programming to an accountant than accounting to a programmer.
This claims 1 and -1 is confusing, then proceeds to use the confusion. Why not use the language of the problem domain? The rules are unambiguous. An increase in assets are a DR, increase in liabilities a CR, in income a CR, in expenses a DR, in owners equity a CR. Decreases the opposite. Using 1 and -1 is nonsensical because their meaning in mathematics is fixed, while as shown by the rules above, in accounting DR/CR…
Then you get to corrective transactions, where a normal return is Sales DR 100 Bank CR 100 while an annulled sales invoice is Sales CR -100 Bank DR -100 The point of using debit/credit vs +/- is just that, the ability to have correct account turnovers with corrections, and maybe some conventional understanding of what's an expense account in debit and what's a vendor account in credit.
Earlier quoted context omitted.
I think where this would get confusing is that a positive number would have to decrease some accounts, but increase others, right?
It does not because if you use + and - liabilities are negative and assets positive and if you add all balances the sum is zero. Actually the commercial accounting software I use works like that, it uses negative balances for liability accounts.
I think the transactions table is misnamed. This is a table of posting legs. Which all must balance for a single transaction. I don't think you should get hung up on +ve-ve versus cr and Dr. When double entry was formalised negative numbers were not common and then thought errant. It is only in the eighteenth century it became normal. I enjoyed the entry. Note that you might you use different minimum fractions eg we…
How many legs are there in a transaction?
[0]: https://egrove.olemiss.edu/aah_journal/vol13/iss2/12/
Edit: I should add that CR and DR at one point in time were related to creditor and debitor. I referenced that article, because it's the journey of the author to find an answer that I enjoyed about it.
This claims 1 and -1 is confusing, then proceeds to use the confusion. Why not use the language of the problem domain? The rules are unambiguous. An increase in assets are a DR, increase in liabilities a CR, in income a CR, in expenses a DR, in owners equity a CR. Decreases the opposite. Using 1 and -1 is nonsensical because their meaning in mathematics is fixed, while as shown by the rules above, in accounting DR/CR…
Feels more as a way to introduce a product (scratch data), rather than a technical article. If you have only one entity to manage accounts for - why would you need to build an accounting engine? In other case, when you manage accounts for multiple entities, such as different "clients" or "branches" - you have millions of transactions, and a query such as "get accounts for this client" will take a long time - and you…
- I believe this is a good application of columnar stores (ie, Clickhouse) rather than traditional Postgres, where handling 1M transactions is really fast.
- You might still choose to use materialized views! This article is a suggestion for a table structure that powers those views.
I think the transactions table is misnamed. This is a table of posting legs. Which all must balance for a single transaction. I don't think you should get hung up on +ve-ve versus cr and Dr. When double entry was formalised negative numbers were not common and then thought errant. It is only in the eighteenth century it became normal. I enjoyed the entry. Note that you might you use different minimum fractions eg we…
I think a lot of people are glossing over the fact that you not only need 1/-1 for DR/CR, but also the "normal" balance of the account to tabulate balances.