I believe this issue (does it have a bug number?) is causing my current problem I reported today. Is there a way to limit the number of digits recorded for COP currency?
On Mon, Feb 9, 2026 at 2:55 AM John Ralls <[email protected]> wrote: > Fred, > > I’m able to reproduce the problem thanks to a copy of your file you sent > me a couple of years ago for diagnosing a (still open) bug. The problem is > that you’ve managed to overflow GnuCash’s number system because the large > amount of COP in the TheCut transaction and the high precision of the > errant exchange rates. .000247466 is represented in GnuCash as 247466/10E10 > and the COP value of TheCut is N*10E8/10E10. Reducing the COP exchange > rate’s precision by just one digit, to .00024747, prevents the overflow. > The overflow is causing a 0 to get passed as one of the currency values. > You should have divide by 0 warnings in your trace file. > > We have int128/int128 computation to avoid exactly that kind of overflow > so somewhere that’s getting bypassed. I just need to figure out where. > > Regards, > John Ralls > _______________________________________________ gnucash-user mailing list [email protected] To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
