ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Carlow (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OFBIZ-494) Support for prices in multiple decimal places
Date Sun, 04 Jan 2015 17:33:34 GMT

    [ https://issues.apache.org/jira/browse/OFBIZ-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14263912#comment-14263912
] 

Christian Carlow commented on OFBIZ-494:
----------------------------------------

I encountered issues with OrderAdjustment.amount as type currency-precise that seems related
to this very old still open issue.  The currency-precise field only allows 3 decimal places
so postgres rounds up if salestax.calc.decimals > 3.  If OrderAdjustment.amount is altered
to numeric(18, 4) the sales tax 0.334600 can be stored precisely.  With the column precision
alteration, a purchase order sales tax gets rounded to 0.33.  Without the alteration the sales
tax is incorrectly rounded to 0.34.

These discussions are related:
http://ofbiz.135035.n4.nabble.com/Dev-currency-amount-vs-currency-precise-vs-floating-point-td167153.html
http://mail-archives.apache.org/mod_mbox/ofbiz-dev/200611.mbox/%3C38B33FA8-1DB2-4A6A-BF01-2DBE0525CBA0@undersunconsulting.com%3E




> Support for prices in multiple decimal places
> ---------------------------------------------
>
>                 Key: OFBIZ-494
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-494
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: order
>            Reporter: Si Chen
>
> Support for order and invoicing with prices in multiple (3, 4, + decimal places).
> At a basic level it can be supported just by modifying OrderItem.unitPrice and other
._Price fields, ReturnItem.unitPrice, and InvoiceItem.amount to currency-precise types and
then changing currency-precise to NUMERIC(18,4) or whatever you need.
> David however also suggested that we then create an Order and Invoice line (and by extension
probably ReturnItem line) total amount in currency-amount so that the rounding behavior is
predictable.  When order/invoice/returns are created those recordes should be updated accordingly.
> Also there is the issue of OrderAdjustment.amount being currency-precise and InvoiceItem.amount
being currency-amount leading to possible 0.01 rounding errors in some cases.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message