Description: In LibreOffice Base, I created a table "Table1" with an ID and a field "Amount" as a number of length 8 with 2 decimal places. I created then a form "Form1" with a table control and three columns: ID, "AmountCurrency" and "AmountNumeric". The"AmountCurrency" is a currency field and the "AmountNumeric" is a numeric field; both of these fields linked to the "Amount" field from "Table1". For "Amount" = 9.87 or 8.87, "AmountCurrency" shows "£9.86", respectively "£8.86". I have not found any other value where this mistake happens. Steps to Reproduce: 1. Create a new base file 2. Create a table with an ID and a numeric field with at least 2 decimal places 3. Create a form layered on the table with a table control and 3 columns, the first for the ID, then a currency field linked to the numeric field in the table and lastly a numeric field linked to the same numeric field in the table 4. Enter 1 into the ID and 9.87 into either of the other field Actual Results: The numeric control on the form shows "9.87" and the currency control shows "£9.86". Expected Results: The currency control should show "£9.87". Reproducible: Always User Profile Reset: No Additional Info: The bug shows on Windows and IOS and with all our 3 users. Version: 7.6.2.1 (X86_64)/ LibreOffice Community Build: 56f7684011345957bbf33a7ee678afaf4d2ba333 Environment: CPU threads: 4; OS: Windows 10.0 Build 19045 User Interface: UI render Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Misc: Calc: threaded
Created attachment 191396 [details] The Base file with the bug (9.87 showing as £9,86)
You are right. The currency field will show wrong values for 8.87 and 9.87. This bug only appears inside a table control. Field will show the right values as a separate form control. For the moment: Use formatted field instead. Works well and will show negative values in red. I only use this field so I never saw such an error before. Could reproduce with Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 6; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded
I have the similar problem in a amount field in a table control. I enter -77.99, but the form displays -77.98; the row in the table correctly shows -77.99. I have deleted and reentered the value, delete the row, saved, shut down Base, re-stared it and re-inserted the row - all to no avail. The only thing that fixes the problem is to switch from 2 decimal places to three. Base will then display the correct value, -77.99. I am running BASE 24.2.7.2 on Linux Mint 22. My machine is an Intel I7 with 32Gb of DRAM.
Reproduced also in Version: 24.8.3.2 (AARCH64) / LibreOffice Community Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 CPU threads: 8; OS: macOS 15.2; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded @Mike: I remember you did some work on the number handling for Base not too long ago. Would you by chance have any idea why the number is being rounded down for the currency format control ?
Regression from commit 0abbf64dc1ebe9f12523a69ce1cfd25fe189d869.
It seems that in LongCurrencyFormatter::FormatOutputHdl [1], rounding fValue before passing it to ImplGetCurr (where it silently truncates as BigInt) fixes the problem. [1] https://opengrok.libreoffice.org/xref/core/vcl/source/control/longcurr.cxx?r=36df3f9ad2f71c122af3cf9fbc58c661f416658e&mo=5930&fi=220#220
we used to round in the previous long currency formatter before https://git.libreoffice.org/core/+/0c85d1ee0688435ffefd8eff797e57eac9bace27%5E! so lets just do that again as https://gerrit.libreoffice.org/c/core/+/179917
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c2f6f23097121a56da9bbd50f96ab5878ced0fec Resolves: tdf#158669 round long currency to decimal digits in use It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/4d996634ee43aeb84925d1cc7553b07ac94a5ceb Resolves: tdf#158669 round long currency to decimal digits in use It will be available in 25.2.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/d330dccca8d5ec8619aaaca626afabb04ab58679 Resolves: tdf#158669 round long currency to decimal digits in use It will be available in 24.8.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.