Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0029113
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] A. Platformminoralways2015-03-03 16:372015-03-06 16:04
ReporterjecharriView Statuspublic 
Assigned ToAugustoMauch 
PriorityimmediateResolutionfixedFixed in Version3.0PR15Q2
StatusclosedFix in branchFixed in SCM revisione9d73be9949d
ProjectionnoneETAnoneTarget Version3.0PR15Q2
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionpiSCM revision 
Review Assigned Todbaz
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0029113: Openbravo interface is not rounding properly the database data

DescriptionOpenbravo interface is not rounding properly the database data
Steps To ReproduceSimplified version:
- Execute this in the javascript console:

OB.Utilities.Number.roundJSNumber(0.135, 2); // it returns 0.14, that is OK
OB.Utilities.Number.roundJSNumber(0.145, 2); // it returns 0.14, that is WRONG

====================

To see how to reproduce it using the UI, follow these steps:

- Open Sales Order
- Create a header and save it
- Create a line.
- Enter 0.135 in the Net Unit Price field and press tab. The price is roudned to 0.14, this is OK
- Enter 0.145 in the Net Unit Price field and press tab. The price is roudned to 0.14, this is WRONG
TagsNo tags attached.
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]
related to defect 0029139 newmarvintm Retail Modules Web POS shouldn't import javascript resources from Core 
related to defect 0030014 closedNaroaIriarte Openbravo ERP The function OB.Utilities.Number.OBMaskedToOBPlain is not working properly with negative big numbers 

-  Notes
(0075130)
AugustoMauch (manager)
2015-03-03 16:44
edited on: 2015-03-03 17:32

 The issue is caused by a javascript rounding problem. The OB.Utilities.Number.roundJSNumber(num, dec) functions does this:

result = Math.round(num * Math.pow(10, dec)) / Math.pow(10, dec);

0.135*Math.pow(10, 2) returns 13.5, that is OK
0.145*Math.pow(10, 2) returns 14.499999999999998, that is WRONG (it should return 14.5)
(0075137)
johnfandl (reporter)
2015-03-04 04:37

 This looks like a reasonable solution:

* http://stackoverflow.com/a/19722641 [^]
(0075138)
hgbot (developer)
2015-03-04 09:17

 Repository: erp/devel/pi
Changeset: b5096788cd44794964e99024d9b19a5c86efa2f4
Author: Augusto Mauch <augusto.mauch <at> openbravo.com>
Date: Tue Mar 03 19:14:50 2015 +0100
URL: http://code.openbravo.com/erp/devel/pi/rev/b5096788cd44794964e99024d9b19a5c86efa2f4 [^]

Fixes issue 29113: BigDecimal is used to prevent rounding error

There was a problem with javascript decimal precision that was affecting the way we round numbers using the OB.Utilities.Number.roundJSNumber. For instance, if this is 0.145*100 is evaluated in the javascr
ipt console, the result was 14.499999999999998, not 14.5.

Now the OB.Utilities.Number.roundJSNumber uses BigDecimal to overcome this precision error. This is the command used not to round a number:

parseFloat(new BigDecimal(num).round(dec,BigDecimal.prototype.ROUND_HALF_UP));

---
M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/utilities/ob-utilities-number.js
---
(0075139)
AugustoMauch (manager)
2015-03-04 09:19

 Tested in ci.openbravo.com/view/try/ with success
(0075160)
hudsonbot (developer)
2015-03-04 15:51

 A changeset related to this issue has been promoted main and to the
Central Repository, after passing a series of tests.

Promotion changeset: https://code.openbravo.com/erp/devel/main/rev/ece5f469f671 [^]
Maturity status: Test
(0075177)
dbaz (developer)
2015-03-04 19:37

 While evaluating:

isNaN(OB.Utilities.Number.roundJSNumber('not_a_number', 2));

before the fix the result was: true
after the fix the result is: Uncaught BigDecimal(): Not a number: n,o,t,_,a,_,n,u,m,b,e,r

There are two possible ways to handle with this situation:

a) Declare the changeset as an API change

b) Add in the beginning some code like:

if (isNaN(parseInt(num, 10))) {
  return parseInt(num, 10);
}

with this you ensure that before and after the changeset, both functions return the same in case of passing a bad number


I am more in favour of something like option "b", because you avoid the API change and you can track easily if the returned item is not a number.
(0075183)
Orekaria (administrator)
2015-03-05 00:56
edited on: 2015-03-05 00:56

 This changeset is breaking Retail integration

Example: https://ci.openbravo.com/view/retail/job/ret-test-pgsql/1843/testReport/junit/org.openbravo.test.mobile.retail.pack.selenium.tests.sales/SALb010_CreateSaleWithEdit/test/ [^]

Error: 'isc is not defined'
(0075187)
hgbot (developer)
2015-03-05 10:17

 Repository: erp/devel/pi
Changeset: e9d73be9949d975d17c8db516b0104a9d868b51f
Author: Augusto Mauch <augusto.mauch <at> openbravo.com>
Date: Thu Mar 05 10:15:41 2015 +0100
URL: http://code.openbravo.com/erp/devel/pi/rev/e9d73be9949d975d17c8db516b0104a9d868b51f [^]

Fixes issue 29113: Use setScale instead of round, and handle properly NaN

The BigDecimal.round function did not work as we expected [1]:

new BigDecimal('0.145').round(2, BigDecimal.prototype.ROUND_HALF_UP).toString() -> 0.15 (OK)
new BigDecimal('1.145').round(2, BigDecimal.prototype.ROUND_HALF_UP).toString() -> 1.1 (WRONG)
new BigDecimal('10.145').round(2, BigDecimal.prototype.ROUND_HALF_UP).toString() -> 10 (WRONG)

To round the number to a specific amout of decimal digits, the setScale function should be used.

