asset amortisation and 'yearly' frequency

[Richard PALO]

I've been tinkering getting a fully working 'degressive' amortisation method in account_assets.

Although initially it was rather quite simple (at it is in theory), there *is* a considerable
issue encountered when the frequency 'yearly' is selected instead of 'monthly'.

I wonder if it is worth the bother keeping the 'yearly' frequence, at least on the basis
of the current compute_depreciation implementation mechanics.

1. 'yearly' quite unconveniently hardcodes the annuity date to 31/12.
This naturally doesn't match the the accounting period end date
of all companies.

For example, in France, many close 31/03 or 30/09 and in the states 30/06
is rather common.

To be useful, there might need to be an initial annuity date (in absence
of a fiscal year being defined all the way back to the activation start_date,
that is for amortisations in progress in an accounting system migration)

2. The company's account period can change, for example to align to a calendar year
or to the contrary. This happens also quite frequently in connection with mergers
and acquisitions.

3. Using only 'monthly' avoids a lot of mucking around in calculations seeing
if the period is longer or shorter than a 'year', needing to verify for each
fiscal year end_date that an annuity is corrected for an activated asset.

All this is simplified keeping only a 'monthly' computation.

'Yearly' effects could still be done, for example, leaving it to the 'movement',
that is, either split by period or grouping all and collapsing into a single movement
at the end of the period... leaving the amortisation 'future' schedule monthly.

What are the experiences and opinions of users or those needing to use the module.

cheers,
--

Richard PALO

[Nicolas Évrard]

* Richard PALO [2016-04-20 12:28 +0700]:

>I've been tinkering getting a fully working 'degressive' amortisation
>method in account_assets.
>
>Although initially it was rather quite simple (at it is in theory),
>there *is* a considerable issue encountered when the frequency
>'yearly' is selected instead of 'monthly'.
>
>I wonder if it is worth the bother keeping the 'yearly' frequence, at
>least on the basis of the current compute_depreciation implementation
>mechanics.
>
>1. 'yearly' quite unconveniently hardcodes the annuity date to 31/12.
> This naturally doesn't match the the accounting period end date of
> all companies.
>
> For example, in France, many close 31/03 or 30/09 and in the
> states 30/06 is rather common.

Indeed this is a bug: https://bugs.tryton.org/issue5500
Thanks for reporting.

> To be useful, there might need to be an initial annuity date (in
> absence of a fiscal year being defined all the way back to the
> activation start_date, that is for amortisations in progress in an
> accounting system migration)

Indeed existing assets could be a problem.

But IIRC, the amortization lines can be edited and you could put as
the first line the total amount of the previous line. This line should
be in the accounting period you use to import the accounting from the
other system (as I guess you're using a special period to import those
data).

>2. The company's account period can change, for example to align to a
> calendar year or to the contrary. This happens also quite
> frequently in connection with mergers and acquisitions.

What happens then accounting wise for the assets?

>3. Using only 'monthly' avoids a lot of mucking around in
> calculations seeing if the period is longer or shorter than a
> 'year', needing to verify for each fiscal year end_date that an
> annuity is corrected for an activated asset.
>
>All this is simplified keeping only a 'monthly' computation.
>
>'Yearly' effects could still be done, for example, leaving it to the
>'movement', that is, either split by period or grouping all and
>collapsing into a single movement at the end of the period... leaving
>the amortisation 'future' schedule monthly.

If a company close its period frequently it might be a problem. I
don't know if they can use a temporary account and do the grouping
when closing the year, that might be OK.

--
Nicolas Évrard - B2CK SPRL
E-mail/Jabber: nicolas...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Richard PALO]

Le 20/04/16 10:56, Nicolas Évrard a écrit :

> * Richard PALO [2016-04-20 12:28 +0700]:
>> I've been tinkering getting a fully working 'degressive' amortisation
>> method in account_assets.
>>
>> Although initially it was rather quite simple (at it is in theory),
>> there *is* a considerable issue encountered when the frequency
>> 'yearly' is selected instead of 'monthly'.
>>
>> I wonder if it is worth the bother keeping the 'yearly' frequence, at
>> least on the basis of the current compute_depreciation implementation
>> mechanics.
>>
>> 1. 'yearly' quite unconveniently hardcodes the annuity date to 31/12.
>> This naturally doesn't match the the accounting period end date of
>> all companies.
>>
>> For example, in France, many close 31/03 or 30/09 and in the
>> states 30/06 is rather common.
>
> Indeed this is a bug: https://bugs.tryton.org/issue5500
> Thanks for reporting.

I am not sure this is the solution as it only moved the date elsewhere,
most likely *still* not to the end_date of the first fiscal year, which is the
problem statement I mentioned.

It doesn't react to any change to the accounting periode after the first annuity
either.

