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.
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.