You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by David E Jones <jo...@hotwaxmedia.com> on 2007/05/04 20:46:58 UTC
Re: Will Pay US$500 for a Solution to a basic tax calculation issue
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
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 patch. Make sure you do this before
> running "ant run-install" as there is a small change to the data model.
>
> Regards
> Scott
>
> On 29/04/07, *peter@ec4b.com <ma...@ec4b.com>* <peter@ec4b.com
> <ma...@ec4b.com>> wrote:
>
> Hi,
>
>
> Well that is indeed what needs to be done because, currently the
> fact of the
> matter is that the figure is not worked out correctly.
>
> See David's response.
>
>
> Thanks & Regards,
>
> Peter
>
>
> -----Original Message-----
> From: Scott Gray [mailto: lektran@gmail.com <ma...@gmail.com>]
> Sent: 28 April 2007 05:56
> To: user@ofbiz.apache.org <ma...@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 settings you place in
> arithmetic.properties.
>
> Your only solution would be to refactor quite of lot of code to support
> calculating tax on the final taxable subtotal.
>
> Regards
> Scott
>
> On 28/04/07, Chris Howe <cjhowe76013@yahoo.com
> <ma...@yahoo.com>> wrote:
> >
> > 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, but if someone wanted to share, I wouldn't
> > complain...i wouldn't complain if they didn't want to share
> either ;-)
> > )
> >
> > Since math is rather straight forward (assuming this is all
> > bigdecimal), there are only a few scenarios that can exist to give
> > these numbers.
> >
> > ::91.03::
> > Tax line item
> > round lineItemTax to two significant digits
> > Add each lineItemTax
> >
> > ::91.05::
> > Tax line item
> > round lineItemTax to three significant digits
> > add lineItemTax to line Item
> > round lineItemTotal to two significant digits
> > sum lineItemTotals
> >
> >
> > Applying the rules from 91.05 to two significant digits, you will get
> > the 91.03 as well.
> >
> > The expected summation is as follows:
> > Tax line item
> > round lineItemTax to x significant digits.
> > sum all lineItemTax
> > add lineItemTaxTotal to lineItemTotal
> > round to two significant digits (cents)
> > This will produce the expected 91.04
> >
> >
> > --- peter@ec4b.com <ma...@ec4b.com> wrote:
> >
> > > 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 with.
> > > Essentially
> > > there are three parameters I have looked at that control the
> rounding
> > > and
> > > length of decimals used with regards to calculation of tax or vat.
> > >
> > > salestax.calc.decimals = 3
> > > salestax.final.decimals = 2
> > > salestax.rounding = ROUND_HALF_UP
> > >
> > > It is safe to say that I have tried every combination of 'Big
> > > Decimal'
> > > rounding field types and 'decimals' length (for
> > > salestax.calc.decimals and
> > > salestax.final.decimals) without any success!
> > >
> > > I have of course been stopping and restarting the server after
> each
> > > change
> > > to reload the file at startup. Even tried some crazy wild figures
> > > just to
> > > ensure that I was getting a different figure, to ensure the process
> > > works.
> > >
> > > Therefore, there must be other files that also have some bearing on
> > > this
> > > calculation. Does anyone know what other files maybe relevant?
> > >
> > >
> > > VERY HAPPY TO PAY SOMEONE 'US$500' for a solution at this
> point. On
> > > condition that the solution actually works and produces the figures
> > > below,
> > > only one payment to the first working model will be paid;
> > >
> > > -------------------------------------------------
> > > price tax product+tax
> > > -------------------------------------------------
> > > Product1 35.74 6.2545 41.995
> > > Product2 35.74 6.2545 41.995
> > > -------------------------------------------------
> > > Product Total 71.48
> > > Shipping 6.00 1.050 7.050
> > > Tax (17.5%) 13.56 13.559
> > > -------------------------------------------------
> > > Grand Total 91.04 91.039
> > > -------------------------------------------------
> > >
> > >
> > > Let's see if someone can prove to me that Ofbiz is capable of
> > > calculating
> > > vat correctly. Had this issue open is various threads for around a
> > > month.
> > >
> > >
> > >
> > > Thanks & Regards,
> > >
> > > Peter
> > >
> > >
> > > -----Original Message-----
> > > From: Scott Gray [mailto:lektran@gmail.com
> <ma...@gmail.com>]
> > > Sent: 18 April 2007 10:50
> > > To: user@ofbiz.apache.org <ma...@ofbiz.apache.org>
> > > Subject: Re: Doesn't calculate tax correctly...Inaccurate
> Calculation
> > > of
> > > Order Total
> > >
> > > Hi Peter
> > >
> > > Did you try what I suggested?
> > >
> > > >Change this line:
> > > >salestax.calc.decimals = 10
> > > >and see if that gives you the results you are expecting.
> > >
> > > Regards
> > > Scott
> > >
> > > On 18/04/07, peter@ec4b.com <ma...@ec4b.com>
> <peter@ec4b.com <ma...@ec4b.com>> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Actually 91.04 is what i need as a result, but i can't seem
> to get
> > > Ofbiz
> > > > to reproduce this result. Technically right now Ofbiz is not
> > > calculating
> > > it
> > > > correctly. I have tried most permatations of the big decimal
> class
> > > and a
> > > > varying the digit length and mostly get 91.03 or 91.05.
> > > >
> > > > Surely, Ofbiz must be able to calculate the tax (at 17.5%)
> > > correctly, it
> > > > is such a basic requirement.
> > > >
> > > > I must be overlooking something. Anyone, can you help.
> > > >
> > > >
> > > > Thanks & Regards,
> > > >
> > > > Peter.
> > > >
> > > >
> > > > - original message -
> > > > Subject: Re: The Return of...Inaccurate Calculation of
> Order
> > > > From: "BJ Freeman" < bjfree@free-man.net
> <ma...@free-man.net>>
> > > > Date: 18/04/2007 02:19
> > > >
> > > > if I read this right
> > > > Grand Total 91.04 91.039
> > > > so if you round to two places on 91.039 you get 91.04
> > > > which means they equal.
> > > >
> > > > peter@ec4b.com <ma...@ec4b.com> sent the following on
> 4/17/2007 4:00 PM:
> > > > > Hi,
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > There is something very odd about the way Ofbiz calculates tax
> > > (in the
> > > > order
> > > > > manager).
> > > > >
> > > > >
> > > > >
> > > > > Using this model from Excel;
> > > > >
> > > > > US$ price tax p+tax
> > > > >
> > > > > Product1 35.74 6.2545 41.995
> > > > >
> > > > > Product2 35.74 6.2545 41.995
> > > > >
> > > > > Shipping 6.00 1.050 7.050
> > > > >
> > > > > Total 77.48 (3 digit)
> > > > >
> > > > > Tax 13.56 13.559
> > > > >
> > > > > -------------------------------------------------
> > > > >
> > > > > Grand Total 91.04 91.039
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Method1 gives 91.05
> > > > >
> > > > > Method2 gives 91.03
> > > > >
> > > > >
> > > > >
> > > > > Tried each of the different big-decimal rounding scheme,
> not give
> > > the
> > > > value
> > > > > I was expecting (91.04). I get either 91.03 or 91.05
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >>From the arithmetic.properties file;
> > > > >
> > > > >
> > > > >
> > > > > METHOD1
> > > > >
> > > > > # Most companies would want their sales tax calculations
> ALWAYS
> > > to round
> > > > up
> > > > > (ie, 100.081 becomes 100.09)
> > > > >
> > > > > # This could be ROUND_CEILING or ROUND_UP. (The difference is
> > > that
> > > > > ROUND_CEILING rounds towards positive infinity,
> > > > >
> > > > > # ROUND_UP away from zero. So, for 1.13, both ROUND_UP and
> > > > ROUND_CEILING
> > > > > will round to 1.2, but for -1.13,
> > > > >
> > > > > # ROUND_UP gives you -1.2 and ROUND_CEILING -1.1.)
> > > > >
> > > > > salestax.calc.decimals = 2
> > > > >
> > > > > salestax.final.decimals = 2
> > > > >
> > > > > salestax.rounding = ROUND_HALF_UP
> > >
> > === message truncated ===
> >
> >
>
>
Re: Suppress roundings in the ui WAS [Re: Will Pay US$500 for a Solution to a basic tax calculation issue]
Posted by Scott Gray <le...@gmail.com>.
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 <ti...@sastau.it> wrote:
>
> 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 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'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
> >>> 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
> >>>
> >>>
> >>> Scott Gray wrote:
> >>>> 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 out to
> >>>> $97.3459 do
> >>>> we want the ui to hide that from us?
> >>>>
> >>>> Initially I created a patch to allow us to specify the decimal
> >>>> places using
> >>>> ofbizCurrencyTransform in ftl's (
> >>>> https://issues.apache.org/jira/browse/OFBIZ-939) but then I started
> >>>> wondering why we need the ui to do any rounding for us.
> >>>>
> >>>> Regards
> >>>> Scott
> >>>>
> >>>> On 09/05/07, David E Jones <jo...@hotwaxmedia.com> wrote:
> >>>>>
> >>>>>
> >>>>> 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 in certain spots, like 3 or 4 or based on db data number
> of
> >>>>> digits.
> >>>>>
> >>>>> -David
> >>>>>
> >>>>>
> >>>>> Scott Gray wrote:
> >>>>> > 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.
> >>>>> >
> >>>>> > Regards
> >>>>> > Scott
> >>>>> >
> >>>>> > On 05/05/07, *Scott Gray* <lektran@gmail.com
> >>>>> <ma...@gmail.com>>
> >>>>> > wrote:
> >>>>> >
> >>>>> > 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 currency's default. That way any rounding problems aren't
> >>>>> > hidden by the display code and it also allows us to display
> tax
> >>>>> > items to 3 decimal places (or whatever the
> >>>>> arithmetic.properties has
> >>>>> > set).
> >>>>> >
> >>>>> > Also, salestax.calc.decimals is a bit of misnomer considering
> >>>>> the
> >>>>> > best we can do when storing intermediate tax is
> >>>>> currency-precise at
> >>>>> > 3 decimal places.
> >>>>> >
> >>>>> > And yes I did get paid (tax free, for the moment at least) :-)
> >>>>> >
> >>>>> > Regards
> >>>>> > Scott
> >>>>> >
> >>>>> >
> >>>>> > On 05/05/07, *Jacopo Cappellato* < tiz@sastau.it
> >>>>> > <ma...@sastau.it>> wrote:
> >>>>> >
> >>>>> > 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
> >>>>> > >
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>>
> >>>>
> >>
>
>
>
Re: Suppress roundings in the ui WAS [Re: Will Pay US$500 for a Solution to a basic tax calculation issue]
Posted by Scott Gray <le...@gmail.com>.
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
On 21/05/07, Jacopo Cappellato <ti...@sastau.it> wrote:
>
> 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 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
> >
> >
> > Scott Gray wrote:
> >> 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 out to
> >> $97.3459 do
> >> we want the ui to hide that from us?
> >>
> >> Initially I created a patch to allow us to specify the decimal places
> >> using
> >> ofbizCurrencyTransform in ftl's (
> >> https://issues.apache.org/jira/browse/OFBIZ-939) but then I started
> >> wondering why we need the ui to do any rounding for us.
> >>
> >> Regards
> >> Scott
> >>
> >> On 09/05/07, David E Jones <jo...@hotwaxmedia.com> wrote:
> >>>
> >>>
> >>> 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 in certain spots, like 3 or 4 or based on db data number of
> >>> digits.
> >>>
> >>> -David
> >>>
> >>>
> >>> Scott Gray wrote:
> >>> > 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.
> >>> >
> >>> > Regards
> >>> > Scott
> >>> >
> >>> > On 05/05/07, *Scott Gray* <lektran@gmail.com
> >>> <ma...@gmail.com>>
> >>> > wrote:
> >>> >
> >>> > 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 currency's default. That way any rounding problems aren't
> >>> > hidden by the display code and it also allows us to display tax
> >>> > items to 3 decimal places (or whatever the
> >>> arithmetic.properties has
> >>> > set).
> >>> >
> >>> > Also, salestax.calc.decimals is a bit of misnomer considering
> the
> >>> > best we can do when storing intermediate tax is
> >>> currency-precise at
> >>> > 3 decimal places.
> >>> >
> >>> > And yes I did get paid (tax free, for the moment at least) :-)
> >>> >
> >>> > Regards
> >>> > Scott
> >>> >
> >>> >
> >>> > On 05/05/07, *Jacopo Cappellato* < tiz@sastau.it
> >>> > <ma...@sastau.it>> wrote:
> >>> >
> >>> > 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
> >>> > >
> >>> >
> >>> >
> >>> >
> >>>
> >>
>
>
>
Re: Will Pay US$500 for a Solution to a basic tax calculation issue
Posted by Shi Jinghai <sh...@langhua.cn>.
+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 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 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
> >
> >
> > Scott Gray wrote:
> >> 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 out to
> >> $97.3459 do
> >> we want the ui to hide that from us?
> >>
> >> Initially I created a patch to allow us to specify the decimal places
> >> using
> >> ofbizCurrencyTransform in ftl's (
> >> https://issues.apache.org/jira/browse/OFBIZ-939) but then I started
> >> wondering why we need the ui to do any rounding for us.
> >>
> >> Regards
> >> Scott
> >>
> >> On 09/05/07, David E Jones <jo...@hotwaxmedia.com> wrote:
> >>>
> >>>
> >>> 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 in certain spots, like 3 or 4 or based on db data number of
> >>> digits.
> >>>
> >>> -David
> >>>
> >>>
> >>> Scott Gray wrote:
> >>> > 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.
> >>> >
> >>> > Regards
> >>> > Scott
> >>> >
> >>> > On 05/05/07, *Scott Gray* <lektran@gmail.com
> >>> <ma...@gmail.com>>
> >>> > wrote:
> >>> >
> >>> > 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 currency's default. That way any rounding problems aren't
> >>> > hidden by the display code and it also allows us to display tax
> >>> > items to 3 decimal places (or whatever the
> >>> arithmetic.properties has
> >>> > set).
> >>> >
> >>> > Also, salestax.calc.decimals is a bit of misnomer considering the
> >>> > best we can do when storing intermediate tax is
> >>> currency-precise at
> >>> > 3 decimal places.
> >>> >
> >>> > And yes I did get paid (tax free, for the moment at least) :-)
> >>> >
> >>> > Regards
> >>> > Scott
> >>> >
> >>> >
> >>> > On 05/05/07, *Jacopo Cappellato* < tiz@sastau.it
> >>> > <ma...@sastau.it>> wrote:
> >>> >
> >>> > 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
> >>> > >
> >>> >
> >>> >
> >>> >
> >>>
> >>
>
>
Re: Will Pay US$500 for a Solution to a basic tax calculation issue
Posted by Jacopo Cappellato <ti...@sastau.it>.
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 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
>
>
> Scott Gray wrote:
>> 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 out to
>> $97.3459 do
>> we want the ui to hide that from us?
>>
>> Initially I created a patch to allow us to specify the decimal places
>> using
>> ofbizCurrencyTransform in ftl's (
>> https://issues.apache.org/jira/browse/OFBIZ-939) but then I started
>> wondering why we need the ui to do any rounding for us.
>>
>> Regards
>> Scott
>>
>> On 09/05/07, David E Jones <jo...@hotwaxmedia.com> wrote:
>>>
>>>
>>> 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 in certain spots, like 3 or 4 or based on db data number of
>>> digits.
>>>
>>> -David
>>>
>>>
>>> Scott Gray wrote:
>>> > 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.
>>> >
>>> > Regards
>>> > Scott
>>> >
>>> > On 05/05/07, *Scott Gray* <lektran@gmail.com
>>> <ma...@gmail.com>>
>>> > wrote:
>>> >
>>> > 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 currency's default. That way any rounding problems aren't
>>> > hidden by the display code and it also allows us to display tax
>>> > items to 3 decimal places (or whatever the
>>> arithmetic.properties has
>>> > set).
>>> >
>>> > Also, salestax.calc.decimals is a bit of misnomer considering the
>>> > best we can do when storing intermediate tax is
>>> currency-precise at
>>> > 3 decimal places.
>>> >
>>> > And yes I did get paid (tax free, for the moment at least) :-)
>>> >
>>> > Regards
>>> > Scott
>>> >
>>> >
>>> > On 05/05/07, *Jacopo Cappellato* < tiz@sastau.it
>>> > <ma...@sastau.it>> wrote:
>>> >
>>> > 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
>>> > >
>>> >
>>> >
>>> >
>>>
>>
Re: Suppress roundings in the ui WAS [Re: Will Pay US$500 for a Solution
to a basic tax calculation issue]
Posted by Jacopo Cappellato <ti...@sastau.it>.
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 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'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
>>> 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
>>>
>>>
>>> Scott Gray wrote:
>>>> 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 out to
>>>> $97.3459 do
>>>> we want the ui to hide that from us?
>>>>
>>>> Initially I created a patch to allow us to specify the decimal
>>>> places using
>>>> ofbizCurrencyTransform in ftl's (
>>>> https://issues.apache.org/jira/browse/OFBIZ-939) but then I started
>>>> wondering why we need the ui to do any rounding for us.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 09/05/07, David E Jones <jo...@hotwaxmedia.com> wrote:
>>>>>
>>>>>
>>>>> 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 in certain spots, like 3 or 4 or based on db data number of
>>>>> digits.
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> Scott Gray wrote:
>>>>> > 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.
>>>>> >
>>>>> > Regards
>>>>> > Scott
>>>>> >
>>>>> > On 05/05/07, *Scott Gray* <lektran@gmail.com
>>>>> <ma...@gmail.com>>
>>>>> > wrote:
>>>>> >
>>>>> > 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 currency's default. That way any rounding problems aren't
>>>>> > hidden by the display code and it also allows us to display tax
>>>>> > items to 3 decimal places (or whatever the
>>>>> arithmetic.properties has
>>>>> > set).
>>>>> >
>>>>> > Also, salestax.calc.decimals is a bit of misnomer considering
>>>>> the
>>>>> > best we can do when storing intermediate tax is
>>>>> currency-precise at
>>>>> > 3 decimal places.
>>>>> >
>>>>> > And yes I did get paid (tax free, for the moment at least) :-)
>>>>> >
>>>>> > Regards
>>>>> > Scott
>>>>> >
>>>>> >
>>>>> > On 05/05/07, *Jacopo Cappellato* < tiz@sastau.it
>>>>> > <ma...@sastau.it>> wrote:
>>>>> >
>>>>> > 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
>>>>> > >
>>>>> >
>>>>> >
>>>>> >
>>>>>
>>>>
>>
Re: Suppress roundings in the ui WAS [Re: Will Pay US$500 for a Solution
to a basic tax calculation issue]
Posted by David E Jones <jo...@hotwaxmedia.com>.
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'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 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
>>
>>
>> Scott Gray wrote:
>>> 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 out to
>>> $97.3459 do
>>> we want the ui to hide that from us?
>>>
>>> Initially I created a patch to allow us to specify the decimal places
>>> using
>>> ofbizCurrencyTransform in ftl's (
>>> https://issues.apache.org/jira/browse/OFBIZ-939) but then I started
>>> wondering why we need the ui to do any rounding for us.
>>>
>>> Regards
>>> Scott
>>>
>>> On 09/05/07, David E Jones <jo...@hotwaxmedia.com> wrote:
>>>>
>>>>
>>>> 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 in certain spots, like 3 or 4 or based on db data number of
>>>> digits.
>>>>
>>>> -David
>>>>
>>>>
>>>> Scott Gray wrote:
>>>> > 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.
>>>> >
>>>> > Regards
>>>> > Scott
>>>> >
>>>> > On 05/05/07, *Scott Gray* <lektran@gmail.com
>>>> <ma...@gmail.com>>
>>>> > wrote:
>>>> >
>>>> > 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 currency's default. That way any rounding problems aren't
>>>> > hidden by the display code and it also allows us to display tax
>>>> > items to 3 decimal places (or whatever the
>>>> arithmetic.properties has
>>>> > set).
>>>> >
>>>> > Also, salestax.calc.decimals is a bit of misnomer considering the
>>>> > best we can do when storing intermediate tax is
>>>> currency-precise at
>>>> > 3 decimal places.
>>>> >
>>>> > And yes I did get paid (tax free, for the moment at least) :-)
>>>> >
>>>> > Regards
>>>> > Scott
>>>> >
>>>> >
>>>> > On 05/05/07, *Jacopo Cappellato* < tiz@sastau.it
>>>> > <ma...@sastau.it>> wrote:
>>>> >
>>>> > 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
>>>> > >
>>>> >
>>>> >
>>>> >
>>>>
>>>
>
>
Suppress roundings in the ui WAS [Re: Will Pay US$500 for a Solution
to a basic tax calculation issue]
Posted by Jacopo Cappellato <ti...@sastau.it>.
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 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
>
>
> Scott Gray wrote:
>> 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 out to
>> $97.3459 do
>> we want the ui to hide that from us?
>>
>> Initially I created a patch to allow us to specify the decimal places
>> using
>> ofbizCurrencyTransform in ftl's (
>> https://issues.apache.org/jira/browse/OFBIZ-939) but then I started
>> wondering why we need the ui to do any rounding for us.
>>
>> Regards
>> Scott
>>
>> On 09/05/07, David E Jones <jo...@hotwaxmedia.com> wrote:
>>>
>>>
>>> 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 in certain spots, like 3 or 4 or based on db data number of
>>> digits.
>>>
>>> -David
>>>
>>>
>>> Scott Gray wrote:
>>> > 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.
>>> >
>>> > Regards
>>> > Scott
>>> >
>>> > On 05/05/07, *Scott Gray* <lektran@gmail.com
>>> <ma...@gmail.com>>
>>> > wrote:
>>> >
>>> > 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 currency's default. That way any rounding problems aren't
>>> > hidden by the display code and it also allows us to display tax
>>> > items to 3 decimal places (or whatever the
>>> arithmetic.properties has
>>> > set).
>>> >
>>> > Also, salestax.calc.decimals is a bit of misnomer considering the
>>> > best we can do when storing intermediate tax is
>>> currency-precise at
>>> > 3 decimal places.
>>> >
>>> > And yes I did get paid (tax free, for the moment at least) :-)
>>> >
>>> > Regards
>>> > Scott
>>> >
>>> >
>>> > On 05/05/07, *Jacopo Cappellato* < tiz@sastau.it
>>> > <ma...@sastau.it>> wrote:
>>> >
>>> > 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
>>> > >
>>> >
>>> >
>>> >
>>>
>>
Re: Will Pay US$500 for a Solution to a basic tax calculation issue
Posted by David E Jones <jo...@hotwaxmedia.com>.
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
Scott Gray wrote:
> 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 out to
> $97.3459 do
> we want the ui to hide that from us?
>
> Initially I created a patch to allow us to specify the decimal places using
> ofbizCurrencyTransform in ftl's (
> https://issues.apache.org/jira/browse/OFBIZ-939) but then I started
> wondering why we need the ui to do any rounding for us.
>
> Regards
> Scott
>
> On 09/05/07, David E Jones <jo...@hotwaxmedia.com> wrote:
>>
>>
>> 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 in certain spots, like 3 or 4 or based on db data number of
>> digits.
>>
>> -David
>>
>>
>> Scott Gray wrote:
>> > 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.
>> >
>> > Regards
>> > Scott
>> >
>> > On 05/05/07, *Scott Gray* <lektran@gmail.com
>> <ma...@gmail.com>>
>> > wrote:
>> >
>> > 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 currency's default. That way any rounding problems aren't
>> > hidden by the display code and it also allows us to display tax
>> > items to 3 decimal places (or whatever the arithmetic.properties
>> has
>> > set).
>> >
>> > Also, salestax.calc.decimals is a bit of misnomer considering the
>> > best we can do when storing intermediate tax is currency-precise at
>> > 3 decimal places.
>> >
>> > And yes I did get paid (tax free, for the moment at least) :-)
>> >
>> > Regards
>> > Scott
>> >
>> >
>> > On 05/05/07, *Jacopo Cappellato* < tiz@sastau.it
>> > <ma...@sastau.it>> wrote:
>> >
>> > 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
>> > >
>> >
>> >
>> >
>>
>
Re: Will Pay US$500 for a Solution to a basic tax calculation issue
Posted by Scott Gray <le...@gmail.com>.
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 out to $97.3459 do
we want the ui to hide that from us?
Initially I created a patch to allow us to specify the decimal places using
ofbizCurrencyTransform in ftl's (
https://issues.apache.org/jira/browse/OFBIZ-939) but then I started
wondering why we need the ui to do any rounding for us.
Regards
Scott
On 09/05/07, David E Jones <jo...@hotwaxmedia.com> wrote:
>
>
> 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 in certain spots, like 3 or 4 or based on db data number of
> digits.
>
> -David
>
>
> Scott Gray wrote:
> > 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.
> >
> > Regards
> > Scott
> >
> > On 05/05/07, *Scott Gray* <lektran@gmail.com <ma...@gmail.com>>
> > wrote:
> >
> > 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 currency's default. That way any rounding problems aren't
> > hidden by the display code and it also allows us to display tax
> > items to 3 decimal places (or whatever the arithmetic.properties has
> > set).
> >
> > Also, salestax.calc.decimals is a bit of misnomer considering the
> > best we can do when storing intermediate tax is currency-precise at
> > 3 decimal places.
> >
> > And yes I did get paid (tax free, for the moment at least) :-)
> >
> > Regards
> > Scott
> >
> >
> > On 05/05/07, *Jacopo Cappellato* < tiz@sastau.it
> > <ma...@sastau.it>> wrote:
> >
> > 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
> > >
> >
> >
> >
>
Re: Will Pay US$500 for a Solution to a basic tax calculation issue
Posted by David E Jones <jo...@hotwaxmedia.com>.
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 in certain spots, like 3 or 4 or based on db data number of digits.
-David
Scott Gray wrote:
> 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.
>
> Regards
> Scott
>
> On 05/05/07, *Scott Gray* <lektran@gmail.com <ma...@gmail.com>>
> wrote:
>
> 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 currency's default. That way any rounding problems aren't
> hidden by the display code and it also allows us to display tax
> items to 3 decimal places (or whatever the arithmetic.properties has
> set).
>
> Also, salestax.calc.decimals is a bit of misnomer considering the
> best we can do when storing intermediate tax is currency-precise at
> 3 decimal places.
>
> And yes I did get paid (tax free, for the moment at least) :-)
>
> Regards
> Scott
>
>
> On 05/05/07, *Jacopo Cappellato* < tiz@sastau.it
> <ma...@sastau.it>> wrote:
>
> 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
> >
>
>
>
Re: Will Pay US$500 for a Solution to a basic tax calculation issue
Posted by Jacopo Cappellato <ti...@sastau.it>.
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)
but all in all I think it is good to have the patch in, we should now
start from there to discuss about how to completely resolve the rounding
issues in OFBiz and the pros and cons of using currency-precise fields.
Thanks for your work,
Jacopo
Scott Gray wrote:
> 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.
>
> Regards
> Scott
>
Re: Will Pay US$500 for a Solution to a basic tax calculation issue
Posted by Scott Gray <le...@gmail.com>.
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.
Regards
Scott
On 05/05/07, Scott Gray <le...@gmail.com> wrote:
>
> 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 currency's
> default. That way any rounding problems aren't hidden by the display code
> and it also allows us to display tax items to 3 decimal places (or whatever
> the arithmetic.properties has set).
>
> Also, salestax.calc.decimals is a bit of misnomer considering the best we
> can do when storing intermediate tax is currency-precise at 3 decimal
> places.
>
> And yes I did get paid (tax free, for the moment at least) :-)
>
> Regards
> Scott
>
> On 05/05/07, Jacopo Cappellato <ti...@sastau.it> wrote:
> >
> > 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
> > >
> >
>
>
Re: Will Pay US$500 for a Solution to a basic tax calculation issue
Posted by Jacopo Cappellato <ti...@sastau.it>.
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
Re: Will Pay US$500 for a Solution to a basic tax calculation issue
Posted by Scott Gray <le...@gmail.com>.
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 currency's
default. That way any rounding problems aren't hidden by the display code
and it also allows us to display tax items to 3 decimal places (or whatever
the arithmetic.properties has set).
Also, salestax.calc.decimals is a bit of misnomer considering the best we
can do when storing intermediate tax is currency-precise at 3 decimal
places.
And yes I did get paid (tax free, for the moment at least) :-)
Regards
Scott
On 05/05/07, Jacopo Cappellato <ti...@sastau.it> wrote:
>
> 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
> >
>
Re: Will Pay US$500 for a Solution to a basic tax calculation issue
Posted by Jacopo Cappellato <ti...@sastau.it>.
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
>