Hello Scott and Rashko, I'm having the same issue with the rounding of the taxes. This is affecting my GL postings. My total debit amount (Accounts Receivable for $30.35) does not match my total credit (Sales of $27.98 plus sales tax of $2.36 = $30.34). I'm off by a penny. The GL transaction does not post since debits and credits must match.
Thanks, Evangelina Bowman Rashko Rejmer wrote: > > Skott, > > I think that you are right. > I was investigating Order total and order components(Items SubTotal, > Total Other Order Adjustments, Total Shipping and Handling, Total Sales > Tax) rounding. > > When order tax adjustments are calculated they are rounded for every > item. > Exactly what you provided > - 6.497 + 1.04 = 7.537 (rounded 7.54) > - 4.997 (rounded 5.00) > I saw your commit that changed that - r602011 > > but when order grand total is calculated then tax adjustments are > rounded together > - 6.497 + 1.04 + 4.997 = 12.534 (12.53) > this is performed in OrderReadHelper.getOrderItemsTotal > > I was willing to check also how ShoppingCart.getGrandTotal calculates > order total before order creation. > > About the second problem I also think that it is impossible to solve it > in usual way. > When invoice total is calculated, the tax items are calculated > separately and rounded after that, so the rounding that was made in the > order(on the order item basis) is lost. > On the other side(exactly what you said) if the order is invoiced to few > invoices then there will be situations when the tax roundings will be > inaccurate. > I very loved your idea about additional adjustment to the invoice that > will correct the final amount. Can somebody give me some suggestions how > to implement that? > > I will continue with investigation. > > Regards, > Rashko Rejmer > > On Fri, 2007-12-07 at 19:10 +1300, Scott Gray wrote: >> Hi Rashko >> >> There seems to be 2 issues going on here, one can be fixed the other >> can't. >> >> The order total is correct at 188.75 but the tax total is incorrect: >> 4.997 + 6.497 + 1.04 = 12.534 (rounded 12.53) not 12.54 >> That can be fixed, I'll commit it shortly. >> >> The other issue is that the order is then split into 2 invoices: >> Tax on invoice #1: 6.497 + 1.04 = 7.537 (rounded 7.54) >> Tax on invoice #2: 4.997 (rounded 5.00) >> Total tax for both invoices = 12.54 as opposed to the order tax total >> which should be 12.53 >> This one I have no idea how to fix, whenever you split a single order >> into multiple invoices there is always the potential for this to >> happen because the tax is rounded more often (once for each invoice as >> opposed to once for the entire order). >> The only option I can see is to incorrectly round the tax (or create >> some sort of tax adjustment) on the invoices so that they stay in sync >> with the order total. >> >> What do you think? >> >> Regards >> Scott >> >> On 07/12/2007, Rashko Rejmer <[EMAIL PROTECTED]> wrote: >> Hi Scott, >> >> The problem occurs in very very specific orders. Here are the >> EXACT >> steps: >> Start creating order with DemoCustCompany party >> Add to cart >> - GZ-1000 x 5 >> - GZ-1001 x 5 >> >> Then create 2 ship groups for the order - for each of the ship >> groups >> chose the second shipping address(US-CA) of the >> DemoCustCompany party >> Then move to the second shipping group one of the items >> GZ-1000 or >> GZ-1001. >> Then use shipment method for the first shipping group - "UPS >> Guaranteed >> Next Day - $10.70" and for the second shipping group "No >> shipping" >> Pay the order with whatever you want(but use only ONE payment >> method). >> Do NOT add any additional parties. >> Create the order. >> The total amount of the order should be 188.75(this is with >> clean copy >> of ofbiz, after run install).If this is the third order you >> create with >> this party then you might get different grand total, because >> the promos >> are over and there aren`t any more of them. >> >> Then "Quick ship entire order". >> >> The sum of the two invoices is 188.76 but the order grand >> total is >> 188.75 >> >> I created example on the demo server - order WSCO10009 with >> invoices >> CI7, CI8 >> >> >> https://demo.hotwaxmedia.com/ordermgr/control/orderview?orderId=WSCO10009 >> >> I will be glad to hear your opinion about this situation. >> I have investigated this very deeply and I have idea why this >> is >> happening but I wanted first to know if this is a bug or not. >> >> Rashko Rejmer >> >> >> On Fri, 2007-12-07 at 07:43 +1300, Scott Gray wrote: >> > Hi Rashko >> > >> > I think you'll find it's some sort of rounding error in the >> order code >> > which will need to be tracked down. If you don't have time >> to look, >> > could you provide some steps to possibly reproduce on a demo >> install >> > and I'll take a look when I get a chance. >> > >> > Thanks >> > Scott >> > >> > On 07/12/2007, Rashko Rejmer <[EMAIL PROTECTED]> wrote: >> > I wanted to ask about weird situation that I >> noticed. >> > I created an order and at the order view screen I >> noticed that >> > there is >> > difference between the order grand total and the >> components of >> > the order >> > >> > Items SubTotal = >> $183.91 >> > Total Other Order Adjustments = -$18.39 >> > Total Shipping and Handling = $10.70 >> > Total Sales Tax = $12.54 >> > Sum is $188.76 >> > __________________________________________ >> > Total Due >> = >> > $188.75 >> > >> > The difference is of 0.01$ >> > Firsth i thought that there is no big problem but >> then i >> > created 2 >> > difference invoices for this order and the sum of >> the invoices >> > was also >> > $188.76 >> > I think that this difference is because of different >> concepts >> > for >> > invoice and order rounding. >> > I wanted to ask if this is normal and how OFBiz is >> supposed to >> > handle >> > that kind of rounding problems. >> > >> > >> >> > > > -- View this message in context: http://www.nabble.com/Rounding-problem-tp14194542p15470233.html Sent from the OFBiz - User mailing list archive at Nabble.com.