new BigDecimal('0.145').setScale(2, BigDecimal.prototype.ROUND_HALF_UP).toString() -> 0.15 (OK)
new BigDecimal('1.145').setScale(2, BigDecimal.prototype.ROUND_HALF_UP).toString() -> 1.15 (OK)
new BigDecimal('10.145').setScale(2, BigDecimal.prototype.ROUND_HALF_UP).toString() -> 10.15 (OK)

Also, when the number provided in the first argument of the OB.Utilities.Number.roundJSNumber is not a number, the function returns NaN, as it used to do it before.

[1] http://stackoverflow.com/a/13461270 [^]

---
M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/utilities/ob-utilities-number.js
---
(0075188)
hgbot (developer)
2015-03-05 10:50

 Repository: erp/devel/pi
Changeset: 1c75a6afca4e9a09fa5593a2a22b56f6e83fdb6a
Author: Augusto Mauch <augusto.mauch <at> openbravo.com>
Date: Thu Mar 05 10:49:36 2015 +0100
URL: http://code.openbravo.com/erp/devel/pi/rev/1c75a6afca4e9a09fa5593a2a22b56f6e83fdb6a [^]

Related with issue 29113: Avoid using isc in OB.Utilities.Number.roundJSNumber

The OB.Utilities.Number.roundJSNumber function is used in the mobile core module, but smartclient is not available there. OB.Utilities.Number.roundJSNumber should not be used there (see [1]), but in the meantime we are going to avoid using smartclient functions in roundJSNumber.

isc.isA.String has been replaced with (typeof num === 'string')

[1] https://issues.openbravo.com/view.php?id=29139 [^]

---
M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/utilities/ob-utilities-number.js
---
(0075190)
dbaz (developer)
2015-03-05 11:54

 Reviewed @ changeset: 26127 - 1c75a6afca4e
(0075212)
hudsonbot (developer)
2015-03-05 17:01

 A changeset related to this issue has been promoted main and to the
Central Repository, after passing a series of tests.

Promotion changeset: https://code.openbravo.com/erp/devel/main/rev/2369c54c9f14 [^]
Maturity status: Test
(0075253)
hudsonbot (developer)
2015-03-06 16:04

 A changeset related to this issue has been promoted main and to the
Central Repository, after passing a series of tests.

Promotion changeset: https://code.openbravo.com/erp/devel/main/rev/1601137b3c3d [^]
Maturity status: Test

- Issue History
Date Modified Username Field Change
2015-03-03 16:37 jecharri New Issue
2015-03-03 16:37 jecharri Assigned To => AugustoMauch
2015-03-03 16:37 jecharri Modules => Core
2015-03-03 16:37 jecharri Resolution time => 1425423600
2015-03-03 16:37 jecharri Triggers an Emergency Pack => No
2015-03-03 16:41 AugustoMauch Steps to Reproduce Updated View Revisions
2015-03-03 16:42 AugustoMauch Steps to Reproduce Updated View Revisions
2015-03-03 16:44 AugustoMauch Note Added: 0075130
2015-03-03 17:32 AugustoMauch Note Edited: 0075130 View Revisions
2015-03-04 04:36 johnfandl Issue Monitored: johnfandl
2015-03-04 04:37 johnfandl Note Added: 0075137
2015-03-04 09:14 AugustoMauch Issue Monitored: dbaz
2015-03-04 09:14 AugustoMauch Review Assigned To => dbaz
2015-03-04 09:17 hgbot Checkin
2015-03-04 09:17 hgbot Note Added: 0075138
2015-03-04 09:17 hgbot Status new => resolved
2015-03-04 09:17 hgbot Resolution open => fixed
2015-03-04 09:17 hgbot Fixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/b5096788cd44794964e99024d9b19a5c86efa2f4 [^]
2015-03-04 09:19 AugustoMauch Note Added: 0075139
2015-03-04 09:21 AugustoMauch Steps to Reproduce Updated View Revisions
2015-03-04 15:51 hudsonbot Checkin
2015-03-04 15:51 hudsonbot Note Added: 0075160
2015-03-04 19:37 dbaz Note Added: 0075177
2015-03-04 19:37 dbaz Status resolved => new
2015-03-04 19:37 dbaz Resolution fixed => open
2015-03-05 00:56 Orekaria Note Added: 0075183
2015-03-05 00:56 Orekaria Note Edited: 0075183 View Revisions
2015-03-05 10:17 hgbot Checkin
2015-03-05 10:17 hgbot Note Added: 0075187
2015-03-05 10:17 hgbot Status new => resolved
2015-03-05 10:17 hgbot Resolution open => fixed
2015-03-05 10:17 hgbot Fixed in SCM revision http://code.openbravo.com/erp/devel/pi/rev/b5096788cd44794964e99024d9b19a5c86efa2f4 [^] => http://code.openbravo.com/erp/devel/pi/rev/e9d73be9949d975d17c8db516b0104a9d868b51f [^]
2015-03-05 10:46 AugustoMauch Relationship added related to 0029139
2015-03-05 10:50 hgbot Checkin
2015-03-05 10:50 hgbot Note Added: 0075188
2015-03-05 11:54 dbaz Note Added: 0075190
2015-03-05 11:54 dbaz Status resolved => closed
2015-03-05 11:54 dbaz Fixed in Version => 3.0PR15Q2
2015-03-05 17:01 hudsonbot Checkin
2015-03-05 17:01 hudsonbot Note Added: 0075212
2015-03-06 16:04 hudsonbot Checkin
2015-03-06 16:04 hudsonbot Note Added: 0075253
2015-05-26 13:21 NaroaIriarte Relationship added blocks 0030014
2015-05-26 15:17 NaroaIriarte Relationship replaced related to 0030014

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker