After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 106873 - Transaction currency in general ledger
Transaction currency in general ledger
Status: RESOLVED INCOMPLETE
Product: GnuCash
Classification: Other
Component: Register
2.0.x
Other other
: Normal minor
: ---
Assigned To: Derek Atkins
Derek Atkins
Depends on:
Blocks:
 
 
Reported: 2003-02-23 18:44 UTC by Paolo Benvenuto
Modified: 2018-06-29 20:29 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Paolo Benvenuto 2003-02-23 18:44:11 UTC
I open gnucash with the --nofile option.

My default currency is USD.

I want to enter a transaction from a LIT account to a DOP account, and I'm
going to create the two accounts "on the fly" while I'm entering the
transaction.

I goes to the general ledger windos. No transaction entered. No account
defined.

I begin entering the transaction in the general ledger window. After
putting the description, I define "on the fly" the first account with
currency of LIT. Then I enter the amount.

GnuCash doesn't permit me going out of the first split without defining the
exchange rate.

However, the transfer funds dialog assumes that I'm, trasferring from a USD
account to an ITL account. I deduce that gnucash put the transaction's
balancing currency to USD.

At this time I haven't any possibility to continue entering the transaction
in which my money went to a DOP account.

It seems more logic to put the balancing currency to the currency of the
account I have put in the first split of the transaction. That would be the
only way to permit me enter the transaction I planned.
Comment 1 Paolo Benvenuto 2003-02-23 18:51:51 UTC
Besides that, the amount I entered after defining the LIT account, say
for example 1,000 (I intend to enter 1,000 LIT), is instead 1,000 USD!!!!

And gnucash didn't tell me that in any moment!
Comment 2 Christian Stimming 2003-02-24 08:35:39 UTC
How did you expect gnucash to work here? You wanted a transfer from a
ITL account to DOP account, but wanted to create these accounts on the
fly? Of course any on-the-fly created account will always have your
default currency, which is USD here as you said. If you want a
transfer in different currencies, you *have* to create those accounts
with non-default currencies *first*, and only after that the
transactions will work.

However, the choice of the "transaction currency" for transactions in
the general ledger might be a different question. The problem here is:
How should Gnucash know which one is the "from-account" (and thus
should determine the transaction currency)? The one you entered first?
I think that's the same problem as above: If you want to *enter* a
transaction that is going to deal with non-default currencies, it
might not be possible to enter those from the General Ledger. 
Comment 3 Paolo Benvenuto 2003-02-24 17:32:54 UTC
The accounts I create on the fly have the currency I put in them: in
the case I were describing, the first account I create on the fly were
a ITL account.

Unfortunatly, gnucash doesn't understand it and when I put the money
value, it interprets it as a USD value!!!! this for me is a serious bug.

I think that the most logic think gnucash can do is, as proposed, to
assign as transaction currency the currency of the first account. This
way the transaction could be entered without problems.


Anyway, I verified that the problem I reported happens in the same
manner if I create my foreign accounts before and not on the fly: the
transaction currency is still USD.

I think that there must be a way in the general ledger to create a
transaction whose currency is different from USD.
Comment 4 Derek Atkins 2003-02-24 17:37:59 UTC
> I think that there must be a way in the general ledger to create a
> transaction whose currency is different from USD.

There is.  Set your locale to the currency you want your GL
transactions in.

For the record, I left this bug open because I do plan to look into
the possibility of using the first split/account to set the Txn
Currency in the GL.  But this is unlikely to be changed anytime soon.

The real fix is to NOT USE the GL for general transaction entry.



        
Comment 5 Christian Stimming 2005-11-11 10:35:30 UTC
Maybe related to bug#116353 as well.
Comment 6 Derek Atkins 2006-02-12 20:05:56 UTC
It's possible that we could use the patch from bug #143720 to fix this problem.
Comment 7 Christian Stimming 2006-08-04 09:09:59 UTC
Does this issue also occur in the 2.0.x versions? Development on 1.8.x has stopped, so please upgrade to 2.0.x (most current is 2.0.1) and see whether this problem still occurs.
Comment 8 Derek Atkins 2006-08-04 13:27:04 UTC
I'm pretty sure this is still an issue, but I haven't tested it.
Comment 9 Paolo Benvenuto 2006-08-04 17:33:09 UTC
Now I have the following:
- my locale is es_DO => gnucash would use currency DOP
- I set the preferences to use currency USD instead

However, when entering the 1st txn the way I explain in the beginning of the bug, the txn I'm defining on the fly uses default currency DOP and not USD.

That is worst than expected, because we would think the txn should have at least the preferred currency, while it has the locale one, without any way to change it.

I think the correct behaviour should be to set the txn currency at the currency of the 1st account entered, either created on the fly or selected from existing accounts.

So the bug is still there.
Comment 10 Frank H. Ellenberger 2008-08-20 14:58:59 UTC
(In reply to comment #4)
> There is.  Set your locale to the currency you want your GL
> transactions in.

As shown in bug 548678, I think, it should read Edit->Preferences->Accounts->"Default Currency" instead of the "locale" currency, which is derived from LANG=.
Comment 11 Christian Stimming 2011-02-08 15:15:08 UTC
Still a problem in 2.4.x?
Comment 12 Christian Stimming 2011-02-28 10:48:49 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!
Comment 13 John Ralls 2018-06-29 20:29:12 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=106873. Please update any external references or bookmarks.