Details

Type: Subtask

Status: Closed

Priority: 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 GZ1000.
>>>>
>>>> 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
>>>>
>>
>>
>>
Issue Links
 is related to

OFBIZ2702 Rounding error(?) prohibits posting
 Closed
 relates to

OFBIZ1579 Price Rule for a Sale Price creates a USD price with 3 decimal instead of 2
 Closed
I have some doubts about the solution suggested by Scott and I'd like to get some feedback.
I will try to clarify the context with an example
Enter a sales order for the customer "DemoCustomer" for 20 units of WG1111.
Check out the order.
Go to Webtools>Entity Data Maintenance>OrderAdjustemnt and filter by orderId and orderAdjustmentTypeId="SALES_TAX"
The sales taxes adjustments will look like the following ones:
Tax Geo and Authority  order item seq id  amount
=====================================================
Utah County / Sales Tax  NA  0.096
Utah County / Sales Tax  00001  0.960
Utah State / Sales Tax  00001  45.592
NA / NA  00001  9.598
Apart from the weird taxes, what it is interesting to note is that we have one order header adjustments (the first one) and a few order item adjustments. Also note that taxes are approximated to 3 decimals
Following Scott's suggestion (if I am interpreting it in the right way) we will have taxes summed up by the same Tax Geo and Authority:
Utah County / Sales Tax  0.864
Utah State / Sales Tax  45.592
NA / NA  9.598
and then we approximate them to 2 decimals (I'm approximating using round half up, but this is just an example):
Utah County / Sales Tax  0.86
Utah State / Sales Tax  45.59
NA / NA  9.60
The final result is that, starting from a set of order header and order item tax adjustments we have transformed them in a set of order header tax adjustment, one for each tax geo and authority.
These are the numbers that will be posted into the GL.
My main question is: when do we do this calculation? In the service that generates the accounting transaction or in the order/invoice (when the adjustments are stored in the db)?
If we do this only in the service that generate the accounting transaction the problem is that there will be differences between the amount s in gl and the numbers in orders, invoices and payments.
If we do this in the order and invoice the problem that I see is that we loose the ability to associate the tax adjustments to the order items (that is a very important feature, in my opinion).