OFBiz
  1. OFBiz
  2. OFBIZ-1434 General Ledger
  3. OFBIZ-1599

Issues with tax adjustment precision (3 decimals) and AcctgTransEntry.amount field (2 decimal)

    Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: Trunk
    • Component/s: accounting
    • Labels:
      None

      Description

      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 <jonesde@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 <tiz@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
      >>>>
      >>
      >>
      >>

      1. Issue_1599.patch
        19 kB
        Sumit Pandit
      2. Issue_1599.patch
        19 kB
        Jacques Le Roux
      3. Issue_1599.patch
        19 kB
        Jacques Le Roux
      4. Issue_1599.patch
        19 kB
        Jacques Le Roux
      5. Issue_1599.patch
        21 kB
        Jacques Le Roux

        Issue Links

          Activity

          No work has yet been logged on this issue.

            People

            • Assignee:
              Jacques Le Roux
              Reporter:
              Jacopo Cappellato
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development