ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BJ Freeman <bjf...@free-man.net>
Subject Re: Need help to figure out an issue with sales tax decimals in InvoiceItem
Date Mon, 07 Jan 2008 15:40:57 GMT
I believe the best solution is to step back and make some high level
design decisions having to do with math.

I believe a complete path map of processes first needs to be generated
to see when the "final" figure is done. for instance when an invoice is
sent.

It may be time to refactor where the calculations are done to get a
invoice "final" figure so the Accounting will flow properly.

Testing should be run to make sure the "Final" figure, matches when two
different processes do the calculation.

Jacopo Cappellato sent the following on 1/7/2008 6:14 AM:
> 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
> 
> 
> 


Mime
View raw message