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