On Depreciation Overriding.

[alcarpio15]

As needed to conclude creating the Method to compute the Initial Adjustment, the main step to take now is to apply the Adjustment Factor on the Depreciation Lines provided by Odoo's Native Asset Module.

Unfortunately, there's an aspect of how Odoo natively handles the computing of an Asset's Depreciation Board that might clash severely with the process: The fact its Compute Method assumes the Depreciation happens in a Yearly basis when an Asset has no posted entries to its name (a common event when adding historical Asset data), despite the Asset Model's innate capability to also set the Depreciation Intervals to a shorter amount of months might lead to the awkward situation where an Asset can end up being depreciated months before its actual purchase.

And while there's the Prorata Temporis field to anchor an Asset to its purchase date, it also changes the Depreciation to work on a near Daily basis, which trades an extreme for another and the way said Depreciation gets computed might not fit some cases.

So the main thing to do is to ensure the Method can be more aware of the length of months between two Depreciation Dates and can pick an Initial Depreciation Date that reflects that awareness.

Now, some key counseling and second opinions is desired regarding how to deal with this issue before implementing a solution given a few factors:

• There's an important rift in the way the Asset Model is implemented between the 8.0 and 9.0 versions, with the Module not migrating to the new API until the release of the latter; So the question lies on whether the format should be preserved when overriding the 8.0 version of the Depreciation Method or should it copy the shape of its equivalent in later versions. Consider the Method also call Subroutines during the process and that the transition between APIs shortened certain columns of the Asset model.

• It's assumed the Depreciation Lines and the Price Indexes the Adjustment Factors are based on might not share the same amount of months that make up their respective intervals, so as the Initial Adjustment Method would be strongly focusing on exploring a List of Relevant Price Indexes to create its Initial Adjustment Lines, it would need to be able of picking the closest Depreciation Date to the Adjustment Date associated to each element of said List.

  (Previous Depr. Date <= Adjust. Date < Next Depr. Date)

• As anything to be included in the future 9.0 branch of this Repository should not rely on relations to the Period Model removed in the later versions of Odoo, Date Definitions and Comparisons hold a higher importance among the operations.

[alcarpio15]

@moylop260 , @zaoral , @nhomar : Is there's anything else I should have in mind while I work on the Override?

[moylop260]

The best to answer is @hbto I can give you my opinion for a cool override methods in order to avoid conflicts with other override inherit for cases where is imposible use a normal inherit with super + my functionality

1. Add a custom field
   • Example custom-field
2. Create a custom method decorator
   • Example: method-decorator
3. Create a inherit method with decorator to override.
   • Example: inherit method

[nhomar]

@alcarpio15

This will apply in all decisions on this development:

1. If the behavior on odoo's base is a "error" make a proper issue in odoo/odoo and then link with your module (<< this is not the case here because odoo is not wrong, just the "Ajuste por Inflacion" considere a different approach).
2. Then as 1 is False create your own method with your own button (as moylop mentioned), and copy-paste the part of the code you need from the official one you do not need to develop 100% of the logic).

Regards.