>
>> To be useful, there might need to be an initial annuity date (in
>> absence of a fiscal year being defined all the way back to the
>> activation start_date, that is for amortisations in progress in an
>> accounting system migration)
>
> Indeed existing assets could be a problem.

They are as I still have not found any way to get them dealt with.
Please advise... The initial balance is typically entered with the
depreciated amounts taken into consideration...

Perhaps a means to create/edit the 'line's with appropriate
values and some manner to indicate (or force) that the movement
for these periods are in the initial balance.

>
> But IIRC, the amortization lines can be edited and you could put as
> the first line the total amount of the previous line. This line should
> be in the accounting period you use to import the accounting from the
> other system (as I guess you're using a special period to import those
> data).
>
>> 2. The company's account period can change, for example to align to a
>> calendar year or to the contrary. This happens also quite
>> frequently in connection with mergers and acquisitions.
>
> What happens then accounting wise for the assets?

prorata temporis... (which is why always having the
monthly schedule would be quite useful).

>
>> 3. Using only 'monthly' avoids a lot of mucking around in
>> calculations seeing if the period is longer or shorter than a
>> 'year', needing to verify for each fiscal year end_date that an
>> annuity is corrected for an activated asset.
>>
>> All this is simplified keeping only a 'monthly' computation.
>>
>> 'Yearly' effects could still be done, for example, leaving it to the
>> 'movement', that is, either split by period or grouping all and
>> collapsing into a single movement at the end of the period... leaving
>> the amortisation 'future' schedule monthly.
>
> If a company close its period frequently it might be a problem. I
> don't know if they can use a temporary account and do the grouping
> when closing the year, that might be OK.
>

Don't really see why a temporary account would be necessary, perhaps
more a question to do a movement each month, or group them on the
annuity date, potentially in an optimised entry.

Seems Sage worked that way, if my memory isn't too fuzzy. But then again;b

BTW, Grouping is also potentially useful if the entity closes by quarter instead
of monthly.

I guess I should have also mentioned that activation dates not falling on the first
of the month can be problematic too, with 'linear' anyway.

Typically the default is a fiscal year comprised of 360 days = 12 months * 30 days
then there is also the method 'actual' (365 or 366 days per year with each month exact), or
the method 360 days in the year, but with the actual number of days in the month, or finally
the mothod 365 days (ignoring intercalary or bissextile years) with the actual number of days in the month.

compute_depreciation does not seem use the typical default.
It appears to use a mix of 30 days per month but actual days per year.
(Otherwise the monthly amounts would differ under 'linear')

This may be a source of difficulties.

--
Richard PALO

[Cédric Krier]

On 2016-04-20 14:15, Richard PALO wrote:
> Le 20/04/16 10:56, Nicolas Évrard a écrit :
> > * Richard PALO [2016-04-20 12:28 +0700]:
> >> I've been tinkering getting a fully working 'degressive' amortisation
> >> method in account_assets.
> >>
> >> Although initially it was rather quite simple (at it is in theory),
> >> there *is* a considerable issue encountered when the frequency
> >> 'yearly' is selected instead of 'monthly'.
> >>
> >> I wonder if it is worth the bother keeping the 'yearly' frequence, at
> >> least on the basis of the current compute_depreciation implementation
> >> mechanics.
> >>
> >> 1. 'yearly' quite unconveniently hardcodes the annuity date to 31/12.
> >> This naturally doesn't match the the accounting period end date of
> >> all companies.
> >>
> >> For example, in France, many close 31/03 or 30/09 and in the
> >> states 30/06 is rather common.
> >
> > Indeed this is a bug: https://bugs.tryton.org/issue5500
> > Thanks for reporting.
>
> I am not sure this is the solution as it only moved the date elsewhere,
> most likely *still* not to the end_date of the first fiscal year, which is the
> problem statement I mentioned.
>
> It doesn't react to any change to the accounting periode after the first annuity
> either.

Probably the current design is wrong. It should not be based on monthly
or yearly but instead base on period or fiscal year. But then we can not
create forecast as it is highly improbable that fiscal years and periods
will be create years in advance.
But if the user has the flexibility to define the date at which the
frequency starts than he can adapt to match its configuration.

> >> To be useful, there might need to be an initial annuity date (in
> >> absence of a fiscal year being defined all the way back to the
> >> activation start_date, that is for amortisations in progress in an
> >> accounting system migration)
> >
> > Indeed existing assets could be a problem.
>
> They are as I still have not found any way to get them dealt with.
> Please advise... The initial balance is typically entered with the
> depreciated amounts taken into consideration...
>
> Perhaps a means to create/edit the 'line's with appropriate
> values and some manner to indicate (or force) that the movement
> for these periods are in the initial balance.

I guess you can just put as value the value already depreciated at the
start date.

