GNOME Bugzilla – Bug 781980
SX editor: Zero fill empty fields and adjust separators at field exit.
Last modified: 2018-06-29 23:56:24 UTC
Using the Since Last Run assistant to enter a simple scheduled transaction previously saved with the following calculation causes an Invalid Transactions error -3 in SX final gnc_numeric value. 3,101.32-230.41-481.28+174.24 This is in the US with standard US default number and currency settings. Release 2.6.15 Windows I have also noticed on other occasions that when manually entering numbers in a transaction if a comma is 3 digits to the left of a decimal point or the final numeric digit the comma is ignored but if it is not three places to the left it causes an error. When a value with four or more digits is displayed by GnuCash it has commas automatically inserted, but if a digit to the right of the comma is deleted an error occurs. I would expect all commas to be ignored on numeric entry when the decimal separator is a period, but perhaps that part is arguable. Seems like the same rule should be used in both cases, whatever that rule is.
When this error occurs the scheduled transaction is entered into the register but it reappears in the Since Last Run dialog for the same date the next time the SLR is run, causing duplicate entries in the register.
In further testing it seems that the string is not what is triggering the error. I have completely removed that string and the error still occurs. This is a fairly old SX that has worked in the past in older releases of GnuCash. It now has five split lines all containing simple decimal amounts in the values. I will try starting GnuCash with the --debug option to see what happens.
Created attachment 350815 [details] excerpt from tracefile Excerpt from the tracefile around the error message. If you need more before or after I will keep the whole file for a while
Some additional information: error -3 means "GNC_ERROR_DENOM_DIFF". It's defined here: https://github.com/Gnucash/gnucash/blob/maint/src/libqof/qof/gnc-numeric.h#L224 The comment in the source file states this error is raised when GNC_HOW_DENOM_FIXED was specified, but argument denominators differed. Right before this error your log file indicates a number of splits get scrubbed. It looks like this is causing it. Why now and not before is not clear to me and I won't have time to investigate further :(
I just tried opening the file with release 2.6.14 in Windows and had the same error when running SLR on that transaction. Then I tried release 2.6.11 in Debian on the same file and it entered the transaction without error. This time the transaction had all simple decimal numbers with no commas, no plus or minus signs. That version is the one that I have used most often in the last few months.
Heh, not surprising. You might recall that you had a bunch of SX bugs that I fixed for 2.6.12. Good that it failed on 2.6.14, though, that rules out the scrubs from being the problem. They were introduced in 3367e19 that was released in 2.6.16. Can you explain what string you removed in comment 2? I'm also confused about the comma in the first number: Is that not in your template transaction? Was it and you removed it when you tested on 2.6.11?
I was testing the premise that either the thousands separator comma or a math symbol was causing the error, because that seemed to be the oddest thing in the transaction. By comment 2 I had replaced the string "3,101.32-230.41-481.28+174.24" in the value of the first split line with the value "2,563.87" except without the comma. I also tried putting the comma back into that single value as you see here. So, when I tried release 2.6.11 I think that the comma was back, as it is there now as I am looking at the file with release 2.6.15 in Windows. I also tried to find the template using LibreOffice Writer on the file but I got confused by all the tags in the splits. I am not comfortable with that stuff. I still think that if there is an error, the transaction should not have been saved. Because I have not deleted all of them yet, there are six copies of that transaction in the file right now.
I still think I don't fully understand what you're doing. The formula is (was?) in one split of the template transaction, right? What about the "other" split? Since there aren't any variables in the formula saving the template transaction should put a number in the credit_numeric and debit_numeric slots. 2.6.16 added a scrub to make sure that those numerics have values matching the calculated value of the string (or no value if the string has variables). As Geert observed it appears that the error might occur as one of those scrubs. It occurs to me that the scrub might have written an error gnc_numeric into the slot and all attempts to load are failing. It might be that before the SX changes a year ago the foo_numeric fields weren't checked and so the bad value in the file raises the error in 2.6.13 and after.
This transaction is/was set up similar to a simple payroll check with one income, a few expenses (all numbers, no variables) and a net deposit. I was lazy and just filled the net split line with a simple numeric formula with a sum of all the other numbers instead of variables thus "3,101.32-230.41-481.28+174.24" without the quotes. In a SX template it gets saved that way instead of being instantly evaluated as in a regular transaction edit. Since it is not evaluated when it is saved, I did not want a trivial math error to generate an unbalanced entry when the SX is entered. I have used that technique in several other SX's with no problem. When I did get the error I started fiddling with the structure of the string, thinking the problem was there. Maybe it was at one point, and now there is, as you suggest, something in one of the slots that shouldn't be there, but it is not visible to the user. I still have the data file open on Libre Office Writer and I see many slot entries such as "<trn:split> <split:id type="guid">e35e298231710f84301bbaf281088411</split:id> <split:memo>Payment 0nn of 120+: 0m-3d-2017</split:memo> <split:reconciled-state>n</split:reconciled-state> <split:value>0/100</split:value> <split:quantity>0/1</split:quantity> <split:account type="guid">4fb0bed40f83cb77bbf0ad75b87f610a</split:account> <split:slots> <slot> <slot:key>sched-xaction</slot:key> <slot:value type="frame"> <slot> <slot:key>account</slot:key> <slot:value type="guid">3bd142add4d74acee5eed822f48105ac</slot:value> </slot> <slot> <slot:key>credit-formula</slot:key> <slot:value type="string">3101.32</slot:value> </slot> <slot> <slot:key>credit-numeric</slot:key> <slot:value type="numeric">77533/25</slot:value> </slot> <slot> <slot:key>debit-formula</slot:key> <slot:value type="string"></slot:value> </slot> <slot> <slot:key>debit-numeric</slot:key> <slot:value type="numeric">0/1</slot:value> </slot> </slot:value> </slot> </split:slots> </trn:split>" How can I tell if this is 'correct'?
I just ran across a different transaction where the SLR produced a transaction that did not match the SX as viewed in the SX editor. There was a value in a split line that was only included for reference and showing nothing in both the credit formula and the debit formula boxes. At some time in the past that line did contain a value. It happened that because the SX was now unbalanced as created, it added a line to balance the transaction as it was entered. I decided to try entering zero into the box that had the bad value, so next month I will find out if there is a change. This has made me think that perhaps the checking during the SX editor save only happens for split lines that contain something new or different.
That is an annual transaction so it will be a year before we see if it is fixed.
Running a test of my thought in comment 10, I entered the value 0 into every formula box of the bad scheduled transaction that did not have any other value and saved the scheduled transaction. Then I ran the Since Last Run assistant with that transaction set to To-Create. The transaction was created with no error. Apparently one of the zeros overwrote whatever was causing the error.
Created attachment 350997 [details] Text of the bad split Close examination of newly created transaction revealed which split line had the problem. I found that one line of the template had both a credit Formula and a debit formula, which created an imbalance as the transaction was entered. I am attaching the text of the split.
OK. So an old SX that you created before we fixed your SX bugs last year now is revealed to be broken. Sounds like a feature. Shall we close this?
I think that if the code has been revised to force zeros or nulls into fields that are visibly blank and to re position commas (thousands separators) that were moved by an insertion or deletion but not manually corrected when the SX is accepted, that covers the remaining issues I have in this bug report.
OK. I've adjusted the title and marked it as an enhancement.
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=781980. Please continue processing the bug there and please update any external references or bookmarks.