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 > >> > > >