> >> 2. The company's account period can change, for example to align to a
> >> calendar year or to the contrary. This happens also quite
> >> frequently in connection with mergers and acquisitions.
> >
> > What happens then accounting wise for the assets?
>
> prorata temporis... (which is why always having the
> monthly schedule would be quite useful).

In such case, I think a new accounting will be started where all
existing assets will be re-encoded.

> >> 3. Using only 'monthly' avoids a lot of mucking around in
> >> calculations seeing if the period is longer or shorter than a
> >> 'year', needing to verify for each fiscal year end_date that an
> >> annuity is corrected for an activated asset.
> >>
> >> All this is simplified keeping only a 'monthly' computation.
> >>
> >> 'Yearly' effects could still be done, for example, leaving it to the
> >> 'movement', that is, either split by period or grouping all and
> >> collapsing into a single movement at the end of the period... leaving
> >> the amortisation 'future' schedule monthly.
> >
> > If a company close its period frequently it might be a problem. I
> > don't know if they can use a temporary account and do the grouping
> > when closing the year, that might be OK.
> >
>
> Don't really see why a temporary account would be necessary, perhaps
> more a question to do a movement each month, or group them on the
> annuity date, potentially in an optimised entry.
>
> Seems Sage worked that way, if my memory isn't too fuzzy. But then again;b
>
> BTW, Grouping is also potentially useful if the entity closes by quarter instead
> of monthly.
>
> I guess I should have also mentioned that activation dates not falling on the first
> of the month can be problematic too, with 'linear' anyway.
>
> Typically the default is a fiscal year comprised of 360 days = 12 months * 30 days
> then there is also the method 'actual' (365 or 366 days per year with each month exact), or
> the method 360 days in the year, but with the actual number of days in the month, or finally
> the mothod 365 days (ignoring intercalary or bissextile years) with the actual number of days in the month.

The methods are customizable so you can add the one you want easily.

> compute_depreciation does not seem use the typical default.
> It appears to use a mix of 30 days per month but actual days per year.
> (Otherwise the monthly amounts would differ under 'linear')

Patch is welcome.

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com

[Richard PALO]

Le 22/04/16 16:23, Cédric Krier a écrit :

> Probably the current design is wrong. It should not be based on monthly
> or yearly but instead base on period or fiscal year. But then we can not
> create forecast as it is highly improbable that fiscal years and periods
> will be create years in advance.

At the very least there needs to be some impedence matching provided between
month/year and period/fiscal year.

There are numerous means and reasons behind the depreciation decided upon in
a business.

If the mechanisms around generating schedules and managing actual moves are
simple but rich enough, the it should be able to cater to most needs.

That is, as long as the methods to generate the moves allows for:
- initial load of an accounting
- for fiscal year end (even if changed)
- as well as for interim accounting situations
(many company elect or have obligation to prepare one)

then KISS should probably apply.

If there were a requirements needs analysis done, I would wager that the all that
is really needed is the 'true' past, and future simulation.

A certified accountant or auditor may potentially invoke more specific details, though.

The past (prior to tryton-managed depreciation) should be possible to "fix", perhaps
as mentioned earlier by updating the first generated move with the date, value, depreciation,
and accumulated depreciation where date is the end_date of the period prior to the first
tryton managed one...(which may not be necessarily the first tryton fiscal account year).
This would allow folks to migrate to tryton managed assets when it suits them.

>>>> To be useful, there might need to be an initial annuity date (in
>>>> absence of a fiscal year being defined all the way back to the
>>>> activation start_date, that is for amortisations in progress in an
>>>> accounting system migration)
>>>
>>> Indeed existing assets could be a problem.
>>
>> They are as I still have not found any way to get them dealt with.
>> Please advise... The initial balance is typically entered with the
>> depreciated amounts taken into consideration...
>>
>> Perhaps a means to create/edit the 'line's with appropriate
>> values and some manner to indicate (or force) that the movement
>> for these periods are in the initial balance.
>
> I guess you can just put as value the value already depreciated at the
> start date.
>

I believe to be generally acceptable, perhaps other data still needs to be taken
into consideration..

For example, the degressive method coefficient (in France, at least) depends upon
such things as the date of activation and the duration... and the coefficient
magnitude has influence naturally upon when the linear optimisation kicks in.

I still sort of favour, currently at least, special first 'line' entry (or entries)
for 'in progress' depreciations.

>
>> compute_depreciation does not seem use the typical default.
>> It appears to use a mix of 30 days per month but actual days per year.
>> (Otherwise the monthly amounts would differ under 'linear')
>
> Patch is welcome.
>

Well, I'd like to get 'degressive' polished first, I think linear can be 'fixed'
and both methods optimised in a future pass.

Walk before run? Teething can be painful:-P Nicolas has a copy of the work in progress.
Once I get the GUI part reacting better, to me at least, I'll prepare the issue for comments.

cheers,

--
Richard PALO