GNOME Bugzilla – Bug 161518
quick-fill and multiple splits
Last modified: 2018-06-29 20:48:31 UTC
I've been having a problem (originally with 1.8.9, but still with 1.8.10) entering transactions with multiple splits when the quick-fill feature is used. 1. select date, tab over to Description field 2. Enter the first part of a description until it matches a previous transaction. 3. Click the split button on the toolbar. 4. Tab past various fields to the account. Change the account. 5. Tab over to the payment column. Change the amount. 6. Tab to the next split in the transation. When I arrive there, the amount I entered in the previous split is now blank. I have been able to determine that this only occurs if I change BOTH the account and the amount. Naturally, this is important for stores where one buys a variety of goods. This is accompanied by a bunch of lines output on the starting shell like this: Warning: PrintAmountInternal: Bad numeric. The account in which I am trying to enter the transaction is a credit card account. My data were imported recently from a bunch of Quicken98 QIF files. There are 7 years of data in there, so it is quite large. I compiled 1.8.9 with CFLAGS="-O2 -march=pentium2" and also with CFLAGS="-g". The problem occurred in both versions. Version 1.8.10 has been compiled with CFLAGS="-O2 -march=pentium2". The behaviour is identical in all instances. My system is based upon Slackware 10 with kernel version 2.6.9. I have installed sufficient libraries for gnome 1.4 to get gnucash to compile as per instructions found at: http://rjmarq.org/gnucash.html This worked even though the instructions are for Slackware 9.1. There is a workaround - enter a different description every time so that the quick fill feature cannot prefill the transaction. However, I would prefer not to have to do this.
The compile options for gnucash probably don't have anything to do with your reported problems, so these should be fine. However, is the quick-filled transaction of any special kind? E.g. are there multiple currencies and/or stocks involved?
The only currency involved was Canadian. I verified that all the accounts were the same currency since if I tried to continue tabbing through split fields, it would put up a dialog asking about a currency conversion. This was completely spurious. There were no investments involved in this transaction. I was recording a charge to a credit card, and recording the expense in several accounts, which were different from the last time I had bought something at that store. Since I have little to no familiarity with the gnucash source, my efforts at debugging were not particularly illuminating. I did note the following, which I found suspicious. When tabbing out of the first split (after changing the value from 21.37 to 19.79), in file pricecell,c, function gnc_price_cell_parse, line 149 (gnucash 1.8.9 sources), the variables newval and oldval both contained the value 19.79. Their names suggest that this should not be the case. This bit of code looked like it was testing if the cell had been changed. Since the variables both contain the same value, it looks to me as though the code may believe that the value was not in fact changed. I have two speculations: 1. the size of the file could be a problem. It contains 7 years worth of data. However, I doubt very much I am the first person to do this. 2. a subtle problem in the QIF import from Quicken98 has resulted in some difficult to detect file corruption. This is supported by error messages on the console such as the following from the other day: Error: gnc_split_register_get_tra...(): bad row ** CRITICAL **: file gnucash-sheet.c: line 141 (gnucash_sheet_cursor_set_from_table): assertion `gnucash_sheet_cell_valid (sheet, v_loc)' failed. Error: gnc_split_register_get_tra...(): bad row ** CRITICAL **: file gnucash-sheet.c: line 141 (gnucash_sheet_cursor_set_from_table): assertion `gnucash_sheet_cell_valid (sheet, v_loc)' failed. (NOTE I was not experiencing this bug at the time, and did not see these errors when I was. I note them only because they make me suspicious that my file may be corrupted.)
And just an additional question for completeness' sake: Are you viewing these transactions in the "General Ledger" register window, or in the register window of a particular account? Other people have reported various problems with the General Ledger and quickfill, and these problems do not occur in the register window of particular accounts.
I am entering these transactions in the register window of a credit card account. In thinking about possible file corruption, I note the following three items, 1. My balance sheet does not balance. I suspect this is partly due to Quicken and Gnucash differently accounting for capital gains, but the imbalance is not by an amount I can recognize from any capital gains reports in Quicken. 2. I also tried a "Check and Repair All". However, it appears that gnucash did nothing. The menu simply disappeared, with no watch cursor, and no CPU activity. I was expecting a dialog or a delay comparable to the time to build a report. The problem continues to occur after this operation. 3. I made a test file from scratch, with made-up data. The problem did not occur. This really makes it appear to be related to my data, and possibly the QIF import.
I'm just confirming this bug. I've had this problem as he describes, but also in the SX editor window. The first couple of SX's went smoothly. After that, just some regular bill payments (deduct from checking, pay to say...gas company), I'd enter all the information in, and the last field where you put in the dollar amount paid to the gas company would go blank if you click OK, and you'd get the bad numeric error in the console. You get an error stating that GnuCash could not balance the transaction. The workaround is to enter the transaction unbalanced, open it in the editor again and re-type the last field. Annoying, as I'm having to do this every time now.
I created a brand-new not imported from Quicken data file for this year. Then, I did not experience this problem. Today, I imported data from my wife's Quicken file. This problem came back. This time, I decided to look at the XML data. For at least some imported transactions, the currency was recorded as USD. However, all my accounts are in CAD (except investments, which are in their respective share types). So I found I had USD transactions recorded in CAD accounts. I had earlier verified that the created accounts were in CAD. Additionally, the importer IIRC asked me about the currency in the QIF files, and I told it CAD. I changed the XML file to indicate that these transactions were in CAD, reopened it in gnucash, and found that the problem has gone away. It would appear that the QIF importer has incorrectly recorded the transaction currency for some transactions. I am now using version 1.8.11 of gnucash.
The original bug here is a dup of bug#106671 although Mark wouldn't have known that at the time, because he didn't know he had multi-currency transactions. This bug is too far along to simply re-file as a QIF-Import bug. Mark, if you can reproduce this can you please file a bug against QIF Import and possibly attach a sample QIF file snippet? *** This bug has been marked as a duplicate of 106671 ***
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=161518. Please update any external references or bookmarks.