Re: Possible goods saving bug in 1.2.X

[Chris Travers <..hidden..>]

On Wed, Jul 13, 2011 at 12:41 AM, Luke <..hidden..> wrote:
> There is what I consider a bug in 1.2.21.  I do not recall seeing this in
> the changelog, so I am guessing it persists in 1.2.24, although I will
> verify as soon as I am able.

It persists.
>
> It appears that if one saves a good/service with a price containing more
> than two decimal places, the price is saved with only two decimal places.
>
> I.E. Saving a product with a sellprice of 9.9500, will instead save a
> product with a price of 9.95.

Actually it stores the value minus precision.  If you check the
sellprice column and you save as 9.00, it saves as 9.  9.20 saves as
9.2, etc.  As a workaround, try saving as 9.9501.  If that is
displaying improperly we can fix that without the problems discussed
below.  This behavior is consistent with how PostgreSQL stores and
displays arbitrary precision numbers (numeric types).

>
> It is still possible to make manual order/invoice adjustments of course,
> but I personally consider this a bug.

It may be a bug but I think when looking at fixing it in a stable
release I think we have to ask ourselves three questions:

1)  Is this new behavior in 1.2.x?  Or is it longstanding?  I think
this is longstanding behavior, probably even from the SQL Ledger days.
2)  Is this a simple fix or is the fix invasive?  Fixing this involves
changing how we store, retrieve, and format amounts and similar
problems are known to exist elsewhere in the application.
3)  Does this impact common use cases or rare ones?

I would not be currently in favor of fixing this for 1.2.x, except as
a custom patch.  It's an extremely invasive fix and affects rather
rare workflows.  I would be concerned that we would possibly introduce
far more serious bugs in trying to fix this.

As for 1.3, I am thinking it may be possible to introduce a fix here.
After all we have already addressed a similar problem on orders and
invoices.

Best Wishes,
Chris Travers