[jira] Created: (OFBIZ-3666) Errors attempting to use quantities with more than 2 decimals of precision
Locked
[jira] Created: (OFBIZ-3666) Errors attempting to use quantities with more than 2 decimals of precision
 
|
Errors attempting to use quantities with more than 2 decimals of precision
-------------------------------------------------------------------------- Key: OFBIZ-3666 URL: https://issues.apache.org/jira/browse/OFBIZ-3666 Project: OFBiz Issue Type: Bug Components: order, product Affects Versions: SVN trunk Reporter: Bob Morley Priority: Minor Fix For: SVN trunk We have a need to handle inventory items with quantities up to four decimal places. The data model currently supports 6 decimals so I thought I would try to complete a purchase order, sales order, and a return for an item that has this many digits of precision. What I found was ... - The order item was calculated properly (including the total for the line) but the totals for the entire sales order were incorrect. This was because when OrderReadHelper was getting the OrderItemQuantity as part of calculating the subtotal it would round it to the order's configured scale (2). Since this is being used as a calculation it should not be rounded -- the total itself should be rounded. - In a number of spots in issuance and reservation services values were (sometimes) being rounded. For example, when an order item was created it would create an InventoryItemDetail record that would reduce the ATP by the precise quantity, however when the order was placed the QOH was reduced by the rounded value. All of these issues were the result of the mini-lang calculate element being used which by default uses a scale of 2 decimals (from the dtd). The solution was when working with quantities pass in the precision scale (6) to ensure we do not lose precision. Again, when order totals, taxes, things like that are being done the configured scale should take over, but the intermediate calculations should not be losing precision. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
[jira] Updated: (OFBIZ-3666) Errors attempting to use quantities with more than 2 decimals of precision
|
|
[ https://issues.apache.org/jira/browse/OFBIZ-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Morley updated OFBIZ-3666: ------------------------------ Attachment: OFBIZ-3666_DoNotRoundPreciseQuantity.patch > Errors attempting to use quantities with more than 2 decimals of precision > -------------------------------------------------------------------------- > > Key: OFBIZ-3666 > URL: https://issues.apache.org/jira/browse/OFBIZ-3666 > Project: OFBiz > Issue Type: Bug > Components: order, product > Affects Versions: SVN trunk > Reporter: Bob Morley > Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3666_DoNotRoundPreciseQuantity.patch > > > We have a need to handle inventory items with quantities up to four decimal places. The data model currently supports 6 decimals so I thought I would try to complete a purchase order, sales order, and a return for an item that has this many digits of precision. What I found was ... > - The order item was calculated properly (including the total for the line) but the totals for the entire sales order were incorrect. This was because when OrderReadHelper was getting the OrderItemQuantity as part of calculating the subtotal it would round it to the order's configured scale (2). Since this is being used as a calculation it should not be rounded -- the total itself should be rounded. > - In a number of spots in issuance and reservation services values were (sometimes) being rounded. For example, when an order item was created it would create an InventoryItemDetail record that would reduce the ATP by the precise quantity, however when the order was placed the QOH was reduced by the rounded value. All of these issues were the result of the mini-lang calculate element being used which by default uses a scale of 2 decimals (from the dtd). The solution was when working with quantities pass in the precision scale (6) to ensure we do not lose precision. Again, when order totals, taxes, things like that are being done the configured scale should take over, but the intermediate calculations should not be losing precision. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
[jira] Commented: (OFBIZ-3666) Errors attempting to use quantities with more than 2 decimals of precision
|
|
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855425#action_12855425 ] Adrian Crum commented on OFBIZ-3666: ------------------------------------ Why specify 6 decimals? What if another user needed a different precision? These issues are another example of why we need better data typing. You don't need a calculate element to perform negation: <set field="createDetailMap.availableToPromiseDiff" value="${-parameters.quantityNotIssued?bigDecimal}"/> > Errors attempting to use quantities with more than 2 decimals of precision > -------------------------------------------------------------------------- > > Key: OFBIZ-3666 > URL: https://issues.apache.org/jira/browse/OFBIZ-3666 > Project: OFBiz > Issue Type: Bug > Components: order, product > Affects Versions: SVN trunk > Reporter: Bob Morley > Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3666_DoNotRoundPreciseQuantity.patch > > > We have a need to handle inventory items with quantities up to four decimal places. The data model currently supports 6 decimals so I thought I would try to complete a purchase order, sales order, and a return for an item that has this many digits of precision. What I found was ... > - The order item was calculated properly (including the total for the line) but the totals for the entire sales order were incorrect. This was because when OrderReadHelper was getting the OrderItemQuantity as part of calculating the subtotal it would round it to the order's configured scale (2). Since this is being used as a calculation it should not be rounded -- the total itself should be rounded. > - In a number of spots in issuance and reservation services values were (sometimes) being rounded. For example, when an order item was created it would create an InventoryItemDetail record that would reduce the ATP by the precise quantity, however when the order was placed the QOH was reduced by the rounded value. All of these issues were the result of the mini-lang calculate element being used which by default uses a scale of 2 decimals (from the dtd). The solution was when working with quantities pass in the precision scale (6) to ensure we do not lose precision. Again, when order totals, taxes, things like that are being done the configured scale should take over, but the intermediate calculations should not be losing precision. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
[jira] Commented: (OFBIZ-3666) Errors attempting to use quantities with more than 2 decimals of precision
|
|
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855430#action_12855430 ] Bob Morley commented on OFBIZ-3666: ----------------------------------- I agree specifying any precision seemed incorrect; but the reality is these services were specifying a precision of 2 and I simply wanted to correct this with the maximum precision of the data type so that rounding would not occur. So in this case I am just making it work without a "higher risk" change that may break the implementation. As for the set field; we are a little out of step but has the type conversion changed? I would have thought that value would be picked up by the FlexibleStringExpander so you would get a properly typed result which would then be converted to a String and assigned to the field. We ran into problems with this when we corrected localization which would cause the value to be formatted with a comma which would later cause problems parsing back to the numeric field. Keep in mind we are working with a trunk that we last merged about six months ago, so I understand some of this may have changed. > Errors attempting to use quantities with more than 2 decimals of precision > -------------------------------------------------------------------------- > > Key: OFBIZ-3666 > URL: https://issues.apache.org/jira/browse/OFBIZ-3666 > Project: OFBiz > Issue Type: Bug > Components: order, product > Affects Versions: SVN trunk > Reporter: Bob Morley > Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3666_DoNotRoundPreciseQuantity.patch > > > We have a need to handle inventory items with quantities up to four decimal places. The data model currently supports 6 decimals so I thought I would try to complete a purchase order, sales order, and a return for an item that has this many digits of precision. What I found was ... > - The order item was calculated properly (including the total for the line) but the totals for the entire sales order were incorrect. This was because when OrderReadHelper was getting the OrderItemQuantity as part of calculating the subtotal it would round it to the order's configured scale (2). Since this is being used as a calculation it should not be rounded -- the total itself should be rounded. > - In a number of spots in issuance and reservation services values were (sometimes) being rounded. For example, when an order item was created it would create an InventoryItemDetail record that would reduce the ATP by the precise quantity, however when the order was placed the QOH was reduced by the rounded value. All of these issues were the result of the mini-lang calculate element being used which by default uses a scale of 2 decimals (from the dtd). The solution was when working with quantities pass in the precision scale (6) to ensure we do not lose precision. Again, when order totals, taxes, things like that are being done the configured scale should take over, but the intermediate calculations should not be losing precision. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
[jira] Commented: (OFBIZ-3666) Errors attempting to use quantities with more than 2 decimals of precision
|
|
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855435#action_12855435 ] Adrian Crum commented on OFBIZ-3666: ------------------------------------ No, the type conversion hasn't changed. The issue is there is no type to convert to. Quantity should be a type, and Money should be a type. Strong data typing would prevent applying quantity precision to a money, and money precision to a quantity. > Errors attempting to use quantities with more than 2 decimals of precision > -------------------------------------------------------------------------- > > Key: OFBIZ-3666 > URL: https://issues.apache.org/jira/browse/OFBIZ-3666 > Project: OFBiz > Issue Type: Bug > Components: order, product > Affects Versions: SVN trunk > Reporter: Bob Morley > Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3666_DoNotRoundPreciseQuantity.patch > > > We have a need to handle inventory items with quantities up to four decimal places. The data model currently supports 6 decimals so I thought I would try to complete a purchase order, sales order, and a return for an item that has this many digits of precision. What I found was ... > - The order item was calculated properly (including the total for the line) but the totals for the entire sales order were incorrect. This was because when OrderReadHelper was getting the OrderItemQuantity as part of calculating the subtotal it would round it to the order's configured scale (2). Since this is being used as a calculation it should not be rounded -- the total itself should be rounded. > - In a number of spots in issuance and reservation services values were (sometimes) being rounded. For example, when an order item was created it would create an InventoryItemDetail record that would reduce the ATP by the precise quantity, however when the order was placed the QOH was reduced by the rounded value. All of these issues were the result of the mini-lang calculate element being used which by default uses a scale of 2 decimals (from the dtd). The solution was when working with quantities pass in the precision scale (6) to ensure we do not lose precision. Again, when order totals, taxes, things like that are being done the configured scale should take over, but the intermediate calculations should not be losing precision. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
Re: [jira] Commented: (OFBIZ-3666) Errors attempting to use quantities with more than 2 decimals of precision
|
|
Adrian Crum (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/OFBIZ-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855435#action_12855435 ] > > Adrian Crum commented on OFBIZ-3666: > ------------------------------------ > > No, the type conversion hasn't changed. The issue is there is no type to convert to. Quantity should be a type, and Money should be a type. Strong data typing would prevent applying quantity precision to a money, and money precision to a quantity. Not replying to jira just yet. I'm interested in working on typed-Foo conversion, in a generic fashion. Might need to add yet another library, maybe a Units library, time to do a google search. > > >> Errors attempting to use quantities with more than 2 decimals of precision >> -------------------------------------------------------------------------- >> >> Key: OFBIZ-3666 >> URL: https://issues.apache.org/jira/browse/OFBIZ-3666 >> Project: OFBiz >> Issue Type: Bug >> Components: order, product >> Affects Versions: SVN trunk >> Reporter: Bob Morley >> Priority: Minor >> Fix For: SVN trunk >> >> Attachments: OFBIZ-3666_DoNotRoundPreciseQuantity.patch >> >> >> We have a need to handle inventory items with quantities up to four decimal places. The data model currently supports 6 decimals so I thought I would try to complete a purchase order, sales order, and a return for an item that has this many digits of precision. What I found was ... >> - The order item was calculated properly (including the total for the line) but the totals for the entire sales order were incorrect. This was because when OrderReadHelper was getting the OrderItemQuantity as part of calculating the subtotal it would round it to the order's configured scale (2). Since this is being used as a calculation it should not be rounded -- the total itself should be rounded. >> - In a number of spots in issuance and reservation services values were (sometimes) being rounded. For example, when an order item was created it would create an InventoryItemDetail record that would reduce the ATP by the precise quantity, however when the order was placed the QOH was reduced by the rounded value. All of these issues were the result of the mini-lang calculate element being used which by default uses a scale of 2 decimals (from the dtd). The solution was when working with quantities pass in the precision scale (6) to ensure we do not lose precision. Again, when order totals, taxes, things like that are being done the configured scale should take over, but the intermediate calculations should not be losing precision. > |
Re: [jira] Commented: (OFBIZ-3666) Errors attempting to use quantities with more than 2 decimals of precision
|
|
http://www.martinfowler.com/ap2/quantity.html
http://timeandmoney.sourceforge.net/ Adam Heath wrote: > Adrian Crum (JIRA) wrote: >> [ https://issues.apache.org/jira/browse/OFBIZ-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855435#action_12855435 ] >> >> Adrian Crum commented on OFBIZ-3666: >> ------------------------------------ >> >> No, the type conversion hasn't changed. The issue is there is no type to convert to. Quantity should be a type, and Money should be a type. Strong data typing would prevent applying quantity precision to a money, and money precision to a quantity. > > Not replying to jira just yet. > > I'm interested in working on typed-Foo conversion, in a generic > fashion. Might need to add yet another library, maybe a Units > library, time to do a google search. > > >> >>> Errors attempting to use quantities with more than 2 decimals of precision >>> -------------------------------------------------------------------------- >>> >>> Key: OFBIZ-3666 >>> URL: https://issues.apache.org/jira/browse/OFBIZ-3666 >>> Project: OFBiz >>> Issue Type: Bug >>> Components: order, product >>> Affects Versions: SVN trunk >>> Reporter: Bob Morley >>> Priority: Minor >>> Fix For: SVN trunk >>> >>> Attachments: OFBIZ-3666_DoNotRoundPreciseQuantity.patch >>> >>> >>> We have a need to handle inventory items with quantities up to four decimal places. The data model currently supports 6 decimals so I thought I would try to complete a purchase order, sales order, and a return for an item that has this many digits of precision. What I found was ... >>> - The order item was calculated properly (including the total for the line) but the totals for the entire sales order were incorrect. This was because when OrderReadHelper was getting the OrderItemQuantity as part of calculating the subtotal it would round it to the order's configured scale (2). Since this is being used as a calculation it should not be rounded -- the total itself should be rounded. >>> - In a number of spots in issuance and reservation services values were (sometimes) being rounded. For example, when an order item was created it would create an InventoryItemDetail record that would reduce the ATP by the precise quantity, however when the order was placed the QOH was reduced by the rounded value. All of these issues were the result of the mini-lang calculate element being used which by default uses a scale of 2 decimals (from the dtd). The solution was when working with quantities pass in the precision scale (6) to ensure we do not lose precision. Again, when order totals, taxes, things like that are being done the configured scale should take over, but the intermediate calculations should not be losing precision. > > |
Re: [jira] Commented: (OFBIZ-3666) Errors attempting to use quantities with more than 2 decimals of precision
|
|
In reply to this post by Adam Heath-2
Adam Heath wrote:
>> Adrian Crum commented on OFBIZ-3666: >> ------------------------------------ >> >> No, the type conversion hasn't changed. The issue is there is no type to convert to. Quantity should be a type, and Money should be a type. Strong data typing would prevent applying quantity precision to a money, and money precision to a quantity. > > Not replying to jira just yet. > > I'm interested in working on typed-Foo conversion, in a generic > fashion. Might need to add yet another library, maybe a Units > library, time to do a google search. Btw, I have been considering starting a project for often-needed Java data types. The TimeAndMoney library is very similar to what I have in mind, but it isn't being maintained. I would probably start with that and update it. Also, I picture the library being built around the ICU4J library - so internationalization can be kept current. |
Re: [jira] Commented: (OFBIZ-3666) Errors attempting to use quantities with more than 2 decimals of precision
|
|
In reply to this post by Adrian Crum
Adrian Crum wrote:
> http://www.martinfowler.com/ap2/quantity.html Haven't looked yet, thanks. > http://timeandmoney.sourceforge.net/ Just based on the name, that's not what I want. I am after a fully general purpose any quantity+unit to any quantity+unit library. |
Re: [jira] Commented: (OFBIZ-3666) Errors attempting to use quantities with more than 2 decimals of precision
|
|
In reply to this post by Adrian Crum
Adrian Crum wrote:
> Adam Heath wrote: >>> Adrian Crum commented on OFBIZ-3666: >>> ------------------------------------ >>> >>> No, the type conversion hasn't changed. The issue is there is no type >>> to convert to. Quantity should be a type, and Money should be a type. >>> Strong data typing would prevent applying quantity precision to a >>> money, and money precision to a quantity. >> >> Not replying to jira just yet. >> >> I'm interested in working on typed-Foo conversion, in a generic >> fashion. Might need to add yet another library, maybe a Units >> library, time to do a google search. > > Btw, I have been considering starting a project for often-needed Java > data types. The TimeAndMoney library is very similar to what I have in > mind, but it isn't being maintained. I would probably start with that > and update it. Also, I picture the library being built around the ICU4J > library - so internationalization can be kept current. There is a jsr that dealt with units, but I believe it's been abandoned. |
Re: [jira] Commented: (OFBIZ-3666) Errors attempting to use quantities with more than 2 decimals of precision
|
|
In reply to this post by Adam Heath-2
Adam Heath wrote:
> Adrian Crum wrote: >> http://www.martinfowler.com/ap2/quantity.html > > Haven't looked yet, thanks. > >> http://timeandmoney.sourceforge.net/ > > Just based on the name, that's not what I want. I am after a fully > general purpose any quantity+unit to any quantity+unit library. The classes are based on the Quantity pattern (value + unit). |
Re: [jira] Commented: (OFBIZ-3666) Errors attempting to use quantities with more than 2 decimals of precision
Administrator
|
In reply to this post by Adrian Crum
From: "Adrian Crum" <[hidden email]>
> Adam Heath wrote: >>> Adrian Crum commented on OFBIZ-3666: >>> ------------------------------------ >>> >>> No, the type conversion hasn't changed. The issue is there is no type to convert to. Quantity should be a type, and Money should >>> be a type. Strong data typing would prevent applying quantity precision to a money, and money precision to a quantity. >> >> Not replying to jira just yet. >> >> I'm interested in working on typed-Foo conversion, in a generic >> fashion. Might need to add yet another library, maybe a Units >> library, time to do a google search. > > Btw, I have been considering starting a project for often-needed Java data types. The TimeAndMoney library is very similar to what > I have in mind, but it isn't being maintained. I would probably start with that and update it. Also, I picture the library being > built around the ICU4J library - so internationalization can be kept current. Would you put it in Apache Commons? It would have more support there, I guess. Jacques |
[jira] Commented: (OFBIZ-3666) Errors attempting to use quantities with more than 2 decimals of precision
|
|
In reply to this post by Nicolas Malin (Jira)
[ https://issues.apache.org/jira/browse/OFBIZ-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855479#action_12855479 ] Jacques Le Roux commented on OFBIZ-3666: ---------------------------------------- I completly agree about stronger data types. But I have often found that increasing the currency decimals number to its maximum (6) is a workaround when rouding issues occur. I do it directly in DB fieldtypes and add or change (depending on the fastness the client wants). Certainly not the best way to do it, but surely the fastest. > Errors attempting to use quantities with more than 2 decimals of precision > -------------------------------------------------------------------------- > > Key: OFBIZ-3666 > URL: https://issues.apache.org/jira/browse/OFBIZ-3666 > Project: OFBiz > Issue Type: Bug > Components: order, product > Affects Versions: SVN trunk > Reporter: Bob Morley > Priority: Minor > Fix For: SVN trunk > > Attachments: OFBIZ-3666_DoNotRoundPreciseQuantity.patch > > > We have a need to handle inventory items with quantities up to four decimal places. The data model currently supports 6 decimals so I thought I would try to complete a purchase order, sales order, and a return for an item that has this many digits of precision. What I found was ... > - The order item was calculated properly (including the total for the line) but the totals for the entire sales order were incorrect. This was because when OrderReadHelper was getting the OrderItemQuantity as part of calculating the subtotal it would round it to the order's configured scale (2). Since this is being used as a calculation it should not be rounded -- the total itself should be rounded. > - In a number of spots in issuance and reservation services values were (sometimes) being rounded. For example, when an order item was created it would create an InventoryItemDetail record that would reduce the ATP by the precise quantity, however when the order was placed the QOH was reduced by the rounded value. All of these issues were the result of the mini-lang calculate element being used which by default uses a scale of 2 decimals (from the dtd). The solution was when working with quantities pass in the precision scale (6) to ensure we do not lose precision. Again, when order totals, taxes, things like that are being done the configured scale should take over, but the intermediate calculations should not be losing precision. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. |
Re: [jira] Commented: (OFBIZ-3666) Errors attempting to use quantities with more than 2 decimals of precision
|
|
In reply to this post by Adam Heath-2
Adam Heath wrote:
> Adrian Crum (JIRA) wrote: >> [ https://issues.apache.org/jira/browse/OFBIZ-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855435#action_12855435 ] >> >> Adrian Crum commented on OFBIZ-3666: >> ------------------------------------ >> >> No, the type conversion hasn't changed. The issue is there is no type to convert to. Quantity should be a type, and Money should be a type. Strong data typing would prevent applying quantity precision to a money, and money precision to a quantity. > > Not replying to jira just yet. > > I'm interested in working on typed-Foo conversion, in a generic > fashion. Might need to add yet another library, maybe a Units > library, time to do a google search. http://jcp.org/en/jsr/detail?id=275 |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |