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 157179 - Poor handling of multi-currency/fund scheduled txn
Poor handling of multi-currency/fund scheduled txn
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: Scheduled Transactions
unspecified
Other other
: Normal normal
: ---
Assigned To: Josh Sled
Josh Sled
: 105664 339900 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-11-03 01:01 UTC by kevin.hobbs.1
Modified: 2018-07-02 07:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gnucash account file that crashes upon pressing Next on startup (5.29 KB, text/plain)
2006-04-14 23:25 UTC, Scott Engles
Details

Description kevin.hobbs.1 2004-11-03 01:02:07 UTC
Distribution: Fedora Core release 2.91 (FC3 Test 2)
Package: GnuCash
Severity: normal
Version: GNOME2.8.0 unspecified
Gnome-Distributor: Red Hat, Inc
Synopsis: Crash on startup with future scheduled fund purchase
Bugzilla-Product: GnuCash
Bugzilla-Component: Scheduled Transactions
Bugzilla-Version: unspecified
Description:
Description of Problem:
I created a scheduled transaction to automaticly enter my automatic fund
purchases.  I also set up the account to get online price quotes.  I
create all scheduled transactions 90 days ahead of time.  After creating
the schedualed transaction gnucash will start up, but imediatly crash. 

Steps to reproduce the problem:
1. I created the fund account
2. I set it up to use price quotes
3. I set up the scheduled transaction
4. I saved and later restarted

Actual Results:
Gnucash opens windows and then goes away.

Expected Results:
I expected the transactions to be created with the current price which I
coulkd edit later.
Or I expect that a failed transaction entry would give me some option to
fix the proken schedule.

How often does this happen?
1 of 1, and every start now.

Additional Information:

This was on stdout :

gnucash: [D] "files to open: "()
gnucash: [D] "starting up (2)."
gnucash: [D] "gnc:find-file looking for ""finance-quote-check"" in
"("/usr/share/gnucash")
gnucash: [D] "  checking for ""/usr/share/gnucash/finance-quote-check"
gnucash: [D] "found file ""/usr/share/gnucash/finance-quote-check"
gnucash: [D] "gnc:find-file looking for ""finance-quote-helper"" in
"("/usr/share/gnucash")
gnucash: [D] "  checking for ""/usr/share/gnucash/finance-quote-helper"
gnucash: [D] "found file ""/usr/share/gnucash/finance-quote-helper"

This was on stderr :

guppi-text-state.c:guppi_text_state_get_block:338: text changed size
102.406 14.614
guppi-text-state.c:guppi_text_state_get_block:338: text changed size
202.306 14.254
guppi-layout-engine.c:schedule_layout:508: layout scheduled
Error: create_each_transaction_he...(): Common-commodity difference:
old=LAFCX, new=USD

Error: create_each_transaction_he...(): Some error in new transaction
creation...
Error: create_each_transaction_he...(): Common-commodity difference:
old=LAFCX, new=USD

Error: create_each_transaction_he...(): Some error in new transaction
creation...

** ERROR **: file dialog-sxsincelast.c: line 1614 (sxsincelast_init):
assertion failed: (nextPage)
aborting...




------- Bug moved to this database by unknown@bugzilla.gnome.org 2004-11-02 20:02 -------


Unknown platform unknown. Setting to default platform "Other".
Unknown milestone "unknown" in product "GnuCash".
   Setting to default milestone for this product, '---'
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here, unknown@bugzilla.gnome.org.
   Previous reporter was kevin.hobbs.1@ohiou.edu.
Setting to default status "UNCONFIRMED".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.

Comment 1 Derek Atkins 2004-11-04 04:32:21 UTC
Scheduled Transactions do not support stock/mutual fund txns.
Comment 2 Josh Sled 2006-01-17 03:05:42 UTC
No, it doesn't work that way, and the bug you're seeing is something else.  I'm going to just close this out INVALID.
Comment 3 Boris Zbarsky 2006-04-08 04:28:19 UTC
I just ran into this today.  I can understand that setting up scheduled transaction fund purchases is nontrivial, but at the moment GnuCash handles the situation by crashing.  Or rather aborting, when it hits a null nextPage in the wizard code; I can post a gdb stack, but I'm not sure how useful it'd be since it wouldn't show what the Scheme code is doing.

If the issue is that scheduled transactions cannot be made between accounts that are in different commodities, shouldn't that get flagged in the scheduled transaction editor when creating the transaction?

Josh, you marked this bug NEEDINFO.  Is there any more information I can provide to help out here?
Comment 4 kevin.hobbs.1 2006-04-08 14:58:39 UTC
What info would be usefull? I'm now using Fedora Core 5 with gnucash 1.8.12 but I could try to replicate the crash again. 
Comment 5 Josh Sled 2006-04-08 15:45:35 UTC
I don't recall what I meant when I closed this out before.

Boris: There shouldn't be any scheme code involved, here.  Yes, it probably should either work or prevent the situation from occuring.

1.9.x should *not* crash, and it will use the first split in the transaction to determine which exchange rates need to be involved in the created transactions.  As Derek's pointed out, though, if the transactions are being created at file-open, there might not be valid exchange rates in the price db when the SX engine tries to create the transactions.  It's all messy.  In any case, 1.9.x shouldn't crash, so it would be good to know how it behaves for you in this case.  I'd love feedback on how it should work, too, though I'm not sure how much time I'm going to have for this before 2.0.  I'm hoping to more fully resolve multi-commodity SX issues post-2.0, though.

Definitely no 1.8 changes will be made.
Comment 6 Boris Zbarsky 2006-04-10 03:57:50 UTC
Josh, I'll try to figure out a way to install and test 1.9.x in a reasonable way without getting rid of my existing 1.8 installation.  If there's any documentation on that (and in particular on how to make sure that the 1.9 version doesn't use the same data as 1.8 is currently using), I'd appreciate a pointer to it.

And I understand that 1.8 is a stable branch; if this gets fixed in 2.0 that's good by me.  ;)
Comment 7 Chris Shoemaker 2006-04-11 21:05:20 UTC
Here are my opinions about behavior:

First, when entering SX it shouldn't allow scheduling automatic entry of transactions with 3 or more commodities unless the user explicitly chooses which commodity is the "transaction-common" currency.

Reasoning: a transaction with N commodities requires N-1 rates.  For N=2 the rate is either available or not, but there's no ambiguity about the required rate.  For N>=3, only N-1 rates are needed.  N(N-1)/2 total rates, N-1 needed, and (N-2)(N-1)/2 unneeded.  But how do we know which are the needed and which are unneded?  Well, we can use some heuristics to guess, but I don't think we should.  The point is, we can't automatically enter a transaction if a rate we guessed was needed turns out to be unavailable.  Plus, I don't really think we should examine every posibility to see if the a combination of rates exist to make it possible to enter the transaction.  

Instead we should just ask: 'Hey, you've asked to autopost a trans with more than 2 commodities.  Which commodity do you want the transaction recorded in?'  or some-such.

Second, when the autopost occurs, if the required rates aren't available in the pricedb, I think it should raise a dialog, similar to the SLR dialog.  That would allow the manual entry of rates, just like a register.
Comment 8 Bengt Thuree 2006-04-12 01:24:28 UTC
Would it be possinble to have two options for the scheduled entries.

1) Automatic entry (no input needed from user)
2) Manual input needed, and user needs to select an Menu option to run these manual transactions. 

In this case, the transaction can be prefilled with the correct accounts and purchase amount, but user fills in commission and price when he enters it later.
Microsoft Money works this way... more or less...
Comment 9 Josh Sled 2006-04-12 01:46:17 UTC
(In reply to comment #8)
> Would it be possinble to have two options for the scheduled entries.

This is roughly how it works now.  As well, the template txn can include ad-hoc variables, which could be used for the commission and price fields.  And/or with user interaction in the SX editor, a-la Chris's great suggestions in comment #7, at transaction-creation time we can maybe create more variables to represent the needed conversion multipliers.  And/or make them functions against the pricedb.  Or maybe the SX SLR creates transient variables to solicit the values from the user, then updates those values in the price db, then creating the transaction just looks in the price-db. Lots of options...
Comment 10 Josh Sled 2006-04-12 01:48:36 UTC
(In reply to comment #6)
> Josh, I'll try to figure out a way to install and test 1.9.x in a reasonable
> way without getting rid of my existing 1.8 installation.  If there's any
> documentation on that (and in particular on how to make sure that the 1.9
> version doesn't use the same data as 1.8 is currently using), I'd appreciate a
> pointer to it.

Install it as a developer would: build it from scratch, with a --prefix of "/opt/gnc/unstable" or something.  Install and run it from there.  For now, they'll co-exist.  Don't install it with a prefix of /usr or /usr/local, though.
Comment 11 Scott Engles 2006-04-14 23:18:52 UTC
I was bit by this bug yesterday (at least I'm now pretty sure it was this one - it has the "assertion failed: (nextPg != NULL)" behavior).  It cost me a day of work getting my file back in order and ticked me off enough to finally register with bugzilla and file bug 338400.  Now I think it was this problem that caused the crash in the first place.

My point here is really that I got the crash via what seems a pretty natural path, to me:  First I imported 14 years worth of Quicken data to gnucash (1.6).  Then I started using my 1.6 file with gnucash 1.8 when I changed to Fedora Core 5.  This worked fine.  So recently I started scheduling transactions.  One of the transactions I scheduled was a regular monthly dividend payment.  All I did was to click on the existing transaction, of which there were already dozens in my register, and schedule it for the 1st of every month.  When I went to create the transactions using the schedule feature ("since last run"...) it crashed and took a lot of work down with it (and the "replay log file" was either hung or effectively hung, bug 338400).
What had happened was that the gnucash import feature (of my QIF file) had set up my dividend income account with the commodity of the stock, rather than USD.  This led to the crash.
Apparently 1.8.12 is the end of the line for 1.8, but if there were going to more, I would say this definitely needs a fix.  It can be hit WITHOUT setting up currency accounts or doing anything pathological (unless you consider a QIF import pathological :-).  In any case, it's unacceptable for an ordinary user to be able to drive a crash like this from his GUI.

I will try to add the little boiled-down file (5422 bytes) which exhibits the crash, as an attachment:testcase, in case it would be helpful for somebody.

Scott Engles
Comment 12 Scott Engles 2006-04-14 23:25:42 UTC
Created attachment 63528 [details]
gnucash account file that crashes upon pressing Next on startup

This small file has only two accounts, no recorded transactions, and one scheduled transaction.  It should attempt to create the scheduled transaction upon startup.  Upon clicking Next to create the trns, it crashes.  If one sets the scheduled trans up to "create automatically", then gnucash would crash immediately on startup with no opportunity to "cancel" out of it.
Comment 13 Christian Stimming 2006-04-25 08:16:19 UTC
Thanks a lot for the test file. Does the test file from comment#12 crash on 1.9.x as well, or only on 1.8.x?
Comment 14 Scott Engles 2006-04-27 18:40:27 UTC
Sorry, I didn't make that clear:  I have only tried this on 1.8.12.  I don't have 1.9.x loaded on my system (I'm just an ordinary user who was on 1.6.x until I got 1.8.12, which came with the Fedora Core 5 distro).

I presume that it is easy enough to extract the file and test it on 1.9.x, but I don't have plans to install 1.9.x at this time, unless there is a compelling reason to.
Comment 15 Josh Sled 2006-04-27 18:46:19 UTC
This data file won't crash 1.9.x anymore, but the handling still isn't great; see comment#7 and comment#9.  I'm re-naming and re-adjusting this bug to be the "multi-currency SX handling sucks" bug.
Comment 16 Josh Sled 2006-04-27 19:06:25 UTC
*** Bug 339900 has been marked as a duplicate of this bug. ***
Comment 17 Josh Sled 2006-04-29 21:55:54 UTC
Okay.  r13881 (1.9.6) will have an updated since-last-run UI that will solicit needed exchange rates from the user as if they were variables.  The "base" commodity for the transaction and values is still the first split in the Transaction.  I still like Chris's idea to query the user about this at SX editing time, but with the string freeze that's not going to happen in 2.0.  So, I'll leave this bug open to attend to that post-2.0, and call this sufficiently solved for now.  Feedback welcome.
Comment 18 Christian Stimming 2006-08-10 09:45:38 UTC
*** Bug 105664 has been marked as a duplicate of this bug. ***
Comment 19 Christian Stimming 2006-11-04 22:23:35 UTC
I'm just going through the milestone-2.0 bugs. Josh, did you target anything still for 2.0.x? The string freeze is lifted, so from a translator perspective, you could just go ahead. Otherwise you are free to change the target milestone to whatever you consider appropriate :-)
Comment 20 John Peach 2007-01-17 16:38:48 UTC
A scheduled transaction was created in version 2.0.2 that would transfer money from a CDN account to a USD account.  Then the transaction is due, the "To-Create Transaction Preparation" window comes up and asks for the exchange rate.

1) What is the "To-" doing in the title... it should just say "Create Transaction Preparation"
2) There is a back button that is active but does not do anything
3) The forward button is active even though no nothing has been entered in the exchange rate box.   This should be disabled until a valid value is entered
4) The program is asking for the USD->CDN exchange rate even though the money is going from CDN to USD.  I entered the USD->CDN exchange rate and apply the transaction.  When I look at the accounts I see that the correct amount was taken out of the CDN account but the wrong amount was entered in the USD account.  It looks like this:
CDN account amount = $100
USD->CDN = 1.1495
USD amount was: $115

It should have been something like
CDN account amount = $100
CDN->USD = 0.86
USD amount was: $86

It may be that the wrong label on the exchange rate was displayed.

5) The exchange rate of 1.495 was entered.  However, the program changed it to 1.15  
Comment 21 Andreas Köhler 2008-03-31 22:34:54 UTC
Is this bug still valid for GnuCash 2.2.x?
Comment 22 John Peach 2008-04-01 02:10:27 UTC
Andreas, I can confirmed the bug is still in V 2.2.1
Comment 23 Boris Zbarsky 2008-12-03 03:12:27 UTC
So I've finally gotten a newer gnucash version set up (2.2.7 to be exact).

The new behavior is that I just can't set up a scheduled transaction of the sort that I want (one split in USD coming out of a bank account, two splits in mutual funds) to be created automatically.  If I run the "Since last run..." thing manually, it prompts me for the exchange rate from USD to one of the mutual funds (the price) and for the exchange rate from one mutual fund to the other (ratio of prices, I guess...).  Given that both mutual funds are in the price database, it seems like pulling a price from there would be better than the current setup.  The worst-case scenario is that the price doesn't match the "real" price on that day, and that can be handled by the user at reconcile time.
Comment 24 Steven N. Severinghaus 2012-08-03 17:26:58 UTC
I've been trying to schedule dividend transactions, with no success. I see three other bugs that seem to be related, and I wonder if they should be consolidated:

https://bugzilla.gnome.org/show_bug.cgi?id=635583
"Investment transaction created from Scheduled Transaction cannot be edited"

https://bugzilla.gnome.org/show_bug.cgi?id=662126
"Cannot create scheduled transaction for dividend reinvestment"

https://bugzilla.gnome.org/show_bug.cgi?id=533508
"Since Last Run - Entered Value not recognized"

These are all from different versions, but as of 2.4.9, it is still a problem.

It seems like this is something that people want to do but that is known not to work, and I wonder if perhaps it needs to be detected and prevented at the point where the SX is first being created. This would be an improvement over the status quo of confusing symptoms and corrupted transactions.
Comment 25 John Ralls 2018-06-29 20:47:57 UTC
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=157179. Please continue processing the bug there and please update any external references or bookmarks.