Please be aware that i use the portable windows version I have to use very low quantity values for a special type of invoice. I used the invoice editor and never had problems. Now I wanted to import an invoice from a CSV and the import crashes without any error. XXXXXXX1;20.07.2020;XXXXXXX2;XXXXXXX3;XXXXXXX4;20.07.2020;XXXXXXX10;XXXXXXX5;XXXXXXX6:XXXXXXX7;0,00005;54,60;;;;;x;;20.07.2020;20.08.2020;XXXXXXX8:XXXXXXX9;XXXXXXX0; I used XXXXXXX0 ... XXXXXXX10 for privacy reason and they seem not to be the problem. I can import quantity values of 1 down to 0,0005 but 0,00005 and lower cause a crash. Please do not say such low quantity values do not make sense in my particular case it makes sense.
5/10000 of what? In particular, what is the commodity's fraction traded and what have you set for the smallest fraction in the receiving account? Is 54,60 the value of the items? There are probably errors reported in the trace file, see https://wiki.gnucash.org/wiki/Tracefile for help finding it. Please attach the one from the crash using the "Add an attachment" link in the box above.
Thank you for your quick response. Unfortunately I couldn't find any actual tracefiles. There are some from 2 years ago. However, I can't remember how I generated them. I need to go into more details. It seems that the standard way of generating tracefiles as described in the link does not work with the portable version of gc. Unfortunately I do not have the chance to install a version to see if it also crashes in the regular version. I will come back as soon as I have found anything new. Or do you know how to generate the tracefiles in the portable version? .\GnuCashPortable.exe -debug -extra does not start at all. Only without any option.
You'll have to ask PortableApps support. We don't support them because they modify our code and violate the GPL by not publishing their modifications.
Created attachment 374006 [details] Tracefile Comment: A tracefile of the time before crash
Created attachment 374007 [details] File causing the trouble with small value to import comment: Trouble file
I could manage to install GNC on a new machine and reproduce the error. It does not only happen on the portable installation. I set up a test account and the machine crashed when I was importing a too small number (here 0,00001). I just XXXXXX out some personal data in the trace file.
The CSV isn't useful unless you also tell us what columns go to what GnuCash fields and the commodities and accounts involved. Since you made a test book you could attach that as well. Since you declined to answer the questions in comment 1, I have to guess based on the trace file: It suggests that the fractions on the accounts are all either 1/1 or 1/100, so trying to import an amount of 5/100,000 will round to zero and computing the price (I guess 54,60 is the value?) would cause a divide-by-zero exception. You need to set the smallest fraction of both the commodity and the account to a value that will accommodate what you want to use. Since you made a test book you can presumably attach that without any privacy concerns. I also need the field mapping for the CSV to reproduce the crash.
Created attachment 374008 [details] Test Account
The test book is attached. Oh I thought there is a fixed link between the columns. I used this Definition: https://www.gnucash.org/docs/v4/C/gnucash-guide/busnss-imp-bills-invoices.html#:~:text=%20GnuCash%20executes%20the%20import%20process%20in%20three,creates,%20updates%20and%20posts%20the%20invoices.%20More The mapping is id; date_opened; owner_id; billingid; notes; date; desc; action; account; quantity; price; disc_type; disc_how; discount; taxable; taxincluded; tax_table; date_posted; due_date; account_posted; memo_posted; accu_splits; Sorry I didn't see your comment. You are right I let the fractions unchanged at usual fractions. Abd yes in this example 54,60 is the value / price. I now changed the fractions for the accounts but still have this problem. I hope you can reproduce the crash. I am also not sure if I used the fractions correctly and that is the cause for the crash. But at least the program should provide a warning.
Sorry, I'd forgotten that bill/invoice csv import was fixed-format. No crash, but I didn't try on Windows yet... but the sample CSV you attached has a quantity of 1 and a price of .0000001. That of course produces a zero value because Euros only have hundredths. Checking my original divide-by-zero hypothesis I switched the quantity and price. No problem there either, though this time both the quantity and value are zero. Lining up the line that crashed in your original description with the headings gives id ; date_opened; owner_id; billingid; notes ; date ; desc ; action; XXXXXXX1; 20.07.2020; XXXXXXX2; XXXXXXX3;XXXXXXX4;20.07.2020;XXXXXXX10;XXXXXXX5; quantity; price ; disc_type; disc_how; discount; taxable; taxincluded; XXXXXXX6:XXXXXXX7; 0,00005; 54,60; ; ; ; tax_table; date_posted; due_date; account_posted; memo_posted; accu_splits; ; x; ;20.07.2020 ; 20.08.2020; XXXXXXX8: XXXXXXX9;XXXXXXX0; I guess there's a misalignment there somewhere.
That is stange. I tried it on a windows (my portable installation) where i realised the crash. And the test system was on a Linux machine. In all cases I an see the correct allignement in the import "editor". I used the csv file and started with 0,01 (or 0,05 or what value I used) and inserted in every new step a further zero. All imports worked, only when there have been too many zeros after the comma it crashed. May also try if you can insert more zeros. Could it may relate to the country schema. I will make more variation when I have access to my Linux system again. Just for completeness: In your above alignment the account after the "action" is missing. But I think that is just citing error as you could import it correctly. I added a file with the header alignment.
Created attachment 374009 [details] CSV Test file with header alignment
Ah, since you can crash on Linux then you can easily get a stack trace: See https://wiki.gnucash.org/wiki/Stack_Trace for instructions. > Just for completeness: In your above alignment the account after the "action" is missing. But I think that is just citing error as you could import it correctly. Ah, account got lost while dealing with the wrapping, and I suppose the ':' in XXXXXXX6:XXXXXXX7 is the account separator, not a typo. > Could it may relate to the country schema. I will make more variation when I have access to my Linux system again. It's possible that it has something to do with localization, but I think it unlikely.
(In reply to John Ralls from comment #13) > Ah, since you can crash on Linux then you can easily get a stack trace: See > https://wiki.gnucash.org/wiki/Stack_Trace for instructions. I added the stack trace file I imported the file with price = 0,0001 which worked and let me successfully import a bill. Then I added a zero to the price 0,00001 and it crashed after I entered "C" for continue. The German terms in the file have the following meaning: Datei oder Verzeichnis nicht gefunden = File or folder not found Register können nicht ausgelesen werden: Kein passender Prozess gefunden. = Register cannot be read: no respective process. I hope that helps. > > > Just for completeness: In your above alignment the account after the "action" is missing. But I think that is just citing error as you could import it correctly. > > Ah, account got lost while dealing with the wrapping, and I suppose the ':' > in XXXXXXX6:XXXXXXX7 is the account separator, not a typo. That is correct
Created attachment 374010 [details] Stack Trace file
Comment on attachment 374010 [details] Stack Trace file You skipped the most important step in https://wiki.gnucash.org/wiki/Stack_Trace#Obtain_the_stack_trace "2. Type bt (bt full might provide additional info about local variables)." Please try again.
To be more clear, tell gdb 'bt' instead of 'c' when it tells you that terminate was called.
Created attachment 374013 [details] Stack Trace file
Sorry I was not active recently. I added the trace file and hope this time it is useful
Yes, that's good. The crash is an unhandled exception in the Bill/Invoice importer caused by rounding of the quantity to 1/100 of the currency SCU. That was done to fix bug 761172. I've added the author of that change (and much of the rest of the bi-importer) so that he can comment. Mike Evans, that's you.
Great. Thank you.
I can see where the bug needs to be handled, in dialog-bi_import.c line 793 and others with the same code. Probably. But gnc_numeric_convert doesn't catch that error and return a suitable gnc_numeric_error, so there's no error to handle in the import code and it crashes. Maybe calling gnc_numeric_convert with GNC_HOW_RND_NEVER is also a bug and it should be GNC_HOW_RND_ROUND_HALF_UP anyway. As John mentioned in Comment 7 these small values will round to zero anyway for normal currencies. Which begs the question, how many decimal places to support in the import? I don't know of any _real_ currencies that require more places than we already provide. Crypo is not supported in GnuCash AFAIK. The comma as decimal threw me for a while.
I still don't think it is because it rounds to 0. You can choose any factor like 100000 (price) and 0.00001 (quatity) (or 0,00001) which should result in 1 (should be available in any currency) and it crashes. You have such numbers for example when you sell land. And the small numbers are just the factors but the result is in a normal range. The other interesting point is that I manually can creat such invoices with those small quantity factors and there is no problem with calculating the end price. The crash just occurs when I want to import such an invoice. GC itself can handle the numbers perfectly. I use these factors since many years. Only recently I wanted to use the import function and realised it crashes.
(In reply to Wmsxx from comment #23) > I still don't think it is because it rounds to 0. The import code doesn't catch the rounding error or do anything to avoid the crash. The smallest value the importer can handle is, 0.0001 as you have seen. This will be fixed once I decide the best way without losing values due to rounding.
Mike, Forcing the amount and price to be denominated at 1/100 of the currency SCU doesn't make sense. Price in particular should always be exact subject to the limits of 64-bit integers and the commodity that amount is in will have its own SCU. Instead calculate the value and check that for rounding errors. I'll fix gnc_numeric_convert to catch the exception and return a GNC_NUMERIC error so that you can use it to check amount * price and decide what to do about rounding. BTW, GnuCash does have limited support for crypto currencies (except etherium because its SCU is an absurd 1/10^16), allowing the SCU up to 1/10^9. The limitation is that they're not currencies so you can't use them for Root, Equity, or AP/AR accounts.
(In reply to John Ralls from comment #25) > Mike, > > Forcing the amount and price to be denominated at 1/100 of the currency SCU > doesn't make sense. I agree. No idea why I did that.
Bug 734183 - Leads us to here too.
*** Bug 798066 has been marked as a duplicate of this bug. ***
Commit 7f1335e6a2f7e87 should fix. Please test.
I would like to test however, I am not an expert with these commits and self compiling. Is there an instruction somewhere from which I could try to build it.
You don't need to build it, just get https://code.gnucash.org/builds/win32/maint/gnucash-4.4-2021-03-15-git-4.4-292-gb51d227af+.setup.exe and install it.
