Merge lp://qastaging/~cv.clearcorp/openobject-addons/7.0-fix_bug_depreciation_board into lp://qastaging/openobject-addons
Status: | Needs review |
---|---|
Proposed branch: | lp://qastaging/~cv.clearcorp/openobject-addons/7.0-fix_bug_depreciation_board |
Merge into: | lp://qastaging/openobject-addons |
Diff against target: |
79 lines (+28/-6) 1 file modified
account_asset/account_asset.py (+28/-6) |
To merge this branch: | bzr merge lp://qastaging/~cv.clearcorp/openobject-addons/7.0-fix_bug_depreciation_board |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
OpenERP Core Team | Pending | ||
Review via email:
|
Description of the change
The next depreciation date (estimation) is based on purchase date. But, for example, in case when purchase date is 31/12/2013, next depreciation will be 1/1/14 and then 28/2/14, but from that date, next depreciation will be 28/3/14 instead of 31/3/14. Also, it exists a problem with months composed of 30 days: For example in June depreciation would be 28/6/14 instead of 30/6/14.
The estimated of next depreciation date doesn't 'respect' or not estimate correctly the final date of each month, depending if the month has 28, 30, 31 days. When February is processed, all depreciation dates are estimated based on 28 or 29, it means that since that date, estimate date ignores purchase date as beginning and replace it with 28/2 or 29/2.
Unmerged revisions
- 9970. By Carlos Vásquez (ClearCorp)
-
[FIX] Fix the next depreciation date estimation is based on purchase date. For example, in case when purchase date is 31/12/2013, next depreciation will be 1/1/14 and then 28/2/14, but since that date, next depreciation will be 28/3/14 instead of 31/3/14. Also, it exists a problem with months composed of 30 days: For example in June depreciation would be 28/6/14 instead of 30/6/14. The solution for this problem is estimated next depreciation date with method_period variable, create a interval time and all estimates are based on purchase_date.