On 5/1/19 9:34 PM, D via gnucash-user wrote:
> I never knew that zero was negative number!
In IBM computers of the 704, 709, 7090, 7094 line, the numbers were in
sign-magnitude form, different from the two's complement form in common
use today. So there were both Positive zero ane Negative zero on
Have you tested the following:
Delete the transaction instead of using the `Void Transaction` function?
Add a reversing transaction either manually?
or using the `Add Reversing Transaction` function?
Curious to see if this discrepancy holds against all workflows.
Regards,
Adrien
> On May 1,
I’ve seen zero as a negative (or red) number before with other applications.
(notably, OOo/LO Calc)
It usually results from a rounding situation where the color is set before the
rounding down to zero. So the real amount was a negative closer to zero than
`-1`.
It is fixable, but would require
Jeff,
Assuming that you're referring to the figures in the reconciliation window, I
have noticed that issue as well. It seems that once they are displayed as red,
the color setting is never revisited.
I just ignored it, knowing that the color was wrong; since a red zero (I never
knew that ze
Is this a know bug? and/or could someone forward it to gnucash-devel if
appropriate?
Windows 10 GNUCash version Version: 3.5 Build ID: 3.5+(2019-03-30)
I'm balancing a checking account. It has a positive amount for Present
and Future in black. I don't specifically remember the Balance column.
