[IMP]asset management: compensate deviation via last entry #1785
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
account_asset_management, change logic to compensate deviation of posted entries. Before this PR, deviations are corrected in the first period after posted/init entries. This leads to rather strange situations illustrated by the following example: Create an asset with - purchase value 120 EUR - start date 2022-12-01 - duration 1 year - linear, prorata temporis - monthly depreciation Set lock date to 2022-12-31. Intuitevely one would expect a depreciation table with 10 EUR/month depreciation. But the pro-rata temporis will calculate for period december 2022 : 31 / 365 * 120 = 10.19 EUR. The user changes the INIT entry value to 10 EUR since his legacy system has calculated 10 EUR / month. This will probably be the case when the 'legacy' system is a spreadsheet. After recompute the compensation is calculated for 2023-01 and becomes 99.81 EUR. After this PR, we continue with the monthly depreciation amount of 10 EUR and compensate in the last month (with also 10 EUR in the last month). Result: clean depreciation table matching end user expectation.
|
Depreciation table before this PR: Depreciation table after this PR: |
luc-demeyer
changed the title
luc-demeyer
changed the title
module : account_asset_management, unit tests Via this commit we align unit test_04 to the new logic where deviations are compensated via the last depreciation board entry. At the same time the scenario becomes more realistic: the INIT entry now gets a value of 269.44 EUR (versus calculated prorata value of 269.53), before this commit the INIT value was set to 279.44, hence a deviation that is much larger than whatever you can get via another calculation logic. Since we now compensate via the last entry, we only need to check that the table maintains the monthly depreciation amount of 55.55 and the last entry. Since we have in this test the same INIT value in both leap and noleap year use cases, the last period deprecation will in both case be equal (8.31 EUR).
luc-demeyer
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
account_asset_management, change logic to compensate deviation of posted entries.
Before this PR, deviations are corrected in the first period after posted/init entries.
This leads to rather strange situations illustrated by the following example:
Create an asset with
Set lock date to 2022-12-31.
Intuitevely one would expect a depreciation table with 10 EUR/month depreciation. But the pro-rata temporis will calculate for period december 2022 : 31 / 365 * 120 = 10.19 EUR.
The user changes the INIT entry value to 10 EUR since his legacy system has calculated 10 EUR / month. This will probably be the case when the 'legacy' system is a spreadsheet. After recompute the compensation is calculated for 2023-01 and becomes 99.81 EUR.
After this PR, we continue with the monthly depreciation amount of 10 EUR and compensate in the last month (with also 10 EUR in the last month).
Result: clean depreciation table matching end user expectation.