Thank you all for your responses. For the record, this is for private bookkeeping purposes (mainly splitting costs for different things with roommates), and so regulations generally don't apply as accuracy to a cent is more than enough and I mostly just want to prevent having to fix imbalances often. Having done this for the past ~12 years, for anything between 5-10 monthly transactions, I was hoping to automate this ever so slightly more, as is the trend with software.
Given the late rounding, somebody mentioned the idea earlier that adding or subtracting 0.005 could be used to turn the "normal rounding" into either "rounding up" or "rounding down", I haven't tested that yet, but I suspect that could work, at least as long as the amount only has be split between two parties: my_expense_amount = (total_amount / 2) # Normal rounding roommates_expense_amount = (total_amount / 2) - 0.005 # Rounding down This is a little messier than I hoped and only works well when splitting two-ways (when you do 3+-ways it gets a little trickier). I was wondering if any devs here could comment on the options to rather supporting a function to explicitly trigger the rounding early, that way the above could e.g. be written as: roommates_expense_amount = (total_amount / 2) # Or really any fraction could work with this my_expense_account = total_amount - roommates_expense_amount = total_amount - gnc_round(total_amount / 2) I'm aware that custom functions can be added to fin.scm, but I didn't dig deep enough yet to understand how I could explicitly trigger the rounding-step from there, if at all. Plus it seemed like there's a slim chance this could be a useful function to include by default since gnucash doing rounding is an omnipresent operation. Thanks for all your suggestions! Thomas On Tue, Dec 22, 2020 at 3:56 PM Michael or Penny Novack < stepbystepf...@comcast.net> wrote: > On 12/22/2020 5:17 PM, Liz wrote: > > I think that we have taken a peek down a rabbit hole and found > > enormous complexity past the entrance. > > > > Liz > > > For us pros it gets far worse than that. In my working days often had to > compute the "fuzz" value to use in comparisons because of "rounding > errors" when the two amounts being compared came from different > calculations. The "fuzz" is the maximum amount of difference that could > have caused. So you can't test for "equal" but need to test for equal > +/- fuzz. > > Michael D Novack > > _______________________________________________ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > If you are using Nabble or Gmane, please see > https://wiki.gnucash.org/wiki/Mailing_Lists for more information. > ----- > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. > _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.