The Return of...Inaccurate Calculation of Order
Locked
The Return of...Inaccurate Calculation of Order
 
|
Re: The Return of...Inaccurate Calculation of Order
|
|
RE: The Return of...Inaccurate Calculation of Order
|
|
Re: The Return of...Inaccurate Calculation of Order
|
|
He means - kill the process - and then restart it. Shut it down and start it up.
Cheers, Tim -- Tim Ruppert HotWax Media o:801.649.6594 f:801.649.6595 On Apr 16, 2007, at 12:02 PM, <[hidden email]> <[hidden email]> wrote:
|
smime.p7s (3K)
RE: The Return of...Inaccurate Calculation of Order
|
|
Re: The Return of...Inaccurate Calculation of Order
|
|
Re: The Return of...Inaccurate Calculation of Order
|
|
RE: The Return of...Inaccurate Calculation of Order
|
|
Re: The Return of...Inaccurate Calculation of Order
|
|
Peter, Sorry it took me so long to take a peek at this... My guess is that the calculation process is not what you are expected, namely in terms of when the rounding is done and such. In order to spot exactly what is going on we need to see exactly how you are doing your calculations to check the numbers. This goes back to the common questions we need answers to in order to understand a bug report, namely: 1. what did you expect to happen? 2. what happened? 3. how was it different than what you expected? What we need in order for this discussion to make progress and not continue to flounder, and to see if and what the problem might be, is to describe this step by step. To really check things I'd also recommend using a hand calculator to reproduce the steps and then you'll have more control over what is happening. My guess is that the lack of helpful replies stems from the fact that there are insufficient details here to spot what might be going wrong. In other words, something like: 0: start 35.74: add product price of 35.74 41.9945: add tax of 6.2545 41.995: round to three digits using ROUNG_HALF_UP method Also, instead of using arbitrary numbers, please use something that is in OFBiz itself so that people reviewing this can test it for themselves and see what is happening. The best way to do this is to describe a set of steps on demo.hotwaxmedia.com, which is just a stock demo of OFBiz with the demo data in place and that is updated daily. -David On Apr 18, 2007, at 2:33 PM, <[hidden email]> <[hidden email]> wrote: > Hi, > > > I have tried 10 digits, exact same problem. > > salestax.calc.decimals = 10 > > > Can anyone offer some assistance. > > > Thanks & Regards, > > Peter > > ________________________________________ > From: Scott Gray [mailto:[hidden email]] > Sent: 18 April 2007 01:27 > To: [hidden email]; [hidden email] > Subject: Re: The Return of...Inaccurate Calculation of Order > > Peter > > Change this line: > salestax.calc.decimals = 10 > and see if that gives you the results you are expecting. > > Regards > Scott > On 18/04/07, [hidden email] <[hidden email]> wrote: > 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 > > > > METHOD2 > > # 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 = 3 > > salestax.final.decimals = 2 > > salestax.rounding = ROUND_HALF_UP > > > > > > Thanks & Regards, > > > > Peter > > > > _____ > > From: Tim Ruppert [mailto:[hidden email]] > Sent: 16 April 2007 19:06 > To: [hidden email] > Cc: 'Chris Howe' > Subject: Re: The Return of...Inaccurate Calculation of Order > > > > He means - kill the process - and then restart it. Shut it down and > start it > > up. > > > > > > Cheers, > > Tim > > -- > > Tim Ruppert > > HotWax Media > > http://www.hotwaxmedia.com > > > > o:801.649.6594 > > f:801.649.6595 > > > > > > > > On Apr 16, 2007, at 12:02 PM, <[hidden email]> <[hidden email]> wrote: > > > > > > Hi Chris, > > > > > > Thanks very much for your quick response. > > > > Exactly do you mean by 'restart ofbiz', by your definition? > > > > > > Thanks & Regards, > > > > Peter > > > > -----Original Message----- > > From: Chris Howe [mailto:[hidden email]] > > Sent: 16 April 2007 18:04 > > To: [hidden email] ; [hidden email] > > Subject: Re: The Return of...Inaccurate Calculation of Order > > > > Hi Peter, > > > > You need to restart OFBiz, not just clear the cache. Hope that helps. > > > > > > --- [hidden email] wrote: > > > > Hi, > > > > > > Sure hope you can help with this, I have been going around in > > circles. > > > > I am having a problem with the way that Ofbiz calculates tax and > > order > > totals. > > > > From what I can gather, the file > > './applications/accounting/config/arithmetic.properties' controls the > > rounding and digit length for the calculation of taxes & order > > totals. > > > > I am starting to think the changes I make to the file are not being > > applied, > > I say this because when I look at the 'Unit Price' in an order it > > shows > > 35.742, rather than 35.74. Which would tend to indicate that settings > > are > > not being used because the number of decimal points in each of the > > settings > > in 'arithmetic.properties ' are set to 2 digits. I have pasted in the > > contents of the 'arithmetic.properties' file below so you can have a > > look. I > > have changed the 'rounding' to a different method to try to achieve > > the > > correct figures. > > > > There is only a disparity of +0.1 but, technically it is wrong. Ofbiz > > keeps > > giving me a total of 91.05, but it should be 91.04. I am been given a > > hard > > time about it... > > > > Essentially; > > > > Using Excel; > > US$ 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 > > > > Simply put, I think that the problem is a combination of two issues; > > (i). Ofbiz uses 3 digits, not 2 digits (I would like to use 2 > > digits). > > and > > (ii). Uses rounding 'ROUND_HALF_UP', I would tend to use > > 'ROUND_HALF_DOWN'. > > I think the ' arithmetic.properties' file below, should do the trick. > > But it > > doesn't seem to being 'applied' to the calculation. > > > > > > So I have two Questions; > > > > 1). (BIGGEST ISSUE) Do I have to 'activate' the > > 'arithmetic.properties' > > file, and if so how do I do that? (All I have been doing is clearing > > the > > cache and logging out then logging in again, as I had been told this > > is the > > way to do it). > > 2). Do you see my point about 94.05 and 94.04, and the best way to > > make this > > calculation? > > > > > > ---CONTENTS OF--- > > > > .../Ofbiz/trunk/applications/accounting/config/arithmetic.properties > > > > > > # > > # Arithmetic properties for configuring BigDecimal calculations > > # > > > > # For setting decimal precision and rounding method of operations > > related to > > invoices > > invoice.decimals = 2 > > invoice.rounding = ROUND_HALF_DOWN > > > > # For setting decimal precision and rounding method of operations > > related to > > orders, > > # such as shopping cart amounts and order amounts > > order.decimals = 2 > > order.rounding = ROUND_HALF_DOWN > > > > # For setting decimal precision and rounding method of operations > > related to > > customer accounts > > # such as Financial Accounts > > finaccount.decimals = 2 > > finaccount.rounding = ROUND_HALF_DOWN > > > > # 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_DOWN > > > > > > > > Thanks & Regards, > > > > Peter > > > > > > ________________________________________ > > > > On 05/04/07, [hidden email] < [hidden email]> wrote: > > Hi Scott, > > > > > > Just strikes me that the file should be 'correct' for everyone. What > > would > > be your guidance as to what the file should be? > > > > Appreciate your fast responses this evening. It is 1:15am here in the > > UK > > just can't stay awake any more. > > > > > > Thanks & Regards, > > > > Peter > > > > > > > > ________________________________________ > > From: Scott Gray [mailto: [hidden email]] > > Sent: 05 April 2007 01:16 > > To: [hidden email]; [hidden email] > > > > Subject: Re: Inaccurate Calculation of Order > > > > Here is the configuration file, you can change the settings to > > whatever you > > want them to be: > > > > http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/ > config/arit > > > hmetic.properties?view=markup > > > > From the default settings, it looks like calculation takes place at 3 > > digits > > then gets rounded up to 2 places. > > > > Regards > > Scott > > On 05/04/07, [hidden email] < [hidden email]> wrote: > > Hi, > > > > > > There must be something we are missing here. This can't be a bug, > > someone > > would have noticed already. Especially something so fundimental. > > > > > > Thanks & Regards, > > > > Peter > > > > > > -----Original Message----- > > From: [hidden email] [mailto: [hidden email]] > > Sent: 05 April 2007 00:11 > > To: '[hidden email] ' > > Subject: RE: Inaccurate Calculation of Order > > Importance: High > > > > Hi, > > > > > > Whichever way I work it out the Order Entry system does seem to be > > slightly > > out. > > > > > > From Excel... > > > > Price tax 2 digits tax 3 digits tax 9 > > digits > > > > Product 1 35.74 6.25 6.255 > > 6.254500000 > > Product 2 35.74 6.25 6.255 > > 6.254500000 > > shipping 6 1.05 1.050 > > > > === message truncated === > > > > > > |
RE: The Return of...Inaccurate Calculation of Order
|
|
Re: The Return of...Inaccurate Calculation of Order
|
|
In reply to this post by David E Jones
It's been an hour and a half since you sent that message... It is very rare that questions are answered that quickly. I'd also recommend being WAY WAY WAY more specific. I can't emphasize that enough. Saying that the problem is with tax calculation was helpful, and may be the key to your question (ie most of the other stuff you said was totally misleading if that really is the problem). Hopefully I or someone can answer your most recent question soon. I would still recommend, as I did in my email below, that you list steps to reproduce for out of the box OFBiz with demo data, or use demo.hotwaxmedia.com as I mentioned. That makes it WAY easier for people to see exactly what you're talking about, with only a little effort on your part. Remember it's 100% about communication, and because OFBiz is such a big system you need to be very specific. -David On Apr 18, 2007, at 5:15 PM, <[hidden email]> wrote: > Hi David, > > > Please find attached my response, don't seem to be getting any > response from > the userlist. Can you help? > > > Thanks & Regards, > > Peter > > > -----Original Message----- > From: David E. Jones [mailto:[hidden email]] > Sent: 18 April 2007 22:12 > To: [hidden email] > Subject: Re: The Return of...Inaccurate Calculation of Order > > > Peter, > > Sorry it took me so long to take a peek at this... > > My guess is that the calculation process is not what you are > expected, namely in terms of when the rounding is done and such. > > In order to spot exactly what is going on we need to see exactly how > you are doing your calculations to check the numbers. This goes back > to the common questions we need answers to in order to understand a > bug report, namely: > > 1. what did you expect to happen? > 2. what happened? > 3. how was it different than what you expected? > > What we need in order for this discussion to make progress and not > continue to flounder, and to see if and what the problem might be, is > to describe this step by step. To really check things I'd also > recommend using a hand calculator to reproduce the steps and then > you'll have more control over what is happening. > > My guess is that the lack of helpful replies stems from the fact that > there are insufficient details here to spot what might be going wrong. > > In other words, something like: > > 0: start > 35.74: add product price of 35.74 > 41.9945: add tax of 6.2545 > 41.995: round to three digits using ROUNG_HALF_UP method > > Also, instead of using arbitrary numbers, please use something that > is in OFBiz itself so that people reviewing this can test it for > themselves and see what is happening. The best way to do this is to > describe a set of steps on demo.hotwaxmedia.com, which is just a > stock demo of OFBiz with the demo data in place and that is updated > daily. > > -David > > > > On Apr 18, 2007, at 2:33 PM, <[hidden email]> <[hidden email]> wrote: > >> Hi, >> >> >> I have tried 10 digits, exact same problem. >> >> salestax.calc.decimals = 10 >> >> >> Can anyone offer some assistance. >> >> >> Thanks & Regards, >> >> Peter >> >> ________________________________________ >> From: Scott Gray [mailto:[hidden email]] >> Sent: 18 April 2007 01:27 >> To: [hidden email]; [hidden email] >> Subject: Re: The Return of...Inaccurate Calculation of Order >> >> Peter >> >> Change this line: >> salestax.calc.decimals = 10 >> and see if that gives you the results you are expecting. >> >> Regards >> Scott >> On 18/04/07, [hidden email] <[hidden email]> wrote: >> 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 >> >> >> >> METHOD2 >> >> # 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 = 3 >> >> salestax.final.decimals = 2 >> >> salestax.rounding = ROUND_HALF_UP >> >> >> >> >> >> Thanks & Regards, >> >> >> >> Peter >> >> >> >> _____ >> >> From: Tim Ruppert [mailto:[hidden email]] >> Sent: 16 April 2007 19:06 >> To: [hidden email] >> Cc: 'Chris Howe' >> Subject: Re: The Return of...Inaccurate Calculation of Order >> >> >> >> He means - kill the process - and then restart it. Shut it down and >> start it >> >> up. >> >> >> >> >> >> Cheers, >> >> Tim >> >> -- >> >> Tim Ruppert >> >> HotWax Media >> >> http://www.hotwaxmedia.com >> >> >> >> o:801.649.6594 >> >> f:801.649.6595 >> >> >> >> >> >> >> >> On Apr 16, 2007, at 12:02 PM, <[hidden email]> <[hidden email]> >> wrote: >> >> >> >> >> >> Hi Chris, >> >> >> >> >> >> Thanks very much for your quick response. >> >> >> >> Exactly do you mean by 'restart ofbiz', by your definition? >> >> >> >> >> >> Thanks & Regards, >> >> >> >> Peter >> >> >> >> -----Original Message----- >> >> From: Chris Howe [mailto:[hidden email]] >> >> Sent: 16 April 2007 18:04 >> >> To: [hidden email] ; [hidden email] >> >> Subject: Re: The Return of...Inaccurate Calculation of Order >> >> >> >> Hi Peter, >> >> >> >> You need to restart OFBiz, not just clear the cache. Hope that helps. >> >> >> >> >> >> --- [hidden email] wrote: >> >> >> >> Hi, >> >> >> >> >> >> Sure hope you can help with this, I have been going around in >> >> circles. >> >> >> >> I am having a problem with the way that Ofbiz calculates tax and >> >> order >> >> totals. >> >> >> >> From what I can gather, the file >> >> './applications/accounting/config/arithmetic.properties' controls the >> >> rounding and digit length for the calculation of taxes & order >> >> totals. >> >> >> >> I am starting to think the changes I make to the file are not being >> >> applied, >> >> I say this because when I look at the 'Unit Price' in an order it >> >> shows >> >> 35.742, rather than 35.74. Which would tend to indicate that settings >> >> are >> >> not being used because the number of decimal points in each of the >> >> settings >> >> in 'arithmetic.properties ' are set to 2 digits. I have pasted in the >> >> contents of the 'arithmetic.properties' file below so you can have a >> >> look. I >> >> have changed the 'rounding' to a different method to try to achieve >> >> the >> >> correct figures. >> >> >> >> There is only a disparity of +0.1 but, technically it is wrong. Ofbiz >> >> keeps >> >> giving me a total of 91.05, but it should be 91.04. I am been given a >> >> hard >> >> time about it... >> >> >> >> Essentially; >> >> >> >> Using Excel; >> >> US$ 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 >> >> >> >> Simply put, I think that the problem is a combination of two issues; >> >> (i). Ofbiz uses 3 digits, not 2 digits (I would like to use 2 >> >> digits). >> >> and >> >> (ii). Uses rounding 'ROUND_HALF_UP', I would tend to use >> >> 'ROUND_HALF_DOWN'. >> >> I think the ' arithmetic.properties' file below, should do the trick. >> >> But it >> >> doesn't seem to being 'applied' to the calculation. >> >> >> >> >> >> So I have two Questions; >> >> >> >> 1). (BIGGEST ISSUE) Do I have to 'activate' the >> >> 'arithmetic.properties' >> >> file, and if so how do I do that? (All I have been doing is clearing >> >> the >> >> cache and logging out then logging in again, as I had been told this >> >> is the >> >> way to do it). >> >> 2). Do you see my point about 94.05 and 94.04, and the best way to >> >> make this >> >> calculation? >> >> >> >> >> >> ---CONTENTS OF--- >> >> >> >> .../Ofbiz/trunk/applications/accounting/config/arithmetic.properties >> >> >> >> >> >> # >> >> # Arithmetic properties for configuring BigDecimal calculations >> >> # >> >> >> >> # For setting decimal precision and rounding method of operations >> >> related to >> >> invoices >> >> invoice.decimals = 2 >> >> invoice.rounding = ROUND_HALF_DOWN >> >> >> >> # For setting decimal precision and rounding method of operations >> >> related to >> >> orders, >> >> # such as shopping cart amounts and order amounts >> >> order.decimals = 2 >> >> order.rounding = ROUND_HALF_DOWN >> >> >> >> # For setting decimal precision and rounding method of operations >> >> related to >> >> customer accounts >> >> # such as Financial Accounts >> >> finaccount.decimals = 2 >> >> finaccount.rounding = ROUND_HALF_DOWN >> >> >> >> # 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_DOWN >> >> >> >> >> >> >> >> Thanks & Regards, >> >> >> >> Peter >> >> >> >> >> >> ________________________________________ >> >> >> >> On 05/04/07, [hidden email] < [hidden email]> wrote: >> >> Hi Scott, >> >> >> >> >> >> Just strikes me that the file should be 'correct' for everyone. What >> >> would >> >> be your guidance as to what the file should be? >> >> >> >> Appreciate your fast responses this evening. It is 1:15am here in the >> >> UK >> >> just can't stay awake any more. >> >> >> >> >> >> Thanks & Regards, >> >> >> >> Peter >> >> >> >> >> >> >> >> ________________________________________ >> >> From: Scott Gray [mailto: [hidden email]] >> >> Sent: 05 April 2007 01:16 >> >> To: [hidden email]; [hidden email] >> >> >> >> Subject: Re: Inaccurate Calculation of Order >> >> >> >> Here is the configuration file, you can change the settings to >> >> whatever you >> >> want them to be: >> >> >> >> http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/ >> config/arit >> >> >> hmetic.properties?view=markup >> >> >> >> From the default settings, it looks like calculation takes place at 3 >> >> digits >> >> then gets rounded up to 2 places. >> >> >> >> Regards >> >> Scott >> >> On 05/04/07, [hidden email] < [hidden email]> wrote: >> >> Hi, >> >> >> >> >> >> There must be something we are missing here. This can't be a bug, >> >> someone >> >> would have noticed already. Especially something so fundimental. >> >> >> >> >> >> Thanks & Regards, >> >> >> >> Peter >> >> >> >> >> >> -----Original Message----- >> >> From: [hidden email] [mailto: [hidden email]] >> >> Sent: 05 April 2007 00:11 >> >> To: '[hidden email] ' >> >> Subject: RE: Inaccurate Calculation of Order >> >> Importance: High >> >> >> >> Hi, >> >> >> >> >> >> Whichever way I work it out the Order Entry system does seem to be >> >> slightly >> >> out. >> >> >> >> >> >> From Excel... >> >> >> >> Price tax 2 digits tax 3 digits tax 9 >> >> digits >> >> >> >> Product 1 35.74 6.25 6.255 >> >> 6.254500000 >> >> Product 2 35.74 6.25 6.255 >> >> 6.254500000 >> >> shipping 6 1.05 1.050 >> >> >> >> === message truncated === >> >> >> >> >> >> > > > From: <[hidden email]> > Date: April 18, 2007 3:49:49 PM MDT > To: <[hidden email]> > Subject: RE: The Return of...Inaccurate Calculation of Order > Reply-To: <[hidden email]> > > > Hi, > > > Thanks for looking in to this David. > > I have broken this down in to 'What is Actually Happening' and > 'What I Would Like to Happen'. Is this enough detail (see below)? > > It is worth mentioning that the Procuts & Shipping calculations > seem fine, it is the Tax calculations that seem to be the issue. > > > For the following calculations using...'Tax' at a rate of 17.5% > (known as VAT). > > ---------------------------- > ---------------------------- > WHAT IS ACTUALLY HAPPENING > ---------------------------- > ---------------------------- > > 0 : start > 35.74: add product1 price of 35.742 (after a 30% discount) > 35.74: add product2 price of 35.742 (after a 30% discount) > 71.48: Goods Sub Total) > 6.00: Shipping and Handling > 77.48: Total to Charge (Pre-Tax) > > ...order.decimals = 2 > ...order.rounding = ROUND_HALF_UP > > : add tax of 6.26 for Product1 > : add tax of 6.26 for Product2 > : add tax of 1.05 for Shipping > > 13.57: vat(tax) Sub Total > > ...salestax.calc.decimals = 3 > ...salestax.final.decimals = 2 > ...salestax.rounding = ROUND_HALF_UP > > 91.05: Grand Total (This is wrong it should be 91.04) > > > ----------------------------- > ----------------------------- > WHAT I WOULD LIKE TO HAPPEN > ----------------------------- > ----------------------------- > > 0 : start > 35.74: add product1 price of 35.742 (after a 30% discount) > 35.74: add product2 price of 35.742 (after a 30% discount) > 71.48: Goods Sub Total > 6.00: Shipping and Handling > 77.48: Total to Charge (Pre-Tax) > > ...order.decimals = 2 > ...order.rounding = ROUND_HALF_UP > > : add tax of 6.2545 for Product1 > : add tax of 6.2545 for Product2 > : add tax of 1.050 for Shipping > > 13.56: tax Sub Total (at 3 digits...13.559) > > ...salestax.calc.decimals = ? (Need to know what to set this to) > ...salestax.final.decimals = 2 > ...salestax.rounding = ? (Need to know what to set this to) > > 91.04: Grand Total (at 3 digits...91.039) > > > Thanks & Regards, > > Peter > > > -----Original Message----- > From: David E. Jones [mailto:[hidden email]] > Sent: 18 April 2007 22:12 > To: [hidden email] > Subject: Re: The Return of...Inaccurate Calculation of Order > > > Peter, > > Sorry it took me so long to take a peek at this... > > My guess is that the calculation process is not what you are > expected, namely in terms of when the rounding is done and such. > > In order to spot exactly what is going on we need to see exactly how > you are doing your calculations to check the numbers. This goes back > to the common questions we need answers to in order to understand a > bug report, namely: > > 1. what did you expect to happen? > 2. what happened? > 3. how was it different than what you expected? > > What we need in order for this discussion to make progress and not > continue to flounder, and to see if and what the problem might be, is > to describe this step by step. To really check things I'd also > recommend using a hand calculator to reproduce the steps and then > you'll have more control over what is happening. > > My guess is that the lack of helpful replies stems from the fact that > there are insufficient details here to spot what might be going wrong. > > In other words, something like: > > 0: start > 35.74: add product price of 35.74 > 41.9945: add tax of 6.2545 > 41.995: round to three digits using ROUNG_HALF_UP method > > Also, instead of using arbitrary numbers, please use something that > is in OFBiz itself so that people reviewing this can test it for > themselves and see what is happening. The best way to do this is to > describe a set of steps on demo.hotwaxmedia.com, which is just a > stock demo of OFBiz with the demo data in place and that is updated > daily. > > -David > > > > On Apr 18, 2007, at 2:33 PM, <[hidden email]> <[hidden email]> wrote: > > > Hi, > > > > > > I have tried 10 digits, exact same problem. > > > > salestax.calc.decimals = 10 > > > > > > Can anyone offer some assistance. > > > > > > Thanks & Regards, > > > > Peter > > > > ________________________________________ > > From: Scott Gray [mailto:[hidden email]] > > Sent: 18 April 2007 01:27 > > To: [hidden email]; [hidden email] > > Subject: Re: The Return of...Inaccurate Calculation of Order > > > > Peter > > > > Change this line: > > salestax.calc.decimals = 10 > > and see if that gives you the results you are expecting. > > > > Regards > > Scott > > On 18/04/07, [hidden email] <[hidden email]> wrote: > > 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 > > > > > > > > METHOD2 > > > > # 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 = 3 > > > > salestax.final.decimals = 2 > > > > salestax.rounding = ROUND_HALF_UP > > > > > > > > > > > > Thanks & Regards, > > > > > > > > Peter > > > > > > > > _____ > > > > From: Tim Ruppert [mailto:[hidden email]] > > Sent: 16 April 2007 19:06 > > To: [hidden email] > > Cc: 'Chris Howe' > > Subject: Re: The Return of...Inaccurate Calculation of Order > > > > > > > > He means - kill the process - and then restart it. Shut it down and > > start it > > > > up. > > > > > > > > > > > > Cheers, > > > > Tim > > > > -- > > > > Tim Ruppert > > > > HotWax Media > > > > http://www.hotwaxmedia.com > > > > > > > > o:801.649.6594 > > > > f:801.649.6595 > > > > > > > > > > > > > > > > On Apr 16, 2007, at 12:02 PM, <[hidden email]> <[hidden email]> > wrote: > > > > > > > > > > > > Hi Chris, > > > > > > > > > > > > Thanks very much for your quick response. > > > > > > > > Exactly do you mean by 'restart ofbiz', by your definition? > > > > > > > > > > > > Thanks & Regards, > > > > > > > > Peter > > > > > > > > -----Original Message----- > > > > From: Chris Howe [mailto:[hidden email]] > > > > Sent: 16 April 2007 18:04 > > > > To: [hidden email] ; [hidden email] > > > > Subject: Re: The Return of...Inaccurate Calculation of Order > > > > > > > > Hi Peter, > > > > > > > > You need to restart OFBiz, not just clear the cache. Hope that > helps. > > > > > > > > > > > > --- [hidden email] wrote: > > > > > > > > Hi, > > > > > > > > > > > > Sure hope you can help with this, I have been going around in > > > > circles. > > > > > > > > I am having a problem with the way that Ofbiz calculates tax and > > > > order > > > > totals. > > > > > > > > From what I can gather, the file > > > > './applications/accounting/config/arithmetic.properties' controls > the > > > > rounding and digit length for the calculation of taxes & order > > > > totals. > > > > > > > > I am starting to think the changes I make to the file are not being > > > > applied, > > > > I say this because when I look at the 'Unit Price' in an order it > > > > shows > > > > 35.742, rather than 35.74. Which would tend to indicate that > settings > > > > are > > > > not being used because the number of decimal points in each of the > > > > settings > > > > in 'arithmetic.properties ' are set to 2 digits. I have pasted in > the > > > > contents of the 'arithmetic.properties' file below so you can have a > > > > look. I > > > > have changed the 'rounding' to a different method to try to achieve > > > > the > > > > correct figures. > > > > > > > > There is only a disparity of +0.1 but, technically it is wrong. > Ofbiz > > > > keeps > > > > giving me a total of 91.05, but it should be 91.04. I am been > given a > > > > hard > > > > time about it... > > > > > > > > Essentially; > > > > > > > > Using Excel; > > > > US$ 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 > > > > > > > > Simply put, I think that the problem is a combination of two issues; > > > > (i). Ofbiz uses 3 digits, not 2 digits (I would like to use 2 > > > > digits). > > > > and > > > > (ii). Uses rounding 'ROUND_HALF_UP', I would tend to use > > > > 'ROUND_HALF_DOWN'. > > > > I think the ' arithmetic.properties' file below, should do the > trick. > > > > But it > > > > doesn't seem to being 'applied' to the calculation. > > > > > > > > > > > > So I have two Questions; > > > > > > > > 1). (BIGGEST ISSUE) Do I have to 'activate' the > > > > 'arithmetic.properties' > > > > file, and if so how do I do that? (All I have been doing is clearing > > > > the > > > > cache and logging out then logging in again, as I had been told this > > > > is the > > > > way to do it). > > > > 2). Do you see my point about 94.05 and 94.04, and the best way to > > > > make this > > > > calculation? > > > > > > > > > > > > ---CONTENTS OF--- > > > > > > > > .../Ofbiz/trunk/applications/accounting/config/arithmetic.properties > > > > > > > > > > > > # > > > > # Arithmetic properties for configuring BigDecimal calculations > > > > # > > > > > > > > # For setting decimal precision and rounding method of operations > > > > related to > > > > invoices > > > > invoice.decimals = 2 > > > > invoice.rounding = ROUND_HALF_DOWN > > > > > > > > # For setting decimal precision and rounding method of operations > > > > related to > > > > orders, > > > > # such as shopping cart amounts and order amounts > > > > order.decimals = 2 > > > > order.rounding = ROUND_HALF_DOWN > > > > > > > > # For setting decimal precision and rounding method of operations > > > > related to > > > > customer accounts > > > > # such as Financial Accounts > > > > finaccount.decimals = 2 > > > > finaccount.rounding = ROUND_HALF_DOWN > > > > > > > > # 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_DOWN > > > > > > > > > > > > > > > > Thanks & Regards, > > > > > > > > Peter > > > > > > > > > > > > ________________________________________ > > > > > > > > On 05/04/07, [hidden email] < [hidden email]> wrote: > > > > Hi Scott, > > > > > > > > > > > > Just strikes me that the file should be 'correct' for everyone. What > > > > would > > > > be your guidance as to what the file should be? > > > > > > > > Appreciate your fast responses this evening. It is 1:15am here in > the > > > > UK > > > > just can't stay awake any more. > > > > > > > > > > > > Thanks & Regards, > > > > > > > > Peter > > > > > > > > > > > > > > > > ________________________________________ > > > > From: Scott Gray [mailto: [hidden email]] > > > > Sent: 05 April 2007 01:16 > > > > To: [hidden email]; [hidden email] > > > > > > > > Subject: Re: Inaccurate Calculation of Order > > > > > > > > Here is the configuration file, you can change the settings to > > > > whatever you > > > > want them to be: > > > > > > > > http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/ > > config/arit > > > > > > hmetic.properties?view=markup > > > > > > > > From the default settings, it looks like calculation takes place > at 3 > > > > digits > > > > then gets rounded up to 2 places. > > > > > > > > Regards > > > > Scott > > > > On 05/04/07, [hidden email] < [hidden email]> wrote: > > > > Hi, > > > > > > > > > > > > There must be something we are missing here. This can't be a bug, > > > > someone > > > > would have noticed already. Especially something so fundimental. > > > > > > > > > > > > Thanks & Regards, > > > > > > > > Peter > > > > > > > > > > > > -----Original Message----- > > > > From: [hidden email] [mailto: [hidden email]] > > > > Sent: 05 April 2007 00:11 > > > > To: '[hidden email] ' > > > > Subject: RE: Inaccurate Calculation of Order > > > > Importance: High > > > > > > > > Hi, > > > > > > > > > > > > Whichever way I work it out the Order Entry system does seem to be > > > > slightly > > > > out. > > > > > > > > > > > > From Excel... > > > > > > > > Price tax 2 digits tax 3 digits tax 9 > > > > digits > > > > > > > > Product 1 35.74 6.25 6.255 > > > > 6.254500000 > > > > Product 2 35.74 6.25 6.255 > > > > 6.254500000 > > > > shipping 6 1.05 1.050 > > > > > > > > === message truncated === > > > > > > > > > > > > > |
OfBiz newbie - prototyping in OfBiz
|
|
Re: OfBiz newbie - prototyping in OfBiz
Administrator
|
| Free forum by Nabble | Edit this page |