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.
