Asset Module: Annual depreciation begins at 'current' fiscal year instead of fiscal year of in-service date

[burksbuilds]

Bug

It appears that the depreciation table fails to generate for assets that were put in service in a prior calendar year, in cases when annual depreciation is expected. I believe that this stems from the fact that the start/end date used to calculate depreciation are always sourced from the current (server time) fiscal year, not the fiscal year associate with the in-service date of the asset.

Notes from research:

• in asset.class.php, the '$fiscal_period_start' variable is set based on the '$depreciation_date_start' variable for daily or monthly depreciation, but is based on the '$init_fiscal_period_start' variable for annual depreciation: code
• The '$init_fiscal_period_start' variable is based on the accountancy function 'getDefaultDatesForTransfer()', which returns the current fiscal year, not the fiscal year which contains the date '$depreciation_date_start' : code

Recommendation:
Instead of using 'getDefaultDatesForTransfer()' to source '$init_fiscal_period_start' and '$init_fiscal_period_end', consider using the accountancy function 'getCurrentPeriodofFiscalYear()', with the '$from_time' argument set as the $depreciation_date_start : code

Environment Version

17.0.2

Environment OS

Linux gator3319.hostgator.com 4.19.150-76.ELK.el6.x86_64 #1 SMP Wed Oct 7 01:34:10 CDT 2020 x86_64

Environment Web server

Apache

Environment PHP

7.4.33

Environment Database

MySQL or MariaDB 5.6.41-84.1

Environment URL(s)

No response

Expected and actual behavior

On an Asset card, When setting "Depreciation type duration" to 'annual':

Actual behavior:

• "Error when calculating the depreciation lines (recovery and future) the reversal date is not provided for the 'economic' depreciation method"

Expected behavior:

• No error, depreciation entries are created for sequential years in the depreciation table tab

Notes for similar circumstances:

• When setting depreciation type duration to 'monthly' the depreciation table generates properly with lines occurring all the way back to the initial month of service, including prior calendar years.
• If the start up date is set to any date in the current calendar year (or fiscal year, they are the same in this case) the depreciation table is successfully created.

Steps to reproduce the behavior

Initial Conditions:

• Accountancy setup: "On accountancy transfer, what is the period selected by default": Fiscal Year
• Fiscal years setup to coincide with calendar years, going back to at least one prior calendar year
• Asset with these conditions:
  ** Acquisition date and startup date in a prior calendar year
  ** Reversal date and reversal amount NOT set

Attached files

No response

[burksbuilds]

Pinging @aspangaro , who seems to be a master of asset/accountancy!

[burksbuilds]

I was able to confirm that using getCurrentPeriodofFiscalYear instead of getDefaultDatesForTransfer fixes the issue. It looks like getCurrentPeriodofFiscalYear was only added for v18, while most of the depreciation stuff was from a prior version, so it make sense why the depreciation generator was not originally using the more flexible funciton.

[BurksEngineering]

@aspangaro : I see that you worked this one line fix into your own copy of v18. Could you please help @josett225 and the rest of the community by working it into the current version of dolibarr if you think it is appropriate? I would like to commit it myself but I don't seem to understand enough about the git workflow required to keep a dev branch up to date during the long review process.