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, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] Sent: 16 April 2007 18:04 To: [email protected]; [EMAIL PROTECTED] Subject: Re: The Return of...Inaccurate Calculation of Order Hi Peter, You need to restart OFBiz, not just clear the cache. Hope that helps. --- [EMAIL PROTECTED] wrote:http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/ config/aritHi, 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, [EMAIL PROTECTED] < [EMAIL PROTECTED]> 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: [EMAIL PROTECTED] Sent: 05 April 2007 01:16 To: [email protected]; [EMAIL PROTECTED] Subject: Re: Inaccurate Calculation of Order Here is the configuration file, you can change the settings to whatever you want them to be: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, [EMAIL PROTECTED] < [EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] Sent: 05 April 2007 00:11 To: '[email protected] ' 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 ===
smime.p7s
Description: S/MIME cryptographic signature
