[jira] [Updated] (OFBIZ-1599) Issues with tax adjustment precision (3 decimals) and AcctgTransEntry.amount field (2 decimal)

["Ingo Wolfmayr (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OFBIZ-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ingo Wolfmayr updated OFBIZ-1599:
---------------------------------
    Attachment: PriceService.patch

> 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
>            Assignee: Jacques Le Roux
>             Fix For: Trunk
>
>         Attachments: Issue_1599.patch, Issue_1599.patch, Issue_1599.patch, Issue_1599.patch, Issue_1599.patch, PriceService.patch
>
>
> 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 <jo...@hotwaxmedia.com> 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 <ti...@sastau.it> 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 was sent by Atlassian JIRA
(v6.3.4#6332)