You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Evangelina Bowman <eb...@idalica.com> on 2008/02/14 00:09:36 UTC
Re: Rounding problem
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 <rr...@iguanait.com> 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 <rr...@iguanait.com> 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.
Re: Rounding problem
Posted by Jacopo Cappellato <ti...@sastau.it>.
Evangelina,
thanks for your report; this is probably a known issue:
https://issues.apache.org/jira/browse/OFBIZ-1599
The solution proposed by Scott should solve it but unfortunately it is
still not implemented.
Jacopo
Evangelina Bowman wrote:
> 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 <rr...@iguanait.com> 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 <rr...@iguanait.com> 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.
>>> >
>>> >
>>>
>>>
>>
>>
>
Re: Rounding problem
Posted by Jacques Le Roux <ja...@les7arts.com>.
It seems that the work stopped because David suggested to consult an accountant before...
Jacques
From: "Scott Gray" <le...@gmail.com>
>I do intend to do this if no one else does, unfortunately time is not on my
> side at the moment.
>
> Regards
> Scott
>
> On 14/02/2008, Rashko Rejmer <rr...@iguanait.com> wrote:
>>
>> Hi Evangelina,
>>
>> Thread that may help you:
>> http://ofbiz.markmail.org/message/72j6aakesmglucrs?q=jacopo+gl+posting
>>
>> Regards,
>> Rashko Rejmer
>>
>> On Wed, 2008-02-13 at 15:09 -0800, Evangelina Bowman wrote:
>> > 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 <rr...@iguanait.com> 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 <rr...@iguanait.com> 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.
>> > >> >
>> > >> >
>> > >>
>> > >>
>> > >
>> > >
>> > >
>> >
>>
>>
>
Re: Rounding problem
Posted by Scott Gray <le...@gmail.com>.
I do intend to do this if no one else does, unfortunately time is not on my
side at the moment.
Regards
Scott
On 14/02/2008, Rashko Rejmer <rr...@iguanait.com> wrote:
>
> Hi Evangelina,
>
> Thread that may help you:
> http://ofbiz.markmail.org/message/72j6aakesmglucrs?q=jacopo+gl+posting
>
> Regards,
> Rashko Rejmer
>
> On Wed, 2008-02-13 at 15:09 -0800, Evangelina Bowman wrote:
> > 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 <rr...@iguanait.com> 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 <rr...@iguanait.com> 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.
> > >> >
> > >> >
> > >>
> > >>
> > >
> > >
> > >
> >
>
>
Re: Rounding problem
Posted by Rashko Rejmer <rr...@iguanait.com>.
Hi Evangelina,
Thread that may help you:
http://ofbiz.markmail.org/message/72j6aakesmglucrs?q=jacopo+gl+posting
Regards,
Rashko Rejmer
On Wed, 2008-02-13 at 15:09 -0800, Evangelina Bowman wrote:
> 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 <rr...@iguanait.com> 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 <rr...@iguanait.com> 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.
> >> >
> >> >
> >>
> >>
> >
> >
> >
>