Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0029113Openbravo ERPA. Platformpublic2015-03-03 16:372015-03-06 16:04
Reporterjecharri 
Assigned ToAugustoMauch 
PriorityimmediateSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Versionpi 
Target Version3.0PR15Q2Fixed in Version3.0PR15Q2 
Merge Request Status
Review Assigned Todbaz
OBNetwork customer
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0029113: 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
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
related to defect 0029139 new marvintm Retail Modules Web POS shouldn't import javascript resources from Core 
related to defect 0030014 closed NaroaIriarte Openbravo ERP The function OB.Utilities.Number.OBMaskedToOBPlain is not working properly with negative big numbers 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-03-03 16:37jecharriNew Issue
2015-03-03 16:37jecharriAssigned To => AugustoMauch
2015-03-03 16:37jecharriModules => Core
2015-03-03 16:37jecharriResolution time => 1425423600
2015-03-03 16:37jecharriTriggers an Emergency Pack => No
2015-03-03 16:41AugustoMauchSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=7830#r7830
2015-03-03 16:42AugustoMauchSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=7831#r7831
2015-03-03 16:44AugustoMauchNote Added: 0075130
2015-03-03 17:32AugustoMauchNote Edited: 0075130bug_revision_view_page.php?bugnote_id=0075130#r7833
2015-03-04 04:36johnfandlIssue Monitored: johnfandl
2015-03-04 04:37johnfandlNote Added: 0075137
2015-03-04 09:14AugustoMauchIssue Monitored: dbaz
2015-03-04 09:14AugustoMauchReview Assigned To => dbaz
2015-03-04 09:17hgbotCheckin
2015-03-04 09:17hgbotNote Added: 0075138
2015-03-04 09:17hgbotStatusnew => resolved
2015-03-04 09:17hgbotResolutionopen => fixed
2015-03-04 09:17hgbotFixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/b5096788cd44794964e99024d9b19a5c86efa2f4 [^]
2015-03-04 09:19AugustoMauchNote Added: 0075139
2015-03-04 09:21AugustoMauchSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=7836#r7836
2015-03-04 15:51hudsonbotCheckin
2015-03-04 15:51hudsonbotNote Added: 0075160
2015-03-04 19:37dbazNote Added: 0075177
2015-03-04 19:37dbazStatusresolved => new
2015-03-04 19:37dbazResolutionfixed => open
2015-03-05 00:56OrekariaNote Added: 0075183
2015-03-05 00:56OrekariaNote Edited: 0075183bug_revision_view_page.php?bugnote_id=0075183#r7858
2015-03-05 10:17hgbotCheckin
2015-03-05 10:17hgbotNote Added: 0075187
2015-03-05 10:17hgbotStatusnew => resolved
2015-03-05 10:17hgbotResolutionopen => fixed
2015-03-05 10:17hgbotFixed in SCM revisionhttp://code.openbravo.com/erp/devel/pi/rev/b5096788cd44794964e99024d9b19a5c86efa2f4 [^] => http://code.openbravo.com/erp/devel/pi/rev/e9d73be9949d975d17c8db516b0104a9d868b51f [^]
2015-03-05 10:46AugustoMauchRelationship addedrelated to 0029139
2015-03-05 10:50hgbotCheckin
2015-03-05 10:50hgbotNote Added: 0075188
2015-03-05 11:54dbazNote Added: 0075190
2015-03-05 11:54dbazStatusresolved => closed
2015-03-05 11:54dbazFixed in Version => 3.0PR15Q2
2015-03-05 17:01hudsonbotCheckin
2015-03-05 17:01hudsonbotNote Added: 0075212
2015-03-06 16:04hudsonbotCheckin
2015-03-06 16:04hudsonbotNote Added: 0075253
2015-05-26 13:21NaroaIriarteRelationship addedblocks 0030014
2015-05-26 15:17NaroaIriarteRelationship replacedrelated to 0030014

Notes
(0075130)
AugustoMauch   
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   
2015-03-04 04:37   
This looks like a reasonable solution:

* http://stackoverflow.com/a/19722641 [^]
(0075138)
hgbot   
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   
2015-03-04 09:19   
Tested in ci.openbravo.com/view/try/ with success
(0075160)
hudsonbot   
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   
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   
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   
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   
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   
2015-03-05 11:54   
Reviewed @ changeset: 26127 - 1c75a6afca4e
(0075212)
hudsonbot   
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   
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