Hi Derek,
I think I mentioned in my original mail that I am using CVS from 12282002 (looking back I actually did say so, but it was quite well hidden far down in the message, sorry about that).Hi. I'm finally back from vacation so I can take a look at this.First question: what version of Gnucash are you using? Everything I am about to talk about is in current CVS (and some are in later 1.7 series releases)....
Nope, not yet at least ;-) Danes are somewhat reticent people (actually, I think they just did not want to get lumped in with europeans in general, but I have heard that now the Euro seems to be stabilizing nicely they want to get in ;-).Disclaimer: I have accounts (as in bank, expense, income) in threeNo, it shouldn't matter that you're not using USD...
different currencies, none of which are US dollars (which might be
important for a couple of observations that I'll make). My typical use
of these account relates to infrequent transfers between bank accounts
of different currencies and expenses and income payed out from/into
account of the same currency).
1) When specifying a transfer between two differently "currencied"Question: is DKK a Euroland currency? Based on your usage here I
accounts using the "To amount" mechanism I expected that it would be
possible to go back and adjust one of the the sides independently of
the other. An example would be that I make a transfer of 10 Euro from
a euro account to a DKK account. In transfer dialog I specify 10 EUR
going out and in the "To Amount" field I specify 75 DKK (which most
often will be based on a guess, albeit a qualified one) coming
in. When my account statement show up later for the danish account, it
would presume not. Sorry, I don't know which currencies are euroland
and which are not....
Now, this is exactly what I assumed gnucash was doing. However, my point is exactly that when the user specifies the transaction using the "To amount" method, he is really saying that it is not the exchange rate but the exact amount that matters. So when gnucash makes a "translation" of an amount relation to an exchange rate and then uses that for all subsequent recalculations, my opinion is that the spirit of the "To amount" method is violated.shows that actually my account has been credited with 70 DKK (they didNo, that's not how it works. When you create a transaction it
not offer the normal interbank rate, they stole some money, the
transaction cost money, I had bad information, whatever). Now, I need
to adjust the DKK account to reflect this, and simply change the 75 to
70. However, gnucash at this point also changes the amount that I have
taken out of the EUR account to say 9 EUR instead of 10. But in my
opinion this is wrong. If I understand correctly the transaction has
been remembered by a calculated exchange rate instead of by the actual
amounts. So one way of looking at this could be that transfers made
with "To amount" should be tagged as such and not recalculated when
amounts change on either side of the transfer.
determines the transaction currency (based on your default currency or
the currency of the account), and then for each split it stores the
split's amount (which is denoted in the split's account's
commodity/currency) and the split's value (which is denoted in the
transaction currency). The exchange rate is the ratio between the
amount and the value.
When you view an account, all amounts are shown in that account's
currency. So, when you open your EUR account, all amounts are
converted to EUR. When you view your DKK account, all amounts are
converted to DKK. When you edit the amounts, it re-converts back as
if all splits are in that currency; the amount-to-value ratio remains
the same through all edits.
What you want to do is "Edit Exchange Rate". Select the transaction
you need to change and then click on Actions -> Edit Exchange Rate.
Then change the exchange rate to what you need it to be. This will do
what you want to do -- change the ratio between the "amount" and the
"value".
I.e. when the user has specified the transaction using an exchange rate I find it perfectly reasonable that a change of either side of the transaction results in a change of the other, but when the "To amount" method is used I would prefer that the side that is changed changes, but leaves the other side unchanged. (I understand this might give interesting problems when the transaction has multiple splits, but it does not seem impossible to make it work as well e.g by simply leaving all the other amounts remain fixed (which would correspond to what I intend anyway)).
In synthesis, if the "To Amount" method is used to specify a currency transfer, a change of either side of the transaction should simply change _that_ amount and nothing else. No need for manually opening dialogs etc.
I have found that dialog in the meantime, and I understand that I can do this. However, it does not really change my opinion about how this thing should work. But we can agree to disagree on this point !!The only alternative method I can see to get my transaction right is
that I completely delete it when the statement arrives and then
reinsert it with the correct numbers (which is what I do for now).
You could do that, but you don't need to. Just use the Edit Exchange Rate function to change it in-place.
I did not get a transaction dialog as you describe, but then I was probably getting a quickfill result as it was a repeated operation. However, I think this is still unfortunate. In my opinion, when a transaction is performed between two accounts with different currencies, I think the transaction dialog should be opened unconditionally (but this might be a result of my usage pattern, so perhaps a user preference could be made for this).2) When making a transfer between two differently currencied accounts
from the ledger gnucash apparently automatically finds some old
exchange rate (probably from the pricedb, even though the price editor
it empty (but then I might have misunderstood the use of the price
editor)). IMHO it should at least be possible to configure a
preference that a) automatically brings up the transfer dialog
identical to the toolbar transfer button when making a transfer
between two accounts with different currencies or b) do as it does now
(even though I'm not really sure how it works, but it does not matter
too much for me as I probably would use the other method anyway).
I don't think I understand what you mean here. When you are in the ledger and enter a txn between accounts of different currencies, it should pop up the exchange-rate editor (which looks a lot like the transfer dialog) for you to edit the exchange rate.
Note that it is possible that what is confusing you is the register'sBecause exchange rates changes frequently ;-) Quickfill is just a convenience, not an accounting principle (not that I would recognize an accounting principle if it jumped up and bit me).
quickfill system. If that is what is happening, then yes, it will
automatically re-use the previous exchange rate (filled in from the
previous transaction) and you will have to manually change it.
This may be considered a bug, but then again it may not. If you are
using the auto-completion to duplicate a transaction why should
gnucash assume the exchange rate is different?
If you looked at these problems, you would probably understand that my assertion about US$ above made a minimum of sense ;-) However, what this basically boils down to is a bunch of problems with using locales for determining report currencies (I think there should at least be a user overrideable preference (I think locales might have some use, but apart from changing menu languages, formatting dates etc I can't really think of any now)), some reports are incomprehensible due to poor graphics and layout, and many of the report "page links" gives a "Badly formed options URL: report-idXXX" (which I think are real bugs).3) Reports:[snip -- I'll leave this for another person/day]
In addition, I think the work flow of setting up some of the reports is simply wrong (see another earlier mail in this thread for more on that, the use of the toolbar Options button as an integrated part is particularly
Finally, there are a lot of unfortunately named menu points, options, page links etc (labels must be short, but also discriminating and informative, whereas many of the report labels are bland, forgettable or downright misleading). Disclaimer: I am not a usability expert although I have spent some time on the subject, and have some practical knowledge of the issue from dealing with our own clients ;-)
I don't have any business transactions in my data (for now I am only using gnucash for my personal income and expense accounting).I have not been able to test the business reports !!!!
Any particular reason? Or just lack of time?
All the best and happy new year
Jan
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
