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 736703 - Scheduled transaction are registered without credit/debit amount
Scheduled transaction are registered without credit/debit amount
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Scheduled Transactions
2.6.3
Other Mac OS
: Normal major
: ---
Assigned To: gnucash-core-maint
gnucash-core-maint
: 728999 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-09-15 22:16 UTC by Marc
Modified: 2018-06-29 23:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Marc 2014-09-15 22:16:18 UTC
I have encountered this problem since a few weeks.
There is no money registered in the transaction.
The transaction is also locked and I cannot modify it.
I have to delete it and manually enter the transaction.
Comment 1 John Ralls 2014-09-17 13:46:41 UTC
What are the values of the credit and debit fields for each split in the scheduled transaction, and what exactly happens when you try to edit the faulty transaction?
Comment 2 Marc 2014-09-18 00:30:58 UTC
In one of the faulty transaction I have the amount of 217,45 in both fields.

The faulty transaction has its credit/debit field blank.

When I enter an amount in this field, the amount id shown on the screen, but a cannot click in another transaction. I can click other fields in the faulty transaction but nothing else.

I am locked in this position.

The only thing I can do is to cancel this modification.

Then I can click again in other transaction.
Comment 3 John Ralls 2014-09-18 01:13:27 UTC
Ah, that rings a bell. Was the Scheduled Transaction created in 2.4.x? What locale are you using? Have you over-ridden any of the locale settings with defualts?
Comment 4 Marc 2014-09-18 02:26:59 UTC
What do you mean by local?

Is it local currency?

If so, I use CAD
Comment 5 Marc 2014-09-18 02:32:34 UTC
Or you mean the locale in Mac OS :

LANG="fr_CA.UTF-8"
LC_COLLATE="fr_CA.UTF-8"
LC_CTYPE="fr_CA.UTF-8"
LC_MESSAGES="fr_CA.UTF-8"
LC_MONETARY="fr_CA.UTF-8"
LC_NUMERIC="fr_CA.UTF-8"
LC_TIME="fr_CA.UTF-8"
LC_ALL=
Comment 6 Geert Janssens 2014-09-18 07:49:25 UTC
Just adding this as a possible cause to investigate: how is equality for commodities established ? I'm asking because I wonder if the new code by Frederic Perrin to use symbols instead of mnemonics may indirectly be causing this.
Comment 7 Marc 2014-09-20 20:20:35 UTC
Note that I use MacOS version of GNUCash downloaded from the WEB site.
Comment 8 John Ralls 2014-09-21 21:17:07 UTC
(In reply to comment #7)
> Note that I use MacOS version of GNUCash downloaded from the WEB site.

Yeah, I figured that. The case I was thinking of was de_CH where the separators in the Apple locale file are wrong. That's not the problem here.

I'm able to reproduce the problem, but not in the way that I'd expect that you're seeing it.

If, having changed locales to fr_CA in System Preferences and creating a new file, I create a scheduled transaction with 217,50 for the amount and then run Since Last Run..., everything works as expected.

However if I use a file created in the US locale with the accounts in USD, the newly-created transactions are blank. Creating new accounts with CAD as the currency and accompanying scheduled transactions works for those accounts; if a transaction is mixed so that one split is in a CAD account and the other in a USD account the transaction is OK in the CAD account and has no value in the USD account. Changing the currency of the account to CAD appears to correct the problem.

So go through your accounts and make sure that the currency for all of them are set to CAD.

I'd say that the bug here is that scheduled transactions set the currency as the currently selected global currency instead of determining it based on the account.
Comment 9 John Ralls 2014-09-25 23:59:16 UTC
The problem arises because the default exchange_rate was zero, and the
SX behavior is to take the number from the SX split and assume that it's
the value in the default currency -- which is a global preference
setting, not even a book setting. If the default currency doesn't match
the account commodity, the routine attempts to look up an exchange rate
in the SX's data, though it's not clear how that gets set. It seems
common enough that it isn't, and the exchange rate is left at 0 which
produces a 0 amount. The register doesn't display 0 amounts, so it's left blank.

Changing the default exchange rate to 1 fixes that part of the problem.

It could be argued that the register's failing to display amounts when they're 0 is also a bug, but we depend on that behavior for capital gains transactions.
Comment 10 Marc 2014-09-29 01:48:09 UTC
I have check the accounts and they were all in CAD$.

But, you are right the problem seems to be due to currency exchange.

Even if the account are all in CAD$, when I try to change the rate for one of the transaction in error,
I have the message: Division of amount is zero, then no exchange rate is necessary (translation from french: La division du montant brut est zéro, ainsi auxin taux de change est nécessaire).

When I do the same command for a transaction that is not in error, I have the message Both currencies are equal.

How can I change the default currency exchange?
Comment 11 John Ralls 2014-09-29 02:54:53 UTC
I've fixed it for newly-created transactions from scheduled transactions. You might be able to fix the already-broken ones from a view that isn't tied to a particular account like Find Results or General Ledger; I was able to fix one in a "review created transactions" view.
Comment 12 Marc 2014-09-29 12:05:58 UTC
I did a research for the transactions in error and I find out that in the research view, the transaction are ok!

When I modify the amount (for the same amount), a windows appears to set the currency exchange.

Anyway, I was able to re-enter the amount, each time with the currency conversion windows, and now the transactions are ok.

Thank you for your help.
Comment 13 John Ralls 2014-09-30 19:03:06 UTC
*** Bug 728999 has been marked as a duplicate of this bug. ***
Comment 14 John Ralls 2018-06-29 23:33:47 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=736703. Please update any external references or bookmarks.