Scott Yes, it would. What I was wondering however was whether it was best to change the definition of both currency-precise (to NUMERIC(18,4) and currency-amount (to NUMERIC(18,3)), or instead, modify each of the data definitions for OrderItem, OrderItemBilling, and InventoryItem individually and change the affected fields (amount and such) to be currency-precise.
I tried the former (changing the currency-amount definition) and it seems to work ok. I will then however have to redo a complete alpha test to be sure nothing unexpected happens. On the bright side, BigDecimal rounding does not seem to be an issue. On the other hand, I am worried that I might miss a data definition that won't show up until a beta test with the customer next week. Skip -----Original Message----- From: Scott Gray [mailto:[EMAIL PROTECTED] Sent: Monday, April 21, 2008 5:51 PM To: [email protected] Subject: Re: Rounding Errors currency-precise should solve the problem Regards Scott On 22/04/2008, BJ Freeman <[EMAIL PROTECTED]> wrote: > > there has been discussion about this. > the consensus as I remember it was leave rounding to the last. > this mean mapping flow to find the final end point where this is going > to be rounded. > This I would think would be in the Accounting module. so the GL will > balance. > > > [EMAIL PROTECTED] sent the following on 4/21/2008 5:23 PM: > > > I am importing orders (and writing them from scratch) with item costs at > > three decimal digits. I have changed order.decimals to 3. > > > > However, I end up with amounts like .466 truncated to .46 > > > > I looked at OrderItem and OrderItemBilling definitions and amount is a > > currency-amount which is defined as NUMERIC(18,2) > > > > I am wondering what is the best way to solve this problem. I am > thinking of > > changing the schema for OrderItem and OrderItemBilling to be > floating-point. > > I could also change the fieldtypepostgres.xml to be > NUMERIC(18,3). However, > > I only want the sold item prices to be three decimal digits, and not the > > totals and so forth. > > > > Anyone have any advice? > > > > Skip > > No virus found in this outgoing message. > > Checked by AVG. > > Version: 7.5.524 / Virus Database: 269.23.0/1381 - Release Date: > 4/16/2008 > > 9:34 AM > > > > > > > > > > No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.0/1381 - Release Date: 4/16/2008 9:34 AM No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.0/1381 - Release Date: 4/16/2008 9:34 AM
