[
https://issues.apache.org/jira/browse/OFBIZ-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589930#action_12589930
]
Jacopo Cappellato commented on OFBIZ-1599:
------------------------------------------
That's great.
To summarize: in order to implement the above solution, we will have to
implement a new service that, given an orderId will retrieve all the
OrderAdjustments for SALES_TAXES and will sum and approximate them by tax
auth/tax geo. The list of amounts will be returned as an OUT parameter together
with the total.
This new service will be used in several places, including:
1) the service that computes the order grand total: wi will have to change it
so that it gets the total for taxes by calling the new service
2) the gl posting service, to get the (summarized) acctg transaction for sales
taxes
> Issues with tax adjustment precision (3 decimals) and AcctgTransEntry.amount
> field (2 decimal)
> ----------------------------------------------------------------------------------------------
>
> Key: OFBIZ-1599
> URL: https://issues.apache.org/jira/browse/OFBIZ-1599
> Project: OFBiz
> Issue Type: Sub-task
> Components: accounting
> Reporter: Jacopo Cappellato
>
> On Jan 7, 2008, at 10:17 PM, Scott Gray wrote:
> > Perhaps we need to do 2 things:
> > 1. Summarize AcctgTransEntries so that you have one entry per TaxAuthority
> > rather than for each tax adjustment
> > 2. During order/invoice processing, calc and final should be applied on a
> > per TaxAuthority basis, so that we are only ever collecting final rounded
> > amounts for each tax authority.
> >
> > So for example if we have invoice with the following adjustments:
> > (I just made these numbers up, they don't relate to any percentages)
> > UT_TAXMAN - $4.311
> > UT_TAXMAN - $7.397
> > UT_UTAH_TAXMAN - $5.643
> > UT_UTAH_TAXMAN - $16.828
> >
> > Tax final would be calculated like this:
> > UT_TAXMAN - $4.311 + $7.399 = $11.71 (2dp)
> > UT_UTAH_TAXMAN - $5.643 + $16.828 = $22.47 (2dp)
> > Tax Total = $11.71 + $22.47 = $34.18
> >
> > Then the AcctgTransEntries would be:
> > UT_TAXMAN = $11.71
> > UT_UTAH_TAXMAN = $22.47
> >
> > Regards
> > Scott
> >
> >
> > On 08/01/2008, David E Jones <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >> On Jan 7, 2008, at 11:04 AM, Scott Gray wrote:
> >>
> >>> Hi Jacopo
> >>>
> >>> My understanding of calc and final:
> >>> calc - adjustment level rounding
> >>> final - the sum of all tax adjustments (tax total) is rounded to this
> >>> precision
> >>>
> >>> Perhaps AcctgTransEntry.amount needs to store to a higher precision
> >>> as well?
> >>
> >> What Scott says above is correct as I understand it, but I'm not sure
> >> this last part is a good idea.
> >>
> >> Accounting/GL transactions are meant to be final and to avoid problems
> >> they are structured in a way where reporting just involves adding
> >> things up and using straight totals with no rounding, etc to avoid any
> >> biasing (with the exception of certain averages and such, but that is
> >> different as precision on those is used in a different way).
> >>
> >> It seems to me that posting anything to an accounting with more than 2
> >> decimals of precision seems like a bad idea to me, except perhaps the
> >> infamous "rounding remainder" accounts. We should probably consult
> >> with an accounting before doing much of that sort of thing, but of
> >> course if we do change the AcctgTransEntry.amount to be higher
> >> precision we can always configure/code around it.
> >>
> >> -David
> >>
> >>
> >>> On 08/01/2008, Jacopo Cappellato <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>> While testing the GL accounting transactions I've found something
> >>>> that
> >>>> could be an issue in the procedure that computes the sales tax
> >>>> adjustment for the invoice.
> >>>> I've noticed that the InvoiceItem.amount for sales tax contains
> >>>> sometimes a number with 3 decimals, even if the arithmetic.properties
> >>>> file we have:
> >>>>
> >>>> salestax.calc.decimals = 3
> >>>> salestax.final.decimals = 2
> >>>> salestax.rounding = ROUND_HALF_UP
> >>>>
> >>>> You can recreate this by creating and invoicing a sales order for 3
> >>>> units of GZ-1000.
> >>>>
> >>>> For example, look at this invoice:
> >>>>
> >>>>
> >>>>
> >> https://demo.hotwaxmedia.com/accounting/control/invoiceOverview?invoiceId=CI1
> >>>>
> >>>> Having 3 decimals is an issue for the gl auto posting service for
> >>>> sales
> >>>> invoices because the sales tax item generates an AcctgTransEntry, but
> >>>> the AcctgTransEntry.amount field can only store 2 decimals.
> >>>>
> >>>> I'd appreciate suggestions/hints.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Jacopo
> >>>>
> >>
> >>
> >>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
