3 ms·

> Facts arrive at random times and then are entered on a schedule. Corrections await on someone to resolve analytical issues. Different accounting units have di

> Facts arrive at random times and then are entered on a schedule. Corrections await on someone to resolve analytical issues. Different accounting units have different timelines, and in a unit there is many threads of an unordered fact flow. It is all synced together only at specific points, usually when it’s time to report officially or internally. If you ask your accountant and the only thing they drop is “busy”, it’s one of these weeks of the year. I fail to see how any of this implies the data is mutable.

wruza 5y ago
An accountant loads a raw payment data from a bank. Every payment has to be recognized and related to some analytics (a project, an expense/income class, etc). If it’s not obvious, then corresponding analytics are left empty or “_Unrecognized”, which rings at top of all related reports. Later the info arrives and they simply go to that day and fill in fields. The change history may be useful for data-debug reasons, but the model that a regular accountant uses is of a mutable nature at their level. Of course one could design a system that made changesets append-only and explicit for them. But they would object, the same way you’d object if instead of updating a working tree, `git pull` simply appended a set of patches to every file in it and expected you to modify source code only by appending patches yourself. Developer’s own work model is mutable (a working tree), and you can’t expect an accountant to be surprisingly fine with what you personally are not.
- slt2021 5y ago
  bank is a perfect example of immutable accounting. once debit is posted to your account (let's say it is fraudulent transaction, or transaction entered by mistake), nobody will go and erase it as if it never happened. They would actually do reversal, by creating a new entry with the same amount and opposite sign. So you would env up with two transactions: +100 and -100. same is true for most accounting systems. Once the accounting period is closed (daily in banking system, monthly for most other companies), you can't change the closed month. All changes go as new transaction adjustments
  - wruza 5y ago
    That’s what I’m talking about! You don’t have to go all-immutable, only at the “commit and set in stone” level (you may have many). Obsessing yourself with a completely immutable state management at all levels does more damage to your workflow than the problems it solves. It’s yet another silver bullet that everyone tries to bite these days.

wruza 5y ago

An accountant loads a raw payment data from a bank. Every payment has to be recognized and related to some analytics (a project, an expense/income class, etc). If it’s not obvious, then corresponding analytics are left empty or “_Unrecognized”, which rings at top of all related reports. Later the info arrives and they simply go to that day and fill in fields. The change history may be useful for data-debug reasons, but the model that a regular accountant uses is of a mutable nature at their level. Of course one could design a system that made changesets append-only and explicit for them. But they would object, the same way you’d object if instead of updating a working tree, `git pull` simply appended a set of patches to every file in it and expected you to modify source code only by appending patches yourself. Developer’s own work model is mutable (a working tree), and you can’t expect an accountant to be surprisingly fine with what you personally are not.

slt2021 5y ago
bank is a perfect example of immutable accounting. once debit is posted to your account (let's say it is fraudulent transaction, or transaction entered by mistake), nobody will go and erase it as if it never happened. They would actually do reversal, by creating a new entry with the same amount and opposite sign. So you would env up with two transactions: +100 and -100. same is true for most accounting systems. Once the accounting period is closed (daily in banking system, monthly for most other companies), you can't change the closed month. All changes go as new transaction adjustments
- wruza 5y ago
  That’s what I’m talking about! You don’t have to go all-immutable, only at the “commit and set in stone” level (you may have many). Obsessing yourself with a completely immutable state management at all levels does more damage to your workflow than the problems it solves. It’s yet another silver bullet that everyone tries to bite these days.