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

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0028427
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] 03. Procurement managementmajoralways2014-12-16 18:562015-02-04 20:34
ReporterngarciaView Statuspublic 
Assigned ToAugustoMauch 
PriorityurgentResolutionfixedFixed in Version3.0PR15Q2
StatusclosedFix in branchFixed in SCM revision7a0dcbb151a5
ProjectionnoneETAnoneTarget Version3.0PR15Q2
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned Toalostale
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0028427: Price is not rounded to calculate the line net amount in Create Lines process of Purchase Order

DescriptionPrice is not rounded to calculate the line net amount in Create Lines process of Purchase Invoices
Steps To ReproduceAs group admin role:
   Create a purchase order header
   Check the price precision of the price list currency is 2
   Check also the Format.xml is configured to show 2 decimals
   Click on Create Lines and set:
      Standard Price: 1.1255
      Quantity: 2000
   Check the price is updated to 1.13 but the Line Net Amount is 1.1255*2000=2251 instead of 1.13*2000=2260
TagsNo tags attached.
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]
related to defect 00255173.0PR14Q3 closedshankarb Wrong calculations on numeric field depending on the formula 
related to defect 00230563.0MP21 closedshankarb Ordered Quantiy field of Sales Order is not properly auto filling the grouping separator 
related to defect 0028720 closedalostale System is not saving big numbers properly 
related to defect 0028747 closedAugustoMauch If a numeric value is entered using a formula, it is saved without being rounded 
depends on defect 00238683.0MP24 closedAugustoMauch Numeric fields are internally stored as strings due to regression 
depends on defect 00239753.0MP24 closedAugustoMauch Number handling does not work properly if ',' is used as decimal separator 
depends on defect 00237583.0MP24 closedshankarb Format.xml is not correctly applied to Amount reference in grid view 
related to defect 0028765 acknowledgedTriage Platform Base It is not possible to use formula inputs if ',' is used as decimal separator 
related to defect 0031901 closedcaristu decimal value can't be changed by trigger/observer after manual edition in form view 

-  Notes
(0073755)
AugustoMauch (manager)
2015-01-23 14:22

 Related issues to test:

https://issues.openbravo.com/view.php?id=23056 [^]
https://issues.openbravo.com/view.php?id=23868 [^]
https://issues.openbravo.com/view.php?id=23975 [^]
https://issues.openbravo.com/view.php?id=23758 [^]
(0073757)
hgbot (developer)
2015-01-23 15:01

 Repository: erp/devel/pi
Changeset: 7a0dcbb151a516466e2d5841907d8b9d96647acf
Author: Augusto Mauch <augusto.mauch <at> openbravo.com>
Date: Fri Jan 23 15:00:12 2015 +0100
URL: http://code.openbravo.com/erp/devel/pi/rev/7a0dcbb151a516466e2d5841907d8b9d96647acf [^]

Fixes issue 28427: Numbers are always rounded on blur

The blur function of the OBNumberItems only did the rounding when the getValue function of the item returned a string. This worked in most of the cases (i.e. standard grids and forms, d
ue to the edit form of the grid having a setTextualValue function, see [1]), but not in the parameter windows. In those windows, both numeric parameters and numeric columns in grid para
meters did not round the entered numbers before saving them.

To fix this, now the numbers are rounded on blur even if the value entered is already a number. To found the number these two functions are invoked:

  value = OB.Utilities.Number.JSToOBMasked(this.getValue(), this.typeInstance.maskNumeric, this.typeInstance.decSeparator, this.typeInstance.groupSeparator);
  this.setValue(OB.Utilities.Number.OBMaskedToJS(value, this.typeInstance.decSeparator, this.typeInstance.groupSeparator));

The first one converts the number to a string representation of the rounded number. The second one converts the rounded string number to a javascript number.

---
M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/form/formitem/ob-formitem-number.js
---
(0073758)
AugustoMauch (manager)
2015-01-23 15:03

 All the issues listed in this note [1] have been tested, using both '.' and ',' as decimal separators.

It has also been checked that numeric values in parameter windows are now rounded before being saved by checking the value sent to the action handler. Both numeric parameters and numeric columns of grid parameters have been checked.

