GNOME Bugzilla – Bug 488534
reconciliation does not take into account the given ending balance with french locale
Last modified: 2018-06-29 21:52:37 UTC
Hi, I'm french using Kubuntu feisty ang gnucash. When I try to reconcile an account today, whatever I enter in the ending balance is not taken into account when the reconcile window opens. It seems to only take the balance I had on the chosen day for reconciliation. For instance, if I have 504€ on 2007/10/05 in an account page, and if I'm told by my bank that on that day I had 1234€, that's the amount I would like to see reconciled. But gnucash only accepts 504€ (well, it accepts anything but only keeps that amount) or an empty value which is then understood as 0€. So I can't reconcile in French. Still, I started gnucash with the following commandline, in order to have gnucash in english (and to more easily report this bug - hey, I'm french ;) ) : LANG=C gnucash Trying to reconcile... apparently takes the right value with this !!??? I didn't click on "finish reconciliation" for now as I'm ready to provide you with an anonymised version of my gnucash file (for easier debugging ?), if you tell me how to do that... Cheers
Lowering severity (see <http://bugzilla.gnome.org/page.cgi?id=bug-status.html#bug_severity>, workaround present).
I cannot reproduce this one. What does "only accepts" mean? Do you enter dots instead of commas?
Hi Andreas, What I meant with "only accept" was that whatever amount I enter in the "Ending Balance" reconciliation setup box, this amount is not taken into account when the reconciliation window appears. The amount that appears in the reconciliation window that's open afterwards is the amount that was initially present when the reconciliation setup window popped up... I hope it's more clear said like that ? I just checked, and I enter commas, not dots. Also as Maf. King described in the users mailing list, changing the reconciliation date back just one day seems to work around the problem.
Hi Frederic, bugzilla was quite laggy yesterday and I wanted to ask you yet another question :-) Does gnucash properly add the comma and 00 cents when you enter 123 into "Solde final" entry and press the <TAB> key? What about 123,<TAB>? Does gnucash print anything onto the console when you start "gnucash --logto=stderr" from the command line?
Hi Andreas, Yes, it does add zeroes when I enter both 123 and 123,... When I run with --logto=stderr, I see indeed a few things, but I cant' tell you what would be printed when I face the bug because it looks like today I can't reproduce it (???) - I could yesterday when I answered, and I just tried changing the date but I just can't reproduce the bug today... really strange, I don't remember I changed anything in my gnucash file yesterday... The output I have (mainly about graphical stuff I guess) is (there are lots of lines about /usr/bin/esd) : gnc.bin-Message: main: binreloc relocation support was disabled at configure time. /bin/sh: /usr/bin/esd: not found * 18:55:53 WARN <gnc.app-util> /home/fred/.gnucash/config-1.8.auto:7:15: While evaluating arguments to gnc:lookup-option in expression (gnc:lookup-option gnc:*options-entries* "Register" ...): /home/fred/.gnucash/config-1.8.auto:7:15: Unbound variable: gnc:*options-entries* In /home/fred/.gnucash/config-1.8.auto: 7: 0* (let ((option #)) ((lambda # #) option)) 7: 1* [gnc:lookup-option ... Found Finance::Quote version 1.12 * 18:55:54 WARN <gnc.backend.file> Invalid timestamp in data file. Look for a 'trn:date-posted' entry with a date of 1969-12-31 or 1970-01-01 (...) * 18:55:55 CRIT <GdkPixbuf> gdk_pixbuf_new: assertion `width > 0' failed * 18:55:55 CRIT <GdkPixbuf> gdk_pixbuf_get_n_channels: assertion `pixbuf != NULL' failed * 18:55:55 CRIT <GdkPixbuf> gdk_pixbuf_get_bits_per_sample: assertion `pixbuf != NULL' failed * 18:55:55 CRIT <GdkPixbuf> gdk_pixbuf_get_width: assertion `pixbuf != NULL' failed * 18:55:55 CRIT <GdkPixbuf> gdk_pixbuf_get_height: assertion `pixbuf != NULL' failed * 18:55:55 CRIT <GdkPixbuf> gdk_pixbuf_get_rowstride: assertion `pixbuf != NULL' failed * 18:55:55 CRIT <GLib-GObject> g_object_unref: assertion `G_IS_OBJECT (object)' failed * 18:55:55 CRIT <GdkPixbuf> gdk_pixbuf_new: assertion `width > 0' failed * 18:55:55 CRIT <GdkPixbuf> gdk_pixbuf_get_n_channels: assertion `pixbuf != NULL' failed * 18:55:55 CRIT <GdkPixbuf> gdk_pixbuf_get_bits_per_sample: assertion `pixbuf != NULL' failed * 18:55:55 CRIT <GdkPixbuf> gdk_pixbuf_get_width: assertion `pixbuf != NULL' failed * 18:55:55 CRIT <GdkPixbuf> gdk_pixbuf_get_height: assertion `pixbuf != NULL' failed * 18:55:55 CRIT <GdkPixbuf> gdk_pixbuf_get_rowstride: assertion `pixbuf != NULL' failed * 18:55:55 CRIT <GLib-GObject> g_object_unref: assertion `G_IS_OBJECT (object)' failed
Just an additionnal comment : I'm still facing the problem, but it seems the work around that's mentioned above does not always work : I'm currently unable to get the right reconciliation amount in the reconciliation dialog... really strange.
And yet another comment, I think I got closer to the bug : entering an amount with 123 and pushing tab adds a coma and 2 zeroes : ",00" entering "123.00" and pushing tab does *not* change the dot into coma When I try to reconcile in French, I'm pushing the dot that on my numeric pad when I enter the correct amount, and the dot is not transformed back into a coma as this is done when I'm using the other features of gnucash : if I enter the correct amount using a coma, it looks like the correct amount is passed into the next dialog... I hope this will help determining and fixing the bug ? Cheers
Which feature of GnuCash converts a dot into a comma? I have tried the register in a french locale and it does not even let me enter dots. So if you additionally have "automatic decimal point"[s] enabled in the general preferences, then GnuCash will insert a comma at the specified position. I am not sure yet whether this really is a bug. Do dots sometimes appear after 10^3, 10^6, ... ciphers as they do in Germany? It is hard for GnuCash to always know what you mean :-) Maybe jsled has an idea.
Hi, actually I was indeed referring to the amounts entered in the register : it actually does not enter dots when I hit the numeric keypad dot key, but a coma, same as you : but when I enter an amount in the first reconciliation dialog, it lets me enter both dots and comas, even though it seems it only understands a coma... but I never ever enter comas when I enter a decimal number in a soft, I use the dot key (yeah I know, looks complicated... but coma key is not on numeric keypad, so it's never used by French people on computers for numbers - except in excel, but that's not a real soft, is it ? ;) ) I'm not sure I correctly understand your question about the 10^3, 10^6 stuff ... when I have an amount that's greater than 999 , gnucash displays for instance "2 345,67" (no dots).
Still a problem with 2.2.7? Also, what was the problem exactly?
Hi, Just tried on 2.2.4 under Kubuntu 8.04 : but did not appear... but it may be due to the fact the amount I entered in first reconciliation window already contained a coma - even if I pressed the keypad dot key (I selected "dot" as the decimal separator under KDE4 properties...) Cheers
Since you can't reproduce this bug anymore, and no-one else seems to hit it, I'm closing this bug for now. Should the problem reappear, please reopen this bug and add the appropriate information.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=488534. Please update any external references or bookmarks.