Really interested in when computer scientists are loaned, what form of interest is paid out on them =)
---
31–40 of 51 posts
Really interested in when computer scientists are loaned, what form of interest is paid out on them =)
---
https://en.wikipedia.org/wiki/Resources%2C_Events%2C_Agents
Quote: The REA model gets rid of many accounting objects that are not necessary in the computer age. Most visible of these are debits and credits—double-entry bookkeeping disappears in an REA system. Many general ledger accounts also disappear, at least as persistent objects; e.g., accounts receivable or accounts payable. The computer can generate these accounts in real time using source document records. REA treats the accounting system as a virtual representation of the actual business. In other words, it creates computer objects that directly represent real-world-business objects. In computer science terms, REA is an ontology.
Traditional accounting models are too anemic to account for most resource flows, REA is proper accounting for computer scientists: https://en.wikipedia.org/wiki/Resources%2C_Events%2C_Agents Quote: The REA model gets rid of many accounting objects that are not necessary in the computer age. Most visible of these are debits and credits—double-entry bookkeeping disappears in an REA system. Many general ledger accounts…
So, debit and credits.
The Wikipedia article does little to really explain how it works. How, for example, does a bank contemplating making a loan to the business evaluate its profitability and cash flow, or the liquidity of its assets? (After all, most bankruptcies are not because the business has negative net worth, but because it hasn't enough liquid assets to cover operational expenses).
Traditional accounting models are too anemic to account for most resource flows, REA is proper accounting for computer scientists: https://en.wikipedia.org/wiki/Resources%2C_Events%2C_Agents Quote: The REA model gets rid of many accounting objects that are not necessary in the computer age. Most visible of these are debits and credits—double-entry bookkeeping disappears in an REA system. Many general ledger accounts…
>At the heart of each REA model there is usually a pair of events, linked by an exchange relationship, typically referred to as the "duality" relation. One of these events usually represents a resource being given away or lost, while the other represents a resource being received or gained. So, debit and credits. The Wikipedia article does little to really explain how it works. How, for example, does a bank contempla…
Debits and credits can be seen as a type of resource flow in REA, but not all resource flows are debits and credits. A debit-credit architecture does not require linking resource flows with their duals, and those that do are likely a limited type of REA system. This loses important information.
Assessing value need not be any different in most cases. The point behind REA is not to change established methods of evaluating such questions for domain experts, but to show how traditional accounting abstractions are not core information abstractions and so shouldn't be modelled directly in computers, but should be derived views of a more general architecture.
I'm eternally interested in learning more about accounting, but I think this is missing crucial information to actually explain what "accounting" is while laying on this patronizing anti-intellectual "accountants use hard words" writing style. 1. What are you trying to solve by "doing accounting"? After reading this article, it seems like it's some sort of arbitrary aesthetic, like people who think the point of organ…
I'll try to answer some of your questions, but I'm not an accountant. 1. You're trying to understand the money coming in and going out of a business. The organization of this information can make certain events more apparent, like whether you're actually making or losing money (this is not necessarily obvious!) how much 'runway' a company has, roughly how valuable it is (a bit nebulous because a lot more goes into it…
The point I want to make is that all the things described in the article should be described in terms of their relation to the problems being solved. Because the article failed to establish this connection you can say "a spreadsheet conveys the data better than a graph", or vice versa, and there's no way to decide whether that's true or not.
For instance, being able to answer the following questions:
- Do I have enough money to continue operating?
- Are there any unexpected losses?
- If there are unexpected losses, where are they?
- Are there unexpected gains? And where are they?
- If I want to spend more, how much can I safely spend?
- How are accounts likely to change in the future, and can the above questions be answered then?
Maybe there are others. Questions an exec, or a spouse, or the tax office might ask. The goal needs to have that level of specificity. When an accountant "balances the books" it's not an arbitrary exercise, it's trying to answer one of those questions above.
For the record, I absolutely want an accounting for computer scientists guide. I'm not exactly interested in wrestling with and mapping the concepts myself, at least with the free time I have right now.
The fundamentals of accounting (in particular double-entry bookkeeping) are simple, but they're often presented or understood as a series of unconnected facts that must be memorized. It doesn't have to be this way! Start with this identity: Equity = Assets - Liabilities This is self-evident: the owners of the company have a claim on the company's assets, but only after any liabilities (like debts to other companies)…
A. Equity = Assets - Liabilities
B. Test time! Here's something we've never talked about before: try to guess which side it goes on!
I learnt all of this by using ledger[0] and, of course, reading its manual. I've been maintaining my own accounts for more than a decade now. It's fun being able to plot my overall wealth and expenses over time. [0] https://ledger-cli.org/
...the gist is "ledger.exe" (crufty-old-C-program) is the "perl" of plain-text-accounting. The implementation _is_ the specification.
"HLedger" (haskell) is the mostly-compatible ("now you have 15 standards!") which cleans up a bit of the crufty accidents and is considered more "pure" and "correct".
Mess with it for funsies, and consider using `hledger-ui` for browsing. It's really really powerful!
Specifically this part is super cool: https://ledger-cli.org/doc/ledger3.html#Commodities-and-Curr...
...and: https://ledger-cli.org/doc/ledger3.html#Currency-and-Commodi...
Implied exchange rates, arbitrary commodities/inventory. It gets into really heady territory pretty quick.
The fundamentals of accounting (in particular double-entry bookkeeping) are simple, but they're often presented or understood as a series of unconnected facts that must be memorized. It doesn't have to be this way! Start with this identity: Equity = Assets - Liabilities This is self-evident: the owners of the company have a claim on the company's assets, but only after any liabilities (like debts to other companies)…
In my high school in South Africa, we were made to take accounting for a time. The entirety of what I remember of the experience can be summed up thusly: A. Equity = Assets - Liabilities B. Test time! Here's something we've never talked about before: try to guess which side it goes on!
Accountants use jargon in the same way that programmers do - to succinctly express commonly known and understood concepts. They do not use 'hard words'; if the words are 'hard' it's because the reader lacks the domain knowledge that accountants have been trained in. The fact is that double-entry bookkeeping does not use negative numbers. Where confusion might arise is in the meaning of 'debit' and 'credit'. 'Debit' o…
'Debit' only means 'the left hand side', and 'credit' only means 'the right hand side'.
Not only, and not even! The terms debit and credit have meaning independent of their columnar position on a traditional ledger. I could create a ledger with the columns reverse or (shocking!) use a computer program with a data structure that doesn't encode the concept of left or right.I think about it like this:
CR / Credit / Creditors -> what the business owes
DR / Debit / Debtors -> what the business owns
https://www.encona.com/posts/debits-and-credits> Even “Bookkeeping for Dummies” makes my head spin. Surely this stuff can’t be that difficult? Is this an artifact of accounting itself? Or of the country in which you live? In my country, accounting is… well still not easy but at least I would say it is accessible to most. Meanwhile my impression of the US tax system for example (not my country!), is that it is a very complicated system with grave consequences for…
Not really. The grave consequences tend to be doled out to people who're obviously trying to cheat the system. For most people, it's just "you owe X. Please pay X." If you take a long time to pay X then there might be penalties added.
I remember that years after my wife shut down a business, we got a very nasty letter from the IRS about all the things they could do: sue, garnish wages, confiscating the house, jail terms, etc. But it all boiled down to "you owe $75 from 3 years ago. Pay it ASAP."
One interesting thing my "tax guy" pointed out is that the IRS is pretty lenient on businesses in their first year because they expect you to make a lot of mistakes in accounting or filing taxes.