[11.0][MIG] account_asset_management_method_number_end : Migration to v11

[grindtildeath]

Requires :

• [11.0][MIG] account_asset_management : Migration to v11 #698

[simahawk]

https://github.com/OCA/account-financial-tools

[simahawk]

what about a mixin to avoid copy/paste? :)

[simahawk]

do you really need to load this for every test? Otherwise pls use SavepointCase + setUpClass

[pedrobaeza]

Why isn't this integrated on main module?

[grindtildeath]

@pedrobaeza I suppose the reason is an historic one.
@luc-demeyer Should we merge these functions into the base module or is there a good reason to keep it separated ?

[luc-demeyer]

There is good reason to keep this separate.
The two methods added by this module are NOT supposed to be used for Financial Asset Management purposes.
In case your customer wants to generate accounting entries for Cost or Revenue spreading than it becomes usefull.

An example:
As a company you may receive insure bills for car insurance on twice a year.
If you have many company cars you may prefer to split the cost of such a bill over the insurance cost duration (6 month) -> use a 'cost spreading' top level view account for reporting purposes and an asset profile with time method number', number = 6, period = month and the appropriate general accounts will do the job.

[pedrobaeza]

Well, the "number of depreciations" methods is a general one that can be used as well for financial assets, and as I saw you on the code sprint, my customers are using it as well as the percentage method. I can agree about the "date end", but at the end, the purpose for what it's used is not the main question, as this adds little overcharge being added to the main module (an if on the appropriated methods), but being more complicated using a modular approach (manifest, new module, new PR...).

[luc-demeyer]

If there is a legal requirement in Spain to support the 'number' method for managing financial assets (hence NOT cost/revenue spreading) than we should add it to the main module. As far as I know financial assets always need to be depreciated based upon fiscal years (full years or pro-rata temporis). The number method allows to depreciate over e.g. 6 months, or 13 months, ... which I think is not allowed (also in Spain) unless those 6 months are accidently the end of the fiscal year.
I don't think we should promote a method that allows customers to make mistakes if the current base module methods are aligned with legal requirements.

The official addons account_asset module has a (rather large) number of flaws, hence you need to use the number method on the official module in some cases to circumvent the fact that their calculations are not fiscal year based.

[astirpe]

For the spreading of costs and revenues I'm proposing a dedicated module. See PR #715

[yung-wang]

@luc-demeyer @pedrobaeza In the Netherlands it is also allowed to used 'number' or date based (fiscal years), so i would propose to pushed this to the main. Let the end-user decided how they want to manage their financial assets. I worked with a lot of accountants and they prefer to calculate the depreciation of the assets based on numbers (like 5 years x12 = 60 periods). You just fill in the start date of the depreciation and based on the numbers of periods, the system will automatically calculate the depreciation per period.
If the purpose of this is only for cost spreading invoices, then why put this module in the Assets category? This shouldn't belong here then.

There is already a cost spreading / accrual like functionality. See PR #715 and account-closing

[grindtildeath]

@luc-demeyer Just fixed the travis issue and rebased, so this should be good.

[MiquelRForgeFlow]

@grindtildeath hello everybody, will this PR proceed forward to has green CI?

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.