Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0028720Openbravo ERPA. Platformpublic2015-01-22 09:192015-02-04 20:34
jonalegriaesarte 
alostale 
immediatecriticalhave not tried
closedfixed 
5
 
3.0PR15Q2 
AugustoMauch
Core
Production - Confirmed Stable
2015-01-09
3.0PR14Q3.5
https://code.openbravo.com/erp/devel/pi/rev/e5465c5925cf54475d090258a3832ec8cc9d14ca [^]
Yes
0028720: System is not saving big numbers properly
System is not saving big numbers properly
- GL Journal window
- Create a new header
- Create a new line
- Add a credit: 10200500.45
- Save it. System stores 1020050045.00
No tags attached.
related to defect 00261323.0PR14Q3 closed guillermogil wrong visualization value of quantity fields with very small numbers 
caused by defect 00285523.0PR15Q2 closed alostale Purchase Invoice amount gets truncated upon saving, when the amount is big 
related to defect 00284273.0PR15Q2 closed AugustoMauch Price is not rounded to calculate the line net amount in Create Lines process of Purchase Order 
related to defect 0029709 closed NaroaIriarte Cannot save a physical inventory line with a negative small number in the Book Quantity field 
related to defect 0030014 closed NaroaIriarte The function OB.Utilities.Number.OBMaskedToOBPlain is not working properly with negative big numbers 
Issue History
2015-01-22 09:19jonalegriaesarteNew Issue
2015-01-22 09:19jonalegriaesarteAssigned To => AugustoMauch
2015-01-22 09:19jonalegriaesarteModules => Core
2015-01-22 09:19jonalegriaesarteResolution time => 1421881200
2015-01-22 09:19jonalegriaesarteTriggers an Emergency Pack => No
2015-01-22 09:25alostaleAssigned ToAugustoMauch => alostale
2015-01-22 09:27alostaleRelationship addedrelated to 0028552
2015-01-22 10:39alostaleRelationship replacedcaused by 0028552
2015-01-22 10:39alostaleRelationship addedrelated to 0026132
2015-01-22 10:41alostaleRegression level => Production - Confirmed Stable
2015-01-22 10:41alostaleRegression date => 2015-01-09
2015-01-22 10:41alostaleRegression introduced in release => 3.0PR14Q3.5
2015-01-22 10:41alostaleRegression introduced by commit => https://code.openbravo.com/erp/devel/pi/rev/e5465c5925cf54475d090258a3832ec8cc9d14ca [^]
2015-01-22 10:42alostaleNote Added: 0073712
2015-01-22 10:44alostaleNote Added: 0073713
2015-01-22 11:16hgbotCheckin
2015-01-22 11:16hgbotNote Added: 0073714
2015-01-22 11:16hgbotStatusnew => resolved
2015-01-22 11:16hgbotResolutionopen => fixed
2015-01-22 11:16hgbotFixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/3e5c7b3e8a8f29ba98c312b092eadef36f03aa81 [^]
2015-01-22 11:18alostaleNote Added: 0073715
2015-01-22 11:18alostaleReview Assigned To => AugustoMauch
2015-01-22 11:21alostaleTriggers an Emergency PackNo => Yes
2015-01-22 13:09AugustoMauchNote Added: 0073721
2015-01-22 13:09AugustoMauchStatusresolved => closed
2015-01-22 13:09AugustoMauchFixed in Version => 3.0PR15Q2
2015-01-22 13:11AugustoMauchNote Added: 0073722
2015-01-26 08:36alostaleRelationship addedrelated to 0028427
2015-02-04 20:34hudsonbotCheckin
2015-02-04 20:34hudsonbotNote Added: 0074172
2015-05-26 09:30NaroaIriarteRelationship addedrelated to 0029709
2015-05-26 13:20NaroaIriarteRelationship addedrelated to 0030014

Notes
(0073712)
alostale   
2015-01-22 10:42   
It is reproducible in 3.0PR14Q3.5 but not in 3.0PR14Q4
(0073713)
alostale   
2015-01-22 10:44   
The problem is caused by fix for issue 0026132 which does not handle properly scientific notation for numbers which are not integer, this problem was hidden until fix for 0028552.

It is only reproducible in case a callout (re)sets numeric values with this case.
(0073714)
hgbot   
2015-01-22 11:16   
Repository: erp/devel/pi
Changeset: 3e5c7b3e8a8f29ba98c312b092eadef36f03aa81
Author: Asier Lostalé <asier.lostale <at> openbravo.com>
Date: Thu Jan 22 11:14:24 2015 +0100
URL: http://code.openbravo.com/erp/devel/pi/rev/3e5c7b3e8a8f29ba98c312b092eadef36f03aa81 [^]

fixed bug 28720: callouts incorrectly set big non integer numbers

  When a big non integer number was set by a callout, decimal separator was removed
  resulting in a different number, ie. 10200500.45 resulted in 1020050045.00.

  The problem was in the OB.Utilities.Number.ScientificToDecimal JavaScript function
  which wrongly assumed scientific exponent always added zeroes to coefficient, which
  is not true in this case where exponent determines where the decimal separator is
  inserted in the coefficient.

---
M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/utilities/ob-utilities-number.js
---
(0073715)
alostale   
2015-01-22 11:18   
added test in testLink, pending to decide on automation:
https://testlink.openbravo.com/testlink/linkto.php?tprojectPrefix=Communit&item=testcase&id=Communit-8029 [^]
(0073721)
AugustoMauch   
2015-01-22 13:09   
Code reviewed and verified in pi@3e5c7b3e8a8f
(0073722)
AugustoMauch   
2015-01-22 13:11   
Check that [1] is no longer reproducible and that [2] and [3] remain fixed. Tested using '.' and ',' as decimal separators.

[1] https://issues.openbravo.com/view.php?id=28720 [^]
[2] https://issues.openbravo.com/view.php?id=28552 [^]
[3] https://issues.openbravo.com/view.php?id=26132 [^]
(0074172)
hudsonbot   
2015-02-04 20:34   
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/f36c91d0ad63 [^]
Maturity status: Test