Openbravo Issue Tracking System - Openbravo ERP
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0012582||Openbravo ERP||03. Procurement management||public||2010-03-06 09:15||2010-03-23 00:00|
|Assigned To||balamurugan|| |
|Platform||OS||20||OS Version||Community Appliance|
|Product Version|| |
|Target Version||Fixed in Version|| |
|Merge Request Status|
|Review Assigned To|
|Regression introduced in release|
|Regression introduced by commit|
|Triggers an Emergency Pack||No|
|Summary||0012582: "Line Net Amount is not Correct" Error message is displayed when we try to save any Purchase/Sales Invoice Line|
|Description||"Line Net Amount is not Correct" Error message is displayed when we try to save any Purchase/Sales Invoice Line|
|Steps To Reproduce||1. Go to Sales Management || Transactions || Sales Order || Header >> Lines tab|
2. Select any product, and enter the following values.
- Ordered Quantity=7
- Now, the remaining fields like Net Unit Price, Net Standard price. etc., are populated as per the setup.
- check the Edit Line Net Amount field and change the value of Line Net Amount to 45.33
- Please realize that the Net Unit Amount is changed based on the Line Net Amount entered.
- click Save.
- Now, "Line Net Amount is not Correct" Error message is displayed when we try to save.
|Proposed Solution||In SL_Invoice_Amt callout, Net Unit Price calculation is done based on Standard Precision , but it has to be done based on Price Precision.|
priceActual = LineNetAmt.divide(qtyInvoice, StdPrecision, BigDecimal.ROUND_HALF_UP); => priceActual = LineNetAmt.divide(qtyInvoice, PricePrecision, BigDecimal.ROUND_HALF_UP);
|Tags||No tags attached.|
|depends on ||defect ||0012581|| ||closed ||balamurugan ||In Purchase/Sales Order Lines tab, while editing Line Net Amount, it is changed when we save. |
|2010-03-06 09:15||balamurugan||New Issue|
|2010-03-06 09:15||balamurugan||Assigned To|| => adrianromero|
|2010-03-06 09:16||balamurugan||Relationship added||depends on 0012581|
|2010-03-06 09:17||balamurugan||Assigned To||adrianromero => dalsasua|
|2010-03-08 08:37||dalsasua||Assigned To||dalsasua => balamurugan|
|2010-03-08 08:39||dalsasua||Note Added: 0025106|
|2010-03-09 07:22||hgbot||Note Added: 0025157|
|2010-03-09 07:22||hgbot||Status||new => resolved|
|2010-03-09 07:22||hgbot||Resolution||open => fixed|
|2010-03-09 07:22||hgbot||Fixed in SCM revision|| => http://code.openbravo.com/erp/devel/pi/rev/331ea7f7c2e5628f41e3ad3b51a106f03f14e486 [^]|
|2010-03-12 22:41||hudsonbot||Note Added: 0025406|
|2010-03-22 07:22||arunkumar||Note Added: 0025631|
|2010-03-22 07:22||arunkumar||Status||resolved => closed|
|2010-03-23 00:00||anonymous||sf_bug_id||0 => 2974925|
This is the desired behavior. Systems checks that line net amount is quantity per net unit price. If are not correct, throws this error.
Please realize that there do not exists any value with standard precision in small bazaar for Euros (2 digits) that makes this equation work:
Furthermore, proposed solution wouldn't help here. If we use price precision (4 digits in small bazaar), then the error will arise again using higher quantity (500, for example):
The calculated unit price due to the line amount entered by the user is rounded to the price precision. If the line amount is not a valid one (using the price precision, it doesn't exists any possible value for unit price) system will raise that in the moment of saving.
Nevertheless, if actually system is rounding to standard precision, and not to price precision in the call-out, when calculating unit price from the given line amount, please fix that.
Author: Balamurugan Ramadoss <balamurugan.ramadoss <at> openbravo.com>
Date: Tue Mar 09 11:56:34 2010 +0530
URL: http://code.openbravo.com/erp/devel/pi/rev/331ea7f7c2e5628f41e3ad3b51a106f03f14e486 [^]
Fixes Issue 12582: \"Line Net Amount is not Correct\" Error message.
As per David's notes if we enter the net unit amount as 45.33 and ordered quantity as 7 it calculates the net unit price as 6.48 and recalculates the net unit amount as 45.36
Discussed with the developer and confirmed with the results.
Tested & Working fine.