Derek Atkins wrote: > > Quoting Mike Alexander <[EMAIL PROTECTED]>: > > > I attached a new patch to 131623. As I said in the comments on the > > attachment, it also includes an option to turn off computation of > > unrealized gains entirely. This is needed with the changes to use > > commodity trading accounts since those accounts record unrealized gains > > and the balance sheet report shouldn't compute them if trading accounts > > are being used. Having the option in without trading account support > > may be a bit confusing but shouldn't hurt anything and this way I know > > the patch works. > > I'm really not sure I agree with the concept of trading accounts. > I think it just confuses the issue even more. How about "hidden" > equivalences? Instead of balancing it in a Split, per se, we balance > it in a KVP? That way: > > 1) it's not visible > 2) you always know which pseudo-split is the auto-balance split > 3) you dont add additional accounts > 4) did I say "it's not visible" yet? > 5) it doesn't add additional splits to the transaction that could just > confuse the user. > > I really think "trading accounts" is the WRONG approach for this problem.
I don't see it as a moral issue; I think it is a question of user preference. As Mike already pointed out, nobody has to use these accounts unless they want to. However, I think there is evidence that properly working trading accounts would be useful to a number of users (I have already heard from several of them). Such users make more than casual use of foreign currencies and would like their currency support to be transparent (i.e., visible and verifiable). This includes small business users such as myself, who need this feature for tax purposes. Your argument is a bit akin to arguing that double-entry accounting is confusing to users and should be hidden away from the user, with the software pretending to do single-entry accounting (and doing the double-entry stuff automatically in the background, or worse, in the report system). This works only for very simple applications. Essentially Gnucash currently uses double-entry accounting for single-currency stuff, but a glorified version of single-entry accounting for multi-currency stuff. This may be adequate for many users, but it is a definite limitation for others. The feature that Mike is implementing is non-disruptive: it simply allows users, at their choice, to "turn on" double-entry accounting for multiple currencies, and provides some (optional) UI support for editing multi-currency transactions. -- Peter _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel