GNOME Bugzilla – Bug 157179
Poor handling of multi-currency/fund scheduled txn
Last modified: 2018-07-02 07:14:22 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.
Scheduled Transactions do not support stock/mutual fund txns.
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.
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?
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.
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.
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. ;)
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.
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...
(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...
(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.
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
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.
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?
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.
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.
*** Bug 339900 has been marked as a duplicate of this bug. ***
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.
*** Bug 105664 has been marked as a duplicate of this bug. ***
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 :-)
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
Is this bug still valid for GnuCash 2.2.x?
Andreas, I can confirmed the bug is still in V 2.2.1
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.
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.
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.