On 3/29/22 5:14 PM, John Ralls wrote:
On Mar 29, 2022, at 10:33 AM, Adrien Monteleone
<adrien.montele...@lusfiber.net> wrote:
The report should simply print the data from the invoice unchanged.
Be careful what you ask for. The data from the invoice is a rational number,
meaning a numerator and a denominator. The print routine will print that as an
integer plus a fraction. Remember all of the complaining a few years ago when
the price editor showed numbers like 123 + 45/6789? Do you *really* want your
invoices to look like that?
Oops, yeah, I was making assumptions and shouldn't do that, certainly
without investigating. (but then I'd already understand how the number
is stored)
Or were you thinking "unchanged" means in decimal form but with no rounding? So
if you have say 1/3 your printer keeps printing pages full of '3' until it runs out of
paper? ;-)
As I mentioned in IRC, the 'view' of the invoice retains the precision
'as entered' but the Invoice Report mangles it. To me, that's the bug. A
user would reasonable expect a printed version of a 'view' to be the
same data-wise as the view itself.
At the very least, the info should not be so altered as to render it
incorrect, or at least certainly un-helpful (such as rounding/truncating
to '0.00' when that is false)
Of course, there are understandable physical screen/paper limits to
displaying or printing rational numbers. (if someone uses π, ϕ, √2, or
e, they're own their own!)
There's a preference for force prices to decimal. If that's set then prices
displayed in the Price Database window and the register are rounded to 1/100th
of the smallest currency unit in which the price is denominated. For most
currencies that's two decimal places so prices are displayed with four. The
same could be applied to invoices and other reports.
I'd think amounts on invoices should be in some integer multiple of the
commodity's smallest fraction traded--that's a property of the commodity that
you set in the New/Edit Security dialog--and should display as a decimal with
the appropriate number of places if the fraction's denominator is a power of 10
or a rational number if not.
Does that seem reasonable?
It doesn't affect it now, but that would be reasonable at least for
prices. And if someone is really intent on 4 decimal precision for a
quantity, perhaps their answer is to rethink the base unit of the
invoice item. (one could argue that should be the answer here too I suppose)
The bug I filed isn't about these questions though. It is that this
already is not much of a problem in the Invoice 'view', but that this
same info is mangled as it makes its way to a printable report.
Regards,
Adrien
_______________________________________________
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.
