Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013310Openbravo ERP09. Financial managementpublic2010-05-13 10:512010-06-30 12:17
Reporternetworkb 
Assigned Tosathiyan 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOS20OS VersionCommunity Appliance
Product Version2.40MP12 
Target Version2.40MP13Fixed in Version 
Merge Request Status
Review Assigned To
OBNetwork customerOBPS
Web browser
ModulesCore
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0013310: the sum of amounts of amortization line is higher than amortization amount
Descriptionwhen the amounts to amortization is low, and the number of months is high, the sum of amounts of amortization line is higher than amortization amount.
This problem has been reproducible in 2.50mp14 and 2.40 mp12.6
Steps To Reproduce. Financial Management || Assets || Assets || Assets >> Asset Amortization
 . Depreciate checked
 . Depreciation Type: linear
 . Calculate Type: time
 . Amortize: monthly
 . Usable Life - Months : 318
 . Depreciation Start Date: 01/01/2009
 . Asset Value: 21.04
 . Residual Asset Value: 0
 . Depreciation Amt: 21.04
 . Previously Depreciated Amt: 3.3
. run "create amortization"

.Financial Management || Assets || Assets || Assets >> Asset Amortization
 . 317 lines have been created, and the amounts of each of them is 0.06
 the amount to amortization is 21.04 - 3.3 = 17.74
 the sum of value of lines is 317*0.06 = 19.02


Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
has duplicate backport 00133162.40MP13 closed dalsasua the sum of amounts of amortization line is higher than amortization amount 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-05-13 10:51networkbNew Issue
2010-05-13 10:51networkbAssigned To => dalsasua
2010-05-13 10:51networkbOBNetwork customer => Yes
2010-05-13 16:29networkbTarget Version => 2.40MP13
2010-05-13 16:31adrianromeroStatusnew => scheduled
2010-05-13 16:31adrianromerofix_in_branch => pi
2010-05-13 16:31adrianromeroIssue cloned0013316
2010-05-13 16:33adrianromeroRelationship addeddepends on 0013316
2010-06-11 10:45sathiyanAssigned Todalsasua => sathiyan
2010-06-14 05:07sathiyanNote Added: 0028334
2010-06-15 06:46sathiyanNote Added: 0028413
2010-06-15 06:46sathiyanAssigned Tosathiyan => networkb
2010-06-15 06:46sathiyanStatusscheduled => feedback
2010-06-16 19:11networkbNote Added: 0028528
2010-06-16 19:12networkbStatusfeedback => new
2010-06-16 19:12networkbfix_in_branchpi =>
2010-06-16 19:19networkbAssigned Tonetworkb => sathiyan
2010-06-17 07:41sathiyanNote Added: 0028535
2010-06-17 12:47adrianromeroStatusnew => scheduled
2010-06-17 12:47adrianromerofix_in_branch => pi
2010-06-21 12:38networkbSeveritymajor => minor
2010-06-21 12:38networkbfix_in_branchpi =>
2010-06-21 18:13dalsasuaNote Added: 0028634
2010-06-21 18:15hgbotCheckin
2010-06-21 18:15hgbotNote Added: 0028635
2010-06-21 18:15hgbotStatusscheduled => resolved
2010-06-21 18:15hgbotResolutionopen => fixed
2010-06-21 18:15hgbotFixed in SCM revision => http://code.openbravo.com/erp/devel/pi/rev/3e46e3bc3c893cc61c1da981ce215958826fc3f1 [^]
2010-06-22 17:17hgbotCheckin
2010-06-22 17:17hgbotNote Added: 0028682
2010-06-22 17:17hgbotFixed in SCM revisionhttp://code.openbravo.com/erp/devel/pi/rev/3e46e3bc3c893cc61c1da981ce215958826fc3f1 [^] => http://code.openbravo.com/erp/devel/pi/rev/aa32a90dfb165fab41c97ed4e7b6c668c84847e5 [^]
2010-06-23 00:17dalsasuaRelationship replacedhas duplicate 0013316
2010-06-23 00:20hgbotCheckin
2010-06-23 00:20hgbotNote Added: 0028688
2010-06-23 00:20hgbotFixed in SCM revisionhttp://code.openbravo.com/erp/devel/pi/rev/aa32a90dfb165fab41c97ed4e7b6c668c84847e5 [^] => http://code.openbravo.com/erp/devel/pi/rev/c12224b72fbbb49b010bbf1c43fa0b5277fe9f0f [^]
2010-06-24 07:38sureshbabuNote Added: 0028718
2010-06-24 07:38sureshbabuStatusresolved => closed
2010-06-25 00:00anonymoussf_bug_id0 => 3021055
2010-06-30 12:16hudsonbotCheckin
2010-06-30 12:16hudsonbotNote Added: 0028887
2010-06-30 12:17hudsonbotCheckin
2010-06-30 12:17hudsonbotNote Added: 0028893
2010-06-30 12:17hudsonbotCheckin
2010-06-30 12:17hudsonbotNote Added: 0028896

