2 ms·

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).

by 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.

by wruza 5y ago

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.