--On March 8, 2007 3:56:43 PM -0500 Derek Atkins <[EMAIL PROTECTED]> wrote:
> Quoting Peter Selinger <[EMAIL PROTECTED]>: > > A single transaction by itself is neither a gain nor a loss. It's a > POTENTIAL gain or loss, but not by itself.. I guess that's why I'm > so hesitant to embrace this idea. Here's an example. I'm traveling > abroad and go to an ATM and pull out ?100 out of my US Bank Account. > (later on I find that this ?100 cost me $157.23). That's it. There's > this single transaction. Do I have a ?100 Income? I dont think so. > Do I have a ?100 Expense? I don't think so, either. You didn't say, but suppose for the sake of argument that the foreign currency is the Euro. Also, to simplify talking about this a bit, let's ignore non-currency commodities. They don't complicate the implementation much, but the do complicate the discussion. After that transaction (with the changes we're talking about) you'll have two additional splits in this transaction. One will be a debit to the Currency:EUR account and the other will be a credit to the Currency:USD account. If the exchange rate never changes then the balance in the parent Currency account (converted to either USD or EUR) will be and remain zero. No income, no expense. If the exchange rate changes (and no additional transactions are entered) and you update the price DB accordingly, then the balance in the Currency parent account may be non-zero. Since the child accounts are not all in the same currency at least one will have to be converted into a different currency to get a balance in the parent account and the changed exchange rate affects this conversion. > This is why I think it's Equity. I now have an Equity balance of > ?100. Where did this ?100 come from? Well, it came from the exchange > of $157.23... But it's neither an income nor an expense. At that point the balance in the currency trading accounts (absent exchange rate changes) will be zero. They are still income accounts, however. It's confusing, perhaps, because these accounts represent potential income which is odd. Peter suggested creating a new account type for this purpose separate from the income account type. This doesn't really affect the fundamental problem, but it might make things less confusing. > Now let's say I buy a ?2 candy bar. That's an expense. But what if > I go to my friend and sell that candy bar for $5 (he's REALLY > hungry!). See, this can get infinitely complicated. So let's > constrain the problem. > > Let's say that I take those leftover ?98 and exchange them for > $145.76. I certainly don't have a loss of $11.43 (because I bought > that candy bar). Of course not. This is essentially the same as the Table 4.4 example in Peter's document <http://www.mathstat.dal.ca/~selinger/accounting/gnucash.html>. The GnuCash file for this can be downloaded at <http://www.mathstat.dal.ca/~selinger/accounting/table4.4.xac>. Rather than me trying to explain it all again here, why don't you go take another look at those? Peter did a better job than I can of explaining it. It really does work, and (at least to some of us) it makes a lot of sense. > As soon as you say "trading accounts" this again brings up the > description of the old "Currency" accounts which are what you needed > to do to trade from one currency to another. > > I'll point out that the CoA never balances, either. A - L never > equals your Equity in your accounts (until you include Income and > Expense, but most people don't think about that). Maybe, but the GnuCash documentation says (correctly, I think) that Assets - Liabilities = Equity + (Income - Expenses) Peter used different names for these in his tutorial, but the effect is the same: Assets - Liabilities = Capital + Income - Expenses That's the correct accounting equation, I believe, no matter what people may think, and it would be nice if the GnuCash accounts obeyed it after scrubbing all transactions. > Having the reports do some of the heavy lifting is PERFECTLY > reasonable. Perhaps, but it seems better to me for the accounts to be balanced automatically without having to run a report to see whether they are or not. However, if most people think the current scheme, where the accounts are internally unbalanced, but the balance sheet report adjusts for that is better, then that won't be the end of the world. In this case I would, however, suggest that my patch to make the balance sheet report actually do this should be applied. Right now the balance sheet report does not correctly adjust things. In the meantime, I think I'm going to continue working on this since I still think it shows promise. Even if it turns out to not be useful to others, I may still use it myself. Mike -- Mike Alexander [EMAIL PROTECTED] Ann Arbor, MI PGP key ID: BEA343A6 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
