On Sun, Mar 04, 2007 at 11:56:20PM -0500, Mike Alexander wrote:
> --On February 22, 2007 4:09:22 AM -0400 Peter Selinger
> <[EMAIL PROTECTED]> wrote:
>
> > I have also written a fairly detailed critique of multi-currency
> > accounting in GnuCash, with some suggestions for how it could be
> > improved. Unlike the tutorial above, this second document is specific
> > to GnuCash, but must be read after the tutorial:
> >
> > http://www.mathstat.dal.ca/~selinger/accounting/gnucash.html
>
> I thought I would let folks know that I've been working on some changes
> similar to the ones suggested on this page. As might be expected, it's
> not as simple as it seems and I don't know if the result will be useful
> or not, although it looks somewhat promising. I thought I'd mention it
> here in case anyone else is thinking about working on this. If so let
> me know so we can compare notes. I'm making all these changes under
> control of a new preference and if it is off GnuCash behaves as before.
> When I get something working I'll submit a patch in case anyone is
> interested in it.
>
Mike, Peter, et al.,
I should have spoken up eariler, but have been pretty busy. I just now
skimmed Peter's reports, and wanted to comment.
First off, Peter's assessment of GnuCash's flaws are fundamentally
correct.
I went through a similar process of research and conclusion about a
year ago, when I started the register-rewrite branch. It turned out
to be a lot more work than I expected, because I hadn't yet realized
_why_ multi-currency didn't work in the existing register. Relative
to GnuCash, my conclusion was that the existing register design is
fundamentally incapable of being used to "do multi-currency"
correctly. This is the cause of many of the very long-standing open
bugs regarding multi-currency support.
So, when figuring out how to make it work correctly, I found that I
had to not only re-implement, but also re-design the register and many
of the functions that ensure balanced transaction entry. The good
news is that I believe that GnuCash's foundational Transaction and
Split data structures can accomodate the "right way".
Mathematically, the contraints and relationships in a multi-currency
transaction are exactly the same as in a "stock" transaction, with
capital gains/losses.
Peter's recommendation that the register show the currency in each
split is essential to any sort of reasonable interface to accurate
transactions.
While the use of full-blown trading accounts has some nice properties,
there are also some smaller changes that would still be an
improvement, even if it still meant calculating exchange gains/losses
at report-time. Those changes would allow someone who wanted to use
trading accounts manually to do so correctly.
Fundamentally, I see this as a UI issue, and I believe that I've
designed the new register in such a way as to support multi-currency
transactions correctly, albeit still with report-time calculation of
gains/losses.
Mike, if you're up for it, I encourage you to take a look at the
register-rewrite, and see if it supports multi-currency transactions
correctly. Even if you're not, I'd be interested to hear more
specifically which improvements you're working on. (BTW, I know you
have outstanding patches filed in BZ that might relate to this
functionality. I feel bad that they've been neglected, but the fact is,
everybody's understandably shy to touch some of that messy code.)
Just a status note about register-rewrite: It should be completely
functional, just not very polished and not yet convenient to use. For
evaluation, I like opening a new register and an old register
side-by-side in adjacent tabs. (You can do this by double-clicking
accounts in a budget, which still opens the old register.)
-chris
> --
> Mike Alexander [EMAIL PROTECTED]
> Ann Arbor, MIPGP key ID: BEA343A6
>
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