Notes
(0028334)
sathiyan   
2010-06-14 05:07   
Total Amount is higher for 0.06. Total amount is lower for 0.05. How we can help for this case, since client has two digit precision as rounding. It is not technically feasible. This test case scenario is not practical in real time business. who will go for huge number of months for amartization plan for small amount. We can have asset group for very low value assets as an long term solution.
(0028413)
sathiyan   
2010-06-15 06:46   
Please see my note section
(0028528)
networkb   
2010-06-16 19:11   
yes, when the amount is low and the number of months is high, this problem is generated, but the aplication should work fine in this cases.
(0028535)
sathiyan   
2010-06-17 07:41   
I can talk to David(he is my lead) regarding this. We have to come up with some break even point in the number of month(if exceed in beyond certain number of months, it will give problem(either higher or lower in amount), it is called break even point of months). If end user gives that beyond the number of months, we have to give error messages.

For example scenario(say our case):
317*0.06 = 19.02
317*0.05 = 15.85
However the amount should be 17.74. There is no choice of choosing the amount between 0.05 and 0.06, since only two digit of precision allowed. So we have other choice of forcing to reduce the number of month. for example if it is 296 months,
296*0.06 = 17.76 (we can go for rounding with floor or Ceil for last months about .02 make sense)

Is that fine solution for you?

Regards
Sathiyan.
(0028634)
dalsasua   
2010-06-21 18:13   
In order to fix this bug several changes have been made:

Currently in the last amortization, an adjustment is done in the last amortization, so rounding differences are fixed. Problem reported in this issue is that if the amount is too big and/or the amount of time is very big, then this rounding differences are quite big, compared with asset value, and even bigger than the amortization amount of the last amortization. If this was the case, last amortization was not created, as negative amounts are not allowed.

What I have done is:

- Detect this rounding issue, and throw an exception.
- Detect as well if, finished the process, the amount to amortize is different from the asset value, and throw an error
- Detect that the percentage to amortize is not different to 100
(0028635)
hgbot   
2010-06-21 18:15   
Repository: erp/devel/pi
Changeset: 3e46e3bc3c893cc61c1da981ce215958826fc3f1
Author: David Alsasua <david.alsasua <at> openbravo.com>
Date: Mon Jun 21 18:15:00 2010 +0200
URL: http://code.openbravo.com/erp/devel/pi/rev/3e46e3bc3c893cc61c1da981ce215958826fc3f1 [^]

Fixes issue 13310
Rounding issues are detected
At the end of the process it's ensured that amortized percentage is 100%
  and amortized amount = asset value

---
M src-db/database/model/functions/A_ASSET_POST.xml
M src-db/database/sourcedata/AD_MESSAGE.xml
---
(0028682)
hgbot   
2010-06-22 17:17   
Repository: erp/devel/pi
Changeset: aa32a90dfb165fab41c97ed4e7b6c668c84847e5
Author: David Alsasua <david.alsasua <at> openbravo.com>
Date: Tue Jun 22 17:16:29 2010 +0200
URL: http://code.openbravo.com/erp/devel/pi/rev/aa32a90dfb165fab41c97ed4e7b6c668c84847e5 [^]

Fixes issue 13310. Fixes issue 13728.

---
M src-db/database/model/functions/A_ASSET_POST.xml
---
(0028688)
hgbot   
2010-06-23 00:20   
Repository: erp/devel/pi
Changeset: c12224b72fbbb49b010bbf1c43fa0b5277fe9f0f
Author: David Alsasua <david.alsasua <at> openbravo.com>
Date: Wed Jun 23 00:20:09 2010 +0200
URL: http://code.openbravo.com/erp/devel/pi/rev/c12224b72fbbb49b010bbf1c43fa0b5277fe9f0f [^]

Fixes issue 13728. Fixes issue 13310. Fixes issue 13727

---
M src-db/database/model/functions/A_ASSET_POST.xml
---
(0028718)
sureshbabu   
2010-06-24 07:38   
Right now system throws below error message, if the amount is too low or the periods are too big.

Error:An amortization plan cannot be created for so low amount and / or so big amount of time
(0028887)
hudsonbot   
2010-06-30 12:16   
A changeset related to this issue has been promoted to main after passing a series of tests and an OBX has been generated:

Changeset: http://code.openbravo.com/erp/devel/main/rev/3e46e3bc3c89 [^]
Merge Changeset: http://code.openbravo.com/erp/devel/main/rev/0670375d782d [^]
Tests: http://builds.openbravo.com/view/int/ [^]
OBX: http://builds.openbravo.com/erp/core/obx/OpenbravoERP-2.50CI.17726.obx [^]
(0028893)
hudsonbot   
2010-06-30 12:17   
A changeset related to this issue has been promoted to main after passing a series of tests and an OBX has been generated:

Changeset: http://code.openbravo.com/erp/devel/main/rev/aa32a90dfb16 [^]
Merge Changeset: http://code.openbravo.com/erp/devel/main/rev/0670375d782d [^]
Tests: http://builds.openbravo.com/view/int/ [^]
OBX: http://builds.openbravo.com/erp/core/obx/OpenbravoERP-2.50CI.17726.obx [^]
(0028896)
hudsonbot   
2010-06-30 12:17   
A changeset related to this issue has been promoted to main after passing a series of tests and an OBX has been generated:

Changeset: http://code.openbravo.com/erp/devel/main/rev/c12224b72fbb [^]
Merge Changeset: http://code.openbravo.com/erp/devel/main/rev/0670375d782d [^]
Tests: http://builds.openbravo.com/view/int/ [^]
OBX: http://builds.openbravo.com/erp/core/obx/OpenbravoERP-2.50CI.17726.obx [^]