Hi Jacopo
I've attached the patch
I haven't really looked at Leon's solution but I believe it's a different
approach.
Regards
Scott
On 22/05/07, Jacopo Cappellato <[EMAIL PROTECTED]> wrote:
Scott,
do you have a patch for this? I'm sorry but I can't find it.
Is the solution proposed by Leon
Scott,
do you have a patch for this? I'm sorry but I can't find it.
Is the solution proposed by Leon different from your?
https://issues.apache.org/jira/browse/OFBIZ-1007
Jacopo
David E Jones wrote:
I think it is good for now. The result will be more complaints about
digits existing that s
I think it is good for now. The result will be more complaints about digits
existing that shouldn't be there, which is great because that will expose the
places where rounding should be done but isn't being done.
-David
Jacopo Cappellato wrote:
David, Scott, all,
is it ok to commit Scott'
Jacopo,
Obviously I'm a +1 for the trunk, but it is important to note that even if
this doesn't go into 4.0 something similar will need to be implemented so
that invoice item tax can be displayed to 3 decimal places. For the record
I would prefer it if this went into 4.0 as well
Regards
Scott
David, Scott, all,
is it ok to commit Scott's patch only in the trunk (not in the release
branch) as a temporary change to help us to figure out all the areas
where rounding needs to be fixes?
Jacopo
David E Jones wrote:
It's a good point... we shouldn't need to round in the UI because wha
+1 to David and Jacopo's solution.
When the quantity is huge, 10 decimals may not be enough.
Shi Jinghai/Beijing Langhua Ltd.
在 2007-05-09三的 09:20 +0200，Jacopo Cappellato写道：
> I would say to display unrounded (by the ui) numbers everywhere in the
> trunk version, to help us to spot out hidden
I would say to display unrounded (by the ui) numbers everywhere in the
trunk version, to help us to spot out hidden issues; and leave things as
they are now in the release branch.
Jacopo
David E Jones wrote:
It's a good point... we shouldn't need to round in the UI because what
is undernea
It's a good point... we shouldn't need to round in the UI because what is
underneath should have things rounded in advance.
What do others think? Should we display full values everywhere, or selectively,
or perhaps just in the Entity Data Maint stuff in WebTools, or something else?
-David
S
Do we really want to commit this patch, and have OFBiz display all currency
values with 10 decimal figures?
My opinion is: definitely no.
If we want to display more decimal digits in certain places we should add an
optional attribute/parameter to the transform and then specify it explicitly i
Hi David
The reason I wanted to do get rid of the ui performing any rounding was that
I couldn't see why it was necessary when it is the responsibility of the
logic supplying the numbers to make sure they are correct in the first
place.
If for some strange reason an order total is being worked o
Hi Jacopo
I'm more than happy to re implement the solution based on your (and anyone
else's) advice, what did you have in mind?
The only other solution I could see was to round one of Peter's tax items up
and the other down, but I wasn't particularly comfortable with that idea.
Regards
Scott
O
Scott,
I agree with you that (at least in the trunk) it is a good idea to
display numbers as they are stored in the db, with no rounding in the ui.
After a very quick review to rev. 535415, I have some doubts about some
of the design decisions (especially the change in the entity definition)
b
Scott Gray wrote:
...
And yes I did get paid (tax free, for the moment at least) :-)
That's great. I'd like to thank Peter (and I'm sure I'm not alone) for
his sponsorship that helped to fix this issue... and of course also
thank Scott.
Jacopo
I've committed the changes in rev. 535415
As I mentioned above, someone with framework commit privileges needs to look
at the rounding of displayed currency. I've attached a patch with the
changes I think are needed. If it doesn't see any action in the short term
I'll throw it in the jira.
Reg
I had planned on working the patch in this weekend, I just need to clean it
up a bit.
One thing I need a framework guy to look at is the rounding currency
formatting in widgets and the freemarker transform, I think we need to set
the default to something like 10 decimal places instead of the curr
Yes,
and, Scott, did you get your 500$ ? :-)
Jacopo
David E Jones wrote:
Scott,
Did this ever make it into OFBiz? I only reviewed it briefly, but if it
is fixing this problem then it would be great to have it in the ofbiz
trunk.
-David
Message-
From: Scott Gray [mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>]
Sent: 28 April 2007 05:56
To: user@ofbiz.apache.org <mailto:user@ofbiz.apache.org>
Subject: Re: Will Pay US$500 for a Solution to a basic tax
calculation issue
From looking at the
MAIL PROTECTED]
Subject: Re: Will Pay US$500 for a Solution to a basic tax calculation issue
Hi Peter
I've attached a patch file which should address the issues for your problem
calculation. You will need to download the latest revision of Ofbiz (not
opentaps) and apply the patch. Make su
Hey Scott,
it seems you have won the 500$ prize!
Peter, is it tax included? ;-)
Jacopo
Scott Gray wrote:
Hi Peter
I've attached a patch file which should address the issues for your
problem calculation. You will need to download the latest revision of
Ofbiz (not opentaps) and apply the pat
ginal Message-
From: Scott Gray [mailto:[EMAIL PROTECTED]
Sent: 28 April 2007 05:56
To: user@ofbiz.apache.org
Subject: Re: Will Pay US$500 for a Solution to a basic tax calculation
issue
From looking at the code, the tax is always calculated and rounded to 2
decimal places for each order (and
To: user@ofbiz.apache.org
Subject: Re: Will Pay US$500 for a Solution to a basic tax calculation issue
>From looking at the code, the tax is always calculated and rounded to 2
decimal places for each order (and invoice) line, so there is no way to get
a grand total of $91.04 regardless of what
This is something that needs to be fixed. One of the requirements
that I modeled with the TaxAuthority stuff was a common VAT
requirement of calculating tax to 3 decimals for each item/line in an
order and then summing it all, and then rounding it to 2 decimals.
It sounds like this has st
From looking at the code, the tax is always calculated and rounded to 2
decimal places for each order (and invoice) line, so there is no way to get
a grand total of $91.04 regardless of what settings you place in
arithmetic.properties.
Your only solution would be to refactor quite of lot of code
For those interested in Peter's challenge, IIRC, his total was ending
up at 91.03 or 91.05, depending on the arithmetic rules. he is
expecting 91.04. If someone could verify the following behavior, you
may claim his prize :) . (I don't have time at the moment to actually
dig for this occurrence,
Hi,
Ofbiz must be capable of calculating tax or vat correctly (the term vat is
used in the UK to describe tax on goods, tax at a rate of 17.5%).
TO BE CLEAR;
THE CALCULATION OF TAX IS THE PROBLEM.
THE CALCULATION OF PRODUCTS IS CORRECT.
'arithmetic.properties' is the file I have been working
25 matches
Mail list logo