[1] https://issues.openbravo.com/view.php?id=28427#c73755 [^]
(0073769)
hgbot (developer)
2015-01-26 12:42

 Repository: erp/devel/pi
Changeset: 39b9171de017afa00b4331275c111d66251c4cb4
Author: Augusto Mauch <augusto.mauch <at> openbravo.com>
Date: Mon Jan 26 12:39:25 2015 +0100
URL: http://code.openbravo.com/erp/devel/pi/rev/39b9171de017afa00b4331275c111d66251c4cb4 [^]

Fixes bug 28747,related with bug 28427: Number entered with formula is rounded

The problem was that if a number was entered using a formula (i.e. by entering =1/3 in the form item), the value was not rounded using the numeric field mask. For non-formula inputs the validation is done at the beginning of the blur function. For formula inputs it is not possible to do it at that point, because the value of the field is still the formula, not the result of evaluating the formula. The formula is evaluated in the validate function(), so the rounding for formula inputs is done after invoking it.

---
M modules/org.openbravo.client.application/web/org.openbravo.client.application/js/form/formitem/ob-formitem-number.js
---
(0073931)
alostale (manager)
2015-01-30 09:44

 code reviewed

tested while closing 0028747, see notes there
(0074178)
hudsonbot (developer)
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
(0074181)
hudsonbot (developer)
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

- Issue History
Date Modified Username Field Change
2014-12-16 18:56 ngarcia New Issue
2014-12-16 18:56 ngarcia Assigned To => AtulOpenbravo
2014-12-16 18:56 ngarcia Modules => Core
2014-12-16 18:56 ngarcia Resolution time => 1421535600
2014-12-16 18:56 ngarcia Triggers an Emergency Pack => No
2014-12-16 18:56 ngarcia Issue Monitored: networkb
2015-01-13 18:57 ngarcia Target Version => 3.0PR15Q2
2015-01-22 00:49 reinaldoguerra Assigned To AtulOpenbravo => reinaldoguerra
2015-01-22 00:49 reinaldoguerra Status new => scheduled
2015-01-22 16:03 ngarcia Steps to Reproduce Updated View Revisions
2015-01-22 18:24 Sandrahuguet Assigned To reinaldoguerra => AugustoMauch
2015-01-23 11:02 AugustoMauch Relationship added related to 0025517
2015-01-23 14:22 AugustoMauch Note Added: 0073755
2015-01-23 14:49 AugustoMauch Relationship added related to 0023056
2015-01-23 14:49 AugustoMauch Relationship added depends on 0023868
2015-01-23 14:49 AugustoMauch Relationship added depends on 0023975
2015-01-23 14:49 AugustoMauch Relationship added depends on 0023758
2015-01-23 15:01 hgbot Checkin
2015-01-23 15:01 hgbot Note Added: 0073757
2015-01-23 15:01 hgbot Status scheduled => resolved
2015-01-23 15:01 hgbot Resolution open => fixed
2015-01-23 15:01 hgbot Fixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/7a0dcbb151a516466e2d5841907d8b9d96647acf [^]
2015-01-23 15:03 AugustoMauch Note Added: 0073758
2015-01-23 15:03 AugustoMauch Issue Monitored: alostale
2015-01-23 15:04 AugustoMauch Review Assigned To => alostale
2015-01-26 08:36 alostale Relationship added related to 0028720
2015-01-26 12:41 AugustoMauch Relationship added related to 0028747
2015-01-26 12:42 hgbot Checkin
2015-01-26 12:42 hgbot Note Added: 0073769
2015-01-26 12:47 AugustoMauch Relationship added related to 0028765
2015-01-30 09:44 alostale Note Added: 0073931
2015-01-30 09:44 alostale Status resolved => closed
2015-01-30 09:44 alostale Fixed in Version => 3.0PR15Q2
2015-02-04 20:34 hudsonbot Checkin
2015-02-04 20:34 hudsonbot Note Added: 0074178
2015-02-04 20:34 hudsonbot Checkin
2015-02-04 20:34 hudsonbot Note Added: 0074181
2016-01-25 12:51 caristu Relationship added related to 0031901

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker