Further investigation found that in the 'Edit Account' panel, the 'Smallest fraction' was set at '1' on this particular account, and the amount was being rounded up on one side, causing the mismatch. Setting the 'Smallest fraction' to 'Use Commodity Value' and running 'Repair All' sorted the problem. I hope the above may be a solution for someone and save them time, if not hair.
It bears repeating, as soon as rounding is involved, exactly in balance goes out the window. It is simply a reality of mathematics that rounded A + rounded B is not necessarily equal to rounded (A + B). Your problem could exist even if both sides were rounded/
LOL -- in my working days, one of the things I did a number of times was calculate the value of the "fuzz" (the maximum discrepancy between calculations done in different order as a result of limits in precision/rounding --- so the computer program would consider the two equal if the difference were less than "fuzz"). And those of us doing calculations in science/engineering know that the order in which we do them can have a great effect on the possible "error" << so we choose the order of calculations that minimizes that >>
In its original form. double entry bookkeeping could demand exact balance because the only operation was addition/subtraction and no rounding involved.
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 ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
